Toujours livrer
Contre toute attente, le bon moment pour publier quelque chose, c’est quand ça fait encore peur.
La raison : livrer tôt et souvent réduit les risques et nous fait franchir les jalons plus rapidement.
C’est si important que c’est devenu le 3e principe agile.
Livrer […] fréquemment, de quelques semaines à quelques mois, en privilégiant l’échéance la plus courte. fréquemment, de quelques semaines à quelques mois, en privilégiant l’échéance la plus courte.
En publiant notre travail tôt et souvent, on découvre vite ce qui fonctionne et ce qui ne fonctionne pas.
Comme les gens sont surtout tactiles et visuels, leur mettre quelque chose de concret entre les mains le plus tôt possible nous donne accès aux réactions les plus franches de nos utilisateurs et de nos clients.
On risque moins de refaire le travail et de perdre du temps. On peut aussi itérer plus souvent et faire évoluer le produit et notre processus par cycles plus courts.
On va chercher les premiers utilisateurs et on voit qui s’intéresse sérieusement à ce qu’on offre. En plus, ça fait jaser.
Les bonnes raisons de publier tôt et souvent ne manquent pas. Alors qu’est-ce qui nous retient?
Voyons deux blocages courants :
Le perfectionnisme
C’est la voix de la peur qui nous dit :
- Si j’ajoute juste X, ça risque moins d’échouer.
- Si je n’ajoute pas Y, les gens pourraient critiquer le produit
Le perfectionnisme n’accepte jamais le « assez bon ». Il exige qu’on ait paré d’avance à toutes les attaques et à toutes les critiques possibles avant la sortie.
Un bon moyen de le repérer : quand de nouvelles exigences repoussent sans cesse la date de sortie. Les exigences d’un projet peuvent changer, mais pas celles de la story ou de l’élément sur lequel vous travaillez
Les vrais artistes livrent.
- Seth Godin
Le perfectionnisme, ce n’est pas faire un travail de qualité. C’est franchir la ligne d’arrivée et refuser d’arrêter de courir.
Pour savoir où s’arrêter, il faut une ligne d’arrivée bien définie.
Le surdéveloppement
Pour livrer fréquemment, il faut adopter une approche agile : découper le projet en jalons fondés sur la valeur et publier notre travail à chacun d’eux.
Ce faisant, l’énergie qu’on met dans le projet nous revient sous forme de rétroaction des utilisateurs et de progrès tangibles. C’est un peu comme un artiste qui se nourrit de l’énergie de la foule.
Sans publier, votre équipe est comme un groupe qui joue devant un stade vide.
Pour que l’énergie continue de circuler, il faut s’en tenir, sans pitié, au strict nécessaire à chaque version.
Le forum en ligne Circle en est un excellent exemple : quand j’ai utilisé la version bêta pour la première fois dans le cadre d’un cours en ligne, il n’y avait aucun moyen d’envoyer un message privé (DM) aux autres membres. Toutes les communications entre utilisateurs étaient publiques, sous forme de publication.
Si on voulait organiser un appel ou une conversation, il fallait publier nos adresses courriel dans le forum de la communauté.
C’était évident que les membres voudraient s’envoyer des messages privés. C’était un trou béant.
Pourtant, Circle a lancé sans cette fonction, parce que la valeur centrale était d’offrir un forum aux communautés d’apprentissage, pas forcément les DM.
Même sans DM, leur plateforme offrait des avantages importants par rapport à la concurrence, alors ils étaient prêts à publier et à tester.
Les utilisateurs ont vite demandé les DM, mais la plateforme gardait beaucoup de valeur sans eux. Ils n’avaient pas besoin de messages privés pour lancer. Ç’aurait été facile de se convaincre du contraire. Ç’aurait été facile d’imaginer les critiques à venir et de retarder le lancement pour inclure la fonction.
Quand Circle a décidé de donner à l’apprentissage en ligne le forum communautaire efficace qui lui manquait, l’équipe savait que les messages privés entre utilisateurs n’avaient rien pour bloquer le lancement. Elle a donc publié sans.
Qu’est-ce qui n’est pas essentiel, mais que vous laissez quand même vous empêcher de publier plus souvent?
Le surdéveloppement est un piège courant : on y perd du temps et de l’énergie, surtout de la motivation. Si vous manquez souvent de jus en plein milieu d’un projet, la cause est probablement là.
Commencez par quelque chose de simple et observez le comportement des utilisateurs pour voir ce qui est vraiment nécessaire ensuite. Ça évite de bâtir pour rien.
Si vous savez clairement ce que vous voulez apporter et dans quel ordre le bâtir, vous allez avoir envie de publier ce que vous avez bâti.
Pour conclure, voici quelques questions à vous poser quand vous planifiez vos versions :
- Qu’est-ce qui compte le plus pour le client ou l’utilisateur (le problème à régler)?
- Quel est le minimum de travail pour y arriver? (pensez au long terme quand vous cherchez à en faire moins)
- Si une user story risque de prendre plus de 2 jours ouvrables, peut-on la découper en plus petits morceaux qui ont chacun leur valeur?
Publier, c’est important parce que ça donne des victoires. L’équipe a une vraie raison de rester mobilisée. C’est le vent dans les voiles de votre équipe… et dans vos ventes.