A legnagyobb jószándék mellett

Ezt olvastam:

"...olyan gyorsan kell a weboldalakat és a vállalati alkalmazásokat fejleszteni, hogy se idő, se energia nem jut a tesztelésre, optimalizálásra. ... Olyan gyorsan kell a vállalatoknak a piaci igényekre reagálniuk, hogy a legnagyobb jó szándék mellett sincs idő a fejlesztés és a tesztelés iteratív folyamatát végigvinni. Önmagában már ez is nagy baj, ám ha hozzávesszük, hogy az új alkalmazást vagy funkciót a már meglévő környezetbe kell illeszteni és ez egyre összetettebb architektúrát eredményez, megmagyarázza az informatikai rendszerek minőségromlását."

/terminal.hu/

Olyan gyorsan...  milyen gyorsan? Mi az, hogy "nincs idő"? Jómagam is végigcsináltam pár IT-projektet, jót és rosszat is, idő az van, csak jól kell kihasználni. Az ilyen vállalatoknál talán inkább módszer nincs. Módszer arra, hogy

• megegyezzünk, ki, mit és meddig kell, hogy befejezzen, beleértve a dokumentációkészítést és a tesztelést is (ezek szoktak leginkább elmaradni...)
• kialakítsunk egy olyan projektkövetési módszert, amivel mindig tudjuk, minek a fejlesztése hol tart (kanban pl., van ilyen, érdemes rákeresgélni a neten), így rögtön látjuk, ha valamivel nem állunk jól.

Többek között. Egyre inkább azt vallom, hogy mi is hibásak vagyunk, mi, projektekben dolgozó szakemberek. Azért vagyunk hibásak, mert birkaként tűrjük a rossz szervezést, rossz irányítást. 

Nem kellene, azt gondolom. Mindenkinek van döntési lehetősége és hatóköre (nem hatásköre!), ha úgy döntünk, hogy bevesszük azt a lesz...rom tablettát, mi magunk is asszisztálunk mindahhoz, ami aztán a mi életünket is megkeserít(het)i...

---

Konferenciáltam

Az elmúlt héten volt az MLBKT éves kongresszusa, ahol pénteken, a Termelés szekció elkövette azt a hibát volt olyan kedves, hogy nekem is adott 30 percet lean témakörben. Az előadás sztem jól sikerült, legalábbis én ezt láttam a hallgatóság szemében, néha még nevettek is amikor vicceset mondtam :) Sőt, a végén meg is tapsoltak (bár lehet, hogy csak udvariasak voltak, vagy örültek, mert jött a kávészünet :)!!!

Egy dolgot emelnék ki, ez pedig a következő. Azt találtam mondani, hogy egyszerű mérési és számolási módszereket kell alkalmazni a gemba-n, és ennek bemutatására egy, az egyik előző előadásban látott, elég bonyolultnak tűnő kanban-számítós módszerre hívtam fel a figyelmet. Az előadó természetesen magára vette, pedig külön hangsúlyoztam, hogy ne tegye...

Én mindig azt az elvet vallottam, hogy a lean tanácsadónak nem bonyolult képletekkel, japán vagy angol kifejezésekkel teletömött beszéddel vagy drága öltönnyel és mindenféle techno-kütyüvel kell elkápráztatni az ügyfelet. A jó lean tanácsadó jó lean szakember, rendelkezik elméleti tudással, érti a lean összefüggéseit és ezeket meg is tudja tanítani, rendelkezik többéves szakmai (értsd: üzemi és/vagy irodai) tapasztalattal, azaz tud példákat mondani, ha kell. Szeret és tud a helyszínen dolgozni (ott, ahol  a dolgok történnek), nem zavarja, ha kicsit piszkos lesz. Viselkedésén pedig látszik, hogy elkötelezett a témát illetően (nem szenvtelenül olvas fel fóliákat pl.). Emellett viszont szerény, nem hiszi magáról, hogy ő aztán A Lean Guru... Nem könnyű szerep, az biztos.

Szóval nem elég sztem pl. kanban-mágusnak lenni. Tudni kell, hogy a kanban milyen problémára ad (átmeneti) választ. A kanban pont olyan eszköz, mint a többi. Ma még jó lehet, de mi lesz holnap? Félre ne értsük egymást, ha Ön éppen most vezetett be papír kártyákkal működő kanbant, az biztos sokkal jobb lesz, mint az addigi rendszer. Ön előtt áll az elektronikus kanban bevezetése, ami elkerül egy csomó rizikót (elvesztés, szakadás,...). Ha sikerül az üzemeltetése legyen rá büszke!

De feltette magának azt a kérdést, hogy MIÉRT is kell a kanban? Hogy pontosan mik azok a problémák, amiket ezzel akar megoldani? Mert ha igen és eljutott a VALÓDI okig meglátja, hogy a kanban egy fontos, de csak egy közbenső lépés a szinkronizált termelésben. Ön és az Ön tanácsadója tudja már ma, mi lesz a következő lépés holnap? Sohase feledje ui., hogy a kanban (még bonyolult képletekkel is) bevezethető bármelyik versenytársánál is...

---

Kísérletezni kellene

Érdemes lenne kipróbálni az IT területen a következőket:

TASK KANBAN BOARD
Van egy nagy fehér táblánk, falfelületünk, amit felosztunk függőlegesen 3 részre:
- elvégzendő (to do) feladatok (fejlesztés, teszt, install,..)
- már futó (doing) feladatok
- befejezett (done) feladatok

A különböző területekre színes kártyákkal (vagy post-it segítségével) jeleznénk, melyik feladattal hogy állunk. Bevezethető színkód vagy egyéb azonosító adott projektjeinkre, amivel szépen követhető a projekt státusza.

FEATURE KANBAN BOARD
A fehér tábla felosztása most vízszintesen egy idősík, az egyes beosztások ((hetek, hónapok,..) alatti kártyák pedig lezárt fejlesztéseket (feature) mutatnak. Színkódolással vagy egyéb azonosítóval elkülöníthetőek az egyes projektek, így jól látható, melyikkel hol állunk.

DAILY BURNDOWN CHART
Egyszerű grafikon, függőleges tengelyen darabszámokkal (issue, feature, task,...) a vízszintes tengelyen napok, hetek, hónapok megadásával. Ábrázolandó a terv, amilyen ütemben feladatainkat meg szeretnénk oldani (target), illetve ahogy a megoldás sikerült (actual).

NIKO-NIKO vagy SMILEY CALENDAR
Egyszerű vizualizálása munkatársaink hangulatának. Mindenki minden munkanap végén beleragasztja a saját naptárába a hangulatát jelképező smiley-ábrát. Jól mutatja a hangulat alakulását egy projekt során.

Érdemes meghatározott időszakonként a tábla előtt egy amolyan "team standup " megbeszélést tartani, azaz a tábla előtt állva mindenki elmondhatja, mivel, hol tart és miért nincs kész :) Az ilyen megbeszélésekre meg kell hívni a fejlesztések ügyfeleit is, akiknek a program készül.

Forrás: www.infoq.com

---

Mint minden módszer....

... a lean ill. annak alkalmazása nagyban függ attól a személytől, akitől tanul az ember. A lean filozófia segítségével működő vállalatok nagy része esküszik arra, hogy a kanban a logisztika eszköze a rugalmas gyártás kiszolgálásában. Én egy japán tanácsadótól egy oktatáson azt hallottam, hogy a kanban akkor kell, ha az ellátási lánc egyes elemei nagyon távol vannak egymástól (pl. beszállító-gyártó). Gyáron belül, mondta ő, nem kell kanban, mivel nincs rá ok. 

Felhívta a figyelmet arra is, hogy a kanban rendszert üzemeltetni -pl. a környezet változásai miatt- komoly ráfordítással jár, amit gyakran elfelejtenek-elhallgatnak a sikertörténetek szerzői...

ui.: Mielőtt esetleg azt mondanák, hogy biztos egy noname japán tanácsadó volt elmondanám, hogy Taiichi Ohno egyik volt munkatársáról van szó, aki gemba kaizen és lean tekintetben komoly szaktekintély.

---