Mnoho firem při svém růstu dospěje do bodu, kdy jejich produkt se prodává dobře a začnou uvažovat o tom, že začnou vyvíjet další produkt. Jak ale poznat, že je ta správná chvíle? A záleží vůbec na tom, jestli budu mít dva produkty nebo jen jeden? Záleží a hodně.
Ve chvíli, kdy přijde myšlenka na nový produkt, musí firma čelit dilematu: vyvinout novou funkčnost jako součást stávajícího úspěšného produktu nebo se pokusit vytvořit nový produkt. Není to lehké rozhodování, tak se pojďme podívat na to, co takovou firmu čeká a na co si musí dát pozor.
Externí pohled
První pohled je externí: co na to řeknou zákazníci. Pokud se vydáme cestou jednoho velkého produktu, bude jednodušší produkt k zákazníkům dostat – prodejní kanály už jsou přece vybudovány a tím pádem i jednodušší získat zpětnou vazbu. Na druhou stranu pokud bude nová funkcionalita jenom volně souviset s tou původní, tak stávající zákazníci možná nepochopí k čemu je a budou ji v lepším případě ignorovat, v horším si stěžovat na to, že jim nové funkce komplikují a kazí jejich dosud oblíbený produkt. Univerzální odpověď neexistuje, management firmy musí zvážit, která cesta bude v tomto individuálním případě výhodnější.
Interní pohled
Než to ale udělá, měl by se podívat na to, co rozhodnutí o případném vývoji druhého produktu způsobí interně ve firmě. Když totiž firma vytvoří dva produkty, téměř automaticky obvykle vytvoří dva produktové týmy. Zároveň je ale druhý produkt často příbuzný s tím prvním (vznikl přece ve stejné firmě) a přirozeně se tak nabízí možnost přepoužít části kódu z prvního produktu v produktu druhém.
Představme si třeba, že prvním produktem je systém pro evidenci docházky zaměstnanců. Druhým produktem potom bude portál pro správu benefitů zaměstnanců. Oba tyto produkty sdílejí část funkcionality – minimálně evidenci zaměstnanců, přihlašování do systému, atd.
Vznik dvou produktů proto firmy často řeší tím, že vytvoří ne dva, ale tři produktové týmy – jeden pro produkt A, druhý pro produktu B a třetí pro sdílenou funkcionalitu. Tomu třetímu se říká různě, většinou vznešeným anglickým jménem – framework, platform, capability. Jeho oficiálním úkolem je plnit požadavky produktových týmů A a B. K tomuto účelu dokonce často dostane přidělený management – vedoucího týmu nebo dokonce tzv. “Product Ownera”.
Proč jsem dal tento pojem do uvozovek? Protože platforma není produkt. Když se podíváme na slovníkovou definici produktu, tak říká: “Produkt je cokoliv, co lze na trhu nabídnout”. I ve všech dalších slovníkových definicích se objevují slova jako spotřebitel, zákazník, prodej. Takzvaný interní produkt, platforma nebo framework je ve ve skutečnosti pouze komponenta přejmenovaná na produkt a tím pádem použití termínu “Product Owner” je zmatení pojmů a tento člověk je nejspíš něco mezi byznys analytikem a projektovým manažerem a nikoliv podnikatelem.
Důsledky rozdělení na dva produkty
I když dáme pojmy stranou, má toto rozdělení také několik negativních praktických důsledků:
- Vznik závislostí. Týmy z produktů A a B teď závisí na sdílené funkcionalitě a netroufnou si v ní cokoliv měnit, protože nevědí, jak by to ovlivnilo ten druhý produkt. Kvalita kódu postupně trpí protože refactoring se stává spíše výjimkou než pravidlem.
- Závislosti vedou k výraznému prodloužení vývoje. Tým produktu A potřebuje něco ve sdílené knihovně. Jelikož neví jak na to a bojí se, aby něco nerozbil pro produkt B, tak tento vývoj svěří odborníkům – napíše požadavek na sdílenou funkcionalitu a počká, až příslušný tým požadavek dodá. To může trvat týdny, protože sdílený tým má samozřejmě “svoje priority”.
- Závislosti se postupně prohlubují, protože každý tým má tendenci si vykolíkovat svoje hřiště i v technické rovině – uloží kód do zvláštního repozitáře, používá jinou automatizaci, jiný standard pro konvence v kódu, atd. Globální refactoring je po čase prakticky nemožný a kvalita kódu trpí.
- Aby efekt závislostí nebyl tak hrozný firma začne zaměstnávat řadu koordinátorů, jejichž jediným cílem je sladit požadavky různých týmů. Jedním z nich je “Product Owner” (ve skutečnosti projektový manažer) sdíleného týmu, ale nejspíš budou potřeba i další. Tito koordinátoři stojí firmu nemalé peníze. Jejich práce by přitom vůbec nebyla potřeba, kdyby produkt byl jenom jeden.
Zkrátka, najít sdílenou komponentu, vyčlenit pro ni tým a začít jí říkat produkt je opravdu špatný nápad, kterého firma po čase bude litovat.
Dva produkty zvenku, jeden uvnitř
Co se ale tedy dá dělat, když z externího (zákaznického) pohledu opravdu silně vychází, že by bylo vhodné mít dva produkty. Například:
- Část zákazníků má zájem pouze o některé funkce, možná by se tyto funkce daly vydělit do zvláštního produktu, který by byl levnější.
- Produkt se chová různě na různých trzích, např. účetní software se logicky chová jinak v Česku a jinak v Německu, protože tam platí jiné zákony.
- Máme stávající produkt na webu a chtěli bychom ho nabídnout jako mobilní aplikaci.
- Máme stávající produkt jako aplikaci pro Windows a chtěli bychom vyvinout cloudovou verzi.
Pokud plánujeme, že dva nově vytvořené produkty budou sdílet nějaký kód, je vhodné rozlišit interní a externí pohled neboli jeden interní produkt a dva produkty externí. Co to znamená? Pro každý externí produkt můžeme mít jiné prodejní kanály, jiný marketing. Každému externímu produktu můžou odpovídat jiné binární soubory – instalace nebo třeba jiná adresa na webu v případě SaaS produktů.
Interně ale oba produkty vyvíjí jeden tým, zdrojový kód je v jednom repozitáři, veškerý kód je sdílený, o prioritách rozhoduje na denní bázi jeden člověk. Tomuto člověku teď mimochodem můžeme zažít říkat Product Owner, protože to odpovídá tomu, jak si tuto roli představuje Scrum – nejspíš tu práci vykonává CEO nebo někdo jiný nejvyššího vedení firmy.
Když to musí být
Pokud se přesto rozhodnete mít dva produkty s dvěma oddělenými vývojovými týmy, je vhodné opravdu oddělit vše – např. lidi nebo zdrojové kódy i za cenu toho, že se některá práce udělá dvakrát. Je to pořád levnější než dlouhodobý problém se zvyšováním závislostí popsaný výše.
Musíte si být taky vědomí toho, že vaše reakce na změny na trhu bude pomalejší a nejspíš budete přicházet o peníze tím, že nebudete flexibilně schopni vyvíjet nové funkce tam, kde jsou potřeba. Je to způsobeno tím, že množství zákaznických požadavků nebude vždy přesně odpovídat kapacitě jednotlivých oddělených týmů.
Hezky to ukazuje Mary Poppendieck v knize Lean Software Development na příkladu výrobce tiskáren. Když světový výrobce vyrábí tiskárnu, musí k ní dodat správnou elektrickou šňůru, protože zásuvky v Evropě a v Americe jsou jiné. Původní řešení bylo předpovídat přesně vývoj poptávky na obou klíčových trzích a podle toho vyrábět počet tiskáren s příslušnou zástrčkou. To se ale nedařilo, protože trhy mají tu vlastnost, že jsou vrtkavé, takže se pravidelně stávalo, že na skladě bylo velké množství sice správných tiskáren, ale se špatnou zástrčkou. Firma tím přicházela o peníze, protože nebyla schopná uspokojit poptávku a na skladě jí ležely nevyužité výrobky.
Pak někdo přišel s nápadem, že se tiskárny budou vyrábět bez zástrčky a příslušný kabel se do nich domontuje až ve skladu poté, co si tiskárnu někdo objedná. Montáž ve skladu je sice asi o dva dolary na kus dražší než přímo ve výrobě, ale když se to porovnalo úsporami ze skladovacích prostor a zvýšenou schopností uspokojit objednávky, firma vydělala asi 3 miliony dolarů měsíčně oproti předchozímu stavu.
Když to celé shrneme, můžeme dojít k následujícímu postupu. Při určení toho, jestli chceme vytvořit nový produkt, musíme vzít v úvahu vnější i vnitřní pohled. I když nám z vnějšího pohledu vychází dva produkty, je lepší vývoj vnitřně řídit jako vývoj jednoho produktu s jedním týmem. Umožní nám to dělat klíčová rozhodnutí později a tím pádem s lepšími informacemi.
Jak to děláte ve vaší firmě? Kolik máte produktů a jak jste k tomu došli?
Pokud se vám článek líbil, sledujte mě na LinkedIn nebo Twitter.
