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

• Datum vydání produktu už bylo veřejně oznámeno (změna zhorší vnímání vaší firmy jako schopné dodávat produkty dle plánu).
• Datum je svázáno s vydáním jiných vašich produktů (svým posunem posunete i je, změnu může být těžké dojednat a sníží reputaci vás i vašeho týmu).
• Už bylo vykonáno mnoho práce počítající s plánovaným datem (např. zadání reklamní kampaně na produkt do médií na dané období).
• Datum je navázáno na nějako pevnou událost, kterou nelze posunout (např. konference).

Vyškrtání funkcí

• Funkce prodávají (čím méně funkcí, tím méně prodaných kopií produktu).
• Seznam nových funkcí už byl veřejně oznámen (změna zhorší vnímání vaší firmy jako schopné dodávat produkty dle plánu).
• S novými funkcemi počítají vaši stávající zákazníci (nedodáte-li je, můžou přejít ke konkurenci).
• Na vašich funkcích závisejí jiné produkty firmy (svým omezením donutíte k omezení i je, změnu může být těžké dojednat a sníží reputaci vás i vašeho týmu).
• Už bylo vykonáno mnoho práce počítající s plánovanými funkcemi (např. příprava reklamní kampaně na produkt do médií, která je zdůrazňuje).

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.