Iniciácia projektu zákopovou metódou
Článok z blogchainu: zákopová metóda.
Potreba vytvárať a meniť procesy (teda aj softvér) v biznise sa nedeje samočinne. Inhibítormi týchto zmien sú identifikované problémy (aktuálne, budúce), alebo príležitosti. Aby sa projekt mohol nazvať projektom, je potrebné problém, alebo príležitosť zarámcovať - určiť ciele a zaniesť (vedomé) limity (rozpočet, časový rámec, rozsah). Stanoviť metriky, ktoré pomôžu indikovať, či riešenie splnilo očakávania.
Business case
What is your goal?
What’s stopping you from reaching the goal?
How much change is needed to overcome the problem?
Are you certain this will solve the problem?
Ak ti nie je jasný cieľ (ciele) projektu na ktorom sa zúčastňuješ, alebo sa s nimi nevieš stotožniť (nie z titulu, že nefunguješ ako profesionál, ktorý zabudol na vloženie svojej emočnej práce), tak projekt je odsúdený na neúspech.
Bez jasne definovaného a vymedzeného problému, alebo príležitosti nie je veľmi ako designovať riešenie. Stakeholderovi treba pomocť identifikovať koreňový problém (root cause analysis, 5whys), nechať ho povedať, čo si myslí, že treba urobiť, ale nie slepo tento návrh nasledovať. Áno, môže dať návrhy riešenia, ale ja potrebujem vedieť, aký problém/očakávanie má, a prečo ho má.
Príležitosť? Pre koho to je? Na čo to je?
Zacieliť hneď na všetkých a všetko, nie je dobrý nápad. Identifikovať a vizualizovať (persóny) komu idem pomôcť, a čím mu idem pomôcť, rovnako popísať si východzí stav (status quo) pre tieto persóny (ako teraz riešia problém, ktorý majú) je dobrá pomôcka a barlička aj pre ďalšiu komunikáciu v rámci projektu. Nezabudnúť ani na to, čo výsledný produkt (robiť) nebude (nerobíme mobilnú verziu aplikácie).
Kvantitatívne posúdenie
Pri príležitostiach je najčastejšiou metrikou návratnosť investície (ROI). Ak však dokážeš identifikovať špecifické metriky, ktorými dokážeš kvantitatívne posúdiť pred a po, tak je dobrý nápad ich zmerať. Pri identifikácii metrík obráť svoju pozornosť na dostupné dáta. Akými informáciami už aktuálne informačné systémy disponujú, ako tieto dáta môžu ciele a výsledky projektu môžu potvrdiť. Rovnako je dobrý nápad pocitovú závažnosť problému overiť na dátach (príklad: zadávateľ robí z komára somára, pričom dáta preukážu, že problém sa týka 0,01% objednávok).
Odsúdený na úspech
Pravdepodobne sa budem ešte veľakrát opakovať, ale zásadný spôsob, ako znižovať riziko neúspechu softvérového projektu, je skracovať dĺžku jeho trvania. Vedomým spôsobom znižovať potrebný rozsah prác (scope).
Odhadovať trvanie vývoja komplexného softvérového riešenia, ktoré sa samo o sebe ťažko uchopuje, kedže v prvotných fázach je softvér len predstava, je alchýmia. Požiadavky sa vždy (z)menia ako plynie čas, a v prípade inovačných projektov podiel objavených úloh často prekročí podiel úloh plánovaných (ktoré som si predstavil, že treba urobiť pri iniciácii projektu).
Timebox
Keď dostávaš na otázku Koľko to bude trvať? od riešiteľa prázdny pohľad, je vhodné použiť timebox. Čo je to timebox (spike)? Predmetnej úlohe sa zadefinuje maximálny čas, ktorý sa jej bude venovať, a s novými informáciami (keď sa predmetný čas investoval) sa urobí ďalšie rozhodnutie.
Ak podobný princíp aplikujeme aj na softvérový projekt ako celok, tak zadávateľa vedome sústredíme na identifikáciu možných a splniteľných cieľov, takých ktoré mu dodajú hodnotu. V lepšie uchopiteľnom časovom rámci - povedzme 6 týždňov - sa lahšie plánuje, vlastne sa ani veľmi neplánuje, a takýto interval má aj inú dynamiku - sa sústredíme len na nevyhnutné úlohy, ktoré nás dovedú k plánovanému (dielčiemu) cieľu.
Dať si záležať na iniciácii projektu je dobrým predpokladom, aby som sa mal o čo oprieť počas jeho behu. Ak sa snažím projekt skrátiť na čo najkratšie časové obdobie, umožňuje mi to lepšie reagovať v dalších fázach (miniprojektoch). Nerobím teoretické rozhodnutia od zeleného stola, ale mám informácie z bojového poľa.