Tento článek obsahuje 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 či z pocitu marnosti z práce, která se nejspíš vyhodí.
Předkládám zde 6 zásadních doporučení, jejichž aplikace by podle mého názoru přinesla jak vyšší spokojenost na straně vývojářů, tak i 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 dosahuje v době, kdy se tyto odhady u projektů typicky dělají, stovek 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 vzory, čí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.
2. Zapomeňte na bodyshop
3. Delivery Management je klíč
Ú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 existenci 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.
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í jsme také schopni pružně 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 vývojáře a ještě obtížněji měřitelnou schopnost dodavatele tuto produktivitu dlouhodobě zlepšovat napříč celým týmem. Jaké metriky máte vy sami nebo vaši dodavatelé stanoveny pro měření produktivity? Jsou adekvátní vaší situaci? Nebo 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ů?
Autor: Tomáš Pavlík, CEO Profinit