Az alábbiakban folytatom az előző részben elkezdett társalgást kollégámmal és barátommal, Marhefka Istvánnal, a Synergon Informatika Nyrt. vezető fejlesztőjével. Nem titok, hogy több, mint egy éve dolgozunk együtt egy projekten, így volt alkalmunk megismerni egymás munkastílusát, hozzáállását.

Te elsősorban üzleti elemzőként, én felülettervezőként ügyködöm a Synergon égisze alatt; a közös alkotás eredményeképpen nemcsak szakmailag, de emberileg is közel kerültünk egymáshoz. A projekt kezdetén történt, hogy egy probléma kapcsán egy egész napot ültem melletted, és figyeltem, hogy miként formálod kóddá az üzleti fogalomteret. Azon a napon radikálisan megváltozott a programozásról alkotott szemléletem.
Addig azt gondoltam, hogy a fejlesztő feladata, hogy megértse az adott problémát, majd a legjobb tudása szerint kódba öntse azt. A program ez alapján lényegében az üzleti fogalomtér végkifejlete lenne, ami olyan, mintha azt mondanók, hogy a beszéd nem több a gondolatok kinyilvánításánál. Pedig a gondolkodás és a beszéd sokkal szorosabban összefügg egymással ennél: nemcsak a gondolkodás formálja a beszédet, hanem a beszéd is alakítja a gondolkodást, azaz szervesen összefonódva hatnak egymásra.
Szóval ahogy írtad az osztályaidat, és hangosan gondolkodtál, azt láttam, hogy nem az okoz erőfeszítést számodra, hogy megtaláld a technológiailag helyes sémát, hanem azon töprengsz, hogy milyen nevet adj az osztályaidnak, függvényeidnek. Pontosan arra fektetted a hangsúlyt, amire nem szokás: sok programozó a névválasztást szükséges nyűgnek tartva az éppen eszébe jutó címkét aggatja a definiált entitásaira. Te ezzel szemben egy-egy ragválasztáson is eltöprengtél, ha egy új üzleti fogalommal gazdagítottad a domaint.
Megint rá kellett döbbennem arra, hogy a szó minden. A helyesen megválasztott fogalom és a következetes nyelvhasználat különbözteti meg az igényes programozót a droid fejlesztőtől. Nevezd meg és uralni fogod! - tartja a középkori mondás - Kiáltsd ki a démon nevét, és ezáltal rabszolgáddá lesz.
Nincs ez másképpen a programozásban sem. A fejlesztő nem tesz egyebet, mint megpróbálja az alkalmazott nyelven megfogalmazni az adott üzleti problémát. Ahogy definiálja az egyes üzleti entitásokat, úgy formálódik át benne az üzleti probléma. A programírás és az üzleti elemzés ily módon állandóan oda-vissza ható folyamat, lényegében egy folytonos küzdelem a fogalmakkal.

M.I.:Nagyon fontos, hogy a fogalmak, koncepciók egyértelműek legyenek mindenki számára. Ez biztosítja azt, hogy nem "csúszik félre" a projekt. Nem csupán azért, mert az ügyféllel közösen megértjük egymást, hanem azért is, mert így biztos lehetek abban, hogy a fejlesztő, akivel egy adott problémát megbeszéltünk, és neki lát egy adott modul fejlesztéséhez, ugyanabban a világban él, mint amiben én (meg mint - remélhetőleg - az ügyfél). Magam is rácsodálkoztam számtalanszor arra, hogy egy-egy világosnak hitt fogalmon mennyire mást tud érteni egy-egy fejlesztőtársam. Volt arra is példa, hogy amíg 1-2 hétre szabira mentem, és utána visszajöttem, olyan fogalmi rendszerrel találkoztam a fejlesztők között, ami - számomra, mint a projekt üzleti elemzőjének - megdöbbentő volt: nem is létezett az az üzleti fogalom: a lényeg "átkorcsosult" egy más fajta fogalmi rendszerbe. Ez persze senkinek sem a hibája, hiszen mindannyian másképpen gondolkozunk, másképpen tekintünk a világra, de szerintem nagyon fontos, hogy legyen _egy_ ember a csapatban, aki következetesen használja és betartatja, "karbantartja" a fogalmi rendszert. Ez nem egy belső nyelv: ennek azt a célt is kellene szolgálnia, hogy az ügyféllel közösen megértsük egymást. Lényegében az ő szakzsargonját próbáljuk "kitisztítani".
Nagyon fontos, hogy ez a törekvés mindenkiben meglegyen, ugyanis a közös fogalmi rendszer hatékonyan segíti a kommunikációt a programban és mindennapi kommunikációban, de pl. egy-egy fogalom névadásánál jelentkező problémák is jelezhetik azt, hogy az üzleti modellünk "bűzlik". (Nem tudunk nevet adni valaminek, vagy a neve nagyon hosszú valaminek vagy csak nehezen körbeírható.)

Az üzleti elemző szerepe

K.Zs.: A fogalomhasználat precizitása úgy tűnik, hogy kulcsfontosságú az olvasható kód írásakor. Üzleti értelemben vett precíz nyelvhasználatra csak az képes, aki átlátja az üzleti fogalomteret, és ezzel gyakorlatilag eléggé leszűkítettük a kört...
M.I.: Nagyon fontos tehát az, hogy a csapat egy fogalmi rendszer használjon (és értsen!), véleményem szerint ez "véletlenül" nem alakul ki, csak akkor, ha valaki ennek a fogalmi rendszernek a megalkotásáért felel, tehát az ő kezében van az irányítás. Ő az, akit üzleti elemzőnek hívunk. Ő látja át ideális esetben a teljes problémateret, üzleti folyamatokat, de legalábbis minimum egy lépéssel előrébb jár a megértésben, mint a fejlesztői csapat. Képes a dolgok mögé látni, és akár egy-két huszárvágással is képes úrrá lenni egy-egy kibogozhatatlannak tűnő problémán. Jó absztrakciós és kommunikációs készsége van.

K.Zs.: Csak nagyon szerencsés esetben találunk olyan személyt, aki otthonosan mozog az adott üzleti területen, és egyben tapasztalt fejlesztő is egy személyben, és ez probléma. Vegyünk egy példát! Tegyük fel, hogy szeretnénk fejleszteni egy banki szoftvert, mely lehetővé teszi, hogy az ügyletek nyomán keletkezett iratok adminisztrálását ellássa. Megoldásunkat termékként kívánjuk értékesíteni, továbbá szeretnénk egy olyan munkatámogató modult is hozzáfejleszteni, mely teljeskörűen támogatja a bankon belüli ügyek lebonyolítását. Akarunk egy célszoftvert, mely az iratkezelés banki szférában való adaptálását valósítaná meg.

1. Ha a régi fejemmel gondolkodnék, akkor azt mondanám, hogy állítsuk rá az üzleti elemzőinket, mérjék fel az igényeket, majd specifikálják a feladatot, melyet a fejlesztőcsapatunk majd kivitelez. Ez jól is hangzana, a probléma csak az, hogy a legtöbb esetben a belsős üzleti elemző záros határidőn belül nem képes kellő mélységben átlátni a problémakört. A legtöbb informatikai projekt már az üzleti elemzés fázisánál zátonyra fut úgy, hogy sem a megrendelő, sem a kivitelező nem ismeri fel a fejlesztés valódi rákfenéjét. Gyúrják, pofozzák a szerencsétlen programot, míg végül lesz belőle egy agyonfoltozott sánta óriás, melyre sem bevezetni, sem karbantartani nincs elég erőforrás.
2. Jelenlegi szemléletem alapján, az első dolgom az lenne, hogy megkeressem a túloldalon ülő vérbeli szakértőt. Azt a személyt, aki már több éve belülről ismeri az összes ága-bogát a banki ügyvitelnek, aki vezetett már banki irattárat, és saját maga is sok iratot írt alá. Ha nem találok ilyet, akkor tovább keresek: ez az első és legfontosabb erőforrás, melyre mindenképpen szükségem lesz, ha sikerre akarom vinni a projektet. Ha megtaláltam a kívánt személyt, leszerződök vele: be kell hoznom a projektbe ahhoz, hogy száz százalékban nekem dolgozzon, hogy belülről képviselje az ügyfelet. Ő lenne a projekt szakmai gazdája, az első számú üzleti elemző.
   A második lépés ennél jóval könnyebb, de egyáltalán nem triviális: a frissen hozott erőforrás bár nagyon ért az adott területhez, informatikailag egyáltalán, vagy csak alig képzett személy. Szükség van mellé egy olyan üzleti elemzőre, aki a fejlesztői csapat élén állva megformálja a program lelkét képező domaint. Ha ezt a két személyt megtaláltam, akkor a kezemben van a projekt szakmai sikerességének garanciája.

M.I.: Itt több dologról is szó esik.
Azt hiszem, eléggé sokan tisztában vagyunk azzal, hogy egy szoftverfejlesztés nem egyszerű dolog. Én még nem találkoztam olyan projekttel, ahol ne jött volna elő az a szituáció, hogy az ügyfél nem arra gondolt, amit megcsináltunk. Nagyon fontos, hogy gyors visszajelzések legyenek, hogy lássuk, valóban tetszik-e az ügyfélnek az, amit épp csinálunk.
Egy kicsit az elejére visszatérve: ma Magyarországon nem igazán lehet beleugrani egy szerződésbe úgy, hogy előtte ne állapodnánk meg abban, hogy mit is kell tudnia a szoftvernek. Ideális esetben külön lehet szerződni a követelményspecifikáció elkészítésére, és az abban megfogalmazott követelmények alapján lehet becsülni a fejlesztés, tesztelés, bevezetés stb. költségét. (Rosszabb esetben úgy adsz ajánlatot, hogy nem vagy tisztában a rendszer szkópjával, és csak annyit tudsz, amennyi a pályázati kiírásban szerepelt.) Azzal kell tisztában lennie mindkét oldalnak, hogy a követelményspecifikációt nem kőbevésett dolognak tekintsük, hanem egy változó szkópnak. Ez mindkettőnk érdeke, mert mi ugyan azt mondhatnánk, hogy ez vagy az nem szerepel a követelményspecifikációban, viszont ő ettől nem lesz boldogabb, és azt a rendszert kapja meg, amit vízionál, ezáltal vita tárgyává válik a teljesítés is. Tudomásul kell venni, hogy le lehet írni egy kövspecet, de attól azt csak kiindulási alapnak érdemes tekinteni, és ha idő közben kiderül, hogy van olyan, ami nem került bele, akkor ki lehet belőle húzni, és helyette bekerül az új dolog. Sok-sok követelményt be lehet írni, de egy nagy része nem fontos, és lehet valami, ami fontos, de nem került bele.

Ez így leírva sem egyszerű, és nagyon kényes dolog is. Biztosan sokan el tudnák mesélni saját tanulságos történeteiket. Sok-sok könyv szól az agilis szoftverfejlesztésről is, látszik, hogy sokakat foglalkoztat ez a dolog:) Az viszont tisztán észrevehető, hogy a hagyományos modell (követelményt felmérünk, tervezünk, fejlesztünk, tesztelünk, átadunk, bevezetünk) nem működik. Van egy kollégám, aki azzal foglalkozik szabadidejében, hogy hogyan lehet az agilis szoftverfejlesztést a közbeszerzésben alkalmazni:)
Az eredeti felvetésednek az első fele azzal foglalkozott, hogy fel kell-e mérni a fejlesztés előtt, ill. mennyi energiát érdemes ebbe belefektetni, a másik fele pedig azzal, hogy kik azok a kulcsemberek, akiknek a megléte nagyban növeli a fejlesztés sikerét.
A legideálisabb az, ha a csapatban jelen van az ügyfél. Ezt az eXtreme Programming (XP) módszertan on-site customernek hívja. Ő ott van, amikor dolgozunk, azonnal validál, mindig lehet kérdezni, ő válaszol stb.
Sajnos, nem mindegyik ügyfél hajlandó foglalkozni a "nyűgjeinkkel". Mi abban a szerencsés helyzetben vagyunk, hogy az ügyfél oldaláról sikerült átcsábítanunk egy szakértőt a fejlesztői csapatba, és ő most már nekünk dolgozik. Ez nagyban lecsökkentette a kockázatokat, ugyanis vele közvetlenül meg tudjuk vitatni a fejlesztendő modulokat, ő maga is részt vesz a tervezésben. Ő az üzleti területet nagyon jól ismeri (üzleti szakértő), és szerencsés helyzetben vagyunk, mert alapvetően ő is technikai beállítottságú, könnyen megtaláljuk a közös hangot, ám ő nem fejlesztő. Kell hozzá egy pár a fejlesztői csapatból (üzleti elemző), aki képes vele egy hullámhosszra kerülni, és a fejlesztők számára megfelelően lefordítani az ő általa megfogalmazott feladatokat. Ez az üzleti elemző vagyok én. Egy év után már nagyon jól megértjük egymást, annyi kérdezz-feleleket játszottunk már, hogy én is látom, "érzem", hogy mit szeretne látni a másik oldal. Egyre gyakrabban fordul elő az is, hogy olyan kérdést tudok feltenni, ami "telibe talál", és így kiderülnek olyan fontos dolgok, amikre eddig nem gondolt a másik oldal. Persze, még ideálisabb esetben az üzleti szakértő és elemző személye egy is lehet, én még ilyennel nem találkoztam.
Minden fejlesztőtársamnak azt javaslom, hogy próbáljanak meggyőzni az ügyfél oldaláról egy segítőkész embert, aki rendelkezésre tud állni, hogy segítsen a fejlesztés során. Hihetetlen dolgokat lehet így véghez vinni!
K.Zs.: Az üzleti felmérést nagyon gyakran olyan elemzők végzik el, akik nem jártasak a fejlesztésben, és nem tudják megállapítani azt, hogy egy adott funkció implementálása milyen horderejű feladatot jelent. Azt tapasztaltam, hogy nagyon sokat jelenthet, ha már az elején jelen van egy programozáshoz értő személy, aki hatást tud gyakorolni a követelményspecifikáció elkészültére.
M.I.: Amikor kimegyünk egy céghez, hogy egyedi szoftver megoldást szállítsunk, fel kell mérni a követelményeket. Nagyon sokszor ilyenkorra már van egy szerződés, ami meghatározza a szoftver kifejlesztéséhez felhasználható erőforrásmennyiséget. Fontos kockázatcsökkentő tényező, ha egy olyan ember legyen képes az ügyfélnél jelen lenni, aki proaktívan, dialógust kezdeményezve próbál olyan előzetes megoldásokat felvázolni, amik csökkenthetik a későbbi ráfordításokat. Valószínűleg nem csak nekem "áll fel a szőr a hátamon", amikor nem egy kövspecben ezt olvasom: "a rendszer naplózzon minden módosítást és módosítási kísérletet". Ha valaki olyan megy oda, akinek fogalma sincs a megvalósítás hátteréről, simán "benyel" egy ehhez hasonló követelményt. Amikor egy ilyen elhangzik, további kérdéseket lehet feltenni az ügyfélnek, hogy valójában mi a célja ezzel, mik a legfontosabb adatkörök, hogyan fogja ezeket felhasználni stb. Így egy pontosabb képet lehet alkotni az elképzelésekről, és ráadásul ésszel lehet neki állni egy ilyen követelmény megvalósításához.
Nem csak ezért fontos, hogy egy fejlesztés közeli ember jelen legyen, hanem azért is, hogy egyből "vegye" az ügyfél igényeit, és ezt - mint a fejlesztői csapat aktív tagjaként - elsőként tudja tolmácsolni a fejlesztők felé.
K.Zs.: Az előbb említetted, hogy a hagyományos hozzáállás (iteratív fejlesztés) manapság nem vezet eredményre. Az átadáskor gyakran kiderül, hogy a szállító cég által készített program nem felel meg a megrendelő igényeinek, mert ő teljesen más rendszert vizionált. Szerinted hogyan lehet csökkenteni a kockázatát annak, hogy ez ne így történjen?
M.I.: Érdemes mindig "nagyot harapni", valahogyan mélységben haladni. Ez azt jelenti, hogy soha ne a részletekre koncentráljunk (no, persze, ezek is fontosak, de ésszerűen kell priorizálnunk.) Próbáljunk mindig egy egyszerűen megvalósítható, de nagyobb részt lefedni. Ebből már sok minden látszik, érdemes megmutatni az ügyfélnek, tud mire reagálni. Ha viszonylag gyakran van lehetőségünk az ügyfélnek megmutatni az eddigi rendszert, akkor elég korán kiderülnek a problémák, és hamar lehet korrigálni, ezáltal biztosítható a minimális vakvágányokkal történő folyamatos konvergálás a cél felé. Persze, nincsenek nagy igazságok, amiket alkalmazva mindig sikerre vihető egy tetszőleges projekt, talán csak egy: a józan paraszti ész. Ne féljünk attól, hogy változtatunk az eddigi bevált módszeren, ha a helyzet ezt kívánja!
K.Zs.: Az agilis projektekben gyakran előfordul, hogy nincs idő specifikálni az egyes igénybeli változásokat, így szóban terjed az ige. Az "...az a mondás, hogy..." kezdetű mondatok nagyon össze tudják zavarni a munka menetét, hiszen gyakran egyáltalán nem világos, hogy egy adott üzleti igény ténylegesen igény, vagy csak vágyálom. Fontosnak tartom, hogy legyen egy személy a projektben, aki képes mindezt átlátni, és nem hagyatkozik az efféle bizonytalan forrásokra. Meg kell, hogy mondjam, hogy ebben a tekintetben is példaértékűnek gondolom a hozzáállásod a projektben: addig böngészted a kapcsolódó forrásokat, amíg le nem tisztult benned, hogy mi az, amit el kell, hogy várjunk a termékünktől.

M.I.: Egyetértek Veled, szerintem is komoly problémát jelent ez. Kell egy személy, aki a program által képviselt modellt átlátja, ismeri a lehetőségeit, korlátait, és meg tudja mondani, hogy egy-egy felmerült igény, elképzelés milyen komplexitású és várhatóan mennyi erőforrást igényel. Csakis következetesen lehet végig csinálni sikeresen egy nagyobb méretű projektet, különben elfelejtődnek a dolgok, vagy olyanok kerülnek be, amik nem is voltak. Mi egy ideje Scrumot használunk, ami segített abban, hogy ezeket tudatosan végig vigyük: van egy product backlogunk, ami priorizálva tartalmazza az összes felmerült üzleti igényt. Ez folyamatosan változik (mert változhat). Úgy dolgozunk, hogy mindig a legnagyobb prioritásút vesszük előre. Ezzel párhuzamosan egy issue-követő rendszerben a hibákat is nyilvántartjuk.
K.Zs.: Tapasztalatom szerint sokkal sikeresebbek azok a projektek, ahol van néhány magasan képzett senior fejlesztő, és kevés droid, mint azok, ahol sok középszerű fejlesztő gyúrja a sok-sok bitet. Minél nagyobb a projekt, annál nagyobb a kommunikációs overhead, annál nagyobb gond átadni az üzleti tudást a csapattagoknak.
M.I.: Igen, én is úgy gondolom, hogy sokkal jobb, ha kevés, ám jó képességű és jól képzett fejlesztő dolgozik együtt, mintha a képességek hiányát vagy a határidő szűkösségét sok emberrel pótolnánk. A nagylétszámú csapatban a tagok közötti kommunikáció gyakorlatilag teljesen lelassíthatja a fejlesztés ütemét és a nagy létszám a minőség rovására megy (még több energiát kell fektetni a minőségbiztosításra). Csak akkor lehet sok emberrel dolgozni egyszerre, ha az üzleti terület egymástól független, jól elhatárolt részekre bontható, ehhez viszont megelőző tervezésre van szükség. Ezt viszont a korábban említett szempontok miatt nem is érdemes sokáig csinálni, hiszen ettől rugalmatlanabbá válik a projekt (túltervezés): az ügyfél nem teljesen tudja, hogy mit akar, és ezt sokszor nem is tudja megfogalmazni. Arról viszont könnyebben tud nyilatkozni, hogy ha valamit lát, az tetszik vagy nem tetszik neki. Sem az alultervezés (under-engineering) sem a túltervezés (over-engineering) nem hatékony: itt is valahol az arany középút a megfelelő.
K.Zs.: Milyen tárgyi tudása van egy jó fejlesztőnek?
M.I.: Erre a kérdésre nem igazán tudok válaszolni. Ha valamilyen kompetencia hiányzik a csapatból, akkor dönthetünk úgy, hogy egy olyan embert veszünk fel, akiben megvan ez a kompetencia. Hosszú távra a korábban említett elképzeléseim azok, amik alapján döntök.
K.Zs.: A hatékony fejlesztés elengedhetetlen eszköze a magasszintű matematikai tudás?
M.I.: Nem, de én úgy gondolom, hogy ha valakiben nincs meg az érdeklődés a matematikai problémák és az absztrakció iránt, az - a Te szóhasználatoddal élve - csak droid lehet. Rájuk is szükség van, de ők könnyebben helyettesíthetőek.
K.Zs.: Rájuk is szükség van? Fentebb emlíetted, hogy valójában nincs, mert egy jó csapatnak senior fejlesztőkből kell állnia. Milyen helyzetben lehet mégis hasznos, ha droidmunkásaink is vannak? Nyilván léteznek olyan problémák, ami monoton munkabírást, és kevés üzleti rálátást követelnek meg.
M.I.: Igen, léteznek. Ezek olyan problémák, amelyeket "kilóra" lehet végezni. Jól kitaposott megoldásokon alapulnak, rendszerint mechanikusan, kevés fantáziával megoldható munkák, amik elvégzése közben nem jelentkezik nem várt nehezség.
Egy-egy projekten belül is vannak olyan részfeladatok, amelyek mechanikusak, de azokat is nyilván meg kell csinálni. Ha viszont már csak ilyen jellegű munkák vannak, vagy egy problémákörnek egy jól elhatárolt része ilyen, akkor ott nincs szükség a kreativitásukat használó senior fejlesztőkre.