Munkám során gyakorta kerülök kapcsolatba "laikus" illetve képzettebb felhasználókkal is. E cikkben a két csoporttal történő konfrontációkról és azok orvoslásáról írok. Noha e cikk informatikai, mégis azt gondolom, hogy egy sor teljesen más fajta szolgáltató ágazat problémája is egyben. Az alábbiakhoz hasonló helyzetek csupán a fantázia művei lehetnek... Írnám, ha filmet rendeznék erről, hogy meg ne sértsek valakit. Pedig a szándékom a segítés és nem a sértegetés.

Az egész problémakör a szükségletből ered. Valakinek kell bizonyos szolgáltatás, tudás és/vagy eszköz, és egy másvalaki (ez lenne az informatikus) tudja szállítani az igényelt dolgokat. Neki viszont arra az ellenszolgáltatásra van szüksége, amivel a megrendelő rendelkezik. Az ellenszolgáltatás az esetek kilencven százalékában pénz. A két fél közti viszony nem alá-fölérendelt, hanem mellérendelt még ha néha igyekeznek is figyelmen kívül hagyni ezt a tényt. Üzleti partneri, és nem főnök-beosztotti a viszony.

Az alábbiakban gyakori eseteket írok le, majd az azokban rejlő félreértéseket és végül az orvoslását, illetve a kudarc elkerülésének módját.

>>>

A megrendelő szeretne informatikai fejlesztésbe vágni (hardver, vagy szoftver, az most mindegy). Kihangsúlyozza, hogy Ő ugyan nem ért hozzá (ezért kéri a segítséget) de valami jót szeretne gyorsan és olcsón. Szakemberünk időt áldozva rá végighallgatja az óhajt, majd nekilát a lehető legjobb megoldás megtalálásának. Ez idő, tehát pénz jár érte... Ha egy boltba bemegyek és érdeklődöm az eladótól, az sincs ingyen, mert a költsége be van építve az eladott termékek árában, noha nem biztos, hogy pont én, pont akkor és ott fizetek is érte.

Egy üzletben jártam, ahol a falon egy felirat állt a következő szöveggel:

"Jót, gyorsan és olcsón? Ön e háromból csupán kettőt választhat!"

Milyen igaz! És e bölcsességet nem említi a megrendelések többségénél senki. Így hát a jó szándékú (mert vannak rossz szándékúak is) szakember nekilát és kiizzad egy javaslatot az ügyfélnek. Olcsót, jót és gyorsat... :-) Ez már eleve munka, noha az ügyfelek gyakran azt hiszik, merő szívesség... Aztán megrendelik a remek terméket, szolgáltatást vagy egyebet. Szakemberünk nekilát, hogy kielégítse az igényeket. Ügyfelünk még mindig abban a hiszemben vesztegel, hogy ez teljesen ingyenes, merő szeretetből ered csupán a boltban sorban állás, a termék hazacipelése, összerakása, beüzemelése, telepítése és végül a helyszínre szállítása.

Ennél a pontnál álljunk meg kicsit és elemezzük ki, a kialakult helyzetet! Gyakran az informatikus szakemberek a felelősek a feni problémákért. Azt a hitet gerjesztik (az ügyfél minden áron történő megtartása érdekében), hogy a jó a gyors és olcsó hármasa létezik.

Aztán ott is hibáznak, hogy nem ismertetik a megrendelővel a termék vagy szolgáltatás leszállítása előtti teendők mennyiségét és (korrekt) árát.

>>>

Menjünk tovább!

Megérkezik a helyszínre a várva várt termék és/vagy szolgáltatás. Beüzemelés, feltelepítés. Csillog villog minden. Az ügyfél azt látja, hogy a megrendelt dolog használata eléggé egyszerű, hiszen az informatikus is csak ripsz-ropsz kezeli és tényleg milyen egyszerű... Kisimulnak az idegek (mindkét részről), megtörténik a fizetés.

Szakemberünk megnyugodva eltávozik és a vevő boldogan birtokba veszi tulajdonát. Hiszen egyszerű, látta ő is... Csak nyomogatni kell.

Másnap reggel aztán felháborodással vegyes elkeseredéssel a szívében felhívja szakemberünket. Dühösen közli: NEM MŰKÖDIK!!! Szakemberünk (védendő a mundér becsületét) lóhalálában a helyszínre siet. Ekkor két eset történhet általában.

  • Kiderül, hogy a vevő egyszerűen csak nem tudta használni a dolgot, amit megvett
  • Kiderül, hogy tudatlanságból eredően tönkre is tette (ideiglenesen, vagy végleg) a vásárolt dolgot

Ennél a pontnál ismét álljunk meg és elemezzünk!

Az egyik hibát a vevő követte el. Azt gondolta, hogy a vásárláskor tudást is vett... Hiszen "olyan sokba került"... Ennyi pénzért már tudnia kellene gondolatokat is olvasni annak a valaminek...!

Ez ahhoz hasonló, mint ha valaki venne egy autót, aztán érvényes vezetői engedély és megfelelő tudás hiányában rögtön, kihajtva a kereskedőtől kidöntene egy oszlopot. Ezután pedig dühösen felhívná a kereskedőt (rögtön még a füstölgő autóból), hogy a vásárolt kocsi nem működik, pedig Ő egy működőképes járművet vásárolt. Micsoda pofátlanság ez a kereskedő részéről??! Azonnal javíttassa meg a kocsit a kereskedő a saját költségén, vagy megnézheti magát!!!

Az autós példán mindenki csak röhög. De a vele analóg számítógépes példán miért nem röhög senki? Mert nem vonnak párhuzamot! Pedig lehetne, csak nem egyszerűen. A felelősség eldöntése néha sokkal nehezebb, mint egy összetört autó esetén. Sokszor nem látszik, hogy mit csináltak azzal a szegény számítógéppel...

Tehát akkor van baj, ha nem érhető egykönnyen tetten, hogyan is történt a tönkremenetel... Nagyon nehéz megmagyarázni valakinek, hogy rosszul csinált valamit, ha nem ért hozzá, sőt szinte csak az érzelmei  befolyásolják (meg a "szakértő" szomszédok, akik persze mindenhez jobban értenek és nincs is semmi veszteni valójuk). Előkerül a fegyvertárból a garanciára történő hivatkozás is... Szembe kerül egy szakember, akinek igaza van és egy vevő, aki dühös. Ki tesz igazságot?

Ilyenkor segíthet, ha az Interneten (ha elérhető valamilyen módon) megmutatunk hasonló esetekkel foglalkozó oldalakat. Ilyenkor nem mi olvassuk a fejére ügyfelünknek a problémákat, hanem megteszi helyettünk ezt a jól kiválasztott oldal. Meg aztán az adott helyzetben talán nagyobb tekintélye is van az internetnek, mint a bajba került szakembernek. Egyet biztosan nem szabad csinálni. Lelépni és végleg magára hagyni az ügyfelet a problémával!

>>>

Végül a szakember belefáradva a viaskodásba nekilát kijavítani a hibát. Ilyenkor némileg lecsillapodnak a kedélyek, de még érezni a feszültséget a levegőben...

Sajnos nem úszható meg, hogy valami minimális "gyorstalpalóban" részesítsük ügyfelünket. El kell mondani neki, hogy mit csinálhat és mi az, amit biztosan nem szabad megtennie!

>>>

Eladott "gyári" szoftver esetén szokott gondot jelenteni, hogy az ügyfél nehezen érti meg, miért nem tudjuk a program esetleges hibáját mi magunk javítani és pláne nem azonnal. Ilyenkor én azt szoktam szemléltető példaként mondani, hogy ez olyan lenne, mintha egy autó tönkrement motorját kizárólag csak a műszerfalon található műszerekkel, kezelőszervekkel szabadna próbálnom megjavítani. Egyértelmű, hogy lehetetlen. A program felülete csupán műszerfal. De a motor, a lefordított forráskód elérhetetlen, kivéve az ingyenes "GNU" szoftverek esetén. De a hibát ott sem egyszerű orvosolni.

Ilyenkor marad a telefonálgatás, levelezgetés a gyártóval, ügyfélszolgálattal, "support-tal" amit jobb, ha mi végzünk és nem az ügyfélre bízunk...!

>>>

Az elvégzett fáradozás időt vett igénybe, amiért pénz járna. Pénzt viszont csak akkor lehet kérni, ha az ügyfél belátta, a szakember és a termék vétlen...

Nekem is volt hasonló helyzet, amiben nem futamodtam meg. Vért izzadva kikecmeregtem a helyzetből és utána sok évig tartó gyümölcsöző üzleti kapcsolat vette kezdetét. Évek múltán már csak nevettünk az egészen.

De az ügyfelem IQ-ja eléggé magas volt ahhoz, hogy idővel reálisan felmérje a történteket.

>>>

Úgy gondolom, nem csak az ügyfélnek van joga minőségi szolgáltatáshoz, hanem a szolgáltatónak is joga van minőségi ügyfélhez. Elvégre (mint már írtam) partneri a viszony...

Az sem biztos, hogy minden áron ragaszkodni kell egy ügyfélhez. Ezt a pillanatnyi józan megítélés határozhatja meg.

>>>

Mindenképpen gondoskodjunk biztonsági tartalékról. Legyen tartalék az árképzésben, a határidő vállalásban és persze legyen mentés a rendszerről, amit átadtunk! Én például gyakran mentem le az ügyfél beállított rendszerét a gépének egy másik erre a célra elkülönített, rejtett partícióján. Így ha gond van, pár perc alatt orvosolhatom a helyzetet...

És ha kiderült, hogy mi hibáztunk, mielőbb javítsuk a hibát és próbáljuk menteni a menthetőt! Próbáljuk meg érdekeltté tenni ügyfelünket, hogy mielőbb elfelejtse a történteket egy-egy plusz (ingyenes) szolgáltatással, segítséggel!

>>>

Végül egy statisztikai adat. Míg egy elégedett ügyfél három másik ügyfelet hoz nekünk, addig egy elégedetlen hét másikat is elriaszt (amerikai felmérés eredménye, de nálunk sincs szerintem másként).

Érdemes a beüzemelés után pár nappal felhívni az ügyfelet és röviden érdeklődni, elégedett-e a szolgáltatásunkkal... Megéri!

 


A szoftverfejlesztők helyzete kissé más, mint azoké, akik számítógépeket javítanak.

Gyakori eset, hogy felkérést kap egy fejlesztő egy bizonyos szoftver elkészítésére. Nagy örömmel elmegy a megrendelőhöz és kifaggatja a feladatról. A megrendelő illetékes embere fejből (!) elkezdi mondani a kívánt funkciókat, műveleteket. A fejlesztő jegyzetel. Aztán megegyeznek egy árban és határidőben. Elindul a fejlesztés és határidőre el is készül. A fejlesztő büszkén megérkezik a megrendelőhöz, és bemutatja művét.

A fejlesztő erre elkezdi mondani, hogy ez így jó, de jobb lenne, ha barokk angyalkák is lennének a képernyő jobb felső sarkában, és noha ez raktári nyilvántartó de ő házipénztárt kezelő programot rendelt. (a példa erősen kisarkított a drámai hatás érzékeltetése céljából)

Erre a fejlesztő fejében a nyomás elkezd növekedni, szóvá teszi, hogy nem ezek lettek megbeszélve. A megrendelő pedig vitázik, hogy igenis, ő ezt mondta, vagy legalábbis ezt gondolta és nem tehet róla, hogy a fejlesztő nem ezt értette belőle. És ha nem azt kapja, amit kér, nem hajlandó fizetni...

Itt a fejlesztő részéről több hiba is történt. Elmulasztotta a megrendelővel aláíratni a frappánsan megfogalmazott írásos szerződés 1. számú mellékletét, ami tételesen felsorolja a végzendő munkákat (helyzet felmérés, rendszer szervezés, program készítés, időnkénti egyeztetés a megrendelővel), a rendszer funkcióit és a fizetés terminusait. Ugyanis hosszú fejlesztésnél ajánlatos részteljesítésre történő fizetést (esetleg előleget) beépíteni a szerződésbe.

Jó pár ilyen esetet láttam már. Sokat gondolkodtam, hogy miért történhetnek ilyenek meg. A következőket gondolom erről.

A fejlesztő örül a megrendelésnek és elfelejti, hogy ő a megrendelővel egyenrangú partner és nincs alárendeltségben. Inkább eltekint a megrendelővel való fárasztó és rázós egyeztetéstől, esetleges vitától csak, hogy megkaphassa a munkát. Így meg is kapja a munkát, csak a pénzt nem kapja esetleg meg érte a végén...

A megrendelő az esetek nagy részében nem informatikus. Így a feladatspecifikáció sem egyszerű. Gyakran a fejlesztő mondja meg a megrendelőnek, hogy az valójában mit is akar, mert még a kívánságait sem tudja egyértelműen megfogalmazni, csak esetleg zavarosan körülírja. Ez neki is megterhelő, de mindenképpen túl kell rajta esni!

A jól meghatározott feladatleírásnak van még egy előnye. A megrendelő elkezdi végiggondolni (az egyeztetés során) a feladatot és közben új ötletei képződhetnek. Hajlamos azt hinni, hogy ezek az új ötletek egy kész fejlesztésbe könnyedén beépíthetők utólag. Csak pár kattintás és kész is, mit vagyunk úgy oda? Kérdezheti...

Én ezt úgy hívom: "mozgó célpontra lövés"

Ne lőjünk mozgó célpontra, csak rögzítettre!

Erre én azt a példát szoktam mondani, hogy ha valaki rendel egy kulcsra kész házat és az el is készül, utána már nehezen tud rajta az alapokat is érintő módosításokat eszközölni. Hiába mondja, hogy ő a déli fekvés helyett inkább mégis nyugati fekvést akar... A kivitelező pofon röhögi...

>>>

Találkoztam egyszer már megrendelő részéről ingyenes (!) "próbamunka" igényével is. És akkor rendeli meg a teljes munkát, ha a próbamunkát számára megnyugtató módon végzem el. A munkát elvégeztem (nem kevés időt és fáradságot beleölve), amit be is építettek a  (brókeri teendőket ellátó) rendszerükbe, és ezek után közölték, hogy nem megfelelő a munkám. Azt akkoriban még nem értettem, hogy akkor miért került be a rendszerbe. Később tudtam meg egy másik "áldozattól" hogy már régóta így folyt a fejlesztés annál a dicső cégnél, nulla költséggel. Több  embert küldtek már el kamu indokokkal (és még senki nem verte meg őket)...

Ma már azt mondanám, hogy próbamunka? Oké, de akkor próbafizetést kérek érte... Ha nem hajlandók rá, akkor a viszont nem látásra...

We use cookies

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.