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, le Sprint Review 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. Ça 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 »
9

Ce qui j’essaye d’illustrer, c’est qu’il ne serait pas normal qu’on m’explique que la masse et le ciseau se tiennent par le manche, et qu’on frappe l’arrière du manche ciseau avec la table du marteau.

Ces outils sont très simples, très efficaces et on comprend comment les utiliser juste en les regardant :slight_smile:

Qu’on ne devrait pas former les gens à cela. Qu’on doit viser cela avec tous nos produits.

Et que par contre, on doit former les gens à faire de belles choses en utilisant bien ces outils.

1 « J'aime »
10

Ah bon ? On a des preuves de ça ? J’aurais plus l’impression qu’on infère l’utilisation suite à une exposition à l’utilisation soit des dits outils, soit à des outils similaires. Si je donne ça à un enfant qui n’en a jamais vu avant (et j’insiste sur le jamais), il y a sûrement peu de chance pour qu’instinctivement on arrive à une utilisation telle que tu la décris, « naturelle ». Le contexte social et culturel amène à cela, de la même façon que le contexte social et culturel rend les enfants d’aujourd’hui hyper-familiers avec les outils numériques alors que les personnes âgés luttes pour atteindre un même niveau de fluidité dans l’utilisation. Le contexte a toujours une importance capitale et c’est là toute la limite d’une observation qui se limite à l’utilisateur.

11

Ca a mis du temps à sortir, mais notre vidéo est là !

J’espère qu’elle vous plaira :grin: Continuous Delivery VS Scrum : est-ce compatible ? - YouTube

1 « J'aime »
12

Je copie-colle mon commentaire ici pour continuer la conversation:

Allez, c’est parti : J’ai l’impression (mais je suis sûr que ce n’est qu’une impression) qu’il y a une confusion entre intégration continue et déploiement continu. Faire payer aux utilisateurs du code inactif dans le bundle front d’une application, c’est pas très écologique :stuck_out_tongue: (entre autres).

De plus, il faut aussi faire attention avec le déploiement continu: Selon la façon dont l’application/le serveur va gérer les updates, on peut se trouver dans des cas extrêmement irritants. Par exemple, devoir attendre une update majeur d’un outil pour pouvoir l’utiliser alors qu’on est dans une situation non propice (rush, stress…), c’est clairement pas cool. Et si ça se répète fréquemment, ça devient carrément un repoussoir.

Concernant la solution de l’ergonomie, comme vous le dites, c’est contextuel. Maintenant, le sujet est bien plus complexe que simplement « si c’est du grand public, allez vers l’ergo ». D’abord, qu’est que ça veux dire grand public ? Si Photoshop est « grand public », on a clairement un exemple (parmi beaucoup d’autres) ou ergo et grand public sont incompatibles. Sur des domaines complexes, le but est d’avoir des interfaces simples (contraire de compliqué), pas simplexes (contraire de complexe).

Plus loin que ça, et toujours sur le sujet du grand public, plus on adresse de population, plus ce qu’on pense être ergonomique ne l’est pas : De manière générale, on voit bien que les populations les plus âgés ont du mal avec des interfaces même considérées comme ergonomiques. Mais plus loin que ça, toutes les personnes avec des handicaps sont aussi à prendre en compte dès lors qu’on augmente la densité de la population des utilisateurs. Et du coup, des compromis sont à trouver. Pas de « silver-bullet »…

Pour ce qui est de la doc, j’ai le sentiment qu’on a un peu survolé le sujet, notamment sur les canaux de communications: quid des newsletters, des vidéos tutos, des patch-notes etc…?

13

Du coup, je viens vous embêter en live demain ou pas ? :smiley: @const @jplambert

1 « J'aime »
14

Mais bien sûr que tu viens !!!

15

J’exagère un peu ou pas? :wink:

« A user interface is like a joke. If you have to explain it, it’s not that good. » (Martin Leblanc)

(4h plus tard : Arf, je viens de voir l’extrait de la vidéo avec la citation… )

16

Oui dans la plupart des cas. Mais non si on est dans un domaine particulièrement complexe ou que l’on propose des solutions innovantes un petit onboarding ne fait pas de mal.

17

Il existe bien sur des exceptions. Mais même dans le cas d’un « domaine particulièrement complexe », la solution, elle, ne devrait pas être complexe à utiliser (ça devrait justement être une qualité de cette solution). Sachant que souvent, plus le domaine est complexe, plus les utilisateurs sont des experts du domaine. Donc je dirai que plus le domaine métier est complexe, plus la solution devrait parler le langage métier, et chercher à rendre l’information et les actions simples et claires. C’est souvent parce que la solution n’est pas alignée sur le domaine et ses concepts qu’elle doit être expliquée aux utilisateurs du domaine.