Manday není jednotka!

Tento příspěvek bude česky, protože se týká hlavně českých firem, tvořících software, a je podložen praxí, bohužel.

Pro některé je titulek možná šokující odhalení a děsný podraz, jelikož celý život krom jednotek Kč, EURO, hodina, den, týden a procento používali též "člověkoden" (manday) a "člověkohodinu" (manhour). O té poslední se zmiňovat ani nebudu, platí pro ní totéž, co pro tu v titulku.

Manday přece funguje

Ano, někdy funguje. Třeba při výkopových pracích bývá rozdíl mezi dělníky řádový jen výjimečně. Manažer si odhad pro jistotu vynásobí nějakým koeficientem a má skoro jistotu, že se termín stihne. Může dokonce jen s malou chybou počítat "cenu manday", atd.
Jenže my se bavíme o tvorbě software, kde jsou rozdíly mezi programátory, analytiky, testery i konzultanty obrovské.

Pepa není Franta

Máte velký projekt, který tvoří statisíce řádek kódu, dvacítka příruček, desetitisíce automatických testů, tisíce uživatelských scénářů pro akceptace a školení, za projektem jsou léta vývoje, používá se poměrně velká sada kompatibilních technologií s popsaným způsobem vazeb ...
Pepa je senior, projekt vede pět let, možná nerozumí všemu, ale přinejmenším ví, "že to tam je", a po deseti minutách se umí zorientovat. Franta je též senior, firma ho zrovna přijala, má léta praxe, všechny používané technologie "má v malíčku", má taky dvojnásobný plat než Pepa.

Stejný úkol

Přesto když ti dva dostanou stejný úkol, Pepa ho má do hodiny vyřešený, Franta pravděpodobně něco rozbije. Manažer se zlobí, začíná pochybovat o tom, že přijetí Franty bylo správné. Možná ho přeřadí na jiný projekt, kde se to zopakuje. Nebo to Frantu nechá opravit a dodělat, a rozčiluje se, že místo jednoho dne, který dostal s velkou rezervou, je to už týden.
První problém totiž je, že práce nováčka se nedá odhadovat bez ohledu na jeho léta praxe na jiných projektech.

Samouk

Další zlá varianta - tým má už tak málo lidí, že Pepa nemá čas na nováčka v týmu, každý den hasí "požáry". V rychlosti na něj každý den vychrlí nové informace, nemá čas ale vysvětlovat podrobnosti. Frantu hodí do vody, ukáže mu jak plavat, a dál ať to zkouší sám. Výsledek? Utekl měsíc, Franta je stále mimo, nefunguje mu už ani editor, nechápe proč. Nadává, co je tohle za firmu. Manažer vynadá Pepovi, ten ho nevrle pošle "do lesa".

Jinak a lépe

Nejefektivnější způsob zaučování je párové programování. Prostě si spolu musí aspoň na půlku pracovní doby sednout, Pepa bude navigátor, Franta řidič. Občas může být problém Frantovo ego, ale to už je na tom, jestli nový člen týmu zapadne do kolektivu. Samozřejmě mandays běží dvojnásobným tempem, ale čert je vem. Postupem času bude Pepy třeba méně a méně, při přechodu na další odlišnou práci si zase spolu sednou a dělají spolu.

Každý je nahraditelný ...?

Je? Není? Ale jo, je ... ale je třeba zvážit, za jakou cenu, přičemž cenou je tu hlavně čas (že čas nejsou peníze, vysvětlím dále). Někteří lidé prakticky nejsou v přijatelném časovém horizontu nahraditelní jedním člověkem - je třeba si rozmyslet, kolik a jaké práce běžně odváděli, v jaké kvalitě i kvantitě (to je další problém - jak to měřit?), a ideálně dostatečný počet nových lidí přibrat do týmu dříve než dotyčný odejde. I tak dojde ke zpoždění, protože je bude třeba do vývoje "dostat".

Opět - Pepa není ekvivalentem pěti Jindřichů ani padesáti Karlíků. Vyplnit vzniklou mezeru může být velmi těžké a pro celý tým stresující, čili je třeba, aby mezera byla co nejmenší, ideálně aby vznikl překryv. Pepa si nové lidi sám zaškolí.

Struktura týmu

V ČR je bohužel zažitá praxe, že organizace firem je hierarchická, někdy dokonce s mnoho patry. Kupodivu to většinou nefunguje, nebo to přinejmenším nefunguje hladce.
Druhý nešvarem je, že firmy týmy dimenzují spíše tak, že týmu jeden člověk chybí než aby jeden člověk přebýval. Tým pak nemá žádnou rezervu na řešení náhlých problémů, výzkum alternativ, atd. Tento přístup je přímo sebevražedný.

V týmu by měli být lidé sobě rovnocenní a měli by si rozdělit práci tak trochu podle vlastních preferencí a specializací. Projektový manažer nesmí být víc než vývojář ani naopak, oba by se měli ale vzájemně respektovat, oba jsou potřebnými a rovnocennými experty, každý na svou oblast.
V týmu si lidé musí vyměňovat názory, klidně se můžou i hádat, ale nesmí sebou navzájem pohrdat nebo se sebe bát v žádném smyslu slova.

Plánování práce

Předem píšu, že se stále bavíme o velkých zakázkách, řádově stovky až tisíce mandays.
Zákazník jen málokdy dodá kompletní specifikaci toho, co chce. Ve smlouvě je často jen název zakázky, cena. No a protože je třeba nějak specifikovat, za co že ta cena vlastně je, stanoví se nějaký počet mandays na základě velmi hrubé analýzy toho, co všechno bude obsahem zakázky.
Tato hodnota smí být užita nanejvýš orientačnímu porovnání s jinými zakázkami, a to ještě s velkou opatrností, nebo k orientačnímu rozdělení zakázky na fragmenty. Jinak je k ničemu a pokud jí k něčemu použijete, nedivte se, že vám pak nic nebude vycházet.

No dobře, když ale nemůžeme používat mandays, jak máme plánovat? Hned na začátku by měly být jasné dva údaje:

• termín
• rozpočet

A od nich a na základě nějakého interního rozboru analýzy odvodit strukturu týmu, jaký bude na implementaci nasazen, pokud možno plným úvazkem, jelikož přepínání úloh při tvůrčí činnosti unavuje, zdržuje, a tato režie sama zabila nejeden projekt. Výjimkou můžou být lidé, kteří neprogramují, ale jsou zapotřebí například pro údržbu serverů, podporu týmu. O těch nemluvím, ale i na ně je třeba v rozpočtu myslet.

Jakýchkoliv sledování nebo nedejbože plánování mandays se v tuhle chvíli vzdejte, jen by celý tým mátly, ale žádný užitek z nich nebude. Pamatujte, nemůžete házet na jednu hromadu Pepy a Franty, ne, ani Petra!
Můžete definovat mezitermíny dokončení "milestones" (tj. částečná implementace, která se dá považovat za hotovou část celku, a dá se například předat zákazníkovi k "osahání") včetně plánu rozpočtu, což se dá snadno a poměrně přesně průběžně kontrolovat.

Po rozjetí projektu (ne nutně po podpisu smlouvy, ale s rizikem, že k němu ani nedojde je třeba vždycky počítat), je v první řadě třeba zpřesnit analýzu tak, aby se dalo začít programovat. Není třeba udělat všechno najednou, ale je třeba mít analýzu konzistentní, abyste se netočili v kruzích.
Programování pak probíhá ideálně v iteracích, co iterace, to nějaká sada dobře naplánovaných úloh, za každou úlohu nese někdo odpovědnost, po každé iteraci se vyhodnocuje stav a případně se úloha posune do další iterace.

Toto je už věc analytiků, programátorů, manažer může přihlížet, vznášet dotazy, ale do organizace práce ostatních členů týmu by neměl nekvalifikovaně zasahovat, rozhodně ne autoritativně. Měl by ale naopak průběžně informovat programátory o stavu rozpočtu a celý tým by měl dokázat zhruba odhadnout procento implementace vůči nejbližšímu plánovanému milestone.

Definice úlohy

Definici úlohy specifikují typicky programátoři ve spolupráci s analytikem. Úloha by měla mít následující atributy:

• Název - jednoduchý a srozumitelný alespoň všem programátorům
• Popis - co nejpečlivější a hned na začátku rozšířený o slovní návrh implementace, plus způsob ověření funkčnosti
• Termín - u úlohy do nejbližší iterace už závazný, u úlohy plánované na později spíše orientační
• Pracnost - odhad programátora, spíše pesimistický než optimistický. Všichni budou šťastní, pokud se to povede napoprvé, ale málokdy se to stane. Pokud je úloha ale dokončena s nižší než odhadnutou pracností, je to pořád dobré.
• Specifikace závislostí na jiných úlohách

Právě součet pracností úlohy je pak použitelný k dalšímu odhadu toho, zda se vše stíhá, nicméně je nutné počítat i se závislostmi a vytížeností týmu, což není tak jednoduché, jak se na první pohled zdá. Pokud to zanedbáte, riskujete, že si až pozdě všimnete, že nestíháte. Na druhou stranu, plánovat příliš podrobně příliš dopředu vás také nikam neposune, jen ztratíte čas něčím, co pak buď budete zbytečně udržovat, nebo co stejně vyhodíte.

Čas nejsou peníze

Prostý fakt je ten, že zákazníka nezajímá, kolik lidí jste ve skutečnosti v týmu měli ani kolik tým strávil "mandays" prací na díle, dokonce ani jestli jste zaměstnali dvacet čerstvých absolventů vysoké školy nebo dva specialisty za 200 tisíc měsíčně. To je věc dodavatele, aby zvolil nejlepší cestu.

Ano, zákazník se může snažit zjistit, jaký máte zisk, resp. o kolik levnější daná zakázka mohla být. Pokud vás ale chce usvědčit z toho, že jste ho obrali, stejně vám při nejbližší příležitosti uteče, a svědčí to mimo jiné o tom, že jste nějak podcenili komunikaci se zákazníkem - začal vás podezřívat.

Zákazníka hlavně zajímá to, aby dílo, které zaplatil, nemělo žádné vady a fungovalo tak, jak požadoval. Mandays používá spíše na "virtuální" ohodnocení pracnosti díla. Toto číslo ale nemá s realitou interních výkazů práce nic společného. Kdyby mělo, představte si to - zákazník má problém, tak za ním pošlete:

• experta, který je za dvě hodiny hotový
• sekretářku, která zavolá expertovi, který jí naviguje. Dílo též skončí po nějakých čtyřech hodinách úspěchem

Vážně si myslíte, že můžete vyfakturovat celý jeden manday (2 lidi krát 4 hodiny)?*
Krom toho plat sekretářky je jen zlomek toho, co bere expert. Seriózní firma samozřejmě vždycky pošle experta. Tento příklad se obvykle řeší smluvně trochu jinak, ale jako okatý příklad nesrovnalosti takového přístupu snad stačí.

Závěr

Jinak řečeno, ano, asi jste si už u svých velkých zakázek všimli, že se nedají moc dobře plánovat. A právě proto vznikly termíny jako agilní techniky vývoje software, extrémní programování, a další, viz oba odkazy. Pro manažera, zvyklého na vodopádový model (pokud vůbec), je to celkem nepříjemná změna, ale je to jen o zvyku - nakonec je naopak příjemné, že se pořád něco děje a pořád se to posouvá, a když po každé iteraci vidí hotové dílo, už by neměnil.

Ještě bych zmínil jeden web, http://wiki.c2.com, vypadá sice triviálně a zastarale, ale obsahuje neskutečné množství nadčasových otázek a odpovědí, týkajících se vývoje software, vysvětlených podle mého soudu celkem srozumitelnou formou včetně různých pastí. Pokud ho začnete vážně číst, je možné, že budete mít problém přestat ...

P.S.: Kniha The Mythical Man-Month byla vydána v roce 1975.

EDIT: Na základě připomínky kamaráda, vztahující se k článkům "Agile is Dead" (které si najděte sami), přidávám ještě jeden odkaz s reakcí na ně: Is the Agile Manifesto Dead?
Stručně řečeno jde o to, že se z Agile stal buzzword, obchodní značka, přičemž původně šlo spíše o apel a nějaký soupis technik, které při vývoji pomáhají. "Agilní" znamená česky "snaživý", tak se snažte dělat věci dobře, chovejte se jako tým, atd. Ne, neznamená to, že se budete doslovně držet nějakého seznamu bodů. Myslete. A mluvte spolu.

*) Pro puntičkáře - zatímco sekretářka cestovala, expert se už připravoval na její podporu a studoval logy, které dostal.