Le workflow est une modélisation de l’enchainement de l’ensemble des activités qui composent le product management. C’est l’héritage du Value Stream Mapping.
Des éléments circulent tout au long du workflow pour se voir soumis aux différentes activités. Ainsi, l’élément qui débute sa course avec l’activité 1 n’est plus dans le même état lors de la réalisation de l’activité 2. Il subit une transformation.
Une des particularités d’un workflow par rapport à un processus, c’est qu’il est composé de différents backlogs. Un backlog contient l’ensemble des éléments en attente de traitement (To Do). C’est aussi ce qu’on appelle du stock (inventory) dans le langage du Lean.
Dans les usines de production physiques, il y a un backlog à l’entrée du poste qui réalise l’activité, et un backlog à la sortie. En effet, il est nécessaire de déplacer les éléments d’un poste à l’autre.
On peut par exemple avoir en backlog d’entrée un châssi de voiture et des roues, qui sont assemblées sur le poste, puis placés assemblés dans le backlog de sortie.
Il est possible de créer d’autres états que « To Do », « In Progress » et « Done », comme « Impediments » qui correspond aux éléments deffectueux par exemple.
En product management, on va surtout travailler sur la représentation virtuelle des éléments et de leur état. Ainsi, on nomme backlog ce qui est en réalité un backlog virtuel ou informationnel suivi d’états dont la représentation n’est pas différenciée.
Il en est de même pour les éléments. On nomme élément principalement la représentation virtuelle des éléments traités.
Ainsi, il y a différents types d’éléments virtuels qui peuvent transiter : les références des éléments à chaque étape du workflow, et/ou les spécifications du travail à réaliser. Les spécifications du travail à réaliser, en mode de fonctionnement agile, sont formulées sous la forme de cas d’usage (User Stories), expérimentations (Spikes), réalisation technique (Technical Story ou Technical Requirement), défaut à corriger (bug), etc.
En product management, le cas d’usage (user story) est la source de toutes les autres spécifications car il se concentre sur le persona cible.
Le cas d’usage est composé d’une phrase courte qui récapitule ce que l’utilisateur peut faire et ce que le résultat lui apporte en terme de valeur ajoutée ou d’impact. Le contexte vient renseigner l’état initial, les différentes contraintes, le parcours préalable, etc. Le scénario décrit ce que l’implémentation du cas d’usage doit permettre à l’utilisateur de réaliser. Les spécifications techniques et fonctionnelles viennent ajouter du détail, notamment en termes d’attentes de performances, d’engagement au sens SLO, etc. Les critères d’acceptance quant à eux sont un outil qui permet à ceux qui implémentent le cas d’usage de s’assurer que celui-ci répond à l’ensemble des exigences précédemment mentionnées. Cela correspond la plupart du temps à des cas de tests formulés en langage Gherkin par exemple.
Ainsi, l’objectif est de faire circuler des éléments (items) d’un backlog à un autre, d’un état à un auttre, etc.
Pour réguler le flux, Toyota a inventé le concept de Kaban. En usine, c’est par exemple un nombre de caisses de transport fixe qui transitent d’une étape à une autre. Les caissent reviennent au point de départ une fois le travail réalisé (done). Ainsi, on ne peut avoir sur la chaine de production que le nombre d’éléments correspondant au nombre de caisses en circulation. Le principe est de limiter le nombre d’éléments en cours d’assemblage en même temps sur la chaine de production pour limiter les gâchis liés (muda).
En product management, cette régulation s’opère plutôt au niveau du nombre d’éléments qui peuvent être dans un même état. Par exemple « In progress ».
Lorsqu’on constate que les états aboutissent à des activités différentes, alors il est pertinent de scinder les activités.
Le takt time est le temps moyen mis entre l’entrée du premier item et l’aboutissement de l’activité correspondante.
Dans un environement plus complexe, on peut imaginer des blocs d’activités par thème de travail.
La variété des travaux aboutit à la gestion de cycles de travaux asynchrones que nous avons choisi de représenter au niveau de chaque bloc pour le product management.
Nous arrivons au bout de notre définition du workflow. N’hésitez pas à nous suggérer des améliorations de cette définition pour nous faire avancer.
Comment organiser le Product Management ?
Nous découpons le Product Management en blocs qui représentent chacun des cycles de travaux asynchrones, avec des aller-retours nombreux : Customers & Users Management, Business & Shareholders Management, Team Empowerment & Continuous Improvement, Vision & Strategy, Discovery, Delivery, Operations & Distribution, Launch & Updates, et End of Life. L’ensemble de ces blocs permet d’aboutir à des produits qui émergent et évoluent avec le temps, et qui peuvent déboucher sur des écosystèmes de produits…
