Amióta kitört a kapitalizmus, feloldhatatlan ellentét feszül munkáltató (illetve a munkáltatót képviselő munkahelyi vezető) és a munkás között – legalábbis ezt tanultuk (vulgár) Marxtól. Amióta pedig a világ digitális világ, még feloldhatatlanabb ellentét feszül a szoftverfejlesztők és munkahelyi vezetőik között. Utóbbiak minden igyekezetükkel azon vannak, hogy megőrizzék a fejlesztési projekt fölötti kontrollt, ezért aztán sokuk görcsösen kapaszkodik a "nyolc óra munka, nyolc óra pihenés, nyolc óra szórakozás" nagyferós közhelyébe. Aztán újra és újra bebizonyosodik: szélmalomharcot vívnak...

A szoftverfejlesztés ugyanis nem úgy működik, ahogy a gyárakban a futószalag mellett a termelés. De miért van eleve kudarcra ítélve ez a vezetői hozzáállás? Nick Hodges, aki hosszú éveket húzott le kutatás-fejlesztési vezetőként, az InfoWorldön szedte össze az okokat.

A szakember szerint a helytelen hozzáállás gyökere abban keresendő, hogy a vezetők a jelen-jövő problémáit a múltbeli tapasztalatok és bevált gyakorlatok alapján próbálják megoldani. Azaz olyan technológiákat és stratégiákat alkalmaznak, melyek a múltban hatékonyak voltak.

Ilyen a idő és teljesítmény közötti korreláció is. Amikor kitalálták a tömeggyártást, a gyártószalagokat, a munkások teljesítménye szorosan összefüggött a szalag mellett eltöltött idővel. Ha négy óra alatt 100 egységet tudott elvégezni, akkor 8 óra alatt 200-at (ha figyelembe vesszük a fáradást, 90-et). Sokan mind a mai napig ezt a szemléletet akarják átvinni a szoftverfejlesztésbe.

Ám ott valamiért nem működik. Miért nem halad gyorsabban a projekt, ha a fejlesztők naponta kétszer annyi időt koptatják a feneküket a gépük előtt?

Az inkompetens vezető

Hodges szerint sok vezető azért fordul az időalapú kontrollrendszerhez, mert valójában képtelen megítélni, mit is csinálnak a fejlesztői. Így aztán arról sincs fogalma, hogy jól és megfelelő gyorsasággal végzik-e a munkájukat. Azt azonban másodpercre pontosan le tudja mérni, hogy mennyit kalapálják a billentyűzetüket, vagy hány sort írtak meg egységnyi idő alatt. (Aprócska magyar irodalmi párhuzam: állítólag Kormos István közismert verses meséje Vackorról, a piszén pisze kölyökmackóról azért áll rövid sorokból, mert a verseket a kiadók akkoriban sorra fizették, azaz több sor – több pénz.)

Ez a szoftverfejlesztésben dolgozók számára nyilvánvalóan nonszensz. Hogyan lehetne ezzel a módszerrel mérni annak a munkának az értékét, amikor egy másfél ezernyi soros kódrészletet egy fejlesztő kicserél másfél száz, de sokkal hatékonyabb kódsorral mondjuk három munkanap alatt, amiből két napig egy billentyűt sem üt le, csak kódot elemez?

Egyes vezetők eljutnak addig, hogy előzetes becslést kérnek az egyes feladatok időigényéről, és az alapján mérik a fejlesztő teljesítményét, hogy tartotta-e a becslést. Az ilyen mérési módszer azonban több okból is kontraproduktív.

A szoftverfejlesztésben nincs két egyforma probléma. Az egyszerű problémákra még egy tapasztalatlan junior is gyorsan talál megoldást. Egy szenior, akire általában a súlyosabb szakmai feladatok hárulnak, napokig-hetekig töprenghet, mire egyetlen dolognak a végére jár. Összehasonlítható a két munka? Nyilvánvalóan nem. Ellenpróbaként érdemes egy gyorsan haladó juniornak adni a szenior egyik feladatát.

Az időalapú teljesítményértékelés a rendszer meghekkelésére sarkallja a fejlesztőket, hogy elkerüljenek minden olyan feladatot, aminél felmerül a gyanú, hogy tovább tart az előzetesen becsültnél. Elvégre ők sem akarnak rossz benyomást kelteni, már csak a következő munkahelyük miatt sem (amit az időalapú teljesítményértékelés bevezetése után sürgősen el is kezdenek keresni).

A (nem triviális) tények makacs dolgok

Senki sem tudja biztosan megjósolni, hogy mennyi idő kell egy nem triviális probléma megoldásához, egy hiba kijavításához vagy egy új funkció implementálásához. Ha pedig arra kényszerülnek a fejlesztők, hogy az órákban, percekben és másodpercekben gondolkodjanak, akkor az eredmény egy trehányul összerakott, hibáktól (sőt: biztonsági résektől) hemzsegő programkód lesz az eredmény.

Utóbbinak pedig súlyos, és akár az egész vállalatot érintő következményei lehetnek.