Afin de fournir une valeur, l’Incrément doit être utilisable
Je deviens fou, je me parle à moi-même.
Je me permet d’exprimer brutalement mon raisonnement ci-dessous.
Résumé
L’organisation développe un produit pour obtenir des revenues, de la notoriété.
Ceux-ci dépendent de ses clients.
Le flux de travail doit être orienté vers le client qui tire la demande (c’est-à-dire ce qui a de la valeur pour lui).
On adapte notre produit afin de maximiser l’apport de valeur que l’on formalise sous forme de problèmes à régler et d’objectif produit à atteindre.
On émet des hypothèses, l’adaptation se concrétise par un incrément.
L’incrément doit être utilisable par le client pour lui apporter de la valeur (ce qui aura un impact sur l’organisation).
Le client est satisfait s’il a ce qu’il veut, quand il veut, où il veut avec une très grande qualité.
Pour être utilisée, l’incrément doit répondre aux critères du client.
Que l’on découvrira que s’il est utilisable.
Finalement, si le client veut un mokup, alors je lui met à disposition, s’il veut une fonctionnalité je lui livre… La question n’est pas tant de livrer ou pas mais que l’on identifie ce que souhaite le client.
Après 1h de réflexion, …
Pour être utilisable, l’incrément doit être là où le client le souhaite.
En fonction de la demande du client, ce sera à disposition, ou livrer, …
Pour aller plus loin dans la réflexion, ce qui me déplaît dans la ‹ mise à disposition ›, c’est ce qui se cache derrière, à savoir une absence d’action de la part du partie qui livre. Dans le cas d’une maquette, le travail ne PEUX PAS s’arrêter là.
Clairement… si. La mesure n’est pas une condition sine qua none pour qu’un produit soit vendable. Est-ce que la stratégie commerciale qui en découle est viable ? Probablement pas. Mais la finalité d’un produit est d’être vendu. (Je grossis le trait, c’est un peu plus compliqué en vrai, mais par soucis de brièveté je m’en tiendrais à ça). Si tu vends des bananes, tu vas pas tester chaque banane que tu vends.
Cette question est plus complexe qu’elle en a l’air, et dépend des retours que tu vas pouvoir en tirer.
Il se peut qu’une maquette soit suffisante pour déterminer un layout de page. Elle ne te dira pas pour autant si le process que tu cherches à changer sera impacté positivement ou négativement. On est presque sur une analogie Test Unitaire vs Test UX (plus loin que le E2E) pour le coup.
Du coup, ce serait présomptueux de se dire qu’une maquette suffira a affirmer que le problème est identifié et résolu. Pour autant, elle est un artefact appartenant clairement au domaine de la solution. Qu’est ce qu’on peut en déduire ? Simplement que les voyages d’un espace à un autre peuvent et doivent être fréquents, et qu’il est donc contreproductif de les voir comme deux temporalités distinctes. Pour utiliser une image un peu fumeuse, ce sont deux pièces d’une même maison où on fait deux choses différentes mais qui sont l’une à coté de l’autre. Libre à nous d’écouter ce qui se passe à côté, où de n’en avoir rien à carrer.
Et ensuite on passe, pour moi, à une autre étape du processus.
Tu proposes un incrément, le client en dispose et tu analyses le résultat que tu partages en review.
L’objectif de la Sprint Review est d’inspecter le résultat et de déterminer les adaptations futures
La boucle est faite. En fait cela ne s’arrête jamais (tant qu’il n’y a pas d’évènement qui rendrait le produit obsolète. )
Mais là, il me semble que nous partons dans un nouveau sujet !
)