Universální řešení

Jako analytik se často nabízím zákazníkům možnost volby. Chcete jednodušší a levnější řešení, nebo řešení složitější, universálnější, ale dražší? Často zákazník volí řešení universálnější, protože co kdyby...

Pojďme se podívat na takový přehnaný příklad. Dejme tomu, že bych byl prodejce motorových vozidel. Důležitou otázkou kladenou zákazníkům je, kde vlastně chce zákazník s daným vozidlem jezdit. Jestli jen po silnici, nebo i v terénu. Případně v jak náročném terénu.  Zákazník ví, že chce jezdit po silnici. Možná se někdy dostane i do terénu, silnice nejsou všude. Takže pro jistotu, chce něco co zvládne náročný terén. Prostě ideálně takové universální vozidlo, které zvládne všechno.

Výsledek: tank. Cena v řádu desítek milionů, spotřeba ve stovkách litrů na 100 km. Na silnici pomalý, ale zvládne jakýkoliv terén.

Nestíháme termín projektu... Co s tím?

Nejprve si stručně popíšeme situaci.

• Termín dokončení projektu je pevně daný a nelze ho posunout. Důvody, proč nelze termín posunout mohou být různé: například je termín zafixovaný ve smlouvě s vysokým penále, nebo se jedná o termín určený třetí stranou (např. datum účinnosti zákona), případně je nutné dodržet termín z obchodních důvodů.
• Zpoždění se objevilo "najednou a neočekávaně". Pokud je projekt řízený zkušeným projektovým manažerem, má obvykle i kvalitně připravený projektový plán. I u takového projektu může dojít z různých důvodů ke zpoždění. Toto zpoždění se ale nikdy neobjeví náhle a neočekávaně, ale postupně v čase. To znamená, že ho lze včas detekovat a eliminovat. "Náhlé a neočekávané" zpoždění se objeví v důsledku rizika, které buď nebylo identifikováno, nebo identifikovány bylo a nemáme pro něj připravený vhodný plán k eliminaci rizika. Příkladem může být třeba projekt s nezkušeným projektovým manažerem, kde se "najednou a neočekávaně" zjistí, že projektový plán vůbec nepočítá s dvouměsíčním testováním a tedy vývoj musí skončit o měsíc dřív než se plánovalo.

A teď co s tím? Řešení lze hledat v následujících oblastech:

Rozsah projektu

Projekt bude dodán v plánovaném termínu, ale rozsah projektu bude omezen. Některé méně důležité požadavky budou přesunuty na později. 

Kdy zvolit tuto oblast:

• Existují požadavky, bez kterých se lze obejít.
• Tyto požadavky jsou časově náročné.

Zdroje

Na dokončení projektu je třeba 200 MD, na projektu nyní pracuje 5 vývojářů, kteří ho jdou schopni dokončit za 2 měsíce.  Můžeme přidat 5 dalších vývojářů a dokončit projekt již za měsíc. Nebo na projekt alokujeme 40 vývojářů a projekt dokončíme již za týden! Takhle to samozřejmě nefunguje, protože se projeví zákon klesajících výnosů. Tj. když se počet vývojářů zvýší z 5 na 40 nebude projekt dokončený 8x rychleji. 

Kdy zvolit tuto oblast:

• Existují volné zdroje, které lze použít.
• Nové zdroje lze bez problémů zapojit do projektu.

Kvalita

Zásah do kvality znamená, že budeme testovat méně. Díky tomu bude projekt hotový dříve, ale bude méně otestovaný tj. bude v něm více chyb.

Kdy zvolit tuto oblast:

• Lze si dovolit větší množství chyb. Chyby nemají žádný kritický dopad.

Zvýšení efektivity
"Zázračné řešení", které mají všichni rádi. Rozsah projektu ani kvalita se nemění, zdroje také ne, jen zvýšíme efektivitu. Zpravidla tím, že použijeme řešení XY, které zkrátí dobu vývoje o polovinu. Bohužel "zázračná řešení" se objevují většinou jen v marketingových prezentacích. Pokud takový zázračný nástroj přece existuje a víme o něm, je otázkou, proč nebyl použit již od začátku projektu.

Kdy zvolit tuto oblast:

• Pokud jsme si jisti, že ono zmiňované "zázračné řešení" skutečně funguje. Jinak existuje riziko.že se naopak zpoždění ještě prohloubí.

V realitě se obvykle volí kombinace. Tj. navýšíme přiměřeně zdroje, snížíme rozsah a o něco zkrátíme testování.