Créer et acheter d'excellents logiciels pour la fabrication de métaux

scanrail/iStock/Getty Images Plus

Les logiciels deviennent de plus en plus pertinents et essentiels pour les ateliers de fabrication modernes. Que vous développiez du code en interne ou recherchiez un outil tiers, il est important de comprendre ce que vous recherchez. Cela peut être difficile sans une compréhension approfondie de la façon dont les logiciels sont créés.

Healthcare.gov représente une étude de cas facilement accessible sur les risques liés à la conception de logiciels. Il a été lancé il y a 10 ans et a immédiatement atterri avec un bruit sourd. C'était si lent et si compliqué que seulement 1 % des personnes intéressées ont pu s'inscrire au cours de la première semaine. La conception Web n’a pas réussi à répondre aux bases absolues, avec des flux de travail médiocres et des interfaces utilisateur défaillantes. Pour couronner le tout, les prestataires d'assurance maladie ont reçu des informations inexactes de la part du site, ce qui a rendu difficile, voire impossible, le traitement correct des inscriptions.

Les tests de résistance qui auraient dû explorer le volume d’utilisateurs attendu se sont révélés totalement inadéquats. Un jour avant le lancement, il a été constaté que le site devenait trop lent avec seulement 1 100 utilisateurs simultanés. Le nombre d'utilisateurs attendu était de 50 000 à 60 000. Comme si cela ne suffisait pas, le nombre réel d'utilisateurs simultanés a grimpé à 250 000 au cours de la première semaine, soit plus de 200 fois le nombre d'utilisateurs que les tests de résistance préliminaires indiquaient que le site pouvait gérer. Rétrospectivement, on se demande pourquoi les tests de résistance ont été effectués. Leur échec évident n’a rien changé au calendrier de sortie.

Le projet n'a pas échoué faute de budget. Le coût initial était estimé à 93,7 millions de dollars, une somme faramineuse même si le projet ne dépassait pas le budget. Mais les estimations étaient tout à fait incorrectes. Avant l'achèvement, le coût total s'élevait à 1,7 milliard de dollars, un chiffre époustouflant et déchirant, soit près de 20 fois plus élevé que prévu.

Healthcare.gov fonctionne très bien en 2023, mais lors de son lancement, il s’agissait peut-être du fiasco logiciel le plus spectaculaire, le plus coûteux et le plus public de l’histoire. Même si une grande partie de la complexité entourant le déploiement de Healthcare.gov était inévitable, nous pouvons utiliser son déploiement bâclé pour explorer ce qui fait la réussite ou l'échec des projets logiciels. Ses échecs pourraient vous donner un aperçu de la manière dont vous pourriez créer votre propre équipe logicielle interne. Cela peut également donner un aperçu de ce qu’il faut rechercher lors de l’achat de logiciels tiers.

Dans un article précédent, j'ai expliqué comment Southwest Airlines s'est effondrée pendant les vacances de 2022. En un mot, la société s'appuyait sur un logiciel vieux de plusieurs décennies qui rendait extrêmement difficile la gestion des interruptions de planification. Les travailleurs ont compris le problème, mais les dirigeants de l’entreprise, isolés des difficultés opérationnelles quotidiennes, n’ont pas réussi pendant des décennies à investir dans de nouvelles infrastructures. Cet échec, combiné à une tempête hivernale et à une forte demande saisonnière, a provoqué l’arrêt de toute l’entreprise, bloquant des dizaines de milliers de personnes pendant la semaine de Noël. Southwest elle-même estime que la catastrophe coûtera à terme à l’entreprise près d’un milliard de dollars. Cette dépense extraordinaire aurait pu être évitée si les décideurs étaient suffisamment proches des problèmes opérationnels pour en comprendre l'urgence.

La leçon à en tirer est qu’un bon logiciel est développé par des équipes de proximité. Une bonne proximité implique deux choses : premièrement, que l’équipe logicielle soit intimement familiarisée avec la douleur qu’elle essaie de résoudre ; Deuxièmement, les développeurs sont proches des résultats produits par leurs logiciels. En d’autres termes, une équipe proche comprend la douleur et utilise ensuite son propre outil logiciel pour l’atténuer. Si le logiciel manque la cible, présente des problèmes ou est difficile à utiliser, les développeurs devraient être les premiers à le découvrir.

C’est un domaine dans lequel le projet Healthcare.gov a certainement échoué. Les développeurs ont peut-être compris les problèmes pour lesquels leur site Web a été conçu, mais l'entrepreneur principal opérait à partir du Canada, et non des États-Unis, le pays desservi par Healthcare.gov. Différents composants du système complet ont également été confiés à de nombreux sous-traitants, dont aucun n'aurait possédé l'application complète. Même si les développeurs avaient compris le problème que le logiciel était censé résoudre, l'expérience utilisateur de bout en bout aurait été fermement hors du contrôle de tout développeur de logiciel individuel.