If you hire people just because they can do a job, they’ll work for your money. But if you hire people who believe what you believe, they’ll work for you with blood and sweat and tears.
Simon Sinek
Étiquette : productManagement
Product Tank #16 : des produits et des jeux
La gamification était bien le thème de cette nouvelle rencontre. Avec 2 interventions très enlevées.
Siffler en travaillant, avec Anna Livia Gomart-Cardin
Anna Livia nous vient du marketing du jeu video, et elle va décortiquer pour nous certains mécanismes du jeu ! Pour commencer, elle distingue 2 notions :
- « play » : sans règle
- « game » : avec des règles
Les raisons principales qui nous conduisent à jouer sont aussi au nombre de deux :
- On est très bon à ce jeu : on joue pour le plaisir, parce que cela met en avant nos compétences.
- Pour apprendre, acquérir des compétences ; pour une vision de soi une fois ces compétences acquises.
Le jeu, c’est également le fun. Il provient de la vision, du sens que l’on donne à notre travail. Les chants de marins symbolisent l’engagement, le plaisir de l’action. Ce sont 4 types de « fun » que distingue Ann Livia :
- « easy fun » : un moment sympa, facile.
- « hard fun » : des moments qui nous grandissent. C’est la raisons pour laquelle on peut faire des mots-croisés, par exemple.
- « fun social » : pour apprendre des autres
- « fun sérieux » : des apprentissages qui servent hors du contexte d jeu.
How do you know that your product works ?
Ai-je vraiment « terminé » ?
C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?
- Quand le code est commité ?
- Quand le produit est testé ?
- Quand il est déployé en production ?
Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.
Où l’on reparle de valeur
La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.
Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.
Note de lecture : Stand Back and Deliver, par Pollyanna Pixton & al.
Note : 7 ; Du modèle de valeur au modèle de leadership.
Pas facile de classer ce livre de prime abord. Finalement, c’est du côté du « Product management » qu’il a le plus sa place. La première chose qui surprend dans ce livre, c’est le titre ! Les auteurs s’en expliquent dans la préface : le point clé du « process », c’est de mettre ensemble les acteurs clés, puis de se tenir en retrait ! La seconde chose qui surprend un peu, c’est la taille de l’ouvrage : seulement 150 pages, qui ne nécessitent guère plus de 7 chapitres.
Le premier chapitre ne compte que 9 pages. C’est une introduction au reste du texte, on y présente dans les grandes lignes les 4 éléments du framework qui feront l’objet des chapitres suivants. Justement le chapitre 2, avec ses 30 pages a trait au premier élément : le « purpose alignment model ». Celui-ci permet de qualifier les éléments d’un portefeuille de projets par rapport aux axes différentiateurs de l’entreprise. Bref, un bel exemple de discrimination par la valeur. Mais surtout un modèle pleinement utilisable tous les jours. Certainement le plus utile du livre !
Le chapitre 3 a trait à la collaboration, c’est l’aspect « stand back » du titre. Ici les auteurs, au long des 25 pages de ce chapitre, nous proposent 3 outils :
L’Impact Mapping s’invite au French SUG !
Décidément, cette nouvelle année du French SUG voit émerger une nouvelle dynamique : celle de permettre aux membres de la communauté d’être acteur des évènements ! D’accord, pour l’évènement de février on peut argumenter que je suis un ancien membre du bureau… Mais ce n’est pas le cas de celui-ci . Il a été imaginé par Géraldine Legris, épaulée par Dragos Dreptate.
Le bitcoin sous toutes ses faces !
En cette fin Janvier, le meetup Product Tank nous proposait un programme tout à fait prometteur : 3 invités venus pour nous présenter le bitcoin sous 3 perspectives différentes ! Sébastien Levaillant a fait un travail remarquable pour organiser cela. Travail mal récompensé par une participation plutôt faible : seulement 25 personnes présentes sur les 75 inscrits !
Bien sûr, le sujet est moins cliquant que lorsque l’on invite le Product Manager d’un commerce en ligne très en vue. Toutefois le sujet est au moins aussi intéressant, plus même dans ce cas précis, car on se situe là en pleine innovation économique !
Agilité et hospitalité Libanaise
J’attendais cela depuis un moment, depuis le milieu de l’été pour être plus précis. Car Pierre Hervouet nous avait invité à venir partager avec la communauté Libanaise pour cette seconde édition de l’Agile Tour Liban ! Nous étions donc 4 Français à nous envoler vers le moyen-orient le vendredi matin pour une conférence qui se déroulerait en week-end.
Améliorer la société au Product Tank
Ce nouveau rendez-vous du Product Tank avait aujourd’hui un focus très clair et très particulier : des produits qui n’en sont pas … et surtout qui sont là pour améliorer la société. Nous étions accueillis à cette occasion au John Paul Lounge, un espace ouvert sur les Champs Elysées !
Un petit comité hélas pour un sujet pourtant si particulier et une soirée qui s’avèrera riche d’enseignements.
Note de lecture : Specification by Example, par Gojko Adzic
Note : 8 ; La référence sur le développement guidé par les tests. Book of the year 2014 !
Régulièrement, je retarde le moment d’ouvrir un livre que je sais excellent (de réputation) et qui prend la poussière sur une de mes étagères. Ce livre est de ceux-là ! Bien que Manning nous gratifie de temps en temps de titres non-techniques, il est assez étonnant de trouver celui-ci chez cet éditeur, probablement parce que ce n’est pas un livre pour remplir un vide thématique.
Il s’agit bel et bien d’un texte nous proposant un regard novateur sur les tests d’acceptance, même si l’auteur rappelle régulièrement au fil des pages qu’il fait suite à son ouvrage précédent « The Communication Gap ». Ce n’est pas non plus un livre très facile à lire, non qu’il soit volumineux car il ne compte que 250 pages, mais il s’appuie essentiellement sur de nombreux témoignages qui transforment le fil conducteur en une sorte de patchwork. Evidemment, ces nombreux témoignages qui sont autant de cas d’étude font beaucoup pour la crédibilité du texte qui est ainsi à la fois un travail digne d’un universitaire et l’œuvre d’un praticien de terrain. Venons-en au contenu.
L’ouvrage se découpe en 3 parties inégales. La première d’entre-elles ne compte que 60 pages réparties en 4 chapitres. Le premier chapitre nous laisse un peu dans le flou, il s’agit surtout d’un argumentaire étayé de témoignages sur la raison de s’intéresser à la spécification par l’exemple. On rentre dans le dur au chapitre suivant qui aborde la manière dont Gojko Adzic voit s’articuler le besoin depuis les « business goals » jusqu’à la « documentation vivante ». Les aspects amont sont par ailleurs l’objet de son ouvrage suivant « impact mapping ». On y apprend incidemment pourquoi l’auteur préfère « spécification par l’exemple » à « développement guidé par les tests d’acceptance ». Un chapitre à ne rater sous aucun prétexte ! Le chapitre 3 « living documentation » offre pour moi peu d’intérêt, sauf peut-être celui de couvrir le schéma de processus que l’auteur nous a exposé au chapitre 2 ? La spécification par l’exemple ne se veut pas une pratique spécifique aux projets agile, bien que ce soit un terrain de jeu naturel. Au chapitre 4, l’auteur aborde différentes façon de basculer d’un projet classique à l’écriture des tests en amont sous forme de patterns (bien qu’ils n’en empruntent malheureusement pas la forme).
User Stories are like bananas. after slicing consume quickly, or they turn into garbage.
Gojko Adzic
Software Freethinker 