Zákony informatiky: Když Brooksův zákon neplatí

Steve McConnell, autor několika věhlasných knih, tvrdí, že Brooks klade příliš velký důraz na komunikaci a její podíl na projektovém čase (komunikační režie projektu) a též na posloupnost projektových fází, kdy jednotlivé úlohy běží vždy za sebou, nikoli vedle sebe (waterfall).

Podle McConnela Brooksova teze o přirovnání softwarového vývoje k narození dítěte může silně pokulhávat. (Jenom pro připomenutí – jedna žena porodí dítě za devět měsíců, ale devět žen neporodí dítě za měsíc) Když je projekt softwarového vývoje organizován v několika menších týmech pracujících souběžně (agilní projektové metody), pak ho lze spíše přirovnat k sběračům bavlny, kteří pracují nezávisle jeden na druhém – a pokud jejich tým rozšíříme z jednoho na devět pracovníků, zcela určitě budeme s prací dříve hotovi.

Podívejme se blíže na modelovou situaci běžného IT projektu, jenž je plánován na 12 měsíců. Nyní jsme v devátém měsíci od jeho zahájení:

9. měsíc: Projekt je ve zpoždění a projektový manažer navrhuje rozšířit vývojový tým o dvě osoby. Vývojáři tvrdí, že je hotovo ze 75 procent a přidání nových členů do týmu v závěrečných fázích celý projekt pouze zpozdí.

11. měsíc: Projektový tým přiznává, že nestíhá odevzdání díla do 12. měsíců. Po vzrušené debatě kolem Brooksova zákona, přidává nakonec manažer projektu dva lidi a přeplánuje projekt tak, aby byl dokončen ve 14. měsíčním časovém horizontu, tj. s dvouměsíčním prodlením.

14. měsíc: Projekt stále není připraven k odevzdání. Vývojáři plísní projektového manažera za porušení Brooksova zákona.

16. měsíc: Projekt je konečně předán, ovšem s výrazně menší funkčností, než bylo původně plánováno.

Jak přispěl Brooksův zákon k problémům s harmonogramem u tohoto projektu? Řešení problému se dle Steve McConnella týká seriózního naplánovaní projektu, jeho trasování a školení. Jiný autor, který sice Brookse nezpochybňuje, ale hovoří o výjimkách z Brooksova zákona je Scott Berkun.

Brooksův zákon předpokládá, že veškerá nová pracovní síla je stejná, což je iluze.

Záleží na tom, kdo do týmu přichází a jaká je jeho výkonnost. Brooksův zákon předpokládá, že veškerá nová pracovní síla je stejná, což je iluze. Když půjde o dobrého programátora, který zná kód a navíc je v přátelském vztahu s polovinou týmu, proč to nezkusit? Znalost kódu a dobré vztahy s týmem kompenzují dva klíčové předpoklady Brooksova zákona – začínat od nuly a komunikační režie.

Některé týmy mohou absorbovat více změn než jiné. Některé týmy jsou odolnější vůči změnám. Dokážou lépe absorbovat režijní a učební povinnosti než ostatní. Je dobře známo, že mezi programátory existuje řada znalostních úrovní, ale je také pravda, že existuje celá plejáda komunikačních a výukových dovedností. I když každý tým zaplatí jistou cenu za přidání lidí, bude se tato cena velmi lišit – a nejde jen o fixní náklady založené na počtu či ceně samotných developerů.

Pokud osoba, kterou přidáváte, vyplní v projektu důležitou mezeru, stojí někdy za to opozdit se.

Jsou horší věci, než zpoždění projektu. Závěr, který si většina z nás udělá po seznámení s Brooksovým zákonem je ten, že byste nikdy neměli přidávat nové programátory do rozjetého projektu. To ale Brooks netvrdí. Pouze říká, že pokud nové členy přidáte, projekt se pravděpodobně zpozdí. To, ale může být v pořádku, pokud se tím např. zvýšila celková kvalita díla. Čas není jediným kritériem úspěchu. Pokud osoba, kterou přidáváte, vyplní v projektu důležitou mezeru, stojí někdy za to opozdit se.

Onboarding nováčků. Existují různé způsoby, jak přidat pracovní sílu. Nešťastným, bohužel však častým způsobem je uvést nováčka do problému se slovy: „Seš ve vodě, tak plavej!“ Pokud manažer vysvětlí, proč se Jana a Martin připojují – a definuje pro ně správné role – otupí počáteční hrany a zajistí hladký přechod. To může zahrnovat i přiřazení mentora, který je schopný a motivovaný být jejich hlavním kontaktním místem pro onboarding. Čím více zkušeností mají členové týmu s personálními změnami uprostřed projektu, tím lépe. Některé nové úkoly je vhodnější přidělit novým lidem a úkolem manažera je zjistit, jaké to jsou.

Nezkušenost. Závisí též na tom, proč je projekt zpožděn. Pokud je projekt ve skluzu kvůli nezkušenosti nebo špatným týmovým praktikám, přidání malého počtu zkušených lidí se scházejícími dovednostmi a nasměrování ostatních, aby je následovali, může tyto nedostatky odstranit. Ne všechny chybějící dovednosti, resp. jejich přenos vyžaduje dlouhé dodací lhůty. Proto ne vždy je přidaná hodnota pracovní síly vždy rovna jedné další programovací jednotce, ale třeba 1+, protože má pozitivní vliv na produktivitu ostatních členů týmu.

Žádné změny členů vývojového týmu nevyřeší psychické problémy vedoucích týmů.

Nekompetentní vedení. Co je ale ještě důležitější, existuje mnoho důvodů pro skluz projektu, jež nemají nic společného s obsazením dodavatelského týmu. Žádné změny členů vývojového týmu nevyřeší psychické problémy vedoucích týmů, resp. mentální dysfunkce vedoucích pracovníků.

Široká paleta řídících nástrojů. Přidání lidí do projektu může být kombinací dalších aspektů jeho komplexního řízení. Na rozdíl od všeobecného přesvědčení není management strategická hra založená na jednotlivých tazích – jako při šachu. Můžete provádět více aktivit najednou. Například můžete někoho z týmu odebrat při současném přidání jiné pracovní síly. Zvyšuje to sice volatilitu v rámci týmových nálad, ale pokud nahrazujeme nejhorší a nejvíce rušivý faktor jedním z nejlepších, může jít o rozumnou volbu.

Seriál Zákony informatiky: