Talán sokan hallották már a következő viccet. Azt mondja a feleség a férjének: "Kérlek, menj el a boltba, vegyél kenyeret, és ha van tojás, hozzál hatot." 

Mit hoz haza egy átlag ember? 6 tojást. Ámde mivel jön haza az informatikus? Nyilván 6 kenyérrel!

A vicc jól mutatja a gondolkodásbeli különbséget. Érdemes, és egyben nagyon érdekes is jobban megismerni az informatikusok gondolkodásmódját ahhoz, hogy megérthessük őket. A bevásárlós példánál maradva pedig azért is, hogy végül azt kapjuk, amit szerettünk volna. A helyzet nem egyszerű, ezért hasznos lehet néhány tanács.

SZÓTÁR IT-SOKHOZ

Mindenképpen jól jöhet például egy szótár, hogy a kérdéseinkre kapott válaszokat is biztosan úgy értsük, ahogy kell. Ezek nem a szakzsargonba tartozó, vagyis nem a szakmát érintő kifejezések lesznek, hanem inkább olyanok, amivel a válaszokat könnyebben dekódolhatjuk. Tehát lássunk néhány konkrét szót, és azok jelentését az IT-sok szótárából! 

1. Bug = valami nem jó, nyugodj bele!

A bug egy hiba a szoftverben, ami azért kapta a bug (=bogár) nevet, mert a régi számítógépeknél a legtöbb probléma oka az volt, hogy egy bogár elrágta a vezetékeket. Ma már persze nem ez a tipikus hiba, de a problémák okát ma is meg kell keresni, kijavítani, majd letesztelni, hogy biztosan jól működik-e minden. Vagyis a "bug" szó alapból a problémát jelenti, egy hibát a programban. Érdekes módon sokszor mégis úgy is használják, mint önmagát magyarázó szó:

2. Business Analyst = aki jó esetben meg is akarja érteni, amit mondunk

A jól működő kommunikációhoz elengedhetetlen, hogy ne csak képes legyen valaki megérteni, amit a másik mond, hanem akarja is azt megérteni. Ez az IT esetében a BA (Business Analyst) szerepkör. Manapság a nagyobb vállalatok őket alkalmazzák mediátorként az üzlet (megrendelő) és az IT között. Vagyis ők azok a szereplők a kommunikációban, akik nemcsak hogy képesek megérteni mindkét oldalt, de meg is akarják találni a közös hangot. Legalábbis ideális esetben, mert azért a BA-k legtöbbször inkább az IT-hoz húznak, nem a mediátor szerephez.

3. By design = ezt így kérték, most már késő változtatni!

Ha megkérdezzük, hogy egy programban mi miért működik éppen úgy, ahogy szerintünk kellene, akkor gyakran érkezhet a "By design" válasz. Ez annyit jelent, hogy a programozó véleménye szerint így kérte a megrendelő, vagyis ha nem jó így, akkor nem a fejlesztő a hibás, hanem az, aki ezt így rendelte meg. További lépéseknek helye nincs, el kell fogadnunk a helyzetet, a szoftver így marad. Talán csak egy megoldás lehet: elolvasni a dokumentum leírást (specifikációt), hogy biztosan úgy kértük vagy sem. Ezt azonban nem teszi meg soha a user, inkább belenyugszik a megváltoztathatatlanba.

4. CR (change request) - nem figyeltél, fizesd ki, és legközelebb majd olvasd el a specit!

Egy program a specifikáció alapján készül el, amely minden kívánt folyamat leírását tartalmazza. Miután a dokumentum véglegesítésre került (vagyis a megrendelő elfogadta), már nem módosítható. Vagy ha nagyon kell, akkor természetesen van az a pénz, amennyiért lehet módosításokat eszközölni. Ennek megkérése a CR, vagyis a változtatás kérés. Költséges hobbi, ami lényegesen kevesebb kiadást okozna, ha a megrendelő elolvasta volna részletesen a specifikációt.

5. Folyamatban van = senki nem nyúlt még a feladathoz, és ha nem kérdezel rá sokszor, akkor nem is fog!

Ha megkérdezel egy IT-st, hogy hol tart az általad kért dolog, és arra azt válaszolja, hogy "Folyamatban van", akkor azt nyugodtan értsd úgy, hogy még senki sem csinált vele semmit. A munka még el sem kezdődött. Az ilyen típusú kérdések és válaszok könnyen végtelen ciklust alkothatnak, amiben az nyer, aki tovább bírja. Ha elég kitartó vagy, előbb-utóbb még az is lehet, hogy a problémád megoldódik!

6. Speci (specifikáció) = a megrendelő szemében NEM elolvasandónak minősülő dokumentum, így ez a legtöbb probléma forrása

Egy szoftver általában egy részletes egyeztetés alapján készül el, ami a megrendelő végleges kéréseit tartalmazza. A megbeszélteket részletesen leírják egy dokumentumban (specifikáció), benne folyamatokat és képernyőket egyaránt találhatunk. Minden szuperül működne, HA alaposan elolvasná mindkét fél, főleg a megrendelő. De inkább csak a programozók lapozgatják, hiszen ez alapján tervezik meg, majd kivitelezik a szoftvert. 

A specifikáció alapján egy használatot segítő kézikönyv (Manual) is készül, ennek olvasottsága szintén nulla közeli. Az erre való emlékeztetésre alkalmazzák az informatikusok a RFM (Read the f...ing manual) vagy szebbre fordítva a "Könyörgöm, olvasd el a kézikönyvet!" üzenet is. Valóban sok kérdésre megtalálnánk benne a választ, de mivel lényegesen hosszabb, mint egy online chat üzenet, ezért ez nem történik meg.

7. User = ember, középvezetői szint alatt

Az IT-sok a kommunikációjukban valós neveket leginkább csak a felső vezetők esetében használnak. Ezen nem kell megsértődni, mivel a jelenség főleg azon alapszik (az empátia helyenkénti hiányán túl), hogy az informatikusok a rendszerek és az abban működő folyamatok oldaláról közelítik meg a problémákat. Ennek megfelelően ami egy ember problémája, az sokaké lehet. Tehát általánosítanak. A szemükben egy átlag ember nem egy személyiség, pláne nem egy érző lény, hanem egy felhasználó, így a szót nem kell negatívnak értékelnünk.

Ellentétben az 1 bites user és az egység sugarú user szavakkal, mert ott már ne dilemmázzunk, azokat nyugodtan vegyük erősen degradáló kifejezéseknek.

8. Work around = az IT ragtapasz

Egy hibát több módon is meg lehet oldani: szépen, alaposan, stabilan - vagy tehetünk rá egy ragtapaszt, és máris elrejtettük a problémát. Ugyanígy az IT-ban is sokszor alkalmaznak tüneti kezeléseket, kerülő megoldásokat (work around-okat). A tervek (értsd: a naiv álmok) szerint ezek addig maradnak, amíg a végleges javítás meg nem történik. A work around-ok általában kevésbé stabil megoldások, szakmailag sem ezek a legjobbak, de ideig-óráig megoldják a problémát. És ebből van a legtöbb probléma is: az áthidaló, ideiglenes megoldásként induló módosítások állandóvá válnak, és a végleges, stabil megoldások ideje nem köszönt be. Valahogy úgy képzeljük el ezeket, mint a '60as évek panelépítkezéseit. A terv az volt, hogy átmenetileg megoldják velük a lakhatási gondokat, és 2-3 évtized múlva eltűnnek a városképről. De nem így lett, hanem velünk maradtak, ahogy a work-around-ok is.

ÍGY KOMMUNIKÁLJUNK!

Most már pár szót pontosabban értünk, amelyekkel az IT válaszokban találkozhatunk. De nézzük meg azt is, hogy nekünk mi mentén érdemes kommunikálni, ha IT-sokkal beszélünk és szeretnénk náluk célt érni. Fontos, hogy a leggyakrabban használt kommunikációs elemeink kerülnek itt felsorolásra, amiktől a legnehezebb lesz megválnunk!

1. Feltételes mód - KERÜLENDŐ!

A magyar nyelvben a feltételes módot gyakran használja az átlagember arra, hogy udvariasabb legyen tőle egy felszólítás. Például: ki tudnád nyitni az ajtót? A kérdés nyilván nem arra vonatkozik, hogy képes-e erre az illető, hanem ez igazából egy felszólítás arra, hogy a másik nyissa ki az ajtót. Ezt a formulát azonban nyugodtan elfelejthetjük, ha egy klasszikus IT-stól szeretnénk kérni valamit. Tőlük ugyanis a következő válasz fog érkezni: "Igen, ki tudnám nyitni". De tett nem fogja követni a szavakat. Éppen ezért azt se kérdezzük meg tőlük, hogy valami lehetséges-e / megoldható-e, mert arra is csak annyi választ fogunk kapni, hogy igen vagy nem. Talán az elején nehéz lesz, de ilyenkor gondoljunk mindig arra, hogy ők 6 kenyeret hoznának a boltból!

2. Mit javasolsz? kérdés - KERÜLENDŐ!

Felejtsd el a "Mit javasolsz?" kérdést! Egy programozó általában egészen máshogy kreatív, mint egy marketinges. Nem akar ötletelni, hanem meg akarja érteni, hogy mi is az ő feladata. Képzeljük el őket úgy, mint egy tolmácsot, fordítót: ők sem akarnak ötletelni a lefordítandó anyagról, hanem pontosan meg akarják azt érteni, hogy utána minél pontosabban átültessék azt egy másik nyelvre. Ez a nyelv pedig a tolmácsok esetében egy beszélt változat, az informatikusoknál pedig egy kód nyelve. A hozzáállás ugyanaz mindegyik oldalon: lefordítani akarják, nem jobbá tenni.

3. Felesleges körmondat - KERÜLENDŐ!

A tolmács analógiánál maradva érdemes kerülni a körmondatokat, és különösen érdemes kerülni a saját tapasztalatot. Ne feledjük, hogy a másik fél a pontos működést szeretné megérteni, és minden más infó (milyen tapasztalataink vannak, mi hogy élünk meg dolgokat) kerülendő. Ezek nem vezetnek a célhoz, inkább csak elveszik az időt és nehezítik a megértést, mert elterelik a figyelmet a lényegről.

4. Kitalálni, hogy mi kis változtatás és mi nagy - KERÜLENDŐ!

A nullák és egyesek világában nem minden úgy működik, ahogy azt a magunkfajta user elképzeli. Lehet, hogy nekünk minimális változtatásnak tűnik, hogy valaminek a sorrendjét megváltoztatjuk, de nem látjuk azt, hogy mindez a szoftverben miket okozhat. Tehát ne találjuk ki előre, hogy mi kis változás és mi nagy, csak mondjuk el, hogy mit szeretnénk!

Tipikus példák:

"Csak egy check box kellene gyorsan, megvárom!"

"Semmit nem érint, csak pár sorral kerüljön ez a rész feljebb!"

Végül íme néhány tanács, amit soha ne feledjünk, ha szeretnénk elkerülni a felesleges köröket az IT-val való egyeztetések során:

Tudnunk kell, hogy mit akarunk!

Fogalmazzunk pontosan, és hogy ezt megtehessük, készüljünk fel az egyeztetésekre! Vagyis tudnunk kell, hogy mit akarunk. Ne dilemmákkal és álmokkal érkezzünk egy IT-s megbeszélésre, hanem konkrét elképzelésekkel.

Ügyfélélmény másképp!

Az IT-sok szolgáltatnak, de nem úgy, ahogy mi gondoljuk. Mi, egyszerű userek már megszokhattuk, hogy más szolgáltatóknál nagy hangsúlyt helyeznek az ügyfélélményre. Vagyis arra, hogy a kiszolgálásunk közben érezzük jól magunkat, és alapvetően törődjenek velünk, mint emberrel. Ez az ügyfélélmény alapú szolgáltatás általában nincs jelen az IT kommunikációban, ezért ne is keressük. Nem véletlen, hogy nem az IT-sok a klasszikus értékesítők, és jellemzően nem is a tapintat mintapéldányai. Emlékezzünk vissza, hogy az ember szóra a user kifejezést alkalmazzák! Az ügyfélélményt inkább a produktumban keressünk, és a végeredmény minőségét tekintsük ebben az esetben az ügyfélélmény mértékegységének.

Nekünk, usereknek pedig a XXI. században élve két lehetőségünk van: vagy a programnyelveket tanuljuk meg, és készítjük mi magunk a szoftvereket, vagy ha ez nem megy, akkor azok nyelvét kell megtanulnunk, akik már most képesek erre. Mert bizony nem lesz mindegy, hogy hogyan értik azt, amit mondunk nekik, vagy amire megkérjük őket.

Ha tehát azt akarjuk, hogy 1 kenyeret és 6 tojást hozzanak, akkor mondjunk azt: "Kérlek, menj el a boltba, vegyél 1 kenyeret, és vegyél 6 tojást is!" Remélem, hogy nem csak Húsvétkor fogunk jól járni a most tanultakkal! :-)