Executeu un pre-mortem a Jira: cerqueu riscos de llançament abans que passin

Un llançament pot semblar preparat a Jira mentre l'equip encara té preocupacions que ningú no hagi escrit. La implementació està gairebé acabada, les proves estan en curs i la data de llançament s'acosta. Algú sospita que els comptes de clients antics es comporten de manera diferent. Algú més es preocupa que l'assistència expliqui els nous controls de manera incorrecta.

Una anàlisi premortem proporciona a aquestes preocupacions un punt de partida útil: imagineu-vos que el llançament ja ha anat malament i, a continuació, descriu què el va causar. L'exercici facilita la discussió de fallades plausibles abans que l'equip s'ocupi de respondre-hi.

En aquesta guia, realitzarem un pre-mortem pràctic per a un llançament de portal de client fictici i organitzarem els resultats a la graella de risc i pre-mortem de Power Pack. El resultat és un conjunt breu de riscos amb responsables clars, senyals d'advertència i treballs de mitigació.

Trieu un resultat de llançament específic

El nostre equip està afegint preferències de correu electrònic a un portal de clients. Els clients podran activar o desactivar els correus electrònics opcionals del compte mentre continuen rebent missatges essencials. La Maya és la responsable del producte, Leo implementa el canvi, Priya lidera les proves i Sam prepara el suport.

Trien el tiquet de Jira que descriu el resultat de el llançament compartit com a casa de la seva pre-mortem. Els tiquets d'implementació i de prova relacionats romanen vinculats mitjançant el seu procés normal Jira. Mantenir la discussió al costat del tiquet del llançament ofereix a la gent un lloc evident per revisar-la.

Abans de la sessió, Maya escriu una declaració d'abast senzilla: reviseu l'experiència del client, el comportament del correu electrònic i la preparació del suport per al primer llançament dels controls de preferències. L'equip considerarà el llançament i la seva primera setmana d'ús. Aquest límit evita que la discussió es converteixi en una revisió de tots els possibles problemes del portal.

Imagineu un fracàs abans de discutir solucions

Comenceu amb una indicació concreta: "És una setmana després del llançament. Els clients estan confosos, les sol·licituds d'assistència han augmentat i hem hagut d'aturar el llançament. Què va passar?" El resultat imaginat hauria de ser prou incòmode per impulsar el pensament sense implicar que el fracàs és inevitable.

Doneu a tothom uns minuts tranquils per escriure de manera independent les possibles causes. Això permet que la preocupació d'un verificador o una observació de suport entri a la discussió abans que la primera explicació confiada prengui el relleu. Demaneu causes que la gent pugui descriure, en lloc de declaracions generals com ara "la qualitat era deficient".

A continuació, compartiu els escenaris al seu torn. Durant aquesta primera passada, recull la preocupació i aclareix el seu significat. Guarda arguments sobre la millor solució per a més endavant. Un participant hauria de ser capaç de plantejar una possibilitat incòmoda sense haver de defensar immediatament un pla de reparació complet.

• Els clients existents veuen preferències que no coincideixen amb la seva configuració de correu electrònic actual.
• La interfície suggereix que els correus electrònics essencials es poden desactivar.
• Les instruccions d'assistència descriuen els controls que van canviar abans del llançament.
• L'actualització de preferències sembla correcta fins i tot quan falla el canvi subjacent.

Aquests són escenaris de ficció per al nostre exemple. La vostra pròpia llista hauria de provenir de les persones que entenguin el treball, les dependències i l'experiència del client. Power Pack enregistra la discussió; l'equip dóna el judici sobre què pot passar.

Converteix les preocupacions en declaracions de risc reconeixibles

Un risc útil descriu un possible esdeveniment i les seves conseqüències. "La migració" és un tema. "Els valors de preferències existents s'assignen incorrectament, de manera que alguns clients reben correus electrònics opcionals que esperaven que s'aturin" és un escenari que la gent pot investigar.

Combina els duplicats sense perdre conseqüències diferents. Diverses preocupacions sobre els comptes antics poden compartir una causa subjacent. Una etiqueta enganyosa i un desament fallit poden confondre els clients, però necessiten comprovacions diferents i normalment haurien de ser riscos separats.

Per a cada escenari, pregunteu què notaria l'equip abans d'hora. Un disparador d'alerta primerenca és un signe observable que mereix atenció. En el nostre exemple, un desajust entre la configuració del compte existent i els valors migrats proposats és més útil que "els clients poden queixar-se". Es pot comprovar abans del llançament.

Acordeu el que significa la probabilitat i l'impacte

Power Pack ofereix una matriu de 3×3 o 5×5 i calcula una puntuació de gravetat multiplicant la probabilitat per l'impacte. Utilitzeu aquesta puntuació per donar suport a la discussió i la classificació. És una avaluació subjectiva, no una predicció de la freqüència amb què es produirà una fallada o un càlcul de la pèrdua esperada.

Per a una primera sessió, el nostre equip tria 3×3 i acorda significats senzills per a les puntuacions. La probabilitat d'un significa que actualment veuen poques proves de suport; dos significa que l'escenari és plausible i necessita investigació; tres significa que hi ha raons sòlides per esperar-ho sense acció. Aquestes són les definicions de treball de l'equip.

Defineixen l'impacte al voltant del client i alliberen conseqüències. Un significa un inconvenient limitat, dos significa una interrupció significativa que requereix un seguiment i tres significa un problema greu del client o un motiu per aturar el llançament. Un altre equip podria necessitar definicions diferents per al seu propi entorn.

Priya considera la migració incorrecta com a probabilitat dos i impacte tres, donant una puntuació de sis. L'equip discuteix els supòsits que hi ha darrere d'aquesta qualificació: el nou mapeig encara no s'ha assajat amb comptes més antics representatius. Les proves que falten són més importants que l'aparent precisió del nombre.

Mantingueu la mateixa escala mentre compareu els riscos inicials. Si canvieu entre les mides de la matriu, es reescala les classificacions existents, així que reviseu les posicions resultants si canvieu la resolució. Una nova posició no s'ha de confondre amb proves recentment descobertes sobre el llançament.

Afegiu els riscos a Power Pack

Obriu Power Pack al tiquet de Jira escollit i seleccioneu Risk & Pre-Mortem Grid. Utilitzeu el mapa de calor per veure la distribució de les qualificacions i el registre de riscos per revisar les entrades. Podeu afegir un risc d'una cel·la de matriu quan ja coneixeu la seva probabilitat i impacte inicials.

Per a cada entrada, anoteu el títol, l'escenari d'error, l'activador d'alerta primerenca i la categoria. Afegiu les qualificacions acordades, un pla de mitigació i un responsable. Power Pack també admet els punts de control de mitigació, l'estat i una referència opcional del tiquet de Jira.

El responsable pot ser un usuari de Jira o un registre d'una persona externa. Trieu algú que coordini la resposta i torni les proves que falten a l'equip. Anomenar aquesta persona a la graella no crea una tasca Jira, no assigna una tasca existent ni proporciona accés al problema.

Reviseu l'estat de desat abans de tractar la graella actualitzada com a compartida. Els canvis s'emmagatzemen en funció del tiquet, i un estat local o de reintent no s'ha de llegir com a confirmació que un altre company d'equip ja pot veure l'última entrada.

Doneu a cada risc important una resposta pràctica

"Provar a fons" és difícil de seguir. Pel que fa al risc de migració, Priya proposa un assaig amb estats representatius dels comptes existents, seguit d'una comparació de les preferències resultants i del comportament esperat del correu electrònic. Leo investigarà qualsevol desajust. Priya segueix sent el responsable del risc i porta el resultat a la revisió del llançament.

Dividiu la resposta en punts de control que facin visible el progrés. L'equip pot seleccionar casos representatius, executar l'assaig, revisar els desajustos i registrar la incertesa restant. Els punts de control ajuden a organitzar la resposta, mentre que l'evidència real es manté en el treball de prova o lliurament pertinent.

Si la mitigació necessita el seu propi tiquet Jira, creeu-lo i assigneu-lo mitjançant el flux de treball normal de Jira i, a continuació, afegiu-ne la clau com a referència del risc. Una referència facilita el seguiment de la relació; no crea automàticament la feina ni gestiona el seu lliurament.

Revisar l'estat quan canvien les proves

Power Pack proporciona els estats Identificat, En curs, Mitigat i Acceptat. Utilitzeu Identificat quan s'ha capturat l'escenari i En curs quan algú està treballant activament en la resposta. Acordeu quina evidència espera l'equip abans de descriure un risc com a mitig.

Acceptat pot descriure una decisió conscient de continuar amb una exposició restant. Per exemple, la Maya pot acceptar una petita bretxa de documentació de suport després que Sam confirmi que hi ha una resposta temporal disponible. Anoteu el raonament i reviseu-lo si canvien els supòsits. L'acceptació ha de ser una decisió entesa, no una manera d'ordenar la graella.

A la revisió del llançament, pregunteu als responsables sobre els activadors d'advertència, els resultats de mitigació i la incertesa restant. Reviseu de manera independent qualsevol canvi d'abast material, nova dependència o resultat de la prova inesperat. Actualitzeu les puntuacions quan l'evidència ho justifiqui i expliqueu per què ha canviat l'avaluació.

Podeu exportar la graella com a Markdown o CSV per a una discussió de planificació. Identifiqueu el tiquet de Jira com el lloc per comprovar el registre actual. Una exportació compartida és una instantània i és possible que ja no reflecteixi l'última avaluació de l'equip.

Utilitzeu la sessió per canviar el que passa a continuació

Una graella completa és útil quan influeix en la preparació. Per al nostre equip del portal, l'anàlisi premortem porta a un assaig de migració, una redacció més clara i una comprovació que la guia d'assistència coincideix amb el candidat de llançament. Cada acció aborda un escenari de fallada específic plantejat per les persones que fan el treball.

Comenceu amb una versió, una breu discussió facilitada i un petit conjunt de riscos significatius. Utilitzeu Power Pack per mantenir visibles els escenaris, els responsables i les respostes al costat del tiquet de Jira. A continuació, torneu a portar el registre a la propera conversa de llançament, on l'equip pot avaluar què ha canviat realment.