20 raisons pour lesquelles les projets logiciels échouent
Chaque projet logiciel commence par de grands rêves et de grandes visions. Quelque part dans un univers alternatif, il y a un projet qui réalise tous les rêves, mais trop souvent, les projets logiciels de notre univers trébuchent vers la ligne d’arrivée et la franchissent parfois.
Bien sûr, par définition, l’échec d’un projet logiciel n’est pas une chose binaire. Vous pouvez vous retrouver avec un code qui fonctionne bien mais que personne n’utilise. Ou vous pouvez vous retrouver avec du code qui ne sera même pas compilé. Parfois, vous pouvez récupérer quelque chose d’utile de l’épave enflammée et parfois, il est préférable de s’enfuir avant qu’elle n’explose.
Lorsque le désordre couvant se refroidit, les autopsies commencent, car les gens veulent savoir ce qui n’a pas fonctionné. Voici les coupables les plus courants.
Trop peu de membres de l’équipe
Essayer d’en faire trop avec trop peu de programmeurs est un problème courant. Les développeurs ne peuvent broyer autant de code qu’avant de s’épuiser. J’ai déjà travaillé dans une équipe où le manager pensait que la bonne façon de presser plus de travail des équipes agiles était de planifier chaque « sprint » pour qu’il commence immédiatement après le précédent. Aucune pause réfléchie pour comprendre ce qui fonctionnait et ce qui ne fonctionnait pas. Le Sprint 42 s’est terminé mercredi à 13h59 et le Sprint 43 a commencé mercredi à 14h00. Des réunions d’analyse rétrospective étaient prévues après le prochain sprint déjà commencé. Un gars intelligent a suggéré qu’ils soient renommés « marathons » et a rapidement trouvé un autre emploi.
Bien sûr, il est difficile de savoir combien de programmeurs suffisent. Parfois, les barrages routiers et les problèmes se mettent en travers du chemin. Ce n’est peut-être pas la faute du gestionnaire si le travail double de taille, mais si vous n’avez pas assez de personnes au travail, votre projet est probablement voué à l’échec.
Trop de membres de l’équipe
Si trop peu de programmeurs peuvent être mauvais, trop de programmeurs pourraient potentiellement être pires, car les effets de réseau peuvent condamner un projet logiciel. Plus de personnes signifie plus de coordination et cela signifie plus de réunions, en prenant du temps pour écrire du code. Mais si vous n’organisez pas assez de réunions, vous découvrirez bientôt que l’API de l’équipe A n’interfacera pas les microservices de l’équipe B.
Ce serait bien si nous pouvions simplement jeter de l’argent sur un problème en surchargeant un projet, mais vous ne pouvez pas.
Trop de communication
Écrire un logiciel est un art solitaire. Les humains peuvent travailler ensemble, mais seulement dans des combats limités. De nombreux développeurs détestent les réunions parce qu’ils doivent passer de la pensée logique immersive profonde au mode social plus ouvert. Cela prend du temps. Certains chefs d’équipe tentent de lutter contre l’échec en organisant plus de réunions pour garder tout le monde synchronisé. C’est un effort noble, mais vous pouvez entendre les engrenages grincer. L’équipe doit partager suffisamment d’informations pour rester synchronisée, mais ne fait plus que gaspiller les cycles cérébraux.
Modifications des fonctionnalités fondamentales
En théorie, les développeurs aiment se considérer agiles. C’est pourquoi ils embrassent la parole. Mais parfois, l’agilité peut déséquilibrer tout le monde. Tout dépend si le changement nécessite des changements fondamentaux au cadre sous-jacent. Il est facile d’être agile lorsque vous déplacez un bouton ou changez de couleur. Mais lorsqu’il s’agit de retravailler le schéma de la base de données ou de se débrouiller avec le sharding et la réplication, il n’y a pas de moyen facile de pivoter gracieusement.
Choisir la mauvaise technologie pour le travail
Même si vous planifiez soigneusement et établissez la liste correcte des fonctionnalités, les choses peuvent échouer si vous utilisez la mauvaise technologie. Les bases de données, par exemple, sont conçues pour être générales et flexibles, mais ont des limites architecturales. Poussez-les à livrer quelque chose qu’ils ne sont pas conçus pour faire, et ils ralentiront à un arrêt virtuel lorsqu’on leur demandera d’évoluer. Ou vous pouvez commencer par une base de données NoSQL car elle semble cool pour découvrir plus tard que vous avez vraiment besoin de transactions de qualité ACIDE pour garder les choses cohérentes et que la base de données ne les offre pas. Oops.
Mauvaise hiérarchisation
De bons planificateurs dressent une liste de fonctionnalités et les hiérarchisent. Mais parfois, les priorités ne correspondent pas à la réalité de leur mise en œuvre. Dans le pire des cas, les fonctionnalités les plus importantes sont les plus difficiles à créer.
Que doivent faire vos développeurs ? S’ils se concentrent sur la fonctionnalité la plus importante, ils ne feront aucun progrès et pourraient finir par ne fournir aucune des fonctionnalités. Mais s’ils commencent à éliminer les plus faciles, ils peuvent se retrouver avec quelque chose qui ne vaut rien.
Une bonne planification nécessite plus qu’une liste de contrôle. La vision architecturale doit prendre en compte les besoins et le coût de leur livraison.
La fenêtre de marché se ferme
Parfois, ce n’est pas la faute du programmeur. Un de mes projets était de transformer un livre de référence à succès en application. Le livre s’est vendu comme des petits pains dans les années précédant Internet. Le plan était de puiser dans cette demande et de créer une version interactive qui permettrait aux gens de trier et de rechercher les données. L’équipe de programmation a livré un logiciel qui comprenait tout dans le livre, mais qui était plus rapide, plus joli et beaucoup plus léger que le livre lui-même. Mais plus personne n’en voulait. Il y avait suffisamment d’autres sources et personne n’avait besoin d’une autre application qui faisait à peu près la même chose que les sites d’information partout.
Parfois, une idée semble géniale, mais le marché a évolué.
Mauvaises décisions architecturales
Sur un projet, on m’a confié la tâche de changer un numéro sur une ligne dans la base de données. Lorsque l’utilisateur a fini de s’inscrire, je devais ajouter le numéro d’identification de l’utilisateur à la dernière commande. Cela semble simple, non? Mais le système a été construit sur une architecture de microservices et je ne pouvais pas résoudre ce problème en écrivant une ligne de code qui indiquerait à la base de données de METTRE À JOUR cette colonne. Non. Le plan architectural était d’ajouter un nouvel appel de microservice à la pile existante et même cela était difficile car mon premier appel de microservices devait déclencher un autre appel de microservices, etc.
En fin de compte, le génie de l’architecture qui a créé ce réseau de microservices m’a dit que tout était très simple et a tracé un chemin serpentin à travers cinq couches de l’architecture. Mon travail consistait à ajouter cinq nouveaux appels d’API à cinq microservices différents, ce qui signifiait également l’ajout de cinq ensembles de tests automatisés pour chaque couche. Et chaque API a été développée par une équipe différente au fil des ans, ce qui m’a obligé à comprendre et à émuler cinq styles de codage différents. Tout pour changer un numéro.
Les décisions architecturales peuvent durer toute une vie, surtout si votre ego y est complètement investi et que vous ne pouvez pas les changer. Les chefs de projet doivent être prêts à remarquer que le plan architectural principal ne fonctionne pas pour que de grandes décisions puissent être prises.
Conflits politiques
Blâmer des facteurs politiques pour une défaillance technique peut sembler farfelu, mais c’est de plus en plus vrai. Au fur et à mesure que les projets prennent de l’ampleur et couvrent plusieurs organisations, il ne devrait pas être surprenant que des factions apparaissent et des groupes jockey pour le contrôle, les ressources et finalement le pouvoir.
Les factions politiques sont différentes des différences techniques réelles. Il existe souvent des normes techniques ou des bases de code qui font à peu près la même chose de différentes manières. Prenez XML et JSON. Maintenant que j’ai tapé cela, je peux sentir les fans de l’un ou l’autre se précipiter pour expliquer pourquoi ils ne sont pas les mêmes et que leur choix préféré est le bon. Mais quand une partie d’une équipe aime un choix et qu’une autre tient la faction concurrente en haute estime, eh bien, la friction va les déchirer.
Ceci est devenu encore plus courant lorsque les architectes ont divisé les applications en plusieurs services et API plus petits. Différents groupes finiront par les contrôler et ils ne s’entendront pas toujours. Si le groupe A aime JSON et que le groupe B s’accroche à XML, votre équipe devra soit implémenter les deux, soit faire en sorte que l’un d’eux change. Les trois sont une douleur pour toute équipe qui doit travailler avec les groupes A et B.
Parier sur une technologie qui n’est pas prête pour la production
Les programmeurs adorent les derniers outils et frameworks. Ils veulent croire que la nouvelle approche balayera toute la crue qui submerge la génération précédente.
Mais souvent, la prochaine génération n’est pas prête à être utilisée en production. Les nouvelles fonctionnalités peuvent sembler parfaites, mais il y a souvent des lacunes qui ne sont pas immédiatement évidentes. Parfois, le code ne prend en charge que quelques types de fichiers ou interfaces avec seulement quelques bases de données. Les autres arrivent bientôt, vous assurent-ils, mais votre projet doit être livré ce mois-ci et « bientôt » pourrait signifier six mois ou plus avant la fin des fonctionnalités dont vous avez besoin.
Parier sur une technologie qui sera bientôt dépassée
D’après mon expérience, l’ancienne technologie est généralement plus fiable et testée au combat, mais cela ne signifie pas que l’ancienne technologie est parfaite. Il peut manquer des fonctionnalités essentielles à votre projet logiciel une fois qu’il sera en ligne. Pire encore, parier sur la vieille technologie peut vous faire rater des opportunités futures en fonction des changements à venir. De nouvelles idées, protocoles et formats de fichiers apparaissent, et ils peuvent ne pas être mis en œuvre. Et si quelqu’un d’une équipe concurrente insiste pour que vous souteniez un nouveau protocole, l’ancienne technologie fera mal.
Délais irréalistes
Les délais sont difficiles. De nombreux projets doivent être commercialisés selon une saison ou un événement particulier. Pourtant, lorsque les délais sont écrits pour la première fois, vos développeurs n’ont pas commencé à découvrir les obstacles et les obstacles sur leur chemin. Ensuite, si le projet glisse et que l’événement passe sans que le logiciel ne soit lancé, l’ensemble du projet est considéré comme un échec même si le code est sur le point de fonctionner correctement. Les délais aident tout le monde à se concentrer et à se rassembler, mais ils créent également des attentes qui peuvent être irréalistes.
Concurrence imprévue
Un bon chef de produit surveille la concurrence avant de plonger, mais personne ne peut prédire quelle concurrence peut apparaître de nulle part. Si de nouveaux concurrents introduisent de nouvelles fonctionnalités que vous devez dupliquer, consultez les sections sur les modifications des fonctionnalités et les incompatibilités de priorité, ci-dessus.
Accélérer le processus
De nombreux projets logiciels commencent comme la vision d’une personne ou d’une équipe qui veut réparer quelque chose. Ils proposent une phrase comme « Snapchat pour Y » ou « Uber pour Y », puis s’attendent à ce que l’équipe produit soit aussi réactive que Snapchat ou Uber. Le problème est que déterminer la portée du projet, esquisser les flux de données et imaginer l’interface utilisateur représentent souvent dix fois plus de travail que d’écrire le code. Mais les imagineers veulent passer de l’idée au code tout de suite.
Les wireframes, le schéma de base de données et les user stories ne sont pas seulement des agitations de la main, mais une partie essentielle du travail. Mais la plupart des gens veulent croire qu’un projet logiciel ne fait qu’écrire du code pour mettre en œuvre une idée.
Croyance fausse au pouvoir du logiciel
Les rêveurs ont souvent des croyances irréalistes au pouvoir du logiciel de changer le monde. Beaucoup imaginaient que les médias sociaux nous uniraient, mais ce ne sont que des lignes de faille exposées qui étaient toujours évidentes. Les projets logiciels commencent souvent par des diaporamas qui promettent de révolutionner un coin du monde. Lorsque l’insertion de bits dans une base de données ne transforme personne, eh bien, les gens se fâchent, s’ennuient, sont confus ou pire. Ils disent que le logiciel est cassé parce qu’il ne parvient pas à livrer la transformation magique à laquelle tout le monde s’attendait.
De nombreux projets logiciels peuvent compiler, passer l’assurance qualité, expédier et même obtenir des critiques décentes, mais ne parviennent finalement à réaliser aucune des promesses du slide deck car, eh bien, ces promesses de changement du monde sont impossibles.
Sous-traitants maléfiques
Nous aimons les fournisseurs qui produisent les bibliothèques et les outils qui nous permettent de créer de la magie avec seulement quelques lignes de code. Parfois, ils ont vent de leur pouvoir et l’utilisent pour détruire un projet. La feuille de budget pour la version 1.0 était si bonne que la direction n’a pas hésité à approuver la version 2.0. Ensuite, le vendeur décide de nous presser en triplant ou quintuplant le prix.
Cet effet peut être ressenti même lorsque les fournisseurs ne le font pas exprès. Les niveaux gratuits peuvent rendre un projet très bon marché. Ensuite, lorsque la demande monte en flèche et que la deuxième version augmente la demande, les prix réels entrent en jeu.
Changement de la mer
En une année de pandémies et de manifestations, rien n’a changé plus vite que l’air du temps. Le projet a-t-il fait de la protection de la vie privée une caractéristique centrale? Whoop. La pandémie a rendu tout le monde intéressé par la recherche de contacts. Quelqu’un voulait-il se concentrer sur les voyages d’affaires? Whoop. L’industrie hôtelière s’est effondrée. Les projets logiciels plus importants qui peuvent prendre un an ou plus risquent d’être bouleversés par des événements cataclysmiques. Ce qui semblait être une idée merveilleuse au début peut sembler désespérément perdu et déconnecté quand il est temps de passer en direct.
Changements techniques
Ce ne sont pas seulement des changements dans le monde en général. Les changements de marée dans la communauté technologique peuvent avoir le même effet. NoSQL était autrefois une idée de génie qui nous libérerait du schéma relationnel. Ensuite, quelqu’un s’est rendu compte que les fichiers gonflaient parce que chaque enregistrement portait un schéma local. Une bonne équipe de développement agile peut changer lorsque les changements technologiques changent les attitudes des dirigeants et des clients. Mais même les équipes les plus agiles ne peuvent pas faire face à de grands changements qui aspirent tout l’air de leurs plans architecturaux. Le système a été construit en supposant que X était une excellente idée et soudainement X est de la saleté. Parfois, il est préférable de le faire exploser et de recommencer.
Trop d’ajouts
Certains projets logiciels démarrent bien et sont même livrés avec succès. Ensuite, quelqu’un ajoute une ou trois fonctionnalités supplémentaires, greffant un nouveau code à la version existante de manière à ce que le code continue de boiter. Les développeurs héroïques peuvent réussir cela plusieurs fois, surtout si l’architecte initial a bien planifié. Mais à un moment donné, la fondation s’effrite. Peut-être que la base de données ne peut pas gérer la charge. Peut-être qu’il y a trop de jointures nécessaires pour satisfaire les différentes requêtes. Un bon logiciel peut devenir trop gros, parfois grâce à de petites améliorations qui l’ont poussé à bout.
Postes d’objectifs mobiles
Les plans initiaux prévoyaient une base de données permettant de suivre les dépenses des clients pour aider aux plans marketing. Ensuite, un génie a ajouté une fonctionnalité qui utilise l’intelligence artificielle pour corréler les dépenses avec les prévisions météorologiques. Ou quelqu’un d’autre voulait que le logiciel enchérisse automatiquement pour les annonces des moteurs de recherche. Changer de destination peut bouleverser un projet.
Il est rare que les changements ruinent les choses par eux-mêmes. Mais de nouveaux objectifs peuvent révéler des faiblesses et déclencher des modes d’échec. Peut-être que l’équipe est maintenant trop petite pour mener à bien le projet. Peut-être que les fondements techniques sont extrêmement inefficaces pour la nouvelle approche. Il est difficile pour tout le monde d’anticiper les combinatoires agitées lorsque la décision est prise de changer les objectifs.