Tlaky při vydávání software

Představte si softwarovou firmu, která vyvíjí klasický krabicový software. Tento software má vývojový cyklus o délce několika měsíců. Na jeho konci se nachází několik betaverzí, release candidates a nakonec finální verze – vše s přesně danými termíny. Nyní se nacházíte někde mezi betaverzemi a dle výsledků testování a počtů nacházených chyb začíná být jasné, že bude problém software dokončit v původně plánovaném termínu a se všemi funkcemi. Co můžete v tuto chvíli jako manažer produktu dělat?

Klasické poučky softwarového inženýrství říkají, že musíte buď posunout termín vydání, nebo vyškrtnout funkce, které ještě nejsou hotové nebo jsou příliš chybové a nestihly by se odladit. Případně můžete obojí zkombinovat. (Je tu ještě třetí možnost: snížit kvalitu výsledku a neopravovat chyby, ale tu nyní zanedbejme – předpokládejme, že chcete vydat kvalitní produkt.)

Problém je, že ať už budete chtít vydat produkt později, nebo ho ořezat, typicky narazíte na velké síly, které vám v tom budou bránit. Několik příkladů:

Posun termínu

Vyškrtání funkcí

Sil je samozřejmě víc, záleží také na konkrétních okolnostech. Prakticky všechny se ale přímo či nepřímo redukují na finanční ztráty pro firmu. Z toho plyne, že bude vždy existovat velice silný tlak na to, aby byly původní termín a seznam funkcí dodrženy.

Tento tlak bude vždy nejvíce pociťovat manažer produktu, protože to je především on, kdo rozhoduje, kterým směrem se jeho vývoj vydá. Je proto možné, že místo uvedených možností zvolí jiné řešení – zvýší tlak na programátory a další členy týmu, aby produkt dodělali včas a úplný. Nařídí se přesčasy, začne horečné opravování chyb na posledních chvíli, hackování místo čistých řešení problémů atd.

Tato cesta je velmi nebezpečná, protože na rozdíl od prvních dvou nemá přímé negativní finanční konsekvence (krom případných proplacených přesčasů) – ty se projeví až mnohem později. Manažerovi tedy nic nebrání po ní jít, je to pro něj defaultní volba. Jak daleko po cestě se vydá záleží v podstatě jen na kultuře firmy a na tom, jak hodně jsou její zaměstnanci ochotní nechat věci vyhrotit.

Co se stane, pokud zajdeme příliš daleko? Tým bude vyčerpaný a demoralizovaný, což může vést k odchodům lidí nebo ztrátě jejich motivace a tedy horším pracovním výkonům a poklesu iniciativy. Kód produktu nebude tak kvalitní, což bude zpomalovat jeho další vývoj a vyžadovat pozdější nákladné refaktorizace. Vše může stát ve výsledku víc, než kolik by firma ztratila odložením vydání nebo omezením funkcí. Zrádnost spočívá v tom, že to není na první pohled vidět.

Dobrý manažer by vše výše uvedené měl vědět a při rozhodování se řídit zájmy dlouhodobými, nikoliv krátkodobými. Měl by zvážit, zda nestojí za to tlaky spojené se změnami termínu a funkcí překonat. Špatný manažer jednoduše zvolí cestu nejmenšího odporu a budoucnost bude řešit až nastane.

Jsem si jist, že vše výše uvedené je už mnohem lépe rozebráno v nějaké chytré knížce. Pro mě ale bylo zajímavé si vše výše uvedené sám uvědomit a pochopit, jak velké síly působí proti opoždění vydání produktu nebo omezení jeho funkcí, a jak malé síly působí proti ždímání lidí a horečnému sprintu na konci vývoje produktu. Snad je to nyní jasnější i vám.

Sep 5, 2010 – 16:00