Agilitás, leterheltség és tűzoltás

Bár még mindig nem vagyok az agilitás témakörének alapos ismerője, az agilis IT leírásokban újra és újra feltűnik, hogy ez a módszer erősen a felhasználó és az IT folyamatos együttműködésére épít. Sajnos itt látok egy komoly problémát.

Egyre több vállalat anyagaiban olvasok a hatékonyságról. Márpedig egy közgazda szemével egy ember akkor hatékony, ha munkaidejének nagy részében a közvetlen értékteremtéssel "van kiterhelve". Ez a "nagy rész" egyre közelít a 100%-hoz, ami szerintem óriási tévedés. Én ezt a tendenciát nagyon elszomorítónak tartom. Ellenkezik az ember alaptermészetével, rövid távú gondolkodás. Egy közel csúcsra járatott ember hamar kiég. Ez nem respect for people.

Az agilis IT az ilyen vállalatoknál komoly problémával találkozhat: nincs együttműködő felhasználó. Mert mindenkinek tele a naptárja. Értéket teremt és/vagy oltja a mindenfelé újra és újra kigyulladó tüzeket. Ki van terhelve, mert ezt kívánja a vezető. Ilyen környezetben nincs idő use caseket és mindenféle storykat megbeszélgetni az IT-vel, aztán a teszteket megtervezni, tesztelgetni, oktatásokon részt venni. Megmondja egyszer mi kell, aztán az IT hozza a megoldást, mielőbb. Persze, hogy aztán nem hozza, vagy nem azt, vagy nem mielőbb.

Kíváncsi vagyok, komolyan, hogy erre mit mondanak az agilis szakemberek. Mert szerintem egy "hagyományos" vállalatnál nem sok esélyük van. Az agilitás is egy új gondolkodásmód, amihez egy változáson keresztül kell menni, pl. a vállalatnak rendelkeznie kell egy lean programmal, aminek része a lean IT is. Ami szerintem először lean IT (belső) folyamatokat jelent, amelyek segítségével kialakulnak a máshogy (értsd: ügyfél-orientáltan) gondolkodó IT-szakemberek, akik aztán elkezdhetik kicsiben az agilis programokat, a már szintén lean gondolkodású felhasználókkal. Akik természetesen egy olyan lean vállalatnál dolgoznak, ahol már nem a 100% kiterheltség a legfőbb szempont, hanem az ügyfél-elégedettség. Az olyan ügyfél, aki elégedett a minőséggel, az átfutási idővel, a kiszolgálás udvariasságával és szakszerűségével. Ha ez úgy áll össze, hogy a munkatársak 90-95%-on pörögnek, akkor sincs probléma. Mert  nyugodtan kiindulhatunk abból, hogy a jó ötletek pont abban az 5-10%-ban születtek.

---

T. Ügyfél/T-Ügyfél

Vannak ismerőseim, akik meggyőződéses alapon nem néznek tévét. Péntek délelőtt óta mi sem nézünk, de ami történik, az alapvetően ellenkezik a meggyőződésemmel. A történet egyszerű, lejárt valami hűségidőszak, hosszabbítottunk és kértünk még pár történelmi/természetvédelmi csatornát. Az ügyintéző valahol nyomott egy vagy két rossz entert, mert sikerült minden adatunkat eltakarítani a rendszerből... A következő gyöngyszemeket szeretném megosztani Önökkel a hétvégi telefonbeszélgetéseinkből:

- A műszaki hibát felvettem. Na de milyen műszaki hibát? Ha elkúr elrontok valamit, az nem műszaki hiba! Az még az ÁSZF-ben is "adminisztrációs hiba"-ként lett meghatározva.

- A műszaki kollégákat nem nagyon érdekli a kötbér. A hibát a szerződésben szereplő 72 órán belül elhárítjuk. Ha ez így van, akkor rossz a  műszakiak célrendszere. Tessék belefoglalni a kötbéreket, meglepő hatásuk lehet! A 72 órán belül miért azt jelenti, hogy a 72. órában?

- Nem tudom kapcsolni a műszakiakat. Ejha! Másik idősíkban vannak vagy elveszett a telefonszámuk? Az igazság a "nem akarom kapcsolni" vagy a "szabály az, hogy nem kapcsolhatom". Természetesen vasárnap délután vezető beosztású személyt sem tudtak adni a call centerben.

Az az igazán elszomorító, hogy azt a tényt is csak a sokadik telefon után ismerték el, hogy az adatokat törölték. Ezt az egyik bejelentésünkben rögzítették is, én tesztképpen rákérdeztem egy nappal később, de a call centeres csak akkor ismerte el, hogy látja ezt a bejegyzést, amikor a számával együtt rákérdeztem!

A másik érdekesség, hogy az "offline", tehát a személyes ügyintézéskor megtudtuk, hogy az ügyintéző sem tud sokkal többet, mint mi. A számítógépes alkalmazás nem nagyon segít neki, hogy eltájékozódjon abban, mit jelentettünk be, erre mit csinált a központ, annak mi lett az eredménye, stb. Ami alapján korrekt tájékoztatást tudna nyújtani. Így hiába mentünk el személyesen, csak még több stresszt gyűjtöttünk be, az ügyintézőnek pedig eggyel több kudarcos ügye lett. Ez lenne a cél?

Mellékeltem a vonatkozó szolgáltatási folyamat minőségi mérőszámait. Az jó, hogy van ilyen, de érdekes a problémák jellege. A telepítéssel nincs probléma, a bejelentés után nagyon hamar kijöttek és gyorsan üzembe helyezték. Érdekük, mert +1 fizető ügyfelük lett. A gondok is ekkor kezdődnek, mert a meglevő ügyfelek bejelentéseivel nem foglalkoznak valami hatékonyan... Mert nem érdekük. Mert talán úgy tudják, hogy a magyar ember ritkán vált minőségi problémák miatt bankot, biztosítót és telekom szolgáltatót. Pedig ez lenne az egyetlen lehetőség arra, hogy valami változzon. Maguktól ezek a cégek úgysem fognak változni.

ui.: a Világegyetem rendelkezik szerencsére némi humorérzékkel. A mellékelt szórólapot ma kaptuk :D

uui: a bejelentett problémát a 80. órában sikerült megoldani egy ... szoftverfrissítéssel!!!! Amit akár a 3. órában is elindíthattak volna...

---

Agilitás

Előre bocsátom, hogy még (mindig) nem tudom pontosan, mi az, hogy agilitás, és milyen vagyok, ha agilis vagyok. Ezért szakítottam egy kis időt  a keresgélésre. Az eredmények:

Az agilis olyan jobbágy, aki nemes nőt vett feleségül, illetve a nemes anyától és nem-nemes apától származó gyermekek. (wikipedia)

Életrevaló, serény, tevékeny, mozgékony, ügyes, hatékony (idegen szavak)

Az első találat biztos nem az, amire az agilis szakma gondolt, de érdekes információnak értékeltem, ezért osztottam meg Önökkel :D

A másik már sokkal használhatóbb. Ezek szerint a lean és az agilis nagyon is közel vannak egymáshoz. Ezek szerint ha egy IT csapat veszteségmentesen (azaz standardok alapján, transzparens módon), ügyfél-orientáltan (azaz gyorsan, pontosan, jó minőségben, udvariasan), hatékonyan  dolgozik, ráadásul innovatív is, akkor  lean is és agilis is egyszerre.

A végére egy eddigiektől eltérő, de valamiért nagyon szimpatikus megközelítés:

---

Agilitás, disznók és csirkék

A múlt héten kaptam egy előadói felkérést az Agilis Szoftverfejlesztők egyesületétől, amit örömmel elfogadtam. Valamikor december elején lesz, ha lesz több információm, akkor Önökkel is megosztom, hátha mást is érdekel. Az október 14-i találkozón Dévai Zoli barátom tart előadást arról, hogy milyen problémák rejtőznek a klasszikus projektmenedzsmentben!

Mivel nem vagyok túl tájékozott agile ügyben, gondoltam kicsit körülnézek, és ekkor történt az, hogy kicsit összekevertek. Akocsis blogbejegyzésében találtam egy hivatkozást, ami alapján eljutottam egy oldalra, ami az agilitas.hu nevet viseli, de a scrumról szól... Gondoltam, megnézem, hogy mit mond a wiki, és ez tényleg kicsit segített. Például ott találtam ezt is:

A disznó és a csirke mennek az utcán. Egyszer csak a csirke megszólal: „Te, nyissunk egy éttermet!” Mire a disznó: „Jó ötlet, mi legyen a neve?” A csirke erre gondolkozik, majd azt feleli: „Nevezzük Sonkástojásnak!” A disznó erre: „Nem tetszik valahogy, mert én biztosan mindent beleadnék, te meg éppen csak hogy részt vennél benne.”

Még mondják, hogy az informatikusok nem vicces emberek :D Szóval ha minden igaz, akkor az agilitás a kulcsszó, és a scrum az csak egy módszer. Nagyszerű!

Az egyik hivatkozott oldalon találtam egy tesztet, és én rögtön kitöltöttem. Nem hazudoztam, bekattintottam a valódit! Meglepetésemre azt mondta, hogy segítségre van szükségünk, és az pont a scrum! Az Értékelés-ben olyan management bullsh tömény szöveget zúdított rám, hogy alig bírtam félrehajolni :D Jó-jó, tudom ám én, ez kell a népnek... Aztán bekattintottam a jó válaszokat és láss csodát, megint kaptam egy hosszú értékelést, amiben elismerték, hogy mekkora császár vagyok, de azért lehetek a Galaxis Ura is, mert a scrum ebben is segít! Én mindig szkeptikus vagyok ilyenkor, mert a leannel kapcsolatban is sokan állítanak ilyesmit, pedig ez sem igaz.

Ahogy a nevezett oldalak között kattintgattam egy dolog mélységesen elszomorított: nem hivatkoznak egymásra... mintha nem is léteznének. Ahogy egyébként a magyar lean társadalomban is előfordul ilyesmi... Lehet, hogy egy USA-nagyságú ország elbírja az ilyen mértékű versenyt, de egy ilyen kis ország, mint mi, nem biztos...

Egyre kíváncsibb vagyok erre a decemberi találkozóra! Már ha ezek után még meghívnak ;)

---

Never touch a running system

Nem akarok lerágott csontokat előásni, de eszembe jutott a minap a címben szereplő mondat. Egy IT-vezetőtől hallottam, de már nem emlékszem pontosan a történetre, amiben elhangzott. Az viszont biztos, hogy mire gondolt vele: ami működik, azt nem kell bántani. Miért kellene? Hiszen működik, tehát rendben van.

Az informatika világában ez megfontolandó tanács. Velem is megtörtént már, hogy csak az aktualitás kedvéért "felpeccseltem" a videokártyát a gépemben, aztán csodálkoztam, hogy nem klappol néhány program. A régi verzióval ment, az újjal nem. Hozzányúltam egy running system-hez, és elrontottam. Valami .inf vagy .exe vagy .dll nem volt kompatibilis egy vagy több másik bigyóval. Egy átlagos PC-n futó alkalmazások között számtalan kompatibilitási gond lehet, egyszer beleszaladtam egy olyan sztoriba, amikor a gépemet védő f-secure és a frissen vásárolt cisco router kezdte el gyűlölni egymást. Kiengesztelhetetlenül. Még a magyar f-secure képviselet sem tudott segíteni, de legalább azt megtudtam, hogy ez egy ismert probléma... Megoldásképpen (?) Comodo Securityre váltottam ;)

Régebbi bejegyzés körül kialakult vitát sem szeretnék újra felmelegíteni, de akocsisnak abban azért igaza van, hogy napjainkra a világot szépen beszövögető informatika kezd némileg átláthatatlanná válni, így a vállalatok és a magánszemélyek sem maradhatnak ki ebből. Persze az átláthatatlanság nem csak úgy keletkezik, azt mi magunk állítjuk elő.

Aztán csodálkozunk, amikor feléled a Skynet :D

---

Misunderstandings már megint

Kaptam egy angol nyelvű levelet az SAP-től. Az a címe, hogy "Get more out of your SAP-faster". Ilyen kérdésekkel nyit:

Do you know how to optimize your SAP processes?

Is SAP forcing you to document your processes for enterprise support?

De jó fejek! Csak az a baj, nem értek velük egyet. Nem az SAP-folyamatokat kell optimalizálni, hanem a vállalatét. Nem az SAP miatt kell folyamatainkat dokumentálni, hanem azért, hogy megértsük, hogyan és miért éppen úgy működnek. Hogy aztán optimalizálhassunk vagy alkossunk egy újat.

Végül is, nézhetem mindezt egy másik szemszögből is: lehet, hogy örülnöm kell annak, hogy vannak cégek, amelyek legalább emiatt végre nekiállnak pár fontos dolognak...

---

Kiscsoport, nagycsoport, T-csoport

Ezt írja az újság: "A tájékoztatás szerint a Magyar Telekom július 20-án adásvételi megállapodást írt alá a Daten Kontor Kft., a DK Telecom Zrt. és a DK Consulting Zrt. (DK Csoport) 100 százalékának megvásárlásáról.... A Magyar Telekom az akvizícióval tovább kívánja erősíteni pozícióját az informatikai szolgáltatások piacán."

Ha végiggondolom csak azt, ami mondjuk az elmúlt 1 évben történt a T-csoport és köztünk, akkor az jut eszembe, hogy a pozíciókat az akvizíciókon kívül talán rendes szolgáltatással is lehetne erősíteni... :D

---

Rejtett hibáink

Van itt egy régebbi hír egy spanyol IT-cégről és az általa a szoftverekbe szándékosan elrejtett hibákról. Tanulságos történet. Abból a sok mindenből, ami emiatt az eszembe jut, most csak kettőt emelnék ki:

A szándékosság persze hogy csúnya dolog, megvetjük. De ha nagyon a lelkivilágába nézünk sok szoftverproblémának, ott az a szándékosság mindenfelé.

Mert hiszen

• szándékosan nem foglalkozunk eleget a tervezéssel,
• a nincs rá időm = szándékosan mással foglalkoztam, amit fontosabbnak tartok,
• mert szándékosan nem teszteltük megfelelő módon,
• mert a nincs rá időm = szándékosan mással foglalkoztam, amit fontosabbnak tartok,
• mert szándékosan nincs rá elég pénz, mert a feléből mennyit engedsz = nem tartom én ezt olyan fontosnak, hogy ennyit adjak ki rá. Szándékosan.

A másik egy történet, amit nemrégen hallottam: tulajdonosnak valami valahol nem tetszik a gépjárműben. Elballag vele a szerelőhöz, mondja mi a szitu, igen persze mindjárt foglalkozunk vele. Tulajdonos nem ballag el, hanem visszaül a kocsiba, mert amúgy esik az eső. Megeszi a reggelijét, majd gondolja visszamegy, hátha végre sorra kerül. Ahogy észreveszik, mondják, hogy de jó, hogy jön, kész az autó, el lehet vinni...

---

Az IT és a gyártósor

Mindenkinek ajánlom akocsis cikkét, mert nagyon jól, strukturáltan összeszedte, miért nem szabad  csak azért szögeket keresni, mert az embernél van egy nagy kalapács :D

A "nálunk ezt nem lehet" gondolattal sokfelé találkozik az ember, és ennek egyik oka szerintem is az, hogy szakbarbárok nekiállnak mindent belefaragni a saját modelljeikbe, és ezt az érintettek az esetek többségében nem nagyon szeretik. Elképzelhető, hogy a siker a különbségek elfogadásán keresztül könnyebben elérhető lenne.

Néhány kiegészítés akocsis cikkéhez:

Hibák

Miközben egyetértek abban, hogy a 0-hiba nem lehet cél, legfeljebb stratégia, az azért elgondolkoztató, hogy ki venne Audit, ha azt mondanánk, hogy az autó egy bonyolult termék,  ezért olyan, hogy hibamentes autó, olyan nincs. Pedig mondhatnánk, hiszen az autó egyre nagyobb része szoftver ;) Az is igaz, hogy manapság egy szervezet saját folyamatai és azok kapcsolatai más szervezetek folyamataival már olyan bonyolultságot értek el, hogy a hiba lehetősége minden ilyen rendszerbe eleve bele van építve. Ezt erősíti, hogy a rizikókat kezelő, azokat megelőző folyamatok elég gyenge lábakon állnak, sok szervezetben szerintem nem is ismertek.

Minőségbiztosítás

Egy jó QA egyaránt foglalkozik a termék és az azt előállító folyamatok minőségével. Terméktől függetlenül. A tesztelés ennek csak egy -nagyon fontos-  része. A lean annyiban tér el a hagyományos QA-elvektől, hogy nagy mértékben foglalkozik a folyamatokba beépített minőséggel (ld. jidoka, poka-joke). Ami eddigi tapasztalataim szerint az IT területen is jól működhet.

Fejlesztési folyamat vs gyártási folyamat

Szerintem rendszeres olvasóink bármelyike bizonyíthatja, hogy a termelő cégek döntő többsége az akocsis által leírt anarchoszindikalista csapatmunka módszerével él :D

Rendszer-integráció

A gyártósoron dolgozók közül jó néhányan megtapasztalták már, hogy az, ha valami CAD-ben, 3D-ben összeszerelhető, az nem minden estben viselkedik így a való világban. Egy autó, egy motor prototípusai a szoftverekhez hasonlóan készülnek, és mi is eldobálunk pár modellt, mire kijön egy elfogadható. Gyártósoraink átépítésekor a 3P workshopokon pedig addig játszunk a karton/műanyag modellekkel, amíg nem vagyunk elégedettek az eredményekkel. Ez is egy fajta rendszer-integráció.

Életciklus

A szoftveren kívül más termékek is elavulnak, így az autók is. Néhány előbb, mások később. Az alkalmazott technológiák elavulnak, így nem lesz biztonságos az autó, sok lesz a károsanyag-kibocsátása, stb. A változtatás költségei már nagyobbak, mint amit hoznának, így egyszerűbb egy új modellt kidolgozni. Nem beszélve a design és a presztízs egyre csökkenő ciklusidejével...

Ciklusidők és veszteségek

Itt találtam némi ellentmondást, kiemelés tőlem:

"Általában azok a szoftverek stabilabbak, amiket eleve jól írtak meg, és csak kevésszer nyúltak hozzá."

"Például az igazán veszteség nélküli programozás az lenne, ha minden kódsort egyszer, és csak egyszer írnánk meg, utána pedig nem változtatnánk. Ezzel szemben bizonyos módszertanok (pl agilis vagy iteratív fejlesztés) eleve arra épít, hogy a programot többször újraírjuk menet közben, ezáltal egy jobb-stabilabb kódot hozva létre. Ez több munkát jelent, amit a kevesebb hibajavítással és változáskérelemmel nyerünk vissza."

A veszteségek elleni küzdelem egyik alapvető eleme, hogy sohasem szabad csak azért megszüntetni egy veszteséget, mert rátaláltunk. Meg kell keresni az okokat, amelyek a veszteséghez vezettek (esetünkben a minőségre törekvés, ügyfél-elégedettség), majd ezeken az okokon kell elgondolkozni.

Specifikáció

Ez szerintem szintén univerzális témakör. Vagy legalábbis annak kell lennie. A PDCA- ciklus szerintem termék- és folyamatfüggetlen A PLAN fázisban meg kel írni egy nagyon jó specifikációt, de ha ezt 100%-osra szeretnénk, akkor soha nem kezdünk el dolgozni. Én egyetértek a 80/20 szabállyal, azaz ha van egy jó 80%-osnak tűnő tervünk, akkor már neki lehet állni a munkának. A jellemző az általam megismert összes területen az, hogy a specifikáció a problémák jelentős részével nem foglalkozik. Ennek az egyik oka szerintem pont az, amit akocsis is említ, miszerint a specifikáció elkészítése önálló szakterület. Rendszerszemléletet igényel, és mintha abból egye kevesebb lenne manapság...

A végén még annyit bátorkodnék megjegyezni, hogy a szakma megtanulása szerintem is alapvető, bármilyen vezetői állásról is legyen szó, de vakon elhinni bármit, amit bármilyen szakember is mond.... én ezt nem javasolnám. Egy bizonyos szintű kételkedés, a dolgok megismerésének igénye szerintem fontos tulajdonság. Mindaddig minden, amit hallunk egy vezetői székben, ne legyen több egy véleménynél.

---

Tökéletes(ített) reakciók

Egy ügyféllel beszélgettem aki azt mondta, hogy az  ő szervezeti egységük nagyon sokat tesz a folyamatok jobbításáért, hiszen van nekik egy rakás SAP-fejlesztésük is. A gond az ezekkel a fejlesztésekkel, hogy sok közülük nem a valódi probléma megoldására készült, hanem a problémára történő minél tökéletesebb reakció érdekében.

Az igaz, hogy a problémákra adott azonnali, tűzoltó reakció is fontos, de erre szoftvereket fejleszteni az valamilyen szinten a vállalat vagyonának folyamatos elherdálása... Az azonnali megoldásokra szerintem nem szabad ekkora energiákat mozgósítani. Mivel amúgy is csak átmenetiek, hiszen a valódi megoldás lesz az, ami majd megszünteti magát a kiváltó okot.

Ami igazán elgondolkodtató, hogy az informatikai fejlesztések egy részének a valódi oka az, hogy az egyik szervezeti egység (az, amelyiknél a probléma kiderül) nem tud megállapodni egy másikkal (azzal, ahol a probléma valódi oka van), így aztán, hogy orvosolja a gondjait, egy rakás pénzért fejlesztet magának erre egy "megoldást". Amit aztán folyamatoptimalizálásnak hív, pedig nem az.

---