Le nouveau triangle du projet informatique – Tristan Henry

Au cours de ma carrière, j’ai travaillé sur des dizaines de projets numériques dans plusieurs sociétés de conseil. Tous ces projets partent de zéro ou ajoutent de nouvelles fonctionnalités à une solution existante mais l’équation principale est la même: «une liste de X fonctionnalités doit être livrée pour $ Y dans Z mois».
La liste des fonctionnalités est indiquée par le client, puis l’équipe de vente / expert fournit le coût en fonction de l’effort et les gestionnaires de projet / ressources partagent le calendrier. Malheureusement, les contraintes de l’équation (portée, budget et calendrier) reposent sur des hypothèses précoces qui s’avèrent souvent être légèrement différentes ou totalement incorrectes. La révision de l’équation initiale nécessite que l’équipe révise la liste des fonctionnalités, le budget ou le calendrier. Ce remaniement est un dilemme cornaline où il n’y a de bonne réponse pour aucune des parties.
Dans les sections suivantes, je vais expliquer pourquoi le fait de se concentrer uniquement sur les contraintes initiales crée des tensions pour fournir de nouvelles fonctionnalités qui pourraient ne pas satisfaire l’objectif commercial et détériorer la solution actuellement en place. Je proposerai ensuite un nouvel ensemble d’indicateurs pour mieux gérer les problèmes de calendrier, suivre la valeur ajoutée et assurer la stabilité du projet.
Construire un projet nécessite de trouver le bon équilibre entre 3 contraintes:
Un Proof a Concept sacrifie la qualité pour obtenir un résultat rapide à un coût minimum. Si la sécurité et la stabilité sont au cœur d’un projet, la mise en œuvre nécessitera un temps et un coût importants.
Cependant, une société de conseil expérimentée doit fournir une qualité standard. UNE rapide et sale n’est pas concevable. Ainsi, les 3 contraintes suivantes sont disponibles:
Une fois que les bonnes contraintes sont établies pour un projet, la croyance principale est de supposer que la portée sera livrée à temps pour le coût budgété. Cependant, cette hypothèse est basée sur les faits suivants:
- La portée est complète et parfaitement comprise
Plus toutes les parties sont expérimentées, plus la portée est entièrement décrite et plus l’estimation des coûts est précise. Cependant, l’humanité a tendance à être trop optimiste et la durée est très souvent sous-estimée. A 2017 Enquêtes du PMI indique que 49% des projets informatiques sont en retard. Dans la même enquête, nous constatons que 31% des projets n’ont pas atteint l’objectif commercial prévu. En ce qui concerne le coût, l’enquête indique que 43% des projets informatiques dépassent leur budget initial.
Étant donné qu’un nombre important de projets créent des contraintes irréalistes, des options alternatives pour traiter les problèmes potentiels doivent être préparées, par ex. gérer le fait qu’un développement de fonctionnalité prend plus de temps que prévu. Avec trois contraintes, il est possible d’agir sur la portée, le calendrier ou le coût (si les ressources sont disponibles). Ce type de discussion peut prendre des âges et dégrader la dynamique du projet. Heureusement, il existe plusieurs options pour traiter ces problèmes plus efficacement.
Afin de traiter les problèmes plus efficacement, une contrainte peut être corrigée. Il aide le processus de prise de décision en offrant moins d’actions possibles. Voici quelques exemples:
- Une approche chronologique fixe permet de se concentrer sur le travail à faire avant la date limite critique. Si des travaux imprévus apparaissent, cela affectera la portée ou le coût (si des ressources supplémentaires sont disponibles)
Ces approches aident à gérer les problèmes en limitant les mesures disponibles pour réaliser le projet compte tenu des contraintes. Certains projets décident de corriger plusieurs contraintes telles que la portée et le coût. Cette approche extrême est vraiment difficile car elle pousse toute la pression vers cette seule contrainte. Dans tous les cas, réduire la complexité n’aide pas à réduire les tensions sur les projets. À la fin, la solution nécessitera de sacrifier une partie de la portée, d’augmenter le budget, de livrer au-delà du calendrier ou d’une combinaison de ceux-ci.
De nos jours sur les projets informatiques, les méthodologies agiles sont l’approche dominante (Enquêtes du PMI). L’idée principale est de livrer plus souvent pour s’assurer que la portée et ses valeurs ajoutées sont alignées avec l’objectif commercial. Généralement avec une équipe agile, le temps et l’effort / équipe sont fixes pour chaque itération, mais la portée variera en fonction de l’exactitude des estimations. Une cérémonie agile appelée rétrospective a lieu à la fin de chaque sprint pour passer en revue ce qui s’est bien passé, quels problèmes ont été rencontrés et comment le sprint peut être amélioré pour les prochaines itérations.
Les approches agiles réduisent la complexité en fixant la contrainte de temps et de coût pour chaque sprint. Cela signifie que si des problèmes surviennent, cela réduira automatiquement la portée. Si les rétrospectives sont bien exécutées, cela garantit que toute la portée sera livrée à la fin du sprint. Cependant, les approches agiles peuvent ne pas toujours prendre en compte la durabilité du système et le fait que chaque nouveau sprint rend le produit meilleur que le précédent.
Réduire la complexité en fixant des contraintes ou en devenant agile est une aide pour gérer les problèmes mais il permet de gérer:
- Gestion des risques
En effet, en insistant sur une ou deux contraintes, les équipes finissent toujours par avoir la même conversation: « Pourquoi avons-nous supprimé cette fonctionnalité? », « Pourquoi devons-nous repousser la chronologie? » et « Pourquoi avons-nous ce coût supplémentaire? ». Ces questions sont de véritables demandes mais elles sont basées sur la première estimation initiale de l’effort et du calendrier qui n’est qu’une première compréhension du projet, pas une règle d’or à suivre pour apporter une valeur ajoutée.
Afin de déplacer la conversation et de se concentrer sur les indicateurs progressifs, il est possible d’utiliser un nouveau triangle de projet. Il contient 3 aspects principaux:
- Évaluer l’impact sur l’entreprise
Valeur ajoutée unitaire
L’élément le plus important de tous les projets est de générer de la valeur. Il existe de nombreuses façons de promouvoir la valeur ajoutée pour le client et certaines sont difficiles à mesurer, comme la réputation de la marque. Ici, nous nous concentrons sur les coûts mesurables composés par:
- Le coût initial
Un projet peut souvent faire face à la situation suivante: une nouvelle fonctionnalité a été publiée après la date limite et au-dessus du coût prévu. Cette situation est frustrante pour toutes les parties mais le cycle de vie d’une fonctionnalité ne s’arrête pas après la sortie initiale. Nous devons évaluer la situation dans son ensemble en comprenant si le temps et les coûts dépensés en valent la peine à long terme. En d’autres termes, la phrase devrait passer de: «Nous avons livré une fonctionnalité avec un mois de retard et cela a coûté 150% du coût initial» à «Nous avons livré une fonctionnalité avec un mois de retard, la fonctionnalité est utilisée par 10% des utilisateurs et les revenus supplémentaires générés couvriront les coûts de développement dans les 6 mois ».
Toutes les fonctionnalités ne peuvent pas se traduire directement en revenus directs, mais il est possible d’isoler leurs coûts.
Outil de développement logiciel et déploiement continu
Pour évaluer le coût de développement, le projet doit pouvoir suivre avec précision le temps passé sur chaque fonctionnalité. Le temps réel passé peut différer de l’estimation initiale, mais grâce à la plupart des outils de développement logiciel, il est possible de suivre avec précision et indépendance le temps et le coût de chaque fonctionnalité.
Il est important de comprendre le coût de chaque fonctionnalité pour évaluer sa valeur commerciale. Il y a deux erreurs à éviter. La première fusionne le temps passé sur toutes les fonctionnalités pendant la phase de développement de l’itération. En effet, dans certains cas, le temps global consacré à une itération de développement est très proche des premières estimations. En réalité, cela est souvent dû à un équilibre dangereux entre les caractéristiques qui ont été sous-estimées et celles qui ont été surestimées. Le deuxième problème vient de la phase de test et de déploiement. Ces activités regroupent souvent plusieurs fonctionnalités, ce qui rend la tâche de bout en bout plus difficile à comprendre.
Il est obligatoire d’être aussi précis que possible pour obtenir le véritable coût de développement. Les fonctionnalités doivent être aussi indépendantes que possible de leur développement jusqu’à leur sortie. Les approches de livraison / déploiement continu aident à être granulaires en suivant et en traitant chaque fonctionnalité indépendamment.
FinOps
Lorsque le coût de développement initial est connu, il est important de comprendre l’impact de l’exécution de cette nouvelle fonctionnalité. Certaines fonctionnalités pourraient être peu coûteuses à développer mais nécessiteront une infrastructure ou des coûts d’exploitation importants.
FinOps est une contraction des mots Finance et Opérations. L’objectif principal de cette approche est de mieux gérer les coûts de fonctionnement (généralement dans le cloud). L’architecture logicielle héritée est souvent monolithique, ce qui signifie qu’un seul grand système gère toutes les opérations. Dans ce cas, il est difficile d’évaluer le coût de déclenchement d’une fonctionnalité particulière. Cependant, grâce à de nouvelles architectures basées sur des microservices, le coût de fonctionnement des services internes peut être plus granulaire. En dehors des services personnalisés, un service externe peut être facturé en fonction du nombre d’appels API. Les applications basées sur le cloud utilisant des microservices peuvent également adopter cette approche dans deux cas distincts:
- Des microservices standard où il est possible d’estimer le coût de chaque service
Un exemple sera le suivant: sur un site e-commerce, un nouveau mode de paiement est implémenté. Le mode de paiement externe utilisé coûte 1 $ par transaction et une fonction de microservice sans serveur dédiée est créée pour le gérer.
À la fin du mois, le coût d’exécution de cette nouvelle fonctionnalité est le coût externe du fournisseur 1 fois X transactions X + le coût cloud d’exécuter X fois le microservice.
Test A / B
Une fois que le coût du développement initial et le coût de fonctionnement sont connus, il est possible de comprendre si cette nouvelle fonctionnalité est utilisée, attire plus de personnes ou génère plus de revenus. Pour ce faire, les tests A / B doivent être exécutés en proposant aux clients les deux versions de la solution: une version sans la nouvelle fonctionnalité et une version avec. Puis, après une période de plusieurs jours à plusieurs semaines, l’équipe a rassemblé suffisamment d’informations pour comprendre la valeur de la nouvelle fonctionnalité.
Les tests A / B sont un moyen simple de recueillir des commentaires sur chaque fonctionnalité. Les outils d’analyse indiquent si la fonctionnalité est utilisée et quelle est la valeur / le revenu supplémentaire potentiel. Le suivi des comportements est un moyen supplémentaire de comprendre en détail le changement apporté par une fonctionnalité particulière du parcours client.
Des sites Web comme Booking.com exécutent 1 000 expériences en même temps (Article HBR). Cette approche permet de tester chaque nouvelle idée (pas seulement l’opinion de HIPPO – la personne la mieux payée) et d’obtenir des données tangibles indiquant les performances de chaque version.
5 pourquoi
Au moment de l’hypothèse initiale, l’effort et le coût pour développer la portée souhaitée ont été estimés. En fonction des ressources disponibles, il est possible de définir un calendrier. Cette première chronologie est généralement valable pour une courte période car de nombreux facteurs internes ou externes obligent rapidement le projet à s’adapter, ce qui se traduit souvent par des retards.
Lorsqu’il s’agit d’indiquer les raisons des retards, les réponses sont souvent compréhensibles mais le questionnement n’est pas suffisamment détaillé pour comprendre les causes profondes et prendre les mesures appropriées.
Par exemple:
La publication a été retardée en raison d’un bogue critique dans une fonctionnalité.
– « Pourquoi la libération a-t-elle été retardée de 2 jours? »
– «La sortie a été retardée car des problèmes inattendus ont été soulevés pendant la phase de test».
Les problèmes peuvent se produire une fois, mais si le même problème se reproduit dans un projet, cela signifie qu’aucune action appropriée n’a été prise pour le gérer. Pour configurer ces actions, il est obligatoire de comprendre en détail la cause première du problème.
La méthode des 5 Whys a été développée par Sakichi Toyoda, l’inventeur et industriel japonais qui a créé Toyota et lancé la réflexion autour de la méthodologie Lean. L’approche des 5 pourquoi aide à mieux comprendre le problème et à obtenir des solutions concrètes en demandant «pourquoi?» 5 fois. Si nous prenons l’exemple précédent, les 5 pourquoi auraient pu mettre en évidence ce qui suit:
La publication a été retardée en raison d’un bogue critique dans une fonctionnalité.
– « Pourquoi la libération a-t-elle été retardée de 2 jours? »
– «La sortie a été retardée car des problèmes inattendus ont été soulevés pendant la phase de test».
– « Pourquoi ce bug a-t-il été signalé si tard pendant la phase de test? »
– « Le bug n’a pas été soulevé lors du développement initial »
– « Pourquoi ce bug a-t-il été autorisé à passer à la phase de test? »
– «Le développeur est nouveau sur le projet et n’a pas mis en place tous les tests unitaires».
– «Pourquoi le développeur n’était-il pas au courant de la politique visant à couvrir toutes les nouvelles fonctionnalités code par test unitaire?»
– «Le développeur a été présenté à l’équipe sans une bonne intégration».
Grâce à cette approche, nous savons qu’avec une bonne intégration, le bogue aurait pu être révélé par un test unitaire et corrigé avant de passer à la phase de test.
Plan A
Le plan d’atténuation est la liste des actions qui empêchent un risque de se produire, c’est le plan A. Comme nous l’avons vu précédemment, un projet a 3 composantes principales: temps, coût et qualité / portée. Pour éviter qu’un composant ne dévie, il est obligatoire de répertorier les risques potentiels et leurs actions associées. L’équipe doit alors planifier à l’avance l’exécution de ces actions.
Exemple:
- Risque: les nouveaux développeurs mal intégrés pourraient affecter la qualité / le calendrier d’un projet
Si un problème est soulevé et examiné par les 5 pourquoi, il doit faire partie du plan d’atténuation ou du plan d’urgence décrit dans la section suivante.
Plan B
Tous les risques ne peuvent pas être traités par un plan d’atténuation et des actions préventives. Si c’est le cas, il est important de s’assurer que l’équipe sait quoi faire quand cela se produit. Le plan d’urgence décrit les actions pour remédier au risque après qu’il se soit produit, c’est le plan B. Les actions doivent être préparées mais pas exécutées.
Exemple:
- Risque: l’arrêt du serveur entraînant la non-disponibilité du service
Suivi des transactions et des performances
Un projet est composé de plusieurs couches utilisées par une multitude de cas d’utilisation. L’ajout de nouvelles fonctionnalités est un élément essentiel de l’entreprise, car cela permet de fournir plus de valeur au client et potentiellement d’obtenir plus de revenus. Cependant, l’ajout de complexité peut détériorer les performances globales et l’expérience utilisateur à long terme. Walmart a découvert que chaque amélioration de 100 ms de la vitesse de transaction entraînait une amélioration de 1% des revenus (Nouvel article Relic). Au contraire, une réduction de 1 seconde de la vitesse de transaction pourrait avoir un impact direct sur le parcours client et les revenus du site.
Afin de gérer l’impact sur les performances, chaque nouvelle fonctionnalité doit être prise en compte dans le parcours client global. Imaginez une nouvelle fonctionnalité qui ajouterait 100 ms de temps de chargement. Cette fonctionnalité n’est utilisée que par 10% des utilisateurs mais fait partie du parcours client principal. Cela signifie que 90% des clients auront une dégradation de leur parcours sans valeur ajoutée.
Grâce à un cycle d’itération plus court et à une livraison / déploiement continu, de nouvelles fonctionnalités peuvent être livrées avec une fréquence plus élevée (jusqu’à plusieurs fois par jour). Même si chaque caractéristique individuelle a un impact insignifiant sur les performances, la solution peut souffrir d’une dégradation de la vitesse à long terme.
Afin de surveiller efficacement les performances et de comprendre l’impact sur le parcours client, il est important de pouvoir:
- Atteindre une disponibilité proche de 100%
Une solution pourrait être rapide et précise, mais elle est inutile si personne ne peut l’atteindre
Lorsqu’une baisse significative des performances est constatée, une action doit être initiée pour gérer la situation. Il pourrait s’agir de déplacer la fonctionnalité vers un parcours utilisateur alternatif ou de réorganiser la solution pour la rendre plus efficace.
Mesurer et maintenir la qualité
Il existe plusieurs façons d’évaluer la qualité d’un projet, par ex. assurer une formation, une documentation, des inspections, etc. appropriées. Ici, mettons l’accent sur les tests et en particulier sur les étapes suivantes:
- Tests unitaires
Test du code spécifique lié à la fonctionnalité
Les tests unitaires automatisés doivent faire partie de chaque développement de fonctionnalités car ils garantissent que le code spécifique fonctionne comme requis. Tous les tests peuvent être exécutés à la demande et avant de passer à la phase suivante en s’assurant que le nouveau morceau de code ne crée aucune régression sur les fonctionnalités précédentes. Il est également possible d’analyser la couverture du code de test unitaire pour vous assurer que toute la logique de la solution est correctement testée.
Une fois le test unitaire couvert, les composants automatisés, l’intégration automatisée et les tests API automatisés peuvent être effectués. Ces tests permettent de s’assurer que tout fonctionne bien ensemble. Les tests d’intégration peuvent être effectués dans différents environnements, par ex. bac à sable, pré-production.
Enfin, les tests d’acceptation peuvent être traités via des tests GUI (Graphical User Interface) automatisés. Ces tests reproduisent le comportement des utilisateurs lors de la navigation dans la solution. Il est même possible de configurer un robot pour exécuter des tests GUI en production afin d’ajouter une nouvelle surveillance des métriques et des alertes.
Grâce à l’automatisation de l’unité, à l’intégration et aux tests d’acceptation, il est possible d’évaluer la qualité de la solution dans le temps et d’éviter que les tests de régression n’apparaissent tardivement dans le processus de test manuel.
Être évolutif prêt
La surveillance de la solution et de sa qualité est obligatoire pour assurer à tout moment le meilleur service aux clients. Cependant, il est également important de se préparer à une époque où les solutions pourraient attirer plus de clients. Pour ce faire, la solution doit être prête à évoluer.
La mise à l’échelle horizontale permet d’augmenter la capacité des services en ajoutant de nouveaux travailleurs. Cette approche est disponible sur la plupart des architectures non monolithiques telles que les microservices. L’analogie sera la suivante: pour absorber les clients supplémentaires attirés par la vente du Black Friday d’un block and mortar shop, des caissiers supplémentaires sont déployés. Cette approche est privilégiée car elle permet d’adapter dynamiquement le nombre de travailleurs nécessaires et elle permet de faire face à une éventuelle indisponibilité des travailleurs. La mise à l’échelle horizontale fonctionne bien avec les solutions de clusters de conteneurs gérés tels que Kubernetes. Il est également inclus sous le capot de la solution inutile.
Si une application est basée sur une architecture monolithique, il y a un fort changement que la mise à l’échelle horizontale ne peut pas être activée. Si tel est le cas, il est possible d’adopter une approche plus restrictive appelée mise à l’échelle verticale. Si nous revenons à notre événement Black Friday en brique et mortier, afin de traiter avec plus de clients, le magasin doit augmenter un caissier unique pour s’assurer qu’il peut gérer plus de clients par minute, par exemple. recruter le caissier le plus rapide de l’industrie. Cette approche ne peut pas être effectuée de manière dynamique et elle crée un point de défaillance unique.
La plupart des architectures sont désormais hybrides où le frontal peut évoluer horizontalement mais le back-end doit rester sur la même instance et ne peut évoluer que verticalement. Les technologies de mise en cache peuvent également aider à absorber la majeure partie du trafic de navigation.
Une fois la stratégie de dimensionnement définie, il est possible de tester plusieurs fois la charge du trafic habituel et, si besoin, d’adapter la solution et de s’assurer que tout fonctionne dans ces conditions.
Le temps, le coût et la portée sont essentiels pour démarrer un projet mais ces indicateurs ne contribuent pas à générer de la valeur ajoutée. En se concentrant sur la mesure de l’impact commercial, en maximisant la précision de la chronologie à l’aide de plans proactifs et en assurant la stabilité technique de la solution, toute l’équipe sera en ligne pour faire fonctionner le projet à long terme.