Článok z blogchainu: zákopová metóda.
Ako získať pocit istoty, pri ktorej viac viem ako tuším, že členovia projektového tímu pracujú na im zverených úlohach? Ako zabezpečím, že vzájomná informovanosť o kľúčových aspektoch projektu, nie je na bode mrazu? Primárne vzájomne medzi riešiteľmi, ale aj "navonok" voči stakeholderom?
Byť výhradne dedikovaný na projekt je pre väčšinu doménových expertov (stakeholderi, používatelia) málo pravdepodobné. Bežná prax je, že ste súčasťou projektového tímu a zároveň riešite svoju agendu vyplývajúcu z vašeho funkčného zaradenia. Pri vývojároch to už také nezvyčajné nie je, ale aj tých dokáže všeličo zaskočiť, a nezriedka pracujú v podmienkach, kedy prepínajú viac kontextov (pracujú na viacerých projektoch). Úlohou projektového manažéra je pomáhať tomu, že úlohy, ktoré dostanú (odhad rozsahu a kapacity) a dostali (preverenie, či sa kapacita dostala k riešeniu rozsahu) na zodpovednosť riešitelia sa hýbu vpred.
Pre správnu dynamiku softvérového projektu, ktorý Ti vždy odporúčam, aby si vedome skracoval, je potrebné zabezpečiť, aby členovia projektového tímu mali pravidelne informáciu o tom:
- čo sa deje v širšom kontexte projektu (nielen moje úlohy)
- že sa veci hýbu vpred (oslava malých víťazstiev)
Pamätáš si na ten pocit, keď si sa dozvedel (mimochodom) kľúčovú informáciu v kontexte projektu, ktorá zásadne ovplyvnila riešenie (tvoju úlohu)? Spomínaš ako si sa cítil, že táto informácia sa k tebe dostala vedlajším kanálom a o týždeň neskôr? Pamätáš ako dobre Ti bolo, keď si videl, že časť projektu sa dostala do užívania a žne úspechy?
3x3x3 míting
Pra-organizáciu pre malý tím (4-5 členov) som kedysi dávno (2006-2008) riešil pomocou 3x3x3 míting/metódy. Každý týždeň v piatok poobede sme si všetci sadli na jednu až dve hodiny, pričom každý sa vyjadril 3 oblastiach:
- 3 veci, čo som vyriešil - DONE
- 3 veci, čo mám na pláne na ďalší týžden- PLAN
- 3 veci, s ktorými mám problém sa pohnúť ďalej - PROBLEM
Tri neznamenalo, že to nevyhnutne museli byť až/len tri, ale znamenalo to vypichnutie toho najpodstatnejšieho (práve z uhla pohľadu každého jednotlivca). Jasné, keď niekto nemal žiadne problémy, tak sme mu mohli zagratulovať. V rámci meetingu sme skoordinovali plánovaciu časť v kontexte priorít, ktoré som odovzdával - biznis prioritne potrebuje X, alebo sme ich určili spoločne - musíme vyriešiť tento problém Y - vracia sa to ako bumerang.
Z mítingu vždy vznikol záznam o stave daného týždňa vo forme matice. Perlička: pre položky sme používali konvenciu s hviezdičkovaním. Kto si niečo prenášal z ostatného týždňa, úlohu/iniciatívu. Hviezdička hanby (prenášam si plán z povodného týždňa, prenášam si problém z aktuálneho týždňa, nebol priestor sa tomu venovať).
V tom čase som pravdepodobne o agilný manifest ešte nezavadil, i keď na svete už bol. Každopádne považujem 3x3x3 ako aplikovanie agilného prístupu, v rámci ktorého sa stretá tím f2f, komunikuje navzájom a dáva si spatnú väzbu. Hlavne sa vytvára zvyk, ktorý považujem za dobrú investíciu, aby veci mohli fungovali.
Áno, celá 3x3x3 metóda vypadá oproti SCRUM, alebo KANBANu s priority line, ako hračka. Ale jej úspech tkvie v jednoduchosti, a uvádzam ju ako inšpiráciu, ako si vytvoriť opakujúci sa míting, v ktorom sa udeje vzájomná aktualizácia.
Kedže som veľký fanúšik hlbokej a asynchrónnej práce v prvom rade, slovíčko (synchrónny) status míting vo mne vyvoláva negatívne konotácie. Preto ako protipól uvediem pár tipov a nástroj pomocou, ktorého je sa možné informovať priebežne.
Obľúbené trio otázok projektového manažéra
Pristihli ste sa pri tom, ako sa na pravidelnom status mítingu všetci spovedajú z toho, čo urobili, resp. kde majú problém sa pohnúť. Je to zmyselne investovaný čas, keď (strelím) 80% informácií, ktoré sa na mítingu komunikujú už sú (môžu ľahko byť) zachytené v PM nástroji (JIRA)?
Ako zabezpečiť transparentné a čerstvé odpovede na obľubené otázky projektového manažéra pomocou PM nástroja?
| Otázka | Akcia |
|---|---|
| Robíš na tom? | Daj najavo, že na úlohe pracuješ (presun z to-do do work-in-progress), zaloguj, že si niečo urobil. |
| Stíhaš to? Kedy to bude? | V rámci šprintu (timeboxu) je defaultná odpoveď, že na konci šprintu (timeboxu) určite. |
| Máš s niečím problém? | Daj varovanie, keď máš obavu, že to nestihneš. Vyšli signál, že si blokovaný. Úspešne používam primitívny spôsob pomocou tagu #waiting |
Pulz projektu
Transparetnosť v informovaní o spolupráci na projekte je zásadný faktor, ktorý ovplyvňuje to, že netrávime zbytočne čas na tom, aby sme si povedali aktualizácie, ktoré je jednoduché vykopať z PM nástroja (JIRA).
Na aktualizácie ohľadom víťazstiev, alebo zásadnejších prekážok odporúčam udržiavať pulz projektu pomocou tlkotov (heartbeats). Tlkoty sú krátke písomne aktualizácie, ktoré sa týkajú projektu. Ak sa nič nedeje, tak tlkot napíše na pravidelnej báze (týždennej, obtýždennej) projektový manažér, ale nič nebráni aj inému členovi tímu prispieť. Je to ekvivalent steny facebookovej stránky venovanej výhradne projektu a vecí s ním súvisiacich. Samotná realizácia sa dá zabezpečiť pomocu Slacku (projektový kanál), Microsoft teams, alebo pomocou priestoru pre projekt v Confluence, ktorý môže byť kŕmený špecifickým typom JIRA issue.
Z neznáma do známa
Chlapci z Basecampu minulý rok (2018) sformalizovali výstižnú metriku, ktorú nazvali kopcový graf (hill chart) a krásne ju vo svojej novej príručke Shape up zasadili do širšieho kontextu. Tento graf reprezentuje, že každý projekt, alebo lepšie, skupina dielčich úloh (volajme ju balíček, epos) má:
1) časť pre vrcholom, kedy stúpam hore a je relatívne komplikované odhadnúť ako rýchlo výjdem na kopec.
2) časť za vrcholom, kedy klesám dolu, a už mám za sebou fázu skúmania, ktorú už je relatívne možné presne odhadnúť, aké úlohy musím ešte urobiť, aby som ju dokončil.
Kopcový graf ako nástroj na reportovanie stavu je integrálnou súčasťou Basecampu. Ak si chcem túto kvalitatívnu metriku (pocit istoty) kvantifikovať mimo tento nástroj, tak môžem ku všetkým Eposom (epic), alebo analytickým úloham (pre ktoré ma zmysel toto monitorovať z ich povahy), pridať vlastnosť Cesta do známa, ktorá môže nadobúdať stavy:
- zdrod - v tejto fáze je krásna myšlienka, ale veľký pocit neistoty, čo všetko čaká riešiteľa
- prieskum - znižujem neistotu, odhaľujem nové dielčie úlohy
- rozhľad - už mám istotu, že som odkryl cely obraz toho, čo sa chystám urobiť
- downhill - už pracujem na tom, aby som pôvodne plánované aj objavené úlohy zrealizoval
- hotovo - považujem všetky dielčie úlohy za hotové, uspokojujúce ciele/metriky projektu
Takto označené balíčky mi z vyšieho pohľadu pômožu vyhodnotiť, či niektorá z úloh dlho netrčí pred kopcom, alebo či stavy za kopcom korešpondujú s blížiacim termínom mílnika.
Aktivita členov tímu
Nikdy nie je zlý nápad pozrieť sa na dáta, ktoré udržiavame k úloham v PM nástrojoch. Rovnako tieto dokážu ukázať ako to v projekte žije. V rámci mojich ilustrácii budem referencovať nástroj Atlassian JIRA, ale podobný výsledok by nemal byť problém získať aj z dát iného nástroja. Nechcem teraz rozoberať bežné metriky ako počet nových incidentov, priemerny vek dlho hnijúcich požiadaviek, burndown graf šprintu, ktoré rovnako dokumentujú ako to na projekte/produkte žije, ale ukážem na pár ideí, ktoré možno nie sú až také bežné, rozšírené.
Potrebujem si odpovedať na otázku, či môj kolega X prikladá ruku k dielu, bez toho, že by som ho otravoval status mítingom, pingovaním do messengera, alebo mailom. Potrebujem včasne zachytiť situáciu, že sa riešitel zamotal do toho, že vedome odkladá prácu na nejakej úlohe, lebo nemá veľmi chuť zakričať, že nevie ako vyriešiť problém.
Ako pomôcku, ktorá pomôže odreportovať odpovede na tieto otázky, možno aplikovať graf aktivity.
Za aktivitu sa považuje akákoľvek aktivita: komentár, zaevidovanie práce (worklog), doplnenie/úprava zadania, ... každá môže mať istú váhu. Report sa môže rezať na úrovniach riešiteľ, epos, verzia, čo môže odkryť špecifické zádrhely. Netvrdím, že to je ultimátny nástroj, ale povedzme, že môže krásne dokumentovať ochladenie prác na projekte, čo môže byť spúšťačom pre stakeholdera, alebo projekt manažéra, aby si preveril, kam sa aktivita projektových členov podela.
Nebuď informačným silom, alebo úzkym hrdlom, hľadaj spôsoby, ako komunikáciu a výmenu informácii na projekte nelimitovať, ako z veľkého množstva malých informácií vytiahnuť to podstatné. Keďže projekty vedome limituješ z pohľadu rozsahu, alebo času, čo implikuje, že počet členov tímu sa udržuje na rozumnom počte, ktorý negeneruje viac komunikačného šumu ako signálu, to umožnuje, aby komunikácia prebiehala efektívne aj peer-to-peer. A ak sa všetci naučia, kde hľadať pulz projektu, tak by sa nikto nemal nájsť v nelichotivej situácii frustrácie s neinformovanosti, alebo naopak informačnej záplavy.