Kdysi jsem dostal radu “za rok ti uletí vesmír – v dnešní době není možné dodávat projekty v řádu let”. Tento přístup může být paradoxně pro firmy dlouhodobě škodlivý, pokud se aplikuje u všech projektů, přesto má svoje místo. Na dnešním trhu nevítězí vždy nejkvalitnější produkty, ale někdy právě ty nejrychlejší, které odpovídají aktuálním touhám zákazníků. Proto dává smysl řešit délku vývoje a s ní související koncept time-to-market.
Co je Time-to-Market
Time-to-maket (TTM) je časové období mezi úvodním nápadem přes jeho detailní návrh, realizaci až po dostupnost produktu uživatelům. Délka tohoto úseku je klíčová pro konkurenceschopnost produktu, který nemusí být po příliš dlouhém období vývoje relevantní nebo může být jeho poptávka pokryta konkurencí.
Proto dává smysl věnovat pozornost délce vašeho time-to-market a snažit se o její zkracování. Někteří nazývají tento koncept speed-to-market.
Zlepšování Time-to-Market
Zrychlování vývoje můžeme dosáhnout skrze nespočtem změn, které jsou nezřídka technologické a specifické pro obor a produkt, kterému se věnujeme (jako např. využití low-code platforem). Přesto existují možnosti, které jsou aplikovatelné v širokém počtu společností, a právě na ty se podíváme:
A) Prioritizace rozsahu a určení MVP
Jak nejlépe urychlit projekt? Zjednodušte a ořezejte produkt. Jak moc? Na minimum, které bude dávat vašim uživatelům a zákazníkům ještě smysl. A co se zbytkem funkcí, které mají velkou přidanou hodnotu, ale do minima se nevešly? Dodejte je poté, co vypustíte do světa vaše minimum.
Tento princip nabalující se sněhové koule je známý jako MVP, “minimum viable product” a dokáže vám významně snížit váš time-to-market.
B) Prioritizace projektů a alokace dostatečných kapacit
I společnosti, které si jsou vědomé významu TTM se ochuzují o rychlejší nasazení produktu, a to typicky skrze přílišné nadšení. Klasický způsob, jak si prodlužujeme TTM, je špatná prioritizace projektů, kterých současně realizujeme příliš vysoké množství. Pak se jim nedostává potřebných kapacit. Tým vývojářů, který pracuje na 50 %, dodá produkt mnohem později v porovnání s plně dedikovaným týmem.
Horší, a přesto častá situace panuje ve společnostech, kde kapacity neřeší vůbec. Víte, zda váš tým pracuje z 50 % na projektu A, z 30 % na projektu B a z 20 % řeší provoz? Ne? Pokud neznáte množství kapacit a její rozdělení, těžko reagujete na priority.
C) Zkrácení schvalovacího procesu Váš vývojový tým může být dokonale sehraný, s top vybavením, ale pokud budou muset čekat týdny na rozhodnutí managementu, váš produkt může přijít pozdě. Stejně tak se setkáváme se situací, kdy byl produkt konečně schválen do vývoje, pracuje se na něm, ale v průběhu práce přicházejí stále noví členové vedení, kteří vývoj dočasně pozastaví, aby jim byl produkt vysvětlen a oni posvětili jeho výrobu.
Opakované zdůvodňování projektu nebo produktu je přínosné, ale mělo by se dít systematicky v rámci milníků a ne ad-hoc dle osobních preferencí jednotlivců. To vytváří neproduktivní kulturu společnosti.
D) Řízení závislostí Vyladěný tým má jasnou a schválenou prioritu, které se může ve vývoji věnovat. Přesto jeho práce není nutně předurčená k úspěchu. Ve světě projektů se hlavní hrozby nacházejí typicky mimo projekt samotný, a to například v tom, že je tým závislý na dodávkách kolegů z jiné skupiny.
Proto je zásadní před začátkem a v průběhu vývoje ověřovat, zda tým není závislý na dodávkách či pomoci lidí mimo jejich okruh. Pokud ano, zajistěte, aby se vaše očekávání setkalo v pravý čas s nutnou pomocí. To je základ pro řízení závislostí (v budoucnu si o něm popovídáme do detailu).
E) Paralelizace práce Mozek je mistrem efektivity a ze své podstaty se snaží zjednodušovat si práci. To se nám odráží i při plánování projektů, které tendenčně tvoříme pouze jako balík navazujících aktivit. Nejdříve dokončíme úkol A a až pak se pouštíme do úkolu B.
Zlomte tento zlozvyk a hledejte místa, kde lze paralelizovat úkoly. Doma nejdříve vymalujeme stěny a až pak jdeme sestavovat nábytek, aby mohly stěny mezitím zasychat. V práci postupujte analogicky a hledejte podobné vzorce.
F) Standardizace práce Už Ford, Baťa a další velikáni věděli, že práce, která se skládá z opakovaných aktivit bude rychlejší (viz “seká to jako Baťa cvičky”). A ani vývoj nového produktu není výjimkou a může probíhat ve standardizované struktuře.
Do jisté míry ani nezáleží na konkrétním postupu. Vyberte si rámec, který vám vyhovuje, například Scrum, Prince2, DevOps či jiný. Princip bude vždy platný a dlouhodobě zlepšíte váš time-to-market.
G) Systém distribuce TTM nemusí být pouze o vývoji produktu a zejména velké kolosy mohou těžit z existující vyladěné distribuční sítě, která zkrátí dobu od vývoje k doručení zákazníkům. Není to můj obor, proto ho zmiňuji jen v krátkosti pro ucelený obrázek.
Hodně štěstí při zlepšování vašeho TTM a nezapomeňte, jak říkal Konfucius: “Kdo rychle jedná, rychle sklízí plody svých činů”.