Jó dolog-e az „as is” kultúra, és van-e anyagi felelőssége a fejlesztőnek a hibás programért?
Jó dolog-e az „as is” kultúra, és van-e anyagi felelőssége a fejlesztőnek a hibás programért?
Tegyük fel, hogy egy szoftverhiba miatt leáll az értékesítési rendszer, és fél napig nem adunk el semmit. Nyilván a vásárlók egy része visszajön később, egy másik részük pedig sose jön vissza. Az üzleti kár konkrét, forintosítható, az értékesítők joggal dühöngnek a kiesett eladásokért (és nem utolsósorban a bónuszuk miatt).
A mai modern 21. századunkban a szoftverhiba már olyan univerzális magyarázat, mintha azt mondanánk, hogy elvitte a manó, vagy hogy ez volt Isten akarata. Mindenki beletörődik, nincs felelős (pont mint a politikában…). De játszunk el a gondolattal, hogy az értékesítési igazgató sarkára áll, és felelősöket akar keresni. Egyrészt mert az üzletet 20 millió forint kár érte, másrészt pedig el akarja kerülni a hasonló eseteket a jövőben.
Ki a felelős a szoftver hibáért?
Akik végigvittek pár projektet, azok most kapásból legalább 100-féle magyarázatot tudnak mondani:
- A tesztelők nem végezték elég jó munkát.
- Az értékesítők nem dolgoztak ki jó teszteseteket. (felelős az, aki kérdez J )
- Nincs hibamentes szoftver, ez tudott.
- A legutóbbi változtatások regressziós hibát okoztak.
- A szoftvert nem erre tervezték.
- Messze több adat van, mint amennyit a szoftver képes lenne kezelni.
- Túl sok változtatás igény érkezett.
- A fejlesztők nem kaptak tisztességes igény specifikációt.
- Senki nem mondta, hogy a szoftvernek ezt is tudnia kell.
- Szerver túlterhelés.
- Interfész hiba.
- Az apróbetűs részben (EULA) ott volt, hogy a szoftvert „as is” adjuk el, mindenféle felelősség nélkül
A legtöbb esetben – ha vesszük fáradtságot utánamenni a történetnek – általában valami banális apróságról van szó, amit annak idején 10 perc pluszmunkával vagy kis odafigyeléssel ki lehetett volna küszöbölni. Mármint utólag banális dolog, akkor és ott senkit sem érdekelt.
Verbálisan szkanderezik egyet az értékesítés az IT-val, aztán elsikamikáljuk a dolgot. Hiba kijavítva, többet nem fordul elő, becsszóra. Mindenki megy a dolgára, 3 nap múlva senki sem emlékszik.
De mi van, ha nem ilyen egyszerű a dolog, mert a szoftverért vagy annak fejlesztéséért az értékesítők egy IT vállalkozásnak fizettek – és most kicsit becsapva érzik magukat. Fizettek a szoftverért 100 milliót, aztán nem tudnak eladni vele.
Belekerült a szoftver 10 millióba, az okozott kár 20 millió, akkor fizet a fejlesztő 10 milliót és kvittek vagyunk - vagy hogy is van ez?
Most egy pillanatra vonatkoztassunk el a szoftvertől, és képzeljük el ugyanezt az esetet más szereplőkkel. Tegyük fel, hogy a Zöld Pardon egy fergeteges vizsgaidőszak-záró bulit szervez szombat estére, amihez elektromos felszerelést (generátor, világítás, hangtechnika) rendel a Megoldjuk Kft-től. Azonban beüzemeléskor este 6-kor az egyik generátor zárlatos lesz, és a hibát nem lehet megjavítani, csak másnapra. A Zöld Pardonban nincs áram, se fény se hang se hűtő. A buli elmarad, a tulajdonos a pulton sír, a bevétel elmaradt.
Ki a felelős ezért? Nem is kérdéses, hogy a Megoldjuk Kft. Az sem kérdéses, hogy anyagi vonzata lesz az ügynek. (Abba most nem mennék bele, hogy mennyi)
Miért más ez az ügy, mint a szoftverfejlesztés? A válasz az, hogy nem más, hanem jogilag ugyanaz. Ha elvárjuk a villanyszerelőtől, a kőművestől és a műszaki bolttól, hogy amit ad, amit csinál, azért felelősséget vállaljon, akkor a programozótól is elvárható ugyanaz. Mert a rosszul bekötött vezetékek által okozott kárért elő lehet venni a villanyszerelőt, az új lakás esetén a kivitelezőt, a rossz tv-t köteles a bolt újra cserélni. És ha a rossz vezeték egyéb kárt is okozott (pl. valaki korházba került áramütéssel), akkor a villanyszerelő bíróság előtt fog elszámolni.
Mi a különbség a szándékos károkozás és a nem észrevett hibák között? Az eredményét tekintve semmi. Ha a szoftver fejlesztő cég szándékosan rak trójai kódot a programba, vagy ha a fejlesztő rosszindulatú módon implementál a bank részére egy átutalási algoritmust (a pénz egy részét saját számlájára utalva), az bűn, amiért a felelős bűnhődjön meg.
Ha a program azért nem működik, mert valaki figyelmetlenül kódolt/tesztelt/tervezett, és ebből kár keletkezik, akkor az ugyanúgy kár, mintha az szándékos lett volna.
Az egyetlen különbség a szándékosság. Viszont a felelősség (beleértve az anyagi felelősséget is) ugyanaz mindkét esetben. Ez minden országban, minden jogrendszerben így van.
Miért kezeljük kényelmesen ezt a dolgot? Mert az IT-ban szokásos megállapodások, munkamódszerek és eljárások során ilyen-olyan mértékben az ügyfelet is bevonjuk a folyamatba, a felelősség jelentős részét áthárítva rá. Például az ügyfél jóváhagyja a tervet, az ügyfél tesztel, az ügyfél átveszi a szoftvert. Biztosan mindenki emlékszik azokra a kifejezésekre az átadás-átvételi jegyzőkönyvben, hogy „a szoftvert átvettem, ellenőriztem, megfelelőnek találtam”.
(Meg aztán mi informatikusok szeretünk csakis az informatikával foglalkozni, minden mást elfelejteni…)
Mindezen eljárások és papírozás ellenére nem szabad elfelejteni, hogy a felelősség az IT cégé. Az informatikai szolgáltatás nagy felelősséget jelent. Sokminden rajtunk múlik, amire csak akkor jön rá mindenki, amikor valami nem működik. Kis léptékben csak kellemetlenség, nagy léptékben már milliós kár.
Lehet, hogy nem minden informatikusban tudatosult, de a törvény betűje szerint felelős a szándékosan és a gondatlanságból okozott kárért. Az együttműködési szerződésekben bizony szerepel kitétel anyagi büntetésre, az okozott üzleti kárra, és annak behajtásának módjára.
Aki pedig nem hiszi, annak itt egy konkrét eset: Vége az SAP - Waste Management pereskedésnek, ahol nem kisebb név, mint a SAP próbálta eljátszani, hogy semmi köze az ügyfelénél bekövetkezett kárhoz – kevés sikerrel.
Zárszóként pedig: jó-e az „as-is” kultúra, amikor csakis úgy adunk ki mindent a kezünk közül, hogy azért nem vagyunk felelősek? A kontároknak, az alacsony szakmai színvonalon működő garázscégeknek biztos jó.
Az ügyfeleknek biztosan nem jó.
A szakma megítélésén is sokat ront.
Hát akkor?
Utolsó kommentek