Les contours, le sable, la tempête... pipeau ! 
C'est vrai que l'imprévu (le "sable", la "tempête"), ça existe, que c'est même inévitable. C'est vrai qu'un système informatique, dès lors qu'il est un peu plus ambitieux que "Hello World", est un peu comme une réalité fractale (les "contours") : plus on s'en approche, et plus on s'aperçoit que chaque module en apparence simple est en fait un système plus ou moins complexe.
Mais ce n'est pas l'essentiel. Ce n'est pas l'imprévu technique ou informatique qui fait perdre l'essentiel du temps dans un projet : c'est l'être humain, avec ses comportements parfaitement habituels, ses habitudes inamovibles, ses méthodes souvent canoniques, son organisation verrouillée et presque intouchable, ses systèmes de management et de décisions inefficaces.
------------------------------------------
La réalité en face, c'est l'incompétence de personnes qui, exécutants ou cadres, côté client/métier, côté spécification/Maîtrise d'Ouvrage ou côté réalisation informatique/Maîtrise d'Oeuvre, sont incapables de faire correctement leur travail, de communiquer correctement avec leurs interlocuteurs, de transmettre des informations correctes au maillon suivant ou de demander correctement les informations nécessaires au maillon précédent dans cette chaîne qu'est la conception d'un logiciel.
Ce sont souvent aussi des méthodes auxquelles on est attaché et qui oui, ne sont pas agiles du tout, en tout cas pas adaptées au projet à réaliser. Ou des méthodes agiles que l'on n'a pas bien compris, ou qu'on ne maîtrise pas, quant ce n'est pas que l'on rejette : car il y a dans les méthodes agiles de nombreux principes qui peuvent déplaire, aux développeurs, mais surtout à toute la hiérarchie habituelle d'un projet qui voit bousculés ses petits pouvoirs et remis en question le contrôle qu'elle exerce habituellement.
Et ne parlons pas de nos organisations, souvent bureaucratiques à l'excès, parfois rigides jusqu'à la sclérose. Un nombre d'échelons hiérarchiques tels (et des relations hiérarchiques telles) qu'une information essentielle que détient un exécutant n'atteint jamais la moitié de la pyramide (surtout si elle dérange, elle peut même s'arrêter à l'échelon immédiatement supérieur). S'ajoutent à cela des cloisonnements horizontaux, des découpages par domaine, secteur, département, service... avec les éventuelles tensions ou conflits qu'il peuvent exister entre, pour rendre la communication des informations encore plus difficile. L'organisation "verticale" et "horizontale" des sociétés les rend rarement efficaces pour gérer les projets informatiques, surtout quand le logiciel doit être prêt pour dans 3 mois, car dans un an la donne aura changé.
Jetons aussi un œil sur le management : quel est l'intérêt pour un développeur de faire son travail vite et bien quand il sait que c'est quelqu'un d'autre qui en tirera les bénéfices (reconnaissance, promotion, augmentation). Dans certains projets, ce sont ceux qui ne font pas grand-chose mais savent se vendre qui réussissent à s'attribuer les mérites de la réussite de leur collaborateurs. Ceci est rarement de nature à faire avancer correctement un projet, cela n'assure pas dans l'équipe la motivation et la cohésion nécessaire justement quand il y a un imprévu, un "coup de bourre", une "charrette". Par contre, cela encourage les abandons de poste, les congés maladie et toutes choses que l'on va rajouter bien sûr à la liste des "imprévus" qui ont entravé la bonne marche du projet. Pour ceux qui voudraient comprendre pourquoi il y a autant d'incompétents à des postes pourtant élevés dans la hiérarchie, il y a le Principe de Peter (un peu simpliste, mais hélas pas assez pour être faux).
Ajoutons à cela aujourd'hui une incapacité croissante des décideurs à prendre une décision, rapidement et de façon stable ("on va quand même pas se mouiller, ça pourrait nous retomber dessus"), et comme chaque étape d'un projet est souvent soumise à plusieurs décisions, on comprend pourquoi non seulement on n'arrive pas à la date prévue, mais surtout on ne commence pas à la date prévue !
En plus de cela, il y a un vrai piège : dès qu'on fixe des délais, les différents acteurs fixent leur vitesse de croisière sur ces délais (surtout pas plus tôt, on ne voit aucun intérêt pour soi). Autrement dit, au moindre problème, au moindre impondérable, et un acteur prend 1 ou 2 semaines de retard. Le développement d'un logiciel étant un enchaînement d'étapes, c'est tout le projet qui dérape, entre les aléas des uns et les surprises des autres. Mais là encore, il y a pour cela des méthodes et des formes d'organisation pour éviter ces dérapages.
------------------------------------------
Or tout ceci, ça existe avant le projet, ça se voit, et même dans certains cas ça se sait. Qu'on ne veuille pas en tenir compte pour fixer des délais, planifier, alors oui SURPRISE, JE COMPRENDS PAS, ON PEUT PAS TENIR LES DELAIS ! 
La communication ça s'apprend. La motivation et l'implication des gens, cela s'encourage, la méthode, ça s'adapte (sinon ce n'est plus une méthode, mais un boulet). Et le management, car plus les projets sont importants, plus c'est là où ça pêche, ça s'apprend aussi et ça devrait s'adapter. L'organisation d'une entreprise, c'est censé s'améliorer aussi pour permettre l'atteinte des objectifs de l'entreprise, et non pour satisfaire les appétits de pouvoir des uns et des autres.
Dans tout cela, il n'y a rien d'imprévisible, rien dont on ne puisse tenir compte pour établir des plannings cohérents, réalistes. Et si l'état des compétences, des motivations, des méthodes, de l'organisation, du management ou du système de décision ne permettent pas de planifier, alors arrêtons de fixer des délais intenables et commençons d'abord par soigner le malade pour qu'il soit en état de marche !
Dans les gros projets, les problèmes informatiques, c'est 80% d'humain et 20% de technique. Les vrais imprévus sont peu nombreux et, à moins d'une destruction des locaux informatiques, jamais susceptibles de repousser notablement la fin de réalisation prévue.
En clair : IL N'Y A AUCUNE LOI QUI FAIT QU'INELUCTABLEMENT, UN PROJET DERAPE. Presque tout est "under control", le tout est de regarder les choses en face, et d'essayer de les changer si besoin pour que les projets puissent enfin suivre un cours normal.
Si nous ne sommes pas capables de regarder en face la réalité, pour voir où sont les vraies sources de dérapage d'un projet, si en plus nous n'avons pas l'envie ou le courage de changer cette réalité pour qu'enfin les projets puissent progresser normalement, alors oui, il faut multiplier par 10 pour être presque certain de ne pas déraper. 
Envoyé par GPPro
Répondre avec citation
Partager