ITÉlet

Az NJSZT Szoftvertechnológiai Fórumának rendezvényeire ritkán kerül sor, de általában érdekesek. Most sem volt másképp.

A rendezvényről magáról itt lehet olvasni. Az előadás PDF formátumban letölthető innen.

Az anyag elég hosszú (52 oldal), a fő üzenetet kiemelném:

Most software creators are not software professionals.

Végtelenül leegyszerűsítve és dióhéjban: a technológiának köszönhetően ma már a felhasználók is képesek arra, hogy alapvetően szoftvermérnöki feladatokat végrehajtsanak. Ilyen például az Excel makro írás, HTML kód építés copy-paste módszerrel, HTML kódba történő belejavítás, vagy Access alapon üzleti alkalmazás építés.

Habár ezeket a tevékenységeket nem nevezzük szoftverfejlesztésnek, de ezek olyan tevékenységek, amiket szoftverfejlesztők szoktak végezni.

A felismerés az, hogy a felhasználók képesek ezen egyszerű IT tevékenységek végrehajtására. Mary végzett egy felmérést, amiből kiderült, hogy valójában nagyon sok felhasználó nagyon sok „szoftvert” épít, számban messze felülmúlva a „hivatásos” szoftvermérnököket.

A prezentáció az USA-ban több mint 90 millió felhasználóval számol, akik többsége valamilyen módon „programozik”. Ehhez képest a hivatásos szoftvermérnökök száma kb 2.5 millió. Az arányok elképesztőek.

Közbevetés: nem is olyan régen írtam az Árnyék IT ökológiájáról, kb hasonló üzenettel: az IT osztályon túl is létezik IT, a felhasználók saját maguk belevágnak egy-egy szoftver fejlesztésbe (hogy milyen eredménnyel, az más kérdés).

Úgy vélem, hogy darabszámra valóban áll a tétel, azaz többen vannak az automatizált Excel formokat gyártó pénzügyesek, mint a pénzügyi rendszert fejlesztő szoftver mérnökök. Budget szempontjából is hasonló lehet a helyzet – miközben az IT költségeket mindenhol erősen nyírják, addig az üzleti költségvetésben elrejtett árnyék-projektek dagadnak.

Szóval a lényeg a lényeg: sokkal többen vannak a programkészítő felhasználók, mint a programkészítő mérnökök.

Az Internet a legnagyobb és leginkább szem előtt lévő példa (a legnagyobb Ultra Large Scale system). Az interneten rengeteg web oldal és szolgáltatás van, amit nem informatikusok készítettek.

Mivel a felhasználók többen (sokkal többen) vannak, ezért az alapvetőnek számító IT tételek Mary szerint nem érvényesek. Ilyenből rengeteg van, de íme 2: a programozás már nem csak a programról és a GUI-ról szól, illetve nem törvényszerű, hogy egy szoftverfejlesztésnek legyen vezetője.

Mindenképpen érdemes végignézni a prezentációt, mert sok érdemes gondolat van benne. Igaz az, hogy ma már jópár informatikai alaptétel nem érvényes. Ismerjük fel, hogy ma másképp fejlesztünk szoftvert, mint 10 vagy 20 éve, és majd 10-20 év múlva másképp fogunk szoftver fejleszteni.

De azt is érdemes látni, hogy mi a gyengéje a gondolatmenetnek. Mert úgy vélem, habár elgondolkodtató a „Most software creators are not software professionals” kijelentés, de nem igaz.

Legalább 2 ok miatt nem.

1. ok: Mit jelent szoftvert készíteni?

Nagyvállalati környezetben előfordul (elég gyakran), hogy a felhasználóknak elegük lesz saját IT-jukból, és az informatikusok kihagyásával informatikai projektbe vágnak. Klasszikus árnyék projekt. Kimondhatjuk, hogy ilyen mindenhol van. Például a pénzügyön, ahol nem kaptak megfelelő Data Warehouse rendszert ezért fejlesztettek egy Access adatbázist, vagy a marketingen, ahol BI rendszer hiányában kifejlesztettek valami hasonlót Excel alapokon.

Ezek a fejlesztések jól vagy rosszul, de mennek. Amíg a feladat egyszerű, és amíg megoldható copy-paste-tel, addig egész jól haladnak. Az még megy, hogy az interneten vagy a help-ben találnak egy lekérdezést, azt átmásolják és belepiszkálnak.

De ha a feladat meghaladja ezt, akkor megáll a tudomány. Amikor többre lenne szükség, mint a help-ben talált lekérdezés alkalmazására, akkor a „fejlesztési projekt” megtorpan és összeomlik.

Ilyenkor derül ki, hogy valójában a felhasználók nem programoztak, hanem csak utánozták a programozást. De ez csak utánzás volt. Messziről, illetve elemeiben programozásra hasonlít. Amint igazi, bonyolult programozási feladat kerül elő, azzal nem tudnak mit kezdeni.

És itt eljutottunk ahhoz, mi is a programozás definíciója. Analógiának megfelelő a házépítés. Tegyük fel, hogy levisz pár cserepet a szél a tetőről, tehát veszek a boltban új cserepet, hétvégén felmászok és megjavítom magam. Ez egy olyan tevékenység, amit a kőműves, az építész végez – ergo én házat építek és építész vagyok. Pedig nem csak utánoztam a kőművest. Halvány lila lövésem sincs, hogyan kell rendesen tetőt fedni, csak reménykedek benne, hogy jól csinálom, és a következő szél nem fogja levinni a cserepet. Ez nem más, mint szerencsejáték. Tudom, hogy nem vagyok kőműves, soha nem is állítanám magamról ezt. Ha ezt az analógiát elfogadjuk, akkor bizony a felhasználók sem készítenek programot.

2. ok: Nem az emberek száma, hanem a teremtett érték számít

A felmérés a mérnökök és a felhasználók számát arányosítja. Na most ez szerintem részrehajlás, hiszen nem az emberek száma a lényeg, hanem amit letettek az asztalra. Ha megnézzük egy vállalatnál, hogy mik a fő informatikai szolgáltatások és rendszerek, összevetve a szoftvermérnökök és a felhasználók által készített termékeket, akkor hiába látjuk a felhasználók óriási számú produktumát, de azok összességében jelentéktelenek.

Például hiába gyártanak le a könyvelők 200 darab automatizált Excel táblát, de a pénzügy lényegét mégiscsak a SAP adja – amit mérnökök fejlesztettek és mérnökök tartanak karban. 200 Excel tábla nem összehasonlítható az 1 darab SAP modul teljesítményével, és a vállalat számára termelt értékével.

Ugyanez a helyzet, ha az Internetet (mint a prezentációban többször emlegetett példát) tekintjük. Igaz, hogy az internet felhasználók jelentős része nem mérnök. De az Internet képét olyan cégek és alkalmazások formálták, mint a Facebook, a Google vagy Twitter – amiket egy csoport szoftver mérnök készített és tart karban. Hiába a felhasználók milliói, az a pár tucat mérnök mégiscsak túltesz rajtuk.

Annak ellenére, hogy nem igaz a kijelentés, azért még érdemes a gondolatmenettel foglalkozni.

Például azzal, hogy a felhasználók egyre több feladatot tudnak átvenni a mérnököktől, illetve hogy egyre több informatikai feladat végrehajtásához nem lesz szükség diplomás mérnökre. Idővel egyre több és több feladat végrehajtható mérnök nélkül – de sosem fogjuk elérni azt a pontot, amikor nincs szükség mérnökre. Mert mérnökre mindig szükség lesz.

Az is igaz, hogy a diplomás mérnök és a technológiához nem értő felhasznál között széles a skála. Ott vannak a wannabe programozók, a kódvető kisiparosok, a web site specialisták, vagy az otthon 3 szerveres hálózatot üzemeltető pénzügyi igazgató.

A történet az a része is igaz, hogy a szoftver fejlesztés változik, bizonyos mértékben. De az, amit az egyetemen tanultunk programozás címszó alatt, az megmarad. Radiális változások nincsenek és nem is lesznek, apró változások igen.

Például az bizonyos, hogy 50 év múlva is a fejlesztési projektet projektvezető vezeti, egy személyben, központosított módon. (Ez ugyanis a vállalatok működési sajátossága, semmi köze sincs az aktuális IT trendekhez.)

De az már kevésbé bizonyos, hogyan fogjuk 50 év múlva kezelni a felhasználói igényeket.

Az NJSZT Szoftvertechnológiai Fórumának rendezvényeire ritkán kerül sor, de általában érdekesek. Most sem volt másképp.

A rendezvényről magáról itt lehet olvasni. Az előadás PDF formátumban letölthető innen.

Az anyag elég hosszú (52 oldal), a fő üzenetet kiemelném:

Most software creators are not software professionals.

Végtelenül leegyszerűsítve és dióhéjban: a technológiának köszönhetően ma már a felhasználók is képesek arra, hogy alapvetően szoftvermérnöki feladatokat végrehajtsanak. Ilyen például az Excel makro írás, HTML kód építés copy-paste módszerrel, HTML kódba történő belejavítás, vagy Access alapon üzleti alkalmazás építés.

Habár ezeket a tevékenységeket nem nevezzük szoftverfejlesztésnek, de ezek olyan tevékenységek, amiket szoftverfejlesztők szoktak végezni.

A felismerés az, hogy a felhasználók képesek ezen egyszerű IT tevékenységek végrehajtására. Mary végzett egy felmérést, amiből kiderült, hogy valójában nagyon sok felhasználó nagyon sok „szoftvert” épít, számban messze felülmúlva a „hivatásos” szoftvermérnököket.

A prezentáció az USA-ban több mint 90 millió felhasználóval számol, akik többsége valamilyen módon „programozik”. Ehhez képest a hivatásos szoftvermérnökök száma kb 2.5 millió. Az arányok elképesztőek.

Közbevetés: nem is olyan régen írtam az Árnyék IT ökológiájáról, kb hasonló üzenettel: az IT osztályon túl is létezik IT, a felhasználók saját maguk belevágnak egy-egy szoftver fejlesztésbe (hogy milyen eredménnyel, az más kérdés).

Úgy vélem, hogy darabszámra valóban áll a tétel, azaz többen vannak az automatizált Excel formokat gyártó pénzügyesek, mint a pénzügyi rendszert fejlesztő szoftver mérnökök. Budget szempontjából is hasonló lehet a helyzet – miközben az IT költségeket mindenhol erősen nyírják, addig az üzleti költségvetésben elrejtett árnyék-projektek dagadnak.

Szóval a lényeg a lényeg: sokkal többen vannak a programkészítő felhasználók, mint a programkészítő mérnökök.

Az Internet a legnagyobb és leginkább szem előtt lévő példa (a legnagyobb Ultra Large Scale system). Az interneten rengeteg web oldal és szolgáltatás van, amit nem informatikusok készítettek.

Mivel a felhasználók többen (sokkal többen) vannak, ezért az alapvetőnek számító IT tételek Mary szerint nem érvényesek. Ilyenből rengeteg van, de íme 2: a programozás már nem csak a programról és a GUI-ról szól, illetve nem törvényszerű, hogy egy szoftverfejlesztésnek legyen vezetője.

Mindenképpen érdemes végignézni a prezentációt, mert sok érdemes gondolat van benne. Igaz az, hogy ma már jópár informatikai alaptétel nem érvényes. Ismerjük fel, hogy ma másképp fejlesztünk szoftvert, mint 10 vagy 20 éve, és majd 10-20 év múlva másképp fogunk szoftver fejleszteni.

De azt is érdemes látni, hogy mi a gyengéje a gondolatmenetnek. Mert úgy vélem, habár elgondolkodtató a „Most software creators are not software professionals” kijelentés, de nem igaz.

Legalább 2 ok miatt nem.

1. ok: Mit jelent szoftvert készíteni?

Nagyvállalati környezetben előfordul (elég gyakran), hogy a felhasználóknak elegük lesz saját IT-jukból, és az informatikusok kihagyásával informatikai projektbe vágnak. Klasszikus árnyék projekt. Kimondhatjuk, hogy ilyen mindenhol van. Például a pénzügyön, ahol nem kaptak megfelelő Data Warehouse rendszert ezért fejlesztettek egy Access adatbázist, vagy a marketingen, ahol BI rendszer hiányában kifejlesztettek valami hasonlót Excel alapokon.

Ezek a fejlesztések jól vagy rosszul, de mennek. Amíg a feladat egyszerű, és amíg megoldható copy-paste-tel, addig egész jól haladnak. Az még megy, hogy az interneten vagy a help-ben találnak egy lekérdezést, azt átmásolják és belepiszkálnak.

De ha a feladat meghaladja ezt, akkor megáll a tudomány. Amikor többre lenne szükség, mint a help-ben talált lekérdezés alkalmazására, akkor a „fejlesztési projekt” megtorpan és összeomlik.

Ilyenkor derül ki, hogy valójában a felhasználók nem programoztak, hanem csak utánozták a programozást. De ez csak utánzás volt. Messziről, illetve elemeiben programozásra hasonlít. Amint igazi, bonyolult programozási feladat kerül elő, azzal nem tudnak mit kezdeni.

És itt eljutottunk ahhoz, mi is a programozás definíciója. Analógiának megfelelő a házépítés. Tegyük fel, hogy levisz pár cserepet a szél a tetőről, tehát veszek a boltban új cserepet, hétvégén felmászok és megjavítom magam. Ez egy olyan tevékenység, amit a kőműves, az építész végez – ergo én házat építek és építész vagyok. Pedig nem csak utánoztam a kőművest. Halvány lila lövésem sincs, hogyan kell rendesen tetőt fedni, csak reménykedek benne, hogy jól csinálom, és a következő szél nem fogja levinni a cserepet. Ez nem más, mint szerencsejáték. Tudom, hogy nem vagyok kőműves, soha nem is állítanám magamról ezt. Ha ezt az analógiát elfogadjuk, akkor bizony a felhasználók sem készítenek programot.

2. ok: Nem az emberek száma, hanem a teremtett érték számít

A felmérés a mérnökök és a felhasználók számát arányosítja. Na most ez szerintem részrehajlás, hiszen nem az emberek száma a lényeg, hanem amit letettek az asztalra. Ha megnézzük egy vállalatnál, hogy mik a fő informatikai szolgáltatások és rendszerek, összevetve a szoftvermérnökök és a felhasználók által készített termékeket, akkor hiába látjuk a felhasználók óriási számú produktumát, de azok összességében jelentéktelenek.

Például hiába gyártanak le a könyvelők 200 darab automatizált Excel táblát, de a pénzügy lényegét mégiscsak a SAP adja – amit mérnökök fejlesztettek és mérnökök tartanak karban. 200 Excel tábla nem összehasonlítható az 1 darab SAP modul teljesítményével, és a vállalat számára termelt értékével.

Ugyanez a helyzet, ha az Internetet (mint a prezentációban többször emlegetett példát) tekintjük. Igaz, hogy az internet felhasználók jelentős része nem mérnök. De az Internet képét olyan cégek és alkalmazások formálták, mint a Facebook, a Google vagy Twitter – amiket egy csoport szoftver mérnök készített és tart karban. Hiába a felhasználók milliói, az a pár tucat mérnök mégiscsak túltesz rajtuk.

Annak ellenére, hogy nem igaz a kijelentés, azért még érdemes a gondolatmenettel foglalkozni.

Például azzal, hogy a felhasználók egyre több feladatot tudnak átvenni a mérnököktől, illetve hogy egyre több informatikai feladat végrehajtásához nem lesz szükség diplomás mérnökre. Idővel egyre több és több feladat végrehajtható mérnök nélkül – de sosem fogjuk elérni azt a pontot, amikor nincs szükség mérnökre. Mert mérnökre mindig szükség lesz.

Az is igaz, hogy a diplomás mérnök és a technológiához nem értő felhasznál között széles a skála. Ott vannak a wannabe programozók, a kódvető kisiparosok, a web site specialisták, vagy az otthon 3 szerveres hálózatot üzemeltető pénzügyi igazgató.

A történet az a része is igaz, hogy a szoftver fejlesztés változik, bizonyos mértékben. De az, amit az egyetemen tanultunk programozás címszó alatt, az megmarad. Radiális változások nincsenek és nem is lesznek, apró változások igen.

Például az bizonyos, hogy 50 év múlva is a fejlesztési projektet projektvezető vezeti, egy személyben, központosított módon. (Ez ugyanis a vállalatok működési sajátossága, semmi köze sincs az aktuális IT trendekhez.)

De az már kevésbé bizonyos, hogyan fogjuk 50 év múlva kezelni a felhasználói igényeket.

Outsourcing az, amit minden nagyvállalat csinál, de nem mindenki csinálja jól. A legtöbb esetben a megrendelő naiv, túlzott – vagy épp ellenkezőleg, túl alacsony – elvárásai vannak, ami mindenféle káros pótcselekvéshez vezet. Az alábbiakban leírok néhány hasznos tanácsot.

Még mielőtt belekezdenénk, mindenkit kérek olvassa el a márciusban megjelent Őszintén az outsourcing-ról című cikket. Ott sok lényegi információ szerepel, ami fontos lesz a tanácsok megértéséhez.

Hogyan lehet a kiszervezést jól csinálni? Az alábbiakban néhány gyakorlati tanácsot osztok meg, a teljesség igénye nélkül.

Mint mindig, itt is a piszkos anyagaikon múlik minden. Egyik oldalon azt szeretnénk, hogy az informatikai szolgáltatások minősége ne romoljon – tehát a legjobb embereket kapjuk meg, akik a lelküket is kiteszik értünk -, a másik oldalon viszont ezt a munkát harmad áron végezzék.

Melyik konstrukció a legjobb, fixed price, time&material, projekt alapú elszámolás vagy elvégzett munka alapján?

Kezdjük hátulról. Elvégzett munka alapján fizetni logikusnak tűnik, csak éppen nem világos, mi az elvégezett munka, illetve mi a hasznosan elvégzett munka. Erre a tanácsadók azt mondják, hogy a lezárt ticket-ek alapján fizessünk, darabra. Szerintem ez a létező legrosszabb, hiszen gyakorlatilag azért fizetjük a fejlesztőket, hogy rossz munkát végezzenek. A rossz munka ugyanis több ticket-et jelent, sok apró hibát. Előbb-utóbb ez a konstrukció oda vezet, hogy a fejlesztők tudatosan bug-okat írnak bugfix helyett.

A projekt alapú elszámolás a kockázatok miatt azt fogja jelenteni, hogy az outsourcing partner rengeteg tartalékot épít az árba, tehát drága lesz.

A fixed price és a time&material jó megoldások. A fixed price a beszállító nagyobb önállóságára épít, a T&M pedig arra, hogy a megrendelő jobban kézben tartja a munkát.

Amikor az együttműködés szerződéses kereteit meghatározzuk, akkor ne felejtsük el, hogy mindenki másképp dolgozik, nem létezik egyetlen jó módszer. Lesznek olyan csoportok, akik szakmailag erősek, de lesznek, akik nem annyira. Lesznek nagy fejlesztői csapatok, és lesznek kicsik. Lesznek menedzserek, akik intelligens majomként kezelik a külső fejlesztőiket, míg mások teret adnak a fejlesztői kreativitásnak. Lesznek olyan csapatok, akik agilisan, dinamikusan dolgoznak, és lesznek olyanok, ahol inkább policy-k és szokások mentén.

Tehát a kiszervezés mindig arról szól, hogy egymástól függetlenül működő silókat építünk. Ez tény, hiszen a megrendelői oldalon ülő menedzserek munkastílusa különböző, a körülmények különbözőek, a beszállítói oldalon lévő csapat adottságai is egyedik. A lényeg tehát nem az, hogy mi a legjobb megoldás, hanem az, hogy mik az igényeink és milyen anyagból dolgozunk.

Tegyük fel, hogy van 10 fejlesztőnk Indiában – időzóna, kulturális különbség, nyelvi problémák. Hogyan lehet a munkát irányítani, a fejlesztőket kézben tartani? Sem a túlzott kontroll, sem a teljes szabadság nem jó. Két legjobb módszer létezik:         
1) A csapat egyik tagját csapatvezetőnek nevezzük ki, és hagyjuk, hogy ő irányítsa a fejlesztőket
2) A fejlesztőket mikromenedzseljük, tipikusan úgy, hogy párokba szervezzük a belső és külső embereket, minden belső ember kap egy külső fejlesztőt, akivel párban dolgozik közös feladaton.

Az egész azon múlik, mekkora szabadságot adunk a fejlesztőknek, illetve van-e csapatvezetőnek alkalmas személy a csapatban.

Miután sikeresen felépítettük a silónkat, megeshet, hogy jön valaki és bele akar szólni. Ha sikerült összehangolni az onsite és offshore csapatokat, és a kooperáció működik, akkor ne engedjük, hogy abba valaki beleszóljon!

Már írtam róla cikket, hogy túlzott bürokráciával, például timesheet kitöltésével nem fogjuk tudni növelni a hatékonyságot. A túlzott bürokrácia alkalmas arra, hogy bizonyos veszteségeket megtaláljunk (például egy gyenge fejlesztő vagy egy naplopó), de ugyanakkor ennek ára van – a fejlesztők érdemi munka helyett adminisztrációval töltik az idejüket.

Amikor külső fejlesztői csapattal dolgozunk, azt hisszük, hogy mint megrendelő, mi vezetjük a fejlesztőket. Ez nem igaz. A külső csapatnak megvan a saját menedzsere, a saját QA-sa. Lehet, hogy ezt a személyt nem ismerjük, de ettől még létezik. Elképzelhető, hogy a partnernél dolgozó menedzser és a megrendelő egymással ellentétes utasításokat ad a fejlesztőknek – akik aztán saját elképzeléseik alapján vagy egyiknek, vagy másiknak engedelmeskednek. Éppen ezért fontos, hogy beazonosítsuk ezt a vezetőt és összehangoljuk a célokat.

A külső csapatnak nem csak saját menedzsere van, hanem saját controlling/monitoring eljárásai. Akár kéri a megrendelő, akár nem, a külső fejlesztő csapat rendszeresen report-ál az elvégzendő és elvégzett feladatokról saját vezetőiknek, akik ezeket az információkat vezetői szinten összesítik. Meglehet, hogy az összesített report egészen más státuszt tartalmaz, mint amit a megrendelő gondol. Például lehet, hogy miközben a megrendelő elégedett a munkával, a cég QA-sa szerint csapnivaló a minőség. Vagy ellenkezőleg, a fejlesztők szerint minden zöld, miközben a megrendelő elégedetlen.

Célszerű felderíteni, hogyan biztosítja a minőséget partnerünk, milyen report-okat gyártanak, és elérni, hogy ezeket hangolják össze a megrendelővel.

Megesik, hogy a partnerünk fogja a legjobb fejlesztőket és elveszi, hogy cserébe kezdőket adjon – természetesen ugyanolyan áron. Ezért célszerű kikötni, a megrendelőnek is legyen beleszólása a HR döntésekbe. Például a leendő fejlesztővel legyen egy formális interjú (önéletrajz megosztással), ahol az ügyfélnek legyen joga a nem megfelelő fejlesztőt visszautasítani. Ekkor a partnernek is érdeke lesz, hogy tapasztalt fejlesztőket adjon.

A korábban írt cikkben szó volt a bizalomról. Kiszervezés esetén mindig felmerül a kérdés, mekkora szabadságot adjunk a külső csapatnak. A tény az, hogy mindegy milyen szerződést írunk és milyen módon ellenőrizzük a teljesítést, a kiszervezett erőforrások fölött csak korlátozott hatalmunk lesz.

A kiszervezés körül a kulcskérdés mindig az, hogy kinek a kezében lesz tudás. Nos, ha a tudást teljes egészében kiadjuk a kezünkből – azaz nem ismerjük saját rendszereinket és nem értünk a technológiákhoz – akkor az sosem lesz jó. Függetlenül attól, hogy a beszállítónk mennyire jó. A helyes felállás az, amikor a fejlesztőcsapat vegyes: külsősökből és belsősökből áll. A tudás legyen közös, mint ahogy a munka és az eredmény is közös.

Outsourcing az, amit minden nagyvállalat csinál, de nem mindenki csinálja jól. A legtöbb esetben a megrendelő naiv, túlzott – vagy épp ellenkezőleg, túl alacsony – elvárásai vannak, ami mindenféle káros pótcselekvéshez vezet. Az alábbiakban leírok néhány hasznos tanácsot.

Még mielőtt belekezdenénk, mindenkit kérek olvassa el a márciusban megjelent Őszintén az outsourcing-ról című cikket. Ott sok lényegi információ szerepel, ami fontos lesz a tanácsok megértéséhez.

Hogyan lehet a kiszervezést jól csinálni? Az alábbiakban néhány gyakorlati tanácsot osztok meg, a teljesség igénye nélkül.

Mint mindig, itt is a piszkos anyagaikon múlik minden. Egyik oldalon azt szeretnénk, hogy az informatikai szolgáltatások minősége ne romoljon – tehát a legjobb embereket kapjuk meg, akik a lelküket is kiteszik értünk -, a másik oldalon viszont ezt a munkát harmad áron végezzék.

Melyik konstrukció a legjobb, fixed price, time&material, projekt alapú elszámolás vagy elvégzett munka alapján?

Kezdjük hátulról. Elvégzett munka alapján fizetni logikusnak tűnik, csak éppen nem világos, mi az elvégezett munka, illetve mi a hasznosan elvégzett munka. Erre a tanácsadók azt mondják, hogy a lezárt ticket-ek alapján fizessünk, darabra. Szerintem ez a létező legrosszabb, hiszen gyakorlatilag azért fizetjük a fejlesztőket, hogy rossz munkát végezzenek. A rossz munka ugyanis több ticket-et jelent, sok apró hibát. Előbb-utóbb ez a konstrukció oda vezet, hogy a fejlesztők tudatosan bug-okat írnak bugfix helyett.

A projekt alapú elszámolás a kockázatok miatt azt fogja jelenteni, hogy az outsourcing partner rengeteg tartalékot épít az árba, tehát drága lesz.

A fixed price és a time&material jó megoldások. A fixed price a beszállító nagyobb önállóságára épít, a T&M pedig arra, hogy a megrendelő jobban kézben tartja a munkát.

Amikor az együttműködés szerződéses kereteit meghatározzuk, akkor ne felejtsük el, hogy mindenki másképp dolgozik, nem létezik egyetlen jó módszer. Lesznek olyan csoportok, akik szakmailag erősek, de lesznek, akik nem annyira. Lesznek nagy fejlesztői csapatok, és lesznek kicsik. Lesznek menedzserek, akik intelligens majomként kezelik a külső fejlesztőiket, míg mások teret adnak a fejlesztői kreativitásnak. Lesznek olyan csapatok, akik agilisan, dinamikusan dolgoznak, és lesznek olyanok, ahol inkább policy-k és szokások mentén.

Tehát a kiszervezés mindig arról szól, hogy egymástól függetlenül működő silókat építünk. Ez tény, hiszen a megrendelői oldalon ülő menedzserek munkastílusa különböző, a körülmények különbözőek, a beszállítói oldalon lévő csapat adottságai is egyedik. A lényeg tehát nem az, hogy mi a legjobb megoldás, hanem az, hogy mik az igényeink és milyen anyagból dolgozunk.

Tegyük fel, hogy van 10 fejlesztőnk Indiában – időzóna, kulturális különbség, nyelvi problémák. Hogyan lehet a munkát irányítani, a fejlesztőket kézben tartani? Sem a túlzott kontroll, sem a teljes szabadság nem jó. Két legjobb módszer létezik:         
1) A csapat egyik tagját csapatvezetőnek nevezzük ki, és hagyjuk, hogy ő irányítsa a fejlesztőket
2) A fejlesztőket mikromenedzseljük, tipikusan úgy, hogy párokba szervezzük a belső és külső embereket, minden belső ember kap egy külső fejlesztőt, akivel párban dolgozik közös feladaton.

Az egész azon múlik, mekkora szabadságot adunk a fejlesztőknek, illetve van-e csapatvezetőnek alkalmas személy a csapatban.

Miután sikeresen felépítettük a silónkat, megeshet, hogy jön valaki és bele akar szólni. Ha sikerült összehangolni az onsite és offshore csapatokat, és a kooperáció működik, akkor ne engedjük, hogy abba valaki beleszóljon!

Már írtam róla cikket, hogy túlzott bürokráciával, például timesheet kitöltésével nem fogjuk tudni növelni a hatékonyságot. A túlzott bürokrácia alkalmas arra, hogy bizonyos veszteségeket megtaláljunk (például egy gyenge fejlesztő vagy egy naplopó), de ugyanakkor ennek ára van – a fejlesztők érdemi munka helyett adminisztrációval töltik az idejüket.

Amikor külső fejlesztői csapattal dolgozunk, azt hisszük, hogy mint megrendelő, mi vezetjük a fejlesztőket. Ez nem igaz. A külső csapatnak megvan a saját menedzsere, a saját QA-sa. Lehet, hogy ezt a személyt nem ismerjük, de ettől még létezik. Elképzelhető, hogy a partnernél dolgozó menedzser és a megrendelő egymással ellentétes utasításokat ad a fejlesztőknek – akik aztán saját elképzeléseik alapján vagy egyiknek, vagy másiknak engedelmeskednek. Éppen ezért fontos, hogy beazonosítsuk ezt a vezetőt és összehangoljuk a célokat.

A külső csapatnak nem csak saját menedzsere van, hanem saját controlling/monitoring eljárásai. Akár kéri a megrendelő, akár nem, a külső fejlesztő csapat rendszeresen report-ál az elvégzendő és elvégzett feladatokról saját vezetőiknek, akik ezeket az információkat vezetői szinten összesítik. Meglehet, hogy az összesített report egészen más státuszt tartalmaz, mint amit a megrendelő gondol. Például lehet, hogy miközben a megrendelő elégedett a munkával, a cég QA-sa szerint csapnivaló a minőség. Vagy ellenkezőleg, a fejlesztők szerint minden zöld, miközben a megrendelő elégedetlen.

Célszerű felderíteni, hogyan biztosítja a minőséget partnerünk, milyen report-okat gyártanak, és elérni, hogy ezeket hangolják össze a megrendelővel.

Megesik, hogy a partnerünk fogja a legjobb fejlesztőket és elveszi, hogy cserébe kezdőket adjon – természetesen ugyanolyan áron. Ezért célszerű kikötni, a megrendelőnek is legyen beleszólása a HR döntésekbe. Például a leendő fejlesztővel legyen egy formális interjú (önéletrajz megosztással), ahol az ügyfélnek legyen joga a nem megfelelő fejlesztőt visszautasítani. Ekkor a partnernek is érdeke lesz, hogy tapasztalt fejlesztőket adjon.

A korábban írt cikkben szó volt a bizalomról. Kiszervezés esetén mindig felmerül a kérdés, mekkora szabadságot adjunk a külső csapatnak. A tény az, hogy mindegy milyen szerződést írunk és milyen módon ellenőrizzük a teljesítést, a kiszervezett erőforrások fölött csak korlátozott hatalmunk lesz.

A kiszervezés körül a kulcskérdés mindig az, hogy kinek a kezében lesz tudás. Nos, ha a tudást teljes egészében kiadjuk a kezünkből – azaz nem ismerjük saját rendszereinket és nem értünk a technológiákhoz – akkor az sosem lesz jó. Függetlenül attól, hogy a beszállítónk mennyire jó. A helyes felállás az, amikor a fejlesztőcsapat vegyes: külsősökből és belsősökből áll. A tudás legyen közös, mint ahogy a munka és az eredmény is közös.

Outsourcing az, amit minden nagyvállalat csinál, de nem mindenki csinálja jól. A legtöbb esetben a megrendelő naiv, túlzott – vagy épp ellenkezőleg, túl alacsony – elvárásai vannak, ami mindenféle káros pótcselekvéshez vezet. Az alábbiakban leírok néhány hasznos tanácsot.

Még mielőtt belekezdenénk, mindenkit kérek olvassa el a márciusban megjelent Őszintén az outsourcing-ról című cikket. Ott sok lényegi információ szerepel, ami fontos lesz a tanácsok megértéséhez.

Hogyan lehet a kiszervezést jól csinálni? Az alábbiakban néhány gyakorlati tanácsot osztok meg, a teljesség igénye nélkül.

Mint mindig, itt is a piszkos anyagaikon múlik minden. Egyik oldalon azt szeretnénk, hogy az informatikai szolgáltatások minősége ne romoljon – tehát a legjobb embereket kapjuk meg, akik a lelküket is kiteszik értünk -, a másik oldalon viszont ezt a munkát harmad áron végezzék.

Melyik konstrukció a legjobb, fixed price, time&material, projekt alapú elszámolás vagy elvégzett munka alapján?

Kezdjük hátulról. Elvégzett munka alapján fizetni logikusnak tűnik, csak éppen nem világos, mi az elvégezett munka, illetve mi a hasznosan elvégzett munka. Erre a tanácsadók azt mondják, hogy a lezárt ticket-ek alapján fizessünk, darabra. Szerintem ez a létező legrosszabb, hiszen gyakorlatilag azért fizetjük a fejlesztőket, hogy rossz munkát végezzenek. A rossz munka ugyanis több ticket-et jelent, sok apró hibát. Előbb-utóbb ez a konstrukció oda vezet, hogy a fejlesztők tudatosan bug-okat írnak bugfix helyett.

A projekt alapú elszámolás a kockázatok miatt azt fogja jelenteni, hogy az outsourcing partner rengeteg tartalékot épít az árba, tehát drága lesz.

A fixed price és a time&material jó megoldások. A fixed price a beszállító nagyobb önállóságára épít, a T&M pedig arra, hogy a megrendelő jobban kézben tartja a munkát.

Amikor az együttműködés szerződéses kereteit meghatározzuk, akkor ne felejtsük el, hogy mindenki másképp dolgozik, nem létezik egyetlen jó módszer. Lesznek olyan csoportok, akik szakmailag erősek, de lesznek, akik nem annyira. Lesznek nagy fejlesztői csapatok, és lesznek kicsik. Lesznek menedzserek, akik intelligens majomként kezelik a külső fejlesztőiket, míg mások teret adnak a fejlesztői kreativitásnak. Lesznek olyan csapatok, akik agilisan, dinamikusan dolgoznak, és lesznek olyanok, ahol inkább policy-k és szokások mentén.

Tehát a kiszervezés mindig arról szól, hogy egymástól függetlenül működő silókat építünk. Ez tény, hiszen a megrendelői oldalon ülő menedzserek munkastílusa különböző, a körülmények különbözőek, a beszállítói oldalon lévő csapat adottságai is egyedik. A lényeg tehát nem az, hogy mi a legjobb megoldás, hanem az, hogy mik az igényeink és milyen anyagból dolgozunk.

Tegyük fel, hogy van 10 fejlesztőnk Indiában – időzóna, kulturális különbség, nyelvi problémák. Hogyan lehet a munkát irányítani, a fejlesztőket kézben tartani? Sem a túlzott kontroll, sem a teljes szabadság nem jó. Két legjobb módszer létezik:         
1) A csapat egyik tagját csapatvezetőnek nevezzük ki, és hagyjuk, hogy ő irányítsa a fejlesztőket
2) A fejlesztőket mikromenedzseljük, tipikusan úgy, hogy párokba szervezzük a belső és külső embereket, minden belső ember kap egy külső fejlesztőt, akivel párban dolgozik közös feladaton.

Az egész azon múlik, mekkora szabadságot adunk a fejlesztőknek, illetve van-e csapatvezetőnek alkalmas személy a csapatban.

Miután sikeresen felépítettük a silónkat, megeshet, hogy jön valaki és bele akar szólni. Ha sikerült összehangolni az onsite és offshore csapatokat, és a kooperáció működik, akkor ne engedjük, hogy abba valaki beleszóljon!

Már írtam róla cikket, hogy túlzott bürokráciával, például timesheet kitöltésével nem fogjuk tudni növelni a hatékonyságot. A túlzott bürokrácia alkalmas arra, hogy bizonyos veszteségeket megtaláljunk (például egy gyenge fejlesztő vagy egy naplopó), de ugyanakkor ennek ára van – a fejlesztők érdemi munka helyett adminisztrációval töltik az idejüket.

Amikor külső fejlesztői csapattal dolgozunk, azt hisszük, hogy mint megrendelő, mi vezetjük a fejlesztőket. Ez nem igaz. A külső csapatnak megvan a saját menedzsere, a saját QA-sa. Lehet, hogy ezt a személyt nem ismerjük, de ettől még létezik. Elképzelhető, hogy a partnernél dolgozó menedzser és a megrendelő egymással ellentétes utasításokat ad a fejlesztőknek – akik aztán saját elképzeléseik alapján vagy egyiknek, vagy másiknak engedelmeskednek. Éppen ezért fontos, hogy beazonosítsuk ezt a vezetőt és összehangoljuk a célokat.

A külső csapatnak nem csak saját menedzsere van, hanem saját controlling/monitoring eljárásai. Akár kéri a megrendelő, akár nem, a külső fejlesztő csapat rendszeresen report-ál az elvégzendő és elvégzett feladatokról saját vezetőiknek, akik ezeket az információkat vezetői szinten összesítik. Meglehet, hogy az összesített report egészen más státuszt tartalmaz, mint amit a megrendelő gondol. Például lehet, hogy miközben a megrendelő elégedett a munkával, a cég QA-sa szerint csapnivaló a minőség. Vagy ellenkezőleg, a fejlesztők szerint minden zöld, miközben a megrendelő elégedetlen.

Célszerű felderíteni, hogyan biztosítja a minőséget partnerünk, milyen report-okat gyártanak, és elérni, hogy ezeket hangolják össze a megrendelővel.

Megesik, hogy a partnerünk fogja a legjobb fejlesztőket és elveszi, hogy cserébe kezdőket adjon – természetesen ugyanolyan áron. Ezért célszerű kikötni, a megrendelőnek is legyen beleszólása a HR döntésekbe. Például a leendő fejlesztővel legyen egy formális interjú (önéletrajz megosztással), ahol az ügyfélnek legyen joga a nem megfelelő fejlesztőt visszautasítani. Ekkor a partnernek is érdeke lesz, hogy tapasztalt fejlesztőket adjon.

A korábban írt cikkben szó volt a bizalomról. Kiszervezés esetén mindig felmerül a kérdés, mekkora szabadságot adjunk a külső csapatnak. A tény az, hogy mindegy milyen szerződést írunk és milyen módon ellenőrizzük a teljesítést, a kiszervezett erőforrások fölött csak korlátozott hatalmunk lesz.

A kiszervezés körül a kulcskérdés mindig az, hogy kinek a kezében lesz tudás. Nos, ha a tudást teljes egészében kiadjuk a kezünkből – azaz nem ismerjük saját rendszereinket és nem értünk a technológiákhoz – akkor az sosem lesz jó. Függetlenül attól, hogy a beszállítónk mennyire jó. A helyes felállás az, amikor a fejlesztőcsapat vegyes: külsősökből és belsősökből áll. A tudás legyen közös, mint ahogy a munka és az eredmény is közös.

Outsourcing az, amit minden nagyvállalat csinál, de nem mindenki csinálja jól. A legtöbb esetben a megrendelő naiv, túlzott – vagy épp ellenkezőleg, túl alacsony – elvárásai vannak, ami mindenféle káros pótcselekvéshez vezet. Az alábbiakban leírok néhány hasznos tanácsot.

Még mielőtt belekezdenénk, mindenkit kérek olvassa el a márciusban megjelent Őszintén az outsourcing-ról című cikket. Ott sok lényegi információ szerepel, ami fontos lesz a tanácsok megértéséhez.

Hogyan lehet a kiszervezést jól csinálni? Az alábbiakban néhány gyakorlati tanácsot osztok meg, a teljesség igénye nélkül.

Mint mindig, itt is a piszkos anyagaikon múlik minden. Egyik oldalon azt szeretnénk, hogy az informatikai szolgáltatások minősége ne romoljon – tehát a legjobb embereket kapjuk meg, akik a lelküket is kiteszik értünk -, a másik oldalon viszont ezt a munkát harmad áron végezzék.

Melyik konstrukció a legjobb, fixed price, time&material, projekt alapú elszámolás vagy elvégzett munka alapján?

Kezdjük hátulról. Elvégzett munka alapján fizetni logikusnak tűnik, csak éppen nem világos, mi az elvégezett munka, illetve mi a hasznosan elvégzett munka. Erre a tanácsadók azt mondják, hogy a lezárt ticket-ek alapján fizessünk, darabra. Szerintem ez a létező legrosszabb, hiszen gyakorlatilag azért fizetjük a fejlesztőket, hogy rossz munkát végezzenek. A rossz munka ugyanis több ticket-et jelent, sok apró hibát. Előbb-utóbb ez a konstrukció oda vezet, hogy a fejlesztők tudatosan bug-okat írnak bugfix helyett.

A projekt alapú elszámolás a kockázatok miatt azt fogja jelenteni, hogy az outsourcing partner rengeteg tartalékot épít az árba, tehát drága lesz.

A fixed price és a time&material jó megoldások. A fixed price a beszállító nagyobb önállóságára épít, a T&M pedig arra, hogy a megrendelő jobban kézben tartja a munkát.

Amikor az együttműködés szerződéses kereteit meghatározzuk, akkor ne felejtsük el, hogy mindenki másképp dolgozik, nem létezik egyetlen jó módszer. Lesznek olyan csoportok, akik szakmailag erősek, de lesznek, akik nem annyira. Lesznek nagy fejlesztői csapatok, és lesznek kicsik. Lesznek menedzserek, akik intelligens majomként kezelik a külső fejlesztőiket, míg mások teret adnak a fejlesztői kreativitásnak. Lesznek olyan csapatok, akik agilisan, dinamikusan dolgoznak, és lesznek olyanok, ahol inkább policy-k és szokások mentén.

Tehát a kiszervezés mindig arról szól, hogy egymástól függetlenül működő silókat építünk. Ez tény, hiszen a megrendelői oldalon ülő menedzserek munkastílusa különböző, a körülmények különbözőek, a beszállítói oldalon lévő csapat adottságai is egyedik. A lényeg tehát nem az, hogy mi a legjobb megoldás, hanem az, hogy mik az igényeink és milyen anyagból dolgozunk.

Tegyük fel, hogy van 10 fejlesztőnk Indiában – időzóna, kulturális különbség, nyelvi problémák. Hogyan lehet a munkát irányítani, a fejlesztőket kézben tartani? Sem a túlzott kontroll, sem a teljes szabadság nem jó. Két legjobb módszer létezik:         
1) A csapat egyik tagját csapatvezetőnek nevezzük ki, és hagyjuk, hogy ő irányítsa a fejlesztőket
2) A fejlesztőket mikromenedzseljük, tipikusan úgy, hogy párokba szervezzük a belső és külső embereket, minden belső ember kap egy külső fejlesztőt, akivel párban dolgozik közös feladaton.

Az egész azon múlik, mekkora szabadságot adunk a fejlesztőknek, illetve van-e csapatvezetőnek alkalmas személy a csapatban.

Miután sikeresen felépítettük a silónkat, megeshet, hogy jön valaki és bele akar szólni. Ha sikerült összehangolni az onsite és offshore csapatokat, és a kooperáció működik, akkor ne engedjük, hogy abba valaki beleszóljon!

Már írtam róla cikket, hogy túlzott bürokráciával, például timesheet kitöltésével nem fogjuk tudni növelni a hatékonyságot. A túlzott bürokrácia alkalmas arra, hogy bizonyos veszteségeket megtaláljunk (például egy gyenge fejlesztő vagy egy naplopó), de ugyanakkor ennek ára van – a fejlesztők érdemi munka helyett adminisztrációval töltik az idejüket.

Amikor külső fejlesztői csapattal dolgozunk, azt hisszük, hogy mint megrendelő, mi vezetjük a fejlesztőket. Ez nem igaz. A külső csapatnak megvan a saját menedzsere, a saját QA-sa. Lehet, hogy ezt a személyt nem ismerjük, de ettől még létezik. Elképzelhető, hogy a partnernél dolgozó menedzser és a megrendelő egymással ellentétes utasításokat ad a fejlesztőknek – akik aztán saját elképzeléseik alapján vagy egyiknek, vagy másiknak engedelmeskednek. Éppen ezért fontos, hogy beazonosítsuk ezt a vezetőt és összehangoljuk a célokat.

A külső csapatnak nem csak saját menedzsere van, hanem saját controlling/monitoring eljárásai. Akár kéri a megrendelő, akár nem, a külső fejlesztő csapat rendszeresen report-ál az elvégzendő és elvégzett feladatokról saját vezetőiknek, akik ezeket az információkat vezetői szinten összesítik. Meglehet, hogy az összesített report egészen más státuszt tartalmaz, mint amit a megrendelő gondol. Például lehet, hogy miközben a megrendelő elégedett a munkával, a cég QA-sa szerint csapnivaló a minőség. Vagy ellenkezőleg, a fejlesztők szerint minden zöld, miközben a megrendelő elégedetlen.

Célszerű felderíteni, hogyan biztosítja a minőséget partnerünk, milyen report-okat gyártanak, és elérni, hogy ezeket hangolják össze a megrendelővel.

Megesik, hogy a partnerünk fogja a legjobb fejlesztőket és elveszi, hogy cserébe kezdőket adjon – természetesen ugyanolyan áron. Ezért célszerű kikötni, a megrendelőnek is legyen beleszólása a HR döntésekbe. Például a leendő fejlesztővel legyen egy formális interjú (önéletrajz megosztással), ahol az ügyfélnek legyen joga a nem megfelelő fejlesztőt visszautasítani. Ekkor a partnernek is érdeke lesz, hogy tapasztalt fejlesztőket adjon.

A korábban írt cikkben szó volt a bizalomról. Kiszervezés esetén mindig felmerül a kérdés, mekkora szabadságot adjunk a külső csapatnak. A tény az, hogy mindegy milyen szerződést írunk és milyen módon ellenőrizzük a teljesítést, a kiszervezett erőforrások fölött csak korlátozott hatalmunk lesz.

A kiszervezés körül a kulcskérdés mindig az, hogy kinek a kezében lesz tudás. Nos, ha a tudást teljes egészében kiadjuk a kezünkből – azaz nem ismerjük saját rendszereinket és nem értünk a technológiákhoz – akkor az sosem lesz jó. Függetlenül attól, hogy a beszállítónk mennyire jó. A helyes felállás az, amikor a fejlesztőcsapat vegyes: külsősökből és belsősökből áll. A tudás legyen közös, mint ahogy a munka és az eredmény is közös.

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 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 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 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.