Kako implementirati Kanban i lako se koristiti njime

Kanban se iznimno jednostavan za implementaciju počevši od top menadžmenta i odlično se kombinira s teorijom ograničenja prikazanih u knjizi „Cilj“ Eliyahua Goldratta. Kanban je odabran od strane odjela za tehničku podršku, administratora sustava, pa čak i voditelja ljudskih resursa i računovođa koji blisko surađuju s IT.

Jedna od glavnih značajki kojom se ističe jest načelo implementacije Kanbana: „Započnite s onim što imate, vizualizirajte proces i organizirajte evolucijske promjene procesa.

Vjerojatno ste pomislili: „Ne zvuči zastrašujuće, tko bi odbio takvo nešto?“ Ipak, kako bi se postigli vidljivi rezultati s poslovnog stajališta, bez većih promjena to neće funkcionirati.

Nakon nevine fraze „dogovorimo se o evolucijskoj promjeni procesa“ može slijediti koješta. Ako je Kanban implementiran s dovoljno iskustva, sve će se odviti vrlo precizno. Niže su opisane pogodnosti radi kojih vrijedi implementirati Kanban i prakse koje se mogu koristiti za optimizaciju procesa.

Pomoću tih metoda nije moguće naučiti programere da brže programiraju, ali većinu vremena vjerojatno će se dešavati da zadaci čekaju u redu, da su blokirani iz određenog razloga, a ponekad su i jednostavno zaboravljeni usred hrpe nedovršenog posla. Kanban se odlično nosi s uvođenjem reda u zadatke.

Prednosti implementacije

1) Kanban je osmišljen radi povećanja transparentnosti procesa unutar organizacije.

Često se događa da ljudi ne razumiju kako su organizirani procesi u dijelu tvrtke s kojim moraju surađivati. Na primjer, koliko marketing stručnjaka zna posao programera? I koliko programera razumije marketing?

Neznanje o organizaciji procesa nekog drugog odjela često uzrokuje da se stvori kriva slika i omalovažavanje rada drugih, a u takvim je uvjetima postaje teže održati komunikaciju, a odjeli čak mogu i međusobno zaratiti.

2) Kanban pomaže u borbi protiv „multitaskinga“ u svojim najgorim oblicima.

Ponekad „učinkoviti menadžeri“, najprije obavljaju kratke zadatke koji ne oduzimaju više od 5 minuta kako bi se jednom za svagda riješili trivijalnosti i zatim nastavljaju sa zahtjevnijim zadacima. No, većina dovitljivih klijenata počinje predstavljati svaki zadatak kao vremenski nezahtjevan a u isto vrijeme od visokog prioriteta.

3) Kanban omogućuje da više ne bavite procjenom vremena za ispunjavanje određenog zadatka.

Umjesto toga savjetuje se korištenje statističkih metoda. Zamislite da izmjerite promjer poprečnog presjeka vodene cijevi i brzinu protoka, a ne predvidite koliko brzo će određena kap (čak i ako bude označena plavom bojom) letjeti kroz cijev od točke A do točke B.

Korisni alati za učinkovitiji Kanban

Za razliku od Scruma, čiju implementaciju prate brojni „rituali“, uvođenje Kanbana se događa glatko i gotovo neprimjetno. Međutim, on također ostvaruje i manji ekonomski učinak na početku, budući da obična ploča, bez obzira na to koliko lijepo izgledala, ne podrazumijeva da je implementiran i čitav Kanban sustav.

Kanban ploča

Kanban ploča cijele organizacije i s njom povezane ploče niže razine za raspodjelu. Radi se o važnom atributu, ali njegova prisutnost još ne jamči prisutnost fleksibilnog razmišljanja i prisutnosti bilo koje metodologije u upravljanju organizacijom. Mnoge implementacije i završe u ovoj fazi.

Upute za implementaciju:

1) Utvrdite kroz kakva stanja zapravo prolazi Vaš tipični zadatak. Opcije „bijes, očaj, pregovaranje, depresija, prihvaćanje“, se naravno, ne prihvaćaju, ali čuju se iznenađujuće često.

Na primjer, mogli bi iskoristiti ove kategorije po stupcima za sveukupni IT proces (strateška razina):

Na čekanju | U tijeku | Analiza | Projektiranje | Dizajn | Razvoj | Ispitivanje | Zaključak

Ili takva (za namjensku podjelu UX-dizajnera):

Na čekanju | U tijeku | Model | Prototip | Layout | Predano na razvoj

I druga ploča može biti dešifriranje riječi „Dizajn“ s prve ploče, kada jedna kartica na velikoj ploči izgleda kao puno malih podzadataka za dizajn na tehničkoj.

Minimalni, univerzalni „komplet“ se sastoji od tri stupca: projekti na čekanju (što treba učiniti), projekti u tijeku i gotovi projekti. Na taj način dobivate jednostavan alat koji vrlo pregledno pomaže da bolje prezentirate svoj „radni proces“.

2) Iscrtajte i formirajte pravu ili virtualnu ploču. U prvoj fazi, preporučeno je da se objesi samo plastična (za markere) ili plutena ploča na zid i razdijeli se s linijama u skladu s namijenjenim procesom.

Fizičko premještanje kartica na ploči pruža određeno zadovoljstvo, no stvara i neugodnosti, pogotovo podijeljenim timovima. Nakon 2-3 tjedna, kada točno shvatite uvjete vaših poslova, možete se prebaciti na elektroničku verziju.

Ograničenje broja poslova u procesu. (WIP limit)

Ova praksa je najbitniji dio Kanbana i bez nje je ostvarivost ekonomskog učinka puno manje vjerojatna. U praksi autora, pri uvođenju limita uvijek se javlja ozbiljni otpor, budući da se ograničenje zadataka u svakom statusu intuitivno percipira kao ograničenje prava i sloboda radnika, što u stvari nikako nije slučaj.

Kako implementirati:

1) raspravite o gomili nedovršenih zadataka (ako ih ima) i uhvatite se u koštac s njima;

2) uvedite ograničenje na stupcu gdje je najviše toga nagomilano i samo na njemu;

3) čim se posveti posebna pozornost određenom dijelu procesa i ukloni „blokadu“ na tom mjestu, tada će dio gdje zapinje nastati an nekom drugom dijelu proizvodnje, te valja pronaći novi dio gdje „zapinje“ i staviti ograničenje na taj stupac

(čak i ako radi toga morate uvjeriti susjedni tim da se također opremi Kanban pločom, zašto ne);

4) dosljedno provodite i stavljajte ograničenja na stupcima na ploči koji su povezani s procesom koji Vam je potreban, ali ne do te mjere da ljudi besposleno sjede samo radi uvedenog pravila. U bilo kojoj kombinaciji mora ostati mali, prikladni obujam posla.

Inicijativa za uvođenje ove prakse najbolje je preuzeta iz samih izvođača, gotovo je nemoguće provesti ga „odozgo“, ali i vrijedi toga. „Coach“ poprilično lako uvjeri ljude da koriste Kanban nakon što im pokaže sve njegove prednosti u simulacijskoj Kanban igri.

SLA — Service level agreement ili sporazum o razini usluge

Unatoč činjenici da se naziv prevodi kao sporazum, to je u stvari statistički element koji ukazuje na to kojom su se prosječnom brzinom izvršavali zadaci, i koji dozvoljava da se na račun njega izgrade realna očekivanja.

No, za razliku od statističkih podataka, ova razina može uključivati malu zadršku tijekom komunikacije s internim ili vanjskim korisnicima.

Implementacija

1) Izračunajte statističkim metodama, koliko vremena prosječno prođe od postavljanja zadatka na čekanje od strane naručitelja (internog ili vanjskog). A također, u kojem vremenskom razdoblju je odrađeno najbržih 10% (nazovimo ih X),  u kojem ostalih 90% (nazovemo ih Y). Izračunajte i vrijeme Z za „dugoročnu izradu“, za trajanje najdugotrajnijih zadataka.

2) Uzmite X i dodajte mu Y i dobit ćete realne rokove za izvršavanje 90% zadataka, čak i ako se naručitelji budu „prkosili“ s hitnim nalozima koji ne mogu čekati dogovoreni rok i odgodit će Vaše zadatke. Reći ćemo Vam u povjerenju da vjerojatno dolaze s hitnim zadacima i sada, također, s posebnim redoslijedom. Autor je upoznat sa slučajem „unutarnjeg mita“, gdje kršenje prioriteta košta šalicu kave ili čokoladu, a neki govore o pravom isplaćenom novcu.

3) Usuglasite se s naručiteljem (internim ili vanjskim) oko toga da se u normalnoj situaciji zadatak obrađuje u X+Y vremenu, a da se samo 10% zadataka smije izvršavati izvanredno dugo iz određenog razloga, do vremena Z.

Kako implementirati?

Da biste raspravili o toj mogućnosti napišite službeni mail i dodajte razdvojnu crtu na ploču. To se obično zove Swimlines, i iako u staroj verziji Jira s tim nema problema, čini se da je u Asani bez dodatnih skripti to nemoguće.

Uloga voditelja zahtjeva za uslugu (SRM)

U tekstovima o Kanbanu autori rijetko iskreno kažu da je ova uloga potrebna, najviše radi toga da ne otpuste Product Ownera prilikom prelaska sa Scruma, ali za tom ulogom (SRM) nema ni prijeke potrebe osim ako nema problema sa zaprimanjem zadataka od naručitelja. Ova uloga može biti korisna za one timove koji pate od nedostatka „jedinstvene točke ulaska“ u trgovačkim tvrtkama. Tada ta osoba može uspostaviti formalnu politiku i rješavati ulazne zahtjeve na čekanju, ali to nije baš namijenjeno kao posao za puno radno vrijeme. Alternativno, možete imati jednog voditelja zahtjeva za nekoliko timova ili pretvoriti u njega bivšeg voditelja projekta ili voditelja razvojnog tima (općenito, onoga koji je ostao bez suvišnog posla pro prelasku na novi proces).

Uloga voditelja isporuke usluge (SDM)

Service delivery manager je mnogo veća uloga, a u većini slučajeva na nju se stavlja voditelja projekta, tj. onoga koji je u početku potreban da se poslovi dogovorili do kraja. Kada imate voditelja isporuke, u većini slučajeva uloga voditelja zahtjeva praktički nije potrebna, iako formalno omogućava „podjelu vlasti“: voditelj zahtjeva bavi se zadacima za koje još nije odlučeno treba li se njima baviti ili ne, s voditelj isporuke s onima koji već trebaju biti obavljeni i dovedeni kraju.

Kadence. Varijacije sastanaka s promjenjivom učestalošću unutar procesa

U Kanbanu takvih sastanaka je mnogo, možda čak i previše. Različiti sastanci, od svakodnevnih do sastanaka planiranja isporuke i planiranje ispunjavanja redoslijeda zadataka na čekanju (analogno planiranju sprinta u Scrumu).

Svakodnevni „leteći“ standup sastanak

Na standup-u, za razliku od Scruma, raspravlja se o mnogo ugodnijim pitanjima za one koji odgovaraju na pitanja. Ne treba se mučno prisjećati onoga što je jučer odrađeno, dovoljno je da zajedno svi bace oko na ploču i odrede što sprječava svaki zadatak da s lijeve strane pređe na desnu, i čemu ona može zasmetati.

Kako u poslu izbjeći formalizme i pokoravanje pravilima na štetu proizvoda?

U tome su iznimno od koristi Operations Review sastanci, koji se razlikuju od Agile retrospektiva po tome što razmatraju procese u organizaciji kao cjelinu, kako se ne bi bavili lokalnom optimizacijom na retrospektivnim sastancima svakog tima, jer prema istoj teoriji ograničenja, lokalna optimizacija će više škoditi organizaciji, nego joj pomoći.

Zamislite inženjere tehničke podrške koji, bez porasta osoblja i drugih vanjskih znakova problema, sve više i učinkovitije i brže reagiraju na sve veći broj korisnika koji se žale, no budući da im je potrebno brzo odgovoriti, ne prenose dobivenu informaciju razvojnom timu. Takvo što nije teško zamisliti, to se događa u tehničkim podrškama velikog broja hrvatskih i stranih tvrtki. Bez obzira na to koliko su učinkovito, brzo i krasno odgovorili, ako ne signaliziraju koji je izvor problema, taj će problem biti sve teže pronaći i popraviti, a njima će biti sve teže nositi se sa sve većim opterećenjem.

Planiranje isporuke

Na ovom sastanku, koji ne mora biti baš točno jednom svaka dva tjedna, već se odrađuje kad baš postoji problem s isporukom ili neka neodređenost. Naprimjer, u marketingu, možete pregledati što je spremnije za dovršetak i odabrati one zadatke koji su veći prioritet za najbližu isporuku.

Popunjavanje backloga

Iskreno rečeno, u autorovim štićenićkim timovima nikada nije bilo posebne potrebe za ovim sastankom, eventualno je problem postojao zbog prenatrpanosti backloga zbog velikog broja naručitelja. Svejedno, potrebu za tim sastancima lako će shvatiti svatko tko je nekada stvarao proizvod od nule i sjeća se novozapisanog projekta, primjerice u Jiri. Na takvom sastanku možete stvoriti zajedničke zadaće na razini proizvoda ili čak organizaciji. Dekompoziciju na tehničkoj razini će i inženjeri odlično odraditi.

Metrika

Postoji standardan skup mjernih podataka o proizvodu: prihod, dobit, ARPPU (average rate per paying user), malo manje voljeni ARPU (average rate per user, koja uzima u obzir prihod u smislu svih korisnika, a ne samo onih koji plaćaju) i druge. Ti pokazatelji su vrlo korisni za bilo koji postupak u trgovačkim poduzećima, te nešto drugačiji, ali podosta slični za outsourcing tvrtke. Naravno, to se sve odnosi na stratešku razinu.

Na razini funkcionalnih jedinica važno je uvesti one metrike ili njihove indirektne projekcije koje će stvarno usmjeriti proces u pravom smjeru. I to nije uvijek prosječan broj obavljenih zadataka po danu, odnosno vrijeme tijekom kojeg se zadaci obavljaju u prosjeku. Iako su ovi mjerni podaci po defaultu predloženi u Kanbanu, postupak bi trebao biti a priori prilagođen potrebama određenog internog i vanjskog korisnika. Samo tako tvrtka može postati niz međusobno povezanih usluga jednih za druge, s ciljem pružanja usluge krajnjem korisniku.

Interakcija s upravljanjem proizvodom

Posao voditelja proizvoda sličan je poslu startup startera, s jedinom razlikom da voditelj proizvoda ima samo plaću i, ako mu se posreći, postotak profita, dok  startup starter nema plaću, ali mu zato potencijalna dobit pripada u potpunost (ili udio s partnerima).

Voditelji proizvoda postoje u tvrtki kako bi razvili pojedinačne proizvode, pobrinuli se za povećanje njihove profitabilnosti, i u principu usrećivali svoje klijente rješavanjem stvarnih problema stvarnih ljudi, a ne da bi ostvarivali sljedeći skup ideja izvršnog direktora koji je o tome već odavno prestao fantazirati, ili nikada nije postojala posebna vizija za taj određeni smjer.

Voditelji proizvoda su vlasnici budžeta i formiraju strategiju, uključujući vrste usluga koje se pružaju klijentu i proračune plaća za provedbu plana. Voditelji proizvoda identificiraju ključne mjerne podatke koje proizvodi moraju ostvariti. Jedinice se mogu izravno podređivati ​​voditelju proizvoda, a moguća je i tradicionalna matrična struktura, što je znatno gore za upravljivost i povećava opterećenje na komunikaciji pojedinih ljudi (voditelja odjela koji bi se trebali baviti ručnim upravljanjem).

Voditelj proizvoda može dizajnirati proces koji mu treba i postaviti mjerne podatke koji su mu potrebni. On može selektivno koristiti Scrum ili Kanban ili čak Fast waterfall u različitim dijelovima svog procesa, jer u konačnici, svaka metoda je samo način za postizanje cilja.

Cross-funkcionalni timovi

Možete koristiti cross-funkcionalne timove u Scrumu. Možete čak upotrijebiti cross-funkcionalni Scrum tim kao jedinicu zajedničke Kanban organizacijske strukture.

No ne valja izravno suprotstavljati Kanbanu Scrumu i žuriti da jedan zamijenite drugim. Kanban je najprikladniji za servisne jedinice, a ne za cross-funkcionalne „borbene“ timove, u kojima svaka može raditi sve od marketinga do tehničke podrške.

U cross-funkcionalnim timovima nije preporučivo dijeliti poslove različitih vrsta i bolje je ne stvarati konfrontacije tipa „taj zadatak još nije u mojem stupcu” u jedinicama s istim funkcijama zaposlenika i s velikim brojem sličnih zadataka. Ovaj pristup trebao bi se pokazati dobrim i s manje napora.

Ne hvatajte se Kanban ploče

Da programera, testera ili bilo kojeg drugog inženjera više ne vuku za rukav voditelj ili bilo koji drugi predstavnik srodnih odjela s pitanjem „kada će biti gotovo?“, dovoljno je naučiti ljude da čitaju ploču i postavljati zadatke na ploču.

Izgleda moderno, a u pravilu, interni naručitelji su oduševljeni i prenose iskustvo ploče u svoje jedinicama, bez dodatnih direktiva odozgo. Međutim, to je samo vizualni alat, Koji pomaže da se Kanban proširi Vašom tvrtkom poput virusa zbog svoje jasnoće i jednostavnosti.