A végtermék jó mérce, de kontrollálható-e a hozzá vezető út? Stopperrel biztosan nem.

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.

Közösség & HR

A Samsung headsetjén mutatkozik be a Google kiterjesztett valósága

A most bejelentett Android XR platform már a Gemini MI-technológiájára épül, és új korszakot nyitna az immerzív technológiák fejlődésében.
 
A software defined network már évek óta velünk él. Csak idő kérdése volt a koncepciót kiterjesztése a WAN-okra.

a melléklet támogatója a Yettel

Amióta a VMware a Broadcom tulajdonába került, sebesen követik egymást a szoftvercégnél a stratégiai jelentőségű változások. Mi vár az ügyfelekre? Vincze-Berecz Tibor szoftverlicenc-szakértő (IPR-Insights) írása.

Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak

Különösen az early adopter vállalatoknak lehet hasznos. De különbözik ez bármiben az amúgy is megkerülhetetlen tervezéstől és pilottól?

Sok hazai cégnek kell szorosra zárni a kiberkaput

Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizennegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2024 Bitport.hu Média Kft. Minden jog fenntartva.