Úplné znění seriálu textů Tomáše Pavlíka, který nabízí doporučení, jakým zásadním chybám se vyhnout při hledání vývojářů do vašeho týmu nebo při nakupování služeb v oblasti vývoje software na zakázku v období, kdy celá Evropa trpí velkým nedostatek kvalifikovaných softwarových inženýrů.
V posledních 2-3 letech se na sociálních sítích mezi vývojáři objevil nový fenomén. Všichni se baví nad trapnými schůzkami s nekompetentními recruitery, nad hloupými nabídkami od personálních agentur a firem, které se snaží ze všech sil na prázdném pracovním trhu něčím zaujmout posledního volného programátora. Probíhají soutěže, kdo dostane více pozvánek na přijímací pohovor za měsíc, kdo obdrží pracovní nabídku do nejvzdálenější destinace na zeměkouli nebo kdo dostane na rande více „HR girls”.
Nezávisle na této bitvě o kvalifikované jednotlivce každý den vidím, jak neefektivně se s takto cennými kapacitami zachází. Nedostatek zdrojů v posledních letech nijak nesnížil počet projektů, které buď skončí krachem, nebo se k nim musí připojit nikdy neplánované „stabilizační etapy”, které nafouknou původní rozpočet i harmonogram na několikanásobek. Také se nijak nesnížil počet lidí pracujících na softwarových projektech, kteří jsou frustrovaní buď z přepracování, z nevyužití svého talentu nebo z pocitu marnosti z práce, která se nejspíš vyhodí.
Jaká jsou má zásadní doporučení, jejichž aplikace by podle mého názoru přinesla jak vyšší spokojenost na straně vývojářů, tak vyšší úspěšnost projektů pro zákazníky?
1) Respektujte známá fakta
Snad všechny větší projekty, které jsem za posledních 25 let viděl, byly poznamenané ignorováním jednoho naprosto základního faktu, který je v softwarovém inženýrství znám již od pravěku tohoto oboru, ale který se buď celá odborná komunita stále stydí odhalit zákazníkům, nebo ho zákazníci odmítají vzít v úvahu. Tímto faktem je, že nepřesnost odhadů pracnosti / nákladů / času je v době, kdy se tyto odhady u projektů typicky dělají, ve stovkách procent. Je to stejné, jako byste si rozpočet na dům pro rodinné bydlení dělali dříve, než si vyberete manželku. U některých zákazníků se tomuto riziku částečně čelí předběžnými analýzami, předepsanými architektonickými paterny, čímž se ze stovek procent můžeme dostat na velké desítky, ale nikdy ne na jednotky procent. Přes všechny zkušenosti v tomto směru vládne obrovská naivita, jejímž výsledkem je stres na projektu, tlak stihnout věci, které se ani při všech přesčasech stihnout fyzicky nedají a ve výsledku frustrace lidí pracujících na takovém projektu.
S nepřesností odhadů je nutné pracovat jako s vlastností softwarových projektů, která je zcela logická a není chybou ani vývojářů ani zadavatelů. Pokud se tedy jako zadavatel chci pouštět do softwarového projektu, musím počítat s tím, že než se dostanu k přesnému rozpočtu, musí být přesně vymyšlena konstrukce celého softwarového systému. Stejně jako u stavby domu se k pevnému rozpočtu dostanu až v momentě, kdy se rozhodnu o barvě poslední kachličky v koupelně a vyberu si poslední vypínač ve sklepě. Dostat se do tohoto stavu ale samo o sobě již bude stát dost peněz a času, a s tím je potřeba počítat. Nebo je možné postupovat obráceně, tedy vzít rozpočet jako pevný a uzpůsobovat rozsah, tedy dodat maximální rozsah, který lze za daný pevný rozpočet pořídit. Tento přístup má v sobě však riziko, že místo rodinného domu dostanete zahradní domek na nářadí.
2) Zapomeňte na bodyshop?
Je velký rozdíl mezi schopností najmout 5 vývojářů na tzv. bodyshop a schopností dodat a provozovat software. Skupina sebelepších programátorů sama o sobě nedodá vůbec nic a hledat je na trhu má smysl pouze pro organizace, které mají rozsáhlou a lety ověřenou zkušenost s tím, jak zařídit, že partička introvertních hochů vyprodukuje udržovatelný a provozovatelný software podle požadavků businessu, a to vše v plánovaném čase a rozpočtu.
Pokud o této schopnosti máte sebemenší pochybnost, nebo pokud vývoj software není váš core business, nehledejte 5 Java vývojářů. Místo toho hledejte profesionální software house, který je schopen vyřešit skutečný problém, tedy vyvinout, dodat a provozovat pro vás softwarový systém.
3) Klíčem je Delivery Management
Úspěch softwarového projektu závisí podle mého názoru mnohem více na procesu tzv. Delivery Managementu než na délce seznamu zkratek jako XML, UML, PHP, HTML atd. v životopisech jednotlivých inženýrů. Delivery Management je možná víc umění než proces a vyžaduje dosažení křehké rovnováhy mezi komponentami, jako jsou business požadavky, technologie, tvrdé limity finanční a termínové, znalosti a zkušenosti jednotlivých vývojářů, potřeby profesního rozvoje členů týmu, nálada Františka po rozchodu s přítelkyní, doba extrakce kávy ve firemním kávovaru a mnoho dalších. Delivery Management, ať na straně dodavatele nebo na straně zákazníka, většinou zastřešují vybraní členové středního managementu. Jedná se o velmi vzácná individua schopná skloubit zdánlivě nespojitelné schopnosti:
- Sami musí být velmi zdatní softwaroví inženýři s praxí a odbornou autoritou, aby viděli do detailu. Zároveň jsou ale schopni vidět věci z nadhledu.
- Jsou schopni organizovat práci ostatním, pracují systematicky, transparentně – a co řeknou, to platí.
- Dokáží motivovat lidi a starají se o svůj tým po personální stránce bez ohledu na existence nebo neexistenci HR oddělení.
- Jsou respektovaným a oceňovaným partnerem pro business zadavatele.
- Jsou zdatní komunikátoři a dokáží zajistit předání informace bez zkomolení od businessu až k vývojářům.
Máte takové Delivery Managery ve vaší organizaci? Dokážete je na trhu najít a rozpoznat tažné od chovných? Pokud ne, doporučuji zapomenout na bodyshop a investovat do dlouhodobého partnerství s profesionální softwarovou firmou.
4) Umožněte nám překročit limity vaší liniové organizační struktury
U našich zákazníků často narážíme na bariéry mezi jejich interními organizačními jednotkami. Tyto bariéry se pak propagují do způsobu práce s externími partnery včetně softwarových firem. Mám na mysli situace, kdy dodáváme software na zakázku pro několik oddělení u jednoho zákazníka. Na dodavatelské straně naši práci vnímáme jako jednu zakázku, s jedním Delivery Managerem a jedním týmem vývojářů, jejichž kapacitu jsme schopni snadno přesouvat tam, kde je to potřeba. Díky skvělé kvalifikaci našich lidí také můžeme jednoduše měnit jejich konkrétní role v projektu (analytik, vývojář, tester, …). Tuto flexibilitu často zákazníci nedokáží konzumovat, protože jejich oddělení se mezi sebou nejsou schopna sladit na prioritách tak, aby se optimálně a plně využila disponibilní kapacita našeho týmu. Naopak se typicky pracuje ve vlnách, kdy v jeden okamžik všechno hoří a je potřeba v panice navyšovat za každou cenu zdroje a pak jsou zase období, kdy práce není dostatek a část lidí z týmu čeká „na střídačce”. Je to zbytečné, protože pokud by se podařilo udělat celkem jednoduché dohody, získali by všichni ve výsledku víc.
5) Nenechte si operovat srdce od stavebního inženýra
Vývoj software je náročná disciplína – vyžadující talent, kvalitní vysokoškolské vzdělání a následný profesní rozvoj po celý život. Je to obor náročností srovnatelný s medicínou. Přesto si řada lidí stále myslí, že programovat může každý, kdo absolvuje týdenní kurs HTML. Samozřejmě „nabastlit” webovou stránku zvládne malé dítě. Ale rozdíl mezi jednoduchou webovou stránkou a softwarem, který realizuje v bance převod peněz, je stejně velký jako mezi schopností si nalepit náplast a kardiochirurgickým výkonem.
Nepodceňujte složitost software a nepodceňujte nároky na vzdělání vývojářů. Pětileté univerzitní vzdělání v oboru softwarového inženýrství je nutný základ pro vývojáře stejně jako absolvování lékařské fakulty pro lékaře. Ptejte se vašich dodavatelů, jaké mají nároky na vzdělání svých lidí. Buďte nároční a nekompromisní v nárocích na vzdělání vašich in house vývojářů. Z naší zkušenosti jednoznačně vychází, že kvalitní oborové vzdělání je důležitější než roky praxe ve firmě, kde se software „bastlí”.
6) Řešte náklady, ne cenu za člověkoden
Často se setkáváme s tlakem nákupních oddělení velkých zákazníků na cenu za člověkoden. Bývá to bohužel jediná tvrdá hodnota uvažovaná ve výběrových řízeních. Náklady na vývoj software jsou ale mnohem komplexnější veličina a kromě ceny za člověkoden je třeba vzít v úvahu také obtížně měřitelnou produktivitu projektového týmu a ještě obtížněji měřitelnou schopnost dodavatele tuto produktivitu dlouhodobě zlepšovat.
Jaké metriky máte vy sami nebo vaši dodavatelé stanoveny pro měření produktivity? Jsou adekvátní vaší situaci? Používáte jen základní učebnicové? Nebo neměříte vůbec? Jak zajišťujete vy nebo váš dodavatel trvalé zlepšování produktivity? Víte, kolik času se stráví vývojem nového kódu versus opravami chyb? Víte, kolik řádků kódu vaši vývojáři vyprodukují za den? Používáte metodu funkčních bodů?
Podle mého pozorování se za poslední 2-3 roky situace na trhu zásadně změnila. Bude stále obtížnější řídit vývoj software výstupem, tedy tím, že chci v daném čase a rozpočtu realizovat nějakou sadu funkčních a nefunkčních požadavků – a nezajímá mě nic před a nic po takovém projektu. Mnohem lepších výsledků lze podle mého názoru dosahovat, pokud budeme vývoj software řídit průtokem, tedy rozhodnutím, že dlouhodobě chci do vývoje software dávat určitý stabilní objem nákladů a pak jen optimalizuji, jak za tyto náklady realizovat co nejvíce požadavků. Pokud dokážeme tuto změnu na trhu akceptovat jako fakt a přizpůsobit se jí, umožní nám to dělat software mnohem efektivněji a s větší radostí, což přeji jak zákazníkům, tak vývojářů.
Tomáš Pavlík, CEO společnosti Profinit