Comment réussir le démarrage de son projet IT ?

Les raisons de l’échec d’un projet IT peuvent être nombreuses : des objectifs ou des jalons peu ou mal définis, des KPI non-accessibles en temps réel, un budget insuffisant… La plupart de ces raisons sont constatées en post-mortem du projet. Mais certains projets sont voués à l’échec dès leur démarrage.

En effet, deux prérequis manquent trop souvent au cours des premières étapes de la mise en place d’un projet IT :

• Une vision centrée sur l’utilisateur et ses besoins ;
• Un partage de la connaissance et de l’expertise métier.

Lorsque les parties prenantes d’un projet IT ne collaborent pas et ne répondent pas aux besoins de l’utilisateur final, la probabilité pour que le projet échoue est énorme.

C’est pourquoi nous vous proposons aujourd’hui la recette pour bien réussir le démarrage de votre projet IT.

Prérequis pour bien démarrer un projet IT

Les participants observent trop souvent l’échec de leurs projets IT. C’est pourquoi nous partageons aujourd’hui quelques conseils à appliquer en amont du lancement de votre projet pour éviter qu’il échoue.

Un UX/UI centré sur l’utilisateur

L’utilisateur doit rester au cœur du projet IT. Malheureusement, il n’est pas rare que l’équipe se focalise sur le design de l’interface (User Interface), en privilégiant l’esthétique à l’utilité. L’UX (User Experience) est alors reléguée au second plan. Pire, l’interface est souvent développée pour coller aux besoins du métier, sans prendre en compte ceux de l’utilisateur final. Et le constat est sans appel : l’échec est assuré.

Éviter le sprint zéro et le « super Architecte »

En Agilité, la mise en place d’un « sprint zéro » fait débat. Certains préconisent d’avoir recours à cette étape préalable au cours de laquelle l’architecte définit l’architecture logicielle du projet. L’équipe de développement sera alors amenée à respecter les règles fixées et l’architecture mise en place. La conséquence est inévitable : dans les faits, l’architecture ainsi définie reste figée et peu modifiée car difficile à remettre en question.

Prévoir la présence d’un expert-métier

Détenteur d’un savoir-faire technique, l’expert-métier est un atout indispensable, sous réserve de s’assurer de sa disponibilité au cours du projet. Sa maitrise du contexte et des enjeux, et sa connaissance métier proche de l’équipe de projet, en augmentent les chances de succès.

En parallèle, il est possible de mettre à la disposition des équipes un Product Owner Proxy (ou « Proxy PO »). Certains pensent même que le Proxy PO pourrait compenser l’absence de l’expert-métier. Toutefois, la présence de deux interlocuteurs augmente les risques de désynchronisation entre leurs visions du développement.

Dès lors, l’équipe de développement produira le code sur la base d’une compréhension subjective du problème et du métier en général.

Notons également que les développeurs doivent déléguer les tests à l’expert-métier ou au Proxy PO. Ainsi, ils repoussent la boucle de feedback (également appelée rétroaction) sur le code produit, qui sera rarement testé. Ils se concentreront alors sur la production des features en quantité et en continu, sans se soucier ni remettre en cause le design ou la qualité de la production.

Avoir une compréhension commune du métier

Le code déployé en production est le fruit de la compréhension du métier et de l’espace-problème par les développeurs. Si cette compréhension est erronée ou diffère selon les intervenants du projet, elle risque de ne pas coller aux exigences du métier et du produit déployé.

Une compréhension subjective du métier peut alors nuire à la réussite du projet IT. En outre, la connaissance du métier doit être commune et doit porter en elle une vision partagée de l’espace-problème. Si chaque intervenant porte une connaissance individuelle et différente, elle sera éparpillée voire perdue. Ainsi, ses effets et ses conséquences se verront dans le code et l’état du produit.

Ne pas avoir une compréhension commune et une vision partagée du métier propulse l’échec du projet dès son démarrage.

Deux workshops pour augmenter les chances de succès d’un projet

Afin d’augmenter les chances de réussite, certains mettent en place des ateliers lors du démarrage d’un projet. Il en existe plusieurs types, dont voici les deux plus connus :

• Le Design Sprint
• L’Event Storming / Example mapping

Workshop Design Sprint

Le Design Thinking est une méthode de gestion de l’innovation centrée sur l’humain. Elle permet d’identifier une problématique, de trouver l’idée qui permettrait d’y répondre et de concevoir la forme de la solution.

Basé sur le Design Thinking, le Design Sprint est un process qui permet de le mettre en place d’une manière efficace dans des délais très courts.

Le but, à travers cet atelier, est de réussir une expérience utilisateur. Les participants commencent par comprendre les problèmes des utilisateurs et leurs besoins vis-à-vis de la solution souhaitée. Une fois les informations nécessaires collectées, l’équipe échange des idées et sélectionne la meilleure afin de la prototyper.

Les acteurs de cette approche arrivent ainsi à produire une solution fiable et agréable pour l’utilisateur.

Mettre en place un Design Sprint est donc une bonne initiative, dans la mesure où il permet de répondre à certaines problématiques destinées à l’utilisateur final. Toutefois, en se focalisant sur les besoins des utilisateurs finaux, cette approche montre ses limites car elle ne rend possible ni la découverte ni le partage de l’expertise métier. Ce flou de connaissance risque d’entrainer l’échec du projet.

Worshop Event Storming / Example Mapping

L’Event Storming est un format de workshop qui permet l’exploration d’un domaine métier tout en favorisant le partage d’une vision commune de cette connaissance.

Basé sur des règles et des cas d’utilisation, l’Example Mapping est un atelier dont l’objet est d’écrire les use cases des produits développés. Il favorise la collaboration entre les équipes et permet la compréhension des règles métiers en se basant sur des exemples concrets.

Mixer ces deux ateliers permet à la fois d’avoir une vision globale et partagée du système, et de clarifier/confirmer les critères d’acceptation des use cases. L’ensemble des experts métier se réunissent avec les autres participants et intervenants sur le projet afin de partager leurs connaissances et leurs expertises.

Le but est de comprendre le process métier et d’avoir une vision commune et partagée du métier. A la fin de ce workshop, l’équipe de développement est en mesure de définir les contextes bornés du système à développer, ses agrégats et les règles métier nécessaires à l’implémentation des use cases.

La nécessaire collaboration de toutes les parties prenantes

L’expérience nous montre que l’une des clefs de la réussite d’un projet est d’inciter les développeurs à collaborer avec toutes les parties prenantes, de manière à construire ensemble un projet de qualité. Une collaboration qui passe également par un partage des connaissances des experts-métiers tout en répondant aux besoins de l’utilisateur.
Afin d’assurer cette collaboration, nous préconisons d’associer les deux workshops présentés ci-dessus. Rassembler ces deux ateliers permettra à la fois :

• De réunir tous les intervenants sur le projet ;
• D’avoir une approche heuristique qui englobe toutes les phases du pré-projet nécessaires au démarrage sain d’un projet.

Enchainement des workshops

Initialement, l’idée était d’enchainer les workshops dans l’ordre suivant : un Design Sprint suivi d’un Event Storming puis d’un Example Mapping.

Gagner en efficacité en combinant les workshops

Toujours dans l’optique de réunir les ateliers, l’idée déployée par @Dave Buchanan est encore plus intéressante qu’une simple succession des workshops. Il s’agit cette fois de combiner à la fois Design Sprint et Event Storming, ce qui permet :

• Une meilleure collaboration entre les équipes (UX/UI designers, testeurs, équipe de développement, experts métier) ;
• Une boucle de feedback plus rapide pour les développeurs et l’équipe.

Vous trouverez ci-dessous les phases combinées, telles qu’elles ont été présentées lors de la conférence Explore DDD sur le thème « Domain Modeling with Your Product Team », auxquelles nous ajoutons l’Example Mapping :

Cette approche combinée permettra également une meilleure compréhension du problème dans toutes ses dimensions. En effet, le prototype choisi définira les intentions, les inputs et les outputs souhaités par l’utilisateur final. Les trois premières étapes sont nécessaires pour la compréhension de ses besoins et le choix de la solution adaptée.

L’Event Storming et l’Example Mapping permettront une meilleure clairvoyance du fonctionnement du métier. Il est intéressant de noter que la connaissance et le fonctionnement métier ne sont pas nécessaires au savoir de l’utilisateur et qu’ils ne doivent pas avoir d’impact sur ses besoins. Ceci explique l’ordre des phases présenté ci-dessus.

Il ne reste ensuite plus qu’à prototyper la solution et la tester…

Combinaison des méthodes : des résultats concrets

La mise en place combinée des différents ateliers par l’équipe de Dave Buchanan a considérablement amélioré la gestion du projet. Elle a notamment permis :

• De réduire la boucle du feedback pour l’équipe et l’utilisateur final ;
• D’améliorer et de fluidifier la collaboration;
• De partager un langage commun entre les différents intervenants ;
• D’augmenter la satisfaction du client;
• De diminuer la frustration de l’équipe.

De manière plus générale, après avoir expérimenté à plusieurs reprises cette méthodologie pour des nouvelles features d’une solution IT, nous avons constaté que cette approche :

• Crée une atmosphère de confiance au sein de l’équipe ;
• Donne un sentiment d’appartenance ;
• Permet de partager un objectif commun ;
• Élève la motivation des intervenants.

Autant d’éléments particulièrement bénéfiques pour la sécurité psychologique de l’équipe.

Mettre en place une méthodologie collaborative est certainement la clef de voûte de la réussite d’un projet IT. Comme quoi, Confucius avait raison : « le tout est plus grand que la somme des parties ».