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

Avagy miért nem jó az, ha valaki ért a szakmájához és jól teljesít.

Van egy fejlesztőm (nevezzük Angel-nek), akit azért fizetek, hogy ne csináljon semmit. Egészen pontosan dolgozik, mert odaadtam egy másik menedzsernek egy másik projektre, hogy ne unatkozzon. De a lényeg az, hogy havonta kifizetem az árát, és nekem nem csinál semmit.

Ez azért van, mert az alkalmazás, amit írt, nagyon stabil. Időnként kell rajta valamit állítani, kb havonta 1-szer hozzá kell nyúlni, de egyébként nincs munka vele. Nekem nagyon megéri, hogy ennek a programnak a karbantartása nem igényel egy hadseregnyi fejlesztőt, és ezért a minőségért hajlandó is vagyok fizetni.

Bizonyára a fejlesztő nagyon ott van a szeren, ért a technológiához, rendesen kódol, és tudja hogyan írjon jó minőségű stabil alkalmazást. Ilyen embert vétek lenne elengedni. Inkább fizetek neki hogy maradjon, szerzek neki munkát hogy ne unatkozzon. Ezért cserébe nyugodt vagyok, mert az a havi 1 munka rendben lesz, és ha majd amikor beesik egy nagyobb fejlesztés, akkor az is kész lesz gyorsan, jó minőségben. A felhasználók elégedettek, az IT támogatja az üzleti folyamatokat, mindenki boldog.

Rajtam kívül feltehetőleg minden más menedzser elzavarná ezt a fejlesztőt a francba, hiszen gyakorlatilag az ablakon dobjuk ki a fizetését.

Tegyük fel, hogy Angel-nek létezik egy gonosz ikertestvére: Devil. Devil pont az ellenkezője Angel-nek – minden programja hibás, minden kódja bug-ot tartalmaz, lassan dolgozik, nehézségei vannak a technológiával. Ha Devil írta volna azt a programot, akkor nem havi 1 ticket lenne, hanem nagyon sok. Feltehetőleg több, mint amennyit Devil kezelni tudna, azért fel kellene venni még 1-2 fejlesztőt. Vagyis lenne egy kisebb csapat, amit Devil vezethetne. Ő lenne a vezető fejlesztő vagy a team leader.

Ez a kis csapat feltehetőleg sok ticket-en dolgozni, hiszen sok lenne a probléma, és sok ticket-et is lezárna. Egész nap csak oltanák a tüzet.

Azonban Devil kódja mindig hibás, minden bugfix egy újabb bug-ot adna a rendszerhez, tehát a munka önmagát generálja és a ticket-ek száma sosem csökkenne le.

A fejlesztőknek folyamatosan lenne munkájuk, őket nem zavarná.

Feltehetőleg a menedzserüket sem zavarná, hiszen lenne mérhető progress: a ticket-ek egy része mindig lezárul, a fontosabb bug-okat mindig valaki kijavítja, megy a munka. A menedzsernek is jó, hogy van 3 fejlesztője és menedzselheti őket.

A felhasználók megtanulnának együttélni azzal, hogy bug-os a program, hogy nem lehet új feature-ákat a rendszerbe rakni mert a fejlesztők leterheltek és más dolguk van. Többé-kevésbé menjen a szoftver, a többit majd megoldják kézzel, Excelben.

Ez egy kiváló ökoszisztéma.

És most jön a trükk: hasonlítsuk össze Devil és Angel hatékonyságát. Bármilyen objektív mutatót tekintünk, Devil fényévekkel veri Angelt!!! (Az ügyfél elégedettség nem objektív mutató)

Mert hogyan mérhetjük Devil és Angel teljesítményét? A lezárt ticket-ek számával. Angel megcsinál havi 1-et, Devil havi 10-et. Angel sokkal kevesebb programsort ír, mint Devil. Angel sokkal több időt tölt egy-egy változtatáson, mint Devil, hiszen jól ágondolja azokat és megkeresi a helyes megoldást, miközben Devil gyorsan javít (aztán majd következő hónapban újra javít, a fellépő regression bug miatt). Tehát Devil alsó hangon is 10-szer hatékonyabb - elő kell léptetni és fizetésemelést adni neki, Angel-t pedig ki kell rúgni, a cég szégyene!

A minőség, a hosszútávon stabil rendszer, az ügyfél-elégedettség nehezen mérhető. Devil is meg tudja ideologizálni, hogy miért stabil az általa fejlesztett rendszer, hogy miért választotta a legjobb minőséget.

Mivel nagyvállalatnál divatos a helpdesk adatok és szoftver metrikák alapján megítélni a fejlesztőket, Devil lesz a sztár. Az se baj, ha a program rossz, hiszen akkor majd indítunk egy projektet a stabilizálásra, természetesen extra erőforrások bevonásával. Az Excel táblából biztosan az jön ki, hogy ez így a legjobb. Az Excel táblában ugyanis nincs olyan oszlop, hogy minőség. Nincs olyan oszlop, hogy hatékonyság. És olyan oszlop sincs, hogy mi lesz az ára, ha a tervet rosszul, rossz minőségben valósítjuk meg.

A vízzel együtt kiöntjük a gyereket is, ami nem mérhető (pl. software craftmanship) azt nem vesszük figyelembe.

Az Angel-féle fejlesztők dilemmája az, hogy ha jól dolgozik, akkor előbb-utóbb kirúgják a cégtől. Rosszabb esetben csak a HR beutalja őket egy tanfolyamra a minőségről és termelékenységről. De utóbb megunják, hogy Devil a sztár, és otthagyják a céget. Ezzel helyreáll a rend, hiszen Devil a norma, és mindenki más, aki nem követi a normát, az ellenség.

De ha Angel szeretné megtartaná a munkahelyét, akkor le kell rontania saját teljesítményét. Előbb-utóbb Devil lesz a főnöke (hiszen Devil sikeres) és rákényszeríti saját módszereit. Ha az angyalnak lenyesik a szárnyait, pont úgy fog kinézni, mint akárki más. Ez viszont ellenmond Angel elveivel, hiszen neki a minőség és a stabilitás fontos.

Vagyis a dilemma arról szól, két rossz közül melyik válassza a fejlesztő:
- Adja fel elveit és fejlesszen rosszul
- Vagy hagyja ott a céget és menjen el máshová – ahol feltehetőleg ugyanez várja

Talán nem véletlen, hogy a nagyon tapasztalt fejlesztők egy része inkább vállalkozóként vagy freelance-ként bukkan fel.

Avagy miért nem jó az, ha valaki ért a szakmájához és jól teljesít.

Van egy fejlesztőm (nevezzük Angel-nek), akit azért fizetek, hogy ne csináljon semmit. Egészen pontosan dolgozik, mert odaadtam egy másik menedzsernek egy másik projektre, hogy ne unatkozzon. De a lényeg az, hogy havonta kifizetem az árát, és nekem nem csinál semmit.

Ez azért van, mert az alkalmazás, amit írt, nagyon stabil. Időnként kell rajta valamit állítani, kb havonta 1-szer hozzá kell nyúlni, de egyébként nincs munka vele. Nekem nagyon megéri, hogy ennek a programnak a karbantartása nem igényel egy hadseregnyi fejlesztőt, és ezért a minőségért hajlandó is vagyok fizetni.

Bizonyára a fejlesztő nagyon ott van a szeren, ért a technológiához, rendesen kódol, és tudja hogyan írjon jó minőségű stabil alkalmazást. Ilyen embert vétek lenne elengedni. Inkább fizetek neki hogy maradjon, szerzek neki munkát hogy ne unatkozzon. Ezért cserébe nyugodt vagyok, mert az a havi 1 munka rendben lesz, és ha majd amikor beesik egy nagyobb fejlesztés, akkor az is kész lesz gyorsan, jó minőségben. A felhasználók elégedettek, az IT támogatja az üzleti folyamatokat, mindenki boldog.

Rajtam kívül feltehetőleg minden más menedzser elzavarná ezt a fejlesztőt a francba, hiszen gyakorlatilag az ablakon dobjuk ki a fizetését.

Tegyük fel, hogy Angel-nek létezik egy gonosz ikertestvére: Devil. Devil pont az ellenkezője Angel-nek – minden programja hibás, minden kódja bug-ot tartalmaz, lassan dolgozik, nehézségei vannak a technológiával. Ha Devil írta volna azt a programot, akkor nem havi 1 ticket lenne, hanem nagyon sok. Feltehetőleg több, mint amennyit Devil kezelni tudna, azért fel kellene venni még 1-2 fejlesztőt. Vagyis lenne egy kisebb csapat, amit Devil vezethetne. Ő lenne a vezető fejlesztő vagy a team leader.

Ez a kis csapat feltehetőleg sok ticket-en dolgozni, hiszen sok lenne a probléma, és sok ticket-et is lezárna. Egész nap csak oltanák a tüzet.

Azonban Devil kódja mindig hibás, minden bugfix egy újabb bug-ot adna a rendszerhez, tehát a munka önmagát generálja és a ticket-ek száma sosem csökkenne le.

A fejlesztőknek folyamatosan lenne munkájuk, őket nem zavarná.

Feltehetőleg a menedzserüket sem zavarná, hiszen lenne mérhető progress: a ticket-ek egy része mindig lezárul, a fontosabb bug-okat mindig valaki kijavítja, megy a munka. A menedzsernek is jó, hogy van 3 fejlesztője és menedzselheti őket.

A felhasználók megtanulnának együttélni azzal, hogy bug-os a program, hogy nem lehet új feature-ákat a rendszerbe rakni mert a fejlesztők leterheltek és más dolguk van. Többé-kevésbé menjen a szoftver, a többit majd megoldják kézzel, Excelben.

Ez egy kiváló ökoszisztéma.

És most jön a trükk: hasonlítsuk össze Devil és Angel hatékonyságát. Bármilyen objektív mutatót tekintünk, Devil fényévekkel veri Angelt!!! (Az ügyfél elégedettség nem objektív mutató)

Mert hogyan mérhetjük Devil és Angel teljesítményét? A lezárt ticket-ek számával. Angel megcsinál havi 1-et, Devil havi 10-et. Angel sokkal kevesebb programsort ír, mint Devil. Angel sokkal több időt tölt egy-egy változtatáson, mint Devil, hiszen jól ágondolja azokat és megkeresi a helyes megoldást, miközben Devil gyorsan javít (aztán majd következő hónapban újra javít, a fellépő regression bug miatt). Tehát Devil alsó hangon is 10-szer hatékonyabb - elő kell léptetni és fizetésemelést adni neki, Angel-t pedig ki kell rúgni, a cég szégyene!

A minőség, a hosszútávon stabil rendszer, az ügyfél-elégedettség nehezen mérhető. Devil is meg tudja ideologizálni, hogy miért stabil az általa fejlesztett rendszer, hogy miért választotta a legjobb minőséget.

Mivel nagyvállalatnál divatos a helpdesk adatok és szoftver metrikák alapján megítélni a fejlesztőket, Devil lesz a sztár. Az se baj, ha a program rossz, hiszen akkor majd indítunk egy projektet a stabilizálásra, természetesen extra erőforrások bevonásával. Az Excel táblából biztosan az jön ki, hogy ez így a legjobb. Az Excel táblában ugyanis nincs olyan oszlop, hogy minőség. Nincs olyan oszlop, hogy hatékonyság. És olyan oszlop sincs, hogy mi lesz az ára, ha a tervet rosszul, rossz minőségben valósítjuk meg.

A vízzel együtt kiöntjük a gyereket is, ami nem mérhető (pl. software craftmanship) azt nem vesszük figyelembe.

Az Angel-féle fejlesztők dilemmája az, hogy ha jól dolgozik, akkor előbb-utóbb kirúgják a cégtől. Rosszabb esetben csak a HR beutalja őket egy tanfolyamra a minőségről és termelékenységről. De utóbb megunják, hogy Devil a sztár, és otthagyják a céget. Ezzel helyreáll a rend, hiszen Devil a norma, és mindenki más, aki nem követi a normát, az ellenség.

De ha Angel szeretné megtartaná a munkahelyét, akkor le kell rontania saját teljesítményét. Előbb-utóbb Devil lesz a főnöke (hiszen Devil sikeres) és rákényszeríti saját módszereit. Ha az angyalnak lenyesik a szárnyait, pont úgy fog kinézni, mint akárki más. Ez viszont ellenmond Angel elveivel, hiszen neki a minőség és a stabilitás fontos.

Vagyis a dilemma arról szól, két rossz közül melyik válassza a fejlesztő:
- Adja fel elveit és fejlesszen rosszul
- Vagy hagyja ott a céget és menjen el máshová – ahol feltehetőleg ugyanez várja

Talán nem véletlen, hogy a nagyon tapasztalt fejlesztők egy része inkább vállalkozóként vagy freelance-ként bukkan fel.

Avagy miért nem jó az, ha valaki ért a szakmájához és jól teljesít.

Van egy fejlesztőm (nevezzük Angel-nek), akit azért fizetek, hogy ne csináljon semmit. Egészen pontosan dolgozik, mert odaadtam egy másik menedzsernek egy másik projektre, hogy ne unatkozzon. De a lényeg az, hogy havonta kifizetem az árát, és nekem nem csinál semmit.

Ez azért van, mert az alkalmazás, amit írt, nagyon stabil. Időnként kell rajta valamit állítani, kb havonta 1-szer hozzá kell nyúlni, de egyébként nincs munka vele. Nekem nagyon megéri, hogy ennek a programnak a karbantartása nem igényel egy hadseregnyi fejlesztőt, és ezért a minőségért hajlandó is vagyok fizetni.

Bizonyára a fejlesztő nagyon ott van a szeren, ért a technológiához, rendesen kódol, és tudja hogyan írjon jó minőségű stabil alkalmazást. Ilyen embert vétek lenne elengedni. Inkább fizetek neki hogy maradjon, szerzek neki munkát hogy ne unatkozzon. Ezért cserébe nyugodt vagyok, mert az a havi 1 munka rendben lesz, és ha majd amikor beesik egy nagyobb fejlesztés, akkor az is kész lesz gyorsan, jó minőségben. A felhasználók elégedettek, az IT támogatja az üzleti folyamatokat, mindenki boldog.

Rajtam kívül feltehetőleg minden más menedzser elzavarná ezt a fejlesztőt a francba, hiszen gyakorlatilag az ablakon dobjuk ki a fizetését.

Tegyük fel, hogy Angel-nek létezik egy gonosz ikertestvére: Devil. Devil pont az ellenkezője Angel-nek – minden programja hibás, minden kódja bug-ot tartalmaz, lassan dolgozik, nehézségei vannak a technológiával. Ha Devil írta volna azt a programot, akkor nem havi 1 ticket lenne, hanem nagyon sok. Feltehetőleg több, mint amennyit Devil kezelni tudna, azért fel kellene venni még 1-2 fejlesztőt. Vagyis lenne egy kisebb csapat, amit Devil vezethetne. Ő lenne a vezető fejlesztő vagy a team leader.

Ez a kis csapat feltehetőleg sok ticket-en dolgozni, hiszen sok lenne a probléma, és sok ticket-et is lezárna. Egész nap csak oltanák a tüzet.

Azonban Devil kódja mindig hibás, minden bugfix egy újabb bug-ot adna a rendszerhez, tehát a munka önmagát generálja és a ticket-ek száma sosem csökkenne le.

A fejlesztőknek folyamatosan lenne munkájuk, őket nem zavarná.

Feltehetőleg a menedzserüket sem zavarná, hiszen lenne mérhető progress: a ticket-ek egy része mindig lezárul, a fontosabb bug-okat mindig valaki kijavítja, megy a munka. A menedzsernek is jó, hogy van 3 fejlesztője és menedzselheti őket.

A felhasználók megtanulnának együttélni azzal, hogy bug-os a program, hogy nem lehet új feature-ákat a rendszerbe rakni mert a fejlesztők leterheltek és más dolguk van. Többé-kevésbé menjen a szoftver, a többit majd megoldják kézzel, Excelben.

Ez egy kiváló ökoszisztéma.

És most jön a trükk: hasonlítsuk össze Devil és Angel hatékonyságát. Bármilyen objektív mutatót tekintünk, Devil fényévekkel veri Angelt!!! (Az ügyfél elégedettség nem objektív mutató)

Mert hogyan mérhetjük Devil és Angel teljesítményét? A lezárt ticket-ek számával. Angel megcsinál havi 1-et, Devil havi 10-et. Angel sokkal kevesebb programsort ír, mint Devil. Angel sokkal több időt tölt egy-egy változtatáson, mint Devil, hiszen jól ágondolja azokat és megkeresi a helyes megoldást, miközben Devil gyorsan javít (aztán majd következő hónapban újra javít, a fellépő regression bug miatt). Tehát Devil alsó hangon is 10-szer hatékonyabb - elő kell léptetni és fizetésemelést adni neki, Angel-t pedig ki kell rúgni, a cég szégyene!

A minőség, a hosszútávon stabil rendszer, az ügyfél-elégedettség nehezen mérhető. Devil is meg tudja ideologizálni, hogy miért stabil az általa fejlesztett rendszer, hogy miért választotta a legjobb minőséget.

Mivel nagyvállalatnál divatos a helpdesk adatok és szoftver metrikák alapján megítélni a fejlesztőket, Devil lesz a sztár. Az se baj, ha a program rossz, hiszen akkor majd indítunk egy projektet a stabilizálásra, természetesen extra erőforrások bevonásával. Az Excel táblából biztosan az jön ki, hogy ez így a legjobb. Az Excel táblában ugyanis nincs olyan oszlop, hogy minőség. Nincs olyan oszlop, hogy hatékonyság. És olyan oszlop sincs, hogy mi lesz az ára, ha a tervet rosszul, rossz minőségben valósítjuk meg.

A vízzel együtt kiöntjük a gyereket is, ami nem mérhető (pl. software craftmanship) azt nem vesszük figyelembe.

Az Angel-féle fejlesztők dilemmája az, hogy ha jól dolgozik, akkor előbb-utóbb kirúgják a cégtől. Rosszabb esetben csak a HR beutalja őket egy tanfolyamra a minőségről és termelékenységről. De utóbb megunják, hogy Devil a sztár, és otthagyják a céget. Ezzel helyreáll a rend, hiszen Devil a norma, és mindenki más, aki nem követi a normát, az ellenség.

De ha Angel szeretné megtartaná a munkahelyét, akkor le kell rontania saját teljesítményét. Előbb-utóbb Devil lesz a főnöke (hiszen Devil sikeres) és rákényszeríti saját módszereit. Ha az angyalnak lenyesik a szárnyait, pont úgy fog kinézni, mint akárki más. Ez viszont ellenmond Angel elveivel, hiszen neki a minőség és a stabilitás fontos.

Vagyis a dilemma arról szól, két rossz közül melyik válassza a fejlesztő:
- Adja fel elveit és fejlesszen rosszul
- Vagy hagyja ott a céget és menjen el máshová – ahol feltehetőleg ugyanez várja

Talán nem véletlen, hogy a nagyon tapasztalt fejlesztők egy része inkább vállalkozóként vagy freelance-ként bukkan fel.

Avagy miért nem jó az, ha valaki ért a szakmájához és jól teljesít.

Van egy fejlesztőm (nevezzük Angel-nek), akit azért fizetek, hogy ne csináljon semmit. Egészen pontosan dolgozik, mert odaadtam egy másik menedzsernek egy másik projektre, hogy ne unatkozzon. De a lényeg az, hogy havonta kifizetem az árát, és nekem nem csinál semmit.

Ez azért van, mert az alkalmazás, amit írt, nagyon stabil. Időnként kell rajta valamit állítani, kb havonta 1-szer hozzá kell nyúlni, de egyébként nincs munka vele. Nekem nagyon megéri, hogy ennek a programnak a karbantartása nem igényel egy hadseregnyi fejlesztőt, és ezért a minőségért hajlandó is vagyok fizetni.

Bizonyára a fejlesztő nagyon ott van a szeren, ért a technológiához, rendesen kódol, és tudja hogyan írjon jó minőségű stabil alkalmazást. Ilyen embert vétek lenne elengedni. Inkább fizetek neki hogy maradjon, szerzek neki munkát hogy ne unatkozzon. Ezért cserébe nyugodt vagyok, mert az a havi 1 munka rendben lesz, és ha majd amikor beesik egy nagyobb fejlesztés, akkor az is kész lesz gyorsan, jó minőségben. A felhasználók elégedettek, az IT támogatja az üzleti folyamatokat, mindenki boldog.

Rajtam kívül feltehetőleg minden más menedzser elzavarná ezt a fejlesztőt a francba, hiszen gyakorlatilag az ablakon dobjuk ki a fizetését.

Tegyük fel, hogy Angel-nek létezik egy gonosz ikertestvére: Devil. Devil pont az ellenkezője Angel-nek – minden programja hibás, minden kódja bug-ot tartalmaz, lassan dolgozik, nehézségei vannak a technológiával. Ha Devil írta volna azt a programot, akkor nem havi 1 ticket lenne, hanem nagyon sok. Feltehetőleg több, mint amennyit Devil kezelni tudna, azért fel kellene venni még 1-2 fejlesztőt. Vagyis lenne egy kisebb csapat, amit Devil vezethetne. Ő lenne a vezető fejlesztő vagy a team leader.

Ez a kis csapat feltehetőleg sok ticket-en dolgozni, hiszen sok lenne a probléma, és sok ticket-et is lezárna. Egész nap csak oltanák a tüzet.

Azonban Devil kódja mindig hibás, minden bugfix egy újabb bug-ot adna a rendszerhez, tehát a munka önmagát generálja és a ticket-ek száma sosem csökkenne le.

A fejlesztőknek folyamatosan lenne munkájuk, őket nem zavarná.

Feltehetőleg a menedzserüket sem zavarná, hiszen lenne mérhető progress: a ticket-ek egy része mindig lezárul, a fontosabb bug-okat mindig valaki kijavítja, megy a munka. A menedzsernek is jó, hogy van 3 fejlesztője és menedzselheti őket.

A felhasználók megtanulnának együttélni azzal, hogy bug-os a program, hogy nem lehet új feature-ákat a rendszerbe rakni mert a fejlesztők leterheltek és más dolguk van. Többé-kevésbé menjen a szoftver, a többit majd megoldják kézzel, Excelben.

Ez egy kiváló ökoszisztéma.

És most jön a trükk: hasonlítsuk össze Devil és Angel hatékonyságát. Bármilyen objektív mutatót tekintünk, Devil fényévekkel veri Angelt!!! (Az ügyfél elégedettség nem objektív mutató)

Mert hogyan mérhetjük Devil és Angel teljesítményét? A lezárt ticket-ek számával. Angel megcsinál havi 1-et, Devil havi 10-et. Angel sokkal kevesebb programsort ír, mint Devil. Angel sokkal több időt tölt egy-egy változtatáson, mint Devil, hiszen jól ágondolja azokat és megkeresi a helyes megoldást, miközben Devil gyorsan javít (aztán majd következő hónapban újra javít, a fellépő regression bug miatt). Tehát Devil alsó hangon is 10-szer hatékonyabb - elő kell léptetni és fizetésemelést adni neki, Angel-t pedig ki kell rúgni, a cég szégyene!

A minőség, a hosszútávon stabil rendszer, az ügyfél-elégedettség nehezen mérhető. Devil is meg tudja ideologizálni, hogy miért stabil az általa fejlesztett rendszer, hogy miért választotta a legjobb minőséget.

Mivel nagyvállalatnál divatos a helpdesk adatok és szoftver metrikák alapján megítélni a fejlesztőket, Devil lesz a sztár. Az se baj, ha a program rossz, hiszen akkor majd indítunk egy projektet a stabilizálásra, természetesen extra erőforrások bevonásával. Az Excel táblából biztosan az jön ki, hogy ez így a legjobb. Az Excel táblában ugyanis nincs olyan oszlop, hogy minőség. Nincs olyan oszlop, hogy hatékonyság. És olyan oszlop sincs, hogy mi lesz az ára, ha a tervet rosszul, rossz minőségben valósítjuk meg.

A vízzel együtt kiöntjük a gyereket is, ami nem mérhető (pl. software craftmanship) azt nem vesszük figyelembe.

Az Angel-féle fejlesztők dilemmája az, hogy ha jól dolgozik, akkor előbb-utóbb kirúgják a cégtől. Rosszabb esetben csak a HR beutalja őket egy tanfolyamra a minőségről és termelékenységről. De utóbb megunják, hogy Devil a sztár, és otthagyják a céget. Ezzel helyreáll a rend, hiszen Devil a norma, és mindenki más, aki nem követi a normát, az ellenség.

De ha Angel szeretné megtartaná a munkahelyét, akkor le kell rontania saját teljesítményét. Előbb-utóbb Devil lesz a főnöke (hiszen Devil sikeres) és rákényszeríti saját módszereit. Ha az angyalnak lenyesik a szárnyait, pont úgy fog kinézni, mint akárki más. Ez viszont ellenmond Angel elveivel, hiszen neki a minőség és a stabilitás fontos.

Vagyis a dilemma arról szól, két rossz közül melyik válassza a fejlesztő:
- Adja fel elveit és fejlesszen rosszul
- Vagy hagyja ott a céget és menjen el máshová – ahol feltehetőleg ugyanez várja

Talán nem véletlen, hogy a nagyon tapasztalt fejlesztők egy része inkább vállalkozóként vagy freelance-ként bukkan fel.

Csak informatikus lehet az, aki szerint egy 90%-os megoldás megfelelő J

Holden blogján olvastam Határ és határidő cikket. Az egyik megjegyzés különösen érdekes volt:

Matyi Tamás, 2011. 09. 02. 22:30

"...hiába van meg a 95%-a."

Kicsit kötekszem:
Minek a 95%-a? A részletes projektspecifikációnak, ami a szerződés előtt lett hosszasan kőbe (szerződésbe) vésve?

És ha időközben - az elkészült részteljesítések tapasztatai alapján - kiderül, hogy nem is pont arra/úgy van szükség?
Mi a jobb? Egy 100%-os teljesítés, de nem túl jól használható eredmény, vagy egy 90%-os teljesítésű, de az igényeknek leginkább megfelelő megoldás?

Természetesen sokszor igaz, hogy egzakt módon lehet és kell mérni, hogy valami kész van-e, vagy nem.
Azonban - pl. fejlesztési projektek kapcsán - érdemes meggondolni, mit is akarunk a végére elérni ill. mit és hogyan definiálunk, mérünk, követelünk meg hozzá... (lásd pl. iteratív szoftverfejlesztés)

A megjegyzés klasszikus IT szemléletet tükröz, akárki írhatta volna. Az kétségkívül igaz, hogy egy 90%-os, de az igényeknek megfelelő megoldás jobb, mint egy 100%-os de nem használható. Ez olyannyira igaz, hogy még fejlesztési módszertant is építettek rá: Rapid Application Development (RAD).

A RAD előnye a gyorsaság. Minél hamarabb van valami (prototípus, működő szoftver), annál hamarabb tudnak a felhasználók visszajelzést adni. A visszajelzés alapján pedig jobb szoftvert lehet késziteni.

A RAD fontos kiindulási pontja, hogy egy fejlesztési projektben a funkciók nagy részét gyorsan el lehet készteni. Viszonylag hamar lesz működő szoftverünk, viszonylag hamar elérjük az 50%-os teljesítési szintet, illetve innen gyorsan eljutunk a 70% és 90%-ig. A sok munka és idő az utolsó 10%-zal szokott lenni, ez az a rész, amikor a fejlesztők vért izzadnak és hétvégéznek (lásd 90-90 rule). A RAD-ban az az okosság, hogy felgyorsítjuk a 90% elérését, azaz minimálisra csökkentjük az előzetes tervezést és kihagyjuk az utolsó 10%-ot. Elvégre ez egy iteratív folyamat, megcsináljuk a 90%-ot, és a maradék 10%-et majd a következő iterációra hagyjuk. A felhasználók addig úgyis meggondolják magukat, új igények merülnek fel, szóval ne is törjük magunkat – feleslegesen – a 100% megvalósításával.

Jól hangzik, de akkor miért nem mindenki így fejleszt?

Mert két komoly baj is van:

1) A szoftver valójában sosem lesz kész – mindig csak 90%-ot érünk el, hogy utána a következő iterációban szintén csak 90% legyen a cél

2) A gyenge tervezés miatt egyre több architektúrális és minőségi problémánk lesz

Az 1. ponttal szeretnék foglalkozni bővebben.

A mondás úgy tartja, hogy jobb ma egy veréb, mint holnap egy túzok. Azaz jobb ma egy 90%-osan kész, működő szoftver, mint holnap egy 100%-os. A felhasználók örülnek, mindenki boldog… aztán a felhasználók megkérdezik, hogy a maradék funkció mikor lesz kész.

Ugyanis nekik minden funkció kell. Ahogyan Holden írta, a teljesítésnek csak két állapota van: készen van, vagy nincs. Ha 10% hiányzik, az nincs kész.

A valóság az, hogy egy 90%-osan kész szoftverrel a felhasználók nem tudnak sokat kezdeni. Az üzleti célok adottak, és azokat egyszer valamikor 100%-ban el kell érni. Például tegyük fel, hogy a projekt célja egy új autó modell bevezetése, illetve az ehhez szükség változtatások végrehajtása az informatikai rendszereken. Amíg ezek nincsenek készen, addig az új modellt nem tudjuk értékesíteni. Ha a változtatások 90%-ban készen vannak, az azt jelenti, hogy 10% még hiányzik, vagyis az új modell még mindig nem értékesíthető. Ilyen értelemben mindegy, hogy a készültség mértéke 50%, 70% vagy 90%.

Még rosszabb a helyzet olyan fejlesztési projekteknél, ahol a fejlesztésen kívül egyéb üzleti feladatok is vannak, például oktatás vagy üzleti folyamat változás. Egy 90%-ban kész szoftvert nem lehet leoktatni, vagy le lehet, de utána az oktatást meg kell ismételni a 100%-osan kész szoftveren. Az üzleti folyamatok változtatása is kétállapotú: vagy a régit követjük, vagy az újat. Olyan nincs, hogy 90%-ban az újat követjük, de 10%-ban a régit.

(Arról nem is beszélve, hogy a 10%-ot az informatikusok választanák ki, nem az üzleti döntéshozók.)

Mondok egy analógiát: tegyük fel, hogy a közlekedésünket átállítanánk jobboldali közlekedésről baloldalira. Csak 100%-os átállás lehetséges, részleges átállás (90%-os) nem lehetséges. Nem mondhatjuk azt, hogy a személyautók és buszok átállnak és a bal oldalon haladnak, de a teherautókra még nem dolgoztuk ki a szabályokat ezért azok továbbra is a jobb oldalon közlekednek.

Mondok egy analógiát: tegyük fel, hogy álmaink házát építtetjük egy építésszel. Nagyon meglepő lenne, ha a ház 90%-ban elkészül, és az építész késznek minősíti a munkát. Bizonyára nem fogadnánk el késznek és nem költöznénk be. Bizonyára megoldható lenne, hogy a ház 90%-ban kész és beköltözhető – feltételezve, hogy mi választjuk ki a 90%-ot, és nem az építész. De ha be is költöznénk, a maradék 10%-ra is igényt tartanánk, mert hiszen egy teljesen kész házat szeretnénk a birtokunkban tudni.

 

A tévedés oka abban keresendő, hogy a programozók a készenlétet a specifikációhoz képest mérik, a felhasználók pedig az igényeikhez képest. A kettő nem ugyanaz, és ez jelenti a szoftverfejlesztés egyik, ha nem a legnagyobb kihívását. A felhasználó, a megrendelő fejében pontosan létezik egy kép az elvégzendő munkáról. Számára a munka akkor van kész, amikor a szoftver ennek a képnek 100%-ban megfelel. Nem hamarabb, és nem 90%-ban.

Azonban a kép a felhasználó fejében van, a programozók pedig nem tudnak gondolatot olvasni. Kell egy közbenső kommunikációs eszköz – a specifikáció (vagy nevezhetjük backlog-nak is, mindegy) – ami leírja ezt a képet, és a fejlesztők el tudják olvasni. Különben nem tudnának fejleszteni. A kommunikáció szükségszerűen veszteséggel jár, tehát a specifikáció nem lesz 100%-ban ugyanaz, mint ami a felhasználó fejében van. Arról nem is beszélve, hogy bizonyos részletek lehetnek homályosak, illetve az igények idővel megváltozhatnak.

Mindez úgy csapódhat le a programozóknál, hogy nem érdemes 100%-os készenlétre hajtani, hiszen a végén úgyse az eredeti specifikáció 100%-át kell megvalósítani. Egy igen jó közelítés az, ha megvalósítjuk a nagyját, aztán majd kezeljük a felmerülő igényeket és a különbségeket. Szóval lehet, hogy a végén csak a specifikáció 90%-át valósítjuk meg, de ettől még az üzleti igények 100%-a a cél.

A dolog azért fontos, mert egy adott ponton a programozók pénzt szeretnének látni a munkájukért. A megrendelő pedig általában olyan, hogy a beígért pénz 100%-át csak akkor szeretné kifizetni, ha az igényei 100%-át sikerült kielégíteni. Nem fog akarni fizetni egy 90%-os a teljesítésre.

Éppen ezért bármilyen fejlesztési módszertan, ami a 90%-os teljesítést célozza meg, nem az ügyfél érdekeinek és szándékának megfelelő. Hiába érzi azt az ügyfél a fejlesztés alatt, hogy jobban ki van szolgálva (hamarabb kap működő szoftvert), ha a végén nem készül el a teljes körű megoldás.

Természetesen kivételek vannak, és ezért az ilyen fejlesztéseknek is megvan a helyük.

Egy marketing célú céges web oldal esetén például fontosabb lehet a gyors megjelenés, mint a teljes funkcionalitás. Ha a design megvan és lehet a web oldalon keresztül rendelni, akkor nem baj, ha pár funkció még hiányzik (mondjuk a fórum még nem elérhető). Az ilyen projektekben kimondottan előny, pénzben mérhető üzleti előny, ha minél hamarabb elkészül egy részleges, de már működő megoldás.

Az informatikai projektek túlnyomó része nem ilyen.

Csak informatikus lehet az, aki szerint egy 90%-os megoldás megfelelő J

Holden blogján olvastam Határ és határidő cikket. Az egyik megjegyzés különösen érdekes volt:

Matyi Tamás, 2011. 09. 02. 22:30

"...hiába van meg a 95%-a."

Kicsit kötekszem:
Minek a 95%-a? A részletes projektspecifikációnak, ami a szerződés előtt lett hosszasan kőbe (szerződésbe) vésve?

És ha időközben - az elkészült részteljesítések tapasztatai alapján - kiderül, hogy nem is pont arra/úgy van szükség?
Mi a jobb? Egy 100%-os teljesítés, de nem túl jól használható eredmény, vagy egy 90%-os teljesítésű, de az igényeknek leginkább megfelelő megoldás?

Természetesen sokszor igaz, hogy egzakt módon lehet és kell mérni, hogy valami kész van-e, vagy nem.
Azonban - pl. fejlesztési projektek kapcsán - érdemes meggondolni, mit is akarunk a végére elérni ill. mit és hogyan definiálunk, mérünk, követelünk meg hozzá... (lásd pl. iteratív szoftverfejlesztés)

A megjegyzés klasszikus IT szemléletet tükröz, akárki írhatta volna. Az kétségkívül igaz, hogy egy 90%-os, de az igényeknek megfelelő megoldás jobb, mint egy 100%-os de nem használható. Ez olyannyira igaz, hogy még fejlesztési módszertant is építettek rá: Rapid Application Development (RAD).

A RAD előnye a gyorsaság. Minél hamarabb van valami (prototípus, működő szoftver), annál hamarabb tudnak a felhasználók visszajelzést adni. A visszajelzés alapján pedig jobb szoftvert lehet késziteni.

A RAD fontos kiindulási pontja, hogy egy fejlesztési projektben a funkciók nagy részét gyorsan el lehet készteni. Viszonylag hamar lesz működő szoftverünk, viszonylag hamar elérjük az 50%-os teljesítési szintet, illetve innen gyorsan eljutunk a 70% és 90%-ig. A sok munka és idő az utolsó 10%-zal szokott lenni, ez az a rész, amikor a fejlesztők vért izzadnak és hétvégéznek (lásd 90-90 rule). A RAD-ban az az okosság, hogy felgyorsítjuk a 90% elérését, azaz minimálisra csökkentjük az előzetes tervezést és kihagyjuk az utolsó 10%-ot. Elvégre ez egy iteratív folyamat, megcsináljuk a 90%-ot, és a maradék 10%-et majd a következő iterációra hagyjuk. A felhasználók addig úgyis meggondolják magukat, új igények merülnek fel, szóval ne is törjük magunkat – feleslegesen – a 100% megvalósításával.

Jól hangzik, de akkor miért nem mindenki így fejleszt?

Mert két komoly baj is van:

1) A szoftver valójában sosem lesz kész – mindig csak 90%-ot érünk el, hogy utána a következő iterációban szintén csak 90% legyen a cél

2) A gyenge tervezés miatt egyre több architektúrális és minőségi problémánk lesz

Az 1. ponttal szeretnék foglalkozni bővebben.

A mondás úgy tartja, hogy jobb ma egy veréb, mint holnap egy túzok. Azaz jobb ma egy 90%-osan kész, működő szoftver, mint holnap egy 100%-os. A felhasználók örülnek, mindenki boldog… aztán a felhasználók megkérdezik, hogy a maradék funkció mikor lesz kész.

Ugyanis nekik minden funkció kell. Ahogyan Holden írta, a teljesítésnek csak két állapota van: készen van, vagy nincs. Ha 10% hiányzik, az nincs kész.

A valóság az, hogy egy 90%-osan kész szoftverrel a felhasználók nem tudnak sokat kezdeni. Az üzleti célok adottak, és azokat egyszer valamikor 100%-ban el kell érni. Például tegyük fel, hogy a projekt célja egy új autó modell bevezetése, illetve az ehhez szükség változtatások végrehajtása az informatikai rendszereken. Amíg ezek nincsenek készen, addig az új modellt nem tudjuk értékesíteni. Ha a változtatások 90%-ban készen vannak, az azt jelenti, hogy 10% még hiányzik, vagyis az új modell még mindig nem értékesíthető. Ilyen értelemben mindegy, hogy a készültség mértéke 50%, 70% vagy 90%.

Még rosszabb a helyzet olyan fejlesztési projekteknél, ahol a fejlesztésen kívül egyéb üzleti feladatok is vannak, például oktatás vagy üzleti folyamat változás. Egy 90%-ban kész szoftvert nem lehet leoktatni, vagy le lehet, de utána az oktatást meg kell ismételni a 100%-osan kész szoftveren. Az üzleti folyamatok változtatása is kétállapotú: vagy a régit követjük, vagy az újat. Olyan nincs, hogy 90%-ban az újat követjük, de 10%-ban a régit.

(Arról nem is beszélve, hogy a 10%-ot az informatikusok választanák ki, nem az üzleti döntéshozók.)

Mondok egy analógiát: tegyük fel, hogy a közlekedésünket átállítanánk jobboldali közlekedésről baloldalira. Csak 100%-os átállás lehetséges, részleges átállás (90%-os) nem lehetséges. Nem mondhatjuk azt, hogy a személyautók és buszok átállnak és a bal oldalon haladnak, de a teherautókra még nem dolgoztuk ki a szabályokat ezért azok továbbra is a jobb oldalon közlekednek.

Mondok egy analógiát: tegyük fel, hogy álmaink házát építtetjük egy építésszel. Nagyon meglepő lenne, ha a ház 90%-ban elkészül, és az építész késznek minősíti a munkát. Bizonyára nem fogadnánk el késznek és nem költöznénk be. Bizonyára megoldható lenne, hogy a ház 90%-ban kész és beköltözhető – feltételezve, hogy mi választjuk ki a 90%-ot, és nem az építész. De ha be is költöznénk, a maradék 10%-ra is igényt tartanánk, mert hiszen egy teljesen kész házat szeretnénk a birtokunkban tudni.

 

A tévedés oka abban keresendő, hogy a programozók a készenlétet a specifikációhoz képest mérik, a felhasználók pedig az igényeikhez képest. A kettő nem ugyanaz, és ez jelenti a szoftverfejlesztés egyik, ha nem a legnagyobb kihívását. A felhasználó, a megrendelő fejében pontosan létezik egy kép az elvégzendő munkáról. Számára a munka akkor van kész, amikor a szoftver ennek a képnek 100%-ban megfelel. Nem hamarabb, és nem 90%-ban.

Azonban a kép a felhasználó fejében van, a programozók pedig nem tudnak gondolatot olvasni. Kell egy közbenső kommunikációs eszköz – a specifikáció (vagy nevezhetjük backlog-nak is, mindegy) – ami leírja ezt a képet, és a fejlesztők el tudják olvasni. Különben nem tudnának fejleszteni. A kommunikáció szükségszerűen veszteséggel jár, tehát a specifikáció nem lesz 100%-ban ugyanaz, mint ami a felhasználó fejében van. Arról nem is beszélve, hogy bizonyos részletek lehetnek homályosak, illetve az igények idővel megváltozhatnak.

Mindez úgy csapódhat le a programozóknál, hogy nem érdemes 100%-os készenlétre hajtani, hiszen a végén úgyse az eredeti specifikáció 100%-át kell megvalósítani. Egy igen jó közelítés az, ha megvalósítjuk a nagyját, aztán majd kezeljük a felmerülő igényeket és a különbségeket. Szóval lehet, hogy a végén csak a specifikáció 90%-át valósítjuk meg, de ettől még az üzleti igények 100%-a a cél.

A dolog azért fontos, mert egy adott ponton a programozók pénzt szeretnének látni a munkájukért. A megrendelő pedig általában olyan, hogy a beígért pénz 100%-át csak akkor szeretné kifizetni, ha az igényei 100%-át sikerült kielégíteni. Nem fog akarni fizetni egy 90%-os a teljesítésre.

Éppen ezért bármilyen fejlesztési módszertan, ami a 90%-os teljesítést célozza meg, nem az ügyfél érdekeinek és szándékának megfelelő. Hiába érzi azt az ügyfél a fejlesztés alatt, hogy jobban ki van szolgálva (hamarabb kap működő szoftvert), ha a végén nem készül el a teljes körű megoldás.

Természetesen kivételek vannak, és ezért az ilyen fejlesztéseknek is megvan a helyük.

Egy marketing célú céges web oldal esetén például fontosabb lehet a gyors megjelenés, mint a teljes funkcionalitás. Ha a design megvan és lehet a web oldalon keresztül rendelni, akkor nem baj, ha pár funkció még hiányzik (mondjuk a fórum még nem elérhető). Az ilyen projektekben kimondottan előny, pénzben mérhető üzleti előny, ha minél hamarabb elkészül egy részleges, de már működő megoldás.

Az informatikai projektek túlnyomó része nem ilyen.

Csak informatikus lehet az, aki szerint egy 90%-os megoldás megfelelő J

Holden blogján olvastam Határ és határidő cikket. Az egyik megjegyzés különösen érdekes volt:

Matyi Tamás, 2011. 09. 02. 22:30

"...hiába van meg a 95%-a."

Kicsit kötekszem:
Minek a 95%-a? A részletes projektspecifikációnak, ami a szerződés előtt lett hosszasan kőbe (szerződésbe) vésve?

És ha időközben - az elkészült részteljesítések tapasztatai alapján - kiderül, hogy nem is pont arra/úgy van szükség?
Mi a jobb? Egy 100%-os teljesítés, de nem túl jól használható eredmény, vagy egy 90%-os teljesítésű, de az igényeknek leginkább megfelelő megoldás?

Természetesen sokszor igaz, hogy egzakt módon lehet és kell mérni, hogy valami kész van-e, vagy nem.
Azonban - pl. fejlesztési projektek kapcsán - érdemes meggondolni, mit is akarunk a végére elérni ill. mit és hogyan definiálunk, mérünk, követelünk meg hozzá... (lásd pl. iteratív szoftverfejlesztés)

A megjegyzés klasszikus IT szemléletet tükröz, akárki írhatta volna. Az kétségkívül igaz, hogy egy 90%-os, de az igényeknek megfelelő megoldás jobb, mint egy 100%-os de nem használható. Ez olyannyira igaz, hogy még fejlesztési módszertant is építettek rá: Rapid Application Development (RAD).

A RAD előnye a gyorsaság. Minél hamarabb van valami (prototípus, működő szoftver), annál hamarabb tudnak a felhasználók visszajelzést adni. A visszajelzés alapján pedig jobb szoftvert lehet késziteni.

A RAD fontos kiindulási pontja, hogy egy fejlesztési projektben a funkciók nagy részét gyorsan el lehet készteni. Viszonylag hamar lesz működő szoftverünk, viszonylag hamar elérjük az 50%-os teljesítési szintet, illetve innen gyorsan eljutunk a 70% és 90%-ig. A sok munka és idő az utolsó 10%-zal szokott lenni, ez az a rész, amikor a fejlesztők vért izzadnak és hétvégéznek (lásd 90-90 rule). A RAD-ban az az okosság, hogy felgyorsítjuk a 90% elérését, azaz minimálisra csökkentjük az előzetes tervezést és kihagyjuk az utolsó 10%-ot. Elvégre ez egy iteratív folyamat, megcsináljuk a 90%-ot, és a maradék 10%-et majd a következő iterációra hagyjuk. A felhasználók addig úgyis meggondolják magukat, új igények merülnek fel, szóval ne is törjük magunkat – feleslegesen – a 100% megvalósításával.

Jól hangzik, de akkor miért nem mindenki így fejleszt?

Mert két komoly baj is van:

1) A szoftver valójában sosem lesz kész – mindig csak 90%-ot érünk el, hogy utána a következő iterációban szintén csak 90% legyen a cél

2) A gyenge tervezés miatt egyre több architektúrális és minőségi problémánk lesz

Az 1. ponttal szeretnék foglalkozni bővebben.

A mondás úgy tartja, hogy jobb ma egy veréb, mint holnap egy túzok. Azaz jobb ma egy 90%-osan kész, működő szoftver, mint holnap egy 100%-os. A felhasználók örülnek, mindenki boldog… aztán a felhasználók megkérdezik, hogy a maradék funkció mikor lesz kész.

Ugyanis nekik minden funkció kell. Ahogyan Holden írta, a teljesítésnek csak két állapota van: készen van, vagy nincs. Ha 10% hiányzik, az nincs kész.

A valóság az, hogy egy 90%-osan kész szoftverrel a felhasználók nem tudnak sokat kezdeni. Az üzleti célok adottak, és azokat egyszer valamikor 100%-ban el kell érni. Például tegyük fel, hogy a projekt célja egy új autó modell bevezetése, illetve az ehhez szükség változtatások végrehajtása az informatikai rendszereken. Amíg ezek nincsenek készen, addig az új modellt nem tudjuk értékesíteni. Ha a változtatások 90%-ban készen vannak, az azt jelenti, hogy 10% még hiányzik, vagyis az új modell még mindig nem értékesíthető. Ilyen értelemben mindegy, hogy a készültség mértéke 50%, 70% vagy 90%.

Még rosszabb a helyzet olyan fejlesztési projekteknél, ahol a fejlesztésen kívül egyéb üzleti feladatok is vannak, például oktatás vagy üzleti folyamat változás. Egy 90%-ban kész szoftvert nem lehet leoktatni, vagy le lehet, de utána az oktatást meg kell ismételni a 100%-osan kész szoftveren. Az üzleti folyamatok változtatása is kétállapotú: vagy a régit követjük, vagy az újat. Olyan nincs, hogy 90%-ban az újat követjük, de 10%-ban a régit.

(Arról nem is beszélve, hogy a 10%-ot az informatikusok választanák ki, nem az üzleti döntéshozók.)

Mondok egy analógiát: tegyük fel, hogy a közlekedésünket átállítanánk jobboldali közlekedésről baloldalira. Csak 100%-os átállás lehetséges, részleges átállás (90%-os) nem lehetséges. Nem mondhatjuk azt, hogy a személyautók és buszok átállnak és a bal oldalon haladnak, de a teherautókra még nem dolgoztuk ki a szabályokat ezért azok továbbra is a jobb oldalon közlekednek.

Mondok egy analógiát: tegyük fel, hogy álmaink házát építtetjük egy építésszel. Nagyon meglepő lenne, ha a ház 90%-ban elkészül, és az építész késznek minősíti a munkát. Bizonyára nem fogadnánk el késznek és nem költöznénk be. Bizonyára megoldható lenne, hogy a ház 90%-ban kész és beköltözhető – feltételezve, hogy mi választjuk ki a 90%-ot, és nem az építész. De ha be is költöznénk, a maradék 10%-ra is igényt tartanánk, mert hiszen egy teljesen kész házat szeretnénk a birtokunkban tudni.

 

A tévedés oka abban keresendő, hogy a programozók a készenlétet a specifikációhoz képest mérik, a felhasználók pedig az igényeikhez képest. A kettő nem ugyanaz, és ez jelenti a szoftverfejlesztés egyik, ha nem a legnagyobb kihívását. A felhasználó, a megrendelő fejében pontosan létezik egy kép az elvégzendő munkáról. Számára a munka akkor van kész, amikor a szoftver ennek a képnek 100%-ban megfelel. Nem hamarabb, és nem 90%-ban.

Azonban a kép a felhasználó fejében van, a programozók pedig nem tudnak gondolatot olvasni. Kell egy közbenső kommunikációs eszköz – a specifikáció (vagy nevezhetjük backlog-nak is, mindegy) – ami leírja ezt a képet, és a fejlesztők el tudják olvasni. Különben nem tudnának fejleszteni. A kommunikáció szükségszerűen veszteséggel jár, tehát a specifikáció nem lesz 100%-ban ugyanaz, mint ami a felhasználó fejében van. Arról nem is beszélve, hogy bizonyos részletek lehetnek homályosak, illetve az igények idővel megváltozhatnak.

Mindez úgy csapódhat le a programozóknál, hogy nem érdemes 100%-os készenlétre hajtani, hiszen a végén úgyse az eredeti specifikáció 100%-át kell megvalósítani. Egy igen jó közelítés az, ha megvalósítjuk a nagyját, aztán majd kezeljük a felmerülő igényeket és a különbségeket. Szóval lehet, hogy a végén csak a specifikáció 90%-át valósítjuk meg, de ettől még az üzleti igények 100%-a a cél.

A dolog azért fontos, mert egy adott ponton a programozók pénzt szeretnének látni a munkájukért. A megrendelő pedig általában olyan, hogy a beígért pénz 100%-át csak akkor szeretné kifizetni, ha az igényei 100%-át sikerült kielégíteni. Nem fog akarni fizetni egy 90%-os a teljesítésre.

Éppen ezért bármilyen fejlesztési módszertan, ami a 90%-os teljesítést célozza meg, nem az ügyfél érdekeinek és szándékának megfelelő. Hiába érzi azt az ügyfél a fejlesztés alatt, hogy jobban ki van szolgálva (hamarabb kap működő szoftvert), ha a végén nem készül el a teljes körű megoldás.

Természetesen kivételek vannak, és ezért az ilyen fejlesztéseknek is megvan a helyük.

Egy marketing célú céges web oldal esetén például fontosabb lehet a gyors megjelenés, mint a teljes funkcionalitás. Ha a design megvan és lehet a web oldalon keresztül rendelni, akkor nem baj, ha pár funkció még hiányzik (mondjuk a fórum még nem elérhető). Az ilyen projektekben kimondottan előny, pénzben mérhető üzleti előny, ha minél hamarabb elkészül egy részleges, de már működő megoldás.

Az informatikai projektek túlnyomó része nem ilyen.

Csak informatikus lehet az, aki szerint egy 90%-os megoldás megfelelő J

Holden blogján olvastam Határ és határidő cikket. Az egyik megjegyzés különösen érdekes volt:

Matyi Tamás, 2011. 09. 02. 22:30

"...hiába van meg a 95%-a."

Kicsit kötekszem:
Minek a 95%-a? A részletes projektspecifikációnak, ami a szerződés előtt lett hosszasan kőbe (szerződésbe) vésve?

És ha időközben - az elkészült részteljesítések tapasztatai alapján - kiderül, hogy nem is pont arra/úgy van szükség?
Mi a jobb? Egy 100%-os teljesítés, de nem túl jól használható eredmény, vagy egy 90%-os teljesítésű, de az igényeknek leginkább megfelelő megoldás?

Természetesen sokszor igaz, hogy egzakt módon lehet és kell mérni, hogy valami kész van-e, vagy nem.
Azonban - pl. fejlesztési projektek kapcsán - érdemes meggondolni, mit is akarunk a végére elérni ill. mit és hogyan definiálunk, mérünk, követelünk meg hozzá... (lásd pl. iteratív szoftverfejlesztés)

A megjegyzés klasszikus IT szemléletet tükröz, akárki írhatta volna. Az kétségkívül igaz, hogy egy 90%-os, de az igényeknek megfelelő megoldás jobb, mint egy 100%-os de nem használható. Ez olyannyira igaz, hogy még fejlesztési módszertant is építettek rá: Rapid Application Development (RAD).

A RAD előnye a gyorsaság. Minél hamarabb van valami (prototípus, működő szoftver), annál hamarabb tudnak a felhasználók visszajelzést adni. A visszajelzés alapján pedig jobb szoftvert lehet késziteni.

A RAD fontos kiindulási pontja, hogy egy fejlesztési projektben a funkciók nagy részét gyorsan el lehet készteni. Viszonylag hamar lesz működő szoftverünk, viszonylag hamar elérjük az 50%-os teljesítési szintet, illetve innen gyorsan eljutunk a 70% és 90%-ig. A sok munka és idő az utolsó 10%-zal szokott lenni, ez az a rész, amikor a fejlesztők vért izzadnak és hétvégéznek (lásd 90-90 rule). A RAD-ban az az okosság, hogy felgyorsítjuk a 90% elérését, azaz minimálisra csökkentjük az előzetes tervezést és kihagyjuk az utolsó 10%-ot. Elvégre ez egy iteratív folyamat, megcsináljuk a 90%-ot, és a maradék 10%-et majd a következő iterációra hagyjuk. A felhasználók addig úgyis meggondolják magukat, új igények merülnek fel, szóval ne is törjük magunkat – feleslegesen – a 100% megvalósításával.

Jól hangzik, de akkor miért nem mindenki így fejleszt?

Mert két komoly baj is van:

1) A szoftver valójában sosem lesz kész – mindig csak 90%-ot érünk el, hogy utána a következő iterációban szintén csak 90% legyen a cél

2) A gyenge tervezés miatt egyre több architektúrális és minőségi problémánk lesz

Az 1. ponttal szeretnék foglalkozni bővebben.

A mondás úgy tartja, hogy jobb ma egy veréb, mint holnap egy túzok. Azaz jobb ma egy 90%-osan kész, működő szoftver, mint holnap egy 100%-os. A felhasználók örülnek, mindenki boldog… aztán a felhasználók megkérdezik, hogy a maradék funkció mikor lesz kész.

Ugyanis nekik minden funkció kell. Ahogyan Holden írta, a teljesítésnek csak két állapota van: készen van, vagy nincs. Ha 10% hiányzik, az nincs kész.

A valóság az, hogy egy 90%-osan kész szoftverrel a felhasználók nem tudnak sokat kezdeni. Az üzleti célok adottak, és azokat egyszer valamikor 100%-ban el kell érni. Például tegyük fel, hogy a projekt célja egy új autó modell bevezetése, illetve az ehhez szükség változtatások végrehajtása az informatikai rendszereken. Amíg ezek nincsenek készen, addig az új modellt nem tudjuk értékesíteni. Ha a változtatások 90%-ban készen vannak, az azt jelenti, hogy 10% még hiányzik, vagyis az új modell még mindig nem értékesíthető. Ilyen értelemben mindegy, hogy a készültség mértéke 50%, 70% vagy 90%.

Még rosszabb a helyzet olyan fejlesztési projekteknél, ahol a fejlesztésen kívül egyéb üzleti feladatok is vannak, például oktatás vagy üzleti folyamat változás. Egy 90%-ban kész szoftvert nem lehet leoktatni, vagy le lehet, de utána az oktatást meg kell ismételni a 100%-osan kész szoftveren. Az üzleti folyamatok változtatása is kétállapotú: vagy a régit követjük, vagy az újat. Olyan nincs, hogy 90%-ban az újat követjük, de 10%-ban a régit.

(Arról nem is beszélve, hogy a 10%-ot az informatikusok választanák ki, nem az üzleti döntéshozók.)

Mondok egy analógiát: tegyük fel, hogy a közlekedésünket átállítanánk jobboldali közlekedésről baloldalira. Csak 100%-os átállás lehetséges, részleges átállás (90%-os) nem lehetséges. Nem mondhatjuk azt, hogy a személyautók és buszok átállnak és a bal oldalon haladnak, de a teherautókra még nem dolgoztuk ki a szabályokat ezért azok továbbra is a jobb oldalon közlekednek.

Mondok egy analógiát: tegyük fel, hogy álmaink házát építtetjük egy építésszel. Nagyon meglepő lenne, ha a ház 90%-ban elkészül, és az építész késznek minősíti a munkát. Bizonyára nem fogadnánk el késznek és nem költöznénk be. Bizonyára megoldható lenne, hogy a ház 90%-ban kész és beköltözhető – feltételezve, hogy mi választjuk ki a 90%-ot, és nem az építész. De ha be is költöznénk, a maradék 10%-ra is igényt tartanánk, mert hiszen egy teljesen kész házat szeretnénk a birtokunkban tudni.

 

A tévedés oka abban keresendő, hogy a programozók a készenlétet a specifikációhoz képest mérik, a felhasználók pedig az igényeikhez képest. A kettő nem ugyanaz, és ez jelenti a szoftverfejlesztés egyik, ha nem a legnagyobb kihívását. A felhasználó, a megrendelő fejében pontosan létezik egy kép az elvégzendő munkáról. Számára a munka akkor van kész, amikor a szoftver ennek a képnek 100%-ban megfelel. Nem hamarabb, és nem 90%-ban.

Azonban a kép a felhasználó fejében van, a programozók pedig nem tudnak gondolatot olvasni. Kell egy közbenső kommunikációs eszköz – a specifikáció (vagy nevezhetjük backlog-nak is, mindegy) – ami leírja ezt a képet, és a fejlesztők el tudják olvasni. Különben nem tudnának fejleszteni. A kommunikáció szükségszerűen veszteséggel jár, tehát a specifikáció nem lesz 100%-ban ugyanaz, mint ami a felhasználó fejében van. Arról nem is beszélve, hogy bizonyos részletek lehetnek homályosak, illetve az igények idővel megváltozhatnak.

Mindez úgy csapódhat le a programozóknál, hogy nem érdemes 100%-os készenlétre hajtani, hiszen a végén úgyse az eredeti specifikáció 100%-át kell megvalósítani. Egy igen jó közelítés az, ha megvalósítjuk a nagyját, aztán majd kezeljük a felmerülő igényeket és a különbségeket. Szóval lehet, hogy a végén csak a specifikáció 90%-át valósítjuk meg, de ettől még az üzleti igények 100%-a a cél.

A dolog azért fontos, mert egy adott ponton a programozók pénzt szeretnének látni a munkájukért. A megrendelő pedig általában olyan, hogy a beígért pénz 100%-át csak akkor szeretné kifizetni, ha az igényei 100%-át sikerült kielégíteni. Nem fog akarni fizetni egy 90%-os a teljesítésre.

Éppen ezért bármilyen fejlesztési módszertan, ami a 90%-os teljesítést célozza meg, nem az ügyfél érdekeinek és szándékának megfelelő. Hiába érzi azt az ügyfél a fejlesztés alatt, hogy jobban ki van szolgálva (hamarabb kap működő szoftvert), ha a végén nem készül el a teljes körű megoldás.

Természetesen kivételek vannak, és ezért az ilyen fejlesztéseknek is megvan a helyük.

Egy marketing célú céges web oldal esetén például fontosabb lehet a gyors megjelenés, mint a teljes funkcionalitás. Ha a design megvan és lehet a web oldalon keresztül rendelni, akkor nem baj, ha pár funkció még hiányzik (mondjuk a fórum még nem elérhető). Az ilyen projektekben kimondottan előny, pénzben mérhető üzleti előny, ha minél hamarabb elkészül egy részleges, de már működő megoldás.

Az informatikai projektek túlnyomó része nem ilyen.

Hogyan lehet sikeres egy informatikai kkv, hogyan jusson zöld ágra a multival?

E blog célja, hogy a hazai informatikusokat tanácsokkal és tapasztalattal lássa el. Ezen belül többször is foglalkoztam a kkv szektorral, a magyar IT vállalkozásokkal. Például Tévhitek az ügyfélről, Hogyan lesz versenyképes az IKT szektor? , A kisvállalati és nagyvállalati szoftverfejlesztés összehasonlítása vagy Magyaros cégtörténet.

A cikkeim nagy része a multik világáról szól, hiszen ebben vagyok benne. Nem vagyok vállalkozó, ezért vállalkozásokról nem tudok írni. Viszont az világos, hogy erős kkv nélkül elveszett a hazai IT ipar, ezért most próbálok kimondottan hozzájuk szólni.

Egy olvasói privát levelezés kapcsán merült fel a kérdés: mit tegyen egy kkv ahhoz, hogy az informatikai projektje sikeres legyen? Hiszen a kkv alapvetően mindent megtesz az ügyfélért, ennek ellenére vannak kudarcok.

Előre bocsájtom, hogy a cikk kizárólag a szakmai kérdéseket érinti. Nem foglalkozok az állammal, az adóhatósággal vagy a számlázási kérdésekkel – elismerve azt, hogy ezek legalább annyira fontosak egy vállalkozás túlélése szempontjából, mint a szakmaiság.

Mi kell egy sikeres IT projekthez? Egy jó beszállító és egy jó ügyfél!

Kettőn áll a vásár, és mindkettőnek hozzá kell tennie a maga részét ahhoz, hogy a végén határidőre elkészüljön a munka. Tessék szíves lenni felismerni azt, hogy pusztán az egyik fél egyoldalúan nem fogja tudni sikerre vinni a projektet, ha a másik fél ebben nem partner!

Általában véve igaz, hogy egyik vagy másik fél át tud tolni problémákat a másik oldalra vagy be tud segíteni a másiknak (kinek mi áll érdekében), de ezen taktikák hosszú távon nem működnek. Ha a megrendelő béna és nem ismeri az informatikai projektek természetet, akkor mindegy mennyire tapossa bele a földbe a beszállítóját, abból nem lesz jó szoftver.

Visszafelé is igaz: ha a beszállító nem hajlandó dolgozni (például mert beesett neki egy másik ügyféltől egy nagyobb megrendelés), akkor a megrendelő nem fogja tudni belőle kisajtolni a munkát. Teljesen mindegy, hogy milyen szerződést írtak, vagy hogy kinek mennyire jó az ügyvédje.

A képlet azt jelenti, hogy nagyjából 2 dolgot lehet csinálni:   
1) A vállalkozó a saját háza táján söpröget   
2) Növeli annak a valószínűségét, hogy az ügyfél oldal is jó legyen

Úgy vélem, hogy minden más tényezőnek – körülmények, politika, svájci frank árfolyama, a csillagok állása – nincs jelentősége, mert azok áthidalhatók.

1) A vállalkozói oldal sikeressége

Alapvetően itt arról van szó, hogy a vállalkozás képes legyen az elejétől a végéig végigvinni a megrendelést, és szállítani az előzetes terv szerint.

Azzal sosem szokott gond lenni, hogy a vállalkozó ne tudna vagy ne akarna programot írni. Valamilyen program mindig elkészül. A gond inkább az „egyéb” dolgokkal szokott lenni, mint pl. a minőség, a körítés és a menedzsment.

Az alábbiakban kiemelek néhány típushibát a teljesség igénye nélkül, a listát feltehetőleg hosszan lehetne folytatni.

Kisipari szoftverfejlesztés vs nagyipari szoftverfejlesztés: A kkv-k más módszerek szerint dolgoznak. Lehetnek ezekben kiválóak, de egy multinacionális cégnél egészen mások a körülmények, emiatt egészen más eljárásokat követnek. Lehet, hogy ami kisvállalkozások esetén bevált, az a multinál a bukás kulcsa. Éppen ezért fontos az alkalmazkodás, illetve a multikkal való tapasztalat megszerzése.

A bizalom mindent megold: Minden projekt úgy indul, hogy a megrendelő megbízik a vállalkozójában (különben nem szerződött volna le vele). Ez a bizalom azonban a projekt végére elpárologhat, például mert lecserélték a multi oldalon a projekt gazdáját, vagy mert új kényszerek kerültek elő. Ilyenkor a bizalmon túl az is fontos, hogy a kkv tettei objektíven nézve is helytálljanak.

A projekt kereteinek fel nem térképezése: Az iskolapélda arról szól, hogy a megrendelő az egy konkrét bizonyos személy, és ő mond el mindent (az igényeit) a fejlesztőknek. Ezzel szemben multi környezetben jellemző, hogy a projektben nem csak egy ügyfél van, esetleg a megrendelő és az ügyfél nem azonos személy. Az is lehet, hogy a fejlesztésre bizonyos belső szabályzatok vonatkoznak, amiket a megrendelő elfelejtett közölni a vállalkozóval. Márpedig tudjuk, hogy a törvény nem ismerete nem mentesít annak betartásától! A megoldás az, hogy jó alaposan feltérképezzük az ügyfelet a projekt indulásakor, illetve igyekezzünk olyan ügyfelekkel dolgozni, akiket ismerünk. Ökölszabályként azt mondom, hogy multi saját IT-ja bevonása nélkül ne kezdjünk fejlesztésbe, és a belső IT feltehetőleg a kereteket igen jól el tudja mondani.

Rosszul megírt szerződések: Sajnos rengeteg rossz informatikai szerződés létezik, és ennek nem ritkán a multi az oka. Sok esetben a szerződést jogok és kötelezettségek halmazának tekintik. Ehelyett próbáljunk meg arra rávilágítani, hogy a projektnek valahogyan el kell készülnie, ez nem jogi kérdés. A szerződésnek pusztán a kereteket kell rögzítenie, mégpedig úgy, hogy ne kényszerítse a vállalkozót rossz munkavégzésre – amivel aztán az ügyfél is rosszul jár. Olyan szerződést semmiképpen ne írjunk alá, amit lehetetlen teljesíteni! Az ügyvédeknek nem érdekük az, hogy ellehetetlenítsék a munkát.

Az ügyfélnek mindig igaza van! Igaz, de vannak helyzetek, amikor téved, és akkor udvariasan ellent kell neki mondani. Míg a vállalkozásra általában a hozzáértés jellemző, a multiknál a kompetencia nagyon változó – lehet kiváló de lehet teljesen nulla. Ne kövessük vakon az ügyfél igényeket, mert a szakadékba vezethetnek.

Mi csak azt csináljuk, amit kértek tőlünk, se többet se kevesebbet! Senki se szeret plusz fizetés nélkül többet dolgozni, a valóság azonban az, hogy egy 100%-os teljesítéshez 110%-ot kell letenni az asztalra. Nem elég a munkát elvégezni, de piros szalaggal át kell kötni és ezüst tálcán nyújtani. Fogadjuk el, hogy az elvégzett munka több lesz a tervezettnél, ezért kell tartalékot rakni a tervbe.

Mi értünk az IT-hoz, az ügyfél ne szóljon bele! Az igaz, hogy az átlagos kkv ért az informatikához, de az igazán jó szakemberek a multi közelében szoktak felbukkanni. Ezért nem árt a szerénység. Főleg mivel az átlagos kkv átlagos informatikusa nem biztos, hogy ismeri és alkalmazza az iparág legjobb gyakorlatait.

Minőség, szakmai igényesség. A legtöbb kkv – akikkel találkoztam – elsősorban a megoldásra és a határidőre összpontosít, és nem arra, hogy az a megoldás minőségi is legyen. Nincs minőségbiztosítás, nincsenek szakmai standard-ok, mindenki úgy fejleszt, ahogy akar. Márpedig a látványos bukások abból fakadnak, hogy van ugyan megoldás, csak az nem válik be, vagy nem várt „mellékhatások” lépnek fel. Lassan járj, tovább érsz! Sajnos sok ügyfél úgy tekint a minőségre, mint extra kiadás, amire neki nincs szüksége – de majd lesz, ha összeomlik a projekt.

Pénz, pénz, pénz! Igaz, hogy a vállalkozás a pénzről szól (pénzért cserébe IT szolgáltatást nyújtani a pénzzel rendelkező, de IT-hoz nem értő ügyfélnek), viszont ne szédüljünk meg a nagy pénzek csalóka ígéretétől! A nagy projekttel együtt járó nagy pénzeket könnyű elkölteni, de az oda vezető út – a teljesítés – nagyon hosszú és nagyon keserves.

Bevállalom a lehetetlent is. Az eddigi tapasztalataim alapján ami lehetetlen, az nem is fog elkészülni. Felesleges a fejünket törni „okos” megoldásokon.

Rokonok. Sok vállalkozásra jellemző, hogy abban rokonok/ismerősök dolgoznak, és ilyenkor a teljesítmény nem, csak a személyes kapcsolat számít. Ez az a pont, amikor a szakmaiság meghal.

Gyors, pontos és rendszeres kommunikáció. Igaz, hogy pénzt a projekt végén a teljesítésre adnak, de addig hosszú az út, és sokat kell kommunikálni. Meg kell válogatni, hogy kivel mikor és mennyit – nem biztos, hogy az ügyfél oldali megbízott az egyetlen ember a kommunikációban, és bizonyára az ő élete is egyszerűbb, ha tájékoztatva van.

Kicsi hal vagyok, megesznek a nagyok. Rossz szemszögből nézzük a dolgokat! A nagyoknak is szüksége van a kicsikre, hiszen a nagynak van pénze, de szüksége van bizonyos informatikai feladatok végrehajtására. A kicsinek szakértelme van, amit pénzért elad, tehát keményen dolgozik és rugalmas, hogy azokat a feladatokat végrehajtsa. Kereslet és kínálat találkozása, win-win.

2) Az ügyfél oldal sikerességének növelése

Az ügyfél oldal sikerességéért elsősorban az ügyfél felelős, de a vállalkozó sokat tehet, hogy segítse ebben, hogy fogja a kezét, vagy éppen rákényszerítse arra, hogy a helyes utat kövesse. Éppen ezért a vállalkozóknak azt tanácsolnám, a saját feladataikon túl az ügyfélre is figyeljenek fél szemmel, és szükség szerint avatkozzanak be. Az alábbiakban néhány tippet adok, szintén a teljesség igénye nélkül.

Erős ügyfél, gyenge ügyfél. Az ügyfél vezetheti a projektet erős kézzel, de az is lehet, hogy nem igazán foglalkozik vele. Szakmailag is lehet erős, de az is lehet, hogy nem ért az IT-hoz. A vállalkozó szerepe az, hogy ehhez alkalmazkodjon és kövesse az ügyfelet. Például ha az erős kezű ügyfél találkozik a harcias és kemény vállalkozóval (mindkettő erős) abból baj lesz. Ugyanígy baj lesz, ha az ügyfelet nem érdekli a munka megszervezése, de a vállalkozó sem akar ezzel foglalkozni. A projekt kezdetén fel kell mérni, hogy ki milyen szerepet fog „játszani” és ezeket össze kell hangolni. Célszerűen már a szerződésben tisztázni kell, ki felelős a projektvezetésért.

IT osztály bevonása. Már említettem, hogy az informatikai fejlesztés akkor a legbiztonságosabb, amikor abban a belső IT is részt vesz. Ha ebben a megrendelő nem partner, finoman rá kell vezetni. Pontosan neki az érdeke.

Menedzsment eszközök használata. Sok esetben a multinál a projekt vezetését olyan emberek kapják meg, akik az adott szakterület mesterei, de se projektek vezetéséhez, sem az informatikához nem értenek. Számukra nem árt – némi oktatási jelleggel – megmutatni az alapvető menedzsment technikákat, például projekt terv készítés, rendszeres státusz meeting vagy határidők követése.

Ügyfél oldali erőforrások biztosítása. Nincs projekt ügyfél oldali erőforrások nélkül, mint például információ, a megfelelő szakemberek rendelkezésre állása, elfogadási tesztelés vagy igények specifikálása. Ezeket a feladatokat a munka legeslegelején tisztázni kell, és nem szabad hagyni, hogy az ügyfél feledékenysége miatt ne álljon rendelkezésre. A szerződésben azt is célszerű tisztázni, mi az erre vonatkozó folyamat, és mi van akkor, ha mondjuk az ügyfél nem válaszol egy kérdésre. Ezt annak ellenére fontosnak tartom, hogy az ügyfél oldalon ülök. Sajnos tényleg az a helyzet, hogy mondjuk egy kulcsszakértő nem elérhető hetekig, viszont a véleménye nélkül nem tud haladni a projekt – amiről cseppet sem a vállalkozó tehet, de a csúszást a vállalkozó nyakába varrják (kötbér).

Eredmények felmutatása. Az ügyfél oldali projektvezetőnek nyilvánvalóan elszámolási kötelezettsége van a saját főnökei felé a projekt haladásáról. Ezért fontos az, hogy legyenek kézzel fogható, könnyen érthető leszállítandók, könnyen érthető határidők, legyenek látványos előrelépések, amiket fel lehet mutatni a vezetőség felé mint eredmény. A „jól haladok, hidd el hogy kész lesz” típusú státuszjelentés nem segít.

Igények pontos meghatározása. Talán a legfontosabb sikertényező az informatikai projektben. A vállalkozó próbálja meg segíteni ügyfelét az igények összegyűjtésében, például prototípus építéssel, GUI tervvel, dokumentáció készítéssel, vagy abban, hogy saját maga is érti az adott üzleti domain-t.

Krízis kezelés. Katasztrófák, váratlan helyzetek biztosan lesznek. Ilyenkor szem előtt kell tartani, hogy az ügyféltől érkező „csúnya levelek” csak pánikreakciók. A lényeg az, hogy az ügyfél érdekét – a katasztrófa megoldását – mindig tartsuk szem előtt, akkor is ha ehhez plusz munkát kell végezni.

„Quick and dirty” megoldások megnehezítése. Előfordulnak olyan esetek, amikor az ügyfél rákényszerít gyors, de kockázatos megoldásra. Ilyenkor mérlegelni kell, és lehetőség szerint elkerülni.

Ne áruljunk zsák krumplit. A legtöbb ügyfél úgy szeretne szoftvert vásárolni, mint egy zsák krumplit: kifizet x milliót, és elvárja, hogy ezért a sült galamb a szájába repüljön. Csábító lehetőség (mármint az x millió), de hosszú távon a vállalkozó jár rosszul. Tudatosítani kell az ügyféllel, hogy egy informatikai projekt nem így néz ki, hogy neki feladatai vannak, és hogy a vállalkozónak ismernie kell a projekt hátterét, az átfogó képet. Például ha a projekt több más csapat is részt vesz, akkor szükség lesz a többi csapatok szakértőivel történő közvetlen kommunikációra.

Én problémám, Te problémád. Tévedés, közös hajóban evezünk, csak Mi problémánk van.

Összefoglalás

A vállalkozó tegyen le minőséget az asztalra és teljesítsen. A munka megkezdésétől kezdve törekedjen a bizalomra és a jó kapcsolatra, de ugyanilyen fontos a munka kereteinek kialakítása – ide értve a jó szerződést.

Az ügyfél sajátosságaihoz alkalmazkodni kell, ha szükséges akkor támogatni, ha szükséges akkor megnehezíteni dolgokat. Fontos az ügyfél igényeinek pontos megismerése, de ezen felül meg kell ismerni azokat a körülményeket is, amiket a projekt végrehajtása során figyelembe kell venni.

Mindezeket összegezve kijelenthető, hogy egy már ismert ügyfélnél sokkal jobbak az esélyek sikeres teljesítésre, mint egy új ügyfélnél. A vállalkozó igyekezzen régi ügyfeleit megtartani, az újakkal való kapcsolatát pedig óvatosan felépíteni.

Hogyan lehet sikeres egy informatikai kkv, hogyan jusson zöld ágra a multival?

E blog célja, hogy a hazai informatikusokat tanácsokkal és tapasztalattal lássa el. Ezen belül többször is foglalkoztam a kkv szektorral, a magyar IT vállalkozásokkal. Például Tévhitek az ügyfélről, Hogyan lesz versenyképes az IKT szektor? , A kisvállalati és nagyvállalati szoftverfejlesztés összehasonlítása vagy Magyaros cégtörténet.

A cikkeim nagy része a multik világáról szól, hiszen ebben vagyok benne. Nem vagyok vállalkozó, ezért vállalkozásokról nem tudok írni. Viszont az világos, hogy erős kkv nélkül elveszett a hazai IT ipar, ezért most próbálok kimondottan hozzájuk szólni.

Egy olvasói privát levelezés kapcsán merült fel a kérdés: mit tegyen egy kkv ahhoz, hogy az informatikai projektje sikeres legyen? Hiszen a kkv alapvetően mindent megtesz az ügyfélért, ennek ellenére vannak kudarcok.

Előre bocsájtom, hogy a cikk kizárólag a szakmai kérdéseket érinti. Nem foglalkozok az állammal, az adóhatósággal vagy a számlázási kérdésekkel – elismerve azt, hogy ezek legalább annyira fontosak egy vállalkozás túlélése szempontjából, mint a szakmaiság.

Mi kell egy sikeres IT projekthez? Egy jó beszállító és egy jó ügyfél!

Kettőn áll a vásár, és mindkettőnek hozzá kell tennie a maga részét ahhoz, hogy a végén határidőre elkészüljön a munka. Tessék szíves lenni felismerni azt, hogy pusztán az egyik fél egyoldalúan nem fogja tudni sikerre vinni a projektet, ha a másik fél ebben nem partner!

Általában véve igaz, hogy egyik vagy másik fél át tud tolni problémákat a másik oldalra vagy be tud segíteni a másiknak (kinek mi áll érdekében), de ezen taktikák hosszú távon nem működnek. Ha a megrendelő béna és nem ismeri az informatikai projektek természetet, akkor mindegy mennyire tapossa bele a földbe a beszállítóját, abból nem lesz jó szoftver.

Visszafelé is igaz: ha a beszállító nem hajlandó dolgozni (például mert beesett neki egy másik ügyféltől egy nagyobb megrendelés), akkor a megrendelő nem fogja tudni belőle kisajtolni a munkát. Teljesen mindegy, hogy milyen szerződést írtak, vagy hogy kinek mennyire jó az ügyvédje.

A képlet azt jelenti, hogy nagyjából 2 dolgot lehet csinálni:   
1) A vállalkozó a saját háza táján söpröget   
2) Növeli annak a valószínűségét, hogy az ügyfél oldal is jó legyen

Úgy vélem, hogy minden más tényezőnek – körülmények, politika, svájci frank árfolyama, a csillagok állása – nincs jelentősége, mert azok áthidalhatók.

1) A vállalkozói oldal sikeressége

Alapvetően itt arról van szó, hogy a vállalkozás képes legyen az elejétől a végéig végigvinni a megrendelést, és szállítani az előzetes terv szerint.

Azzal sosem szokott gond lenni, hogy a vállalkozó ne tudna vagy ne akarna programot írni. Valamilyen program mindig elkészül. A gond inkább az „egyéb” dolgokkal szokott lenni, mint pl. a minőség, a körítés és a menedzsment.

Az alábbiakban kiemelek néhány típushibát a teljesség igénye nélkül, a listát feltehetőleg hosszan lehetne folytatni.

Kisipari szoftverfejlesztés vs nagyipari szoftverfejlesztés: A kkv-k más módszerek szerint dolgoznak. Lehetnek ezekben kiválóak, de egy multinacionális cégnél egészen mások a körülmények, emiatt egészen más eljárásokat követnek. Lehet, hogy ami kisvállalkozások esetén bevált, az a multinál a bukás kulcsa. Éppen ezért fontos az alkalmazkodás, illetve a multikkal való tapasztalat megszerzése.

A bizalom mindent megold: Minden projekt úgy indul, hogy a megrendelő megbízik a vállalkozójában (különben nem szerződött volna le vele). Ez a bizalom azonban a projekt végére elpárologhat, például mert lecserélték a multi oldalon a projekt gazdáját, vagy mert új kényszerek kerültek elő. Ilyenkor a bizalmon túl az is fontos, hogy a kkv tettei objektíven nézve is helytálljanak.

A projekt kereteinek fel nem térképezése: Az iskolapélda arról szól, hogy a megrendelő az egy konkrét bizonyos személy, és ő mond el mindent (az igényeit) a fejlesztőknek. Ezzel szemben multi környezetben jellemző, hogy a projektben nem csak egy ügyfél van, esetleg a megrendelő és az ügyfél nem azonos személy. Az is lehet, hogy a fejlesztésre bizonyos belső szabályzatok vonatkoznak, amiket a megrendelő elfelejtett közölni a vállalkozóval. Márpedig tudjuk, hogy a törvény nem ismerete nem mentesít annak betartásától! A megoldás az, hogy jó alaposan feltérképezzük az ügyfelet a projekt indulásakor, illetve igyekezzünk olyan ügyfelekkel dolgozni, akiket ismerünk. Ökölszabályként azt mondom, hogy multi saját IT-ja bevonása nélkül ne kezdjünk fejlesztésbe, és a belső IT feltehetőleg a kereteket igen jól el tudja mondani.

Rosszul megírt szerződések: Sajnos rengeteg rossz informatikai szerződés létezik, és ennek nem ritkán a multi az oka. Sok esetben a szerződést jogok és kötelezettségek halmazának tekintik. Ehelyett próbáljunk meg arra rávilágítani, hogy a projektnek valahogyan el kell készülnie, ez nem jogi kérdés. A szerződésnek pusztán a kereteket kell rögzítenie, mégpedig úgy, hogy ne kényszerítse a vállalkozót rossz munkavégzésre – amivel aztán az ügyfél is rosszul jár. Olyan szerződést semmiképpen ne írjunk alá, amit lehetetlen teljesíteni! Az ügyvédeknek nem érdekük az, hogy ellehetetlenítsék a munkát.

Az ügyfélnek mindig igaza van! Igaz, de vannak helyzetek, amikor téved, és akkor udvariasan ellent kell neki mondani. Míg a vállalkozásra általában a hozzáértés jellemző, a multiknál a kompetencia nagyon változó – lehet kiváló de lehet teljesen nulla. Ne kövessük vakon az ügyfél igényeket, mert a szakadékba vezethetnek.

Mi csak azt csináljuk, amit kértek tőlünk, se többet se kevesebbet! Senki se szeret plusz fizetés nélkül többet dolgozni, a valóság azonban az, hogy egy 100%-os teljesítéshez 110%-ot kell letenni az asztalra. Nem elég a munkát elvégezni, de piros szalaggal át kell kötni és ezüst tálcán nyújtani. Fogadjuk el, hogy az elvégzett munka több lesz a tervezettnél, ezért kell tartalékot rakni a tervbe.

Mi értünk az IT-hoz, az ügyfél ne szóljon bele! Az igaz, hogy az átlagos kkv ért az informatikához, de az igazán jó szakemberek a multi közelében szoktak felbukkanni. Ezért nem árt a szerénység. Főleg mivel az átlagos kkv átlagos informatikusa nem biztos, hogy ismeri és alkalmazza az iparág legjobb gyakorlatait.

Minőség, szakmai igényesség. A legtöbb kkv – akikkel találkoztam – elsősorban a megoldásra és a határidőre összpontosít, és nem arra, hogy az a megoldás minőségi is legyen. Nincs minőségbiztosítás, nincsenek szakmai standard-ok, mindenki úgy fejleszt, ahogy akar. Márpedig a látványos bukások abból fakadnak, hogy van ugyan megoldás, csak az nem válik be, vagy nem várt „mellékhatások” lépnek fel. Lassan járj, tovább érsz! Sajnos sok ügyfél úgy tekint a minőségre, mint extra kiadás, amire neki nincs szüksége – de majd lesz, ha összeomlik a projekt.

Pénz, pénz, pénz! Igaz, hogy a vállalkozás a pénzről szól (pénzért cserébe IT szolgáltatást nyújtani a pénzzel rendelkező, de IT-hoz nem értő ügyfélnek), viszont ne szédüljünk meg a nagy pénzek csalóka ígéretétől! A nagy projekttel együtt járó nagy pénzeket könnyű elkölteni, de az oda vezető út – a teljesítés – nagyon hosszú és nagyon keserves.

Bevállalom a lehetetlent is. Az eddigi tapasztalataim alapján ami lehetetlen, az nem is fog elkészülni. Felesleges a fejünket törni „okos” megoldásokon.

Rokonok. Sok vállalkozásra jellemző, hogy abban rokonok/ismerősök dolgoznak, és ilyenkor a teljesítmény nem, csak a személyes kapcsolat számít. Ez az a pont, amikor a szakmaiság meghal.

Gyors, pontos és rendszeres kommunikáció. Igaz, hogy pénzt a projekt végén a teljesítésre adnak, de addig hosszú az út, és sokat kell kommunikálni. Meg kell válogatni, hogy kivel mikor és mennyit – nem biztos, hogy az ügyfél oldali megbízott az egyetlen ember a kommunikációban, és bizonyára az ő élete is egyszerűbb, ha tájékoztatva van.

Kicsi hal vagyok, megesznek a nagyok. Rossz szemszögből nézzük a dolgokat! A nagyoknak is szüksége van a kicsikre, hiszen a nagynak van pénze, de szüksége van bizonyos informatikai feladatok végrehajtására. A kicsinek szakértelme van, amit pénzért elad, tehát keményen dolgozik és rugalmas, hogy azokat a feladatokat végrehajtsa. Kereslet és kínálat találkozása, win-win.

2) Az ügyfél oldal sikerességének növelése

Az ügyfél oldal sikerességéért elsősorban az ügyfél felelős, de a vállalkozó sokat tehet, hogy segítse ebben, hogy fogja a kezét, vagy éppen rákényszerítse arra, hogy a helyes utat kövesse. Éppen ezért a vállalkozóknak azt tanácsolnám, a saját feladataikon túl az ügyfélre is figyeljenek fél szemmel, és szükség szerint avatkozzanak be. Az alábbiakban néhány tippet adok, szintén a teljesség igénye nélkül.

Erős ügyfél, gyenge ügyfél. Az ügyfél vezetheti a projektet erős kézzel, de az is lehet, hogy nem igazán foglalkozik vele. Szakmailag is lehet erős, de az is lehet, hogy nem ért az IT-hoz. A vállalkozó szerepe az, hogy ehhez alkalmazkodjon és kövesse az ügyfelet. Például ha az erős kezű ügyfél találkozik a harcias és kemény vállalkozóval (mindkettő erős) abból baj lesz. Ugyanígy baj lesz, ha az ügyfelet nem érdekli a munka megszervezése, de a vállalkozó sem akar ezzel foglalkozni. A projekt kezdetén fel kell mérni, hogy ki milyen szerepet fog „játszani” és ezeket össze kell hangolni. Célszerűen már a szerződésben tisztázni kell, ki felelős a projektvezetésért.

IT osztály bevonása. Már említettem, hogy az informatikai fejlesztés akkor a legbiztonságosabb, amikor abban a belső IT is részt vesz. Ha ebben a megrendelő nem partner, finoman rá kell vezetni. Pontosan neki az érdeke.

Menedzsment eszközök használata. Sok esetben a multinál a projekt vezetését olyan emberek kapják meg, akik az adott szakterület mesterei, de se projektek vezetéséhez, sem az informatikához nem értenek. Számukra nem árt – némi oktatási jelleggel – megmutatni az alapvető menedzsment technikákat, például projekt terv készítés, rendszeres státusz meeting vagy határidők követése.

Ügyfél oldali erőforrások biztosítása. Nincs projekt ügyfél oldali erőforrások nélkül, mint például információ, a megfelelő szakemberek rendelkezésre állása, elfogadási tesztelés vagy igények specifikálása. Ezeket a feladatokat a munka legeslegelején tisztázni kell, és nem szabad hagyni, hogy az ügyfél feledékenysége miatt ne álljon rendelkezésre. A szerződésben azt is célszerű tisztázni, mi az erre vonatkozó folyamat, és mi van akkor, ha mondjuk az ügyfél nem válaszol egy kérdésre. Ezt annak ellenére fontosnak tartom, hogy az ügyfél oldalon ülök. Sajnos tényleg az a helyzet, hogy mondjuk egy kulcsszakértő nem elérhető hetekig, viszont a véleménye nélkül nem tud haladni a projekt – amiről cseppet sem a vállalkozó tehet, de a csúszást a vállalkozó nyakába varrják (kötbér).

Eredmények felmutatása. Az ügyfél oldali projektvezetőnek nyilvánvalóan elszámolási kötelezettsége van a saját főnökei felé a projekt haladásáról. Ezért fontos az, hogy legyenek kézzel fogható, könnyen érthető leszállítandók, könnyen érthető határidők, legyenek látványos előrelépések, amiket fel lehet mutatni a vezetőség felé mint eredmény. A „jól haladok, hidd el hogy kész lesz” típusú státuszjelentés nem segít.

Igények pontos meghatározása. Talán a legfontosabb sikertényező az informatikai projektben. A vállalkozó próbálja meg segíteni ügyfelét az igények összegyűjtésében, például prototípus építéssel, GUI tervvel, dokumentáció készítéssel, vagy abban, hogy saját maga is érti az adott üzleti domain-t.

Krízis kezelés. Katasztrófák, váratlan helyzetek biztosan lesznek. Ilyenkor szem előtt kell tartani, hogy az ügyféltől érkező „csúnya levelek” csak pánikreakciók. A lényeg az, hogy az ügyfél érdekét – a katasztrófa megoldását – mindig tartsuk szem előtt, akkor is ha ehhez plusz munkát kell végezni.

„Quick and dirty” megoldások megnehezítése. Előfordulnak olyan esetek, amikor az ügyfél rákényszerít gyors, de kockázatos megoldásra. Ilyenkor mérlegelni kell, és lehetőség szerint elkerülni.

Ne áruljunk zsák krumplit. A legtöbb ügyfél úgy szeretne szoftvert vásárolni, mint egy zsák krumplit: kifizet x milliót, és elvárja, hogy ezért a sült galamb a szájába repüljön. Csábító lehetőség (mármint az x millió), de hosszú távon a vállalkozó jár rosszul. Tudatosítani kell az ügyféllel, hogy egy informatikai projekt nem így néz ki, hogy neki feladatai vannak, és hogy a vállalkozónak ismernie kell a projekt hátterét, az átfogó képet. Például ha a projekt több más csapat is részt vesz, akkor szükség lesz a többi csapatok szakértőivel történő közvetlen kommunikációra.

Én problémám, Te problémád. Tévedés, közös hajóban evezünk, csak Mi problémánk van.

Összefoglalás

A vállalkozó tegyen le minőséget az asztalra és teljesítsen. A munka megkezdésétől kezdve törekedjen a bizalomra és a jó kapcsolatra, de ugyanilyen fontos a munka kereteinek kialakítása – ide értve a jó szerződést.

Az ügyfél sajátosságaihoz alkalmazkodni kell, ha szükséges akkor támogatni, ha szükséges akkor megnehezíteni dolgokat. Fontos az ügyfél igényeinek pontos megismerése, de ezen felül meg kell ismerni azokat a körülményeket is, amiket a projekt végrehajtása során figyelembe kell venni.

Mindezeket összegezve kijelenthető, hogy egy már ismert ügyfélnél sokkal jobbak az esélyek sikeres teljesítésre, mint egy új ügyfélnél. A vállalkozó igyekezzen régi ügyfeleit megtartani, az újakkal való kapcsolatát pedig óvatosan felépíteni.

süti beállítások módosítása