Hello, une petite question qui m’est venue suite a un cas professionnel et une idée non liée au boulot.
Admettons, on vous demande de reprendre en tant que PO une application ancienne (disons une dizaine d’année) ayant des utilisateurs et vous ne disposez de quasi aucune doc ou info sur celle ci. L’idée est de conserver une grande partie de la logique de l’existant pour ne pas perturber les utilisateurs mais de refondre l’application pour la réactualiser (techniquement mais aussi simplifier la vie des utilisateurs).
Vous devez donc à la fois récolter des informations sur l’existant tout en commençant les premières modifications.
Comment procédez vous ? Et tant qu’on y est, quel framework aurait votre préférence dans cette situation ? Scrum, Kanban, autre ?
Existe-t-il des remontées d’utilisateurs ?
Est-ce qu’il y a des connaissances de l’appli au sein de l’équipe ?
La vérité est dans le code, je m’entends souvent dire.
Alors, si j’étais hypothétiquement PO, et ayant accompagné auparavant un PO/PM pour un contexte très proche :
Je challengerais tout de suite l’hypothèse « conserver une grande partie de la logique de l’existant ». Si l’outil a une 10aine d’années, le monde change, les habitudes parfois, et donc…
J’irai interviewer les utilisateurs et voir ce qui a de la valeur sur l’outil, et ce qui n’en a pas. Commencer par de la discovery d’abord. L’important est d’avoir le parcours « théorique » (celui de l’application) et le parcours « réel » (ce que les utilisateurs font réellement). Pour le coup, il me faudra un product designer avec moi pour m’aider. Avant même de faire des premières modif, vaut mieux prendre un petit peu de temps pour bien vérifier tout ça !
« Eat your own dog food », va falloir aussi que je mette les mains dans le cambouis pour mieux comprendre le fonctionnement du produit par moi-même aussi, en pur novice !
Pas de framework préféré, « there is no silver bullet », ça va vraiment dépendre du quotidien. A priori pour quelque chose comme ça, commencer avec Scrum n’est pas déconnant, mais avec une bonne dose d’eXtreme programming si les devs sont chauds.
Entièrement d’accord avec toi et si je dis conserver une grande partie de la logique de l’existant, ca n’est pas tant sur le parcours que sur la logique qu’il y a derrière (l’outil auquel je pense est grosso modo un agenda)
Mon questionnement est plus sur le « comment commencer rapidement un premier sprint alors qu’on ne sait pas comment ça marche » que sur l’approche « Remise en question de l’existant/redesign »
Si je pars du principe que je prends le temps de récolter des informations tant en terme d’utilisateur que d’un point de vue technique (retrouver les règles fonctionnelles mises dans l’appli pour savoir si elle font encore sens ou non), j’ai l’impression qu’on part dans une longue phase d’analyse/recherche et qu’on se crée un effet tunnel immédiatement. Est ce qu’il y a un moyen d’éviter cela et de se lancer rapidement - il y aura forcément une phase de recueil pour alimenter de quoi lancer un premier sprint - pour commencer a avoir de premier incrément pendant qu’on récolte plus de feedback utilisateurs, qu’on challenge/épluche l’existant, qu’on crée un nouveau parcours utilisateurs, etc
Personnellement je ferai un premier sprint « statistique d’utilisation » ou quelque chose comme ca pour demander au devs de mettre en place une mesure objective de l’utilisation au mieux qu’il peuvent. (page, bouton, nb vue, nb click … eventuellement 10 plus gros utilisateur par page, 10 plus petit pour pouvoir aller leur parler )
Est-ce qu’il y a un moyen d’éviter cela ? Oui.
Est-ce que c’est une bonne idée ? Je ne sais pas… Attention au « build trap », vouloir absolument un incrément sans réfléchir et juste créer pour créer.
Le discovery, c’est plus long qu’on le croit.
Ma raison pour ne pas se lancer trop vite : le modèle Cynefin aide pas mal là-dessus. En regardant ton cas, parmi les 5 états « Simple » « Compliqué » « Complexe » « Chaos » « Désordre », où se place-t-on ?
Spoiler
De mon point de vue, on est dans le désordre. D’où le fait d’abord d’expliciter le problème avant de se lancer tête baisser. J’irais voir les devs, leur en parler, et de voir comment ils peuvent aider sans forcément « faire du dev » !
Je me pose encore des questions sur a quel point pousser la redécouverte de l’existant sans tomber dans l’effet tunnel de l’analyse complète qui risque en plus de paralyser ma créativité car les parties prenantes pourraient tomber dans le piege du « on veut tout pareil »
Mais le retour de Benjamin sur le fait de ne pas tomber dans le built trap, je n’y avais pas songé
J’ai envie de dire, toutes les manières de découvrir des pistes pour créer de la valeur sont envisageable du moment que c’est par le retour utilisateur qu’on confirme l’hypothèse… Mais bon ca c’est la version idéaliste. On peut dire … du moment que c’est par l’afflux d’oseille généré qu’on confirme l’hypothèse.
Et jeudi, comme tous les jeudi, il y a le Live hebdo de Scrum Life.
Viens participer au Live ! Jeudi 24 novembre 2022 à 13:00 CET.
De quoi parle-t-on ?
On « fait monter sur scène » les membres de la communauté pour qu’ils prennent directement la parole dans le Live, plutôt que de juste échanger via le chat. Alors viens ! La communauté, c’est toi !
