Déminer une projet digital : les questions clés à se poser

Certains projets digitaux sont réalisés dans un contexte de tensions démesurées et nocives entre les différentes parties-prenantes. Plus particulièrement, la relation IT/Marketing peut nécessiter la restauration d’un climat de confiance, qui permettra d’atteindre les objectifs de qualité attendue par vos clients. Voyons quelques pistes de travail pour assainir les choses …

 

1 – “in code we trust”

Compte tenu de leur formation et de leurs goûts, les équipes techniques sont souvent habitées par une vision “techno-centrée” de l’innovation et de l’évolution des produits/services digitaux dont ils ont la charge. Ils peuvent avoir tendance à recommander une solution car elle est techniquement séduisante, porteuse de promesses en terme de performance ou de rationalisation des coûts mais pas toujours en adéquation avec le besoin du marketing ou pire, avec les attentes des utilisateurs finaux. Certains choix techniques (infras serveurs, headless, briques CMS, moteurs d’indexations, …) sont ainsi imposés au démarrage d’un projet, et constituent parfois un poids difficile à dépasser dans les phases de conception et de réalisation. De surcroit, après 18 ou 24 mois de travail opérationnel, les choix initiaux peuvent perdre en légitimité ou même devenir incompris si le turn-over dans vos équipes est significatif. Veillez donc à toujours remettre en perspective les choix opérés en début de projet et, pourquoi pas, à les réviser en fonction de vos retours d’expérience.

 

2 – Qui peut le plus peut le moins ?

Les chantiers de refonte ou d’évolutions des dispositifs digitaux des grands comptes s’accompagnent souvent d’une série de lourdes tâches consacrées à l’évolution des infrastructures et des process de mise en production. (serveurs, déploiement continu, sécurité, …) On peut alors assister à un empilement des projets qui reposent pour partie sur les mêmes équipes, sollicitées de toutes parts par diverses chaines hiérarchiques rarement intéressées par les mêmes objectifs. Dans ce contexte les équipes peuvent perdre le sens des priorités et consacrer un temps trop limité sur le développement de produit, seul indicateur visible et légitime côté marketing.

Dans ce sens, il faut vérifier que les projets sont suffisamment pilotés, staffés et que les parties prenantes sont régulièrement tenues au courant des sujets qui les intéressent. Si vos équipes IT semblent très occupées alors que le marketing s’agace de l’avancement laborieux de leur produit, vous êtes peut-être dans ce cas de figure.

 

3 – pas d’agilité dans le brouillard

L’avènement des méthodes dites “agiles” dans la réalisation des projets digitaux, s’accompagne de son lot de méconnaissances et d’attentes démesurées. Il n’y a rien de “magique” dans les méthodes agiles puisqu’il s’agit essentiellement d’appliquer une méthode qui définit des rôles (Product owner et Scrum master), un mode organisationnel (équipes agiles, backlog, sprints, …) et des rituels (daily meeting, démo, poker planning, …). Le rôle de Product-owner est particulièrement important car il fait le lien entre l’expression du besoin et la réalisation technique. Il est le véritable catalyseur du projet et son rattachement hiérarchique, comme opérationnel, doit se faire de manière avisée. (on a tendance à conseiller de rattacher les PO à l’entité qui exprime le besoin, et non à une entité tierce et encore moins à l’IT)

Si vous avez le sentiment que vos product-owner n’ont que peu d’impact sur le projet et que vos équipes techniques se plaignent d’un besoin métier trop changeant/flou, il faut travailler sur la clarification des rôles et sur la préparation des sprints, notamment dans la précision et l’exhaustivité des besoins exprimés à travers les user stories.

 

conclusion : laissons sa chance à la conception !

Si vous êtes à la recherche d’une médiation pour réunir les 2 mondes (IT/Marketing), les phases de conception fonctionnelle et technique peuvent constituer un bon terreau de culture pour notamment  :

• Sortir de la relation client-fournisseur : Les équipes techniques sont capables d’apporter autre chose que de la simple exécution, ne considérez pas que les développeurs ne sont là que pour pondre des lignes de codes, sorties de leur contexte et sans vision du projet global. Il faut casser la posture de “client” parfois endossée par le marketing et travailler la cohésion d’équipe autour du projet. La remarque en miroir peut être faite vis à vis des développeurs qui ne codent que ce qu’il y a d’écrit dans les user-stories (ou spécifications), sans se préoccuper du rôle que jouera leur bout de code dans le produit global. Associer l’équipe agile très en amont de la réalisation de la première ligne de code n’est jamais du temps perdu.
• Renforcer la cohésion autour du produit : Dans la continuité du premier point, il faut essayer de profiter des rituels prévus dans la méthode agile pour rapprocher les équipes dites “thinker” des profils dits “Doer”. Vous pouvez par exemple inviter les équipes marketing à certaines rétrospectives de l’équipe agile, avec un encadrement efficace du Scrum-master vous pourrez créer de l’empathie entre des personnes qui inter-agissent au quotidien sans vraiment connaitre leurs contraintes respectives. Par ailleurs, la revue de backlog ou la mise en place de points “roadmap” peuvent permettre de donner de la perspective aux équipes qui comprendront vers quelle direction vogue le projet. Un point sur la démo : la méthode préconise de faire une démo à chaque fin de sprint, mais assurez d’avoir suffisamment de “valeur-métier” à présenter si vous invitez les équipes marketing. Une démo peut avoir un effet contre-productif et donner l’impression d’un projet qui n’avance pas …

Finalement, soyez vigilants sur vos recrutements et assurez-vous de positionner suffisamment de profils médiateurs expérimentés et dotés d’une forte sensibilité customer-oriented dans vos équipes. Par exemple, le Scrum-master pourra aussi endosser un rôle de chef de projet l’amenant à construire des ponts de communications entre les parties prenantes. En tant que garant de l’agilité, il doit veiller à la bonne motivation de l’équipe agile et à la responsabilisation du marketing sur la qualité du produit fini.