Kavargó gondolatok, azaz mire is gondol az ügyfél

A szoftver mindig valamilyen igényt elégít ki.

Ez legtöbb esetben valamilyen vállalkozás valamilyen üzleti igénye: 

• például, szeretnének egy menetrendkereső alkalmazást webes felületre, hogy az ügyfelek tájékozottabbak legyenek, többet vásároljanak, és kevesebb költséget generáljanak azzal, hogy az ügyfélszolgálatnak telefonálnak információkat kérve.
• vagy valaki szeretne elkészült videókat pénzért megosztani (egy streaming-szolgáltatóhoz hasonlóan).
• vagy egy webshopot szeretne készíttetni a saját igényeire szabva 
• vagy igazából bármi, ami éppen valakinek valamilyen problémájára megoldást jelent

A kavargó gondolatok fázisa

A szoftverötlet az én szoftverfejlesztő karrierem során kivétel nélkül egy üzleti döntéshozó fejéből pattant ki: lehet ez vállalkozásvezető, valamilyen üzletrész vezetője. Ha a személyiségüket nézzük, akkor többnyire ők abban erősek, hogy víziót hozzanak létre, és azt utána a kollégák közreműködésével valóra váltsák. Ritka eset az, amikor ők technikai vagy még inkább informatikai szakemberek. 

Nem találkoztam még egy olyannal sem, aki leült volna a számítógépe mellé, és órákon át elmélyedve azon gondolkozott volna, hogy a megvalósítandó rendszer pontosan hogyan is épüljön majd fel. Ha ezen a ponton megkérdezzük tőle, hogy mit szeretne, jellemzően egy-két mondatot kapunk válaszként és egy kérdést, hogy ez mikorra lesz kész és mennyibe fog kerülni.

Legrosszabb esetben még akár az is előfordulhat, hogy annyit kapunk, hogy „Csinálj egy webshopot az üzletemnek!” vagy kicsit kevésbé rossz  esetben „Csinálj egy webshopot az üzletemnek ami olyan, mint a Józsikáé!”. Rosszabb esetben a kérdés úgy hangzik „Miért nincs még kész a webshopom?” 🙂

Talán már ebből is sejtjük, hogy még messze van az a pont, ami már kellően részletesen leírja, hogy milyen szoftvert kell készítenünk. Gondoljunk csak bele abba, hogy mit tapasztaltunk az általunk használt webshopok kapcsán: hányféle kinézet, logo, megjelenés, termékcsoportosítás, termékleírás, hányféle fizetési és szállítási lehetőség az, ami elérhető egy-egy megoldás esetén: mindegyikről el kell dönteni, hogy kell-e, nem kell, beépítjük, kihagyjuk… A megrendelés milyen státuszokban lehet kártyás, és milyen státuszokban lehet utánvétes fizetés esetén. Rengeteg a kérdés, amit a szoftverfejlesztői oldalnak fel kell ismernie, meg kell fogalmaznia és fel kell tennie az ügyfélnek. Itt még az eszközöknél (akár AI eszközöknél) is sokkal fontosabb az előzetes tapasztalat, a probléma átlátásának képessége: és ez sok esetben a programozóéleten kívülről jön. Egy-egy megbízás esetében tudom használni a saját cég működtetésében szerzett tapasztalataimat, így vissza tudok kérdezni olyan helyzetekben (EU-s adózás, GDPR…) amivel már találkoztam, de lehet, hogy az ügyfél vagy annak az ügyvédje nem gondolt rá. Neked – ha pályaváltást fontolgatsz – milyen területen vannak tapasztalataid, ami hasonló helyzetben kritikus lehet egy projektben? Milyen szakmával tudod kombinálni a szoftverfejlesztésben megszerzendő tapasztalataidat? Ezt milyen helyzetben tudnád a leendő munkahelyed (és így a magad) számára kiaknázni?

Lépjünk tovább, nézzük meg mindezt egy analógiával:

Útban a feladat pontos leírása felé – analógia

Ha valaki egy webshopot szeretne tőlünk, akkor az olyan, mintha azt mondaná egy autókereskedőnek, hogy „kérek egy autót!”. Ebből még nem sok mindent tudunk sem arról, hogy mit tudjon az a jármű, mire legyen jó, mire nem, és arról sem, hogy mennyibe fog majd kerülni.

Mert ugye autó a középkategóriás Opel, a felsőkategóriás Mercedes vagy Tesla, de autónak számíthat egy nagydobozos, amivel a különféle futárcégek szállítják a csomagokat, vagy szélsőséges esetben egy kamion is. Ha másik irányban indulunk el, akkor egy Bugatti Veyron is, és egy Forma-1-es versenygép is autó.

A különféle autók különféle dolgokat tudnak, és különböző az áruk is, tehát egy használt középkategóriás kombi Opel 3-4 millió Ft-ért jó választás lehet sok esetben, de ha 300-zal akarunk repeszteni egy tükörsima versenypályán, akkor inkább a sokszázmilliós sportautók jönnek számításba. Ha pedig a Forma-1-es versenyszériát akarjuk megnyerni, akkor már a Bugatti Veyron sem jöhet számításba, oda mindenképpen egy Forma-1-es versenyautóra lesz szükségünk, ami akár 3,5 milliárd Ft-ba is kerülhet.

Ha viszont árut akarunk szállítani, akkor egy teljesen másik irányt kell választani, és ott is vannak különféle árú különféle lehetőségeink raktérméret, erő, hatótáv, szükséges jogosítványszint tekintetében.

Mivel rengetegféle opció van, autók terén is, meg kell tudnunk, hogy milyen autóra gondolt a megrendelő, amikor felkiáltott, hogy „kérek egy autót!”

Business analyst

Az ötlet kibontásához olyan szakemberre van szükség, aki

• egyrészt ért az ügyfél nyelvén, képes szót érteni vele, elmagyarázni neki koncepciókat úgy, hogy megértse, azaz képes arra, hogy „kivarázsolja” a fejéből az igényeket, 
• ugyanakkor komoly IT ismeretei is vannak, hogy képes legyen felmérni, hogy mi az, ami megvalósítható jelentősen megugró költségszint nélkül, mi az, ami nem olyan nagy áldozat.
  Autós analógia: az ügyféllel egy középkategóriás kombi Opelről beszélgetünk, aminek a végsebessége nagyjából 200 km/h, és az ügyfél azt mondja, hogy „csak szorozzátok meg a végsebességet kettővel, az csak egy szorzás, nem?”, akkor a vele beszélgető szakembernek tudnia kell, hogy az nem csak egy szorzás, és egy 400 km/h-val menő autó építése nem fog beleférni egy középkategóriás kombi Opel árába, és vagy le kell beszélnie az ügyfelet a változtatásról, vagy elő kell vele teremtetni 4 millió helyett 400+ millió forintot a megvalósításra.

Ezt a szerepkört leginkább business analyst-nek nevezik, és jó esetben van erre külön ember a csapatban. Kevésbé jó esetben rátestálják a projektmenedzserre, aki úgyis ért az emberek nyelvén (hiszen projektmenedzser), akkor majd ő megbeszéli az igényeket. Ha viszont nem tudja mellétenni az IT oldalt, akkor ebből lesznek az olyan jellegű projektindulások, hogy „Na akkor emberek, az a feladat, hogy készítsünk egy olyan autót, aminek a végsebessége 400 km/h, teherbírása 30 tonna, teljes terhelés mellett 2 másodperc alatt gyorsul 200 km/h-ra, és van rá 2,5 millió forintunk. Na húzzunk bele!” (és amiről csak menet közben derül ki, hogy amúgy a 30 tonna mellett még 32 embert is kellene tudnia szállítani…)

Továbbá lehetséges még az is, hogy valaki a szoftverfejlesztő csapatból próbál helytállni ebben a szerepkörben. A technikai oldal így adott lesz, viszont a jó minőségű technikai tudás és szemlélet ritkán jár együtt jó kommunikációs és vezetői készségekkel. Persze vannak szerencsés kivételek. 

És természetesen az is lehet, hogy minden flottul megy: beülsz egy multiba, mindenki jól dolgozik a kollégák közül, neked csak a saját munkáddal kell foglalkoznod. Ha szoftverfejlesztő leszel, akkor rá fog állni a szemed azokra az esetekre, hogy egy folyamat hol romolhat el. Ami nem pesszimizmus, csak nekünk programozóknak olyan valószínűtlen helyzetekkel is foglalkoznunk kell, amin az átlagember átsiklik. Nekünk pedig meg is kell oldani… Így aztán én is hajlamos vagyok ezeket a szituációkat is előrángatni és elmesélni.

Erre az esetre is fel kell készülni, de persze van, hogy minden simán megy. Most mi azokat a sarkos példákat ragadtuk ki – és fogjuk majd a későbbiekben is bemutatni – ami felhívja a figyelmedet arra, hogy nem feltétlenül csak a kódolás van egy projektben. Ahhoz, hogy teljesebb képet kapj a programozók munkájáról,  igyekszünk mindent körüljárni, de semmiképp nem elijeszteni. 😉