Définition du succès

Analyse agile n’est pas un nouveau concept sous quelque forme que ce soit. Des éléments tels que les boucles de rétroaction et le développement axé sur les processus semblent s’intégrer parfaitement dans le paradigme de l’analyse, du moins sur le papier. Heck, il y a même le Build-Mesure-Apprendre cadre pour le développement continu. Il serait difficile d’affirmer que l’analyse n’a pas de rôle dans quelque chose avec mesure dans le nom!

Cependant, les trois dernières années de travail chez Reaktor, l’une des plus grandes sociétés de technologie agile au monde, m’ont fait découvrir un tout nouvel ensemble de problèmes liés à l’intégration d’un « état d’esprit analytique » dans un flux de travail agile, ou d’un « état d’esprit agile » dans l’analyse processus.

Le nœud du problème est de savoir comment négocier la méthodologie limitée dans le temps d’un sprint avec les paramètres toujours fluctuants et contextuels de monnaie. Pour résumer : il est difficile de mesurer la impacter du travail de développement d’une manière qui établirait une boucle de rétroaction solide.

L’un des principaux éléments qui s’opposent à l’analytique agile est précisément ce qui alimente sprints en général : le Définition de terminé (DoD). Dans Scrum, l’un des frameworks agiles les plus populaires, DoD est essentiellement une liste de contrôle des choses que chaque tâche/fonctionnalité/sprint doit réussir pour que le sprint soit considéré comme un succès. Le DoD a beaucoup de choses qui fonctionnent pour lui :

• C’est négocié par tout le monde dans l’équipe.

• Ce n’est pas monolithique.

• Il est ajusté pour mieux répondre à un contexte commercial en constante évolution.

• Il quantifie le succès du workflow agile.

Dans les messages précédents et les discussions sur le sujet, j’ai recommandé d’ajouter Analytique dans le cadre du DoD dans tout projet de développement. En ayant analytique en tant que mot-clé dans le DoD, l’idée est que lors du développement de fonctionnalités, la question toujours importante de « Devrions-nous mesurer cela ? » serait toujours considéré. “Non” est une réponse parfaitement valable à cette question – cela n’a pas de sens de mesurer tout. Mais ce qui est important, c’est que cette discussion ait lieu en premier lieu.

Toute personne travaillant dans l’analyse peut partager des anecdotes sur des moments où elle a voulu vérifier certaines statistiques d’utilisation à partir des données disponibles, pour découvrir que les balises nécessaires n’ont jamais été déployées pour commencer. En ajustant le DoD, cela peut potentiellement être évité.

Cependant, ayant un Définition de terminé s’est avéré insuffisant pour établir objectifs alimentée et validée par la mesure. Même si un sprint ou une branche de fonctionnalité peut être considéré Fini selon les critères établis dans le DoD, cela ne signifie toujours pas que la fonctionnalité était une Succès.

Faire les bonnes choses contre bien faire les choses

Il est tentant de penser à une équivalence entre quelque chose étant Fini et quelque chose étant complété. Cependant, je soutiens qu’il y a une distinction entre les deux. La première peut être formalisée avec des outils tels que la Definition of Done. La seconde est plus difficile à cerner, car elle nécessite de prendre en compte ce qui est à succès.

Considérez l’histoire suivante dans un backlog :

Implémentez un flux de paiement d’une seule page.

Une fonctionnalité comme celle-ci pourrait avoir une définition très claire de Terminé, et il serait très facile de valider si cette fonctionnalité peut être livrée :

• La couverture des tests a été mise à jour pour inclure le nouveau code.

• Une documentation a été rédigée pour couvrir le fonctionnement de la nouvelle caisse.

• Le déploiement en production est réussi.

• Le nouveau paiement est mesuré dans Google Analytics.

• La nouvelle caisse est déployée auprès de 50% des visiteurs (test A/B).

La nouvelle caisse est Fini lorsqu’il satisfait à ces exigences. Les membres de l’équipe travaillant sur la nouvelle caisse peuvent examiner ces étapes et planifier leur travail en conséquence.

Mais qu’est-ce qui détermine si le nouveau flux de paiement est un Succès? C’est un technique succès une fois déployé en production, mais qu’est-ce qui confirme réellement que la nouvelle caisse apporte une valeur ajoutée à l’organisation ?

Une nouvelle série de critères doit être élaborée à cette fin. Ces critères doivent prendre en compte les éléments suivants :

• Le succès est subjectif. Différentes parties prenantes peuvent avoir des idées différentes sur ce qui est considéré comme un succès.

• Le succès est temporel. Ce qui réussit aujourd’hui ne réussira peut-être pas demain, en particulier dans un paysage commercial en constante évolution.

• Le succès est non binaire. Il n’est pas toujours possible de passer un vrai faux verdict pour le succès d’une fonctionnalité développée. Il y a parfois des variations degrés de succès.

La définition de terminé est un excellent outil, car elle nous guide pour bien faire les choses. Cependant, il n’a pas la portée nécessaire pour nous guider dans la hiérarchisation des tâches à accomplir. Il n’a pas la capacité de déterminer si nous sommes faire les bonnes choses.

UN Définition du succès car l’exemple de ce chapitre pourrait être quelque chose comme :

• Cette migration est réussie pour l’équipe lorsque le flux de paiement a été déployé en production.

• Cette migration est réussie pour le client lorsque le test A/B montre des résultats statistiquement significatifs, la nouvelle caisse augmente les revenus par utilisateur.

• Cette migration est réussie pour l’utilisateur final lorsque le nouveau flux diminue l’abandon de caisse.

Si nous menons cette expérience de pensée à sa conclusion, nous constaterons que achèvement découle de l’union d’une caractéristique étant Fini et une fonctionnalité en cours de réalisation avec succès. Il est possible que ces deux éléments se chevauchent, comme dans le critère de succès pour l’équipe ci-dessus, et il est possible que Succès est impossible à déterminer pour certaines fonctionnalités et certains acteurs particuliers.

Définition du succès

La définition du succès est une série de questions que vous posez lors de la priorisation (toilettage) ou en ajoutant de nouvelles histoires au backlog. Les questions sont :

• Si cette fonctionnalité est développée, qu’est-ce qui détermine s’il s’agit d’un Succès au utilisateur final?

• Si cette fonctionnalité est développée, qu’est-ce qui détermine s’il s’agit d’un Succès au maître d’ouvrage / maître d’ouvrage?

• Si cette fonctionnalité est développée, qu’est-ce qui détermine s’il s’agit d’un Succès au équipe?

En posant ces questions, vous êtes obligé de réfléchir à la impacter de votre travail de projet, pas seulement le résultat. De façon optimale, impacter est quelque chose que vous pouvez mesurer – quelque chose que vous pouvez utiliser des données et des analyses pour valider. Mais c’est parfaitement bien d’établir des critères de succès comme quelque chose de plus éphémère.

Jetons un coup d’œil à quelques exemples.

Dans le premier exemple, il est assez facile d’établir des critères de réussite pour quelque chose ayant un tel potentiel d’impact qu’un nouveau flux de paiement. Nous pouvons déterminer des métriques précises pour le succès, avec des objectifs clairement définis qui doivent être dépassés pour que la fonctionnalité soit un succès.

Une tâche très technique, telle que la migration d’un backend cloud d’un partenaire de service à un autre, peut être plus difficile à aligner sur les critères de réussite. Comment le utilisateur final valider le succès de la migration ? Parfois, il est parfaitement normal de ne pas avoir de réponse pour les trois vecteurs. En fait, ce n’est que lorsque vous ne trouvez pas de critères de réussite pour un Célibataire vector si vous vous inquiétez de la validité de la fonctionnalité en premier lieu.

Le dernier exemple montre que plus d’un des trois vecteurs peuvent partager les mêmes critères de succès. Dans ce cas, la construction d’un tableau de bord marketing améliore la visibilité des efforts marketing, ce qui est bénéfique pour le client aussi bien que l’équipe qui a construit le tableau de bord. Le critère de succès pour l’utilisateur final est là encore difficile à cerner. À « long terme », une plus grande visibilité sur les efforts marketing actuels devrait également se traduire par de meilleures campagnes au profit des utilisateurs finaux.

Succès === Valeur

En fin de compte, nous voulons construire des choses précieuses et à valeur ajoutée. Nous voulons que la valeur du travail de développement soit, à tout le moins, la somme de ses parties. De façon optimale, nous voulons dépasser attentes et créer des fonctionnalités qui collaborent pour produire une valeur inattendue de manière inattendue.

Une chose qui unit les deux courants de achèvement et Succès est évaluer en soi. Une caractéristique peut être considérée fait avec succès s’il produit une plus-value nette pour les parties qui ont un intérêt dans le projet.

Mais évaluer peut être difficile à mesurer. Il peut être défini avec la même terminologie que nous utilisons lorsque nous parlons de micro et macro conversions dans l’analyse. Il y a de la valeur qui peut être directement dérivé du développement d’une fonctionnalité. Typiquement, cela aurait un symbole de devise devant lui. Alors il y a une valeur qui est déduit indirectementgénéralement après un certain temps.

Pour se référer aux exemples précédents dans cet article, nous pourrions dire que le nouveau flux de paiement d’une seule page a valeur directecar nous pouvons mesurer son impact sur les revenus générés par le site par rapport à l’ancien flux de paiement (de préférence dans un test A/B !).

De même, on peut dire que la création d’un nouveau tableau de bord marketing a valeur indirectecar nous espérons qu’en rendant les données plus transparentes, nous pourrons contribuer à la création de meilleures campagnes qui, à terme, augmenteront la valeur de notre processus marketing.

Quelle que soit la façon dont vous l’épinglez, vous devriez toujours être en mesure de décrire de bons critères de réussite en utilisant évaluer comme point focal.

Succès flou

Voici une dernière pensée pour conclure cet article.

Je tiens à souligner que Définition du succès est un outil de communication plutôt qu’un ensemble de critères de validation stricts. Cela n’a tout simplement aucun sens de bloquer le développement en attendant qu’une fonctionnalité produise suffisamment de données utilisables pour déterminer son impact.

Validation du fait qu’une fonctionnalité a été à succès ou non peut prendre beaucoup de temps. Pensez aux efforts d’optimisation des moteurs de recherche, par exemple. Ça pourrait être mois avant que des résultats statistiquement (et intuitivement) significatifs n’apparaissent. Cela n’aurait aucun sens de bloquer le développement d’une nouvelle fonctionnalité critique pendant que vous attendez ces données.

Ainsi, en raison de cette définition floue et multidimensionnelle de Succèsil est tellement plus difficile de déterminer si quelque chose a été à succès que de vérifier si le travail de développement est Fini.

Que faire, alors ?

Bon je réitère : Définition du succès est un outil de communication. C’est une approche qui vous aide à évaluer les tâches de développement en fonction de leur potentiel de valeur. C’est plus important en tant que sujet de discussion qu’en tant que directive qui guide votre travail de développement (comme peut l’être Definition of Done).

Une chose que vous pouvez faire est l’exercice décrit plus haut dans cet article. Réservez du temps pour une session où toute l’équipe examine attentivement le backlog de votre projet. En équipe, essayez de déterminer les critères de réussite pour chaque histoire en attente de développement. Rappelez-vous les trois questions :

1. Si cette fonctionnalité est développée, qu’est-ce qui détermine s’il s’agit d’un Succès au utilisateur final?

2. Si cette fonctionnalité est développée, qu’est-ce qui détermine s’il s’agit d’un Succès au maître d’ouvrage / maître d’ouvrage?

3. Si cette fonctionnalité est développée, qu’est-ce qui détermine s’il s’agit d’un Succès au équipe?

Vous devriez constater que cet exercice à lui seul peut révéler des choses sur les éléments du backlog auxquels vous n’auriez pas pensé auparavant.

Si vous pouvez proposer des indicateurs de réussite quantifiables et mesurables, tant mieux. Assurez-vous que ceux-ci sont mesurés lorsque les fonctionnalités sont déployées et assurez-vous que l’équipe sait comment accéder à ces données.

Je pense que cet exercice est également bon pour la constitution d’équipes. Vous communiquez ensemble, en tant qu’unité, sur la valeur à long terme de votre travail. C’est une excellente occasion de renforcer la motivation, car les critères de réussite clarifient souvent vos objectifs généraux. Vous voulez que le projet soit un Succèségalement, il est donc logique de s’assurer que toutes les tâches décrites dans le backlog contribuent au succès de l’ensemble du projet.

Résumé

Je voulais écrire cet article parce que je pense qu’on en parle beaucoup trop peu évaluer et Succès dans le travail de développement quotidien. Je parie que cela s’applique également aux équipes marketing, et pas seulement aux développeurs. Je parie que cela s’applique aux créateurs d’entreprise, aux relations publiques, au recrutement, aux propriétaires d’entreprise, aux actionnaires, aux communautés et aux lois universelles qui régissent notre existence !

C’est difficile d’en parler Succès car c’est tellement subjectif. Pourtant, je vous demande de déployer un outil conçu pour un usage général, où l’accent est mis sur cette notion subjective de Succès.

Mais je suppose que c’est mon point. Il est subjectif, mais c’est aussi quelque chose auquel vous devez absolument consacrer du temps. La discussion doit également être étendue à toute l’équipe. Toutes les personnes impliquées dans le travail de projet doivent comprendre qu’il existe tout un courant sous-jacent de communication, où les membres de l’équipe réfléchissent activement en termes de valeur et de ce que cela pourrait signifier pour les différentes parties prenantes.

J’ai peut-être vécu dans une bulle, mais il est frappant de constater à quel point le succès quantifiable à long terme est rarement présenté à la discussion dans des contextes agiles. Je comprends tout à fait l’accent mis sur les sprints limités dans le temps, où le succès est le résultat net de plusieurs sprints qui sont tous « faits » et « complets ». Mais je pense que cela ignore le changement dans la dynamique de nombreuses équipes de développement, où les concepteurs, les analystes, les CRO, les SEO, les gestionnaires de médias sociaux, les propriétaires d’entreprise et les directeurs des ventes font désormais également partie du mélange. Considérer le travail de développement comme quelque chose qui n’implique que les développeurs de logiciels est donc la saison dernière.

Ainsi, lorsque ces rôles “plus flous” sont ajoutés au mélange, la discussion autour de choses comme évaluer et Succès doit être étendu pour couvrir d’autres éléments que “couverture de test à 100 %”, “évalué par des pairs” et “code bien écrit”.

Comment cela peut être fait de manière systématique et complète est encore sur la planche à dessin. Mais j’espère que ce concept de Définition du succès sonne vrai – à tout le moins comme sujet de discussion et expérience de pensée, si rien d’autre.

Un grand merci à mes collègues de Reaktor, en particulier Aleksi Lumme, Jaakko Knuutilaet Matias Saarinenpour leur collaboration à l’élaboration de la Définition du succès.