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

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • 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

Amikor valami nem működik, az emberek hajlamosak a számítógépre fogni. Pedig a számítógépek pontosan azt csinálják, amire be lettek programozva.

Amikor valami nem működik, az emberek hajlamosak a számítógépre fogni. Pedig a számítógépek pontosan azt csinálják, amire be lettek programozva.

Bizonyosan előfordult már mindenkivel a következő szituáció: a pénztárnál az árcédulát lehúzva a pénztárgépen nem az az ár jelenik meg, ami a polcon ki van rakva. Amikor erre a tényre felhívjuk a figyelmet, akkor valami olyan választ kapunk, hogy „biztos a számítógépben nem lett átállítva az ár”. Vagy esetleg ránk kiabálnak, hogy „a számítógép biztosan nem téved!”

Egyik esetben sem fogjuk azt hallani, hogy „bocsánat de mi hibáztunk” vagy hogy „bizonyára xy kolléga még nem állította be a jó árakat”.

A számítógép, a program bűnbakká lett. Bármit meg lehet úgy magyarázni, hogy mi nem hibáztunk semmit, de az a fránya számítógép jól elrontotta. Buta, rossz számítógép!

Ezeken jókat mosolygok, és persze nem szoktam annyiban hagyni.

A számítógép ugyanis pontosan azt és úgy csinálja, amire beprogramozták. Ha valamit rosszul csinál, akkor az csakis abból fakad, hogy
a) Rosszul írták meg a programot
b) Rossz adatokat tápláltak be

A rossz, hibás programmal kapcsolatban érdemes végiggondolni, hogy hány embernek kellett hibáznia ahhoz, hogy a hiba megtörténjen:
1) Hibázott az, aki rosszul határozta meg az igényeket
2) Aki leadta a megrendelést a rossz igényekre
3) A fejlesztő, aki látta, hogy marhaságot rendelnek tőle, de megcsinálta
4) A fejlesztő főnöke, aki hallgatott a beosztottaira, amikor azok felhívták a figyelmét a hibára
5) A tesztelők, amikor jónak találták
6) A felhasználó, aki validálta a megoldást de nem szúrta ki a hibát
7) Az összes menedzser, aki ezeket az embereket felvette és még nem rúgta ki
8) A felsővezetők és az ügyvezető igazgatók, akik engedik, hogy a cégüknél ilyesmi előforduljon

A gép az egyetlen, ami nem hibázott – csak azt csinálta, amire beprogramozták.

Lehet, hogy a 20. században a gép még „hibázott” (a bug hétköznapos tartozéka volt a szoftvernek), de azóta sokat fejlődött a minőségbiztosítás. Kevés az olyan jellegű „probléma”, ami hibás kódolásból fakad.

Manapság ha hibákat találunk az éles környezetben, az sok esetben business process issue, vagy pedig logikai hiba. Például a program nem tud kezelni egy olyan szituációt, amire az igények megfogalmazásakor senki sem gondolt. Vagy amikor a lefektetett folyamatok az emberek nem követik (csak a számítógép).

Zárszóként annyit pedig egy idézet, amit akkor szoktam mondani, amikor valaki elkezdi fejtegetni, hogy „nem lehet megcsinálni”:

„A számítógép programozható!”

Címkék: hiba minőség

A bejegyzés trackback címe:

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

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.

version · http://majic12.blog.hu 2011.06.22. 14:14:29

na ne viccelj, minden nagyobb program hajlamos az osszecsuklasra, es ez foleg a c++ miatt van , mert mar a kor picit tulhaladt rajta

Ismeretlen_102125 2011.06.22. 14:34:14

Szerintem elég kevés helyen használnak manapság c++-t, ezért nem nevezném ki bűnbaknak.

Krisztian 2011.06.22. 14:44:42

A C++ miatt? Persze :) akkor inkabb a globalis felmelegedes miatt :)

Ismeretlen_184825 2011.06.22. 17:17:29

Azért az a "fekete lista" a hibás emberekről nem teljesen egyértelmű. Gondolom azt akartad írni, hogy legalább egy, de lehet, hogy több ezek közül okoz hibát. De semmiképpen nem az összes kell egy hibához.:) Ez az egész kb. olyan, mintha azt mondanád, hogyha egy ember beteg lesz, arról csak ő tehet, hiszen az ő teste, miért nem vigyázott rá. Vannak külső hatások, együtt bekövetkezett ritka események, és ne feledkezzünk meg a számítógépek egy mumusáról sem: a bitfordulásról.:)

Ismeretlen_102125 2011.06.23. 08:56:56

@attila04: Ha a hibát hibás koncepció okozza, akkor az összes ember kell a hibához. Az a személyes tapasztalatom, hogy amikor egy szoftverfejlesztés nagyot bukik, akkor ott nem "bitfordulás" történik, hanem mindenki nagyon is tisztában van a dolgokkal - hogy valami nem stimmel - csak megalkudnak a helyzettel, reménykedve abban, hogy majd valami csoda történik. Valóban nem volt egyértelmű, a "fekete lista" úgy értendő, hogy legalább egy, de feltehetőleg több ember kell egy hibához. Például - lehet, hogy a fejlesztő "mellényúl" valaminek, de azért van ott a tesztelő, hogy ezt megtalálja - lehet, hogy az architect rosszul tervezett, de akkor majd a fejlesztők kérdőre vonják - lehet, hogy a felhasználók logikátlan igényt adnak le, de azért van a rendszerszervező, hogy visszakérdezzen Szóval lehet, hogy a problmát egyetlen ember hibája okozza, de a teljes katasztrófához kell legalább mégegy. A vezetők pedig alapból felelősek a beosztottaikért, vagyis rögtön legalább 3 ember felelősségéről beszélünk.

Viktor 2011.06.23. 09:27:37

attila04: Általánosságban szerintem is igaz, hogy az előforduló hibákért egy felső vezető is felelős, de azért persze van egy határ, amit nehéz / nem lehet átlépni, mert külső függőségek is vannak, mint pl egy bitfordulás :-), vagy egy FDIV-bug. Persze még így is lehet bug mentes, tökeletesen hibamentes szoftvert írni, csak sokba kerül, nincs, aki megfizesse vagyis nincs is szükség rá. A vezetői felelősségre konkrét eset: találkoztam olyannal, hogy egy oracle bug miatt nem magas prioritású de napi több hiba keletkezett ( amikkel foglalkozni kellett, tehát pénzbe kerültek ). A hiba megszüntetéséhez új oracle verziót kellett volna installálni, arra viszont nem volt sem erőforrás, sem megfelelő környezet. Ezért az a vezetői döntés született, hogy nem lesz új oracle verzió. Ez egyértelmű vezetői felelősség. Persze a vezető mérlegel, hogy megéri-e kijavítani a hibát vagy sem. Mert minden szervezet beáll egy minőségi szintre, amit vagy hallgatólagosan vagy kimondva elfogad az IT és az üzleti oldal is. Ha hallgatólagosan, akkor rosszabb a helyzet, mert lehetnek konfliktusok és egy rosszabb szándékú üzleti vezető kontra gyenge IT konfliktusból az IT rosszul jön ki. Ha viszont van egy nyílvános megállapodás ( mérőszámokkal, külső rendszeres auditokkal, amit röviden a vezetőség is megkap ), akkor jobban tudatosul az üzleti oldalban, hogy a minőségnek ára van. De ha nincs is ilyen kimondott megállapodás, a jó IT vezető akkor is az, aki eltalálja ezt a szintet, megérti, hogy milyen minőséget és mennyi pénzért szeretne az üzlet. Ezzel kapcsolatban jut eszembe a következő ( erre van egy matematikai modell is :-) ). Egy szoftveren alapvetően kétféle változtatás lehet. Új fejlesztés vagy karbantartás. Az új fejlesztés törvényszerűen erodálja a kódot, rontja a minőségeet, míg a karbantartás javít a minőségen. Vagyis minél többet fejlesztünk karbantartás nélkül, annál rosszabb lesz a kód. Mi következik ebből? Ha van egy ügyfelünk, aki csak fejlesztéseket végeztet és végtelen mennyiségű pénze van, akkor véges időn belül elérjük azt az állapotot, hogy használhatatlan kódunk lesz :-)

Viktor 2011.06.23. 09:45:37

"A vezetők pedig alapból felelősek a beosztottaikért, vagyis rögtön legalább 3 ember felelősségéről beszélünk." Igen, a vezetői felelősségben nem lehet vita. A vezető felelős onnantól, hogy felvette a illetőt, ha ő vette fel, azon keresztül, hogy megtartotta, odáig, hogy milyen folyamatok alapján dolgozik az illető. Mert sokszor (szinte mindig ) a folyamat az, ami lehetővé tette, hogy hiba keletkezett. Pl. ha gyenge a minőségellenőrzés ( pl. nincs is kód review ), tesztelés, specifikáció, bénák a fejlesztők ( a vezető vette őket fel, nem?? vagy miért nem rúgja ki a bénákat vagy miért nem küldi el őket képzésre??? ), vagy rossz az adminisztráció. Ez utóbbira egy jó példa, ha mondjuk a tesztelők ( már, ha ugye egyáltalán vannak :-), de ha nincsenek, akkor az szintén folyamat hiba ) levélben küldözgetik a hibákat. Aztán, ha ott elveszik egy hiba, akkor az annak a felelőssége, aki ezt a levelezős folyamatot kitalálta vagy fenntartotta és nem azon ügyködött, hogy legyen egy normális issue tracker. ( persze sokszor az ilyet rákenik a tesztelőre vagy a fejlesztőre, hogy miért nem nézik a leveleiket... muhahahaha )

Ismeretlen_184825 2011.06.23. 10:53:22

@akocsis: "mindenki nagyon is tisztában van a dolgokkal - hogy valami nem stimmel - csak megalkudnak a helyzettel, reménykedve abban, hogy majd valami csoda történik." -ez telitalálat volt.:)))) @Viktor: igen, a verzióváltás sarkallatos pontja egy ilyen ügynek, de továbbmegyek, néha még egy patch alkalmazása sem lesz jóváhagyva. Persze ez érthető, hiszen azt is tesztelni kell, csak az a baj, hogy nem haladnak párhuzamosan a dolgok, és néha egy patch tesztelése/alkalmazása hasonló erőforrásokat igényel, mint egy verzióváltás...