La formation utilisateur dans un cadre Scrum

Communauté Scrum Life
1

Hello les Scrum lifeurs !

Je cite le Product Owner responsable d’un produit interne : « j’en chie à former les utilisateurs sur tout ce qu’on déploie en cours d’itération ».

Dans un contexte Scrum, avec itérations et déploiement continu, si on attend la Sprint Review pour montrer aux utilisateurs finaux/clients le travail accompli, ça peut faire long si on déploie souvent des nouvelles features en cours de sprint.
De plus, la SR est une démo (avec feedback client), pas une formation à proprement parler pour tous les utilisateurs finaux.

Prenons un exemple, si on déploie une feature assez tricky pour le service compta, et que seul le.a manager de ce service est présent.e à la SR, est-ce sa responsabilité de former ses équipes à la feature ou plutôt au PO, ou encore, à quelqu’un dédié à cette fonction ? :thinking: La documentation utilisateur fait-elle partie de vos DoD ?

Bref, sujet formation utilisateur dans un contexte de déploiement continu :grin:

1 « J'aime »
2

Pas besoin de formation ou de documentation quand on fait un bon produit.

( c’est pareil pour le code d’ailleurs.)

Si tu as besoin d’expliquer c’est que c’est qu’il faut revoir la copie.

Parfois se limiter à documenter et former est plus « économique » (en argent, en motivation, disponibilité, …) et parfois pas. C’est donc un CHOIX (du PO).

Attention j’ai parlé ci-dessus de formation et documentation. À ne pas confondre avec l’information et la sensibilisation. Ou à la formation à bien exercer l’activité pour laquelle on s’appuie sur le produit.

==> informer les gens qu’une fonctionnalité est disponible (mais se permettre de s’arrêter là et de ne pas devoir expliquer comment la prendre en main)

==> sensibiliser, rassurer, pouvoir dire à l’utilisateur "Vas-y essaie, si tu casses un truc, c’est que NOUS n’avons pas encore le produit parfait, viens nous le raconter, qu’on améliore ça.

===> formation sur l’activité.

Un menuisier qui apprend à sculpter au marteau et au ciseau apprend à bien mettre son ciseau, à bien doser ses coups… mais on lui a fourni un bien triste outil si on doit lui mettre un mode d’emploi pour lui expliquer qu’on tient la masse par le manche et qu’avec la table du marteau, on frappe l’arrière du ciseau et non le biseau

image

Pour moi la SR n’est pas une étape de validation, ni de formation. C’est un moment de partage, d’information, l’échange est ouvert à chaud pour comprendre ce qu’on a reçu PENDANT le sprint. En quoi cela a tenté de faire progresser le produit sur l’objectif qui avait été fixé pour le sprint.

à la démo on plante des graines… Et on ne sait pas encore si le blé sera bon. Ca le boulanger viendra le raconter au PO.

1 « J'aime »
3

Le DoD est propre à chaque équipe, voire à chaque sprint
Il ne pourra pas être le même pour une équipe qui développe un IHM Front d’une équipe qui développe des API. Ca pourra être une session de formation ou un Swagger …

Ceci dit, dans certains cas, le métier à besoin d’une doc ou une formation utilisateur. Dont acte. C’est un élément identifié parmi les livrables du sprint donc à estimer et quantifier au Sprint Planning. Sa réalisation sera prise en charge par un BA/QA, ou un acteur métier identifié (PO ou super utilisateur).
Dans ce cas, ça fait partie du DoD, au même titre que tous les objectifs du sprint …

4

Merci les gars, très intéressant vos retours !
Comme tu l’as soulevé @Moosh, améliorer la communication sur le contenu de l’itération aux parties prenantes lissera peut-être ce souci, à tester ^^

5

Je trouve que c’est une super question (peut être même qu’on aura une vidéo dessus ? :grin: ).

Je rejoins ce que tu dis @Moosh (même si jsuis pas certaine de te suivre sur l’exemple du menuisier). Le truc c’est que le problème me semble rester entier car si on est d’accord pour dire que l’activité s’appuie sur l’outil, j’ai l’impression qu’elle ne peut pas en être facilement decorellée. Un utilisateur pour lequel l’activité évolue qui se retrouve avec juste de l’information sur l’évolution de son outil, ben il est perdu, il a bien besoin de comprendre son activité pour comprendre en quoi l’outil lui apporte support et s’il la découvre en même temps que les évolutions de l’outil… cela ne me semble pas génial.
A moins que l’outil affiche l’explication entre ce qu’il permet ou ne permet pas de faire sur le parcours user et en quoi cela répond à l’activité (formation activité intégrée).

Activités = processus, outil = produit et procédures ? :thinking:

Je tire la réflexion en même temps que j’écris…
Puisque l’activité se base sur l’outil, ne fait elle pas partie de la description du besoin ? Donc dès l’émission du besoin on sait déjà en quoi l’activité évolue ou en quoi l’activité existante ne trouve pas de solution dans l’outil. L’outil ne viendra que répondre à ce besoin, cette problématique. Donc il y a bien des personnes qui connaissent cette activité et comment elle évolue. N’est ce pas à ces personnes de communiquer/former ? Est ce que c’est le PO ? Est ce que ce sont certains utilisateurs finaux ?

En tous cas, mon sentiment c’est que c’est de la valeur pour l’utilisation du produit. Sans cette formation/information, potentiellement, l’utilisateur final ne peut pas utiliser l’outil.

Ça dépend peut être du domaine d’activité :woman_shrugging:t3:

Intéressante cette question @jplambert @const :wink:

1 « J'aime »
6

Plutôt que de poser les questions " Est-ce que ça fait ce que j’ai demandé ? " Et même « est-ce que ça marche ? »

Poser les questions " Est-ce que j’arrive à faire ce dont j’ai besoin ? Est ce que j’y arrive mieux qu’avant"

Au pire les 2 premières questions vont dans la dod.

Et ce qui est sûr , c’est que ce n’est pas au po ni au « spectateur » d’une démo, même si il y a prise en main immédiate, qu’il faut poser ces questions.

Mais ceux a qui le truc a été livré et utilisé en prod

7

Grâce au poke très subtil de @SophieB, on fera une vidéo sur ce sujet ! :grin:

3 « J'aime »