Kanban rendszer: eredet, alapelvek és PMO-bevezetés vegyes portfóliókhoz
A Kanban a projektmenedzsment egyik leggyakrabban félreértett fogalma, főként azért, mert két nagyon különböző dolog viseli ugyanazt a nevet. A Kanban tábla egy vizuális eszköz, oszlopok és kártyák, amelyet szinte minden második szoftvercsapat faláról ismerünk. A Kanban rendszer az eszközt körülvevő keret: irányelvek, folyamatban lévő munka korlátai, folyammutatók, visszacsatolási hurkok és a hat gyakorlat, amely a Kanbant fegyelemmé teszi, nem pedig táblás gyakorlattá. A kettő összekeverése az oka annak, hogy oly sok Kanban-bevezetés megreked: a csapat megkapja a táblát, de a rendszert soha. Ez a cikk végigveszi, mi is valójában a Kanban rendszer, honnan ered, miben különbözik a Kanban táblától, mikor érdemes a Scrummal szemben választani, és hogyan vezet be egy PMO Kanbant egy vegyes portfólión. Projektvezetőknek és PMO-elemzőknek szól, akiknek szervezeti környezetben kell működtetniük a Kanbant, nem csupán egyetlen csapat tábláját moderálniuk.
Legfontosabb tudnivalók:
- A rendszer több, mint a tábla: a Kanban tábla egyetlen vizuális eszköz, de a Kanban rendszer hozzáadja a folyamatban lévő munka korlátait, az explicit irányelveket, a folyammutatókat és a visszacsatolási hurkokat. A legtöbb bevezetés azért akad el, mert a csapatok megkapják a táblát, de a rendszert soha nem építik ki.
- A Toyotából nőtt ki: a Kanban a Toyota gyártósorain húzó elvű jelzési módszerként indult, majd átkerült a szoftverbe és a tudásmunkába. Az alapgondolat érvényben marad: a túl sok folyamatban lévő munka szétzilálja az áramlást.
- Hat gyakorlat teszi fegyelemmé: a munka vizualizálása, a folyamatban lévő munka korlátozása, az áramlás irányítása, az irányelvek explicitté tétele, a visszacsatolási hurkok működtetése és a közös fejlesztés. Együtt egy meglévő munkafolyamatot irányított rendszerré alakítanak a csapat átszervezése nélkül.
- A folyammutatók megmondják, működik-e: a ciklusidő, az átfutási idő, az átbocsátóképesség és a kumulatív áramlási diagram megmutatja, milyen gyorsan és kiszámíthatóan halad a munka. A véleményt bizonyítékkal váltják fel, amikor egy PMO átvizsgálja a szállítást.
- A Kanban és a Scrum eltérő problémákat old meg: a Scrum a kiszámítható, iterációalapú funkciómunkához illik, míg a Kanban a folyamatos, szolgáltatásorientált vagy megszakításokkal terhelt áramláshoz. Egy PMO gyakran mindkettőt működteti egy vegyes portfólión.
Mi a Kanban rendszer
A Kanban rendszer egy munkafolyamat-irányítási keret, amely a munka vizuális megjelenítését, a folyamatban lévő munka korlátait, a húzó elvű feladatáramlást és a folyamatos fejlesztést egységes működési modellé köti össze a tudásmunkát végző csapatok számára. Nem projektmenedzsment-módszertan a Scrum értelmében: a Kanban nem ír elő szerepeket, ceremóniákat vagy rögzített iterációkat. Amit előír, az olyan gyakorlatok összessége, amelyeket bármely meglévő munkafolyamat átvehet a csapat átszervezése, a munkakörök átnevezése vagy új értekezletek beütemezése nélkül. Ezért terjedt el a Kanban rendszer a gyártásból a szoftverbe, majd a marketingbe, a HR-be és az IT-üzemeltetésbe: ráépül arra, amit a csapat már amúgy is csinál.
A rendszernek négy alapmechanizmusa van, amelyek együtt működnek. A vizualizáció közös felületen (fizikai vagy digitális) teszi láthatóvá a munkát, hogy mindenki ugyanazt az aktuális állapotot lássa. A folyamatban lévő munka korlátai korlátozzák az egyes szakaszokban egyszerre folyó munka mennyiségét, és arra kényszerítik a csapatot, hogy befejezze a megkezdettet, mielőtt újba fogna. A húzás felváltja a tolást: a munka csak akkor halad tovább, ha lejjebb kapacitás szabadul fel, ahelyett hogy az tolná, aki előállítja. A folyammutatók mérik, milyen gyorsan és kiszámíthatóan halad a munka a rendszeren át, és felszínre hozzák a szűk keresztmetszeteket, mielőtt késésekké válnának.
Az eredet: a Toyotától a tudásmunkáig
A Kanban a Toyota gyártási rendszerében született az 1940-es és 1950-es években. A japán kanban szó táblát vagy kártyát jelent, és a Toyota gyáraiban a kanban kártya fizikai jelzés volt: csak akkor engedélyezte egy alkatrész gyártását vagy pótlását, amikor lejjebb valós igény jelentkezett. Ez megfordította a szokásos logikát. Ahelyett, hogy biztonságból gyártottak volna alkatrészeket és készletet halmoztak volna fel, minden állomás csak akkor húzott munkát, amikor a következő állomás készen állt. Az eredmény kevesebb készlet, rövidebb átfutási idő és korán láthatóvá váló problémák voltak.
A tudásmunkába való átlépés évtizedekkel később következett be. A 2000-es években David J. Anderson ugyanezeket az elveket vitte át a szoftverfejlesztésbe és az IT-be, és a Kanbant az evolúciós változás módszereként fogalmazta meg. A felismerés ugyanaz maradt: a túl sok egyidejű munka szétzilálja az áramlást, a látható korlátok pedig helyreállítják. Ezért működik ugyanaz a minta az autóalkatrészektől a szoftverfunkciókon át a marketingkampányokig.
Kanban rendszer és Kanban tábla: a döntő különbség
A Kanbanról szóló beszélgetésekben a leggyakoribb tévedés, hogy a táblát és a rendszert szinonimaként kezelik. Nem azok. A Kanban tábla egyetlen vizuális eszköz: az oszlopok az áramlás szakaszait, a kártyák a munkaelemeket jelölik. A Kanban rendszer a teljes keret: a tábla csak egy összetevő a folyamatban lévő munka korlátai, az explicit irányelvek, a folyammutatók, a kadenciák (rendszeres értekezletek és felülvizsgálatok) és a hat gyakorlat mellett. Egy csapatnak lehet Kanban táblája Kanban rendszer nélkül, és a különbség az eredményekben mutatkozik meg.
Képzeljük el, mi történik, ha egy csapat csak a táblát vezeti be. Valaki létrehoz oszlopokat teendő, folyamatban és kész címkékkel, mindenki tologatja a kártyáit, és kívülről Kanbannak látszik. De a folyamatban lévő munka korlátai nélkül a folyamatban oszlop tovább telik; explicit irányelvek nélkül mindenki mást ért kész alatt; folyammutatók nélkül pedig senki sem tudja, javul-e vagy romlik a szállítás. A tábla láthatóvá teszi a munkát, de csak a rendszer teszi irányíthatóvá. Ezért a tábláról a rendszerre való áttérés nem a jobb szoftverről szól, hanem irányelvekről, korlátokról és mérésről.
A Kanban munkafolyamat-útmutató és a Kanban tábla útmutató részletesen bemutatja magát a táblát és annak használatát; ez a cikk a táblát körülvevő rendszerre összpontosít.
Tapasztalja meg a projektirányítás új szintjét fejlett PPM-szoftverrel, kezdje el még ma ingyen.
A Kanban rendszer hat gyakorlata
A Kanban rendszer hat alapgyakorlaton nyugszik. Együtt teszik ki a különbséget egy táblát használó csapat és egy áramlást irányító csapat között. Külön-külön minden gyakorlat egyszerű; hatásuk abból fakad, hogy együtt alkalmazzák őket.
A munka vizualizálása
Minden munka láthatóvá válik egy közös táblán, hogy mindenki ugyanazt az állapotot lássa. Már önmagában a láthatóság felszínre hozza a szűk keresztmetszeteket, a blokkolt elemeket és az egyenetlen terhelést, amelyek a feladatlistákban rejtve maradnak.
A folyamatban lévő munka korlátozása
Minden szakasz kap egy folyamatban lévő munka korlátot, felső határt az egyszerre aktív elemek számára. A korlátok arra kényszerítik a csapatot, hogy befejezze a megkezdettet, mielőtt újba fogna, és épp így kezd a munka gyorsabban és kiszámíthatóbban áramlani.
Az áramlás irányítása
A csapat figyeli, hogyan halad a munka a szakaszokon át, és ott avatkozik be, ahol elakad. A cél a stabil, kiszámítható áramlás, nem pedig minden ember maximális kihasználtsága.
Az irányelvek explicitté tétele
A rendszer szabályait, hogy mit jelent a kész, mikor léphet tovább egy kártya, hogyan rangsorolják az elemeket, kimondják és leírják. Az explicit irányelvek véget vetnek a néma nézeteltéréseknek, és a rendszert taníthatóvá és fejleszthetővé teszik.
Visszacsatolási hurkok bevezetése
A rendszeres kadenciák, a napi egyeztetés, az áramlás felülvizsgálata és a retrospektíva, lehetőséget adnak a rendszernek, hogy ellenőrizze és korrigálja önmagát. Hurkok nélkül a tábla statikussá válik, és eltávolodik a valóságtól.
Közös fejlesztés
A változás fokozatosan és bizonyítékok alapján történik, nem nagy átszervezésekkel. A csapat a mutatóit és megfigyeléseit felhasználva kis kísérleteket futtat, és megtartja azt, ami mérhetően javítja az áramlást.
A Kanban rendszer alapmutatói
A Kanban a véleményt bizonyítékkal váltja fel, és a bizonyíték négy mutatóból ered. Ezek megválaszolják a kérdéseket, amelyeket minden PMO feltesz a szállításról: meddig tart a munka, mennyit fejezünk be, és hol torlódik.
Ciklusidő és átfutási idő
A ciklusidő azt méri, meddig tart egy elem a munka megkezdésétől a befejezésig. Az átfutási idő hosszabb szakaszt mér, attól kezdve, hogy egy kérés beérkezik, a szállításig, és így magában foglalja a munka megkezdése előtti várakozást is. Az ügyfél az átfutási időt éli meg; a csapatok a ciklusidőt irányítják.
Átbocsátóképesség és kumulatív áramlási diagram
Az átbocsátóképesség azt számolja, hány elem készül el időszakonként, és a legegyszerűbb alap az előrejelzéshez. A kumulatív áramlási diagram szakaszonként ábrázolja a munkát az időben; a szélesedő sávok növekvő sorokat jeleznek, a sávok közötti vízszintes távolság pedig egy pillantással megmutatja az átfutási időt. Együtt ezek a mutatók a szubjektív érzést, hogy hogy megy, megbízható számokká alakítják.
Kanban és Scrum: melyik keretet válasszuk
A Kanbant és a Scrumot gyakran állítják szembe, pedig eltérő problémákat oldanak meg. A Scrum iterációalapú: a munkát sprintekben vállalják be, a csapat a sprint határain szállít, és rögzített szerepekkel és ceremóniákkal működik. A Kanban folyamatos áramlás: a munka akkor halad a folyamatban, amikor kapacitás szabadul fel, rögzített iterációk nélkül, és szerepek helyett gyakorlatokat ír elő. Egyik sem jobb; eltérő munkaformákhoz illenek.
A Scrum jól illik a kiszámítható funkciómunkához, amely értelmesen sprintekbe tervezhető, például egy termék felépítéséhez egy ütemterv mentén. A Kanban a folyamatos, szolgáltatásorientált vagy megszakításokkal terhelt munkához illik, ahol a prioritások naponta változnak, például az üzemeltetéshez, a támogatáshoz vagy a karbantartáshoz. Sok érett szervezet mindkettőt párhuzamosan működteti, és egy vegyes portfóliót irányító PMO-nak ritkán kell egyet választania mindenre. A gyakorlati kérdés nem az, hogy Kanban vagy Scrum, hanem hogy melyik keret illik melyik munkatípushoz.
A Scrum módszertani útmutató részletesen bemutatja ezt a keretet.
Kanban rendszer bevezetése PMO-környezetben
Egyetlen csapatot a tábláról a rendszerre átvinni egy dolog. Kanbant bevezetni egy egész portfólión, PMO-környezetben, egészen más, mert most több csapat, eltérő munkaformák és az egységes áttekintés igénye lép be a képbe. Itt térül meg leginkább a tábla és a rendszer közötti különbség.
Kicsiben kezdeni: a vizualizációtól a teljes rendszerig
A legmegbízhatóbb út egy olyan csapattal kezdődik, amelynek valós áramlási gondja van. Először vizualizálják a munkáját, majd hozzáadják a folyamatban lévő munka korlátait, azután explicitté teszik az irányelveket, végül bevezetik a mutatókat. Ha a rendszer egy csapatnál meggyökeresedett, mintaként szolgál a következőknek, ahelyett hogy egy folyamatot egyszerre kényszerítenének mindenkire.
Portfólió-nézet a PMO számára
Egy PMO-nak többre van szüksége az egyes csapatok tábláinál; olyan nézetre, amely megmutatja, hogyan áramlik a munka a projektek és részlegek között. A FlexiProjectben a Kanban tábla szervezeti részlegek szerint jeleníti meg a feladatokat, és portfólió-szinten hozza felszínre a szűk keresztmetszeteket és az egyenetlen terhelést. Így a PMO nemcsak az egyes projektek állapotát látja, hanem a teljes portfólió szállítási mintázatát.
Egységes irányelvek, helyi rugalmasság
A művészet abban rejlik, hogy elég sokat szabványosítunk ahhoz, hogy a portfólió összehasonlítható maradjon, és elég teret hagyunk ahhoz, hogy minden csapat leképezhesse a saját munkáját. A kész közös meghatározása, a közös mutatók és a közös kadencia megbízható összképet ad a PMO-nak, miközben minden csapat megtartja a saját oszlopait és korlátait.
Ha a csapatok Kanban-munkájukhoz már Jirát használnak, a FlexiProject-Jira integráció az állapot, a felelős és a típus megőrzésével importálja a feladataikat, így a PMO nézetei naprakészek maradnak anélkül, hogy a csapatok eszközt váltanának.
Lendítse előre projektjeit fejlett PPM-szoftverrel, próbálja ki a FlexiProjectet 30 napig ingyen.
GYIK: a Kanban rendszer
Mi a különbség a Kanban és a Scrum között?
A Scrum iterációalapú: a munkát sprintekben vállalják be (jellemzően kéthetesekben), és a csapat a sprint határain szállít. A Kanban folyamatos áramlás: a munka akkor halad a folyamatban, amikor a kapacitás engedi, rögzített iterációk nélkül. A Scrum szerepeket (Product Owner, Scrum Master, fejlesztőcsapat) és ceremóniákat ír elő. A Kanban gyakorlatokat ír elő, de nem konkrét szerepeket vagy eseményeket. A Scrum a kiszámítható funkciómunkához illik; a Kanban a folyamatos, szolgáltatásorientált vagy megszakításokkal terhelt munkához.
Hogyan számítjuk ki a folyamatban lévő munka korlátait?
Nincs egyetemes képlet; a gyakorlati megközelítés tapasztalati. Egy elterjedt kiindulópont a csapatméret közelében vagy kicsit alatta van, hogy ne mindenki dolgozzon több dolgon egyszerre. Ezután a korlátot megfigyelés alapján igazítjuk: ha a munka folyamatosan feltorlódik egy korlát előtt, az előző szakasz túl laza; ha vannak tétlen emberek, a korlát túl szigorú. A korlát irányítási eszköz, nem rögzített érték.
Kell-e külön szoftver egy Kanban rendszerhez?
Nem. Egy Kanban rendszer működhet falra ragasztott cetlikkel is, és sok csapat így kezdi. A szoftver akkor válik értékessé, amikor a munka több csapat között oszlik meg, amikor a mutatókat automatikusan érdemes rögzíteni, vagy amikor egy PMO-nak portfólió-nézetre van szüksége. Ekkor egy olyan eszköz, mint a FlexiProject, egy helyen fogja össze a táblát, a folyamatban lévő munka korlátait és a folyammutatókat.
Kombinálható a Kanban a Scrummal?
Igen. Az elterjedt megközelítés, amelyet gyakran Scrumbannak neveznek, megtartja a Scrum kadenciáját és szerepeit, és hozzáadja a Kanban folyamatban lévő munka korlátait és áramlásirányítását. Segít azoknak a csapatoknak, amelyek sprintekben dolgoznak, de kiszámíthatatlan beérkezésekkel küzdenek, például vegyes funkció- és támogatói munkával.
A rendszer, nem csak a tábla
A Kanban rendszer a teljes keret azon dolog körül, amit a legtöbben Kanban alatt értenek: nem csupán tábla, hanem a folyamatban lévő munka korlátai, folyammutatók, explicit irányelvek, visszacsatolási hurkok és hat gyakorlat, amelyek egy vizuális eszközből működési fegyelmet formálnak. A Kanban táblától való megkülönböztetés azért fontos, mert a legtöbb bevezetés a tábla szintjén reked meg: a csapatok megkapják a vizualizációt, de a rendszert soha nem építik ki, és az ígért áramlási javulás elmarad. A Toyota-gyártásbeli eredet megmagyarázza a mechanikát: a túl sok folyamatban lévő munka szétzilálja az áramlást, a láthatóság a korlátokkal együtt helyreállítja, és a minta minden környezetben megáll. Egy vegyes portfóliót irányító PMO számára a valódi haszon nem a táblában rejlik, hanem az egységes irányelvekben, a közös mutatókban és egy portfólió-nézetben, amely megmutatja, hogyan áramlik a munka az egész szervezetben. Aki Kanbant vezet be, a táblát kiindulópontként, a rendszert célként tekintse.
