Gestioneu les aprovacions de les parts interessades a Jira: deixeu clar l'estat d'aprovació

"Tothom ha aprovat això?" sembla una simple pregunta de llançament. Es fa més difícil respondre quan una persona va revisar el disseny, una altra va comprovar una compilació anterior i una tercera va dir que "es veu bé" sense explicar què havia examinat.

Una aprovació útil concreta l'acord. Identifica qui revisa el treball, què està revisant i si l'aprova o necessita canvis. També ofereix a l'equip una manera de revisar aquest acord quan canvia el lliurament.

En aquesta guia, utilitzarem les aprovacions i les aprovacions de les parts interessades de Power Pack per organitzar revisions per a un llançament fictici del portal del client. L'objectiu és fer entenedor l'estat d'aprovació juntament amb el tiquet de Jira, amb prou context perquè la següent persona actuï.

Separa les ressenyes que responen a diferents preguntes

El nostre equip del portal de clients està preparant nous controls de preferències de correu electrònic. Maya és la responsablea del producte, Leo és l'enginyer, Priya lidera les proves i Sam prepara el suport. El llançament necessita diversos tipus de revisió, però aquestes ressenyes no responen totes a la mateixa pregunta.

Maya ha de confirmar que el comportament coincideix amb el resultat acordat pel client. Priya revisa les proves de verificació i els buits coneguts. Sam comprova que el suport pot explicar els controls i gestionar preguntes probables. Una única aprovació anomenada "Release ready" ocultaria aquestes diferències.

L'equip tria un tiquet de Jira que descriu el resultat del llançament compartit i l'utilitza com a casa per a aquestes aprovacions. El tema apunta al treball de lliurament i als materials de revisió. Els revisors haurien de poder trobar l'evidència rellevant sense buscar a través de converses no relacionades.

Aquestes són responsabilitats de revisió il·lustratives. Trieu els revisors que tinguin el context adequat per al vostre equip i confirmeu que entenen la sol·licitud. Un títol per si sol no diu a algú quina evidència hauria d'examinar o quina decisió s'espera que prengui.

Escriu un àmbit que sobrevisqui a la conversa

Abans de crear les aprovacions, descriu el candidat al llançament en termes que l'equip pugui reconèixer. En el nostre exemple, la revisió cobreix les preferències de correu electrònic opcionals, l'explicació de correu electrònic essencial i la gestió d'una actualització de preferències fallida. L'equip també identifica la compilació particular i la revisió de la guia de suport que s'està revisant.

A continuació, doneu a cada revisió una breu declaració d'abast. Per estar preparat per a l'assistència, Sam hauria de revisar la guia amb el candidat de llançament esmentat, confirmar l'explicació dels correus electrònics essencials i comprovar la resposta si no s'ha desat. Això és molt més clar que demanar a Sam que aprovi la "documentació".

Incloeu les exclusions rellevants quan eviten malentesos. La revisió de suport no estableix que la implementació hagi superat totes les proves. La revisió de verificació no decideix si la redacció del producte compleix la promesa del client prevista. Mantenir les preguntes explícites ajuda la gent a contribuir sense suposar que algú més ho ha cobert tot.

• Anomeneu el candidat de lliurament o llançament que s'està revisant.
• Assenyala les proves i els materials que necessita l'aprovador.
• Indiqueu els criteris que permeten completar la revisió.
• Expliqueu les exclusions significatives o les preguntes restants.
• Acordeu quan cal la decisió mitjançant el procés de planificació normal de l'equip.

Utilitzeu un identificador de compilació, una revisió del document o una altra referència estable quan el vostre equip en tingui un. Aquestes referències ajuden la gent a descriure el que han examinat. No converteixen una descripció d'un tiquet mutable en una còpia conservada del contingut aprovat, així que mantingueu les proves de revisió al lloc adequat.

Creeu aprovacions amb un abast concret a Power Pack

Obriu Power Pack sobre el tiquet de Jira i seleccioneu Vistiplau i aprovacions de les parts interessades. Creeu un punt de revisió per a cada revisió diferent, amb un títol, descripció o abast, categoria i aprovador designat. Els preajustos estàndard del punt de revisió poden proporcionar un punt de partida; editeu els detalls per adaptar-los a la versió real.

Per a aquesta guia, assigneu usuaris reals de Jira com a aprovadors. Confirmeu mitjançant el vostre procés d'accés normal Jira que poden obrir el problema i arribar als materials de revisió. Una entrada que anomena una persona no s'ha de tractar com una invitació o com a prova que la persona té accés.

Mantingueu el conjunt prou petit per entendre-ho d'un cop d'ull. Tres revisions ben definides poden ser més útils que una llarga llista d'aprovacions departamentals amb un abast superposat. Afegiu una altra porta quan respongui a una pregunta diferent que realment necessita resoldre el llançament.

Comproveu que els registres s'han desat abans de demanar als revisors que confiïn en ells. Power Pack manté les aprovacions contra el problema i un estat local o de reintent és diferent de la confirmació que el registre Jira compartit conté els darrers canvis.

Demaneu una decisió amb proves útils

Una sol·licitud d’aprovació hauria d'arribar quan el material estigui llest per revisar. Digues a Maya quin candidat de llançament ha d'examinar, on es descriu el comportament acordat i on trobar les notes de demostració o verificació. Doneu a Sam la revisió de la guia i les pantalles pertinents orientades al client.

El registre fa visible l'estat, mentre que l'equip encara necessita coordinar la revisió. Utilitzeu el vostre procés de comunicació habitual Jira per demanar la decisió i resoldre preguntes. El simple fet d'afegir un punt de revisió no determina que el revisor hagi vist la sol·licitud o hi hagi reservat temps.

A la interfície normal Power Pack, les accions d'aprovació i de sol·licitud de canvi estan disponibles per a l'aprovador Jira assignat; altres usuaris veuen aquests controls d'aprovació desactivats. Això fa que el revisor previst sigui clar durant l'ús diari. Mantingueu qualsevol requisit d'aprovació organitzatiu separat en el vostre procés establert.

Utilitzeu notes per explicar què es va aprovar

Quan el revisor assignat aprova, Power Pack obre un pas de confirmació amb una nota de revisió opcional i registra el temps d'aprovació. Les entrades aprovades mostren la data i l'hora, amb la nota quan es proporciona. Animeu una nota breu que connecti la decisió amb el seu abast.

Per a Maya, una nota útil podria ser: "El candidat del portal 4 revisat contra el comportament de correu electrònic opcional acordat. L'explicació de correu electrònic essencial és clara i el missatge de desat fallat coincideix amb la redacció acordada". Això explica molt més que "Aprovat", tot i que és ràpid de llegir.

Sam podria registrar: "Revisió de la guia d'assistència revisada 3 contra el candidat 4. Les instruccions coincideixen amb els controls visibles, inclosa l'explicació dels missatges essencials". La nota ajuda el coordinador de llançament a entendre quins materials s'han examinat i quina revisió s'ha de revisar després d'un canvi.

No utilitzeu una nota positiva per amagar condicions no resoltes. Si el revisor encara necessita un canvi abans de poder aprovar l'abast indicat, registreu els canvis sol·licitats. Si una limitació és acceptable, descriu-la clarament i assegureu-vos que la persona adequada hagi acceptat continuar amb aquesta limitació.

Feu que les sol·licituds de canvis siguin accionables

Un revisor pot sol·licitar canvis i registrar un motiu. A continuació, el punt de revisió mostra Canvis sol·licitats, fent visible la revisió no resolta. Escriu el motiu com una cosa que l'equip pot abordar i portar-lo per a una altra decisió.

Suposem que Sam troba que la guia diu que els clients poden aturar tots els correus electrònics del compte. Enregistra: "Actualitzeu la guia per distingir els correus electrònics opcionals dels missatges essencials del compte i, a continuació, comproveu la captura de pantalla d'exemple amb el candidat 4". La sol·licitud identifica tant el problema com el seguiment previst.

L'equip gestiona l'edició real mitjançant el seu procés de lliurament. Si el canvi necessita una tasca Jira, creeu o actualitzeu aquesta tasca per separat i feu que el context de revisió sigui fàcil de seguir. L'estat d’aprovació comunica la posició del revisor; no assigna el treball corrector per si mateix.

Quan el treball estigui llest, demaneu a l'aprovador designat que l'examini de nou. A partir de Canvis sol·licitats, el revisor pot aprovar mitjançant el pas normal de confirmació quan la correcció compleixi l'abast acordat. Una edició completada i una revisió aprovada són esdeveniments separats; el primer no és un substitut automàtic del segon.

Torneu a comprovar les aprovacions després de canvis materials

Després que la Maya aprovi el candidat 4, Leo canvia la interacció desa al candidat 5. La nova versió pot ser una millora, però la nota anterior de la Maya descriu un candidat diferent. L'equip ha de decidir deliberadament quins àmbits de revisió es veuen afectats.

En aquest cas, el comportament del producte i les revisions de verificació necessiten una altra mirada. Sam també hauria de comprovar si les instruccions de suport encara coincideixen. Un petit canvi intern podria afectar menys ressenyes; un canvi visible per al client pot creuar diversos àmbits. Feu aquesta avaluació en funció del canvi en si.

Power Pack proporciona un avís de canvis des de l'aprovació i controls de reaprovació. Tracteu un advertiment com una indicació per revisar l'abast de nou. Torneu a comprovar de manera independent les aprovacions després de canvis importants, perquè una advertència no és una explicació completa del que ha canviat o quina decisió de les parts interessades segueix sent aplicable.

En sol·licitar una nova aprovació, el punt de revisió torna a Aprovació pendent. Aleshores, el revisor pot examinar el material actualitzat i registrar una nova decisió. Si l'aprovador retira la seva aprovació, el punt de revisió també torna a estar pendent. Mantenir actualitzada la referència de la revisió perquè la següent decisió tingui una base comprensible.

Llegeix els estats abans de prendre la decisió de llançament

A la revisió del llançament, escanegeu els punts de revisió individuals i llegiu-ne l'abast i les notes. L’aprovació pendent significa que encara cal una decisió. Canvis sol·licitats significa que el revisor ha identificat el treball per abordar. Aprovat registra una decisió positiva per a la revisió descrita.

Un resum totalment aprovat és una visualització convenient dels estats registrats. El coordinador de llançament encara ha de confirmar que les aprovacions s'apliquen als lliuraments actuals i que es compleixen altres requisits de llançament. Les proves de proves, les regles de flux de treball Jira i els controls de desplegament segueixen sent parts separades del procés.

Per al nostre equip del portal, el resultat útil és una conversa clara: Maya va aprovar el comportament actual, Priya va revisar les proves rellevants i Sam va confirmar les instruccions de suport actuals. Quan la feina canvia, tothom sap la revisió de qui tornarà a revisar.

Comenceu amb un tiquet de Jira i unes quantes aprovacions significatives. Definiu el seu abast, nomeneu els aprovadors i feu que les proves siguin fàcils de trobar. Power Pack pot mantenir visibles les decisions resultants, mentre que l'equip manté la connexió entre cada aprovació i el treball que realment cobreix.