Retards des projets informatiques
Pendant le boom de l’informatique dans les années 2010, c’était habituel que les projets soient délivrés avec beaucoup de retard. Néanmoins, les développeurs travaillent de longues heures avec beaucoup de pression. Quel était le problème, alors ? Est-il résolu aujourd’hui ?
Le développement de logiciels était une profession neuve. C’était habituel de trouver des problèmes inattendus durant les projets. Pour cette raison, les estimations initiales, faites pendant la phase d’analyse, ne devenaient plus valables. Par contre, par rapport au contrat, il y avait une date de livraison qui devait être respecté. Souvent, c’étaient les développeurs qui faisaient les estimations et qui se trompaient. Ceci les rendait responsables de respecter leurs estimations et donc de travailler dur.
Vous penserez qu’ avec de l’expérience, de nos jours, les estimations sont plus précises et donc les projets plus prédictibles. Malheureusement, ce n’est pas le cas car la technologie change rapidement. Les développeurs ont peur de se tromper et résistent à donner des estimations ce qui rend impossible la planification d’un projet.
Les développeurs, de manière assez générale, sont orientés sur résultats. Le travail de résolutions de problèmes leur plait. Ils aiment avoir des tâches bien définies ; néanmoins, le travail d’analyse est différent. C’est un autre métier. En fait, c’est n’est pas juste de rendre responsables les développeurs d’un travail que n’est pas le leur.
De nouvelles méthodologies de gestion ont récemment émergés, plutôt orientés sur les tâches, sans prescrire d’estimations. Par exemple ITIL dans la gestion de services, ou Kanban pour la gestion de ticketing. Ces méthodologies permettent que les développeurs travaillent à leur rythme sans pression. Par conséquent, les développeurs sont protégés.
Ces méthodologies offrent des avantages, surtout quand l’incertitude est grande ou les tâches sont répétitives. En revanche, elles n’aident pas au business qui se plaint souvent du manque de transparence et de l’inhabilité de bien prioriser. De plus, ces méthodologies ouvrent la porte à l’abus; le nombre de tickets résolu n’est pas synonyme d’un bon travail, il n’est pas non plus lié directement avec le succès du business. La bonne priorisation et définition des tâches est essentielle et ceci demande une étroite collaboration entre tous.
En conclusion, ni les méthodologies anciennes, ni les actuelles fonctionnent bien. Il faut que les développeurs comprennent les vrais besoins du business et que le business comprenne les vraies difficultés des développeurs. Dans ce but, à mon avis, il vaut mieux valoriser la transparence et la collaboration plutôt que l’individualisme, la responsabilité et le processus. Pour la majorité des entreprises, ceci demande un changement culturel assez grand qui doit être géré par un expert dans le métier.









