Vezess döntési naplót a Jirában: őrizd meg, miért ezt az utat választottátok

Hat héttel a kiadás után valaki megkérdezi, miért e-mailes értesítést választott a csapat napi összefoglaló helyett. A Jira-feladatok leírják, mi készült el. Egy komment szerint „tervezésen megbeszélve”. Akik emlékeznek, elfoglaltak, és senki sem biztos benne, melyik korlát volt döntő.

A döntési napló ezt a hiányt pótolja. Megtalálható helyen rögzíti a helyzetet, lehetőségeket, választást és következményeket. A Power Pack Decision Log eszközében a bejegyzés a Jira-feladat mellett, az általa magyarázott munkához közel található.

Ez az útmutató egy képzeletbeli ügyfélportál-csapatot követ, amely hasznos bejegyzést ír, összekapcsolja a megvalósítással, majd az ügyféligények változásakor újra előveszi.

Döntsd el, mi érdemel bejegyzést

Nem kell minden beszélgetést rögzíteni. Olyan választásokkal kezdj, amelyeket a jövőbeli kollégák jogosan megkérdezhetnek: megvalósítási megközelítés, függőség, kiadási határ vagy tudatos kompromisszum, amelynek következménye túlnyúlik egy kis feladaton.

Portálcsapatunknál az értesítések kézbesítése ilyen döntés. Az azonnali e-mail alakítja a fejlesztést, tesztelést, ügyfélszolgálati útmutatót és ügyfélelvárásokat. A csapat mérlegelt alternatívákat, és a forgalom növekedésekor várhatóan újragondolja a választást.

Ezzel szemben egy gombfelirat elírásának javításához valószínűleg nem kell saját döntési bejegyzés. A különbség gyakorlati: az indoklás ismerete segítene-e valakinek később fenntartani, módosítani vagy elmagyarázni az eredményt?

Az architekturális döntési feljegyzések, vagyis ADR-ek hasznos mintát adnak. Michael Nygard eredeti cikke rövid bejegyzéseket ír le háttérrel, döntéssel, állapottal és következményekkel; a felváltott döntéseket is megőrzi az újra mutató hivatkozással. A forrás alább található. Példánk ezt az egyszerű elvet alkalmazza egy Jira-megvalósítási döntésre.

Adj egyértelmű helyet a döntésnek

Válaszd azt a Jira-feladatot, amely legjobban képviseli az érintett munkát. A példában a csapat a portálértesítéseket koordináló feladatot használja. Ez már eleve a megvalósításra és tesztelésre irányítja az olvasót.

Mondd el a csapatnak, hol van a bejegyzés. A Power Pack Decision Log egy feladathoz tartozik, ezért alakítsatok ki egyszerű keresési szokást. A koordináló feladat megjegyzése jelezheti, hogy az értesítési döntéseket ott vezetik. Ha külön projektmutatót használtok, a szokásos folyamatban oda is vedd fel a feladatot.

Ne szórj szét másolatokat több feladat között azzal, hogy majd összhangban maradnak. A többi feladat a kiválasztott helyre irányíthat. Az exportált másolat hasznos a megbeszéléshez, de legyen világos, hol található a jelenlegi álláspont.

A következtetés előtt írd le a hátteret

A háttér megmagyarázza, miért merült fel a kérdés. Különböztesse meg a tényeket, korlátokat és feltételezéseket, hogy a későbbi olvasó lássa, melyik változott.

A portálcsapat ezt írja: „Az ügyfeleknek tudniuk kell a támogatási kérés érdemi változásáról. A jelenlegi szolgáltatás már küld e-mailt. Az első portálkiadásban nincs postaláda. A legtöbb kérésnél kevés ügyfél számára látható állapotváltozásra számítunk, de a bevezetés utáni értesítési mennyiséget még nem mértük.”

Ez hasznosabb, mint az „e-mail a legegyszerűbb”. Elmagyarázza a kiindulást és láthatóvá tesz egy feltételezést. Nem állítja azt sem, hogy mindig az e-mail lesz a helyes csatorna.

Szükség szerint hivatkozz az alátámasztó vizsgálatra. Ha műszaki próba befolyásolta a döntést, nevezd meg az eredményeit tartalmazó Jira-feladatot. Ha az ügyfél-visszajelzés számít, foglald össze a releváns mintát személyes adatok szükségtelen bemásolása nélkül.

A háttér alapján egy új kolléga értse meg a helyzetet teljes értekezlet-rekonstrukció nélkül. A választást befolyásoló részleteket tartsd meg, a nem kapcsolódó beszélgetést hagyd eredeti helyén.

Valódi alternatívákat hasonlíts össze

A hasznos feljegyzés azt is megmutatja, mit tehetett volna a csapat. Sorold fel a komolyan mérlegelt lehetőségeket, mindegyikhez őszinte előnyt és hátrányt adva.

Ezek a képzeletbeli rendszer szemléltető értékelései. Más csapatnak már lehet postaládája vagy összefoglaló-szolgáltatása, ami teljesen megváltoztatja az összevetést. A jó döntési leírás láthatóvá teszi ezt a kontextusfüggést.

Ne gyengítsd mesterségesen az elvetett lehetőségeket, hogy a választott elkerülhetetlennek tűnjön. Az összefoglaló valós előnye a kevesebb külön üzenet. Erre a kiadásra azért vetik el, mert a jelenlegi feltételezések mellett a gyorsaság és a fejlesztési terjedelem fontosabb.

Az opciót is különböztesd meg az önálló döntéstől. Például külön vizsgálat kellhet ahhoz, hogy az ügyfél teljes üzenete szerepeljen-e az e-mailben. Minden értesítési kérdést egy bejegyzésbe sűríteni megnehezíti a tényleges megállapodás megértését.

Mondd ki a választást és következményeit

Teljes mondatban írd a döntést: „A portál első kiadásában e-mailt küldünk, ha egy támogatási kérés állapota érdemben, az ügyfél számára láthatóan változik. A belső szerkesztések nem indítanak üzenetet.”

Utána az indokot: „Ez a meglévő kézbesítési csatornát használja, gyors előrehaladási hírt ad az ügyfeleknek, és kezelhető keretek között tartja a kiadást.” Ez a példa indoklása, nem annak állítása, hogy az e-mail általában olcsóbb vagy megbízhatóbb.

A következmények ugyanilyen figyelmet érdemelnek. Közös definíció kell az érdemi változásra. A tesztelésnek ki kell térnie az ismételt frissítésekre és duplikációra. Az ügyfélszolgálatnak tudnia kell, mely események küldenek üzenetet. Az aktív kérésekkel rendelkező ügyfelek továbbra is több e-mailt kaphatnak a kívántnál.

A hasznos következmény természetesen vezet további munkához. Itt rögzítsd a hatást, a feladatot pedig a Jirában kezeld. A bejegyzés magyarázza a munka szükségességét, de ne váljon második backloggá versengő állapotokkal és felelősökkel.

Hozd létre a bejegyzést a Power Packben

Nyisd meg a Power Packet a megfelelő Jira-feladaton, és válaszd a Decision Log (ADR Lite) eszközt. Adj olyan címet, amely megnevezi a tényleges választást, például „Azonnali e-mail használata a portál szokásos állapotfrissítéseihez”.

Válassz a csapat használatához illő kategóriát, és a vita alatt kezdd Proposed állapottal. Add meg a döntéshozót, a választás után pedig a dátumot. A döntéshozó mező a választás felelősét rögzíti; egy név beírása nem végez el helyetted jóváhagyási folyamatot.

Töltsd ki a hátteret, add meg az alternatívákat előnyeikkel és hátrányaikkal, jelöld ki a választott opciót, és írd le a következményeket. A tartalom legyen érthető annak is, aki nem volt ott.

Szükség szerint add meg az érintett Jira-kulcsokat. A szerkesztő vesszővel elválasztott feladathivatkozásokat fogad, amelyek azonosíthatják az érintett fejlesztési és tesztfeladatokat. Ezek rögzített hivatkozások; valódi feladatkapcsolathoz külön használd a Jira szokásos linkelési folyamatát.

Az érintettekkel nézd át a kész bejegyzést. A kiválasztott opció és az indoklás legyen összhangban. Mielőtt a kollégák a legfrissebb verzióra támaszkodnak, ellenőrizd a mentést, különösen helyi vagy offline jelzésnél.

Állapottal tedd egyértelművé a jelenlegi helyzetet

A Power Pack Proposed, Accepted, Rejected és Superseded állapotokat kínál. Egyeztessétek használatukat, hogy az olvasó megkülönböztesse a döntésre váró ötletet a már megvalósítást irányító választástól.

Amikor Maya termékfelelős meghozza az értesítési döntést, a csapat dátumot rögzít és Accepted állapotot állít be. Ez a döntés helyzetét írja le. Nem bizonyít kész implementációt, sikeres teszteket vagy engedélyezett kiadást.

Ugyanez igaz a Rejected állapotra. Ha egy javaslatot nem fogadnak el, a rövid indoklás megóvhat valakit egy már elvégzett vizsgálat tudatlan megismétlésétől. Az indoklást akkor is őrizd meg, ha nem követi megvalósítási feladat.

Feltételezésváltozáskor vedd elő a döntést

Képzeljük el, hogy a bevezetés után a portál sok aktív kéréssel dolgozó ügyfelekkel bővül. Az ügyfélszolgálat szerint néhányan naponta több szokásos e-mailt kapnak. Ez új kontextus, közvetlenül kapcsolódik az eredeti kis üzenetmennyiségi feltételezéshez.

A csapat a módosítás javaslata előtt megnyitja a régi bejegyzést. Így elkülönítheti a korábbi ésszerű kompromisszumot a mai termékkérdéstől. A meglévő döntés megmagyarázza az azonnali e-mail választását; nem tilt jobb megoldást más körülmények között.

Hozz létre új Proposed bejegyzést a napi összefoglalóra. A Power Pack meglévő bejegyzést is duplikálhat Proposed állapotba kiindulópontként. Minden másolt mezőt ellenőrizz: a régi feltételezések, dátumok és következmények már nem feltétlenül érvényesek.

Az új választás elfogadása után a korábbit állítsd Superseded-re, és a helyettesítési mezőben hivatkozz az új döntésre. Az eredeti indoklást hagyd olvashatóan, ne írd át úgy, mintha a csapat mindig összefoglalót tervezett volna.

Ez csapatdokumentációs gyakorlat. A bejegyzések szerkeszthetők maradnak, ezért egyezzetek meg, hogy érdemi változáskor új bejegyzés készül, a normál szerkesztést pedig javításra és pontosításra használjátok. A napló nem megváltoztathatatlan auditnyom.

Tedd hasznossá a naplót a napi munkában

Használd, ha új kolléga érkezik, valaki újratervezést javasol, vagy szokatlan követelmény okát kérdezi. A keresés és szűrés segíthet az adott feladat naplójában megtalálni a bejegyzést. A Power Pack ADR-stílusú Markdown-exportot is kínál ellenőrzéshez vagy más dokumentációs folyamathoz.

Export megosztása előtt ellenőrizd, hogy az aktuális bejegyzést tükrözi, és jelöld meg a karbantartásra használt feladatot. A letöltött dokumentum pillanatfelvétel; későbbi módosítások nem frissítik a már máshová elküldött másolatot.

Kezdj egy nemrég hozott, várhatóan újra előkerülő döntéssel. Írd le a hátteret, valódi alternatívákat, választást és következményeket. Tedd a Power Packben a Jira-munka mellé, majd kérj meg egy, a beszélgetésről lemaradt kollégát, hogy olvassa el. Ha el tudja magyarázni, miért volt értelmes a választás és mi indokolná a változtatást, a napló hasznos munkát végez.

• Michael Nygard: architekturális döntések dokumentálása