HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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?

Címkék: informatika etika fejlesztés felelősség informatikus

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr575211346

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

PetiAti 2010.05.17. 13:41:16

Érdekes felvetés, hogy meddig tart egy fejlesztő (fejlesztő cég) felelőssége és részben egyet is értek a felvetésekkel. De csak részben. Ha "dobozos" termékről beszélünk, akkor szerintem is igaz az, hogy a "teljes" felelősség a szállítót illeti meg. Azt nyilván nem lehet a fejlesztőre hárítani, ha kidől a szerver az alkalmazás alól, de azt sem, ha a felhasználó véletlenül kitörölt egy adatot. Ugyanakkor az "egyedi" fejlesztéseknél már érdekesebb a kérdés. Sokszor ugyanis a fejlesztőnek nincs is módja mindent letesztelni, főleg azt a részt, ami nincs benne a specifikációban. Véleményem szerint az egyik legnagyobb felelősség a tesztelőkön van, illetve a teszt eljárást kidolgozó csapaton. Itt élek azzal az "előítélettel" hogy a fejlesztő mindent a legjobb tudása szerint követett el és úgy adta át a programot tesztelésre, hogy nem talált benne hibát. Sajnos a mai rohanásban a tesztelésre jut a legkevesebb idő.

Petya · http://susnya.hu/ 2010.05.17. 16:44:21

A független audit és minőségellenőrő szervezetek bevonása nem teremtene tisztább helyzeteket? Feltéve, hogy az ügyfél csak akkor írja alá a átvételi papírokat, amikor az auditor/minőségellenőr már azt mondja, hogy az ő részéről rendben.

Hesz Roland · http://rolandhesz.com 2010.05.17. 21:52:22

Ez az amit "The Golden Age"-nek hívtam [kis önreklám: http://fracturedbloughts.rolandhesz.com/2008/02/26/the-golden-age-of-the-software-industry/] még 2008 februárjában, amikor a Ceska Sporitelna kb. 1 millió koronát bukott egy szoftvehibán. Nekem az volt - és még mindig az - a véleményem, hogy az "as is" komoly gátja a minőségnek. Amíg az "as is" védi a fejlesztő céget, addig gondolkodás nélkül bevállalja a lehetetlent is. Ha felelőssége van, akkor nem fogja bevállalni, nem olyan rohamtempóra, nem annyi pénzért. A vevőnek ez fájhat először, de egy idő után már rászokik, hogy 1.5 év alatt 1 év alatt lesz haználható rendszere, és kevesebb fájdalommal is jár a bevezetés.

Marhefka István · http://infokukac.com 2010.05.18. 20:59:21

Szia! Előszöris: most találtam meg a blogodat. Gratulálok! Most örülök, mert én a másik oldalról vagyok, és lehetőségem van innen is megvilágítani a dolgokat. (Én vagyok a gonosz programozó, aki felelősség nélkül gyártja a sz@rát :)) Teljesen megértem az aggodalmadat. Úgy gondolom, az esetek többségében azt is jól érzed, hogy a szállító cég nem tesz meg mindent azért, hogy a szoftver hibamentes legyen. Ez két dolog miatt van: 1) A lehető leghamarabb le akarja tudni a munkát, és lezárni a projektet. (Maximalizálja a profitot a ráfordítás minimalizálásával.) Ahogy írtad: aláírattatja az ügyféllel a papírt, hogy átvette a szoftvert, amit elvileg ő maga is ellenőrzött. Persze, ilyenkor fenn szoktak tartani egy garanciális hibaidőszakot is, amin belül a szállítónak a projekt zárása után a "garanciális" hibákat ki kell javítania (amiről külön vitatkoznak, hogy hiba-e vagy sem). 2) Szoftverfejlesztőként elég lesújtó a véleményem a saját szakmámról. (Szerintem ezt az időszakot az informatika sötét korának fogják egyszer nevezni.) A legtöbb programozó nem tud programozni. Ez az igazság. Az nem programozás, hogy elkészítek valamit, ami éppen működik. A szoftverfejlesztés nálam ott kezdődik, hogy először megértem, hogyan gondolkozik az ügyfél. Elejétől kezdve egymáshoz bizalommal(!) fordulva dolgozunk, hogy _együtt_ elérjük a közös célunkat. Léteznek olyan eljárások ma már a szoftverfejlesztésben, amivel nagymértékben le lehet csökkenteni egy szoftverben jelenlévő hibák számát. Itt a refaktorálásra (refactoring), a teszt vezérelt fejlesztésre (Test Driven Development), az automatizált egység tesztekre (unit tests), ill. integrációs tesztekre gondolok. Ezekről a technikákról jó, ha a magyarországi szoftverfejlesztők egyáltalán hallottak. Túlnyomó többségük nem, vagy rosszul alkalmazza őket. Annak ellenére viszont, hogy nem vagyok jó véleménnyel a szakmámról, azt is meg kell, hogy jegyezzem, hogy sajnos jelenlegi ismereteink szerint nem lehet hibamentes szoftvert készíteni. A kockázatokat nagy mértékben lehet csökkenteni (a fent említett módszerek pl. ezt a célt szolgálják), de megszüntetni nem lehet. Ha nagyon kritikus egy rendszer (pl. egy atomreaktor vezérlőszoftverét készítjük), akkor a minőségbiztosítási eljárások nagyon költségesek lesznek. A rendszert csakis megbízható, "bevizsgált" komponensekből lehet felépíteni. Általában, azt kell mondanom, hogy ilyen szintű megoldás irreális árat produkál, és valójában ilyen szintű megoldásra nincs is szükség. (És még ez sem tudja garantálni a 100%-os megbízhatóságot.) Sajnos, egy szoftverfejlesztő cég sosem fogja tudni garantálni a szoftvere hibamentességét. Viszont ez nem jelenti azt, hogy a szoftvere nem lehet minőségi! Az a gond, hogy a mai beszerzések során a szoftverfejlesztési módszertanok szerepe nem eléggé hangsúlyos. Azt gondolják, ha jó sok pénzt költenek független minőségbiztosítóra, akkor biztos jó szoftver is lesz az eredmény. Sajnos, ez nem így van. A minőségbiztosítás a tapasztalataim szerint csak papírozást jelent. Hogy mi a megoldás? A jogi lépések, az (ál)minőségbiztosítás nem eredményez minőségi szoftvert. Amit lehet tenni, hogy találni kell egy jó szoftverfejlesztő céget, akiben meg lehet bízni. Mintha az otthoni lakásfelújításhoz egy jó mesterembert keresnél. István

Csépányi-Fürjes László 2010.05.25. 12:03:31

Hello! A cikked sajnos sületlenséget állít. Egy generátor bonyolultságát nem lehet egy szoftverhez hasonlítani. Mindamellett a fejlesztő természetesen felelős a munkájáért, de nem ebben a vonatkozásban. A minőségi szoftverfejlesztésért elsősorban a management a felelős. Üdv, Csépányi-Fürjes László

Ismeretlen_102125 2010.05.25. 12:26:56

Kedves Csépányi-Fürjes László, A felelősségnek nincs köze se a bonyolultsághoz, se a menedzsmenthez. Ha megírsz egy szoftvert, és utána a szoftver hibás működéséből fakadóan valakit kár ér, akkor Isten és törvény előtt felelős vagy. Tessék megkérdezni a jogászod. Üdv akocsis

Janoszen · http://janoszen.hu 2010.07.07. 12:14:04

Kérdés az, hogy vajon a megrendelők halandóak lennének-e egy weboldal elkészítéséért ötször annyit fizetni? A nagyvállalati szoftveres körökben vannak úgynevezett elfogadási tesztek amiknek a szoftvernek meg kell felelnie ahhoz hogy egyáltalán átvegye a megrendelő. Természetesen ez a megrendelő oldaláról is munkát kíván hiszen specifikálnia kell azt, hogy mit is szeretne tulajdonképpen. Addig amíg a megrendelő erre nem képes, nincs acceptance teszt, nincs szigorú követelmény hogy "mit bír" a rendszer ergó nincs mire garanciát vállalni. A dolog másik oldala az, hogy pontosan ezért szeretnek a cégek utóbbi időben nem terméket eladni hanem support szerződéseket kötni (lásd Linux) mert akkor folyamatos anyagi fedezete van a hibajavításnak, tovább fejlesztésnek.

Ismeretlen_102125 2010.07.07. 14:14:02

Ha nincs specifikáció és nincs acceptance teszt, az nem azt jelenti, hogy nincs garancia. Hanem ez azt jelenti, hogy bármikor bármi megtörténhet, és vagy sikerül megmagyarázni vagy nem. Jó eséllyel a becsületes IT beszállító jár rosszul... vagy azért mert hibákat javítgat, vagy azért mert összeveszik az ügyféllel. Igazad van a SaaS modellel kapcsolatban. Mi ügyfél vagyunk, és nekünk is jobb szoftver bérelni: nincsenek viták a garanciáról.

ibub · http://ibub.hu 2012.07.13. 16:26:22

"független audit és minőségellenőrő szervezetek bevonása nem teremtene tisztább helyzeteket?" nem, a fejlesztési folyamat talán javul, de bugtalan szoftver nincsen, így ez önmagában semmire sem jó. "Ha megírsz egy szoftvert, és utána a szoftver hibás működéséből fakadóan valakit kár ér, akkor Isten és törvény előtt felelős vagy." aha, meg definiáld a "hibás működést". " Egy generátor bonyolultságát nem lehet egy szoftverhez hasonlítani." persze h nem, a szoftver ezerszer összetettebb. mire a 0-1 világból Marika néni előtt megjelenik a "Árbevétel ma..." ablak, meglehetősen sok dolog és sok rétegen keresztül történik.

FacebookerPro · http://hackerkepzes.hu/blog/facebook-feltores/ 2012.11.25. 23:36:05

véleményem szerint azért valamilyen szintű felelősséggel azért mégis csak tartozik a munkájáért
süti beállítások módosítása