NetAcademia

A legjobbakat tanítjuk!

A produktivitás nem mérhető

2016. július 08. 08:00 - Plesz Gábor

Rengeteg érzelemmel telített vita zajlik a fejlesztési módszertanok, tervezési gyakorlat és hasonló témák körül. A legtöbb ilyen konfliktust lehetetlen feloldani, mivel az iparágban hiányzik a képesség a szoftverfejlesztés hatákonysági alapelemeinek a mérésére. A termelékenység mérésére például nincs ésszerű módszerünk.

A termelékenységet józan paraszti ésszel valahogy úgy lehetne meghatározni, hogy megnézzük, hogy a bemeneti tevékenységek milyen kimeneti eredményeket produkálnak. Vagyis ahhoz, hogy mérjük a fejlesztés termelékenységét mérnünk kell az eredményt. És itt a baj, ugyanis az eredményt nem tudjuk mérni.

Ez természetesen nem azt jelenti, hogy még nem próbálta senki. A legjobban azok a tanulmányok zavarnak, amik a termelékenységet a leírt kódsorok száma alapján próbálják mérni. Először is, különböző programnyelvek léteznek, különböző kódolási stílussal valamint formázási megszokásokon alapuló különbségekkel. De tegyük fel, hogy a kezdetektől következetesen mérünk, ugyanazt a nyelvet és automatikusan ugyanolyan kódolási stílust használunk - nos, a sorok száma ekkor sem megfelelő arra, hogy a kimenetünket mérjük vele.

Minden jó fejlesztő tudja, hogy ugyanazt a dolgot rengeteg féle képpen lehet megvalósítani, ráadásul, azok a kódok, amik jobban vannak tervezve általában rövidebbek, mert például a duplikációkat kiszűrik a kódból. Fordítva, a másolás és beillesztés programozási módszer pedig rossz tervezéshez és magasabb számú sorhoz vezet, ugyanis gyártja a többszörözést. Ezt be is tudjuk bizonyítani olyan refactoring eszközzel, ami támogatja az egysoros függvény és a függvény kivonat használatát. Ha ezt a gyakori eljárásoknál jól és ügyesen használjuk, simán meg tudjuk duplázni a kódsorok számát.

Gondolhatnánk, hogy a kódsorok száma alapú mérések mára már kihaltak, de nem. Minden hónapban találkozhatunk erre alapuló termelékenységi tanulmányokkal - még az olyan köztiszteletben álló folyóiratoknál is mint az IEEE, pedig nekik ezt már tudniuk kellene.

Ez persze nem jelenti azt, hogy a kódsorok száma teljességgel használhatatlan. Jól tudja például jelezni egy redszer méretét. Az azért valószínű, hogy egy 100.000 soros rendszer nagyobb, mint egy 10.000 soros. De ez csak becslés, ha én írok egy rendszert 100.000 sorból, a munkatársam Joe pedig megírja ugyanazt 10.000 sorból az nem tesz engem produktívabbá. Valójában inkább azt a következtetést lehet levonni ebből, hogy a termelékenységünk nagyjából azonos, de az én rendszerem sokkal rosszabbul van tervezve.

Egy másik megközelítése a témának, ha a kimenetet a funkciópontok számával jellemezzük. Ez számomra már egy kicsit szimpatikusabb, de még mindig nem meggyőző. Ebben mondjuk az sem segít, hogy hallottam olyan történetet, amiben egyetlen rendszer különböző pontszámai között egy hármas szorzó volt, persze ugyanazt az elemző rendszert használva.

De még ha precízen tudnánk is számolni a funkciópontokat, azt hiszem akkor is elhibáznánk a termelékenységi mérést. Azt nyilván mondhatjuk, hogy a funkcionalitás mérése egy módszer a szoftverfejlesztés közvetlen kimenetének a vizsgálatához, de a valódi kimenet azért egy kicsit más. Tegyük fel, hogy van egy precíz funkciópont mérési rendszerünk. Ha például én egy évben leszállítok egy 100 funkciópontos rendszert, Joe pedig egy 50 pontosat, akkor vajon feltételezhetjük-e, hogy az én termelékenységem magasabb? Azt mondanám, hogy nem. Az is lehet például, hogy az én 100 pontomból csak 30 olyan funkcionalitás van, ami ténylegesen használható is a vásárlómnak, amíg Joe 50 pontjából mindegyik használható. Ez inkább azt jelenti, hogy bár az én nyers, közvetlen termelékenységem magasabb, Joe valódi, használható termelékenysége a jobb.

Jeff Grigg arra hívta fel a figyelmemet, hogy belső tényezők is számítanak az egyes funkciópontok szállításakor. "Az én 100 pontom feltűnően hasonló funkcionalitást takar, és elvitt egy évemet, mivel nem sikerült megfelelő szintre emelnem menet közben a kód újrafelhasználást. Joe 50 pontja feltűnően különbözik (ez volt számára a rossz hír). Gyakorlatilag semmilyen újrafelhasználás nem történt. De annak ellenére, hogy 50 látványosan különböző funkciót kellett megvalósítania, és semmilyen újrafelhasználást ehhez nem tudott kialakítani, mindössze 1 év alatt elkészült vele. Szóval Joe egyszerűen fantasztikus,"

De mindez teljességgel figyelmen kívül hagyja, hogy még a használható funkcionalitás sem jelenti a jó mérőszámot. Például, ha én 30 használható funkciópontot gyártok, Joe pedig 15-öt, de valaki rájön, hogy az ő ügyfelei 15 millió dollár extra profithoz jutottak ezáltal, míg az én munkám csak 5 millió dollárhoz vezetett. Ismét azt kell mondanom, hogy Joe valódi produktivitása nagyobb, hiszen több üzleti értéket szállított - és egyben ráébreszt, hogy a szoftverfejlesztés valódi termelékenységét mérő adatoknak a leszállított, üzletileg értékes dolgokon kellene alapulnia.

Ezek a gondolatok elvezetnek a sikeresség vizsgálatához. Általánosságban megállapítani egy szoftver sikerét nehéz ügy, mivel az emberek nem értik, mit is jelent pontosan a sikertelenség. Érvelhetek úgy, hogy a sikeres projekt az, ahol több üzleti értéket szállítok, mint amennyibe került a projekt. Rendben, akkor mi van, ha Joe is és én is öt projektet vezetünk, én sikeres vagyok néggyel, Joe pedig eggyel - most végre sikeresebb vagyok, mint Joe? Nos, nem feltétlenül. Ha az én négy sikeres projektem egyenként 1 millió dollár nyereséget hoz, de Joe az egy sikeres projekten 10 millióval több bevételt termel, mint amennyibe került az összes projektje, akkor bizony őt kell ünnepelni.

Így hát vannak olyanok, akik azt mondják, hogy amit nem tudsz mérni, azt nem is tudod kezelni. Vagyis, dobjuk el az összes szabályt. Az üzleti szereplők valójában folyamatosan kezelnek megmérhetetlen dolgokat is. Hogy méred meg egy céges jogász produktivitását, a marketing osztályét vagy éppen az oktatási intézményekét? (erről bővebben itt olvashatsz: Robert Austin).

Ha egy csapat hatékonyságát nehéz megmérni, akkor sokkal nehezebb megmérni a csapatot alkotó egyének együttműködését.  Figyelheted erősen a csapat által fejlesztett funkcionalitások számát fejlesztési ciklusonként. Ez nyers értelmezés, de érzékelheted, hogy melyik csapat gyorsult fel, vagy érzékelheted, ha egyik csapat sokkal gyorsabb, mint a másik. De egyének közreműködését sokkal nehezebb értékelni. Amíg egyes emberek az egyes funkcionalitások fejlesztéséért felelősek, a többiek támogató szerepet játszanak - másoknak segítenek a funkciókat megvalósítani. Az ő közreműködésük nagyon is számít a teljes csapat termelékenységében - de nagyon nehéz megérteni az ő személyes teljesítményüket, anélkül, hogy a csapatban dolgozó fejlesztő lennél.

És ha ez az egész még nem lenne elég bonyolult, az Economist (2003. szeptember 13-19) közzétett egy cikket a produktivitással kapcsolatos trendekről. Ebben az állt, hogy az újságírók már látják, hogy a 90-es években a termelékenység növekedett az informatikai beruházásoknak köszönhetően. A lényeg azonban az, hogy a növekedés időben lemaradva követi a beruházásokat: "Az informatikai beruházások nem automatikusan növelik a produktivitást; az üzleti gyakorlatot is át kell szervezni ehhez". Ugyanez az időeltolódás történt az elektronikába történő beruházásokkor.

Tehát nem csak az üzleti értéket mérése nehezíti az életet, hanem még az időeltolódást is. Vagyis, talán a csapatod termelékenységét egészen addig nem fogod tudni jól megmérni, amíg el nem telik néhány év az általuk fejlesztett szoftver kiadását követően

Teljesen érthető, hogy a termelékenység mérése miért olyan csábító cél. Ha tudnánk ilyet, akkor sokkal könnyebben értékelhetnénk a szoftvereinket, mint ahogy most ezt meg tudjuk tenni. De egy rossz mérés csak még rosszabbá teszi a dolgokat. Ezért szerintem érdemes beismernünk, hogy milyen tudatlanok is vagyunk e területen valójában.

Cannot measure productivity

1 komment

A bejegyzés trackback címe:

https://netacademia.blog.hu/api/trackback/id/tr828760910

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

KCB 2016.07.12. 11:21:46

A "produktivitás" sokféleképpen mérhető, ez nagyban befolyásolja a mozgóbér nagyságát.

Nagyjából mindegyiknek az az alapja, hogy szimpatikus vagy-e az aktuális managernek, team leadernek, scrum masternek vagy sem.

Ha pl. dohányzik az értékelő, akkor a bagósok jó fejek lesznek, függetlenül attól hogy idejük nagy részét munkától távol töltik.

Ha van közös hobbi, érdeklődési kör, együtt söröznek, ebédelnek, másokat fikáznak, stb akkor szintén pozitívan értékelik az illető produktivitását.

Szintén nem szempont, ha valaki egész nap internetezik, ellógja a munkát, nem szól ha végez hanem napokig írja rá még az órákat. Ha az illető amúgy cimbi.

Ha valakinek nincs kedve bizonyos melókhoz és válogat, akkor könnyen az jön ki belőle, hogy milyen jól dolgozik, mivel hajlamos az ember abban sokkal jobban és gyorsabban dolgozni amit szeret. Ellenben aki válogatás nélkül minden melót elvállal, az lassú lesz.

Gyakori eset még, ha valakinek nincs családja, nője, hobbija, gyereke, élete és leginkább a melóhelyen lóg akkor az lesz a normál és mindenki más alul teljesítő lehet csak.

Szintén gyengén teljesít az, aki sokáig egy adott területen dolgozik, így máshoz nem ért a cégen belül.
Ha esetleg váltana, akkor azt elutasítják.

A teljesítmény mérésnek alapja, hogy az illetőt soha nem kérdezik és nem hallgatják meg, mindig felette döntenek róla. (mi miért tartott annyi ideig, stb) Tipikus hogy az értékelő olyan kifejezéseket használ hogy ezt fele annyi idő alatt is meg lehetett volna csinálni. Persze anélkül hogy komolyabban utánajárt volna, mik voltak a munka buktatói.

Előfordul hogy további fogalmatlanokat kérdeznek az illetőről, de ezen véleményeket csak akkor veszik figyelembe, ha egyezik a véleményező gondolataival. Így mindig önigazolást nyer a "helyes" értékelés.

Az értékelésen az emberek 95% átlag alatt teljesít, cserébe átlagon felül fizetik, így jobb lenne ha nem ugrálna. Örüljön hogy dolgozhat a CÉG-nek, mert a cég ezzel valójában szívességet tesz neki hiszen máshol fele ennyiért sem tudna elhelyezkedni.

A fenti példák mint a valós életből vett, személyes vagy barátok által tapasztaltakból adódtak.

És a fentiek alapján tett értékelést mindig produktivitás/hatékonyság címszóval nyomják.