S rozšířením a popularitou empirických(aneb zkusím a uvidím) přístupů se někdy zdá, že se konečně našlo jednoduché univerzální řešení na to jak efektivně dělat inovace a řídit teamy zodpovědné za firemní projekty a změny. Zejména agilní přístupy se dnes napříč zeměkoulí staly téměř standardem a v rámci jednotlivých iterací se teamy učí experimentovat, rychle ověřovat nápady a zjišťovat co nejdříve jestli jednotlivé inovace jsou realizovatelné a mají očekáváný efekt. Zdálo by se, že stačí vzít libovolnou partu motivovaných lidí, zvolit vhodný mix agilních frameworků a technik a nechat je iterovat a výsledky se brzy dostaví. Pokud něco neumí, nebo neznají tak se to za běhu díky zpětné vazbě prostě naučí a jede se dál. Je to, ale opravdu tak?
Jako investor nebo manažer hospodařící s omezenými zdroji bychom si přáli, aby cesta k cílí byla co nejméně klikatá, aby výsledný produkt vznikl ideálně s minimálním množstvím potřebných finančních, či lidských zdrojů a v co nejkratším čase.
Tradiční projektové řízení se tento sen snažil naplnit snahou vše dopředu co nejpodrobněji vymyslet, naplánovat a zoptimalizovat tak, aby se ideálně jedním výstřelem (iterací) trefil cíl. Což se dost často z mnoha důvodů nedaří. Empirické a iterativní přístupy nás vedou k tomu, přibližovat se k cíli po dílčích krocích, kdy pokaždé iteraci se vyhodnotí, jak se team posunul směrem k cílí a případně se podle potřeby upraví kurz. Každá iterace je pak chápana jako experiment, který může dopadnou lépe nebo hůře. Vede takový přístup vždy cíli? Nemusí.
Pokud náročnost cíle výrazně přesahuje znalosti a zkušenosti teamu, tak dojdou peníze, nebo team ztratí motivaci a rozuteče se dřív než vznikne něco hodnotného. A i zkušený team zvláště v komplexních prostředích jako jsou velké korporace nemá šanci mít ve svých hlavách všechny dovednosti a znalosti pro efektivní dosažení cílů. Jak z toho ven?
Odpověď z agilního světa by byla: „Věř teamu a jeho schopnosti se učit za běhu“. Odpověď z tradičního projektového světa by byla udělej pořádnou analýzu, ošetři rizika a připrav si projektový plán. Co si vybrat? Když se podíváme na to jak úspěšné teamy reálně fungují a dodávají vždy najdeme kombinaci empirických a analytických, na znalostech založených činností. Dobrý projektový manažer rozdělí projekt do iterací, v projektovém plánu najdeme činnosti jako např. technologické PoC(Proof-of-Concept) a v budgetu rezervu na změny a rizika, které se objeví po cestě. Naopak špičkový agilní team neinvestuje svůj čas a iterace do prvních nahodilých nápadů, které se mu objeví v backlogu, ale pečlivě vybírá (na základě nějaké formy analýzy a dostupných znalostí), co bude řešit a co ne.
Jinak se k témuž závěru dá dojít, když si uvědomíme, že každý změnový projekt či iniciativa, která se snaží posunout produkt, proces či celou organizaci ze stávajícího stavu do cílového stavu musí cestou udělat řadu „designových“ rozhodnutí. Rozhodnutí od obchodních typu na jakém trhu se budeme pohybovat, přes výběr potřeb zákazníků, na které se bude cíli a vlastností produktů. Na to navazují procesy a technologie, které zvolíme a to vše až do malých detailních rozhodnutí o tom, kde bude tlačítko na obrazovce, či jaký algoritmus programátor pro nějakou funkci zvolí. Změnovou iniciativu si pak můžeme představit jako strom rozhodnutí a jejich realizací.
A jak se rozhodnutí dá udělat? Buď analyticky, kdy si zjistím maximum informací, které poslouží pro rozhodnutí nebo dokonce exaktně kdy vypočítám optimální řešení. A nebo empiricky, kdy si vyberu jedno z možných řešení, zrealizuji jej a následně vyhodnotím jestli jsem dosáhl uspokojivých výsledků. Asi už začíná být zřejmé, že závisí na kontextu zda pro dané rozhodnutí je efektivnější analytický, nebo empirický přístup.
Používat vždy jenom empirický, nebo analytický přístup nebude rozumné. Pokud chci rozhodnout jestli klientům bude více vyhovovat červené, nebo zelené tlačítko na nějaké obrazovce. Prostě jednu z variant vyberu, nebo udělám A/B test a to mi řekne, která varianta je vhodnější. Alternativně by šlo před rozhodnutím o barvě tlačítka udělat sociologickou studii napříč všemi občany ČR, která by nám řekla co potenciální uživatele preferují. A i když by možná nějakou odpověď dala, rozhodně by to stálo více úsilí a času, než pár minut vývojáře, který obarví tlačítko na červeno a nebo později na zeleno, když se to nesvědčí. Naopak pokud řeším jiné téma třeba jak naplnit GDPR legislativu a použiji přísně empirický přístup nemusím dopadnou dobře. Jak by to v extrému vypadlo? Počkám na první pokutu úřadů a pak uděláme takové změny, abychom v tomto případě vyhověli požadavku legislativy. Pak zareaguji na další pokutu a tak dál, dokud nebudu v souladu s legislativou. Což by asi stálo dost peněz jak na pokutách tak, na opakovaném upravování firemních systémů. Takže v reálu, každá firma přistoupí v případě implementace GRPR nejdříve k právní a pak technické analýze než se pustí do úpravy svých systémů.
Co si z téhle úvahy odnést?
- Pokud Vaše teamy jedou převážně projektově, nebo stakeholdeři tráví čas nekonečnými diskuzemi na dílčím vlastnostmi řešení naučte team více experimentovat a nebát se dělat chyby
- Pokud naopak vidíte, že v teamu chybí potřebné znalosti pro kvalitní rozhodování zvažte doplnění teamu o experty, kteří přinesou do teamu potřebnou znalost, nebo analytiky, kteří pro team posbírají a utřídí střípky informací na kterých bude team stavět
