Ocskay Lászlóval az OANDER Development Kft. ügyvezetőjével az informatikai cégekkel folytatott kommunikációról beszélgettünk, pontosabban a fejlesztési projektekről és az ezek sikerességéhez szükséges kommunikáció mibenlétéről. Mire fontos odafigyelnünk, ha belevágunk egy fejlesztési projektbe, legyen az kisebb vagy nagyobb? És mit jelent az, hogy 100 óra fejlesztési időre 100 óra ügyfélidő kell jusson?
A kommunikációnk minőségén és milyenségén mindig jóval több áll vagy bukik, mint azt esetleg tudatosítanánk, mielőtt belevágunk egy tárgyalási folyamatba. Hogyan kommunikáljunk tehát a fejlesztőinkkel, hogy elérjük célunkat? Hogyan kommunikáljunk úgy, hogy a befektetett pénzünk ne csupán egy tanulási folyamat részévé váljon, hanem meg is térüljön? Vannak-e és ha igen, mik azok a tényezők, amik garantálhatják, egy informatikai projekt sikerességét?
László az informatikai fejlesztő cégek oldalán ül az Oander képviseletében, így az ő térfelükre enged bepillantást. Vállalkozása fejlesztett már webshopokat, webes üzleti rendszereket és olyan partnerségek résztvevői is voltak, ahol több tízezer órás fejlesztést végeztek! Ha tehát valaki, akkor az Oander ügyvezetője igazán kompetens abban, hogy segítsen eligazodnunk a fejlesztői világban. Többek között arról is kérdeztük, mi mindenre szükséges/fontos figyelnünk onnantól kezdve, hogy egyáltalán megfogalmazódik bennünk: szoftverfejlesztést szeretnénk, legyen szó egy weboldalról vagy akár egy komplex informatikai rendszer felállításáról.
„A mindenkori kommunikációnkon múlik, hogy adott projektbe befektetett pénzünk megtérül vagy pedig a tanulási folyamatunk részévé válik.” – Gangel Péter
*
Mire figyeljünk a partnerkeresés során?
Egy szoftverfejlesztésének első lépései közé tartozik a fejlesztéssel megbízni kívánt partner kiválasztása, mely kiválasztásnak a kölcsönösségen kell alapulnia. Ocskay László elárulja, hogy ezen a téren is legalább olyan fontos a harmonikus együttműködés, mint egy párkapcsolatban, hiszen a nagyobb ívű, hosszadalmas fejlesztői folyamatok, melyek akár hónapokon át is tarthatnak, mély bizalmi kapcsolat nélkül nem működnek.
Mire szükséges még figyelnünk?
- Ismerjük egymás értékeit.
- Tisztázzuk pontosan együttműködésünk keretrendszerét!
- Tájékozódjunk arról, milyen szereplők, milyen típusú problémáira, kihívásaira kínál megoldást, rendszereket a fejlesztő, akivel együtt akarunk dolgozni.
- Legyünk tisztában cégünk digitális érettségével. Ha nincs vagy nem jelentős az előéletünk informatikai szempontból, megeshet, hogy be sem tudjuk lőni, milyen partnerre lenne szükségünk. Járjuk körül tehát figyelmesen a témát!
- Adott cég és adott fejlesztő mennyire passzolnak egymáshoz a cég kihívásainak mérete, finanszírozóképessége alapján?
Hogyan dönthetjük el, milyen termékre, szolgáltatásra van szükségünk?
Minden eset teljesen egyedi. Mire van tehát szükségünk ahhoz, hogy meghatározhassuk dobozos termékbe, dobozos termék testreszabásába vagy egyedi fejlesztésbe fektessünk? Hogyan dönthető el, mi lesz a számunkra megfelelő informatikai megoldás?
- Szánjunk időt a döntés előkészítésére! Elemzés, elemzés és még több elemzés!
- Értsük pontosan, hogyan működik az üzleti modellünk és hogyan lesz működőképes a digitális térben.
- Figyeljünk arra, kitől kérünk ebben a döntési folyamatban tanácsot.
Ocskay László szerint: „Nem biztos, hogy mindig hiteles, ha a tanácsadásnak ezt a részét a majdani beszállítók végzik.”
- Minél kisebb egy cég, annál nagyobb az esélye, hogy elegendő lesz számára egy dobozos termék.
- A piacon bérelhető megoldások is találhatóak, méghozzá mérettől függő megoldások. Ismerkedjünk meg ezekkel is!
Egy informatikai projekt lehetséges buktatói
A vásárló/megrendelő elképzelte, a projektvezető valahogyan dekódolta ezt az elképzelést, ezek alapján készült egy design, majd ezt a programozó leírta… De vajon megrendelőként azt adtuk át, amit akartunk? A folyamat mindig soron következő állomásának felelőse jól értett minket? Hogyan kerülhető el, hogy elcsússzon a kommunikáció és az elképzeléseink végül egész más formát öltsenek? Amikor kiválasztottuk a partnerünket, hogyan tudjuk úgy megfogalmazni igényeinket, hogy az az informatikai cég számára is érthető legyen?
„Ez elsődlegesen azon múlik, milyen mélységű a valóságban a megrendelő felkészültsége. Aki több éve foglalkozik adott területet érintő informatikai megoldásokkal és használja is ezeket, annak sokkal könnyebb dolga van. – mondja Ocskay László – Ismerjük fel, milyen készültségi szinten vagyunk megrendelőként!”
Felkészültségünk fejlesztése megrendelőként
Vegyünk fel projektmenedzsert? Legyen produkt owner-ünk? Egyáltalán mit jelentenek ezek a kifejezések? Bármi is legyen a meghatározott üzleti célunk, legyünk tisztában azzal, milyen kihívások elé állít minket ennek a célnak az elérése és milyen költségekkel kell számolnunk. Csak ezek ismeretében állítható össze olyan csapat, aki a jobbkezünkké válik a megvalósítás, majd a továbbfejlesztés során.
„Fejlesztő cégként arra van szükségünk, hogy a megrendelő pontosan tisztában legyen az általa tervezett projekt kereteivel, kihívásaival mind anyagi, mind minden egyéb – általa felderíthető, az ő hatáskörébe tartozó – tekintetben. Mi akkor teljesíthetünk igazán eredményesen, ha a megrendelő meghozza saját hatáskörben a rá tartozó döntéseket, mint például a kereskedelmi döntéseket. Ha ezeket kiszervezi hozzánk, azzal az egész folyamatot hátráltatja, hiszen hogyan hozhatnánk iparág-specifikus kérdésekben döntést? Adott iparágnak adott projekt megrendelője az ismerője, esetenként a legkiválóbb szereplője is. Kulcstényező, hogy az iparági kérdések, döntések nála maradjanak és vétletlenül se vándoroljanak a fejlesztőhöz.” – mondja László.
- Kulcskérdés még a kommunikációnk megfelelő csatornákba való terelése! Egy sokezer órás projekt esetében kialakul(hat) egyfajta hierarchia a résztvevők közt, ami azt jelenti, hogy mondjuk egy tartalom-projekt esetében az adatbázisokat építő csapatoknak külön koordinátorai vannak. Itt a munkát ciklusonként szükséges szinkronizálni és hasznos, ha van egy személy, aki a folyamatok „tetején” összefogja az egész projektet.
- Ha a fejlesztő cég 100 órát dolgozik, akkor ez azt jelenti, hogy a megrendelő oldalán is ugyanennyi munkaóra keletkezik, azaz elengedhetetlen a tervezés, a tartalom, a megoldások tesztelése. Röviden: 100 óra fejlesztési időre 100 óra ügyfélidő kell, hogy jusson!
- A tesztelés nem feltétlenül az ügyfél feladata, erre egy jó fejlesztő cégnél vannak teszterek és különböző eljárások (esetenként automatizáltak is). Azonban ne felejtsük el, hogy az igazán hiteles tesztelő a szolgáltatás tulajdonosa, hiszen ő tudja, mi a jó a vevőinek és kiemelten lényeges, hogy ez a tudás beépüljön a folyamatba.
Hogyan követhetőek nyomon az informatikai cégek által eladott munkaórák?
Az informatikai cégek ugyanis nagy általánosságban órabérben dolgoznak. De hogyan követhetjük nyomon megrendelőként, mire és/vagy milyen mértékben lettek fel-és elhasználva az elszámolt munkaórák?
- A munkanap elején a fejlesztő elindul x egységnyi időkészlettel, ami a nap végére elfogy. Az a fő szempont, hogy legyen egy rendszeresség ennek az időfogyásnak a mérésére. Pl.: burn out sáv.
- Tisztázzuk a közös munkafolyamat legelején, milyen módszertannal fogunk dolgozni és a megrendelő, valamint a szállító oldal módszertanai hol találkoznak majd a gyakorlatban!
- Tipikus probléma lehet, amikor a szállító (a fejlesztő) agilisan szállít, nála a rugalmasságon van a fókusz, de nincs előre definiálva, hogy pontosan mit kell szállítania. Ezzel szemben a megrendelő előre szeretne meghatározni mindent.
„Látni kell, hogy a nagyobb fejlesztések alapvetően az agilis irányba tolódnak el. Az üzleti környezet általában olyan dinamikusan változik, hogy a fejlesztéseket gyakorlatilag a projekt megvalósítása során folyamatosan változáskezelni kell. Ez ad(hat) egy nagy rugalmasságot, itt a működés sprintszerűen, akár kéthetes ciklusokban történik és apránkénti változáskövetéssel dolgozunk. Hogy ez megfelelő-e számunkra, arról mindenképp egyeztessünk a fejlesztő céggel!” – Ocskay László
- Érdemes alaposan körbejárni a projektmenedzsment-háromszög (határidő+költség+minőség / scope+ resources+ schedule) kérdést a projekt várható költségeinek meghatározásához!
- Scope = definiálja, melyek azok a rendszerek, nagy vonalakban mi az az architektúra és elérendő üzleti cél, amit meg szeretnénk valósítani. Ha ebből kilépünk, számoljunk azzal, hogy az módosít a költségvetésen és a határidőn is!
- Mivel tulajdonosként a legtöbben pénzügyi szemlélet alapján vezetik cégüket, ez a szemlélet afelé tol(hat)ja a vállalkozókat, hogy minél olcsóbban akarják megoldani a fejlesztés kérdését. Egy dobozos rendszer esetében ez működhet, egyedi fejlesztés esetén azonban kockázatos lehet.
- Lőjünk be egy puffer-értéket (ahogyan ezt az építőiparban szokás használni). 20-30%-os többlet a reális, ennyire szükség van a rugalmassághoz. Ez az építőipari hasonlat mentén annyit tesz: egy-két fal máshová kerül(het), de az alapszerkezeten nem változtatunk! Minél nagyobb kockázatot vállalunk, minél bizonytalanabbak vagyunk abban, csináltak-e már olyat a piacunkon, amit most mi csinálunk, annál nagyobb puffer-zónát hagyjunk!
- Növekvő bizonytalanság + megnövelt puffer-érték = csökkentett csalódási esélyek.
Amennyiben fejlesztési projektünk nem a vártnak megfelelően halad
Mi történik, ha minden tervezésünk ellenére a fejlesztés elakad vagy nem úgy halad, ahogyan arra számítottunk? Ocskay László tanácsa, hogy legyen prioritáslistánk és az legyen az elsődleges, hogy ez a lista elkészüljön!
- A backlog vagy termékhátralék egy olyan lista, mely nem csak funkcionálisan, de a tényleges üzleti értékek szintjén is összeszedi, minek kell megvalósulnia a projektünk során és ezek a tételek hogy állnak. (Egy ilyen lista elején értelemszerűen a legnagyobb üzleti értéket képviselő tételek szerepelnek.) A listánkat folyamatosan frissítsük, ha pedig a projektünk több alprojektből áll össze vagy egy projektporfóliót kezelünk, minden folyamatnak legyen saját backlogja, illetve szükségünk lesz egy összefogó backlogra is. Ezeket a listákat valószínűleg más kolléga kezeli megrendelői és más a szállító (fejlesztő) oldalon.
- A prioritások ismeretében kezelhetővé válnak az esetleges emberi problémák is. Ilyen lehet egy hosszabb projekt esetében a belassulás vagy akár a kiégés, de előfordulhat, hogy az alprojektek elkezdenek egymással konkurálni. Megrendelői oldalon is változhat a céges stratégia, aminek következtében egy másik szoftver kerül előtérbe egészen hirtelen (Ez történt például a COVID 19 által kiváltott helyzet folyományaként is több helyütt.) és az új szoftver háttérbe szorítja a fejlesztő által készítettet, azaz utóbbira kevesebb elemzői kapacitás jut. Ennek megfelelő menedzselése is priorizálási kérdés.
- Az idő mérésére praktikus megoldás lehet, hogy a backlog üzleti tételeire a kollégák rákönyvelik adott tétel kapcsán felhasznált munkaóráikat. Erre a típusú megoldásra már számos applikáció érhető el, és ha így vezetjük ezeket az adatokat, az nagyban megkönnyíti, hogy belelássunk a fejlesztőink munkaóráiba.
„Kiemelten fontos, hogy fejlesztőként ne csak órát adjunk meg, hanem költséghelyet is, hiszen a megrendelő nehezen tudja értékelni azt az információt, hogy XY valamivel öt órát foglalkozott. Ez nem teremt értéket. Meg kell találni az értéket a projektben. Itt kapcsolódik az időkönyvelés a backloggal, hiszen a backlog eleve tartalmazza, milyen üzleti értéket vár a megrendelő, a backloggal történő elszámolás pedig azt, hogy milyen üzleti érték teremtődött abban az időben, amit kifizetett számunkra.” – mondja az Oander ügyvezetője.
- A fejlesztőnktől akkor korrekt a munkaóráiról készült kimutatásokat bekérnünk, ha óraalapú vagy agilis projekttel bíztuk meg.
- Minél fiatalabb adott iparág – amiben a megrendelő tevékenykedik, és a fejlesztést tervezi –, annál bonyolultabb a kontrollgyakorlás.
„Ami kiemelten fontos, hogy legyen kontrollunk az elégetett idő felett. Azt javaslom, hogy mindenki mérje az elégetett időt a megrendelői oldalon is.” – Ocskay László
