Avec un titre aussi racoleur j’ai intérêt à assumer derrière 😅 ! Au moins autant que cette dernière vidéo youtube sur laquelle vous avez cliqué parce que le titre et la vignette semblaient sympa.

Avec cet article histoire, je vais vous raconter la vie d’un projet qui se rêvait produit.

✍️ Notes de l’auteur

Au cours de cet article-histoire, nous aborderons ensemble une notion qui varie selon les gens avec qui vous discutez ou les sites internet que vous visitez.

De la même manière que personne ne détient de vérité absolue, laissez-moi vous expliquer ce point de vue de suite.

Un projet : c’est une réalisation avec une date de début et une date de livraison. Une fois livré, le projet s’arrête et on passe en TMA.

Un produit : c’est une réalisation qui n’a pas de date de fin (ou en tout cas pas connue à l’avance), il y a une date de début et des livraisons régulières. Le projet ne passe jamais dans cette logique de TMA.

On pourrait passer des heures à débattre de la sémantique utilisée, j’aurais pu appeler cela une claquette et un abribus, mais ç’aurait été cognitivement moins simple à appréhender.

📖 Prologue

Notre histoire commence sur une erreur, je partais du principe que tout le monde connaissait le cycle de vie d’un projet, même d’un produit. Mais je me trompais.

D’ailleurs, connaissez-vous la différence entre un projet et un produit ?

Je ne m’étais même jamais posé la question

90% des personnes sondés selon un sondage jamais réalisé

De la même manière qu’on narre la vie d’un personnage, je vais vous raconter la vie d’un produit qui, malheureusement pour lui, a été considéré comme un projet.

❤️ Chapitre 1: L’envie

Chaque début de vie commence par une envie. Une idée.

Notre protagoniste, qu’on appellera Camille (parce que c’est un prénom mixte) a cette idée qui lui trotte dans la tête depuis quelque temps maintenant. Ce besoin utilisateur qui se fait de plus en plus ressentir.

Après beaucoup de réflexions, Camille a très envie de se lancer.
C’est vérifié, budgétairement, ça passe. Et de toutes façons, il faut y aller, Camille en a la conviction, si cette idée ne prend pas vie rapidement, les frustrations des utilisateurs seront vite un problème impossible à ignorer.

Seulement voilà, Camille n’a aucune idée de comment donner vie à son idée. Ni les compétences d’ailleurs.

Alors Camille va se mettre en quête d’un partenaire technologique. À deux, ils vont donner vie, ensemble à cette idée.

Seulement voilà, Camille n’a pas encore réfléchi au comment.

• Est-ce que son partenaire va juste l’aider à donner vie à son idée ?
• Est-ce que son partenaire va l’aider à réfléchir à son idée ?
• Est-ce que son partenaire va l’accompagner dans la vie de son idée ?
• Et une fois que son idée aura pris vie ? Qui va l’aider à s’en occuper ?

Tout un tas de questions qui méritent une réponse ! Parce que cela va très fortement impacter le choix que Camille doit faire dans son partenaire.

D’ailleurs, est-ce vraiment un partenaire ?

Si les réponses sont majoritairement non, Camille ne cherche pas un partenaire, Camille cherche juste un réalisateur. C’est son droit, mais cela va changer la donne.

Si les réponses sont majoritairement oui, alors Camille cherche un partenaire, qui va challenger son idée, lui apporter de la matière et co-construire cette dernière pour lui donner une dimension à laquelle Camille n’avait pas forcément pensé au début.

Camille se dit, « je verrais bien ». Et si Camille se dit ça, la réponse est aussi claire que si les réponses étaient non.

🍼 Chapitre 2 : La naissance

Pour donner naissance à son projet (NDLR; si j’avais mis produit l’article aurait perdu de sa saveur, mais n’ayez crainte, comme toute bonne histoire, un cliffhanger arrive) Camille, a trouvé un partenaire top ! Et bien un partenaire.

Camille a co-construit son idée avec ce partenaire, ils ont réalisé un design sprint ensemble.
D’ailleurs, l’idée de Camille a évolué. S’est transformée. En mieux !

Ensemble, ils ont consulté les utilisateurs et utilisatrices, et repensé les irritants pour arriver à une solution qui a vraiment du sens pour eux.

Ils sont même allés jusqu’à modéliser ce que donnerait l’idée une fois réalisée, cela ne restait qu’une simulation sans action derrière, mais cela permet de palper la solution future.

Camille aurait très bien pu faire différemment.
En ne remettant pas du tout en cause son idée, simplement en la donnant au réalisateur (qui du coup, n’est pas un partenaire).
Cela n’est pas forcément un mauvais choix, cela dépend si Camille a la certitude que son idée répond exactement aux soucis de ses utilisateurs et utilisatrices ou non;

D’une façon ou d’une autre, Camille et son partenaire, après une gestation plus ou moins longue en arrivent au même point, l’idée va prendre vie !

🚼 Chapitre 3 : Les premiers mois

Une fois que Camille et son partenaire sont satisfaits de la forme que prendra son idée, la balle passe plus dans le camp du partenaire.

En itérant à une certaine fréquence, ce dernier va développer l’idée de Camille. Plusieurs méthodes existent pour cela, la plus connue étant scrum, mais ce n’est pas la seule.

Camille n’est pas pour autant complètement à part. Au contraire !

En effet, pour que l’idée de Camille prenne vie de la meilleure façon, il faut une présence importante de Camille tout au long des premiers mois.

C’est Camille qui donne le LA, qui donne les priorités, qui réagit sur les fonctionnalités. Car c’est surtout ça être agile.

Peut être qu’en cours de route, on va se rendre compte qu’il faut des changements par ci, par là. Et ces changements il faut les embrasser, mais c’est Camille qui va nous notifier de ces changements.

D’ailleurs, au fur et à mesure que l’idée de Camille prend vie, son partenaire va pouvoir lui montrer les changements et attendre sa validation ou non ! Cela permet d’éviter un effet tunnel qui ne serait bon, ni pour Camille, ni son partenaire.

Après quelques itérations, Camille et son partenaire y sont enfin. L’idée a pris vie, l’idée est sortie.
Les utilisateurs et utilisatrices de Camille sont ravis de voir un outil qui va permettre de combler certains de leurs irritants.

A cette étape, Camille n’est que joie !

⚰️ Chapitre 5 : La mort

Un peu violent comme chapitre, vous en conviendrez… Seulement voilà, il faut se montrer réaliste.

Mais comment en est-on arrivé là ?

Camille avait pensé son idée, et c’était une bonne idée. Seulement Camille n’avait pas pensé à la suite.

Alors une fois que l’idée de Camille a pris vie, la vision a changé. La relation qu’avait Camille avec son partenaire a changé.

En effet, Camille voulait que son projet (et pas produit) continue de vivre, ou plutôt… De survivre.

• Camille n’a pas pensé à de nouvelles fonctionnalités (ou de manière atomique)
• Camille n’a pas engagé ses utilisateurs sur son idée
• Camille n’a pas cherché à améliorer son projet.

Les utilisateurs et utilisatrices, plus victimes que coupables, subiront d’ailleurs cette fin d’histoire…

Parce qu’en effet, lorsque le projet de Camille est entré en TMA, l’objectif n’était que de stabiliser, corriger les bugs et faire en sorte de maintenir le service opérationnel.
Une tâche louable, mais qui n’est pas vraiment adaptée aux attentes des utilisateurs et utilisatrices d’aujourd’hui.

📓 Epilogue

Un soir d’automne, à sa fenêtre, avec un bon verre de jus de mangue, Camille pensa: « Je n’ai pas vu la vie de mon projet« …

Réflexion normale. Mais pourquoi ?

En fait, Camille a demandé à son partenaire de faire de la TMA sur le projet, et d’un coup, en un mot, son partenaire est devenu un réalisateur.

Fini la co-construction
Exit l’amélioration continue
Oublié les nouvelles fonctionnalités
Hors de propos la v2

Et c’est normal. C’est le but de la TMA.

En faisant ça, Camille a amorcé la fin de vie de son idée de façon automatique. Cela prend parfois 1 an, parfois 10, parfois (souvent) beaucoup moins.

Mais comment aurait-on pu éviter cela ?

Après tout, un projet doit forcément finir par partir la tête haute, mais si vite ?

Si la lecture ne vous a pas échappé, nous sommes passés du chapitre 3: les premiers mois au chapitre 5 : la mort.
Ce n’est pas un oubli. C’est volontaire, parce qu’avec la TMA, Camille et son partenaire n’ont pas fait une chose, ils n’ont pas suivi la vie de leur projet.

Prenons une machine à voyager dans le temps, et, à la manière d’un film de Noël, voyons ce qui se serait passé sans TMA.

🦋 Chapitre 4 : La vie

Projetons-nous, l’idée de Camille vient de prendre vie ! La v1 est rendue disponible aux utilisateurs et aux utilisatrices.

Camille est joie, son partenaire est joie, les utilisateurs & utilisatrices sont joies.

Le temps passe, le projet se stabilise bien sûr, le partenaire est là pour ça.
Et on commence à se rendre compte que de nouveaux besoins émergent.

Camille et son partenaire en discutent. Tout ne mérite pas forcément d’être pris en compte, mais certaines idées sont vraiment bonnes. Le projet doit évoluer, il doit redevenir un produit !

Il faut refaire certaines réflexions terrains (UXUI), il faut aller rechercher du budget, refaire du dev.

Mais cela vaut tellement le coup ! Le produit va changer, va grandir. Va engager.

Prenez vos applications. Regardez les mises à jour. Regardez les apports.

Il y a toujours quelque chose à faire et c’est ça donner la vie à son produit !

🕵️‍♂️ Notes de l’auteur

Quand j’ai commencé à réfléchir à cet article, je me suis dit, est-ce que La Mobilery va me laisser l’écrire sur le blog de la société ?

Parce que néo-ESN ou non, de la TMA, on en propose. Donc faire un article entier en dénigrant une partie de notre métier, ce n’est pas forcément limpide que c’est un bon moove.

Sauf que voilà, de la même manière que se lever à 5h du matin pour les boulangers, risquer sa vie sur des incendies volontaires pour les pompiers, compter la caisse en fin de journée pour les commerçants et j’en passe, on ne le fait pas parce que ça nous éclate, on le fait car c’est nécessaire. Encore beaucoup trop aujourd’hui.

Qui rêve de TMA ? Qui ?

Je parle de la bonne vieille TMA, aujourd’hui on met un peu tout dedans, mais de la TMA c’est de la maintenance, pas de l’ajout de fonctionnalités.
Quand un constructeur automobile sort un nouveau moteur, la TMA c’est le nettoyer, le huiler et le réparer, pas rajouter un cylindre à droite ou un réducteur de bruit à gauche.

De la TMA, ce sont des soins palliatifs pour un projet, c’est du bugfix. POINT BARRE.

Wikipedia le dit bien, la TMA c’est maintenir en conditions opérationnelles selon un niveau de service prédéfini

Personne ne veut faire de TMA. Encore moins ceux qui ont participé à ce que le projet produit prenne vie.

Ce qu’on veut, c’est vivre avec lui, lui apporter de nouvelles fonctionnalités, le soigner, l’améliorer, le faire grandir.

Mais c’est aussi ce que veulent vos utilisateurs. Rester bloquer sur une v1 qui n’apporte rien c’est lassant.
C’est comme vivre dans un appartement ou une maison sans jamais faire de travaux, de peinture, de décoration. Cela ne dure qu’un temps.

L’engagement utilisateur vient aussi par là, par l’ajout de nouvelles choses, le retrait d’autres inutilisées.

Alors voilà, fort de cette petite analogie, si jamais vous avez une idée, un besoin, que ce soit une application mobile, web, ou tout autre chose qui vous permet de vous transformer numériquement, La Mobilery est là.
Nos équipes sont prêtes à donner naissance à votre idée, en co-construisant, en étant partenaire avec vous de cette étape.

Si vous le voyez comme un projet, c’est dommage, cela ne veut pas dire qu’on ne le fera pas avec vous, parce que chaque idée mérite qu’on lui donne sa chance.

En revanche, si vous le voyez comme un produit, cela sera une super expérience.
De la naissance du produit avec la co-construction en un design sprint, animé par nos experts UX/UI, à la phase de prototypage et maquettes interactives pour tester avec vous et vos utilisateurs.
Des premiers instants de vie avec notre phase de build en agilité avec vous en proximité pour régulièrement voir votre produit grandir avant sa première dent mise en ligne.
Et tout au long de sa vie en améliorant constamment ce dernier, en lui donnant de la saveur et de la vie, tout en espérant ne jamais arriver à cette phase de TMA qui est, malgré tout, inéluctable un jour ou l’autre.