HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

A tudás és a tapasztalat próbája: hogyan lehet mérni egy jó fejlesztő teljesítményét multinacionális környezetben?

Az előző poszt-on, A jó fejlesztő dilemmáján csavarnék egyet és játékra hívom a Kedves Olvasókat. A feladat nagyon egyszerű: adjanak meg olyan szoftver metrikát, ami szerint Angel jobb, mint Devil.

A háttérről röviden:

Angel és Devil fejlesztők, mindketten egy nagy multinacionális cégnél dolgoznak, több száz társukkal együtt.

Angel jól dolgozik, szakmailag hozzáértő és tapasztalt. Ha egy hibát lát, akkor a hiba okát keresi meg és azt javítja ki. Hosszú távú megoldásokat keres. Az általa megírt kód stabil és hibamentes.

Devil az ő ellentéte: gyorsan és hanyagul dolgozik. Mindig rövid távú megoldást keres, nem ás a dolgok mélyére. Az általa írt kódban újabb hibák bukkannak fel.

A vezetőség szeretné mérni a fejlesztők hatékonyságát, hogy megszabaduljanak a rossz fejlesztőktől és megjutalmazzák a jókat. Ez nem egyszerű, hiszen több száz fejlesztőről van szó, nagyméretű rendszerekről, amiken egyszerre akár több tucat fejlesztő is dolgozik. A felhasználó bázis is óriási. A vezetőség nem ismeri személyesen se a felhasználókat, se fejlesztőket, se a fejlesztési vezetőket, ezért valamilyen könnyen és objektíven mérhető metrikát szeretnének.

Arra kérném az Olvasókat, hogy adjanak tanácsot a vezetőségnek, milyen metrikát kellene alkalmazni – amivel kiderül, hogy Angel munkája értékes és Devil munkája nem az.

Néhány megjegyzés:

- Az ügyfél elégedettség nem objektív metrika.

- A fejlesztők főnökének véleménye nem objektív metrika.

- A regression bug-ok száma nehézkesen mérhető, hiszen ugyanazon a szoftveren egyszerre több változtatás is fut.

- A szoftverek, amiken a fejlesztők dolgoznak, különböző méretűek, tehát ha valakinek sok munkája van a másiknak pedig kevés, az önmagában nem jelent semmit.

- Józan paraszti ész nem számít, csakis amit az Excel mutat J

Segítségképpen leírok pár metrikát, amik BIZTOSAN NEM JÓK:

- Lezárt hibajegyek száma: A helpdesk rendszerből könnyedén kinyerhető információ. Devil gyorsabban dolgozik, ezért több hibajegyet zár le, mint Angel.

- Functional Point Analysis: Lásd előző, Devil gyorsabb fejleszt ki egy-egy funkciót, mint Angel. A statisztika ugyebár nem mutatja ki, hogy utána a funkciót hányszer kell bugfix-elni.

- Program size: A megírt kódsorok számában is feltételezhetően Devil nyer (spagetti kódolás), szemben Angel jól átgondolt tömör kódjával.

- TCO: Mivel Devil egységnyi idő alatt több kódot ír és több funkciót készít el, ezért az egységnyi funkcióra eső fejlesztési költség is alacsonyabb.

- ROI: Mivel Devil gyorsabban készíti el a funkciókat, ezért több üzleti értéket teremt – legalábbis papíron.

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr555211613

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.

Nincsenek hozzászólások.
süti beállítások módosítása