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

Comments

Radek

Neresi toto vse Agile Development metodologie? Jestlize vime ze testovani funkci je soucasti iteraci a neda se prejit k dalsim funkcim bez toho aniz bychom otestovali stavajici tak se do vyse popsaneho scenaria ani nedostaneme. V SCRUM napr mame burn-down chart ktery ukazuje jestli na projektu pracujeme rychle ci ne.

Daniel Srb ben Abraham
Daniel Srb ben Abraham

@Radek: Neodvážil bych se napsat, že metodika něco řeší, ale agile přístupy nabízí empiricky ověřené cesty jak to řešit lze. I přes nekvalifikovanost managementu.

@David: Ano, vidět dál, než za další kvartál je schopnost, která se nevidí až tak často.

David Majda

[1] Nemyslím si, že agilní metodiky něco mění na silách popsaných v článku. Spíš mohou dát dříve představu o skutečném stavu projektu (což jde ale i bez nich - stačí mít vývoj vymezený nějakými přesně definovanými milníky) a poskytnout rámec pro rozhodování (např. některé možnosti, kudy jít, jsou vyloučeny už metodikou).

U složitějšího softwaru s potřebou testování v reálném světě navíc agilní technologie nedají ani představu o stavu projektu - ten se zjistí až při onom testování, typicky na konci vývojového cyklu.

Neříkám, že agilní metodiky jsou špatné, jen že nejsou všemocné.

Martin Michálek

Manažer produktu může myslím jít ještě jednou cestou -- namísto tlaku na své lidi může argumentovat směrem ke svým nadřízeným. Vysvětlovat jim rizika komunikace termínu vydání nových verzí softwaru a jeho vlastností v marketingu firmy.

Myslím, že spokojenost uživatele s produktem se neodvíjí od znalosti data vydání příští verze a vlastností, na které se může těšit.

Mám dokonce pocit, že systém "tichého uvolňování nových verzí" postupně začíná převažovat.

srigi
srigi

[5] Jakub Vrána >> alebo mame firmy ako Apple, Adobe alebo MS, ktore nemaju konkurenciu na poli svojich produktov. Tie mozu zvesela posuvat terminy ako uznaju za vhodne (po zapocitani poklesu doveryhodnosti firmy).

[4] Niekedy je manazer posledny clanok a dalej su uz iba zakaznici - typicke pre webstudia.

Add comment

It is not possible to add comments to posts older than one month.