Lean menedzsment

A Lean szoftverprojekt-menedzsmentet tartom az egyik legizgalmasabb területnek és azt várom, hogy a jövőben ez fogja a legnagyobb hatást gyakorolni a szoftverfejlesztésekhez kapcsolódó menedzsment módszertanokra. A Lean fordítása "karcsú, hajlékony". A Lean menedzsment legismertebb képviselője és sokak szerint a feltalálója is a Toyota. Valójában a lean menedzsment alapjául szolgáló filozófiát W. Edwards Deming fektette le, akit az amerikai hadsereg küldött Japánba a népszámlálás módszertani támogatására. Deming Japánban maradt, ahol menedzsment módszerei sokkal nagyobb befogadókésszséggel találkoztak, mint az USA-ban. A Japán gazdaság eredményei igazolják zsenialitását.

A lean menedzsment hatása a minőségre

Dr Peter Middleton, 2009. Miami Lean & Kanban konferencián tartott "Lean software development:achieving better requirements" c. előadásában találtam egy rendkívül beszédes grafikont a lean termékfejlesztés minőségre és követelménymenedzsmentre gyakorolt hatásáról. A mellékelt grafikon azt mutatja, hogy mennyi változtatást kell bevezetni a Toyota, illetve az átlagos amerikai autógyárak egyes típusaiban a gyártásba állítást követően. Az eredmény meglehetősen jól mutatja, hogy a tradicionális PPP módszerek során alkalmazott előzetes követelményelemzési technikák mennyire elmaradnak a lean termékfejlesztésben alkalmazott konkurens tervezés eredményeitől. (A konkurens tervezés sok tekintetben hasonlít a "Scrum gyökerei" című bejegyzésemben írt módszerhez.)

A Lean adaptív filozófia

A Lean szoftverprojekt-menedzsmentet gyakran sorolják az agilis módszertanok közé, mások külön irányzatnak tartják, mivel a folyamatokra lényegesen nagyobb hangsúlyt fektet a hagyományosan agilisnak nevezett (XP, Scrum) módszereknél. Mindenesetre az nem megkérdőjelezhető, hogy a Lean filozófia is adaptív módszer, hiszen a tanulásra, a kommunikációra a fejlődésre és az emberekre fekteti a hangsúlyt. A téma egyik jelentős forrása Jim Womack és Daniel Jones "Lean Thinking" c. könyve. Womack és Jones a Lean gondolkodás alapelveiként a következőket fogalmazzák meg:

• Azonosítsd a termék valódi értékét (hasznát) a végfelhasználó szempontjából
• Azonosítsd azokat a lépéseket a tevékenységi láncban, melyek ezt az értéket szolgálják. Szabadítsd meg a folyamataidat minden olyan tevékenységtől és szabálytól, melyek nem szolgálják egyértelműen ennek az értéknek az előállítását. Más szóval: szűntesd meg a pazarlást!
• A megmaradt, értékteremtő folyamatokat szervezd egy integrált tevékenységi láncba, melyen keresztül a termékelőállítás folyamata gördülékenyen végighalad a végfelhasználó felé.
• A termelési folyamatot a végfelhasználói igények vezéreljék (pull system). A folyamat akkor induljon be, amikor valós vevői igény jelentkezik. Minden folyamatlépést az azt igénylő folyamat indítson.
• Törekedj a tökéletességre! A világos, igényvezérelt folyamatok legyenek átláthatóak minden résztvevő számára, akik ezáltal gyorsan felismerhetik a potenciális javítási lehetőségeket. Folyamatosan és állandóan javítsd a folyamatot!

Mivel a Lean menedzsment gyökerei a termelési folyamatokhoz kapcsolódnak el kellett telnie egy kis időnek, mire a lean alapelveket használható formában adaptálták egy teljesen más paradigmára, az egyedi szoftverfejlesztésre.

Lean Software Development

A Lean menedzsment nagyon világos, pragmatikus adaptációját tartalmazza a Mary és Tom Poppendieck által írt könyv, a Lean Software Development. A könyv alapját a szerzők azon tapasztalata szolgáltatja, amikor a 3M felvásárolta és Lean menedzsmentre állította át azt a gyárat, ahol Mary Poppendieck fejlesztőként dolgozott. A könyvben a fenti lean alapelveket némileg átstrukturálták és kiegészítették, de az alapfilozófia változatlan maradt. Az alábbiakban sorra veszem az általuk megfogalmazott alapszabályokat.

Szűntesd meg a pazarlást!

A Toyota gyártási rendszerének alapfilozófiája "a veszteség abszolút megszűntetése". Ennek módszere az értéktermelési lánc végletekig történő optimailzálása. A módszer lényege, hogy az értéktermelési láncban a vevői megrendeléstől a termék ellenértékének "begyűjtéséig" minden egyes lépést megvizsgálnak. Azokat a lépéseket, melyek nem adnak értéket ehhez a folyamathoz megszűntetik. A maradék lépések átfutási idejét pedig folyamatosan rövidítik újabb és újabb ötletek bevezetésével. Ennek a filozófiának az alappilére a valódi érték, a tevékenység valós céljának meghatározása. A veszteség két alapvető forrása: 1.) minden olyan tevékenység, ami a vevő számára nem hordoz valódi értéket; 2.) minden olyan lépés, ami a vevő számára az értékhez történő hozzájutást késlelteti.

A szoftverfejlesztés és a gyártás közötti analógiákat keresve a lean szoftverfejlesztés az alábbi tipikus veszteségforrásokat azonosította.

Gyártás	Szoftver fejlesztés
Gyártási raktárkészlet	Befejezetlen funkciók, kód : dokumentáció, ami nem kerül megvalósításra, kód ami nem kerül alkalmazásra, dokumentálátlan kód stb.
Túltermelés	Extra funkciók: minden olyan lefejlesztett, specifikált vagy megtervezet funkció, amit a felhasználók nem használnak a gyakorlatban)
Redundáns feldolgozási lépések (extra processing)	Újratanulás: minden olyan tevékenység, döntés amit már korábban elvégeztünk, de megfeledkeztünk róla.
Szállítás	Mesterséges tudásátadás (handoffs): a gyakorlatban ez a természetes (személyes) kommunikáció helyett készített felesleges dokumentációk gyártása. Az a tevékenység, amikor a fejlesztő csapatot elzárjuk a végfelhasználóktól és közvetítő dokumentációkon keresztül próbáljuk átadni az információkat a számukra.
Mozgatás (azok a tevékenységek, amik megszakítják a folyamatosságot)	Feladatváltás (task switching): a fejlesztői team mozgatása egyik projektről a másikra. A team folyamatos munkavégzésének megszakítása.
Várakozás	Késés, várakozás: a szoftverfejlesztésben a leggyakoribb várakoztatási tényező az üzleti elvárások pontosítása. Ha egy fejlesztő olyan kérdésbe ütközik, ami a rendszer üzleti funkcionalitását befolyásolja, a lehető leggyorsabban biztosítani kell számára a szükséges információt.
Hibák	Hibák: a kódban hagyott hibák továbbgyűrűznek a rendszerben feleslegesen növelve annak komplexitását. A hibalisták kezelése nagy számú hiba estén külön menedzsment eljárásokat igényel, amit össze kell hangolni a fejlesztés többi tevékenységével. Ez feleslegesen növeli a ráfordításokat.

A pazarlás megszűntetése a lean menedzsment talán legfontosabb alapelve.

Vágj bele gyorsan!

A rendszerrel szemben támasztott követelmények nem mérhetőek fel teljeskörűen a fejlesztés korai szakaszában. Bármilyen alapos is a követelményelemzési szakasz, a felhasználói elvárások folyamatosan változni fogak részben a környezet változásának eredményeként, részben a rendszer lehetőségeinek megismerése során. Igazán jó alkalmazás csak akkor készíthető, ha a rendszer fejlesztői átérzik a felhasználói igényeket. A részletes követelményspecifikáció nem alkalmas arra, hogy a rendszerrel kapcsolatos valós elvárásokkal megismertessék a fejlesztőket, ráadásul a külön követelményelemző csapat elzárja a direkt kommunikációtól a megvalósítást végző szakembereket. A jó rendszer végleges felépítése a megvalósítási lehetőségek vizsgálatával, a lehetséges alternatívák szűkítésével, kompromisszumokkal és folyamatos visszacsatolásokon keresztül alakul ki. Ahogy a szerzők írják: "A jó architektúra nem a ráfordított idő, vagy a követelményelemzés részletességének a függvénye, hanem a képzett embereké és a közöttük lévő információáramlásé. A jó rendszert befolyásoló tényezők a szakemberek felkészültsége és az információáramlás hatékonysága."

Tanulj folyamatosan!

A folyamatos tanulás jelentőségét mindenki elismeri és evidenciának tekinti. Kevésbé elfogadott ennek a szabálynak a következménye: a folyamatos tanulás elve ellentétes az előzetes, részletes követelményspecifikáció eszméjével. Miért? Két ok miatt. Először is, ha veszem magamnak a bátorságot, hogy kimondjam: mindent tudok ahhoz, hogy részletesen megtervezzem a jövőt, azzal azt mondom, hogy nincs szükségem tanulásra. Ha nem tudok mindent arról a rendszerről, amit fejleszteni akarok, akkor az erre vonatkozó terveim csak feltételezéseken alapulnak. Amint ezek a feltételezések megváltoznak, az erre alapozott terveim is feleslegesek lesznek. Másodszor, a környezet és az elvárások változnak. Ha ragaszkodni akarok a terveimhez, akkor a változást - és a tanulást - figyelmen kívül kell hagynom, vagy a terveim feleslegesek lesznek. Könnyű félréerteni ezeket a gondolatokat. A tervezés fontos, maguk a tervek viszont csak átmenetiek és ennek megfelelően kell kezelni őket. A tervezés nem más, mint a tanulási folyamat része. Újra és újra végre kell hajtani de csak olyan mélységben, amilyen mélységű információkkal rendelkezünk. Ez az alapelv általánosan igaz mindenre a projektben: azért mert valamit már elkészítettünk egy korábbi, azóta már megváltozott elképzelés alapján, ne féljünk megváltoztatni az új tudásunk birtokában. A tanulás változást jelent, a változás meg tanulást követel.

Várj az elköteleződéssel!

Az elkötelezettség felvállalásának a késleltetése azt jelenti, hogy nyitva hagyjuk magunk számára a választás lehetőségét a kritikus pillanatig. A kritikus pillanat (a szerzők "last responsible moment" kifejezést használják) az az utolsó időpont, ahol a döntés még a mi kezünkben van. A kritikus pillanat után a döntési alternatíváink száma szűkül, és egy számunkra kedvezőtlen alternatíva felé kényszeríthetnek a folyamatok. Ennél a pillanatnál későbbre a döntést nem szabad halogatni. A lean alapfilozófiája ebben a tekintetben az, hogy várjunk a döntéssel addig, amíg feltételezések helyett tények vagy események alapján hozhatjuk azt meg, de a folyamat irányítása még a kezünkben van. A lean gyártási elvek szerinti just-in-time rendszerben a gyártási folyamat akkor indul meg, amikor a megrendelés megérkezett, nem pedig egy bizonytalan keresleti előrejelzés alapján. A túl korai döntés legalább annyi kockázatot hordoz magában, mint a későn meghozott döntés. A döntéshozás késleltetése a lean filozófia "pull system" szabályának a betartása. Ha egy tevékenységet vagy döntést nem kell most elvégezni, akkor ne is tegyük meg, mert semmi nem garantálja, hogy holnap nem jutunk valami olyan információ birtokába, ami alapján egy másik alternatíva jobbnak bizonyulna. Ez egyben a veszteségtermelés elkerülésének egyik legjobb módja. Az adaptív módszertanok egyik kulcsfontosságú eleme éppen ezért a prioritási listák alkalmazása. Azzal foglalkozunk, ami ott és akkor a legfontosabb. (Ennek az elvnek a figyelmen kívül hagyása vezet a tradicionális módszertanok által produkált, több mint 60%-ot kitevő felesleges funkciók fejlesztéséhez.)

Szállítsd le gyorsan!

"A jó munkához idő kell!" így tartja a közmondás. A szoftverfejlesztésben ezzel szemben a rendszeresen gyors átadási képesség minden esetben a jó minőség legjobb jele is. A megbízható és gyors leszállítási képesség nem lehetséges kiemelkedő minőség nélkül. A just-in-time rendszerek kulcsa a vevői igény megjelenésétől a termék leszállításáig eltelt idő minimalizálása. Ha ezt a feltételt nem tudják teljesíteni, a vevők elpártolnak a vállalattól. A just-in-time rendszerben éppen ezért nem fogadhatóak el a hibák. Ha egy korai fázisban készült komponens hibás, az a teljes ráépülő termelési láncot blokkolja. A just-in-time rendszerben működő vállalatok és fejlesztői teamek hatalmas energiákat fordítanak arra, hogy a termelés hibamentes legyen. (Ezt megtehetik, hiszen a részletes tervezésre és előrejelzésre szánt idő jelentős részének megspórolásával bőven marad idejük a termelési lánc minőségének folyamatos javítására.) A szoftverfejlesztési projektben ezt a célt szolgálja a test driven development megközelítés, és a prioritási listák alapján történő inkrementális fejlesztés. A gyors szállítási képesség másik feltétele a pontos és jól szabályozott viselkedés. A gyors leszállításhoz kapcsolódó agilis elvekkel szemben gyakran hozzák fel ellenérvként a tervezetlenséget és az ad-hoc munkavégzést. A valóságban ugyanakkor a jól szervezett adaptív projekt számtalan szigorú normát tartalmaz, melyek az egyes tevékenységekkel szemben támasztott minőségi kritériumokat definiálják. Éppen ez teszi lehetővé, hogy team vezérlése "laza" legyen és a munkát ne fojtsák meg a szigorú irányításhoz szükséges nem értékteremtő tevékenységek. A gyorsan leszállított résztermékek lehetővé teszik az adott teamre és üzleti környezetre jellemző tényadatok gyűjtését, ami végsősoron megalapozott előrejelzések készítésének feltételeit teremti meg. Ez az előrejelzhetőség paradoxona: azáltal, hogy világos szabályok és minőségi elvek mentén hagyjuk a projektet adaptívan futni a hipotéziseken alapuló tervekhez történő ragaszkodás helyett, a gyakorlati tapasztalatok és az iteratív fejlesztés során gyűjtött tényadatok segítségével végülis az előrejelezhetőséget érjük el.

Építsd be a minőséget!

A just-in-time rendszerek jellegükből fakadóan rendkívül érzékenyek a hibákra. Hasonló a helyzet a lean szoftverfejlesztéssel is. Ha a csapat gyorsan akar eredményeket szállítáni, nincs idő hosszú hibajavító tesztelési eljárásokra. Az építsd be a minőséget alapelv lényege a hibák korai felismerése, kivizsgálása és megelőzése. A Toyota sikerét a századforduló környékén az "önleállító" szövőgépek alapozták meg. Ezek a gépek észlelni tudták, ha szövés folyamatába valamilyen hiba csúszott és automatikusan leálltak. Ez lehetővé tette, hogy az akkori japán munkaügyi szabályok mellett, - amely tiltotta a munkások éjszakai foglalkoztatást - a gépeket felügyelet nélkül éjjel is üzemeltethessék. Ezt a tulajdonságot "stop the line" névvel illették és később a Toyota teljes gyártási folyamatában alkalmazták. Bármilyen hiba a gyártósor bármely részén a teljes termelés leállítását eredményezi addig, amíg a hiba okát alaposan ki nem vizsgáltak és meg nem győződtek arról, hogy a későbbiekben nem fog előfordulni. Ez az elv elsőre nagyon kockázatosnak és megdöbbentőnek tűnik, de a konzekvens alkalmazása mellett a hibák száma minimálisra szorítható, a hibajavító eljárások gyakori alkalmazása pedig rutint biztosít, ami végsősoron a gyors hibaelhárításhoz vezet. Ennek az elvnek az alkalmazása szükségtelenné teszi az egyébként jelentős erőforrásokat lekötő "selejt-menedzsmentet". A szoftverfejlesztésben erre analógia a test driven devlopment. A lean szoftverfejlesztés szószólói ennek az elvnek a szélsőséges alkalmazását javasolják, melynek eredményeként akár a teljes issue-tracking rendszer is megszűntethető.

Értékeld az embereket!

A lean filozófia alapja, hogy a terelési folyamatot legjobban ismerő emberektől várhatóak a legjobb ötletek és a leginkább hasznos újítások. A lean menedzsment alapja a motivált és gondolkodó emberi viselkedés elősegítése. A Toyota alapelve, hogy jó terméket csak elkötelezett, felelősségteljes és a szakmájában kiváló szakemberek hozhatnak létre. A szervezet minden szintjén dolgozók megfelelő tiszteletet, autonómiát kapnak és lehetőségük van (mitöbb elvárják tőlük) a tevékenységi folyamataik folyamatos javítására, kísérletezésre. A lean szervezetben a hierarchia nem ugorható át, senki nem kerülhet egyszerűen a szervezet legmagasabb hierarchia szintjeire.

Optimalizáld az egészet!

A lean menedzsment alatt működő szervezetek felismerték, hogy a komplex rendszer nem írható le annak dekomponált részeinek együttesével, más szóval az egész nem ugyanaz, mint a részek összege, hanem valami annál több. Az egyes résztevékenységek önálló mérőszámok szerint történő mérése és ezek szerinti optimalizálása a teljes rendszer szuboptimális működéséhez vezetnek. A lean szervezetben minden tevékenységet a teljes "megrendeléstől a pénz begyűjtéséig" értéklánc egészére gyakorolt hatása szerint vizsgálnak. Mary Poppendieck egy érdekes ellenpéldát hozott fel könyvében: a gyártási láncban volt egy rendkívül drága berendezés, melynek az élettartama rövid volt. A dekompozíción alapuló optimalizáció alapján az tűnt logikusnak, hogy ezt a gépet a lehető legnagyobb kihasználtsággal kell üzemeltetni, hiszen a rövid élettartam alatt az egy termékre jutó költség akkor lesz alacsony, ha adott időszakban a legtöbb alkatrészt gyártja le. Ennek eredményeként hatalmas alapanyagkészleteket halmoztak fel (hogy véletlenül se hátráltassa a gyártást az alapanyaghiány), illetve a nagy kibocsátás miatt nagy kimeneti raktárra is szükség volt. Ennek eredményeként a lokális optimalizálás "ellenére" a teljes termelési láncban a gyártási költség magasra szökött.

Az egész folyamat optimalizációjára való törekvés a lean szervezetek partnerkapcsolataiban is megmutatkozik. Amikor a Fujitsu 2001-ben átvette a British Midland Airways (BMI) helpdesk rendszerének üzemeltetését, rövid időn belül felismerte, hogy a bejelentések 26%-át a check-in pultoknál lévő nyomtatók hibája okozta. A Fujitsu javaslatot tett új nyomtatók üzembe állítására, valamint további fejlesztési ötletekkel rukkolt elő. A fejlesztések eredményeként a hibabejelentések száma rövid időn belül 40%-kal csökkent. Ebben a történetben az az érdekes, hogy az eredeti help-desk szerződés alapján az üzemeltetőt a bejelentett és elhárított incidensek alapján fizették, tehát elvileg nem állt volna érdekében ez az optimalizálás. Az eredmények hatására a BMI és a Fujitsu módosította az üzemeltetési szerződést, aminek eredményeként mindkét cég a vártnál jobb feltételekhez jutott és ami a legfontosabb, sikerült fenntartaniuk a közös érdekeken alapuló optimalizációs folyamatot. Ennek az alapelvnek az ösztönzési rendszerre vonatkoztatva is messzemenő hatásai vannak. Az érdekeltségi rendszerek lehető legegyszerűbb elveken történő meghatározása szintés egy jellemző lean módszer.

Követelmények helyett elvárások!

A szoftverfejlesztési projektek egyik kulcsfontosságú területe a követelmények helyes meghatározása. Azt is tudjuk, hogy az egyedi fejlesztési projektek bukását leggyakrabban a hibás követelményelemzésre vezetik vissza. De vajon miért olyan nehéz feladat a követelmények helyes feltárása, dokumentálása és az ezeket kielégítő rendszer lefejelsztése? Szerintem a válasz az, hogy a követelmények nem a természetes gondolkodás kellékei. A követelmények részben a környezeti kényszerek, részben a megrendelők adott pillanatban, adott információk alapján kialakított elvárásainak rögzített leképezése. A gond az, hogy ezek mind változnak. A környezeti feltételek változásával nem nagyon tudunk mit kezdeni, azok a projekttől teljesen függetlenek, néha előre láthatók, néha nem. Ilyenek tipikusan az adott projekt környezetét befolyásoló jogszabályok, és az üzleti környezet változása.

A követelmények merevek, az elvárások élők

Sokkal izgalmasabb a megrendelői elvárásokat elemezni. Azok ugyanis a projekt hatókörén belül helyezkednek el. A megrendelő végsősoron dönthet arról, hogy ragaszkodik az adott elvárásához, vagy sem. Itt szándékosan az elvárás szót használom. A követelmények ugyanis az elvárásokból származnak. A követelmény kifejezés azt sugalja, hogy valami statikus dologról van szó, amit csak rögzíteni kell és onnantól ismerjük. Éppen ez a probléma vele! A megrendelőt ugyanis nem érdeklik a követelmények. A megrendelőnek elvárásai vannak, amiknek megfelelő rendszert akar látni. Az üzleti megrendelő szemében a követelmény csak egy szükséges rossz, amibe az előzetes követelményspecifikáción alapuló fejlesztési kultúra belekényszeríti a tervezhetőség látszatának fenntartása érdekében. A valós igények az elvárásokban bújnak meg. Az elvárások pedig a megismerés során folyamatosan változnak. Az elkészítendő rendszerrel kapcsolatos ismeretek bővülése pedig folyamatos. Az elemzési, tervezési szakaszban nemcsak a fejlesztők, de az üzleti megrendelők is folyamatosan formálják a fejlesztendő rendszerről kialakított képüket. A vízesés modellben alkalmazott követelménykezelési módszerek problémája tehát nem abban rejlik, hogy hibásan alkalmazzuk őket, hanem abban, hogy eredendően téves elképzelésből indulnak ki. Az elvárások ugyanis természetüknél fogva többnyire nem statikusak, tehát nem is rögzíthetők. A megoldás tehát nem az, hogy egyre komplexebb követelményelemzési és dokumentációs technikákat dolgozunk ki hanem az, hogy megtanuljuk követni a az elvárások változását. A hatékony elváráskezeléshez vezető legjobb út az, ha pontosan megértjük a fejlesztendő rendszer célját és üzleti környezetét. Ekkor az energiánkat nem a követelmények rögzítésére, hanem a problémák megoldására fókuszálhatjuk. A követelmények komplex rögzítésére és dokumentálására fordított energia nagy részét hasznosabb lenne olyan tevékenységekre fordítani, melyek során a fejlesztő csapat megértheti a megrendelői elvárásokat és az azok megött meghúzódó okokat. A jó rendszer elkészítéséhez a fejlesztő teamnek mindenképpen meg kell ismernie a megrendelő üzleti környezetét, ha rögzítjük a követelményeket, ha nem.

Az információmegosztás módszerei

Ambler W. Scott készített egy felmérést arról, hogy az egyes kommunikációs formák milyen mértékben járulnak hozzá ahhoz, hogy a fejlesztők megértsék a rendszerrel szemben támasztott elvárásokat. Az egyes kommunikációs formák hatékonyságát -5 és +5 közötti skálán lehetett osztályozni. A negatív értékek nagyjából azt jelentik, hogy az adott kommunikációs módszer inkább hátráltatja a megértést, mintsem javítja azt. A felmérésben az egyes információátadási módszerek hatékonyságát a csapaton belüli, valamint a csapat és a megrendelő közötti kommunikációban is vizsgálták. Érdemes megfigyelni, hogy az egyetlen negatív eredményt a részletes specifikáció kapta.

Egy figyelemreméltó példa

Szintén érdekes tanulsággal szolgál a Toyotánál alkalmazott követelménykezelési módszer. A Toyotánál alapszabály, hogy minden elvárásrendszernek el kell férnie egy A3-as oldalon. A Toyota Prius fejlesztésébe a Toyota hatalmas összegeket fektetett be úgy, hogy az autóval szembeni elvárásokat mindössze 5 pontban foglalták össze (relatív tágas belső tér; magas üléspozíció; jó aerodinamika; 20km/liter fogyasztás; kicsi, horizontálisan elhelyezett motor fokozatmentes automata váltóval). A követelmények gyűjtése helyett a prototípusok előállítására és tesztelésére helyezték a hangsúlyt. A gyakorlati megvalósítással szemben semmilyen megkötést nem alkalmaztak. A hybrid hajtás például a projekt során kialakított megvalósítási döntés volt, sehol nem szerepelt az eredeti elvárásokban. Érdemes elgondolkodni azon, hogy a világ legnagyobb és legnyereségesebb autógyára miért ezeket a módszereket alkalamzza? Ha jobban belegondolunk, egy új típus fejlesztése egy ugyanolyan kockázatos befektetés, mint egy új szoftver kifejlesztése. Ha a Toyota felismerte, hogy fölösleges előzetesen "agyonspecifikálni" a terméket, akkor miért ne tehetnénk mi is ugyanezt?

A SCRUM gyökerei

A Scrum menedzsment modell alapjául szolgáló elmélet leírása Takeuchi és Nonaka nevéhez kötődik. Ők publikálták 1986-ban a Harvard Business Review január-februári számában a "The new new product development game" című cikküket. A tanulmány témáját az a felismerés vezette, hogy a vállalatok profitjának egyre nagyobb része származik az új termékek értékesítéséből. (A 70-es években az 5 évesnél fiatalabb termékek részesedése a profitból 1/5 volt, a 80-as évekre ez 1/3-ra emelkedett.) Világos volt tehát, hogy azok a vállalatok számíthatnak hosszútávú sikerekre, akik a legjobbakká válnak az új termékek fejlesztésében és piacra vezetésében. A jó termékfejlesztés kritériumai a következők: rövid fejlesztési idő, magas minőség, alacsony fejlesztési és gyártási költségek. A nyolcvanas években az általánosan elfogadott termékfejlesztési módszertan a NASA által kifejlesztett vízesés modell alapú PPP (phased program planning) volt. A tradicionális PPP modellben a termékfejlesztés a meghatározott specialistákból álló csoportokon haladt végig (pl. a marketing meghatározta a célcsoportot, részletesen definiálta a termék paramétereit, a fejlesztő mérnökök elkészítették az ezekhez az igényekhez illeszkedő termék terveit, majd a gyártástechnológusok kialakították azt a gyártási modellt, amelyben a termék nagy számban előállítható).

A scrum neve a rugby játékból jön. A rugbyben a különböző posztokon játszó játékosok egy csapatban szorosan együttműködve juttatják el a labdát a célig. Ennek a módszernek két jellemzője van: 1.) különböző szerepek dolgoznak szorosan együttműködve egyidőben 2.) a labda nem egyenesen a cél felé halad, hanem néha visszajátszák egymásnak a játékosok, új pozíciót keresnek, és innen indulnak meg újra a cél felé.

A cikk írói azt vizsgálták, hogy a termékfejlesztésben sikeres vállalatok milyen módszereket alkalmaznak a termékfejlesztési projektjeik során. A vizsgálat többek között a Fuji-Xerox, Canon, Honda, NEC, EPSON és a HP több sikeres termékének kifejlesztésénél alkalmazott módszereket vizsgálta. A termékfejlesztésben résztvevőkkel készített interjúk alapján az alkalmazott fejlesztési folyamatokban a következő közös jellemzőket azonosították:

Szándékos instabilitás a folyamatban

A felsővezetés egy röviden megfogalmazott célmeghatározással indítja el a projektet, melyhez meglehetősen rövid határidőt rendel. A stratégiai célok meghatározásán túlmenően nem definiálja részletesen a termék jellemzőit. A Canon AE-1 modell fejlesztését kezdetekor például a menedzsment a következő célokat tűzte ki a fejlesztő team elé: állítsatok elő egy kompakt méretű, automata expozícióval rendelkező, magas minőségi szintet képviselő fényképezőgépet, melyet amatőrök is képesek használni és a jelenlegi uralkodó kompakt gépekhez képest 30%-al olcsóbban előállítható.

Önszerveződő projekt teamek

A projekt leginkább egy induló vállalkozáshoz hasonlít, aki maga alkítja ki a szabályait és mechanizmusait. A projekt elején nagy a fluktuáció, majd kialakul a team saját működési rendje. A felsővezetés egy kockázati tőke-befektetőhöz hasonlóan viselkedik, biztosítja a forrásokat és világosan kommunikálja a projekt stratégiai céljait. Ezen túlmenően alig avatkozik be a projekt menetébe. A projekt team a termék életciklusában érintett minél több szervezeti egység képviselőiből áll össze (pl. marketing, gyártás szervezés, karbantartás, tervezés).

Átlapoló fejlesztési szakaszok

Az átlapoló fejlesztési szakaszok során a projekt team újra-és-újra visszanyúl a korábbi fázisok eredményeihez és változtat rajtuk, ha kell. A tradicionális PPP modellekben ezt nehéz megtenni, mivel a korábbi szakaszokon dolgozó pl. tervezést végző mérnökök már a következő terméken dolgoznak akkor, amikor az általuk készített termék gyártástechnológiáját próbálják a gyártástechnológusok kidolgozni. A multifunkcionális csoportokban az egyes termékszempontok egyszerre képviseltetik magukat, ezért jelentősen hamarabb előjönnek a későbbi fázisokban várható problémák akkor, amikor még az elképzelések csak kezdeti szakaszban vannak. Ez lehetővé teszi annak elkerülését, hogy egy korai fázisban elkövetett hiba (vagy még akkor nem ismert szempont felmerülése) végigyűrűzzön az egész tervezési folyamaton.

"Multilearning" többszintű és többfunkciós tanulás

A scrum projektek alapja a tanulás. A projekt folyamatára jellemző az ismétlődő próbálkozás-tévedés ciklus, melynek során folyamatosan szűkítik a megvalósítható alternatívák körét. A szerzők kétirányú tanulási folyamatot azonosítottak: a többszintű (multi level) és a multifunkcionális (multifunctional) irányokat. A többszintű (multilevel) tanulási irány lényege, hogy egyéni és szervezeti szinten is elvárják a projektben résztvevőktól a fejlődést. A 3M-nél például a tervező mérnökök idejének 15%-át saját maguk által választott témákban történő tanulásra tartják fenn. A Honda City projektjének teljes termékfejlesztő csapatát Európába küldték 3 hétre, hogy gyűjtsenek ötleteket az Európai piacról. A multifunkcionális tanulási irány arra koncentrál, hogy a projektben résztvevő, különböző szakterületekről érkező szakemberek fejlesszék saját tudásukat a többi szakterületi irányba, hogy egy közös nyelvet és problémamegértést alakítsanak ki. Az Epson első minatűr nyomtatójának projekttagjai döntően mechanikai mérnökök voltak, és hiányzott az elektronikai tudás. A projekt vezető mérnöke 2 évig tanulta a villamosmérnöki területet, miközben a projekt futott. A projekt zárásakor az összes résztvevő mechanikai mérnök releváns villamosmérnöki ismeretekkel rendelkezett.

"Finom" irányítás

A scrum projektekre jellemző önszerveződés nem jelenti az irányítás és a felügyelet hiányát. A projekt felsőveztői rendszeres ellenőrzési pontokat iktatnak be, ahol kiértékelik a projekt haladását és ha szükséges beavatkoznak. A felsőezetés ugyanakkor távoltartja magát a direkt irányítástól. A projekt jellemző irányízási eszköze a "csoport nyomás", ahol a motivált projekttagok egymástól várják el a nagy teljesítményt. A finom irányítás két legfontosabb feltétele a projekt team tagjainak rendkívül alapos válogatása és a csoport szintű (nem egyéni!) jutalmazási rendszer. Ezeket egészítik ki olyan alapelvek, mint a hibák tolerálása és azonnali kiértékelése. A hibák tolerárálása teszi lehetővé a korai felismerést (mivel nem kell szégyelni és rejtegetni) és a következmények minimalizálását.

Szervezeteken átívelő tanulási folyamat

A scrum projektkultúrát követő szervezetek kivételes figyelmet fordítanak a szervezeten átívelő tanulási folyamatra. Ezt alapvetően két módon valósítják meg. Egyrészt a sikeres fejlesztési projektekben résztvevőket más projektcspatokba osztják be annak érdekében, hogy a személyes hatásokon keresztül terjedjenek a sikeres ötletek és működési modellek. Másrészt a több projektben bizonyított módszereket standardizálják és a vállalati kultúra részévé teszik.

A szerzők figyelmeztetnek, hogy a fent leírt alapelvek alkalmazása együttesen fejtik ki hatásukat. Bármelyik elhagyása a rendszer instabitásához vezethet, együttes alkalmazásuk viszont kiemelkedő dinamikát és innovációt hoz a termékfejlesztésbe. Fontosnak tartom kihangsúlyozni, hogy a tanulmányban leírtak nem hipotézisek, hanem egy igen kiterjedt kutatás tapaszatalatainak az összegzése.

A módszer számos projekt eredményein keresztül bizonyított, ezek közül néhány:

• Xerox 9900 fejlesztési időtartama kevesebb, mint 3 év volt holott a korábbi, hasonló termékek fejlesztésének átlagos időtartama meghaladta az 5 évet
• Az Epson EP-20 termék fejlesztésének időtartama 2 év volt, szemben a korábbi termékek átlagosan 4 éves fejlesztési idejével
• 1982-ben a Honda fél év alatt közel 30 új modellt dobott piacra, amivel jelentősen megrengette az addig piacvezető Yamaha pozícióját

A Scrum azóta az uralkodó agilis fejlesztési menedzsment modellé vált, számos vállalat, köztük az IBM, Microsoft és az Apple alkalmazza. Az elmúlt időszakban kritikus területeken is megkezdte a térhódítást, például a Lockheed Martin vadászgépeinek szofteverfejlesztésében is alkalmazzák. A SCRUM menedzsment modell szoftverfejlesztésre történő adaptálása Ken Schwaber nevéhez fűződik.

www.scrumalliance.org

Fontos vagy sürgős?

A személyes időmenedzsment módszerek közül talán a legsikeresebb a feladatok fontosság-sürgősség szerinti osztályozásán alapuló. A rendszer kialakításához az a felismerés vezetett, hogy bármilyen hatékonyan is végezzük el feladatainkat, előbb vagy utóbb bekövetkezik az a pont, ahol a feladatok száma meghaladja a rendelkezésünkre álló időkeretet. Ha hatékonyabban dolgozunk, akkor ez az állapot kicsit később következik be, ha kevésbé hatékonyan, akkor hamarabb. A feladatok elvégzésének gyorsasága másodlagos, a lényeg az, hogy megfelelően válasszuk ki, hogy mire fordítjuk az időnket. A feladatainkat egy fontosság és egy sürgősség tengely mentén kialakított mátrixban helyezzük el. A fontos dolgaink a mátrix felső sávjában kapnak helyet. A módszer központi eleme a világos célmeghatározás, és értékrend kialakítás. Azok a feladatok tekintendők fontosnak, amelyek közvetlenül hozzájárulnak ahhoz, hogy céljainkat elérjük. Miután egy ideje alkalmaztam ezt az időszervezési rendszert rájöttem, hogy a megközelítés ugyanúgy alkalmas egy projekt team erőforrásgazdálkodásának menedzselésére, mint a személyes időgazdálkodásra. Mi a célja egy fejlesztési projektnek? A valós igényeket kielégítő, működő szoftver! Nézzük meg ebből a szempontból, hogy mik jellemzik a mátrix egyes negyedeit:

I. negyed: a sürgős és fontos tevékenységek - a tűzoltás

Ebbe a kategóriába tartoznak azok a feladataink, amiket mindenképpen el kell végeznünk, viszont a rendelkezésünkre álló idő szűkös. Az ebben a negyedben eltöltött idő okozza a legtöbb stresszt, és vezet a legtöbb hibához. A fejlesztési projektben tipikusan ilyen a rendszer átadását megelőző időszak, ahol számos ismert hibát kell kijavítani, véglegesíteni kell a rendszerhez kapcsolódó üzemeltetési és felhasználói dokumentációkat stb. Világos, hogy a feladatok fontosak, viszont reménytelenül kevésnek látszik a rendelkezésre álló idő.

II. negyed: fontos, de nem sürgős tevékenységek - a fejlődés, teremtés

Ez a leghasznosabb időtöltés. Ebben a negyedben végezzük el azokat a feladatokat, melyek a projektet ténylegesen előremozdítják, javítanak a termék minőségén. Itt termelünk a leghatékonyabban valódi értéket. A fejlesztési projektben ez az az időszak, amikor hagyjuk a csapatot dolgozni, kreatívan gondolkodni, amikor lehetőséget adunk a fejlődésre és a kísérletezésre. Ide tartozik az az idő, amikor a fejlesztő csapat lehetőséget kap arra, hogy megértse a rendszer valós üzleti környezetét. Ebben a negyedben végezzük a tervezést és a feladatok priorizálását is.

III. negyed: sürgős, de nem fontos tevékenységek - a zaklatás

Ez a legalattomosabb negyed. A személyes hatékonyságot vizsgáló felmérések azt mutatták ki, hogy a vezetők az idejük 30-50%-át ilyen tevékenységekkel töltik. Az alattomosságát az okozza, hogy a sürgető határidők a fontosság érzetét keltik. Az ebbe a negyedbe tartozó tevékenységek veszik el az időt a tényleges értékteremtésről, mivel állandóan nyomás alatt tartják az embereket. Tipikus képviselői a megszakításokból adódó feladatok. A fejlesztési projektekre vetítve ilyen az emberek projektek közötti mozgatása, a gyenge menedzsment által azonnali határidőre igényelt státusz jelentések és demók.

Kicsit elvonatkoztatva ugyanide sorolható a legtöbb dokumentáció leadás is. A követelményspecifikáció, vagy a funkcionális specifikáció projekttervben meghatározott időpontra történő leadási kényszere ahhoz vezet, hogy a team nem tud kellő időt szakítani a fejlődésre, vagy a végfelhasználókkal történő kommunikációra, mert bezárkózik az irodába a dokumentum megírása miatt. Ezek a tevékenységek elterelik a figyelmet a valódi kérdésekről és a követelményeket kipipálandó feladatokká degradálják nem hagyva időt a valódi okok megértésére.

IV. negyed: nem sürgős és nem fontos tevékenységek - a pazarlás

Ezek azok a tevékenységek, melyek alig járulnak hozzá a projekt sikeréhez. Legtipikusabb képviselőjük a túlhízlalt dokumentációk és a soha le nem fejlesztett, de részletesen specifikált követelmények és rendszerfunkciók. Az operatív menedzsment területén ilyenek a túl nagy körben megrartott, nem előkészített megbeszélések, elhúzódó státusz egyeztetések, vagy a gyenge menedzsment bizonytalanságát enyhítendő időelszámoltatások. Szintén jellemző pazarlási forrás a nem kellően átgondolt módosítási igények átvezettetése a rendszerben. Amik később újra megváltoznak... végül soha senki nem használja...

A fentieket jobban átgondolva gyorsan rádöbbenhetünk, hogy az agilis fejlesztési irányzatok végsősoron arra törekszenek, hogy a team erőforrásait az első két negyedre összpontosítsák. A projekt megszabadítása az alsó sávban lévő felesleges ráfordításoktól a lean menedzsment (lean = karcsú) egyik legfontosabb irányelve.

A cikkben felhasznált képeket a következő oldalakról vettem kölcsön: collegecandy.com, www.vuidesign.net, www.cmse.ie, bitsandpieces.us