Valóban, csakhogy nem annyira szépsége miatt, hanem azért,mert éppoly kockázatos megrendelni bármelyiket is.. És persze a másik fél részéről, az elkészítést „bevállalni”. Nos, azt a nem kevéssé pesszimista álláspontot megpróbálom kifejteni.
Emberünk talál magának egy festőt, és rendel tőle egy festményt. Ad neki egy fotót a régen elveszített nagymamáról, és megkéri, hogy ábrázolja őt valamilyen természetes környezetben, és ha lehet, akkor egy kicsit fiatalítsa meg. A festő holdvilágos réten lobogó hosszú hajjal megfesti a képen egyébként már ősz nagymamát. Emberünk elképed, nem így gondolta.
Nem ragozom az egyébként a valóságtól nem teljesen elrugaszkodott fikciómat. De mi is történt valójában? Az egyik fél elképzelt valamit, és megpróbálta azt a másiknak elmondani. A másik meg megpróbálta az elsőt megérteni, és elképzelni, mit is láthatott az első a lelki szemei előtt. Két ember még akkor is mást lát, ha nem csak egy elképzelést próbálnak magukban leképezni. ennek igazolására elég, ha együtt megtekintünk bármely tárgyat, majd a megszemlélt objektumot utólag leíratjuk a két személlyel. Az eredmény meglepő lesz. Bármennyire is törekedtek volna a leírtnál jóval pontosabb, alaposabb, bővebb tájékoztatásra, a két elképzelt látvány sosem lesz azonos. Egyszerűen, mert a két elme másképpen működik, másképpen értelmez dolgokat, sokszor ugyanazt az élményt is másképpen ragadjuk meg.
Nem túlzás, hogy egy vállalati informatikai projekt esetében is hasonló a helyzet. Legalábbis abban az értelemben, hogy a megrendelő elképzeli, hogy milyen működési támogatást vár el a bevezetésre kerülő szoftvertől, és igyekszik ezt a képet a lehető legjobban elmagyarázni a szoftveres kollegának. Csakhogy neki el kellene mondani sok egyéb dolgot ahhoz, hogy azt a szoftveres viszonylag jól értse. Ő ugyanis a megrendelő vállalkozásával is csak éppen most ismerkedik. A megrendelő azonban számos dolgot, tényezőt nem mond el, de nem is hibáztatható ezért. Egyszerűen nem jutnak eszébe. Éppen azért nem, mert ezek annyira alapvetőek, hogy eszébe sem jutnak, mint átadandó információk. Számára ezek magától értendő természetes dolgok, mivel ő maga napjában számtalanszor végzi. Lehetnek a nem szándékoltan elhallgatott dolgok, jelenségek adatok, kiegészítő információk szakmai trivialitások. Egy általános beszédben nem részletezzük mi az ég és a föld, ismertnek tételezzük fel. A szakmai trivialitás azonban nehéz kérdés, és a felelősség is e tárgyban közös. A szakmával éppen ismerkedőnek jó érzékkel kellene minden kicsit is gyanús fogalmat, közlést kielemezni. Ehhez azonban gyakorlat, sok tapasztalat kell. Így azután, ami a megrendelő és az ő kollegái számára egyértelműek és nyilvánvalóak, sok esetben a külső szemlélő részére teljesen ismeretlenek. És sokszor hosszú időn keresztül azok is maradnak Az átadott információ tehát már itt torzulhat. De torzulhat másképpen is, éppen annak kapcsán, hogy ugyanarról a fogalomról két személy más képzeletet alkot. Csak egy példa: „Kérek egy forgalmi kimutatást is”! Az, aki ezt kéri, elég pontosan tudja, mit szeretne ezen a listán látni. Ha ezt a kérést többen is hallgatják, akkor biztos, hogy mindenki mást és mást fog képzelni erről a listáról, következésképpen lényegében annyiféle lista lesz, ahányan hallgatták a megfogalmazott kérést. Rendben, ez itt egy viszonylag egyszerű eset, és itt a szoftveres kollega biztosan rá fog kérdezni, hogy mi legyen ezen a listán (most nem térünk a folyamatnak arra a momentumára, hogy egy ilyen kérdésre milyen csodálkozó szemet szoktak vágni a megrendelők, mondván, vagy gondolván: na, milyen szakember vagy te, ha ezt sem tudod..). Nem fog azonban rákérdezni sok más esetben, mert ott szakmailag sem várható el, hogy gondoljon arra, hogy vannak általa nem ismert tényezők. Nem tud rá gondolni. Aki nem tudja, hogy létezik csavar, az mindent szögelni fog… Így azután törvényszerű, hogy egy vállalati projekt megvalósítás során a megrendelő számos csalódást kell, megéljen, elszenvedjen. Sajnálom őket, de a valóság az, hogy leginkább erről nem tehet senki. A megrendelők ilyenkor személyiségük függvényében kisebb-nagyobb „balhét” csinálnak, számon kérve a szoftveres kivitelező alkalmasságát, tudását, stb. Soha egyetlen percig fel nem merül, hogy a feladat megfogalmazásakor nem hangzottak el fontos információk. (nyilván előfordul az is, hogy a szofverfejlesztő cég elsikkad bizonyos információk felett, vagy logikailag hibásan oldja meg a feladatot, azonban ez az írás nem erről szól).
Mit lehet mégis tenni?
Azt azért nem mondanám, hogy a helyzet teljesen reménytelen. Nézzük, mi is egy informatikai projekt kivitelezési módszertanának a legelemibb része? A specifikáció elkészítése. A specifikációé, aminek elméletben a kivitelezés bibliája kellene, hogy legyen.
Kicsit messziről kezdem a gondolatot. Amikor potenciális megrendelőkkel tárgyalok, és kiejtem a számon, hogy bizony az a projekt várhatóan 6 hónapos lesz, sokszor elkerekedik a szemük. Egyszerűen a PIAC nem érzékeli a szakmai alapvetéseket. A szükséges idő ráfordítására sem anyagilag, sem időben nincs felkészülve. Gyors eredményt szeretne. Pedig az egyetlen helyes út az lenne, ha a specifikáció elkészítésére nem a projekt teljes megvalósulási idejének a 5-10 %-t szánnánk, hanem legalább 40 %-ot, vagy még ennél is többet. Ha az informatikai csapat embere, vagy nota bene emberei beköltöznének hetekre a megrendelő cégébe, és megpróbálnák ellesni azt, ami egyébként nem mondható el. És akkor máris a helyére kerül e dolgozat elején említett megrendelő akkor még hiányosnak ítélt elmondása. Helyére kerül, mert ebben a kontextusban már valóban nincs is neki más dolga, mint a célt megfogalmazni. Az informatikai csapat emberei a cégnél eltöltött hetek alatt elsajátított ismertek alapján már elég jó érzékkel lesz képes megtalálni saját maga azokat a momentumokat, amiket a megrendelő nem mondott el. Vagy kérdezni, mert már birtokában vannak legalább annyi ismeretnek, hogy kezdjék felismerni, hogy mit nem tudnak. Itt van tehát az optimista pillanat, VAN MEGOLDÁS!!
De mi a valóság? Sajnos azt látni kell, hogy a leírt módszer nagyon költséges. A helyszínen dolgozó rendszermérnök kollegát (vagy kollegákat) minden más munkából ilyenkor ki kell venni, csak ezzel az egyetlen munkával tudnak foglalkozni. Ez a tanulási idő önmagában tovább is tart, mint amennyi idő az általános gyakorlatban ma a specifikáció készítésére fordítódik. És ebben a szakmában az ár mértékegysége az, amit az „embernap” csúnya kifejezéssel jelölünk. Az esetek többségében tehát egyszerűen nincs pénz arra, hogy ekkora anyagi ráfordítással valósítsák meg a vállalkozások az informatikai projektjeiket.
Mi a realitás?
Tudomásul kell vennünk a valós körülményeket, és meg kell próbálnunk megtalálni az erre a helyzetre kialakítható módszert. Mi a SZÁMADÓ-ban nagyon sok időt fordítottunk arra, hogy találjunk kis lépéseket ezen az úton. Véleményem szerint a legfontosabb elemek:
- Alapvetés, hogy a leírtakkal mindkét fél tisztában legyen. Ha sikerül ezekben a körülményekben egyformán gondolkodni, akkor jó esély van arra, hogy mindkét fél a projekt kivitelezésének közös munkája során kellő empátiával és megértéssel lesz a másik fél iránt.
- marad a megoldás, hogy a specifikáció elkészítésére annyi idő marad, amennyi a mai gyakorlat, tehát 2-3 hét. Nincs mit tenni…
- A megrendelővel el kell fogadtatni azt a tényt, hogy egy ilyen projekt megvalósítása nem arról szól, hogy a szoftveres cég valahol a távolban dolgozik, mint a güzü, ő meg, mint megrendelő vár az eredményre. Folyamatosan kell, együttműködjön vele, a részeredményeket is meg kell kapja, azokat annak száz hibája ellenére ki kell próbálja. Éppen azért, hogy ha esetleg valami kezd kicsit félrecsúszni, azt időben lehessen megfogni, és ne kellejen a folyamatot egy továbbfutott állapotból majd visszahozni.
- A felek között a megszokottnál sokkal több konzultációra van szükség. Egy-egy felmerült problémát a fejlesztők ne egymással beszéljék meg, hanem az ügyféllel. Legyen az akkor is úgy, ha ez esetleg úgy tűnik, hogy (a konzultációs időpont egyeztetése miatt) ez időveszteség. Nem, ez nem időveszteség, sokkal több idő válik feleslegessé, ha a fejlesztés téves irányt vesz, és az később derül csak ki.
Kezdetben tehát nem is gondolnánk, hogy egy informatikai projektben mennyire sok a szubjektív elem. Pedig, némi túlzással mondhatnánk, hogy csak az van benne. Ha nem így lenne, akkor nem projektről, hanem dobozos szoftvertermékről beszélnénk. Éppen ez a szubjektív momentum, ami egyedivé és különlegessé tesz minden projektet. Cégre alakítottá a megvalósult terméket. Évek óta mondom: minden vállalkozás egy szellemi termék. Az ez eljárási rend, ahogy a belső folyamataikat megvalósítják, éppen ez a szellemi termék. Az évek során kialakult vállalati kultúra, a sok kollega és a vezetők által egymásra rakott építőkövek (jók, is hibásak is) felépítménye. Ezért különbözik minden vállalkozás akkor is, ha azonos iparágban dolgoznak. És ezért van az, hogy minden olyan informatikai projekt, ami egy vállalat folyamatait kell, hogy kiszolgálja, segítse, önálló szellemi termék kell, hogy legyen.
Ettől szép ez a szakma…
