Table des matières
L’histoire que nous avons tous entendue
La première réunion
Au début du projet, le grand patron entre dans la pièce et dit à tout le monde que le projet doit être terminé pour la fin de l’année fiscale, dans six mois.
Le moral de l’équipe est élevé. Pourquoi ne le serait-il pas ? Nous disposons encore de tout notre budget. L’équipe que nous avons constituée semble enthousiaste et compétente. Tout se passera bien.
L’analyse
Le projet est ensuite envoyé aux analystes. La phase d’analyse commence et devrait durer deux mois. Pourquoi deux mois ? Parce qu’il y a trois phases (analyse, conception, mise en œuvre) et que six mois divisés par trois phases équivalent à deux mois.
Deux mois plus tard, la phase d’analyse est terminée dans les délais. Les analystes ont fait leur travail et ont élaboré de jolis diagrammes et graphiques qui ont donné à tous les membres de l’équipe de projet l’impression d’en savoir beaucoup plus sur le projet. Tout le monde est convaincu que les choses se passent bien.
La conception
Le projet est ensuite envoyé aux concepteurs. La phase de conception commence et devrait durer encore deux mois.
Au cours de ces deux mois, certaines exigences sont modifiées. De nouvelles fonctionnalités sont ajoutées, d’anciennes sont supprimées et certaines sont modifiées. Idéalement, nous devrions renvoyer ces fonctionnalités aux analystes pour qu’ils les réanalysent, mais qui a le temps de le faire ? Nous avons un délai à respecter, alors nos talentueux concepteurs intègrent directement ces changements dans leur conception.
Deux mois plus tard, la phase de conception est terminée dans les délais. Les concepteurs ont fait leur travail et ont créé des “wireframes”, des maquettes et parfois même des prototypes agréables à regarder. Tous les membres de l’équipe du projet sont encore plus convaincus que les choses se passent bien.
Qu’avons-nous dépensé et qu’avons-nous obtenu jusqu’à présent ?
Voyons où en est le projet. En ce qui concerne le calendrier, nous en sommes aux deux tiers. En ce qui concerne les coûts, nous sommes probablement à 1/3 ou 1/2 du budget. D’accord, mais qu’en est-il de la valeur ajoutée ?
Jusqu’à présent, nous n’avons rien. À moins que l’application ne soit entre les mains de l’utilisateur, un projet logiciel ne génère aucune valeur.
Mais tous ces diagrammes et maquettes doivent avoir un sens. Nous sommes convaincus qu’avec ces analyses et ces livrables de conception, la phase de mise en œuvre se déroulera bien. Nous ne faisons donc que suralimenter le projet et nous obtiendrons notre retour une fois la mise en œuvre terminée, n’est-ce pas ? Il faut espérer.
La mise en œuvre
Poursuivons. Le projet est envoyé aux développeurs pour être mis en œuvre. La phase de mise en œuvre commence et devrait durer encore deux mois, car c’est tout ce qu’il nous reste.
Au cours du mois et demi qui suit, d’autres exigences changent. De nouvelles fonctionnalités sont ajoutées, d’anciennes sont supprimées et certaines sont modifiées. Idéalement, nous devrions renvoyer ces fonctionnalités aux analystes et aux concepteurs pour qu’ils les réanalysent et les redessinent, mais qui a le temps de le faire ? Nous approchons rapidement de la date limite.
Contrairement aux deux phases précédentes, qui n’ont pas de critères d’achèvement définis, il n’y a aucune ambiguïté quant à la fin de la phase de mise en œuvre. Nous ne pouvons pas prétendre qu’elle l’est simplement parce que le temps est écoulé.
Nos talentueux développeurs font donc de leur mieux pour intégrer ces changements directement dans le code.
Deux semaines avant la date limite, nous regardons ce que nous avons construit et nous nous rendons compte que cela n’a rien à voir avec les jolis diagrammes et wireframes. De plus, le travail restant ne semble pas pouvoir être réalisé en deux semaines. Quelqu’un sonne enfin la cloche et le grand patron, pour la première fois depuis le début du projet, apprend que nous sommes confrontés à des difficultés.
Il se dit : « Vous n’auriez pas pu me le dire plus tôt ? Pourquoi vous ai-je payé pour faire toutes ces analyses et conceptions ? Et pourquoi me dites-vous cela alors que nous sommes à deux semaines de la date limite et que nous avons presque dépassé le budget ? »
L’enfer
La suite est brutale.
Les parties prenantes sont en colère, la pression est forte, les gens font des heures supplémentaires et ne parviennent toujours pas à respecter le délai initial.
De nouveaux membres sont introduits dans l’équipe, dans l’espoir qu’un plus grand nombre de personnes permettra d’accomplir plus de travail plus rapidement. Cependant, cela ne fait que diminuer la productivité, car les nouveaux membres ne savent rien du projet et mobilisent les ressources seniors à des fins de formation.
Plusieurs nouvelles dates d’achèvement du projet sont rejetées. On entend dire : « Nous ferons mieux la semaine prochaine ». « Nous pensons pouvoir terminer le projet dans deux semaines ». « Nous espérons que nos nouveaux membres rattraperont bientôt leur retard, ce qui remettra les choses sur les rails. » Remettre les choses sur les rails de quoi ? À ce stade, dix mois se sont écoulés depuis le début du projet.
Lorsque l’application est enfin déployée, elle fait en quelque sorte ce à quoi elle était prévu de faire. Tout le monde est démotivé. On se pointe du doigt, mais plus personne ne s’en soucie.
Qu’est-ce qui a mal tourné ?
Tous les projets de logiciels ne se déroulent peut-être pas comme l’histoire ci-dessus, mais il y en a beaucoup trop qui s’en approchent. Plusieurs choses ont mal tourné dans l’histoire décrite, mais dans cet article, je veux me concentrer sur le début du projet. Voyons comment nous démarrons un projet.
Avant tout, je tiens à souligner qu’il n’y a rien de mal à consacrer des efforts à l’analyse et à la conception ; ces deux activités sont nécessaires. Le problème réside dans le calendrier de ces activités et dans le niveau de détail auquel elles s’engagent avant le début de la mise en œuvre.
Au début d’un projet, de nombreuses informations doivent être précisées. Comme il s’agit d’un stade précoce, la plupart des informations recueillies ne sont pas concrètes : « Nous pensons que faire ceci améliorera notre efficacité », « Nous pensons que former les utilisateurs pour qu’ils prennent le contrôle de l’application », « Nous pensons que faire ceci améliorera notre efficacité ». « Nous pensons que la formation des utilisateurs à cette nouvelle méthode de travail ne posera pas de problème. « Nous pensons que la plupart du temps, le flux de travail/la conception proposé(e) devrait fonctionner. Les exceptions devraient être rares…. »
Il y a beaucoup d’informations hypothétiques ici. Ce genre d’informations vagues est capturé et incorporé dans des artefacts d’apparence sérieuse, tels que des diagrammes, des graphiques, des maquettes et des images fil de fer. Tout d’un coup, ils ont l’air concrets, mais ils ne le sont pas.
Une fois que l’équipe chargée de la mise en œuvre commence à construire l’application sur la base de ces informations sérieuses mais non concrètes, nous les mettons véritablement à l’épreuve, car l’utilisateur nous dira si les fonctionnalités qui en découlent fonctionnent réellement. Certaines fonctionneront. La plupart ne le feront pas.
Le pire, c’est que la plupart de ces produits livrables contenant des informations non concrètes ne seront pas mis à jour par la suite, faute de temps ou de ressources. Non seulement ils ne contribuent pas au projet, mais ils deviennent parfois des informations erronées et conduisent le projet dans une mauvaise direction.
N’oubliez pas que tous les produits livrables qui ne contribuent pas au logiciel fonctionnel final n’ont aucune valeur.
Ce qui s’est passé, c’est que nous avons dépensé beaucoup d’argent et de temps au départ, mais que nous avons créé des produits livrables qui ne contribuent pas beaucoup au logiciel final (c’est-à-dire du gaspillage). Nous avons investi davantage et obtenu moins en retour, ce qui, en fin de compte, génère un RSI (retour sur investissement) plus faible.
La meilleure façon
Au lieu de dépenser la moitié du budget de votre projet avant de voir une seule fonction opérationnelle et de produire un gaspillage important, vous pouvez dépenser 10 % pour lancer le projet et obtenir davantage en retour.
Comment, me direz-vous ?
Commencez par produire moins de gaspillage. Ne créez que des produits livrables qui seront utiles à l’avenir en ne vous engageant que sur certaines informations à ce stade du projet.
Que faire alors ?
Établir le plan de projet initial
Il ne s’agit pas d’un plan de projet détaillé dont l’élaboration prendrait plusieurs semaines. Il s’agit d’une courte liste de fonctionnalités appelées « récits« , qui sont estimées, classées par ordre de priorité (en fonction de leur valeur commerciale) et dont la mise en œuvre est provisoirement prévue pour les prochaines semaines (dans certains cas).
C’est tout ce dont nous pouvons être certains à ce stade du projet, et c’est donc tout ce que nous produisons et nous nous engageons à faire.
Aussi décevant qu’il puisse paraître, ce plan initial fait de récits prépare le projet à la réussite. Les récits eux-mêmes sont des représentations tangibles de votre projet. Vous pouvez en ajouter de nouveaux, en supprimer d’anciens ou les déplacer vers le haut ou vers le bas dans l’ordre des priorités. Le processus de rédaction, d’estimation, de planification et de conception des récits ne s’arrête jamais. En suivant ce processus, vous disposerez toujours d’un plan de projet à jour, basé sur les informations dont vous êtes certain à ce moment-là.
Comme les récits sont estimés (et continueront à être réestimés), de nombreuses données sont produites pour la gestion du projet :
- En additionnant toutes les estimations des récits restants, tout le monde (y compris le grand patron) peut savoir combien de travail il reste dans votre projet (portée restante).
- En mesurant les estimations des récits terminés chaque semaine, tout le monde peut savoir à quelle vitesse nous progressons (vélocité).
- Et avec les mathématiques de l’école élémentaire, vous obtenez le temps d’achèvement prévu si vous utilisez la portée restante divisée par la vélocité.
L’avantage de disposer de ces données est que vous n’avez pas une seule occasion de vous faire dire que vous êtes dans la merde. Vous avez des occasions chaque semaine, ce qui vous permet de gérer votre projet, d’en ajuster la portée et de gérer les résultats et les attentes.
Préparer le projet sur le plan logistique
Il n’y a rien de pire que d’être tout à fait prêt pour la mise en œuvre et de se rendre compte que certains problèmes doivent être réglés par le service informatique dans plusieurs semaines.
Par conséquent, au début du projet, nous devrions obtenir tout ce dont nous avons besoin sur le plan logistique pour le projet. Cela comprend, sans s’y limiter, les éléments suivants:
- Un environnement de développement et de test pour le logiciel
- Un répertoire de code
- Un environnement de gestion des requis et des tâches
- Un répertoire de documents
- Des plans de communication
- La clarification des responsabilités
- Tous les types d’accès
- Et bien d’autres choses
Créer un concept initial provisoire
La conception produite à ce stade doit être basée sur la liste des récits. Les récits doivent fournir des orientations pour la mise en œuvre à venir, mais ne doivent pas être trop détaillés pour pouvoir être modifiées et adaptées aux besoins les plus récents.
Voici quelques-uns des produits livrables que nous avons l’habitude de produire au début d’un projet :
- Certains diagrammes illustrent le flux de travail et le flux de données de haut niveau souhaités
- Des décisions architecturales de haut niveau, telles que la manière d’aborder certaines intégrations et le choix de la pile technologique.
- Une ou deux maquettes pour donner le ton de l’aspect général du système.
- et parfois, lorsqu’il s’agit de projets particulièrement difficiles, des preuves de concept.
Tous ces livrables sont soit d’un niveau très élevé, de sorte qu’il est facile de les tenir à jour, soit destinés à être jetés (comme une preuve de concept).
Effets sur le retour sur investissement
Il y a trois raisons pour lesquelles la deuxième méthode augmente le retour sur investissement.
Premièrement, un dollar aujourd’hui vaut plus d’argent qu’un dollar demain. En passant moins de temps avant un projet à créer des plans et des conceptions détaillés, nous pouvons commencer la mise en œuvre plus tôt. N’oubliez pas que si l’application n’est pas entre les mains de l’utilisateur, un projet logiciel ne génère aucune valeur/rendement. Plus tôt nous commencerons la mise en œuvre, plus tôt certaines fonctionnalités de l’application pourront être envoyées aux utilisateurs, et plus tôt vous commencerez à obtenir un retour sur votre investissement.
Deuxièmement, le fait de mettre l’application à la disposition de l’utilisateur plus rapidement permet également d’obtenir une meilleure conception générale, ce qui se traduit par un rendement plus élevé. Transmettre l’application à l’utilisateur et recueillir ses commentaires est le moyen le plus efficace de transformer des informations non éprouvées en informations concrètes. C’est en s’appuyant sur des informations concrètes que l’on obtient le meilleur résultat possible pour un projet. Et par définition, le meilleur résultat possible, qui est presque certainement différent de ce que vous pensiez obtenir au départ, reste le meilleur résultat possible.
Enfin, la réduction du gaspillage augmente le retour sur investissement. En ne s’engageant que sur des informations concrètes, nous canalisons nos efforts sur la création d’applications fonctionnelles plutôt que sur la création d’une documentation ou d’un design agréable à l’œil.
Conclusion
En ne s’engageant que sur des informations concrètes et en investissant moins au début de votre projet dans la production de gaspillage, vous vous donnez de bien meilleures chances de réussite. Cela semble trop beau pour être vrai ? Alors contactez-nous et laissez-nous vous montrer comment faire.