Laczkó Gábor: – Üdvözlök mindenkit, én Laczkó Gábor vagyok, a Stylers, Braining Hub és a Protechtor egyik alapítója. Mai videónkban azt fogjuk megnézni, hogy hol hasalnak el IT folyamatok, fejlesztések. Két olyan szakemberrel fogok beszélgetni, akik számos fejlesztési projektben vettek részt, és vélhetően belefutottak már olyanba is, ami nem sikerült vagy nem feltétlenül úgy sikerült, ahogy tervezték. Mai vendégeim Novák István szoftvermérnök és agilis mentor, valamint Szirják Csaba Chaar-Lee Tribe Tech Lead a Foundationben. Köszöntelek titeket Chaar-Lee és István. Ha mondatok magatokról pár mondatot, azt megköszönöm.

Novák István: – Sziasztok, Novák István vagyok. Elsősorban az agilis múltam arra tekint vissza, hogy fejlesztőcsapatok fejlesztésével foglalkozom. Ez nagyon gyakran azt jelenti, hogy mentorálom őket, beülök közéjük és velük együtt hajtok végre egy-egy projektet. Segítem őket mind az agilis szemlélet, mind egyéb technológiai problémák megoldásában, kezelésében. A szoftvermérnöki és az agilis mentori tevékenységem mellett megszállott open source fejlesztő vagyok, szabadidőmben rengeteget foglalkozom webes technológiákkal, néha webes technológiákról szóló könyveket is írok. Nem nagyon tudom elképzelni ezt a szakmát anélkül, hogy az ember valamifajta fizikai tevékenységet ne végezne. Így nálam a hobbik listáján szerepel a hosszútávfutás és a könnyűbúvárkodás.

Laczkó Gábor: – Köszi István. Chaar-Lee?

Szirják Csaba: – Sok mindent meg tudnék ismételni abból, amit István mondott. Szirják Csaba, Chaar-Lee vagyok, ahogy mondtad te is, jelenleg a Foundationnél dolgozom. Múltamat tekintve szoftverfejlesztőként, mérnökként kezdtem. A mérnök szót egyébként én is nagyon fontosnak tartom a szakmában. Tehát nemcsak a kódolás, hanem sokkal inkább a tervezés és utána annak a megvalósítása. Én a kezdeti időszakban saját vállalkozások, cégek, sokszor szabadúszóként dolgoztam. Most már kicsit több mint 10 éve munkavállalóként jellemzően szoftvercsapatok fejlesztésével, építésével foglalkozom. Általában engineering szervezet teteje környékén szoktam lenni. Ami még jellemző rám, mindenevő vagyok, szinte minden szerepkörbe belekóstoltam. Ugyanúgy szerettem fejlesztőként CSS-t írni, mint adatbázist tervezni, ugyanúgy beleszólok productos területekbe, néha dolgoztam product ownerként. Nagyon szeretem az agilisból származó elveket, módszertanokat, azokból hogyan alakítsuk ki a dolgainkat. Néha nem is szeretnek emiatt, mert adott esetben túl sok mindenbe beleszólok.

Laczkó Gábor: – Nem tudom ti hogy vagytok vele, én már saját magam bőrén éreztem azt, hogy megtervezünk egy fejlesztési folyamatot, egy projektet, és aztán természetesen a jó része az új kihívások kapcsán nem úgy sikerül, ahogy az tervezve lett. Sokszor belefutottam abba én is, hogy esetleg határidőt átléptük, vagy funkcionális korlátok kapcsán merültek fel olyan tényezők, ami egy nem  várt esemény volt, és elmehet a projekt olyan irányba, amire azt mondhatjuk, hogy nem egy sikeres projekt. Ti hogy definiálnátok a sikeresség tényezőjét? Mikor lehet azt mondani, hogy sikeres egy folyamat vagy egy fejlesztés? Mikor lehet azt mondani, hogy ez egy bukott projekt?

Szirják Csaba: – A sikert úgy szoktam definiálni, hogy az a siker, ha a stakeholderek elégedettek. Nem is feltétlen az a legfontosabb, hogy az eredetileg leírt számok mentén menjünk, vagy kimutatható-e a haladás. Ez mind-mind óriási segítség, de a legvégén szinte csak az fontos, hogy aki a megrendelő, aki a stakeholder – és a projektek esetén azért mi jellemzően ilyenről beszélhetünk –, ő elégedett-e.

Novák István: – Ez egy nehéz kérdés, hogy mikor nevezhetünk sikeresnek egy projektet. Én általában azt szoktam mondani, hogy minden projektet két szemszögből is lehet nézni, nagyon fontosnak tartom amit elmondtál Chaar-Lee, hogy a stakeholdernek elégedettnek kell lenni. Ez egy szükséges feltétel, nálam viszont nem elégséges. Én azt szoktam mondani, hogy akkor sikeres a projekt, ha a stakeholderek mellett a megvalósító, a fejlesztő, a kivitelező, a termékfejlesztő csapat is úgy érzi, hogy elégedett. Vagyis azok a belső elvárások is teljesülnek, amelyekre ők úgy gondolják, hogy fontos. Most rengeteg ilyet mondhatnék, a kód minőségétől kezdve, a hogyan érezték magukat a projekten, vajon lesz-e jövőbeli folytatása a projektnek, megoldható-e ez technikai, technológiai szempontból, és így tovább. Nagyon sok ilyen dolog van. Én ezt is ebbe a sikeres vagy nemsikeres kategóriába sorolom.

Szirják Csaba: – Egyetértek veled. Ez is nagyon fontos.

Novák István: – Azért érdemes a dologról beszélni, mert néha előfordulnak olyan projektek is, amelyeket csak az egyik oldal tart sikeresnek, akár a stakeholderek, akár a megvalósító csapat. Sokkal problémásabbak azok, amelyeket csak a megvalósító csapat tart sikeresnek. Vannak olyanok is, amelyek egyik csapat számára sem sikerültek, majd ezekről is érdemes beszélnünk a mai nap folyamán.

Szirják Csaba: – Egyébként mi most pont egy ilyenben vagyunk benne, ahol nagyon erős a két oldal közötti megítélése annak, hogy amit csináltunk, az sikeres-e. Egy frissen épülő csapat, egy olyan szállítással, ahol nagyon rosszul definiált dolgok mellett szállítottunk, értéket teremtettünk. Azt gondoljuk, hogy itt a csapat úgy éli meg, hogy nagyon rövid idő alatt behúztuk a dolgokat, a másik oldal pedig úgy éli meg, hogy szerinte nem azt csináltuk meg, amire neki szüksége volt. Majd ezt fejtegethetjük, mert itt az elején azt sem tudtuk, hogy mi a stakeholder, már a -1. ponton elvérzett az egész történet. Ezért vagyunk itt, hogy ilyenekről beszéljünk.

Laczkó Gábor: – Mondtátok a sikerességnek a kulcsát. Mi a bukás? Mert igen, valami sikeres vagy kevésbé sikeres, de mi az, amikor azt mondjuk, hogy teljes káosz, csőd, elbukott az egész. Amikor mind a két oldal azt érzi, hogy ez tényleg el lett rontva.

Novák István: – A siker és a bukás skála, az nem egy bináris dolog, hogy vagy sikeres a projekt vagy nem. A két érték között nagyon sok dolog lehetséges és attól is függhet, hogy ki az, aki végzi. Régen, amikor még alapvetően tradicionális projektszemlélettel rendelkező cégeknél dolgoztam, az ottani érintettek, ottani projektvezetők általában úgy fogalmazták meg, hogy az a sikeres projekt, amit sikeresnek nyilvánítunk, és az a bukott projekt, amelyet bukottnak nyilvánítunk. Sajnos sok mindent nem mond ez igazából. Nálam ennél egy sokkal szelídebb skála van. A sikerességre én is azt mondom, hogy az a sikeres projekt, ahol a stakeholderek úgy gondolják, még inkább sikeres a projekt, ha a projektcsapat is úgy gondolja. A bukott projektnél nagyon sokfajta lehetőség van. Én általában az általad megfogalmazott nagyon-nagyon bukott projektnek azt tekintem, ahol a stakeholderek egyértelműen kinyilvánítják, hogy az az eredmény, amit kaptak, azzal nem elégedettek. Ezekben is láttam már olyan projektet, ahol nem egyszerű kinyilvánítás volt, hanem erőteljes jogi következmény is. Gyakorlatilag a szállító, szállított rengeteg pénzébe került, aminek nagy részét valószínűleg nem is fizették ki, és ezért sok-sok probléma volt. Vannak azok a típusú bukott projektek, ilyet is láttam, ahol a stakeholder elégedett, de valójában a projektüzlet megbukott, mert a szállítónak rengeteg pénzébe került és alapvetően veszteséget jelentett. Nyilván ilyenkor a veszteségben benne van az az ár, hogy egy jó image-et teremtett vagy tartott fenn magáról. Vannak azok a bukott projektek, amiket a stakeholder is elfogadott, még azt mondanám, hogy üzleti szempontból nyereséget is termel, viszont mindez olyan megközelítésmóddal járt együtt, hogy a megvalósító csapat alapvetően sikertelennek érezte, rosszabb esetben akár ki is égett, és igazából mindaz az érték, amit teremtett, az eltűnt, elpárolgott a projektből.

Szirják Csaba: – Nekem nagyon nehéz visszagondolni olyan projektre, amit nagyon bukottnak lehetne minősíteni, mert azt gondolom, hogy István is, én is egyfajta agilis környezetben dolgozunk, iterációban dolgozunk, részben pont azért, hogy a kockázatokat minimalizáljuk. Lehet, hogy az a vonat kisiklott többször, beszéltünk arról, hogy bukás volt, lehet, hogy elcsúszott a határidő, lehet, hogy elcsúsztak a költségek, a scope vagy a minőség. Viszont, ha folyamatosan változtatsz a terven, akkor minimalizálod ezeket a bukásokat. Ezért nem tudok olyat felidézni, hogy megrendeltek volna tőlünk egy projektet, 2 év múlva leszállítjuk, közben nem beszélgetünk semmit. Merthogy folyamatosan beszélgetünk. Ott lehetne egy óriási buktáról beszélni, hogy totál nem az készült el, mint amire számítottunk. Úgyhogy talán a mai világban ez kevésbé jellemző. Legalábbis azokban a környezetekben, ahol én dolgoztam, kevésbé jellemző. Én azt gondolom, hogy ezért is próbálják szervezetek az agilist behozni, magukévá tenni és tanulni belőle. Nekem ezek kéz a kézben járnak, tehát az agilis és tradicionális projektmenedzsment nem gondolom, hogy egymástól független vagy ellentétes dolgok. Csak az agilis kiáltványban ott van, hogy a tervektől való eltérés, ami azt jelenti, hogy vannak tervek, nem pedig azt, hogy nincsenek tervek. Az nem nevezhető szerintem agilisnak, ahol nem terveztünk. Én behoznám a projektháromszöget, ha projektekről, projektmenedzsmentről beszélünk. Legyen ez kitéve, mert sokszor erre hivatkozunk. A háromszög tetején ott van a scope, mi az, amit fejleszteni akarunk, van egy cost vagy budget csúcs, ami arról szól, hogy mennyibe fog kerülni tervek szerint ez az egész, és van egy schedule vagy time, hogy milyen határidőre fog leszállításra kerülni. Sokszor a háromszög közepébe beírjuk, hogy quality, tehát azzal még lehet játszani, hogy mi az a minőség. Bármelyik dimenziónál beszélhetünk bukásról szerintem. Ezek mentén tudjuk vizsgálni, hogy milyen szempontból sérült esetleg az, amit eredetileg terveztünk.

Novák István: – Egy kis kiegészítés ehhez, mert nagyon egyetértek ezzel a megközelítésmóddal. Az én tapasztalatom az szokott lenni, és gyakorlatilag minden megvalósító csapat tapasztalatában erről van szó, hogy amikor problémák kezdenek egy ilyen projektnél jelentkezni, akkor leggyakrabban azokat a problémákat hanyagoljuk, amik a qualityhez tartoznak ott középen. El szoktam mondani a legtöbb csapatnak, hogy alapvetően semmi baj nincsen azzal, hogy a minőség romlik vagy esik. Egészen addig nincs baj vele, amíg egy olyan pontot el nem érünk, ahol gyakorlatilag az érintettek, a stakeholderek nem fogják elfogadni annak a projektnek a termékét, amit készítünk, mert annyira esik a minőség. Ezek szoktak nehézséget jelenteni. Nagyon gyakran ezt a fontos összefüggést kevesen értik meg, érdemes erre is figyelni.

Laczkó Gábor: – Chaar-Lee, itt behoztad ezt a háromszöget. Van egy olyan nézete is, hogy a házon belüli fejlesztők, akik magas minőségre törekszenek, ők hogyan ítélik meg, amikor azt mondja az üzlet, hogy egyébként időben gyorsan kell ezért az oltáron feláldozni a minőséget. A fejlesztők pedig úgy élik meg, hogy ők nem egy szép kódot, szép rendszert írtak. Ilyen szempontból is lehet házon belül egy bukott rész, hogy hát jól sikerült a projekt, csak a srácok nem úgy ítélik meg, mert a quality nem olyan, amilyennek lennie kéne.

Szirják Csaba: – Itt behoznám egy kicsit az expectation managementet, nemcsak a stakeholder irányába, hanem a csapat irányába is. Én azt gondolom, hogy igenis vannak olyan projektek, amik alacsony minőségben is rendben vannak. Mondok egy-két példát. Amikor tipikusan pilotolunk valamit, és fontos, és azt mondjuk, hogy nekünk az idődimenzió a legfontosabb, hogy válaszokat kapjunk, hogy tervezni tudjunk. Volt egy időszak, amikor tv-ben dolgoztam, tv-műsorokat, vetélkedőket készítettem. Fura volt, hogy akik ebben már 10-20 éves tapasztalattal bírtak, azt mondták nekem, hogy figyelj, az a fontos, hogy az első forgatásnál működjön a kód, utána soha nem fogunk hozzányúlni, mert tv-s vetélkedőknél az a mondás, hogy működő dolgokhoz nem nyúlunk. Innentől kezdve egyrészt volt egy rapid fejlesztés, mert általában rövid határidőre kellett fejleszteni, és a helyszínen, a forgatásokon még egy csomószor módosítottam a kódot, és olyasmiket csináltam, amikre iszonyatosan nem vagyok büszke. Copy-paste-eltem kétképernyőnyi részeket és átírtam benne néhány karaktert, mert gyorsan kellett. Viszont a szoftver működött, és nem volt feladat, hogy azt utána maintaineljem, feature-öket fejlesszek bele. Elért egy állapotot, és itt elfogadható volt szerintem, hogy egy szutyok minőséget sikerült a végén leszállítani. Mégis mindenki elégedett volt vele. Sokszor hivatkozik a fejlesztő csapat, hogy minőséget akarunk csinálni. Ez jó, legyen ez egy alapelv, csak mindig vannak akadályozó körülmények. Projektje válogatja, az elején érdemes tisztázni, hogy most mire lövünk.

Novák István: – Teljesen egyetértek ezzel a dologgal. Az én tapasztalatom azt mutatja, hogy nagyon nehéz ilyen szempontból egy viszonylag agilis megközelítésmóddal, vagy akár tradicionális megközelítésmóddal kezdő termékfejlesztő minőségügyben dolgozni. A két szélsőség, ami szokott lenni, hogy nem is tudjuk mi az, hogy minőség, ezért folyamatosan gyártjuk a technikai adósságot, ez az egyik. A másik pedig az, amikor művészi szintre emeljük a minőséget, amikor a minőség céllá válik a projekt egyéb fontos céljai helyett. A minőséget le szoktam arra fordítani, hogy nézzük meg, hogy mennyi technikai, vagyis műszaki adósságot termelünk. A nagy kérdés az az, hogy az a műszaki adósság, amit termelünk, az lenullázható-e? Ha például Csaba tv-s projektjét előveszem, ez a „nem nyúlunk hozzá a kódhoz” azt jelenti, hogy a benne lévő műszaki adósságot lenullázhatók, nem kell vele foglalkoznunk, hiszen egyetlen egyszer használjuk fel őket. Ha ez a környezet áll, akkor a projekt sikeréhez nem feltétlen szükséges a minőség. Ha olyan valamiről van szó, ha olyan életű termékkel foglalkozunk, ahol a külső megrendelők számára a minőség nem annyira fontos, akkor lehet, hogy az első projektünk nagyon jól fog sikerülni, és mindenki rettentően örül. De az a típusú adósság, amit fölhalmoztunk, majd elő fog jönni egy következő projektfázis során, tehát nagyon-nagyon óvatosan kell ezzel a dologgal bánni.

Szirják Csaba: – István behozott egy szót, a terméket. Lehet, hogy kicsit körbejárhatnánk, product és project. Mert azt gondolom, hogy a kettő között óriási különbség van. Amikor a minőség kerül előtérbe, akkor én sokkal inkább a termékfejlesztésben hiszek, ahol nem kimondottan az a fontos, hogy adott határidőre adott scope-ot számítsunk, hanem hosszútávon gondolkodva egy jó minőségű terméket akarunk létrehozni. Én tipikusan akkor voltam projektekben, amikor egy külső megrendelőnek mi voltunk úgymond a bérfejlesztői, ahol neki a határidő volt fontos. Megmondta mennyi pénze van rá, innentől kezdve beégettünk dolgokat, és mindig a qualityn húztunk, amikor ilyen projekt van. De amikor termékfejlesztő szervezetben vagyok, akkor ott is csinálunk projekteket, de valójában azok egymásra épülő dolgok, sokkal rugalmasabban kezelhetők a határidő csúszások, hiszen nem kifelé, hanem magunk felé teszünk sok esetben vállalásokat, és ezt a fenntarthatóságot kell szerintem figyelembe venni.

Novák István: – Egy picit itt eltér az álláspontunk. Én a saját csapataimnál terméknek hívom az egyszerű szoftverfejlesztést is, aminek nem nagyon látjuk az életét. Egyszerűen azért, mert ennek a metaforának a segítségével tudom igazából jól megvilágítani a csapatok számára, hogy hogyan dolgozunk. Hozzáteszem, már elmondtad Chaar-Lee, nagyon fontos az expectation management. Valószínűleg teljesen más elvárásokat támasztunk egy ilyen értelemben egyszeri szoftverfejlesztésként, de terméknek tekintett projekt esetében, mint akkor, hogyha nekünk egy folyamatosan fejlődő, változó, a világ változásával valamilyen szempontból lépést tartó termékről beszélünk, amit akár egy adott projektcsapat, de lehet, hogy sok-sok egymás után következő kis projektiterációkban külön kibocsátásokkal ad át.

Laczkó Gábor: – Említetted Chaar-Lee, hogy most is valami olyasmibe futottatok bele, volt olyan témakör, hogy más volt az elvárás, más a nézőpont stakeholderi szinten. Ha egy kicsit elkezdjük boncolgatni, és a legelejére megyünk a folyamatoknak, akkor a szerepeknek a tisztázása, felállítása, illetve az, hogy üzletileg ki mit vár el egymástól, ennek a tisztázása egy kulcsmomentum tud lenni egy-egy jó projektél. Valószínűleg ez egy alapból kihagyhatatlan eleme kell, hogy legyen egy ilyen folyamatnak.

Szirják Csaba: – Igen, szerintem ez a stakeholderek beazonosítása úgymond kinél van a pénz, kinél van az igény. Az, hogy most projektről vagy termékről beszélünk, hogy a kettő között hol vannak a határok, hogy egy picit példákon keresztül tisztább legyen, nekünk volt egy jogi határidőnk, egy állambácsi által meghatározott időpont, amikorra valamivel el kellett készülni. Ez kőbe volt vésve. Egy nagy multiszervezet, amit mi csináltunk, projektként közelítették meg. Ellenben a mi csapatunk egy teljesen új bankot épít, mi termékszemlélettel álltunk hozzá, nekünk nem az volt a fontos, hogy tegyünk egy pipát az adott határidőnél, hogy ez megvan, hanem hogy mi erre építkezni fogunk, akár egy évtizeden át, és hogy más legyen a minőség. Amit mi sajnos elrontottunk, kicsit későn csöppentem bele a csapattal, már alapból egy olyan szituációban vettük át ezt a történetet, hogy az előre tervezett időnek eltelt a kétharmada, és még akkor kezdtük el kapirgálni, hogy mi is a feladat. Nem sikerült jól beazonosítani a stakeholdereket. Azt gondoltuk, hogy van egyfajta dokumentum, ami irányba rak bennünket, hogy mit is kell leszállítani. Konkrétan a leszállítás után úgy, hogy még csúsztunk is a határidővel néhány hetet, akkor kezdett el kiderülni, hogy ki is valójában a stakeholder, aki önmaga is csak akkor jött rá, hogy ezt az én embereim fogják használni, és hozzá kéne szólnom. Csak ott a rengeteg dolog miatt neki sem ez volt a prioritás. Azóta eltelt jó sok idő, és azóta is küzdünk igazándiból, hogy ki mitől is gondolja ezt jónak. Most tisztázzuk azokat a dolgokat, amiket pont egy éve kellett volna.

Laczkó Gábor: – Ezt hogy teszitek egyébként? Leültök beszélgetni? Vagy minél több megbeszélés van? Van valami technikátok rá?

Szirják Csaba: – Jelenleg rengeteg megbeszélésünk van. Van újabb jogi határidő, vannak projektkereten belüli megbeszélések, workshopokat tartunk, kiscsoportos megbeszéléseket tartunk. Ez egy sokszázmilliárdos történet amiben benne vagyunk. Itt még külső fejlesztőcsapatok is érintettek. Szerintem nagyjából 50 megbeszélésen vagyunk túl csak az idei évben. A stakeholderekkel én például úgy kezdtem, hogy akkor üljünk le egyet one-on-one jelleggel, egyáltalán ismerkedjünk meg. Most is itt ülök Békéscsabán, mert egyébként Pesten dolgozom, de Békéscsabán vannak olyan felhasználó csoportjaink, akiknek a vezetői itt ülnek, és fontosnak tartom, hogy személyesen találkozzunk, lássuk egymás arcát, fogjunk kezet, hogy amikor a későbbiekben egymással beszélgetni fogunk, ne mint két vadidegen álljunk egymással szembe. Valójában egy közös szekeret tolunk, nem egymás ellenségei vagyunk. Ezt nagyon nehéz megteremteni. Valakinél ez jobban megy, valakinél nehezebben. Ekkora méretnél beleszólnak belső politikai ügyek is abba, hogy mi hogy mehet. Ez egy komoly kihívás jelen pillanatban, hogy hogyan menedzseljük ezen dolgokat.

Laczkó Gábor: – István, mindig tőled idézem, hogy „egy projekt sikeressége 60 %-ban az input minőségétől függ”. Itt az inputnál nagyon fontos, hogy milyen a szakember, aki ott van, egy business analyst vagy egy product owner, aki az üzleti oldalt képviseli. Ez valóban így van? Ezt egy jópár éve beszéltük. Azóta támogatod, vagy azt mondod, hogy még jobban fontos, vagy kevésbé? Mi a meglátás?

Novák István: – Csak, hogy tisztázzuk, mi az az input. Az input mindazon információknak az összessége, amelyre szükség van a projektnek és a projekt környezetének is ahhoz, hogy esélye legyen sikeresen kifejleszteni a terméket, sikeresen végigvinni a projektet. A legnagyobb problémát az input kapcsán az szokta jelezni, hogy nem tudjuk igazából megítélni, hogy mikor megfelelő minőségű az input, alapvetően, hogy minden információ megvan-e ahhoz, amire szükségünk van. Én korábban 60 %-ot mondtam, de akár már 80 %-ot is mondhatnék. Ahogy az idő eltelt amióta erről legutoljára beszéltünk. Én mindig azt érzékelem, hogy azok a projektek, amelyek ilyen értelemben elbuknak, ott nagyon sérül az input helyessége, minősége. Csaba is erről beszélt. Azt szoktam általában mondani, hogy amikor egy ilyen értelemben nehéz projekten dolgozunk, vagyis utána kell járni kik a stakeholderek, mit akar a tisztelt megrendelő, mi a célja vele. Hiszen ez nem teljesen triviális. Ez attól, hogy egy törvényi határidő van és a törvényben le van írva valami, ettől még nem feltétlen lineárisan következik, hogy az adott projektnek mi a célja. Ott mindig érdemes azzal kezdeni, hogy ahelyett, hogy csapatot verbuválnánk és összegyűjtenénk egy hatalmas nagy – elnézést – kőműves brigádot, aki majd ezt a terepet fel fogja építeni, hogy az egész projekt, az egész termékfejlesztés megközelítésmódján érdemes úrrá lenni. Ha van egy megközelítésmódunk, akkor az sokkal nagyobb esélyt ad arra, hogy ez a projekt normálisan végigmenjen. Sokkal nagyobb az esély arra, hogy látjuk, mi az az input, amit össze kell gyűjteni és be kell szerezni. Ha ez a típusú dolog nincs, és nem tudunk egy jó megközelítésmódot kitalálni, akkor a projekt bajban van. Ez az a -1. lépés, ahol lehet, hogy megéri a projektnek ezen a ponton elbuknia. Én azt szoktam mondani, hogy nem feltétlenül baj, ha egy projekt elbukik. A projekt elbukása az nem feltétlenül jelenti azt, hogy nem fogjuk tudni elérni a projektnek a célját. Ez azt jelenti az én szótáramban, az én megközelítésmódomban, hogy az a típusú megközelítésmód, amit kiválasztottunk, arról kiderült, hogy megbuktatja a projektet. Ennek a segítségével nem lehet továbbhaladni. Nagyon sok csapatom, akik ilyen értelemben hamar elbuktak egy projektet, viszonylag kis részét élték fel a projekt költségvetésének, és az esetek egy nagyon jelentős részénél kellemes, pozitív következménye is volt a dolognak. A projekt ilyen gyors elbukásából megtanulták, hogy milyen megközelítésmódok nem használhatók, de ugyanakkor volt néhány ötletük arra, hogy hogyan lehet ezt a megközelítésmódot átalakítani azért, hogy sikeresek legyenek. Vagyis, egy ilyen projektbukás esetén, ha mondjuk a projektköltség 10 %-át felélték, akkor ennek a 10 %-nak a feléléséből tanultak valami olyasmit, hogy a maradék 90 %-ra még egy olyan megoldásmódot, megközelítésmódot rá tudtak húzni, amibe sokkal könnyebb lehet eljutni a projekt céljához. Az én tapasztalatom általában az a projektbukások kapcsán, hogy valójában azok a komoly projektbukások, ahol nagyon sok idő telik el mire kiderül, hogy zsákutcában vagyunk, nagyon rossz megközelítésmódot választottunk és nem tudunk visszafordulni. Chaar-Lee is egyébként erre utalt szerintem, amikor az előző projektpélda kapcsán említette, hogy már kétharmada eltelt az időnek, amikor ők elkezdték azt a megközelítésmódot használni, ami sikerre vezethet. Összegzésül válaszolva a kérdésedre, én úgy gondolom, hogy még inkább fontos lett ennek az inputnak a helyessége, azok a csapatok, amelyek törekednek arra, hogy ezt a fajta bukást elkerüljék, azok megpróbálnak sok időt eltölteni azzal, hogy ennek az inputnak a minőségén javítanak, és ezt nagyon gyakran a projekt megközelítésmódjával tudják megtenni.

Szirják Csaba: – Nagyon sokat bólogattam menet közben, egy-két dolgot szerintem ki is hangosítanék. A bukás, amiről most István beszélt, lehet, hogy kicsit átforgatnám abba, hogy önreflexió, és észrevettük igazából, hogy nem a megfelelő vágányon vagyunk és korrigálunk. Én nem feltétlenül szoktam ezt bukásnak hívni, de ezt a definíciót is teljesen el tudom fogadni, és nagyon is egyetértek vele, hogy ezzel foglalkozni kell egy csapatnak, fel kell ismerni minél hamarabb, hogy rossz irányban vagyunk, változtassunk, csináljuk másképp, hozzunk új koncepciókat, tanuljunk a múltbeli dolgokból. Elkanyarodtunk kicsit az agilis mindset irányába szerintem, ami pont ezeket emeli ki, hogy nem félünk a változástól, tanulunk a hibáinkból, és ilyen szempontból még ünnepelhetjük is, hogyha hibák vannak, és nem szabad tőle félni, mert rengeteget tudunk belőle tanulni.

Laczkó Gábor: – Nyilván a projektmegközelítés az egyik fontos eleme annak, hogy jól induljunk. Nálam mindig az jön fel, hogy a tapasztalt szakemberek, akik ott vannak egy projektkezdési résznél, rettentő fontosak. Sokszor mondják, hogy nem biztos, hogy olyan tapasztalt ember kell egy-egy projekthez, mert lehet, hogy egy mediorabb ember is elviszi. Nekem az a tapasztalatom, hogy azt tényleg meg kell nyomni. Amit mondtatok, hogy elbukik valaki, és azokon a bukásokon már túl van, nyilván még lesz neki jópár, de már túl van valamennyin, azt a tapasztaltot meg tudjuk spórolni, ami nála megvan. Én ezt nagyon fontos pontnak érezném, hogy nyilván egy jó szemléletmóddal induljunk el. A másik pedig az, hogy tapasztalt jó szakemberek legyenek azok, akik a tervezési vagy a kezdeti fázisokban ott vannak. Ezeket már könnyebben meg tudják ugrani, mint ha valaki a mélyvízbe esik bele.

Szirják Csaba: – Én is azt gondolom, hogy a tervezésen múlik sok minden. István is a mérnök szót használta az elején, én is a mérnök szót használtam az elején. Szerintem a jó tervek egyik alapja annak, hogy siker legyen, valamint a megvalósító csapat. Nem feltétlen azon kell, hogy legyen a hangsúly, hogy szuper senior szakemberek, akik úgy bevágják a kódot mint a csuda. Sokkal fontosabb, hogy megértsük mi az, ami a probléma, ki tudjuk találni mi rá a megoldás üzletileg, vagy product szempontból mik azok a feature-ök, amikkel meg akarjuk ezt oldani. Fontos utána a technológia része, milyen architechtúrát tervezünk, milyen technológiákat használunk, hogy érnek össze ezek a dolgok. Bejön még a design része, a tesztelés része, ezek mind-mind a tervezéshez kötődő elemek. Szerintem ezt az elején el kell végezni a projekt, termék jellegéből fakadóan különböző mélységekben. Utána menet közben iterációról iterációra, kisebb lépésekben, de a tervezéssel foglalkozni kell. Kihagytam a becslés részét, ugye, hogy az egész projektben mennyi a költség, mi a határidő, az valójában abból származik, és hogy megértettük mit dolgozunk. A becslések révén pedig meg tudjuk jósolni, hogy mennyibe fog kerülni, kapacitástervezéssel pedig ki tudjuk számolni, hogy mikorra érhetünk oda. Feltárhatjuk még a függőségeket, szűk keresztmetszeteket. Ez mind-mind tervezés. Ha ezeket elrontjuk vagy elhanyagoljuk, szinte garantált a bukás.

Novák István: – Teljesen egyetértek ezzel. Van egy olyan kifejezés, amit a szakmában használnak, hogy „this code smells”, vagyis, ez a kód bűzlik. Én nagyon-nagyon szeretem ezt a „bűzlik” kifejezést, mégha nagyon csúnyán hangzik is projektekre. Vannak olyan jellegzetes dolgok, aminél ha az ember odakerül egy projektre, akkor érzi, hogy bűzlik. Ha finomabban fogalmazok, akkor úgy fogalmaznék, hogy az ember fejében ilyen szirénák elkezdenek megszólalni. Elég sokat beszéltünk ennek a mérnöki oldaláról, viszont van egy nagyon fontos oldal, amivel én egyre gyakrabban találkozom. Valószínűleg ez azért van, mert egyre gyorsabb változásaink vannak, egyre inkább pörög az élet, a gazdasági, politikai környezet sem feltétlen annyira stabil, mint korábban volt. Ezt a faktort én egyfajta kultúrális közegnek vagy céges kultúrához közel álló dolognak érzem, ami egyébként megjelenhet a megrendelők és a beszállítók oldalán egyaránt. Úgy gondolom, hogy egy agilis értelemben jó projektet nem lehet úgy vinni, hogy ha két nagyon fontos dolog nincs jelen. Az egyiket úgy hívom, hogy őszinteség, a másikat úgy, hogy nyitottság. Az őszinteség nálam azt jelenti, hogy mindkét fél egy ilyen kapcsolatban, a megrendelő is és a beszállító is, nyitott kártyákkal játszik abban az értelemben, hogy minden fontos dolgot átad a másik félnek. A megrendelő tisztázza, hogy mik az üzleti célok, akár beleértve azokat a kicsit politikai célokat is, azokat a dolgokat, amiket nem lehet feltétlenül nagyon tisztán elmondani, de legalább virágnyelven lehet utalni rá. A célokat mindenféleképpen tisztává teszi. A beszállító oldaláról ugyanígy az őszinteségnek a része, hogyha elmondja azokat a potenciális problémákat, amik őt esetlegesen akadályozhatják. Akár azt is, hogy én nem fogom tudni olyan gyorsan összeszedni a csapatot, ahogy te szeretnéd kedves megrendelő. Nem is biztos egyébként, hogy szükség van rá. Ez az egyik típusú dolog. Mindkét félnek ezt a fajta őszinteséget biztosítania kell. Nagyon fontos egy ilyen környezetben, hogyha a megrendelő oldaláról csak vélt projektkeretek vannak mind határidőben, mind büdzsében, vagy bármely olyan egyéb dologban, ami befolyásolja ezt a dolgot, azt megosztani a beszállítóval. A másik ilyen típusú dolog, amiről beszéltem az őszinteség mellett, ez a nyitottság. A nyitottság mind a két fél részéről azt jelenti, hogy én nem csak meg akarom érteni a célokat, hanem, ha megértettem ezeket, akkor pozitívan és rugalmasan próbálok ehhez a dologhoz hozzáállni, azért, hogy a közös sikerünket segítsem. Mit jelent ez a megrendelő oldaláról? A megrendelőnek célszerű nyitottnak lenni arra, ha a beszállító javasol neki olyan megvalósítási alternatívákat, amivel ezek a célok esetleg könnyebben, jobban vagy kockázatmentesen elérhetők, akkor figyelni rá. A beszállító oldaláról ez a fajta nyitottság azt jelenti, hogy nyitva tartja saját magát, például, ha nem annyira fontos a minőség az adott projekten, mint amennyire a beszállító saját csapata véli, akkor megpróbálják ezt a fajta meccset lejátszani és ezt tisztázni. Ott, ahol ez a két dolog rendben van, ott nagyobb valószínűséggel tud ez a projekt továbbhaladni, mint ott, ahol nincs. Ahol ezek hiányoznak, az én eddigi tapasztalatom alapján ott gyakorlatilag a -1., 0. lépésnél valahol a projektnek az el nem ismert, szőnyeg alá söpört bukása az szinte biztos.

Szirják Csaba: – Nagyon egyetértek a dolgokkal. Én talán bizalomnak és rugalmasságnak hívnám ezt a kettőt. Mind a kettőben azt emelném ki, hogy mind a két fél részéről, hogy ezeket eléggé nehéz egyébként ilyen hozzáállással kezelni. Hiszen amikor őszinték vagyunk egymással, kitárjuk magunkat és kitesszük a lapjainkat, nem fogsz ezzel visszaélni, nem fogod ezt kihasználni. Nem ilyen az emberi alapbeállítottság. Ehhez azért kell egy szint, hogy bizalmat tudjunk egymás iránt szavazni. Ezért nagyon fontos szerintem dolgozni is azon, mondjuk beszállítóként, vagy mind a két irányból, de főleg mivel a stakeholdereknél van úgymond a pénz, a másik oldalnak itt sokkal inkább építenie kell és törekednie arra, hogy bizalmat tudjon kiépíteni. A rugalmasságnál pedig az a kedvencem, amikor a fejlesztőcsapatok azt mondják, hogy mi csak agilisan szeretünk dolgozni, így vagyunk agilisak, úgy vagyunk agilisak. És amikor a megrendelői oldalról jön a változás, hogy ő mást szeretne, akkor azt mondjuk, hogy hát hülye ez? „Minden ügyfél hülye” – van egy ilyen szólás is. Miközben pedig csak nyitottan, rugalmasan kellene hozzáállni, meg kellene érteni, hogy ahova eljutottunk, ahogyan változott a környezet, egyszerűen azt kívánja meg, hogy itt változtassunk. Nekünk is igazából örülni kellene, csak megint itt az emberi természet. Nem arra vagyunk programozva. A stabilitást jobban szeretjük, mint azt, hogy változik körülöttünk minden.

Laczkó Gábor: – Beszéltünk nagyon sok mindenről, ami a kezdeti fázisokhoz tartozik. Alapvetően, ha például egy ember beteg, és itt fáj, ott fáj, amott fáj, jönnek a különböző tünetek, valami arra mutat, hogy betegséggel küzdünk. Egy fejlesztési folyamatban, egy projektben milyen olyan tünetek vannak, amiket ha érzünk, akkor ott valami probléma lesz. Egy tapasztalt szem felismeri. Milyen tüneteket tudnátok mondani?

Szirják Csaba: – Utalnék Istvánnak a code smell kifejezésére, én is szeretem ezt használni. Vagyis, hogy hol bűzlik a projekt. Ha visszamegyünk a projektháromszöghöz, én sok csapatnál azt kértem, hogy CPI-t és SPI-t mérjünk. Ez a Cost Performance Index és a Schedule Performance Index. Magyarán hogy állunk a tervezett költségekhez képest, és hogy állunk a tervezett ütemezéshez képest. Ez vizuálisan jobban elképzelhető egy burnup vagy egy burndown churton, valójában a sprintek is, amikor berajzoljuk, erről szólnak. Csak egy sprint az nem feltétlenül mutatja meg egy teljes projektben, hogy hogyan állunk. Szeretem ezt kialakítani. Mert hogyha ez a két mérőszám nem mérhető, akkor önmagában már egy smell van, ugyanis ha nem került meghatározásra a scope, akkor nem tudtam becsléseket leadni, mert nem tudom, hogy lehetne ezt mérni, és nem tudom hol kellene tartanom. Amit szoktam még mérni, az a progress, ami a teljes projektre vonatkozzon. Nekem ezek szoktak segítségek lenni. Ezekből nekem következik. Hogyha ez nem mérhető, akkor valahol bűzlik a projekt.

Novák István: – Teljesen egyetértek. Nagyon sok olyan pici, apró dolgot tudunk mérni. Akkor jó egyébként, ha kevés ilyen dolog mérésére van szükségünk, hogy valamifajta módon meg tudjuk mutatni, hogy hogy halad a projekt. Ez mindig fontos. Gyakran látok projekteken olyan jellegű problémát – és ezek mind abba az irányba vezetnek –, hogy valami nagyon nincs rendben a projekttel. Az egyik ilyen, hogy későn jutunk el egy projekt során odáig, hogy bármit tudjunk mérni. Akár ezt a két számot, amit Chaar-Lee említett. De bármi olyasmit, ami akár valójában méri a teljesítményünket, a projekt előre haladását. Rengeteg sok projektnél nagyon későn alakulnak ki ezek a dolgok. Van sok-sok olyan pici, apró jel, amit én intő dolognak szoktam tekinteni. Egyik kedvencem, ami mindenképpen egy intő jel, amikor azt látom, hogy indul egy projekt, még sehol nem járunk, csak az input beszerzése körül. Tehát még éppen beszélgetünk kéne arról, hogy egyáltalán mi a megközelítésmód, mit fogunk csinálni, és már összeállt a hatalmas projektcsapat. Már összeálltak, ott van a szoba, ahol le tudnak ülni, hogy nekik valamit csinálni kell és ott az a 8-10 ember, azonnal elkezdenek dolgozni. Kódolnak, dokumentálnak, specifikációt írnak. Áltevékenységet folytatnak, amiből úgy látszik, hogy összeállt a projektcsapat és hogy dolgozunk a projekten, az teljesen mindegy. Ezt mindig egy intő jelnek tekintem. Sokkal egészségesebb jelnek, projektindulásnak látom azt, hogyha mondjuk a projekt a méreténél fogva akkora, hogy mérnöki hasra csapással azt becsüljük, hogy nagyjából 8-10 embernek kell ezen dolgoznia, hiszen annyi értelmes hozzáférési pont van. Ha ezek a projektek úgy indulnak, hogy az elején 2 vagy 3 embert látok csak ott, akik azzal vannak elfoglalva, hogy ezt az inputot ezt valahogy minősítsék, begyűjtsék, akkor kicsit egészségesebbnek látom ezt a dolgot. Nekem a legtöbb intő jel mindig a projekt indulása környékén mutatkozik. Természetesen később is vannak intő jelek, Chaar-Lee, akár elő is hozhatunk néhány ilyen dolgot felváltva, amit látunk. Nagyon komoly intő jel szokott lenni az, amikor hirtelen elkezdjük azt tapasztalni, hogy sok változás van a projekten. Olyan értelemben, hogy megbeszélünk valamit, és ezek a változások pár napon belül bekövetkeznek. Tehát kvázi ledefiniálunk egy sprintet, ledefiniálunk egy következő szakaszt, elgondolkodunk azon, hogy mit kell csinálni, de gyakorlatilag ezeken állandóan változtatunk. Ez azért intő jel, mert ez azt jelenti, hogy bár mint agilis csapat, alapvetően támogatjuk a változtatásokat, a változásokat. Ilyen környezetben élünk, de azért az állandó változtatások inkább káoszt jelentenek, tehát ez is mindig egy óvatos dolog, ami bennem megerősíti azt, hogy valami nincs átgondolva, megtervezve ezen az adott projekten.

Szirják Csaba: – Az előbb mondtál egy olyan szituációt, amit én is nagyon sokszor átéltem. Csapdahelyzetet is vélek benne felismerni. Hogyha az elején tényleg ott a csapat, és még tervezni kellene, érzünk egy olyan kényszert, hogy munkát kell adni a fejlesztőknek. Pont a tervezéstől vesszük el az időt, annak érdekében, hogy meglegyen az érzet, hogy dolgozunk. De ezzel közben meg a tervezés nem halad, így a hosszútávú munka is sérülni fog. Erre tényleg oda kell figyelni. Ráadásul nem fekete-fehér az élet, nem az van, hogy vannak a zérópontok és akkor most kezdődik a projekt, és itt ér véget, majd ezt követően jön a következő, hanem egymásra csúsznak dolgok, egymásra indítunk projekteket. Attól függ megint, hogy milyen szervezetben dolgozunk. Lehet, hogy mozgatni kell kapacitásokat egyik projektről a másikra, ezeket kisimítani, jól odafigyelni és ezt jól betartani, az egy komoly nehézség. De amiket mondtál smelleket, azokkal nagyon egyet tudok érteni. Az, hogy a projektet mérhetővé tegyük, hogy haladást mérjünk, hogy legalább színezzük ezekkel a piros-sárga-zöld dolgokkal, hogy projektet státuszoltassunk, azért el szokott mindenki idáig jutni. Én azt szoktam rossz jelnek tekinteni még, hogyha ez a haladás, ez hasraütésszerűen van megállapítva. Azt szoktam kérni a csapattól, hogy csak abban a progress százalékban hiszek, amit gép dob ki. Tehát ami ticketinget vagy bármi egyebet használunk, abból kell származzon ez az érték, mert minden más igazából nem oké. Itt visszautalok arra, hogy ha ezt meg tudjuk csinálni egy ticketingbe, akkor az azt jelenti, hogy le van bontva megfelelő mélységekbe vagy különböző időszakokra különböző szinteken az elvégzendő feladat, meg van becsülve, menedzselve van, hogy amivel készen vagyunk, az ott van a kész állapotban. Ha innen származik a végén egy százalék, akkor vagyok én oké. Ha másképp származik, akkor szinte biztos, hogy bűzlik. Akkor jön a vicc, hogy milyen színű a projekt? Görögdinnye. Kívül zöld, belül piros.

Novák István: – Teljesen egyetértek ebben a dologban. Függetlenül attól, hogy agilis vagy nem agilis megközelítésmódról beszélünk. Az agilis szoftverfejlesztés hetedik alapelve rettentő fontos. Azt mondja, hogy az előre haladás egyetlen valódi mércéje a működő szoftver. Azért tartom jónak ezt a dolgot, ahogy te is mondtad, amit a gép ad ki, az valószínűleg közelebb áll ahhoz a dologhoz, de még mindig benne van a tévedés lehetősége. Az én tapasztalatom az szokott lenni, hogy ez a típusú megközelítésmód nagyon jól kezd működni attól a pillanattól kezdve, ahogy a csapat az előtte álló megvalósítandó feladatokat, sztorikat, bármi legyen, kézzel fogható kellően kisméretű dolgokra bontja le. A saját tapasztalatom azt mutatja, hogy ott ahol ezek a feladatok – vagy sztorik, attól függ milyen megközelítésmódot használok – olyan szintig le vannak bontva, hogy 2-3 embernapál nagyobb munkadarabok nem léteznek ott nagyon jól tud működni ez a megközelítésmód, és egyszerűen, mert minden munkadarabnak csak bináris állapota van, készen van vagy nincsen kész. Ott, ahol elkezdjük a feladatokat aszerint súlyozni, hogy egy már 90 %-ig kész van, az mindig egy veszélyes 10 %. A 90 %-os készültség az lehet az, hogy az idő 90 %-át felhasználtuk. Ahol a munkadarabokat nem binárisan tudjuk mérni, és az összteljesítés százalék az nem abból származik, hogy hány munkadarabunk van kész az elkészítendők során, ott ez a dolog nagyon-nagyon félre tud bennünket vinni. Ott, ahol ezek a munkadarabok sokkal nagyobbak, ott azt tapasztaltam, hogy ez a típusú mérési módszert nem tud jól működni a csapatoknál. Minden áron, minden módon visszasírják ezt a feladaton belüli százalékos dolgot, és onnantól kezdve ez a dolog, amit említettél Chaar-Lee, hogy a gép kihozza a számot, ez nagyon félrevisz a valóságtól.

Szirják Csaba: – Igen. Én ide is bedobnék egy saját tapasztalatot, amikor először ezt átéltem, ott userstorynak hívtuk ezeket a munkadarabokat, ott én voltam a PO, többszáz ilyet megírtam, projekt harmadánál, negyedénél tartottunk, amikor éreztem, hogy amit megírtam userstory, a hátsó száz az mind kuka. Másképp haladunk, teljesen felesleges volt ilyen szintig lebontani, ebbe sokan beleesnek, csapdaként. Azt gondolják, hogy amikor tervezést mondok, vagy azt mondom, hogy meg kell terveznem a projektet, akkor lebontják az utolsó elemet is erre az utolsó munkadarab szintig. Ez egy háromszög jellegű történet. Minél közelebb van valami, annál inkább igaz rá, hogy ezekre a pici végső méretekre kell szétbontani, és minél távolabb van, annál inkább lehet nagyobb, de ettől még ezek a különböző szintek. Én egyébként az epic-feature- userstory-task négyest szeretem használni. Meg vannak becsülve, és amikor jobban szétbontom, tisztább lesz az adott elemnek a becslése is, de ettől még nagyon szépen mérhető egy progress, hogy nem minden van az utolsó szögig lebontva. Viszont hogyha van egy szakasz, amit végig sem gondoltam, egyszerűen nem tudjuk, hogy hol a projekt vége, mennyi van belőle hátra. Ezért nem szeretem én csak a sprinteket mérni. Lehet ezt is, csak akkor nem projektről beszélünk, hanem valami másról.

Novák István: – A sprintek mérése fontos lehet, de önmagában – ahogy te is mondtad –meglehetősen félrevezető információt tud adni. Azt fogja tudni megmutatni, hogy a terméket megvalósító csapat a saját bevállalásaihoz képest milyen mértékben halad. Sajnos nincs semmilyen biztosíték arra, hogy ez a mérés ez korrelációban van azzal a dologgal, amit a másik oldal, a stakeholder oldal elvár. Ezt nagyon óvatosan kell csinálni. Alapvetően félrevezető információt is adhat. Szerintem a nehézséget valójában pont az jelenti, hogy nehéz összekapcsolni azt a típusú dolgot, hogy van egy jól mérhető előrehaladás, amit a megvalósítócsapat végez, és a másik oldalon pedig valamifajta értékteremtést vár el a stakeholder. Ezek eléggé eltérhetnek egymástól. Megmondom nektek őszintén, nem sikerült még igazából nagyon jó, nagyon kifinomult, egyszerűen használható dolgot találni erre a kettőre. Az egyetlen dolog, amivel találkoztam és működni tud, az, hogy megfelelő kommunikációt választ ez a két oldal. Ott ahol ezt sikerült a csapatokkal végrehajtani, ott nagyjából az volt a megegyezés, hogy a csapat 4-6 hetente egyfajta demót tart a stakeholdereknek, és semmi mást nem csinálunk, mint hogy megpróbáljuk a következő ilyen demót 4-6 hétre előrevetíteni. Néha ez igazán jól sikerül, néha meg rettentően rosszul sikerül abból a szempontból, hogy 4-6 hét alatt az ember rájön, hogy amiről azt gondolta korábban, hogy értéket teremt, azzal valójában nem teremt akkora értéket, mint egy másikfajta módon. Ha a stakeholder nyitott erre a fajta megoldásra, akkor ez működni tud. Egy dolgot viszont az összes ilyen típusú demós megközelítés nagyon-nagyon sok esetben segíteni tud. Ez pedig az, hogy mind a két fél számára teljesen nyilvánvaló legyen, hogy valamilyen értelemben jó vagy rossz irányba haladnak. Legtöbb nehézséget az okozza egy beszállító csapat számára, és gyakran a stakeholderek számára is, hogy meglehetősen nehezen tudjuk meghatározni, hogy mi az, ami elkészült, mi az, ami készen van. Ezen nem sokat segít önmagában, hogy egyfajta agilis szemlélettel definition of done-t készítünk, mert attól, hogy adminisztratív módon ki tudunk pipálni dolgokat, a csapat meg tudja mutatni, hogy elkészült azokkal a sztorikkal, azokkal a feladatokkal, taskokkal, epicekkel, bármivel ami előtte van, ebből nem feltétlen következik, hogy a stakeholder is elégedett lesz.

Szirják Csaba: – Én itt a demóra fűznék rá egy picit, annak a fontosságára, és amikor mondtad, hogy a működő szoftver az elsődleges, és lehet, hogy egy jobb mércéje egy százalékos mutatónak is. Az egyik olyan projekt, amit én sikerként tartok számon, az szerintem pont azért tudott sikeres lenni, mert az elején lebeszéltük a megrendelővel, hogy kéthetente meg fogunk jelenni, kéthetente meg fogjuk mutatni, hogy hol tartunk, biztosítjuk a lehetőséget, hogy ott még beleötletelhetsz. Az elején teljesen el volt ettől zárkózva. Amikor azt mondtuk, hogy oké, tudjuk, hogy neked van egy kereted, tudjuk, hogy van egy határidőd, azt javasoljuk, hogy tegyél bele change request keretet, és a teljes büdzsé 20 %-át allokáld erre, hogy change requestek lesznek. Hát, hogy néz ez ki, hogy ő nem tudja megmondani, hogy mit akar? És fizessen ki valami jövőbeni valamire 20 %-ot? De aztán belement nagy nehezen. Amikor megjelentünk és demóztunk, azonnal elkezdett ötletelni, nagyon hamar rájött, és a projekt felénél azt mondta, hogy ő kér még ugyanennyi change request keretet, mert látja, hogy erre szükség lesz. A demókat úgy tartottuk, hogy én voltam a PO, a csapat demózott nekem egy héttel korábban, és utána én egy hét csúszással vittem ki az ügyfélhez, és mutattam meg. Szeretem belekényszeríteni a PO-t, magamat is belekényszerítettem, hogy tudjon demózni a PO, mert a működő szoftver akkor működő, ha nem deaf környezetben működik, hanem a kiélesített környezetben, ahol egy PO is képes ezt megmutatni. Ráadásul én vittem ki fejlesztőket is ezekre a demókra, kicsit szokták a légkört, hogy egy stakeholder menedzsment hogy néz ki, első kézből érezzék, hogy mikor teremtettünk értéket. Igen motiválóan tud hatni, amikor azt érezzük, hogy valaki másnak jót csináltunk. Ezért akartam a demóról beszélgetni, hogy szerintem ezek nagyon jó eszközök.

Laczkó Gábor: – Lassan a beszélgetésünk vége felé közeledünk, nálam még két olyan dolog van, amit szeretnék veletek megbeszélni. Az egyik az, hogy az ügyfél elégedetlen. Lemegy a csapat szintjére az elégedetlenség? Vagy azt mondjuk, hogy megáll egy bizonyos szinten, és a fejlesztőkhöz már nem viszem le, vagy valahogy máshogy viszem le? Sokszor van az, hogy azt hallani, hogy bestresszelnek, és ha nyomás van rajtuk, nem tudnak úgy haladni. Hagyjuk a fejlesztőket ki ebből? Mi a meglátásotok? Mi a jó személéletmód egy ilyen helyzetben?

Szirják Csaba: – Nekem az esernyő szó jutott eszembe, az elmúlt időszakban több kollégától kaptam meg, hogy esernyő. Valójában nem ez a szó a legjobb szinonima itt, mert az azt jelenti, hogy felfogok mindent és ők nem kapnak belőle semmit. Én azt gondolom, hogy igenis kell kapjon a fejlesztő is belőle. Inkább a szűrés az, ami nagyon fontos. Szerintem az nem transzparens, nem egy nyílt működés, hogy egy réteg elnyeli ezt a cunamit. Kell belőle lentebb is, de nem engedhetünk át mindent, mert tényleg túl lesz stresszelve. De úgy ahogy a sikert, úgy a rossz dolgokat is meg kell osztani. Szerintem egy vezető a product owner, a menedzser és a csapat közötti bizalmat is tudja építeni, ha jól kezeljük és kommunikáljuk. Röviden összefoglalva, szerintem kell, hogy kapjon belőle a csapat, de mindenképpen szűrni kell az információt. Ez nemcsak a kudarcra és a rossz dolgokra, hanem mindenre vonatkozik szerintem.

Novák István: – Egyetértek Chaar-Lee-val. Az én észrevételem az, hogy amikor szóba kerül az a dolog, hogy az ügyfél elégedetlenségét átengedjük-e a megvalósító csapathoz, általában az azt jelenti, hogy nem egyszerűen arról van szó, hogy valami pici, apró probléma van, ami az ügyfélnek nem tetszik, hanem tipikusan ez a helyzet azt szokta jelenteni, hogy hosszabb időszak óta az ügyfél folyamatosan elégedetlenkedik, vagy akár ennek az elégedetlenségnek a szintje is folyamatosan növekszik. Igen gyakran abban látom a problémát, hogy nem vesszük ezt időben észre. Általában az a tapasztalatom, hogy ezt a típusú elégedetlenséget egy ideig felfogja esernyővel az a személy, legyen az a projektmenedzser, a product owner, adott esetben akár a scrum master, hogy ne jusson el a csapathoz, de valójában ezzel nagyon komoly problémát követnek el, mert egyszer csak azt az esernyőt valaki be fogja csukni, és onnantól kezdve a teljes eső a csapatra esik rá. Hamar érdemes ezekre felfigyelni. Megtudni, hogy mi az elégedetlenség oka. Ezt érdemes a csapattal is kommunikálni. Ez lehet az emberek munkájával való elégedetlenség. Lehet a jogi környezettel való elégedetlenség. Ez lehet bármi, hogy például az ügyfél bal lábbal kelt fel. Ténylegesen találkoztam ilyennel, amikor ilyen típusú dolog volt. Folyamatosan elfedni az nem megfelelő és nem jó dolog. A legfontosabb az, hogy idejében el kell ezt kapni. Ha odáig járunk, hogy a csapatra ez lehullik, az azt jelenti, hogy ott már általában nagyobb problémák vannak.

Laczkó Gábor: – Amit zárásként kérnék tőletek az az, ha bukott projektet el szeretnénk kerülni, jó irányba szeretnénk menni, és mondjuk a három legfontosabb tényezőt kéne kiválasztanotok, hogy mit javasolnátok, hogy mire figyeljünk nagyon egy ilyen folyamatban, akkor mi lenne az a három dolog, amit megemlítenétek?

Novák István: – Ha három dolgot kellene megemlítenem, akkor az első az az volna, hogy nézd meg, hogy képes leszel-e az adott ügyféllel az adott projekten együtt dolgozni. Nem sok komoly tartalékot tudok abban az értelemben adni egyik csapatnak sem, hogy hogyan lehet ezt megcsinálni. Inkább azt mondanám, hogyha az ügyféllel való beszélgetés néhány dialógus után azt a dolgot sugallja, hogy ezt én nagyon nehezen tudom elképzelni, hogy ezzel az adott ügyféllel vagy megrendelővel én meg fogom tudni értetni magam, egyáltalán, hogy ugyanarról a dologról beszélünk, akkor ez egy intő jel, hogy dolgozni kell érte. Ez az első dolog. A másik, amit szoktam mondani, hogy nézd meg, hogy tényleg a legfontosabb inputod megvan-e ahhoz, ami ahhoz kell, hogy ezt a projektet vagy ezt a termékfejlesztést elindítsd. Alapvetően ne abból indulj ki, hogy mi az ami megvan, hanem hogy mi az, amiről úgy érzed, hogy hiányzik. Ha fajsúlyos dolgokat találsz, amik a te szempontodból hiányt jelentenek, akkor próbáld meg őket tisztázni, mielőtt ebbe a típusú projektbe belemész. A harmadik dolog pedig, azt szoktam mondani, hogy mindaz a dolog, mindaz, amit összegyűjtöttél információt az ügyfélről az input kapcsán, ismered a saját csapatodat, csapataidat, hogyha ezek alapján a fejedben kibontakozik egy vagy akár több olyan megközelítésmód, amivel el tudsz indulni, akkor érdemes belekezdeni. Ha viszont teljes bizonytalanság van a fejedben, és úgy gondolod, hogy majd helyetted ezt a csapatok ki fogják találni, akkor bajban vagy.

Szirják Csaba: – Beszéltünk mindegyik dologról, ami nekem most eszembe jut és három. Először röviden mondanám. Stakeholder első helyen, tervezés második helyen, mérhetőség harmadik helyen. Kicsit kifejtve újra, tudd, hogy kik a stakeholderek. Nem azonosítottad be, akkor a tervezésed nem lehet teljes. Hiába tudsz minden mérni, nem lesz sikeres. Nagyon fontos, hogy kik is igazándiból akik az igényeket megfogalmazzák, és akiket elégedetté szeretnél tenni a szállításoddal. A tervezéshez a megfelelő szakmai embereknek, mérnököknek a közössége, akik tervezni tudnak, föl tudják mérni, hogy mi a scope, hogyan szeretnénk erre megoldást adni, és hogyan lehet ezt egy megvalósítható tervvé fordítani, becsléseket összerakni. Ha elvéted és rosszul határozod meg, rosszul becsled meg a költségeket, megint hiába jó a megvalósítás, félre fog menni a történet. Ez van a második helyen. A harmadik pedig a mérhetőség. Én akkor tudok menedzselni valamit, hogyha azt érzem, hogy fogom a kormányt. Ha olyan műszerfalam van, amiről le tudom olvasni, hogy hogyan állunk. Ha csak így érzéseim vannak, akkor nem tudom autóvezetés közben, hogy 50-nel megy, 100-zal megy. Érezhetek valamit. De ha tudom pontosan, hogy mit mutat a mutató és hogy áll a tank, és tudom, hogyha mozdítom a kormányt és arra fogunk haladni, amerre én szeretném, akkor tudom ezt menedzselni. Szerintem erről szól a projektmenedzsment, erről szólnak a mérhetőségek, hogy olyan kevés, de jó inputot kapok, hogy én tudjam, hogy merre kell most fordítani és jól állunk vagy nem jól állunk. Én ezt a hármat emelném így ki.

Laczkó Gábor: – Köszönöm szépen. Úgy gondolom egész jól körbejártuk a témát, egészen a tervezési fázisoktól kezdve a szerepeken át. Adtunk egy olyan látképet, hogy miket érdemes figyelembe venni egy-egy ilyen folyamat során, hogy tényleg elkerüljük akármilyen oldalról is, ne egy bukott projektnek a szereplői legyünk. Nagyon szépen köszönöm Chaar-Lee és István nektek, hogy itt voltatok, és megosztottátok a gondolataitokat. Kívánok mindenkinek sikeres projekteket. Nagyon remélem, hogy a közeljövőben ugyanígy, akár egy más témával tudjuk majd folytatni, mert úgy gondolom, hogy rengeteg minden van még, amiről lehetne beszélni. Nagyon szépen köszönöm nektek, hogy itt voltatok!

Szirják Csaba: – Köszönjük szépen a meghívást! Én nagyon élveztem egyébként ezt a szakmai beszélgetést. Köszi nektek!

Laczkó Gábor: – Mi is, nagyon szépen köszönjük. Sziasztok!

Novák István: – Köszi, további szép napot! Sziasztok!

Szirják Csaba: – Sziasztok!