Kanban: mi az? Tervezi a Kanban bevezetését az üzleti folyamataiba? Íme, hol kezdjem

Több cikket fogok írni az új Kanban (Kanban Development) agilis fejlesztési módszertanról, hogy felkészüljek a 2009-es Skandináv Agilis Konferenciára, ahol az egyik beszámolót fogom tartani (egyébként meghívok mindenkit a konferencia).
Ma közzéteszem az első cikket.
Az első cikk fő célja, hogy a lehető legegyszerűbben leírja a Kanban alapjait: mi az, miben különbözik a többi rugalmas módszertől, és miért van rá szükség.
Szeretnék minél több kérdést és kételyt összegyűjteni a megjegyzésekben, hogy válaszolhassak rájuk a következő cikkekben, ezért írjon bármit, amit nem ért, vagy bármi mást, amit tudni szeretne a Kanbanról.
Nem vagyok éppen nagy szakértő ebben az új módszertanban, de a csapaton belül egyedül jutottunk el a Kanbanhoz, és következetesen végigmentünk a mutáció minden szakaszán a SCRUM-tól a Kanbanig, tehát gyakorlati tapasztalataink vannak.

Először a kifejezés eredetéről írok Kanban.

Ez a kifejezés Japánból került hozzánk a szűk körökben széles körben ismert Toyota gyártási rendszernek köszönhetően. Szeretném, ha minél többen olvasnának erről a rendszerről és a benne foglalt alapelvekről - lean termelés, folyamatos fejlesztés, ügyfélközpontúság stb. Mindezeket az alapelveket Taiichi Ohno A Toyota gyártási rendszer című könyve írja le, amelyet orosz nyelvre fordítottak le.

A Kanban kifejezésnek szó szerinti fordítása van: „Kan” azt jelenti, hogy látható, látható, a „ban” pedig kártyát vagy táblát jelent.
A Toyota gyáraiban mindenhol Kanban kártyákat használnak, hogy elkerüljék a raktárak és a munkaterületek zsúfoltságát az előre elkészített alkatrészekkel. Képzelje el például, hogy ajtókat szerel fel egy Toyota Corollára. Van egy 10 ajtós csomagja a munkahelye közelében. Egymás után rakja fel őket az új autókra, és amikor 5 ajtó maradt a csomagban, akkor tudja, hogy ideje új ajtókat rendelni. Fogsz egy Kanban kártyát, írsz rá egy rendelést 10 ajtóra és elviszed az ajtógyártóhoz. Tudod, hogy éppen akkor készíti el őket, amikor kifogysz a maradék 5 ajtóból. És pontosan ez történik – az utolsó ajtó beszerelésekor egy 10 új ajtót tartalmazó csomag érkezik. És ez mindig megtörténik – csak akkor rendel új ajtót, amikor szüksége van rájuk.
Most képzelje el, hogy egy ilyen rendszer az egész üzemben működik. Sehol nincs olyan raktár, ahol hetekig-hónapokig hevernek az alkatrészek. Mindenki csak kérésre dolgozik, és pontosan annyi alkatrészt gyárt, amennyit kér. Ha hirtelen több vagy kevesebb megrendelés érkezik, a rendszer maga is könnyen alkalmazkodik a változásokhoz.

A Kanban kártyák fő célja ebben a rendszerben a „folyamatban lévő munka” (folyamatban lévő munka) mennyiségének csökkentése.
Például egy teljes gyártósorhoz pontosan 10 ajtókártya tartozhat. Ez azt jelenti, hogy egy adott időpontban legfeljebb 10 kész ajtó lesz a vonalon. Mikor kell új ajtót rendelni és mennyi dolga a beszerelőnek. Csak ő ismeri az igényeit, és csak ő tud rendelést leadni az ajtógyártónál, de ő mindig 10-re korlátozódik.
Ezt a Lean gyártási módszert a Toyota találta fel, és most világszerte számos gyártó cég alkalmazza vagy már bevezette.

De ez mind a termeléshez kapcsolódik, nem a szoftverfejlesztéshez.
Mi a Kanban fejlesztés a szoftverrel kapcsolatban, és miben különbözik a többi rugalmas módszertől, legyen az SCRUM vagy XP?

Először is azonnal meg kell értened, hogy a Kanban nem egy konkrét folyamat, hanem egy értékrendszer. Pont mint a SCRUM XP-vel. Ez azt jelenti, hogy senki nem fogja megmondani, mit és hogyan kell csinálni lépésről lépésre.
Másodszor, az egész Kanban egyetlen egyszerű mondattal leírható - „A jelenleg folyamatban lévő munka csökkentése (folyamatban lévő munka)”.
Harmadszor, a Kanban még „rugalmasabb” módszertan, mint a SCRUM és az XP. Ez azt jelenti, hogy nem fog megfelelni minden csapatnak vagy minden projektnek. Ez azt is jelenti, hogy a csapatnak még jobban készen kell állnia az agilis munkára, mint a SCRUM-ot és XP-t használó csapatoknak.

A Kanban és a SCRUM közötti különbség:
- A Kanbanban nincs idődoboz semmire (se feladatokra, se sprintekre)
- A Kanbanban több a feladat és kevesebb
- A Kanbanban a feladatok határidejének becslése nem kötelező, vagy egyáltalán nem kötelező
- A Kanbanban nincs „csapatsebesség”, és csak a feladat elvégzésének átlagos idejét veszik figyelembe

Most nézze meg ezt a listát, és gondolja át – mi marad az agilis módszertanból, ha eltávolítjuk a sprinteket, növeljük a feladatok méretét és leállítjuk a csapat sebességének mérését? Semmi?
Hogyan is beszélhetünk fejlesztésirányításról, ha eltávolítjuk a főbb vezérlőeszközöket - határidőket, munkasebességet és sprinteket? Számomra ez a kérdés szinte a legfontosabb.
a menedzserek mindig az irányításra gondolnak, és megpróbálják megszerezni azt, bár a valóságban soha nem rendelkeznek vele. A fejlesztés menedzser általi ellenőrzése kitaláció. Ha a csapat nem akar dolgozni, akkor hiába irányítod, megbukik a projekt.
Ha a csapat élvezi a munkát és teljes odaadással dolgozik, akkor nincs szükség kontrollra, csak beavatkozik és növeli a költségeket.
Például a SCRUM jól ismert problémája a megbeszélések, értekezletek és a nagy időveszteség a sprintek csomópontjain (amikor legalább egy napot az egyik sprint lezárásával, majd egy napot egy új nyitásával töltenek). ha a sprint 2 hetes, akkor 2 hétből 2 nap 20%, rohadt sok). Ennek eredményeként a SCRUM használata során az idő közel 30-40%-át magának a folyamatnak a karbantartására fordítják - napi megbeszélésekre, 5%-ban workshopokra, sprint retrospektívákra stb. harminc%!

A Kanban fejlesztés elsősorban a feladatokra való összpontosításában tér el a SCRUM-tól. Ha a SCRUM-ban a sprintek sikeres teljesítése a fő hangsúly a csapatnak (el kell ismernünk, hogy ez igaz), akkor a Kanbanban a feladatok állnak az első helyen.
Nincsenek sprintek, a csapat az elejétől a befejezésig egy feladaton dolgozik. A feladat telepítése akkor történik meg, amikor az készen áll. Az elkészült munkák bemutatása - is. A csapat ne becsülje meg a feladat elvégzésének idejét, mert ennek nincs sok értelme, és az elején szinte mindig rossz.
Ha a menedzser bízik a csapatban, akkor miért kell időbecslést készíteni? A menedzser feladata egy prioritásos feladatkészlet létrehozása, a csapaté pedig az, hogy ebből a készletből minél több feladatot teljesítsen. Minden. Nincs szükség vezérlésre. A menedzsertől csak feladatokat kell hozzáadnia ehhez a készlethez, vagy módosítania kell a prioritásukat. Így irányítja a projektet.

A csapat Kanban táblát használ a munkához. Például így nézhet ki (kivéve):

Oszlopok balról jobbra:

A projekt céljai:
Nem kötelező, de hasznos oszlop. Magas szintű projektcélokat helyezhet el ide, hogy a csapat láthassa azokat, és mindenki tudjon róluk. Például: „Növelje a sebességet 20%-kal” vagy „Támogatás hozzáadása a Windows 7 rendszerhez”.

Feladatsor:
Itt tárolják a feladatokat, és készen állnak a kezdésre. A legfelső, legmagasabb prioritású feladat mindig végrehajtásra kerül, és a kártyája a következő oszlopba kerül.

Tervezés fejlesztés:
Ez és a többi oszlop a „Befejezve”-ig változhat, mert a csapat dönti el, hogy a feladat milyen lépéseken keresztül éri el a „Befejezett” állapotot.
Ez az oszlop például olyan feladatokat tartalmazhat, amelyeknél a kód vagy az interfész kialakítása még nem világos, és amelyek megvitatása folyamatban van. A megbeszélések befejeztével a feladat a következő oszlopba lép.

Fejlesztés:
Itt a feladat lefagy, amíg a funkció fejlesztése be nem fejeződik. Ha elkészült, a következő oszlopba lép.
Vagy ha az architektúra nem megfelelő vagy pontos, a feladat visszakerülhet az előző oszlopba.

Tesztelés:
A feladat ebben az oszlopban van, amíg tesztelés alatt áll. Ha hibákat talál, akkor visszakerül a Fejlesztésbe. Ha nem, akkor továbbmegy.

Telepítés:
Minden projektnek megvan a saját telepítése. Egyesek számára ez azt jelenti, hogy a termék új verzióját kell feltenni a szerverre, másoknak pedig egyszerűen a kód behelyezését a tárolóba.

Befejezett:
A matrica csak akkor kerül ide, ha a feladattal kapcsolatos összes munka befejeződött.

Minden munkában vannak sürgős feladatok. Tervezett vagy nem, de azokat, amelyeket most azonnal meg kell tenni. Az ilyenek számára külön helyet jelölhet ki (a képen „Expedite” jelzéssel). Egy sürgős feladatot behelyezhet az Expedite programba, és a csapat azonnal elkezdhet dolgozni rajta, és a lehető leggyorsabban elvégezni. De ilyen feladat csak egy lehet! Ha megjelenik egy másik, azt hozzá kell adni a „Feladatsorhoz”.

És most a legfontosabb. Látod a számokat az egyes oszlopok alatt? Ennyi feladat lehet egyszerre ezekben az oszlopokban. A számokat kísérletileg választják ki, de úgy gondolják, hogy a csapatban lévő fejlesztők számától függenek.
Például, ha egy csapatban 8 programozó van, akkor a „Fejlesztés” sorba beírhatja a 4-es számot. Ez azt jelenti, hogy a programozók egyszerre legfeljebb 4 feladatot végeznek el, ami azt jelenti, hogy sok okuk lesz rá. kommunikálni és tapasztalatokat megosztani. Ha odaírja a 2-es számot, akkor 8 két feladatot végző programozó megunhatja, vagy túl sok időt veszíthet a megbeszélésekre. Ha 8-ra állítja, akkor mindenki elvégzi a saját feladatát, és néhány feladat sokáig ott marad a táblán, de a Kanban fő célja, hogy csökkentse azt az időt, amely alatt egy feladat az elejétől a kész szakasz.
Senki nem fog pontos választ adni arra, hogy mik legyenek ezek a korlátok, de először próbáld meg elosztani a fejlesztők számát 2-vel, és nézd meg, hogyan működik ez a csapatodban. Ezek a számok azután a csapatának megfelelően módosíthatók.
A „fejlesztők” alatt nem csak a programozókat értem, hanem más szakembereket is. Például a „Tesztelés” oszlop esetében a fejlesztők tesztelők, mert a tesztelés az ő felelősségük.

Az ilyen táblán lévő feladatok nem csak feladatok, hanem az úgynevezett Minimum Marketing Feature, azaz egy olyan szolgáltatás, amely „eladható” az ügyfeleknek.
Jó teszt az MMF számára, ha felteszi magának a kérdést: „Írnék erről a funkcióról a vállalati blogon?” Ha nem, akkor nem MMF.

Milyen újat és hasznosat ad egy ilyen limitekkel ellátott tábla?

Először, A párhuzamos feladatok számának csökkentése nagymértékben csökkenti az egyes feladatok végrehajtási idejét. Nincs szükség kontextusváltásra a feladatok között, a különböző entitások nyomon követésére, ütemezésére stb. - csak az történik, ami szükséges. Nem kell sprint tervezést és 5%-os workshopokat szervezni, mert a tervezés már megtörtént a „feladatsor” oszlopban, és a feladattal kapcsolatos részletes munka CSAK akkor kezdődik, amikor megkezdődik a feladat végrehajtása.

Másodszor, a dugók azonnal láthatóak. Például, ha a tesztelők nem tudnak megbirkózni a teszteléssel, akkor nagyon hamar kitöltik a teljes oszlopukat, és az új feladatot végrehajtó programozók már nem tudják áthelyezni azt a tesztelési oszlopba, mert tele van. Mit kell tenni? Itt az ideje, hogy emlékezzünk arra, hogy „egy csapat vagyunk”, és megoldjuk ezt a problémát. Például a programozók segíthetnek a tesztelőknek elvégezni az egyik tesztelési feladatot, és csak ezután helyeznek át egy új feladatot a szabad helyre. Ez mindkét feladatot gyorsabban elvégzi.

Harmadszor, kiszámíthatja egy átlagos feladat elvégzéséhez szükséges időt. A kártyán fel tudjuk jelölni a feladatsorba való felvétel dátumát, majd az indítás dátumát és a befejezés dátumát. Ezt a három pontot felhasználva legalább 10 feladatnál már kiszámolható az átlagos várakozási idő a feladatsorban és az átlagos feladatvégzési idő. És ezekből a számokból a menedzser vagy a terméktulajdonos már kiszámolhat, amit akar.

Az összes Kanban három alapvető szabállyal írható le:
1. Vizualizálja a termelést
- Oszd fel feladatokra a munkát, írj fel minden feladatot egy kártyára, és helyezd ki a falra vagy a táblára.
- Használjon elnevezett oszlopokat egy feladat állapotának megjelenítésére a termelésben.
2. WIP korlátozása(folyamatban lévő vagy egyidejűleg végzett munka) mindegyiken gyártási szakaszban.
3. Mérje meg a ciklusidőt(átlagos idő egy feladat elvégzésére) és folyamatosan optimalizálja a folyamatot csökkenteni ezt az időt.

Csak 3 szabály!
Például a SCRUM-ban 9 alapszabály van. XP-ben - 13, és a klasszikus RUP-ban - akár 120. Érezd a különbséget.

Itt fejezem be az első cikket a Kanbanról.
Várom visszajelzéseiket és észrevételeiket, valamint javaslataikat a jövőbeni cikkekhez.

Maria Denisenko, a pénzügyi és beszerzési szakértő, a ScrumTrek kiemelt projektek fejlesztésének vezetője mesél a módszer bevezetésének tapasztalatairól az egyik orosz minisztérium pénzügyi osztályán. Ezt a rovatot azoknak a vállalkozások képviselőinek is érdemes elolvasniuk, akik a módszertant szeretnék megvalósítani projektjeikben.

Mit kellett volna tennem?

Miután 2013-ban csatlakoztam az Orosz Föderáció Digitális Fejlesztési, Kommunikációs és Tömegkommunikációs Minisztériumának beszerzési részlegéhez, egy teljes szervezeti egység tevékenységének megszervezésének folyamatát kellett választani. A munkát az új jogszabályi követelményeknek megfelelően „a nulláról” kellett megszervezni. A 94-FZ törvényt a szerződési rendszerről szóló új törvény váltotta fel - 44-FZ törvény.

Két feladat előtt álltam. Egyrészt egyértelműen ki kellett építeni az új szabványoknak megfelelő beszerzésszervezési rendszert. Ez pedig azt jelenti: új folyamatok, új dokumentumok, új elektronikus rendszerek, új emberek. Másrészt mindezeket az újításokat rá kellett erőltetni a szervezet jelenlegi realitásaira. Hiszen bizonyos folyamatok a szervezetben már léteztek, sőt működtek is. Helyi fellépések hegye volt (több mint huszonöt).

Volt egy szakembergárda – egy egész osztály. De nem volt szerkezet. Nem volt hatékony javítási folyamat. Nem tudták a tevékenység célját. A szakemberek túlterheltek voltak.

A beszerzési osztály tevékenységét szabályozó összes rendelkezésre álló dokumentum (alkalmazotti munkaköri szabályzatok és a szerkezeti felosztásokra vonatkozó szabályzatok, beszerzési és átvételi megbízások létrehozásáról szóló utasítások, beszerzési és szerződéskötési utasítások), valamint a beszerzési osztály tevékenységét szabályozó összes rendelkezésre álló dokumentum meglehetősen hosszas tanulmányozása után minisztériumi alkalmazottak, arra a következtetésre jutottam, hogy először az egész folyamatot vizualizálni kell. Értsd meg és értelmezd azt, ami most létezik.

Mik voltak a problémák?

Ennek eredményeként kiderült, hogy egyrészt sok fontos folyamat van, amely nem szabályozott. Például a szerződés aláírásra történő átadása, a panaszokkal kapcsolatos dokumentumok elbírálásának időzítése, az indoklás folyamata és a beszerzés tervezése. És az állami és önkormányzati beszerzések területén minden szakember tudja, hogy ezen jelentős intézkedések bármelyikének hibája egy adott munkavállaló adminisztratív felelősségre vonásához vezethet.

Másrészt sok olyan folyamat van, amely teljesen független a beszerzési szervezeti egység tevékenységétől, de az alkalmazottak végzik. Például a műszaki leírások elsődleges követelményeinek kialakítása, a szerződés végrehajtásában való részvétel.

A beszerzési osztály munkatársai gyakorlatilag nem kommunikáltak a működő ügyfelekkel (a minisztérium megrendelő szervezeti egységeivel). És ez a tény az összes közös vagy egymást követő folyamat jelentős növekedéséhez és bonyolultságához vezetett. A menedzsmentet rengeteg mikromenedzseri funkcióval terhelték meg, teljesen blokkolva az irány stratégiai fejlesztésének lehetőségét. Megrendelések folyamatos aláírása, szerződések ellenőrzése, problémák megoldása a beszerzési osztály és a beszerzésben részt vevő egyéb részlegek interakciójában.

A feladatok áramlása annyira rendszertelen és nagy volt, hogy a munkavállalók mindegyike „sikeresen” indokolta a munkaszerződés pontját, amely szerint az állami közalkalmazott „szabálytalan munkaidőben” dolgozik.

Mit tettem?

Még nem tudván, hogy a Kanban-módszer létezik a fejlett világban, intuitív módon már követtem az elveit és alkalmaztam gyakorlatait.

Vizualizált folyamatok

Nehéz volt és elég hosszú. Néhány folyamatot erőszakkal el kellett távolítani a kapcsolódó részlegek alkalmazottaitól. Néhányan már a munka során nyilvánvalóvá váltak. Ehhez a felső 1 szinttől a hétköznapi szakember szintjéig kellett kommunikálni a munkatársakkal, vizuálisan kiszűrni a felesleges funkcionalitást, felépíteni a rendszert. Jól láthatóvá váltak a szűk keresztmetszetek, a felesleges dokumentumok, az új munkatársak iránti igény.

Elmagyarázta a menedzsmentnek a „húzórendszer” alapelveit

Ugyanakkor a folyamatokat úgy építette fel, hogy a minisztérium megrendelői osztályai, akiknek a kérései alapján a beszerzéseket lebonyolították, egyértelműen megértették az elfogadott és halasztott kötelezettségek közötti különbséget. A „dedikált sáv” WIP-korlátja napról napra ésszerűbbé vált, amíg el nem érte az egyegységes szabványt. Nem tértünk át azonnal a „mindent sürgősen”-ről a rangsorolásra és a húzásra. Nem azonnal.

A vezetőség nehezen tudja megmagyarázni, miért nem vállalták még el a feladatukat. A legtöbb vezető számára a hetekig „folyamatban” lógó feladatok jobbak, mint az aktuálisan végzett munka, és az egyéb, elkötelezettségre váró feladatok.

Véleményem szerint a prioritások meghatározása és az áramlás korlátozása bizonyult a legnehezebb feladatnak. Ez a minisztérium, mondták, itt minden fontos. Itt minden sürgős. A megrendelő szerkezeti egység minden vezetőjének pedig, akkoriban körülbelül tizenketten volt, joga van feladatot kitűzni a beszerzési egységre. Egy év nagyszabású felvilágosító munka után arra a következtetésre jutottunk, hogy a beszerzési osztály prioritásait én határoztam meg. A legfelsőbb szintű vezetők (miniszter-helyettesek) ritka hívásai pedig a prioritás megváltoztatásához vagy a kiosztott sávhoz feladatok hozzáadásához vezettek.

Együttműködtünk a vezetőséggel és a csapattal, hogy megértsük, mit jelent a „célnak megfelelő” szolgáltatásunk.

Ez a rendszer összeomlása volt. Azok az emberek, akik egy nagy minisztérium „technikai” munkájának egy kis területén dolgoztak, nehezen tudtak megérteni a célt és a minőséget. Szinte az egész csapatot le kellett cserélni. Sőt, a szakemberek kiválasztása volt a kulcsa az irány további fejlesztésének sikerének. Ezért nagyon komolyan közelítettem hozzá, figyelembe véve többek között a 79-FZ törvényben szabványosított kiválasztási jellemzőket.

Az alkalmazottak cseréje meglehetősen gyakori jelenség, amikor a tevékenységek szervezésének megközelítése megváltozik. Új feladatok, a munka új jellemzői – nem minden alkalmazott áll készen mindezt ellenállni. Körülbelül egy évvel az alkalmazottak cseréje után új munkarendszerre váltottunk: zárt irodából nyitott térré, állandó megbeszélésekkel és értekezletekkel, megválaszolatlan hívásoktól ügyfélközpontúságig, a dokumentumok elkészítésekor elkövetett hibák kifogásaitól a csapatig. dolgozzon rajtuk. És az új folyamatparadigmának megfelelően már kiválasztottam az összes későbbi alkalmazottat a beszerzési osztályra.

Dolgozott az elégedetlenség forrásaival a jelenlegi rendszerben, és visszacsatolási hurkokat valósított meg

Arra biztatlak, hogy folyamatosan és szorosan dolgozz velük. Véleményem szerint ez a haladás fő motorja. Az evolúciós fejlődés elvének megvalósítása. Ezt megelőzően egyszerűen nem fogadták el a „visszajelzések” gyűjtését a szervezetben érdekelt felektől. Senki nem hívott visszajelzést a „panaszokon” kívül. Mindezek a panaszok pedig örökre a vezetőség homályába süllyedtek, és csak személyes megrovásban részesültek az alkalmazottaknak.

Rendszeresen kaptunk visszajelzést szervezett csatornákon keresztül (szolgáltatási igények vezetői szintre, félig hivatalos megbeszélések, minőségellenőrzési hívások). Rendszerré alakítottuk. Az ilyen közös munka eredményeként pedig strukturálódtak a minisztériumi szerződéses szolgáltatás folyamatai, amely a legfrissebb adatok szerint mintegy 80 alkalmazottat foglalkoztatott.

A vezetés megnyilvánulásának ápolása is kihívást jelentett

A helyzetet bonyolította, hogy a munkavégzés sajátosságait figyelembe véve minden munkavállalónak nemcsak felelőssége volt, hanem felelőssége, amelyet adminisztratív felelősség is alátámasztott (a beszerzés területén elkövetett szabálysértéseket a vonatkozó cikk szerint minősítik). a közigazgatási kódex). Egy olyan rendszerben, ahol a „bónuszok” csak a miniszter háláját és minden jogsértésért 3-50 ezer rubel felelősséget tartalmaznak, senki sem vágyott arra, hogy „vezető legyen”.

Eleinte kis csoportokban adtam kis feladatokat. Később a kollégák spontán módon növelték a probléma megoldásában részt vevő dolgozók számát. Workshopokat és ötletbörzeket tartottunk. Belső munkavállalói képzési projektek szervezése. Mentori intézetet ápoltunk, amikor a beszerzési részleg új munkatársakkal bővült.

A közös munka hamarosan általánossá vált. Mostanra szinte minden feladatot több alkalmazott látott el (vállalt vagy felügyelt). Csökkent a hibák száma (majdnem ötszörösére), és az egyes telephelyeken nőtt a munka sebessége. Elkezdtünk időben hazamenni, kivéve a szezonális költségvetési és tervezési időszakokat.

A teljesítmény javítását célzó szabályok kialakításakor bizonyos nehézségekbe is ütköztünk

A folyamat vizualizálása és a munka WIP-korlátok figyelembevételével történő tesztelése után a menedzsment a folyamatok szabályozása mellett döntött (na, hol lenne e nélkül egy kormányhivatal). És minden későbbi változtatást jóváhagyással kellett végrehajtani. De a rugalmas megközelítés általános paradigmáját követve az ilyen jóváhagyások meglehetősen fájdalommentesen mentek végbe. És részben megoldódtak az én szintemen.

Megalkottuk a szerződéses szolgáltatási szabályzatot. Ez egy folyamatdokumentum, amely a folyamatok vizualizálása és jogszabályi normákkal való összekapcsolása, valamint a funkcionalitás újraelosztása után jött létre. Életben volt, állandó változásoknak volt kitéve a hibakeresési folyamatok eredményei alapján, valamint a jogszabályi normák változása esetén.

A feladatok kihúzásának elvét a kezdeti szakaszban jelentősen bonyolították a beszerzés jogszabályi sajátosságai

Ezek a folyamatok szigorú határidőkkel és a 44-FZ törvényben meghatározott egyértelmű végrehajtási folyamattal rendelkeznek. Minden szabályozva van: a beszerzési terv és a beszerzési ütemterv összeállítása és közzététele, a beszerzési hirdetmény közzétételének és a dokumentáció feladásának ütemezése, a résztvevők jelentkezésének elbírálásának és a szerződés aláírásának időpontja. Mindezt a WIP-korlátokkal összefüggésbe hozni és az ideális kézbesítési sebességet kidolgozni nem könnyű feladat. És figyelembe véve a jogszabályok állandó változásait, egy ilyen rendszer egyáltalán nem fog működni állandó evolúciós fejlődés nélkül.

mi az eredmény?

Idővel sikerült rendszereznem, elmélyíteni és bővíteni a tudás és a felhalmozott tapasztalatok teljes integritását a Kanban módszer elsajátítása során. Feltárult néhány korábban el nem számolt folyamat használatának fontossága. A mérőszámok köre jelentősen bővült. Megértjük a módszer alkalmazhatóságának szélességét. Az alapelvek rendszere teljesen kiépült (most már nem csak megértettem, de könnyen nyilvánvalóvá is tudtam tenni őket mások számára).

Több mint öt éves munkatapasztalat alapján egyértelmű következtetést tudok levonni arról, hogy a kanban hatékonyan tud működni a pénzügyi blokkban. Ezenkívül jelentősen megkönnyíti a pénzügyi egység és a szomszédos strukturális részlegek interakcióját.

A fent bemutatott alapelvek és gyakorlatok rövid útmutatóként használhatók a Kanban bevezetéséhez a pénzügyi osztályon. Ugyanakkor szeretném felhívni a figyelmet arra, hogy ebben a cikkben nem érintettük a kanban megvalósításának szisztematikus megközelítésének (S.T.A.T.I.K.) részletes szempontjait. Ezt a témát külön cikkben tárgyaljuk.

Sajnos a folyamatokat nem tudtam szélesebb körű szolgáltatásokra skálázni. De a pénzügyi részlegekkel szomszédos tömbökben a kanban módszer alkalmazása is lehetséges és hatékony, még a közszféra sajátosságait is figyelembe véve. És hamarosan megosztjuk veletek egy ilyen eset eredményét.

A Kamban menedzsment a gazdasági gyakorlatban az üzleti tevékenység olyan megszervezését jelenti - legyen az gyártás, logisztika vagy kiskereskedelem -, amely a just-in-time rendszerként jellemezhető. Maga a „Kanban” kifejezés, amelyet japánul „látható kártyának” fordítanak, magában foglalja az üzleti optimalizálás megközelítését műveletekre osztva és a munkafolyamat megjelenítésével. És bár a Kanban-filozófiát először a Toyota használta több mint fél évszázaddal ezelőtt, ezt a modern értelemben vett módszert David Anderson közgazdász fejlesztette ki és javasolta.

Mi az a Kanban rendszer?

David Anderson közgazdász 2005 tavaszán Tokióban, a császári palota keleti kertjében tett séta során arra a következtetésre jutott, hogy az újrafelhasználható, többszínű, Kanban nevű műanyag jegyek a turisták számára a gazdasági tevékenység eszközévé válhatnak. a bizonytalanság feltételei. Azzal, hogy sétát tett és megfordult a Kanbanban, lényegében befejezte a „gondolatbeli munkát”. Az ellenőrök egy speciális oszlopos táblára feljegyezték a kártyák kiállítását és visszavételét a látogatóknak.

Anderson arra a következtetésre jutott, hogy kártyákon és oszlopokon keresztül lehet például ellenőrizni a raktárkészletet vagy az áruszállítást. A just-in-time koncepciónak köszönhetően lehetővé válik az anyagköltségek minimalizálása és az értékesítés optimalizálása. Valami hasonlót használtak a Toyota gépészeti gyártásában még a múlt század 60-as éveinek végén, de akkor az egyidejűleg elvégzett feladatok száma minimális volt, a munka szigorú algoritmus szerint zajlott.

Anderson tehát a Kanban táblát értékes gyártási eszköznek tekintette, amelyet a Kanban: Succesful Evolutionary Change for Your Technology Business című könyvében írt le.

Mit tesz a Kanban a gyártásért?

A David Anderson által megfogalmazott Kanban módszertan tehát egy evolúciós feladatkezelési folyamat, amely magában foglalja a munka (szállítások) pontos megszervezését.

„A fő elv az, hogy minden munka ne legyen hiábavaló” – mondja Maxim Yurkin közgazdász. - A Kanban lehetővé teszi az üzletember számára, hogy egy projekt szakaszait még az indulás előtt optimalizálja, a hasonló munkák befejezéséről szerzett vizuális információk alapján. Erre épül a „lean gyártás”.

Ha összehasonlítjuk az Anderson-féle módszertan bevezetése előtti és utáni gyártási folyamatokat, láthatjuk, hogyan csökkennek az anyagköltségek nap mint nap. Ugyanakkor a dolgozókat a Kanban kártya „Kész” („kész” „éppen időben”) bejegyzése irányítja. Az Anderson-módszert alkalmazó vállalkozók 25-30%-os jövedelmezőség-növekedésről számoltak be – jelentősebb beruházás nélkül. Az idő múlásával a Kanban módszer egyre elterjedtebb és egyre igényesebb a közép- és kisvállalkozásokban.

Hogyan lehet bevezetni a Kanbant egy cégben?

Az orosz médiában megjelent publikációk elemzése azt mutatja, hogy a Kanban megvalósítása sok esetben egy „just-in-time” ellátórendszer integrálását jelenti, amely speciális táblákat használ a „to do” (kezdett munka), „in” oszlopokkal. haladás” (munka), „review” ” (munka felülvizsgálata), „teszt” (eredmény), „kész” (befejezett). Így minden alkalmazott tevékenysége ellenőrzött, és nem állhat elő olyan helyzet, amikor az egyik alkalmazott rengeteg teljesítetlen feladatot halmozott fel, míg egy másik tétlenül ül.

Anderson könyvének orosz olvasója azt gondolhatja, hogy a Kanban ellentmondásos. Ez olyan, mintha a kocsit a ló elé tennénk, mert a hagyományos tervezés a semmiből történik. Ez a módszer arra ösztönöz, hogy „hagyd abba az indulást és kezdd el befejezni”.

A Kanban 4 alapelve

A JIT rendszer megértéséhez és sikeres bevezetéséhez a Kanban kilenc alapvető dologára kell figyelnie: 4 alapelvre és 5 szabályra. Kezdjük az elvekkel:

• Mindig értékeld, amit csinálsz.
• Készülj fel az evolúciós változásokra.
• Tartsa tiszteletben a szerepeket, felelősségeket és címeket.
• Az informális vezetők ösztönzése.

A helyzet az, hogy a Kanban koncepció nem ad „vas” beállításokat, még kevésbé ír elő „terápiás” eljárásokat. Éppen ezért Anderson azt tanácsolja, hogy a meglévő munkafolyamatokon felül „superpozáljon” szabályokat, amelyeket naponta be kell tartani a termelésben. Vegye figyelembe, hogy a Kanban-módszer magában foglalja a legkisebb ellenállás útjának követését. Más szóval, ösztönzi a jelenlegi rendszer folyamatos inkrementális és evolúciós változtatásait, mivel a forradalmi változás jelentős ellenállásba ütközik – mind az alkalmazottak, mind az ügyfelek részéről.

David Anderson arra ösztönöz, hogy értékeljék a meglévő üzleti folyamatokat, valamint az alkalmazottak szerepkörét, beosztását és felelősségét. Más szóval, ha egy eljáráson belül néhány folyamatot helyesen hajtanak végre, akkor érdemes megmenteni azokat. A korszerűsítésükhöz később, más folyamatok fejlesztésekor térhet vissza. Fontos megérteni, hogy a fokozatos változás nem kelthet olyan félelmet, amely akadályozza a fejlődést. Szükséges egy olyan csapat összeállítása, amely lehetővé teszi az üzletember számára az új termékek széles körű bevezetését, és ezáltal megkönnyíti a Kanban koncepció megvalósítását.

Azt is meg kell jegyezni, hogy minden csapatban vannak olyan emberek, akik élvezik a tekintélyt, még akkor is, ha nem töltenek be magas pozíciókat. Azonban meghallgatják és tisztelik őket. Bölcs dolog előmozdítani karrierjük növekedését. Az ilyen informális vezetők ösztönzése pozitív hatással van a vállalkozás egészének egészségére.

A Kanban 5 szabálya

A 4 alapelven kívül David Anderson „Kanban: Sikeres evolúciós változások a technológiai üzletedben” című könyvében 5 alapvető szabályt írt le, amelyeket a sikeres üzletemberek betartanak:

• A munkafolyamat vizualizálása.
• A folyamatban lévő munka korlátozása (WIP - Work-In-Progress).
• Munkafolyamat menedzsment.
• A változások egyértelműsége és átláthatósága.
• Az együttműködés javítása (modellek és tudományos módszer alkalmazásával).

Beszéljünk részletesebben a szabályokról. Mivel a Kanban célja a munkafolyamat pozitív megváltoztatása a következetes optimalizálás révén, mindenekelőtt meg kell válaszolnunk a fő kérdést: mi a célja az üzleti evolúciónak? Ezt csak a folyamat működésének megértése után lehet megtenni. Csak ezután célszerű megpróbálni integrálni a just-in-time koncepciót.

Az üzleti folyamatok vizualizálása nagyon hatékony módszer. Vizualizálni lehet az úgynevezett Kanban tábla vagy a LeanKit platform segítségével. Vegye figyelembe, hogy a LeanKit támogatja a lean gyártási elvek megvalósítását, hogy megteremtse a feltételeket az üzleti folyamatok folyamatos fejlesztéséhez és az innovációk integrálásához.

„A vizualizációs módszerek ugyanolyan változatosak, mint az optimalizált munkafolyamatok” – magyarázza Maxim Yurkin. "A munkafolyamat és a végrehajtási idő mellett más kritériumok is használhatók, mint például a piaci kockázat és a késedelem költsége a tevékenységek osztályozása során."

Ha helyesen képzeli el a munkafolyamatot, könnyen megtalálhatja az „üzleti gyilkosoknak” nevezett WIP-töredékeket.

„Ez azt jelenti, hogy a folyamatban lévő munkák elleni küzdelemnek a teljes munkafolyamat során folytatódnia kell” – írja David Anderson. - Mert az időben el nem végzett munka a negatívot „átviszi” a következő lépésre, majd a negatívumot a duplájára a következő lépésre. És olyan, mint egy hógolyó. A WIP nullára csökkentése a Kanban sarokköve.”

A visszajelzés nagyon fontos. A változtatások elvégzése után meg kell győződnie arról, hogy valóban javulás következik be.

„A Kanban-módszer egy izgalmas utazás, amikor nem tudod, hol fogsz végezni” – emlékeztet David Anderson. "Egy probléma megoldása súlyosbíthat egy másikat."

Annak elkerülése érdekében, hogy a változtatások végrehajtásának folyamata zsákutcába kerüljön, a projekt minden résztvevője számára érthetőnek kell lennie. Ebben a tekintetben logikus egy másik Anderson-idézet idézni: „A dolgok működésének világos megértése nélkül a problémák minden megvitatása érzelmi jellegű, anekdotikus és szubjektív. Ez olyan igaz, mint egy térdrángató reakció.”

A Kanban módszerben a kulcsfogalom a Kaizen, ami folyamatos, inkrementális és pozitív változást jelent.

„A JIT-t integráló üzletembernek meg kell értenie, mi az a Kaizen” – mondja Anderson. "Ha nem elkötelezett a fejlesztés iránt, nincs értelme a Kanban alkalmazásának."

Kanban vs. Agilis

Nyilvánvaló, hogy a Kanbannak vannak ellenzői, akik azt állítják, hogy más fogalmak jobbak. Mindeközben a szakértők arra buzdítják, hogy ne keverjék össze az Anderson-módszert más elismert irányítási rendszerekkel – szerintük ez olyan, mintha az almát a naranccsal hasonlítanánk össze. A Kanban-koncepció leggyakrabban a következőkkel áll szemben:

• Agilis;
• Dulakodás;
• Sovány;
• Hat Szigma;
• HERCEG2.

Mindeközben a Kanban és az Agile hasonlít egymásra, mint testvérek, azzal az egyetlen különbséggel, hogy Anderson egy szélesebb módszert javasolt, míg az Agile inkább az informatikai projektekre összpontosít. Mindkét módszer evolúciós változásokkal jár, bár az első esetben az üzletember szerepe összehasonlíthatatlanul jelentősebb, mint a munkavállaló státusza az Agilis Kiáltvány szerint.

Ha a Kanban kibékíthetetlen harcot foglal magában a folyamatban lévő munkával szemben, akkor az Agilis filozófia e tekintetben liberálisabb, mivel a rugalmasságot – az eredeti tervnél fontosabb változtatásokra való készséget – helyezi előtérbe.

A programozók nagyobb valószínűséggel vizsgálják meg az „elhagyott alprojekteket”, ha találnak egy optimálisabb szoftverarchitektúrát. A Dostaevsky, Chernika, uKit Group és mások cégei elmondhatják, hogy a Kanban hatékony módszer Oroszországban.

Következtetés

A Kanban egy intuitív módszer a munkafolyamat megszervezésére, amely segít az üzletembereknek többet és gyorsabban dolgozni. A „just in time” rendszer azonban nem csodaszer minden problémára, hanem egy olyan eszköz, amelyet helyesen kell tudni használni, minden nap finom változtatásokat végrehajtva a munkafolyamatban, amelyek együttesen hoznak eredményt.

Vegye figyelembe, hogy a Kanban nem hatékony az összetett többszintű technológiai rendszerekben, de szinte ideális kis- és középvállalkozások számára.

Mi az a kanban módszertan, és hogyan segíti a feladatok időben történő elvégzését?

Folyamatos multitasking és nagyszámú ügyfél mellett előbb-utóbb bármely rendszer túlterhelődik. A határidők kezdenek elmaradni, az elvárások nem teljesülnek, a rendszer káoszba fordul. Ma azt javaslom, hogy ismerkedjünk meg egy olyan módszerrel, mint a kanban. Ez a megközelítés az erőforrások hatékony elosztását és minden problémánk megoldását ígéri. Ellenőrizzük.

Egy pillanat a kanban történelemből

A kaban ötlet alapját a Toyoyta Motors találta ki. Egy autógyártó súlyos veszteségeket szenvedett a gyártósoron a raktárkészlet és a kapacitás helytelen elosztása miatt. Egyes gyártási szakaszok tétlenül működhettek, néhány pedig túlterhelt volt.

1959-ben javasoltak egy gyártásellenőrzési rendszert, amely lehetővé tette a vonal összes szakaszának kiegyensúlyozását. Az alapelv az volt, hogy a munkások minden szakaszban feladták a szükséges számú alkatrészt tartalmazó kártyákat, amelyeket továbbadtak a soron. A gyártósoron minden dolgozó pontosan annyi alkatrészt vett el az előzőből, amennyit a kártyán kiosztottak neki.

Így minden részhez volt kártya, és egyszerűen nem lehetett felesleg. Ennek eredményeként a készletek nem növekedtek a területeken, és minden következő munkás pontosan annyi alkatrészt kapott, amennyire szüksége volt.

Fogalmazzuk meg, mi az a kanban, és alkalmazzuk az internetes termékek fejlesztésére.

A Kanban egy lean gyártásirányítási rendszer (japánul: "signal"/"card"), amely információs kártyákat használ a rendelések továbbítására a gyártás minden szakaszában. Egyszerűen fogalmazva, nyomon követjük a termék teljes útját, az ötlettől a bolt polcára kerüléséig.

Fent van egy kanban tábla. Ez a fő eszköz a feladat állapotának megjelenítéséhez. A fő elv: látjuk, hogy a gyártási folyamat mely szakaszában található egy adott feladat. Ráadásul az időt minden területen nyomon követik, vagyis mindig megtalálhatja a rendszerben a „ ” jelet, és dolgozhat velük.

Ön határozza meg az oszlopok számát a projekt jellemzői alapján. Fontos, hogy ezek a fő szakaszok, amelyeken a termék átmegy. A fenti példa plusz vagy mínusz az online termék főbb szakaszaira vonatkozik.

A módszertan alkalmazása nagyon széles. A Kanbant projekt-végrehajtásra, értékesítési menedzsmentre, gyártósorokra, IT-fejlesztésre, de akár saját életének megszervezésére is használják.

Elnézést az olvasás megszakításáért. Csatlakozz a távirati csatornámhoz. Friss cikkek bejelentései, digitális termékek fejlesztése és növekedési hack, minden megvan. Várok rád! Folytassuk...

Kanban alapelvek

• A feladatok vizuális megjelenítése. Minden feladatot kártyák formájában kell bemutatni és a táblán kell tükrözni. Nagyon fontos a feladatok állapotának frissítése. Például, ha a fejlesztők elkészítették a kódot és beküldték tesztelésre, akkor a feladatkártyának a megfelelő oszlopba kell kerülnie. Így a csapat bármely tagja bármikor láthatja, hogy a feladat melyik szakaszában van.
• A WIP (folyamatban lévő munka vagy egyidejűleg végzett munka) oszlopok korlátozása a gyártás minden szakaszában. Annak érdekében, hogy a rendszer előbb-utóbb ne „fulladjon ki” a feladatok áramlásától, korlátozásokat kell beállítani. Például a fenti kanban táblán az Analisis oszlopban (analytics) 2 ember dolgozik, és legfeljebb 2 feladatot tudnak kezelni, nincs értelme többet betölteni, mivel a rendszer további szakaszai tétlenek lesznek. Az oszlopkorlátozásokat empirikusan választjuk ki.
• Koncentrálj a teljesítetlen feladatokra. Amikor a feladatokkal ellátott táblát nézzük, mindenekelőtt azokra a feladatokra figyeljünk, amelyek egyik vagy másik oszlopban „lógnak”. Ha az egyik szakasz veszi el a legtöbb időt az Ön számára, akkor lehetőség szerint próbálja meg újra elosztani az erőforrásokat vagy adjon hozzá embereket.
• Folyamatos fejlesztés. Miután kiegyenlítette a terhelést a rendszerben, könnyebben nyomon követheti a teljes folyamatot. Mérje meg a ciklusidőt (mennyi ideig lóg a feladat egy külön oszlopban, és mennyi ideig tart attól a pillanattól kezdve, hogy bekerül a Teendők közé, a Kész megjelenéséig). Változtassa meg a rendszer terheléseit, és csökkentse az összes szakasz végrehajtásához szükséges időt.
• Ügyeljen a részletekre. Például, ha a fejlesztők által rendszeresen írt kód nem megy át a tesztelésen, és visszaküldik felülvizsgálatra, akkor talán van lehetőség a fejlesztés minőségének javítására, hogy egy jobb minőségű terméket teszteljenek?

A kanban megközelítés idealisztikusnak tűnhet, de biztosíthatom Önöket, hogy elvei eredményeket hoznak. Először is hozzá kell igazítania a módszertant az Ön helyzetéhez, majd csiszolnia kell a rendszert.

Kanban eszközök

Vagy hol kell karbantartani a kanban táblát.

• Excel táblázatok
• Tábla matricákkal
• Egy újabb fantázia...

Valójában nagyon sok lehetőség van, rákereshetsz a google-ban és meríthetsz egy kis ihletet. A lényeg az, hogy megvan ez a tábla, és a folyamat minden résztvevője láthatja, mi történik az adott pillanatban a feladatokkal.

Példák kanban táblákra

Itt van egy tábla, amely a falon lóg, ahol minden feladat öntapadó cetliken tükröződik.

Vagy lehet egy felhőszolgáltatás, mint a Trello.

Számos vélemény létezik arról, hogy milyen eszközöket és lehetőségeket használjon a munkája során, de ez többnyire ízlés kérdése. Csak próbáljon ki különböző megoldásokat, és döntse el azt, amelyik a legjobban tetszik. A lényeg, hogy kezdjük el használni a kanbant, és ne ragadjunk le a lehető legszebb tábla használatánál.

A véleményem a következő: ötletbörze vagy esetek offline munkája során jól működik egy normál matricás tábla. De a mindennapi munkához természetesen olyan felhőmegoldást kell használni, mint a Jira, Kanbantool, Trello stb. Ezekben az egész csapat megjegyzéseket fűzhet a feladatokhoz, mozgathatja azokat oszlopok szerint és még sok mást.

Árnyalatok/gondolatok

Ha internetes termékekről beszélünk, akkor a kanban működik, segít és javít, de számos aggályt vagy árnyalatot kell figyelembe venni.

• Valószínűleg egy oszlopon a WIP-korlátok bevezetése kissé megijesztheti a projektmenedzsmentet. Hiszen hogyan lehet meghatározni, hogy egy fejlesztő vagy például egy tesztelő hány feladatot tud párhuzamosan megoldani? Mi van, ha korlátozásokat vezetünk be, és csak lazítanak?

Látod, ha az ember nincs teljesen megterhelve, az nem rossz. Képes tanulmányozni és elemezni az elvégzett munkát, megtalálni a hiányosságokat és kijavítani azokat, sőt pihenni is tud. Ráadásul a folyamat más részeiről (oszlopokból) is segíthetsz társaidnak, további részletek alább.

• A kanaban guruk szerint a rendszer ideálisan működik többfunkciós csapatokban. Na, valami ilyesmi, ha nincs mit tenni, menj el segíteni egy munkatársnak. Igaz, ahhoz, hogy összeállítson egy csapatot, ahol a fejlesztők tesztelők lehetnek, és fordítva, a rendszertervező pedig segít a tervezőnek, sok pénzt kell kiforgatni, és megéri?

Természetesen nagyszerű, ha a csapattagok tanulnak egymástól, és tudnak segíteni valamilyen módon, ha valami történik. De ahhoz, hogy ez a feltétel teljesüljön, kis csapatokra van szükség, amelyek lehetőleg valahol a közelben ülnek és folyamatosan kommunikálnak. Nagy projekteknél nehéz reprodukálni egy ilyen tapasztalatcserét.

Ezért hajlamosabb vagyok a tudásom csiszolására, ha van egy csendes pillanatom. Nézze meg, mit tett, gondolja át, hogyan javíthatna rajta, olvasson hasznos cikkeket. Az ember élő szervezet, nem fogaskerék a futószalagon.

Teljes

Megvizsgáltuk a kanban módszertant, és most, remélem, megérti, hogyan kell alkalmazni a projektjében. Próbálja meg folyamatait fő szakaszokra bontani, és a megszerzett ismeretek alapján optimalizálja a rendszert.

Próbáltál már egy csoportot összehívni egy termék létrehozására vagy egy projekt elindítására? Bónuszként: szoros határidő, terjedelmes technikai feladat és megoldhatatlan ügyfél. Megtörtént? Ha igen, akkor nem kell tovább olvasnod.

Egy csapatot irányítani nem könnyű. Főleg digitálisban. A munkát úgy kell megszervezni, hogy a termék minősége magas legyen, a határidőket betartsák, a csapat kényelmes legyen, a megrendelő elégedett legyen. Fontos a konfliktusok elkerülése és a csapat folyamatos fejlesztése.

Nincs olyan varázstabletta, amely minden problémát egyszerre megoldana. De vannak olyan módszerek és rendszerek, amelyek segíthetnek leegyszerűsíteni a folyamatot. Az egyik a Kanban.

Mi az a Kanban

A Kanban egy módszer a fejlesztési folyamatok javítására és az agilis filozófia része. Az Agilis Szoftverfejlesztési Kiáltványon alapul.

Agilis szoftverfejlesztési kiáltvány

A Kanban célja, hogy időben megkapja a kész, jó minőségű terméket. Találjuk ki, hogyan érhetjük el ezt.

A Kanban a vizualizációval kezdődik, hogy a munkafolyamat látható legyen a csapat számára. Ehhez használjon speciális táblát és kártya- vagy matricakészletet.

A tábla egy agilis módszertan kötelező eleme. Scrumban van, Kanbanban is. Minden csapattag bármikor hozzáférhet hozzá, és láthatja, hogy a feladat melyik szakaszában van.

A tábla lehet valós vagy virtuális: használhat egy egyszerű parafa táblát vagy olyan programokat, mint a Trello.

A Kanban tábla egy univerzális eszköz, amely bármilyen folyamathoz igazítható és bármely területen alkalmazható. Például készítsen egy teendőlistát.

Először elemeznie kell a munkafolyamatot, és a táblát oszlopokra kell osztania, amelyek tükrözik a termék létrehozásának szakaszait. Például egy informatikai projekt létrehozásának szakaszai a következők lehetnek:

Az oszlopnevek a projekttől függően változhatnak, de fontos, hogy konzisztensek legyenek. A táblának teljes mértékben tükröznie kell az értékteremtési folyamatot, amelyet a Kanbanban flow-nak neveznek.

A Kanban kártyák olyan feladatok, amelyeket a csapat státuszától függően mozgat a táblán. A kártyák száma módosítható. Írd fel egy kártyára vagy matricára a feladat nevét, és ragaszd a tábla elejére!

A kanban tábla segítségével egy csapat több projektet is kezelhet egyszerre, különböző színű kártyákat használhat: egy szín - egy projekt.

Hogyan segít a vizualizáció

A terhelés kontrollálásával pontos eredmények érhetők el időben. Ehhez korlátozni kell a feladatok számát.

A kanban tábla egyik oszlopa egyszerre annyi feladatot tartalmaz, amennyit a csapat a meghatározott időkereten belül ténylegesen elvégz. Például a „Tervezés” állapotban legfeljebb két feladat van egyszerre, a „Tesztelés” oszlopban pedig csak egy. A csapat képességei szerint választja ki a létszámot.

Példa

A fejlesztő még nem végzett az aktuális feladattal, de a következőt már megkapta. Nincs ideje, és lelassítja az összes munkát.

Megoldás: Hagyja abba a feladatok fejlesztésre való átadását, és hagyjon időt a programozónak a munka befejezésére.

Fontos megtalálni az egyensúlyt: olyan munkatempót válasszon, amely kényelmes a csapat számára, és nem sérti a projekt határidejét. Ehhez a Kanban figyelembe veszi az egyes feladatok befejezési idejét. Így a csapat megérti, hogy mi az, ami több időt vesz igénybe, és mi az, ami kevesebb időt vesz igénybe, és megfelelően meg tudja szervezni a munkát.

Példa

A terméktesztelési szakaszban nehézségek merültek fel, és több időre van szükség.

Megoldás: megtudja, hogy a munka melyik részét lehet gyorsabban elvégezni a minőség romlása nélkül. Vagy egy alkalmazott, aki szabad, és segít a tesztelőnek.

Minden folyamat megjelenik a táblán, a csapat elemzi azokat, és kiküszöböli a gyenge pontokat. A Kanbanban ezt hívják áramlásszabályozás.

A Kanban használatához nem elég csak leakasztani egy táblát a kártyákkal. A csapatnak ismernie kell azokat a szabályokat, amelyek szerint működik.

A folyamat átláthatóságáról is szól: amikor a munka látható és az eredmény mindenki számára egyértelmű.

Fontos az egység, a folyamatos termékfejlesztés és az alkalmazottak fejlesztése. A Kanban csapata egyetlen mechanizmus. Ha valaki elbukik, akkor a közös ügy szenved. A munka egy táblán van megtervezve, az egész folyamat látható, így mindenki láthatja hozzájárulását, értékét a projekthez.

A Kanban ötvözi az agilis módszertan és a lean gondolkodás elveit. Itt nincsenek szigorú szabályok vagy drasztikus változások, de vannak elvek, amelyekre támaszkodhat.

Hogyan ne keverjük össze a Kanbant és a Scrumot

A Kanbant gyakran összekeverik vagy összekeverik az agilis Scrum módszertannal. Annak elkerülése érdekében, hogy ez megtörténjen, nézzük meg, melyek a fő különbségek.

Dulakodás egy rugalmas projektmenedzsment módszertan, ill Kanban- módszer bármely módszertan tökéletesítésére.

Nincsenek találkozók

Kell egy kiindulási pont

Szűk profilú csapatok dolgozhatnak

Következetes és zökkenőmentes változtatások

A csapatban nincs szereposztás

Találkozások vannak

Nincs szükség kiindulási pontra

A csapat már bevezette a Scrumot, de folytatni kívánja a folyamat fejlesztését. Itt ismét jól jön a Kanban.

Nem mindegy, hogy milyen fejlesztési módszertant alkalmaz a csapat, de a Kanban megvalósításához kell egy kiindulópont.

A Kanban megvalósítása

Ha a Kanban használata mellett dönt, türelmesnek kell lennie, és önfegyelmet kell tanulnia. Nem szabad ráhangolódnia a radikális változásokra, és minden gyakorlatot egyszerre alkalmazni. A Kanban a következetes és zökkenőmentes fejlesztésekről szól. Előfordulhat, hogy nem kell minden eszközt használnia a kívánt eredmény eléréséhez.

Foglaljuk össze

Most már tudja, mi az a Kanban rendszer, miben különbözik a Scrumtól és hogyan használható. És készek vagyunk mindent ellenőrizni működés közben. Az elmélet jó, de gyakorlatra van szükség. És jobb gyakorolni anélkül, hogy félne attól, hogy egy rossz mozdulat árthat a gyakorlatnak. Ezért, amely frissíteni fogja Önt a projektmenedzsmentben. Képes lesz bármilyen agilis rendszert beépíteni a munkájába, és magabiztos lehet az eredményekben.