Az AgileHungary november 11-i rendezvényének egyik témafelvetése arról szól, amikor az IT szolgáltató cég kívülről próbálja megváltoztatni az ügyfélnél lévő cégkultúrát. Ehhez kapcsolódóan arról írnék, hogy szabad-e, lehet-e az ügyfelet (ki)oktatni, vezet-e ez bárhová?

Az AgileHungary november 11-i rendezvényének egyik témafelvetése arról szól, amikor az IT szolgáltató cég kívülről próbálja megváltoztatni az ügyfélnél lévő cégkultúrát. Ehhez kapcsolódóan arról írnék, hogy szabad-e, lehet-e az ügyfelet (ki)oktatni, vezet-e ez bárhová?

Igazából az agilitáshoz csak kis mértékben kapcsolódik az ügyfél nevelése. Azon a ponton, hogy az agilis szoftverfejlesztésben hívő programozók a projekt elindítása után (vagy még előtte) elkezdenének belecsapni a lecsóba, és önhatalmúlag agilizálni az ügyfelet. Nyilván a programozók véleménye az, hogy a számukra leghatékonyabb módszereket szeretnék alkalmazni, és az majd biztosan jó lesz az ügyfélnek is – elvégre őt a kész szoftver érdekli.

A másik oldalról viszont az ügyfél oldalon már létezik egy cégkultúra, esetleg konkrét IT-s folyamatok és előírások is vannak. Ugye a klasszikus szituáció szerint az ügyfél egy multi a maga kiforrott és globális működési környezetével, amit a frissen belecsöppent néhány ifjú titán szeretne fenekestől felforgatni. És nekifognak az ügyfelet nevelni…

Persze nem csak ez az egyetlen szituáció, ahol a kis IT cég a nagy multit szeretné kioktatni. Ott vannak a programfejlesztő guruk, akiknek a kisujjában van az egész. Aztán ott vannak azok a cégvezetők/menedzserek, akik csak egy módon tudják elképzelni a projektet: ha ők diktálnak.

Ugyebár az IT-vel foglalkozó kkv ért az IT-hoz – pontosan ezért kötöttek vele megállapodást. A multis ügyfelet tipikusan az IT-hoz kevéssé értő üzleti szakértő/szponzor/Product Owner és a még kevéssé értő beszerzés fogja képviselni. Szakértők vs laikusok meccs.

Az ember naivan azt gondolná, hogy egy kis oktatás segít, ha jobban értenek a szoftverfejlesztéshez akkor jobban megtalálnánk a közös hangot. Ezzel a szándékkal alapvetően semmi gond, csakhogy:
- Az ügyfél nem akar informatikussá avanzsálni. Pont azért hívta a vállalkozót, mert ő nem akar vele foglalkozni.
- Az ügyfélnek megvan a maga elképzelése és módszertana a saját munkára – amit nem fog a programozók kedvéért megváltoztatni.
- A programozók – mint kívülről jövő emberek – nem látják át a nagyvállalat belső működését, a folyamatokat és elvárásokat, a dzsungelharcot és kapcsolati hálókat. A tanácsuk körülbelül annyira lesz releváns, mint a szerencsesütiből nyert bölcsesség.

A legrosszabb pedig az, hogy maga az elgondolás („változtassuk meg az ügyfelet”, „neveljük az ügyfelet”) abból a feltételezésből indul ki, hogy mi vagyunk a tökéletes tudás letéteményesei, miközben az ügyfél egy szerencsétlen pancser. Illetve szerencsés pancser, hiszen belénk botlott.

És itt egy pillanatra álljunk meg, és gondoljuk végig, hogyan és miért kerültek a programozók az ügyfél közelébe! Azért kerültek oda, mert írni kell egy programot vagy egy új funkciót. Ebben az lesz a legnagyobb kihívás, hogy az ügyfél oldali szakértő/kulcsfelhasználó pontosan elmondja, mire van szüksége, és az ő fejében meglévő képet az elvárásokról valahogyan beletöltsük a fejlesztőkébe.
Ez csakis akkor tud sikerülni, ha a fejlesztők figyelnek az ügyfélre, és tényként elfogadják amit ő mond.
Ha a fejlesztők nem figyelnek az ügyfélre, akkor bármilyen jól is programoznak, az elkészült program nem lesz jó a felhasználóknak, a projekt csúszni fog vagy megbukik.

Márpedig ha a fejlesztők meg akarják nevelni az ügyfelet, akkor ugyebár feltételezik róla, hogy buta pancser, amit mond az tévedésen alapul – pontosan azért akarják megnevelni, hogy ezeket a tévedéseket kijavítsák és jó útra tereljék az ügyfelet.
Ugyebár a követelmény specifikáció egyirányú kommunikáció: ügyfél -> programozók.
Az oktatás szintén egyirányú kommunikáció, csak pont fordított irányú: programozók -> ügyfél
(itt most a kommunikáció irányáról van szó, nem a programozók és a felhasználók közvetlen kapcsolatáról)

Tehát aki szoftvert fejleszt és közben kioktatja a kulcsfelhasználókat, az ott biztosan egy kommunikációs hiba, ami nagyon csúnyán meg tudja magát bosszulni.

Például azon nagyon egyszerű módon, hogy az ügyfélnek/kulcsfelhasználóknak nem fog tetszeni a kioktatás. Nekik megoldás kell, nem lecke. Megromlik a viszony, megkérdőjeleződik a vállalkozó hitelessége. Aki viszont úgy fogja értelmezni a helyzetet, hogy az ügyfél nem értette meg az oktatást, és még erősebben próbálkozik… amivel még jobban romlik a helyzet, egészen a kirúgódásig.

Nem elfelejteni: az ügyfélnek jogában áll butának lennie, hiszen mindig igaza van!

Néha előfordul az az érdekes spin-off, hogy a projektben váratlanul felbukkan egy informatikus az ügyfél oldalon, hirtelen kiderül, hogy a messiás szerepben tündöklő külső informatikai cég a nemes közművelés mellett elhanyagolta a szakmai nívót… „hoppá” pillanatok…

Saját tapasztalatok: eddig két olyan partnerrel találkoztam, aki megmondta, hogyan végezzem a munkámat… ma egyikük sem a partnerünk J

Mit tanácsolnék azoknak az informatikusoknak, akik a fenti szituációba csöppennek, azaz gyenge az ügyfél oldal, és úgy érzik oktatni kell, forradalmat kell kirobbantani?

Először is mélyen magunkba/tükörbe kell nézni. Könnyű az ügyfelet kritizálni, könnyű más szemében a szálkát meglátni. Előbb 10-szeresen is ellenőrizzük a saját munkánkat, mielőtt másra ujjal mutogatnánk!

Ha az ügyfél oldal gáz, akkor sem szabad elfelejteni, hogy eredményeket kell letenni az asztalra. Az én olvasatomban a guru nem az, aki tanít, hanem aki hozza a kész, működő szoftvert a nehézségek ellenére is.

Ha maga a teljesítés van veszélyben az ügyfél oldal gyengesége miatt, akkor nyilván el kell gondolkodni, hogyan lehet az ügyfelet segíteni anélkül, hogy abból konfrontáció legyen. De ez a kérdés már nem az informatika, hanem a projekt menedzsment körébe tartozik. (Például eleve beárazzuk az ügyfélkockázatot a projekt elején.)

Update:
Hogyan lehet  jól oktatni az ügyfelet? Akkor, ha ezt ő akarja. A változás csak akkor lehet sikeres, ha belülről fakad, és fentről támogtják. Alulról vagy kívülről nem lehet megváltoztatni semmit.
Tehát a helyes út az, amikor a menedzsment kifejezett kérésére jön egy tanácsadó, és a megfelelő módon hozzányúl a cégkultúrához.

A tanácsadó ért hozzá - a programozók nem.