Le backlog est vivant, il bouge avec des feedbacks (épisode 2 - pour découvrir le produit, il faut le construire)
Les idées fusent.
Charlotte prend plaisir à formaliser ses idées, elle rédige ses idées comme des petites histoires utilisateurs qui prendront vie quand le logiciel fonctionnera. Elle raconte comment ce sera bien d’utiliser le logiciel. C’est un moment agréable et facile.
« Il permet de jouer aux devinettes de kana et de romaji, il possède un mode aléatoire, il permet aux élèves de connaître leur progression, … »
C’est salvateur de formaliser toutes ces histoires : elle avait ces idées en tête, mais les écrire lui permet de se projeter sur la suite. Elle a l’impression de bien travailler, de prendre les choses dans l’ordre et de travailler proprement. C’est vraiment un bon moment.
Le résultat est le suivant :
Les idées sont limpides. Elle s’imagine commencer bientôt.
Elle hésite.
Il y a beaucoup de travail, évidemment.
Elle se dit « Par quel bout faut-il le prendre ce produit pour que ce soit un succès ? ».
Commencer par quoi.
Écrire les idées a été un exercice facile, rapide même. Maintenant elle se demande par quoi elle commence, et voilà que cette question déconstruit toutes ses certitudes.
C’est angoissant. Elle sent bien qu’elle peut se tromper et elle commence à saisir la gravité de ses décisions de priorisation.
Elle réfléchit :
« Suis-je bon stratège ? Est-ce que je prends les choses dans le bon ordre ?
« Si je suis cette liste d’idées, serais-je fidèle à mon intention du début ?
« Ne suis-je pas en train de perdre mon temps avec du travail superflu ? »
Elle ne peut pas faire patienter ses enfants 3 mois ou 6 mois. Elle aura l’air ridicule, pas compétente. Ou alors pire, ils n’auront plus envie.
Elle voudrait leur demander souvent « Ça vous plaît ? ».
Elle s’entend bien avec ses ados, elle compte bien en profiter pour récupérer des feedbacks et améliorer son produit à chaque fois.
C’est rigolo, elle sait qu’elle a rarement des rapports aussi francs et transparents avec ses utilisateurs. Elle aimerait bien pourtant.
Elle décide de leur poser souvent la question « Ça vous plaît ? ».
Leur promettre quelque chose et le leur montrer.
Puis le refaire souvent.
Des petites promesses, faciles à tenir.
Elle retravaille ses idées en les regroupant. Elle les montrera au même moment, en même temps. Le premier moment (l’itération 1), c’est la promesse qu’elle fait à ses utilisateurs du futur fonctionnement. Cette promesse est une phrase, mûrement réfléchie, qui rend logique le regroupement de ces idées-là pour la première itération.
« Maman elle fera quoi ton appli ?
— Tu vas pouvoir t'entraîner à reconnaître les kanas.
— Ok »
L’enthousiasme des ados n’est pas délirant non plus, les utilisateurs sont à convaincre finalement. Le logiciel a intérêt à tenir ses promesses et même plus. Il doit ravir ses utilisateurs, les exciter pour qu’ils demandent la suite.
Elle a promis « Tu vas pouvoir t’entraîner à reconnaître les kanas. » Elle cherche quelles idées sont en lien avec ça. Elle se rend compte que sa promesse modifie un peu ses idées. Elle réfléchit. La promesse est plus importante que les idées déjà écrites. Du coup elle découpe des idées, change des priorités. Elle découvre un nouveau chemin d’idées pour tenir sa promesse : pour progresser, il faut s’entraîner à deviner. Elle décide donc que l’entraînement se fera d’abord sur la reconnaissance des kanas en mode romaji, et ce dans les deux alphabets des kanas (hiragana et katakana).
Pour autant, elle ne s’arrête pas de réfléchir et elle a d’autres idées. Ces nouvelles idées ne sont pas en lien avec sa première promesse, elles sont donc moins importantes. Elle les écrit, en y apportant peu de détails car il s’agit juste de ne pas les oublier, elle y reviendra plus tard.
Sa nouvelle liste d’idées ressemble à ça :
Elle est un peu rassurée. Les idées présentées sous cet ordre sont moins risquées. Cette construction-là du backlog plaira mieux, elle en est sûre. Elle voit l’itération 1 comme un premier pas qui, elle l’espère, la rassurera encore.
Enfin, elle verra ce que les enfants en diront.
Bon finalement c’est fatigant d’écrire ces idées, elle avait l’impression de savoir quoi faire et pourtant elle se rend compte qu’elle découvre son produit. C’est un comble, c’est elle qui le construit.
Elle n’est pas encore convaincue, elle est inquiète maintenant elle a l’impression de tâtonner.
Ou alors c’est une démonstration, elle doit chercher, prouver.
La promesse 1 + la promesse 2 + la promesse 3 = l’intention de son produit.
Construire le backlog, c’est comme essayer de faire une bonne démonstration.
Vu comme ça, c’est sympa ces promesses.
Très facile en fait.
Elle imagine un dialogue avec sa fille pour tester si l’argumentaire est convainquant :
« Comme je vous l’ai annoncé plus tôt, très chère utilisatrice, nous travaillerons d’abord sur l’entraînement à reconnaître les kanas.
Puis vous pourrez apprendre ce que vous voudrez.
Puis vous connaîtrez votre score. »
Elle vérifie et vérifie encore.
La promesse 1 plus la promesse 2 plus la promesse 3, ça marche. C’est cohérent avec l’intention du produit.
Très très très facile.
Chouette.
« Vous allez vous entraîner à reconnaître des kanas. »
Cette promesse regroupe finalement deux idées seulement, c’est suffisant.
Quelle fierté d’avoir économisé du temps. Ce sera du travail de développer tout ça, et c’est un soulagement de découvrir que la promesse sera atteinte avec deux idées seulement au lieu de trois. Du temps économisé pour faire autre chose.
Non, pas juste du temps économisé.
Charlotte se rend compte que si elle développait une idée « en trop », les utilisateurs auraient une fonction en trop. Ce serait dommage de réaliser une application dense, il y en a assez comme ça, elle n’aime pas ça.
C’est comme dans la langue française.
Bien, c’est bien.
Beaucoup, c’est un peu trop.
Trop, c’est un aveu d’échec.
Finalement, bien réaliser c’est réaliser moins et mieux.
Elle pensait savoir ce qu’elle voulait depuis le début.
Elle se rend bien compte qu’elle passe du temps à écrire ses idées … et à les modifier, et à les déplacer.
C’est déconcertant mais elle l’avoue, elle comprend de mieux en mieux son produit.
épisodes :
2 - pour découvrir le produit, il faut le construire
4 - les utilisateurs seront ravis
7 - la PO n'est pas certaine, elle pourrait aller plus vite