Le fait d’être programmeur informatique est un métier qui fait vivre de nombreuses personnes depuis plus de 30 ans. Plus de la moitié d’entre eux sont des freelances, travaillant sur des projets pour les gens. J’ai remarqué une différence importante entre les projets très réussis et les projets moins réussis.
Y a-t-il quelqu’un avec qui discuter avec le développeur ?
Le développement de logiciels est un type de travail de connaissance. L’essentiel du travail consiste à comprendre les problèmes qui se posent et à inventer des solutions pour les résoudre. Parce que ce qui doit être fait en général n’est pas connu à l’avance, on le découvre en cours de route. Les approches modernes du développement, telles que les principes Agiles, en tiennent compte en rassemblant toutes les parties prenantes et en les engageant dans des conversations fréquentes, et en progressant de manière très progressive.
Mais beaucoup de gens pensent encore à tort que le logiciel est quelque chose de mécanique. Vous n’avez qu’à spécifier clairement ce que vous voulez, puis les programmeurs n’ont plus qu’à aller le coder. C’est ainsi que cela était généralement perçu il y a quelques décennies. Les analystes rédigeaient les spécifications de ce qui devait être fait, puis nous devions simplement appliquer suffisamment d’heures de travail des programmeurs pour l’implémenter. Cela n’a jamais bien fonctionné, parce qu’une fois que les programmeurs sont revenus avec le travail, six mois ou un an plus tard, et qu’on l’a montré aux gens qui l’avaient demandé, ils se rendaient généralement compte que ce n’était pas vraiment ce qu’ils voulaient, et ils demanderaient des changements. Et les analystes révisaient les spécifications et les programmeurs partaient et recommençaient le travail, et revenaient quelques mois plus tard. C’était l’idée autrefois, mais elle est ridiculement inutile et inefficace, de sorte que l’approche a été abandonnée pour la plupart. Toutefois, cela ne signifie pas nécessairement qu’il est facile de persuader les clients qu’ils doivent participer au processus. Parfois, c’est très difficile à vendre.
Le pouvoir de la conversation sur le succès d’un logiciel
Les projets logiciels les plus réussis que j’ai réalisés ont impliqué une conversation continue avec d’autres personnes, souvent tous les jours. Ça ne veut pas dire de longues réunions. De nos jours, il s’agit de brefs messages instantanés asynchrones et de courtes réunions face à face occasionnelles. Pas nécessairement avec tout le monde, mais il devrait certainement inclure quelqu’un qui a une idée de ce qui est nécessaire, c’est-à-dire quelqu’un qui représente les intérêts des utilisateurs finaux. Et, étrangement, c’est parfois très difficile à trouver, et cela pourrait faire beaucoup souffrir le projet. Cela signifie qu’il faudra beaucoup plus de temps, qu’il sera plus coûteux et qu’il est fort probable qu’il n’apportera pas ce dont on a vraiment besoin.
Le problème est en partie que la complexité est difficile à comprendre. La complexité est quelque chose de dynamique et de vivant qui ne peut pas être compris à l’avance, mais qui a des propriétés émergentes, qui peuvent ou non être celles que l’on souhaite. C’est par rapport à des choses qui sont simplement compliquées. S’il est compliqué, il pourrait être possible de faire un grand schéma de montage et de demander à quelqu’un de simplement suivre les instructions. Cela fonctionne avec beaucoup de choses, comme les meubles Ikea, mais pas avec d’autres, comme les logiciels. Ou la communication. Vous ne pouvez pas simplement impartir les relations d’une organisation avec les médias sociaux et vous attendre à ce qu’elles fonctionnent bien. Il doit y avoir quelqu’un à la maison qui participe au processus de recherche de ce qui fonctionne.
Alors, un mot pour moi : Affrontez le problème d’emblée. N’acceptez pas un projet de développement auquel le client ne participe pas lui-même. S’ils veulent simplement vous dire ce qu’ils veulent et vous dire combien de temps cela prendra, marchez dans l’autre sens.
