Jak je to v Tour de App?
- V IT vývoji se nic nevyrovná hmatatelnosti prototypu.
- Týmy pracují na projektu v čase s omezenými zdroji a musí prioritizovat.
- Používají projektové nástroje (např. kanban).
- Tým pracuje s milníky a deadliny, které nejsou vždy formálně definované (mají i interní deadliny).
- Soutěžící nesou důsledky svých rozhodnutí (nestihnutí, technický dluh, zjednodušení řešení).
Perspektiva soutěžícího
„Víme, co je teď důležité. Dokážeme si rozdělit práci, rozhodnout se pod tlakem a upravit plán, když se realita změní.“
Projektový trojimperativ (čas × rozsah × kvalita)
Projektový trojimperativ je základní model řízení projektů, který definuje neodmyslitelný vztah mezi rozsahem (co se dělá), časem (kdy to bude) a náklady (za kolik zdrojů). V běžné praxi platí, že změna jednoho parametru vyvolá reakci u ostatních, například pro zrychlení práce musíte navýšit rozpočet nebo ubrat na funkcích.
V kontextu Tour de App ale je tento trojúhelník extrémně zafixovaný: termín odevzdání je neposunutelný, kapacity a zdroje jsou limitovány volným časem a dovednostmi soutěžících, a proto jedinou skutečnou pákou, kterou můžou ovládat, zůstává rozsah, který musí včas ořezat tak, aby stihli odevzdat kvalitní aplikaci.
Abychom se přiblížili více k realitě, měli bychom do budoucna „rozhýbat“ (klidně i simulovaně) tento trojúhelník.
Úrovně
Indikátory
Procesní indikátory
- Tým umí vysvětlit, co je MVP a proč.
- Existuje alespoň hrubá roadmapa (klidně v kanbanu nebo seznamu).
- Změny v zadání vedou k úpravě plánu, ne k chaotickému přepisování všeho.
Výstupové indikátory
- Výsledná aplikace odpovídá deklarovanému cíli (nepůsobí jako náhodná směs funkcí).
- Je zřejmé, že některé věci byly vědomě vynechány.
- Tým dokáže obhájit svá rozhodnutí („proč tohle ano, tohle ne“).
Prahové indikátory
Z podstaty věci je tato kompetence sledovatelná příležitostně, protože se jedná o těžko dokumentovatelný proces (pokud chceme zanechat volnost sebeřízení). Jedna z možných alternativ jak sledovat tuto kompetenci jsou jednoduché prahové indikátory (True/False) otázky, jako např.:
- tým někdy vědomě zrušil feature [Ano/Ne]
- tým někdy změnil plán na základě reality [Ano/Ne]
- tým někdy pojmenoval trade-off [Ano/Ne]
Možné metody sledování
Decision log
| Kdy | Jak | Co sledujeme |
|---|---|---|
| SK | Klient se může během jedné z posledních schůzek zeptat | Jaké zásadní rozhodnutí tým udělal - co bylo kompromis, co bylo vědomě vynecháno? |
| SK, GRF | Porovnání snapshotu plánu (dotaz / dotazník) s výsledkem | Co skutečně dodali, co z plánu zmizelo? |