Jednoho produktivního vývojáře prosím!

Jak velký je rozdíl mezi slabým, průměrným a vynikajícím vývojářem? Kolik průměrných vývojářů zastoupí jednoho excelentního? O kolik člověkodnů dokončíme projekt rychleji přidáním dalšího vývojáře?

Odpovědi na tyto otázky samozřejmě nelze exaktně vyčíslit. Někdo by dokonce mohl říci, že v IT se nedá nic pořádně odhadovat a tak se o to ani nebude pokoušet. Můžeme se ale na problém výkonnosti vývojářů podívat přes jejich produktivitu a posoudit efekt jednotlivých manažerských zásahů na rychlost práce vývojového týmu.

Produktivita vývojáře

Strohá definice říká, že produktivita vývojáře je (ekonomický) ukazatel mezi výsledkem (softwarový produkt) a časem potřebným k jeho dosažení. Podle této definice bychom se měli snažit produkovat software za co nejkratší dobu. Samozřejmě s dodržením akceptačních kritérií na funkční a nefunkční požadavky. Měli bychom také zajistit dostatečnou vniřní kvalitu systému, která nám u dlouhodobých projektů zjednoduší jejich údržbu a následný rozvoj.

Výslednou produktivitu vývojáře ovlivňuje velké množství faktorů. Patří mezi ně odborné znalosti, zkušenosti z jiných projektů, dovednosti v používání nástrojů, intuice v rozhodování, schopnost správného výběru z mnoha alternativ, soft skills, pracovní prostředí, vhodné nástroje a mnoho dalších.

Opravdu kvalitní vývojáři jsou mnohem produktivnější než ti průměrní

Někteří zkušení projektoví manažeři tvrdí, že vynikající vývojář je až o řády produktivnější než průměrný vývojář. Vzhledem k tomu, že vývoj software je vysoce komplexní záležitost, dá se tomuto tvrzení věřit. Co se naprogramuje dnes, stane se základem pro zítra. Pokud tedy pokládá základy určité části systému méně disponovaný vývojář, může být jeho práce nedostatečně kvalitní a ve výsledku neproduktivní. Stavět na takto chatrných základech je pak pro ostatní velice neefektivní. Situace si někdy vynutí velký zásah nebo dokonce kompletní předělání, samozřejmě s výrazným navýšením pracnosti.

Vývoj software prochází několika fázemi (specifikace požadavků, analýza, návrh, implementace, testování, nasazení do provozu, údržba). Chyby a nerespektování požadavků v jednotlivých fázích mohou mít velké časové a ekonomické dopady. Výborný vývojář používá efektivně postupy a nástroje, které chyby eliminují. Tím tráví méně času řešením následných defektů zanesených do systému v předchozích fázích.

Přidám lidi, zrychlím projekt

Tento mýtus IT managmentu je dost rozšířený. Pokud zapojíte další skladníky do nakládky kamionu, jistě se celá akce urychlí (pokud se nepoperou o ještěrku :)). Ale vývoj software není pásová výroba. Tam takové pravidlo neplatí.

Přidáním vývojáře dojde z krátkodobého hlediska spíše ke zpomalení týmu. Stávající členové totiž musí věnovat určitý čas na zaškolení nováčků a jejich uvedení do problematiky. Pokud navíc přidáte slabého vývojáře, jeho nekvalitní a pomalá práce může snížit efektivitu ostatních. S navýšením počtu členů týmu také roste zátěž manažera v koordinací lidí. Množství komunikačních kanálů roste exponenciálně podle počtu lidí. Podle vzorce n(n-1)/2 určíme, že např. pro tým 12 lidí, bude muset manažer udržovat 66 komunikačních vztahů.

Někdy je vhodnější slabého člena z týmu odebrat než se snažit přidat dalšího průměrného vývojáře. Výborným vývojářům se uvolní ruce od zátěže s neproduktivním vývojářem a sami pak odvádějí lepší práci. V tomto případě tedy platí, že méně je více.

Jak tedy urychlit vývoj?

• Určitě se soustřeďte na personální kvalitu Vašeho týmu. Věnujte více peněz na výběr excelentních členů.
• Investujte do školení a dalších forem zvyšování produktivity.
• Nespoléhejte jenom na průměrné vývojáře. Nemůžete na nich stavět projekt, který má být úspěšný. V IT neplatí, že průměrný tým odvede ve výsledku průměrnou práci. Výsledek může být mnohem problémovější.
• Poskytněte vývojářům kvalitní nástroje, které zefektivní jejich práci.
• Nezmatkujte a neurychlujte krátkodobě vývoj přidáváním dalších vývojářů. Hledejte důvody, proč je projekt v prodlení a odstraňujte překážky.
• Zbavte se slabých vývojářů a nebudete je muset hlídat.

Zdroje

K napsání příspěvku mě inspirovala úvaha Neala Forda Developer Productivity Mean vs. Median.