Discussion :

[Stéphane le calme]

39% des projets informatiques aboutissent dans les délais et budgets impartis,
Forrester suggère aux développeurs une autre façon de penser

Forrester Research, spécialiste des études de marché sur l'impact des technologies dans le monde des affaires, a publié un rapport qui révèle une déconnexion entre l'informatique et l'entreprise. Sur les 474 responsables informatique d'entreprise dont les employés se compte par milliers, seuls 39% d'entre eux ont pensé que leurs structures informatiques internes avaient la capacité de finaliser régulièrement des projets dans les délais et le budget. D'ailleurs moins de la moitié (43%) estiment que leurs structures ont collaboré avec les entreprises sur les stratégies de l'entreprise et l'innovation.

Parmi les obstacles qu'ils ont rencontrés, 56% d'entre eux estiment que le plus important se retrouve dans des exigences utilisateurs en constante évolution sur des projets déjà en traitement. La moitié estiment être surchargés de travail et finir donc par essayer de trop en faire à la fois. Plus d'un tiers (34%) estiment qu'ils manquent de directives exécutives claires, tandis que 34% déplorent le manque de talent de développeur adéquat.

Côté satisfaction, moins de la moitié des décideurs IT ont eu un retour favorable quant au développement des applications mobiles à l'intention de leurs clients. En revanche la plupart ont retrouvé le sourire une fois qu'il était question d'expérience utilisateur sur les d'applications web.

Les développeurs se montrent eux aussi très insatisfaits par leurs départements. Moins de la moitié d'entre eux estiment que leurs départements informatiques répondent à leurs besoins technologiques ou encore a une compréhension de leurs besoins pour mener à bien leurs tâches.

A la lumière de tous ces éléments, les auteurs du rapport font des recommandations pour permettre d'améliorer la collaboration entre la technologie et le monde des affaires. Pour eux, les équipes de développement d'applications ne devraient pas se limiter à la création d'applications, mais devraient aussi tenir compte de leur impact sur les entreprises et ainsi considérer le tableau dans son ensemble. Ils devraient orienter leurs décisions en prenant en considération des paramètres comme les objectifs de l'entreprise, l'expérience client, les processus d'affaires, les employés, la technologie, l'architecture et l'intégration; se rassurer que chacune des milliers de technologie, processus d'affaires, et les décisions concernant l'interface utilisateur soient liés à la fois au bon plaisir des clients et au service des objectifs de l'entreprise.

Ils proposent aux équipes de développement de :

• prendre la responsabilité avec une pensée d'intégration : une pensée d'intégration requiert des équipes de développement de visualiser le tableau dans son ensemble et d'accepter la responsabilité non seulement de la conception des applications mais de leur impact positif ou négatif sur l'entreprise ;
  
• concevoir des tâches avec des personnes qui comprennent à la fois les affaires et la technologie ;
  
• mesurer chaque décision de conception en se basant sur son impact sur l'expérience utilisateur.

Source : Effective UI (au format PDF)

Et vous ?

Est-il fréquent ou occasionnel que vous finissiez un projet informatique dans les délais et le budget ?

Que pensez-vous des recommandations de Forrester ?

[ctxnop]

Je n'ai même pas lu l'article, le simple sous-titre m'en dissuade.
C'est toujours la faute du développeur, jamais celle du commercial qui vends des choses infaisables ou dans des délais délirants. Jamais celle du chef de projet qui promet des délais toujours plus court et impose des choix techniques alors qu'il ne sait même pas écrire un hello world dans le langage utilisé par l'équipe.

Bien évidemment que le développeur à des responsabilités dans les retards et les dépassement de budget, mais c'est toujours la même chose, quand une entreprise va mal elle demande un audit qui va systématiquement pointer du doigt le gars en bas de l'échelle : on ne dénonce pas l'incompétence de ceux qui nous payent.

Bref, avec un tel sous-titre, je n'ai pas envie de lire le reste de l'article, aussi bon/juste/impartial soit-il.

[imikado]

Est-il fréquent ou occasionnel que vous finissiez un projet informatique dans les délais et le budget
On arrive généralement à finir dans les délais, mais c'est souvent en travaillant plus d'heures/jour que prévus

Après je comprends le problème des deux cotés: coté utilisateur , il est toujours difficile d'imaginer une interface, c'est en l'utilisant que l'on se rent compte des choses non ergonomiques...
Et coté développeur, forcément, la charge estimée en début de projet ne cesse d'augmenter

Ce que l'on fait pour limiter ceci, c'est d'être itératif et force de proposition: on critique et modifie les maquettes (par expérience) avec leur accord, et l'on donne la main à l'utilisateur pour tester au fur et à mesure que l'application est développée (livraison de micro lots)

[yimson]

Merci à Forrester Research pour ces statistiques, cela permet de mieux comprendre comment évolue les travaux des développeurs.
Mais seulement, un projet informatique qui n'aboutit pas, est-ce toujours la faute du développeur?
J'embraye ici dans le même sens que ctxnop, pour dire, qu'il faudrait que nos chef de projet et nos managers soient des personnes qui ont été aussi à la feuille de l'arbre.

Je pense que les entreprises devraient comprendre que ils existent d'autres entreprises dédiées dont le métiers est de développer des logiciels et de faire aussi de l'intégration (SSII), au lieu de faire développer leur produit en interne, il serait préférable de sous traiter cette tache afin qu'elle soit réalisé proprement car pour les SSII c'est leur métier.

Concernant, les recommandations de Forrester, je me rends compte qu'elles résument le fait que les exigences utilisateurs sont au centre du développement d'un logiciel et que le produit est au finish destiné à l'utilisateur. Une fois de plus, les directions informatiques doivent externaliser les développements de logiciels vers les SSII, car ce sont les SSII qui ont la compétence et les qualifications nécessaires car elles sont dédiées.

[yahiko]

Je n'aime pas trop le titre qui réinterprète grossièrement le contenu de l'enquête.

Il ne s'agit pas de 39% des projets qui aboutissent dans les clous, mais d'une opinion partagée par 39% de responsables informatiques. A partir de là, nous ne sommes plus dans le domaine des faits, mais des croyances.

[plawyx]

C'est toujours la faute du développeur, jamais celle du commercial qui vends des choses infaisables ou dans des délais délirants. Jamais celle du chef de projet qui promet des délais toujours plus court et impose des choix techniques alors qu'il ne sait même pas écrire un hello world dans le langage utilisé par l'équipe.

Tout est dit

[kremvax]

C'est toujours la faute du développeur, jamais celle du commercial qui vends des choses infaisables ou dans des délais délirants. Jamais celle du chef de projet qui promet des délais toujours plus court et impose des choix techniques alors qu'il ne sait même pas écrire un hello world dans le langage utilisé par l'équipe.

Tiens, on bosse dans la même boite??

[redcurve]

Je n'ai même pas lu l'article, le simple sous-titre m'en dissuade.
C'est toujours la faute du développeur, jamais celle du commercial qui vends des choses infaisables ou dans des délais délirants. Jamais celle du chef de projet qui promet des délais toujours plus court et impose des choix techniques alors qu'il ne sait même pas écrire un hello world dans le langage utilisé par l'équipe.

Bien évidemment que le développeur à des responsabilités dans les retards et les dépassement de budget, mais c'est toujours la même chose, quand une entreprise va mal elle demande un audit qui va systématiquement pointer du doigt le gars en bas de l'échelle : on ne dénonce pas l'incompétence de ceux qui nous payent.

Bref, avec un tel sous-titre, je n'ai pas envie de lire le reste de l'article, aussi bon/juste/impartial soit-il.

Oui, pareil ma SSII veut que je délivre à terme une version par semaine alors que déjà souvent les specs sont foireuses, je trouve des énormités chaque jour. En plus, de ça le réseau interne a été monté par des singes mongoliens, je veux bien bosser mais il faudrait déjà que je puisse me connecter au contrôleur de sources etc. Du grand n'importe quoi, le chef de projet ex dev est mauvais dans ce métier mais il veut absolument être chef de quelque chose, il fait des trucs super chiant du genre, modifier les sources (en créant des bugs bien entendu sinon ce n'est pas marrant) et check-in le tout sans faire get-latest avant ... et là le mec t'écrase des heures de boulot .

Sur un autre projet les commerciaux ont vendu des choses techniquement impossible à un client le tout avec des délais tirés par les cheveux. Verdict mon collègue à du tout refaire en MVC, et le délais vendu de 15 jours a été explosé il en est à 25 et il n'a pas fini . Il est tellement gavé que maintenant il arrive tout les jours à 14h parce que de toute façon 95% du temps il n'y a pas le net, et le réseau interne fonctionne mal ou pas du tout

[Cincinnatus]

Contrairement à yimson (

Je pense que les entreprises devraient comprendre que ils existent d'autres entreprises dédiées dont le métiers est de développer des logiciels et de faire aussi de l'intégration (SSII), au lieu de faire développer leur produit en interne, il serait préférable de sous traiter cette tache afin qu'elle soit réalisé proprement car pour les SSII c'est leur métier.

) je pense que nombre de développements gagnent à être réalisés en interne, par des équipes connaissant l'entreprise / administration cliente.
Ainsi, les développeurs connaissent les équipes fonctionnelles concernées, les équipes sont (relativement) stables et il n y a pas de surfacturation .

Tous les logiciels ne doivent pas être réalisés par des usines logicielles ; une bonne part répond à des besoins plus ou moins spécifiques. Après, libre aux équipes rencontrant un besoin proche de partager certains dévs en coopérant entre elles ou même en open source.

[Cincinnatus]

Je n'ai même pas lu l'article, le simple sous-titre m'en dissuade.
C'est toujours la faute du développeur, jamais celle du commercial qui vends des choses infaisables ou dans des délais délirants. Jamais celle du chef de projet qui promet des délais toujours plus court et impose des choix techniques alors qu'il ne sait même pas écrire un hello world dans le langage utilisé par l'équipe.

Bien évidemment que le développeur à des responsabilités dans les retards et les dépassement de budget, mais c'est toujours la même chose, quand une entreprise va mal elle demande un audit qui va systématiquement pointer du doigt le gars en bas de l'échelle : on ne dénonce pas l'incompétence de ceux qui nous payent.

Bref, avec un tel sous-titre, je n'ai pas envie de lire le reste de l'article, aussi bon/juste/impartial soit-il.

J'ai rencontré le cas d'un développement à livrer 2 mois après la demande, alors que nous étions fermés 3 semaines en été...
La direction proposait de faire appel à un prestataire externe. Le temps de le trouver, de le mettre au fait de la demande (avec les responsables fonctionnels qui s'absentent), puis qu'il réalise le dév et la reprise des données, on aurait explosé les délais... (cf la loi de Brooks)

Alors les SSII pour ces situations :

[Arnard]

Alors, travailler en fonction du retour/ressenti client, c'est très bien, sauf que le user final, tu le vois jamais, vu que tu as toujours une couche MOA qui pense à la place de l'utilisateur et qui néglige de lui demander son avis... Le nombre de fois qu'on m'a dit :
- ça c'est débile
- ça, ça aurait été mieux comme ça
- ça, ça nous manque ...

[ericherve]

Contrairement à beaucoup d'autres commentaires, je pense que dans le sous-titre "développeurs" est générique, et ne concernent pas uniquement les gars qui codent vraiment. Ce que je comprends, c'est que c'est surtout l'appeau à troll de la fin de semaine.

En gros cet article dit :
- Chaque strate de l'organisation voit les problèmes selon son propre point de vue, et chaque strate prend les autres strates pour des caves (un grand classique).
- Faites du agile (pas de l'arrache)
- Améliorer vos organisations (avec des gens compétents (sérieux???) et des gens qui comprennent ce qu'ils font au niveaux tech + biz (2xsérieux???))

Ce sur quoi, on est vraiment avancer.
Merci Forrester.
J'en parle dès lundi à mes collaborateurs. Vraiment, ça nous aide.

[Patriarch24]

Une fois de plus, les directions informatiques doivent externaliser les développements de logiciels vers les SSII, car ce sont les SSII qui ont la compétence et les qualifications nécessaires car elles sont dédiées.

sous traiter cette tache afin qu'elle soit réalisé proprement car pour les SSII c'est leur métier.

Bien sûr, les SSII travaillent proprement et sont les seules à mener à terme des projets logiciels...
Il n'y a rien à sortir de cette étude : tout ce que qui y est dit a déjà été étudié et analysé depuis 20 ans. Pour ceux qui seraient encore en retard, il reste ces pseudos analyses qui affirment que les responsables de sociétés sont persuadés que leurs équipes font leur taff en temps et en heure. Ben voyons...

[Arnard]

J'ai compris l'astuce, je ne donne plus de plannings. Je la joue à la blizzard : When it's done !

[Kearz]

tandis que 34% déplorent le manque de talent de développeur adéquat.

Un développeur, ça se paie.
Un bon développeur, ça se paie un peu plus.
Un développeur talentueux, ça se paie beaucoup plus.

Ceux qui sortent le porte monnaie se plaignent rarement du talent de leur développeur. (sauf s'ils ont pas payé leur RH pour avoir de bon RH)

Mais mince alors, ça voudrait dire que dans tous les métiers pour avoir des gens bons il faut les payer plus que les mauvais?

Je pense que les entreprises devraient comprendre que ils existent d'autres entreprises dédiées dont le métiers est de développer des logiciels et de faire aussi de l'intégration (SSII)

Et dans le service informatique des boites, on se sert à rien?
Je suis désolé mais les services informatiques des boites sortent des produits de meilleurs qualité que les SSII parce qu'ils:
- connaissent le contexte.
- pensent plus "qualité" qu'argent parce que derrière les utilisateurs se plaignent directement.
- sont touchés directement par les développements.

Une SSII n'en a pas "rien à foutre" mais presque, l'important c'est d'avoir le contrat. Le devoir de conseil des SSIIs? ça passe souvent à la trappe.
La qualité des dév? Aucun intérêt, ils vaut mieux torcher un truc vite et pas cher pour gagner le contrat.

Les seuls avantages des SSIIs:
- Domaine de compétences potentiellement plus large.
- Consulting parce qu'ils ont probablement eu des projets similaires sur d'autres boites.
- Main d'oeuvre temporaire pour éviter d'avoir des services informatique trop grand. (maintenant quand on voit des prestas qui restent des années dans le même service info, il faudrait peut-être embaucher.)

[Luckyluke34]

Il ne s'agit pas de 39% des projets qui aboutissent dans les clous, mais d'une opinion partagée par 39% de responsables informatiques. A partir de là, nous ne sommes plus dans le domaine des faits, mais des croyances.

+1

En plus, le sondage comportait à l'origine une échelle de 1 à 5 et seules les réponses donnant un score de 4 ou 5 ont été retenues comme confirmant le point en question, ce qui laisse les scores de "3" assez inexpliqués.

Certaines études plus basées sur de l'analyse de données factuelles comme le Chaos Report semblent confirmer ce faible taux de succès des projets, mais donnent en même temps un taux de projets à "issue mitigée" (délai, budget, fonctionnalités) de 43%. Ca reste à mon avis de mauvais chiffres quand même, signe d'un petit problème dans notre profession, et ce n'est pas réservé aux départements informatiques internes par opposition aux SSII.

[kiprok]

Je pense que les entreprises devraient comprendre que ils existent d'autres entreprises dédiées dont le métiers est de développer des logiciels et de faire aussi de l'intégration (SSII), au lieu de faire développer leur produit en interne, il serait préférable de sous traiter cette tache afin qu'elle soit réalisé proprement car pour les SSII c'est leur métier.

De mon coté, apres externalisation des developpements, le bilan est assez simple : explosion des temps de realisation, explosion du budget.
Ce qui me semble logique car plus on a de distance entre le client et la réa, plus c'est compliqué...

Ce qui n'a pas explosé? La qualité des dev, qui est plutot en nette baisse...

Le truc "positif" pour nos responsables est le "c'est pas nous c'est notre presta" qu'ils peuvent balancer à nos clients lorsqu'ils ne sont pas contents...

[gangsoleil]

Je pense que les entreprises devraient comprendre que ils existent d'autres entreprises dédiées dont le métiers est de développer des logiciels et de faire aussi de l'intégration (SSII), au lieu de faire développer leur produit en interne, il serait préférable de sous traiter cette tache afin qu'elle soit réalisé proprement car pour les SSII c'est leur métier.

Merci, j'ai bien rigolé !

Sans rire, quelle est la difference entre une entreprise dans laquelle tu as un commercial, il voit un contrat, il se prostitue pour l'avoir, et c'est au developpeur de se debrouiller, et une SSII dans laquelle tu as un commercial, il voit un contrat, il se prostitue pour l'avoir et c'est au developpeur de se debrouiller ?

Concernant, les recommandations de Forrester, je me rends compte qu'elles résument le fait que les exigences utilisateurs sont au centre du développement d'un logiciel et que le produit est au finish destiné à l'utilisateur. Une fois de plus, les directions informatiques doivent externaliser les développements de logiciels vers les SSII, car ce sont les SSII qui ont la compétence et les qualifications nécessaires car elles sont dédiées.

Et donc tu es reellement persuade que la SSII est a meme de comprendre le besoin du client de l'entreprise, client qu'elle ne connait pas et dont elle ignore tout ?
Mieux que l'entreprise qui est en lien direct avec son client, qui peut le joindre pour lui demander des precisions, des reunions, du suivi, ... ??

Ils proposent aux équipes de développement de :

• prendre la responsabilité avec une pensée d'intégration : une pensée d'intégration requiert des équipes de développement de visualiser le tableau dans son ensemble et d'accepter la responsabilité non seulement de la conception des applications mais de leur impact positif ou négatif sur l'entreprise ;
  
• concevoir des tâches avec des personnes qui comprennent à la fois les affaires et la technologie ;
  
• mesurer chaque décision de conception en se basant sur son impact sur l'expérience utilisateur.

Que pensez-vous des recommandations de Forrester ?

Ils sont deconnectes de la realite commerciale existant aujourd'hui : juste expliquer que pour X jours de developpement il faut 3X jours en tout (specs, dev, tests, docs), les commerciaux s'evanouissent, alors si en plus il faut faire tout ca, on va tendre vers 4X ou 5X...

Si Forrester vend ca a des commerciaux qui le vendent aux clients, je veux bien faire tout ca en plus.

[marc.collin]

Les résultats sont similaires à ceux présenté par standish group via le chaos report
C'est beaucoup mieux qu'au tout début de ces études (95-96).

Et c'est similaire pour la mise en place de ERP, CRM...
Une étude parmis d'autre concernant les ERP: http://www.zdnet.com/2013-erp-resear...fo-7000011619/

Les décisionnaires n'ont qu'à prendre leur responsabilités.

[CodeurPlusPlus]

"Ouah non mais ils sont trop nuls les développeurs ! Toujours en retard, toujours à dépasser le budget, et encore le résultat n'est pas parfait ! Oh les nazes !
- Ah ouais ? ébin t'as qu'à virer tous les developpeurs qui bossent pour toi, et recruter d'autres grosses taches de ton espèce pour voir s'ils font le boulot mieux que ceux dont c'est le métier."