Processus de décision Go/No-Go : arbre de décision de préparation au lancement
Un modèle d'arbre de décision go/no-go pour la préparation au lancement : qui répond à chaque question et les branches à démarrer, les résultats conditionnels, les pilotes, les non-départ et les abandons.
Qu'est-ce que le processus processus de décision go/no-go : arbre de décision de préparation au lancement ?
Une décision go/no-go n’est pas une étape dans un flux de travail, c’est un jugement. Au moment où une version atteint la porte de préparation, le travail est terminé ; il ne reste plus qu’à tester les preuves par rapport à des critères convenus à l’avance et à dire, à haute voix et officiellement, lequel des résultats annoncés s’applique. La plupart des équipes ont les questions quelque part (dans une liste de contrôle, un runbook, une invitation récurrente à une réunion), mais elles sont rarement écrites sous forme d'arbre, de sorte que personne ne peut voir quelle réponse mène où, quelle question est un arrêt difficile et laquelle attache simplement une condition, ou qui est réellement autorisé à répondre à chacune.
Cette page est délibérément un arbre de décision plutôt qu'une cartographie des processus. Une cartographie des processus répond à « ce qui se passe ensuite et qui le fait » : tâches en séquence, transferts entre équipes, un chemin principal avec des exceptions qui y sont suspendues. Un arbre de décision répond « quelle option choisissons-nous et qui décide » : une série de questions, chacune pouvant être répondue à partir de preuves, avec des branches étiquetées par la réponse plutôt que par la tâche suivante, se terminant par des résultats nommés distincts. Si vous souhaitez que le flux de bout en bout autour de cette porte (gel de la portée, construction et test, préparation et UAT, déploiement, tests de fumée et surveillance), utilisez l'organigramme du processus de publication du logiciel sur /fr/templates/organigramme-du-processus-de-publication-du-logiciel. Cette page est la vue agrandie de la décision unique qui s’y trouve.
L'arborescence ci-dessous comporte douze questions réparties en quatre étapes d'évaluation, les couloirs nommant qui répond plutôt que cartographiant les services : responsable des versions, ingénierie et assurance qualité, opérations et support, et sponsor exécutif. Cela se termine par six résultats distincts (partir, partir avec des conditions nommées, un passage limité à un groupe pilote, non-partir parce que les critères d'acceptation n'ont pas été remplis, non-partir avec une date reprogrammée et abandonner) parce qu'un examen qui ne peut dire que oui ou non force toute préparation partielle à l'une des deux mauvaises réponses. Les deux sorties interdites sont délibérément séparées : échouer à la première porte sur des critères non satisfaits est un résultat différent de celui d'effacer la qualité et de perdre la fenêtre de changement.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre voies de décision plutôt qu'une carte de département : responsable des versions, ingénierie et assurance qualité, opérations et support, et sponsor exécutif, réparties en quatre étapes : examen des preuves, contrôle de la qualité, contrôle opérationnel, et décision et résultat.
- La branche des critères d'acceptation : « Les critères d'acceptation sont tous remplis ? répond Met ou Gaps, et Gaps est dirigé vers « Les lacunes peuvent-elles être levées ?
- La branche seuil de défaut : « Défauts dans les seuils de gravité ? » répond À l'intérieur ou Au-dessus, avec Au-dessus acheminé vers « Correction ou renonciation acceptée ? » ainsi, une sortie au-delà du seuil ne repose que sur un accord enregistré, et non sur un optimisme.
- Deux questions de préparation qui peuvent survivre à une réponse partielle : « Dépendances et fournisseurs prêts ? » passe à « Pouvons-nous expédier sans eux ? » et « Rollback testé avec succès ? passe à « Le changement est-il réversible ? », où un Non est la seule voie à suivre pour abandonner plutôt que pour reprogrammer une date.
- Support et calendrier sous forme de portes dures distinctes : « Support formé et doté en personnel ? » et "**Changer de fenêtre** et le calendrier sont-ils effacés ?" chaque réponse directe à "Non prêt" ou "Affrontement", gardant la préparation opérationnelle hors de la conversation d'ingénierie.
- Une paire de décisions finales qui nomment le résultat : « Approbation de l'exécutif donnée ? (Signé ou Retenu) puis "Quelle portée est autorisée ?", branchant Complet, Conditionnel et Pilote uniquement en trois points de terminaison distincts aux côtés des terminateurs d'interdiction et d'abandon.
Quand utiliser ce modèle
- Vous organisez un examen de préparation ou de lancement et les critères sont gravés dans la tête des gens. Le résultat dépend donc de qui est présent dans la salle et de la façon dont la semaine s'est déroulée.
- Vos avis ne produisent que des « départs » ou des « retards », et une préparation partielle (un fournisseur en retard, une rotation de support mince) n'a nulle part où atterrir, sauf un arrêt complet ou un pari non enregistré.
- Vous devez régler les droits de décision avant que la prochaine version ne force le débat : qui peut renoncer à un critère d'acceptation, qui peut accepter un défaut dépassant le seuil et dont l'approbation est requise.
- Vous documentez la manière dont les modifications sont autorisées, testées et approuvées pour un audit ou un questionnaire de sécurité client, et devez montrer les critères ainsi que l'approbation.
- Vous effectuez une révision post-incident d'une version qui n'aurait pas dû être livrée et souhaitez que la discussion porte sur la question qui a été ignorée plutôt que sur une reconstruction de mémoire.
Comment cela fonctionne
Renommez les voies selon vos véritables droits de décision
Remplacez le responsable des versions, l'ingénierie et l'assurance qualité, les opérations et le support et le sponsor exécutif par les rôles qui détiennent véritablement la réponse dans votre organisation. Gardez les voies réservées à celui qui répond, et non à qui est impliqué : si trois équipes apportent des preuves à une question mais qu'une personne en décide, cette question se trouve dans la voie décisive. Fusionnez toutes les voies dans lesquelles vous ne pouvez pas nommer une personne ou un rôle spécifique.
Notez les seuils avant d’en avoir besoin
La qualité de l’arbre dépend de ses tests. Dans « Défauts dans les seuils de gravité ? », enregistrez la limite par gravité pour la portée publiée, qui peut ignorer une violation et si le décompte inclut les problèmes connus provenant de versions antérieures. Faites de même pour « Les critères d'acceptation sont tous remplis ? » en marquant chaque critère comme obligatoire ou souhaitable lors du gel du périmètre, afin que le portail ne soit pas renégocié le jour même.
Définir ce que signifie une restauration testée
« Rollback testé avec succès ? » devrait signifier répété dans un environnement de type production, chronométré, avec une personne nommée capable de l'exécuter et un déclencheur écrit pour l'appeler. Notez explicitement la question sur les données, car un changement de schéma ou de migration est souvent ce qui transforme la réponse en « Le changement est-il réversible ? » en Non, et cette branche est la seule voie pour abandonner.
Rendre réels les résultats conditionnels et pilotes
Un passage conditionnel n'est différent d'un passage simple que si chaque condition comporte un propriétaire nommé, une date d'échéance et une conséquence déclarée en cas de non-respect. Un projet pilote nécessite de définir sa cohorte, de rédiger le pourcentage d'exposition ou la liste de clients et le critère d'élargissement. Ajoutez les deux au champ de commentaire sur « Quelle portée est autorisée ? » l’examen ne peut donc pas se terminer sur un signe de tête sans réserve.
Séparer le refus de l'abandon
No-go signifie que la même version sera expédiée plus tard, elle nécessite donc une date reprogrammée et un bloqueur nommé avant la clôture de la réunion. Abandonner signifie que la version est retirée et que la portée est retravaillée ou reconsidérée. En les conservant comme points de terminaison distincts, vous évitez qu’un véritable abandon soit enregistré comme un délai de deux semaines qui se répète silencieusement.
Publiez-le, puis relisez-le après chaque porte
Partagez l'arbre où l'examen a réellement lieu, avec le dossier de preuves, et obtenez l'approbation des personnes nommées dans les couloirs. Après chaque publication, vérifiez si une question a reçu une réponse sans preuve et s'il manque un résultat dont vous aviez besoin. Conservez les versions antérieures afin de pouvoir indiquer quand les critères ont changé et pourquoi.
Questions fréquentes
Quelle est la différence entre un arbre de décision go/no-go et une cartographie du processus de publication ?
Une cartographie du processus de publication répond à « ce qui se passe ensuite et qui le fait ». Il affiche les tâches en séquence sur les couloirs (gel de la portée, construction, test, déploiement, surveillance) et traite l'appel go/no-go comme un nœud unique. Un arbre de décision répond « quelle option choisissons-nous et qui décide ». Sa colonne vertébrale est une chaîne de questions plutôt que de tâches, ses branches sont étiquetées avec des réponses telles que atteint, ci-dessus, renonçable ou retenu plutôt qu'avec l'activité suivante, et elle se termine par plusieurs résultats distincts au lieu de revenir sur un chemin heureux. Utilisez les deux : la cartographie des processus pour le flux de bout en bout, sur /fr/templates/organigramme-du-processus-de-publication-du-logiciel, et cette arborescence pour la porte à l'intérieur.
Quelles questions doivent être posées lors d’une décision de go/no-go ?
Sept couvrent la plupart des lancements. Tous les critères d’acceptation obligatoires sont-ils remplis ? Les défauts ouverts se situent-ils dans les seuils de gravité convenus ? Les dépendances et les tiers sont-ils prêts ? La restauration a-t-elle été testée, pas simplement écrite ? Le support et les opérations sont-ils formés et dotés en personnel pour le volume attendu ? La fenêtre de changement est-elle claire par rapport au calendrier commercial ainsi qu'au calendrier technique ? L’approbation de l’exécutif est-elle en place ? Chacun doit répondre à partir des preuves recueillies avant la réunion, c'est pourquoi l'arbre commence par un ensemble de preuves de préparation plutôt que par la première question.
Qui fait l'appel "Go/No Go" ?
Une personne désignée devrait le présider, généralement le responsable des versions ou le responsable de la production, mais la discipline utile consiste à attribuer chaque question plutôt que la décision dans son ensemble. L'ingénierie et l'assurance qualité répondent aux questions d'acceptation et de défauts, les opérations et le support répondent aux restaurations et à la dotation en personnel, le responsable des versions répond aux dépendances et à la fenêtre de modification, et le sponsor exécutif répond à l'approbation. Ainsi rédigé, le travail du président consiste à gérer l'arbre et à enregistrer les résultats, et non à arbitrer personnellement chaque question. Enregistrer qui a répondu à ce qui compte également à titre de preuve : les cadres de contrôle tels que SOC 2 s'attendent à ce que les changements soient autorisés, testés, approuvés et documentés, et un arbre de décision avec des droits de décision nommés est un moyen simple de le montrer.
Quand un go/no-go doit-il se terminer par un go conditionnel plutôt que par un no-go ?
Lorsque l'élément en suspens ne met pas la version en danger et que quelqu'un en sera propriétaire après le lancement. Un Go conditionnel n'est un résultat réel que si chaque condition a un propriétaire nommé, une date d'échéance et une conséquence déclarée en cas de manquement ; sinon, c'est simple, avec de la paperasse supplémentaire. Évitez tout ce qui pourrait laisser les utilisateurs exposés ou non pris en charge. Dans cet arbre, le blocage des écarts d'acceptation, un défaut de dépassement de seuil non convenu, une dépendance dure sans laquelle vous ne pouvez pas expédier, une fonction de support non prête et une fenêtre de modification se heurtent tous à une date reprogrammée.
Quelle est la différence entre ne pas aller et abandonner ?
No-go signifie que la sortie est différée : la même portée est expédiée à une date reprogrammée une fois le bloqueur résolu. Abandonner signifie qu'il est retiré et que l'oscilloscope revient pour être retravaillé ou reconsidéré, sans date attachée. Les séparer est important car une version qui ne peut pas être annulée du tout, ou une version dans laquelle le sponsor exécutif retient sa signature pour des raisons commerciales, n'attend pas une solution : l'enregistrer comme un retard conduit à la même révision quinze jours plus tard avec les mêmes preuves.
Comment limiter un lancement à un groupe pilote ou canari ?
Traitez-le comme le résultat de la décision, et non comme un compromis trouvé dans la salle. Dans cet arbre, la dernière question, "Quelle portée est autorisée ?", regroupe uniquement les versions Complète, Conditionnelle et Pilote, de sorte qu'une version limitée est délibérément choisie après que chaque question de préparation a reçu une réponse plutôt que comme un moyen d'éviter un non-droit. Avant la revue, définissez ce que signifie un pilote dans votre produit : quelle cohorte ou niveau d'exposition, combien de temps il dure, ce qui est surveillé et le critère qui autorise son élargissement.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus de test d'acceptation par l'utilisateur.
Précède
- Organigramme du processus de test d'acceptation par l'utilisateur — Modèle de processus de test d'acceptation utilisateur pour la portée, les scénarios commerciaux, les données de test protégées, la préparation de l'environnement, les preuves d'exécution, la gravité des défauts, le nouveau test et…