fbpx

Opanuj chaos: Kanban w zarządzaniu projektami

  • Home
  • Wiedza
  • Opanuj chaos: Kanban w zarządzaniu projektami

Teoretycy zarządzania często opisują świat, w którym tworzymy plan na najbliższe pół roku (podejście tradycyjne) albo przynajmniej dwa tygodnie (Scrum i inne techniki zwinne). I choć w ich założeniach pojawiają zmiany (którymi uczą nas zarządzać), to całość zawsze zachowuję jako-taką strukturę. Jednak z naszego doświadczenia wyłania się obraz nieco inny i zdecydowanie mniej optymistyczny. Sytuację w wielu działach, a nawet całych firmach można bowiem określić często jako wszechogarniający CHAOS. Owszem, miewamy wcale niezłe plany, ale…

  • Non-stop spływają zgłoszenia o krytycznych błędach. Trzeba rzucać wszystko i naprawiać.
  • Dzień w dzień dostajemy kilkadziesiąt maili, z czego w co piątym jest prośba z gatunku „rzucaj wszystko i biegnij”.

Efekt? Kilkanaście rozgrzebanych wątków i wciąż przybywają kolejne, a wszystkie prognozy terminów okazują się nierealistyczne i przestrzelone. Sytuacja taka jest:

  • Z punktu widzenia firmy turbo-kosztogenna. Rozgrzebujemy liczne tematy, ale mało który kończymy porządnie. Praca włożona w takie niedokańczane albo pół-dokańczane zadania idzie na marne.
  • Z punktu widzenia zespołu turbo-wypalająca. Wszyscy są zmęczeni permanentnym bieganiem z przysłowiowymi pustymi taczkami. Nikt już nie wierzy w sens planów i prognoz, skoro i tak wszystko zaraz się zmieni.

Co robić, jak żyć? Jedną z odpowiedzi jest zarządzanie projektami z wykorzystaniem metody Kanban, którą wyczerpująco opisujemy w tym artykule.

SPIS TREŚCI

  1. Przestań zaczynać, zacznij kończyć!
  2. Tablica kanbanowa to jeszcze nie Kanban
  3. Jak skonstruować dobrą tablicę?
  4. Esencja Kanbana: limit pracy w toku
  5. Ustalanie podstawowych zasad
  6. Doskonalenie systemu
  7. Często zadawane pytania (FAQ):
  8. Kanban w zarządzaniu projektami – tips & tricks
  9. Podsumowanie

PRZESTAŃ ZACZYNAĆ, ZACZNIJ KOŃCZYĆ!

Każda skuteczna zmiana na lepsze stoi na dwóch nogach: techniczno-procesowej oraz psychologicznej. Do tej pierwszej przejdziemy za chwilę. Ale żeby miała ona szansę zadziałać, musisz zrozumieć pewną brutalną prawdę:

NIE DA SIĘ zrobić wszystkiego, co spłynie na waszą skrzynkę i wasze biurka!

Próby takie kończą się tylko otwieraniem kolejnych nowych wątków, które nie mają szans na porządną realizację. Dlatego jako lider musisz mieć cały czas z tyłu głowy, by przede wszystkim kończyć, dostarczać, dowozić, a nie rozgrzebywać i napoczynać.

Zrozum, że wraz z rozwojem firmy i Twoim ilość zmian, wrzutek i ASAPów nie będzie malała, a jedynie rosła. Dlatego Ty i Twój zespół musicie nauczyć się radzić sobie z nimi w sposób inny niż nadgodziny i kolejna kawa. Inaczej prędzej czy później dojdziecie do ściany.

W uniknięciu takiego zderzenia wydatnie może pomóc Wam właśnie zarządzanie zadaniami i projektami z użyciem Kanban.

TABLICA KANBANOWA TO JESZCZE NIE KANBAN

Tak, jak nie jesteśmy fanami egzekwowania precyzyjnych definicji, tak trzeba wyjaśnić sobie jedno – to jest przykład bardzo ładnej tablicy kanbanowej:

tablica-kanban

Ale to jeszcze nie jest kanban! Dlaczego? Bo nic nie powstrzyma nas tutaj od rozgrzebania 17 spraw na raz, by tygodniami i miesiącami gniły w kolumnie „w trakcie”.

Tablica kanbanowa TO NARZĘDZIE, które pomaga nam zwizualizować pracę. Kanban w zarządzaniu projektami TO SPOSÓB, w jaki kierujemy przepływem zadań przez tę tablicę.

I tyle jeśli chodzi o teorię i definicję. Nienasyconych odsyłam do Wikipedii. A teraz wracając do Kanbana…

KROK PIERWSZY: BUDOWA TABLICY

Podstawą kanbana jest przejrzystość i wizualizacja pracy. Po prostu aby sprawnie ogarniać pracę musicie mieć jedno wygodne miejsce (a nie dziesiątki maili i notatek), gdzie zobaczycie wszystkie zadania, jakie Wasz zespół ma na talerzu. Osiągamy to z pomocą wspomnianej wyżej tablicy, która powinna odzwierciedlać wasz proces. Czyli mówiąc po ludzku sposób, w jaki realizowane są zadania od momentu ich przyjęcia do zamknięcia.

kanban-simple

Tak może wyglądać najprostsza tablica, która doskonale sprawdzi się albo w przypadku zarządzania własnymi zadaniami (tablica dla jednej osoby), albo w przypadku zespołu, gdzie każdy realizuje zadania od początku do końca (nie przekazuje innym osobom by dalej kontynuowały nad nimi pracę).

Z kolei w sytuacjach, gdy jedne osoby przekazują pracę innym, by te je kontynuowały i wreszcie przekazały jeszcze innym, które dokończą je i zamkną – tablica może wyglądać tak:

Jak rozpoznać dobrze skonstruowaną tablicę? Dobra jest wtedy, gdy jeden rzut oka wystarcza, by zorientować się w sytuacji. Dużo mamy do zrobienia, co dokładnie dzieje się z danym zadaniem? Stąd m.in. na powyższych przykładach znajdują się zaskakujące dla niektórych twory:

  • Kolumna „czeka na akcept”: dlaczego tworzyć osobną kolumnę skoro takie zadanie właściwie jest „w trakcie”? Dlatego, że podczas czekania nie wykonuje się żadnej pracy i można w tym czasie robić co innego. Dzięki temu jako liderzy widzimy co NAPRAWDĘ robi zespół. Mając tylko jedną kolumnę „w trakcie” i mając tam np. sześć zadań można by sądzić, że nasi ludzie są zawaleni robotą, podczas gdy wszystkie te zadania byłyby czekające, a oni do roboty nie mieliby w tym czasie nic.
  • Dodatkowy podział kolumn „budowa” i „testy” na podkolumny „doing” i „ready”: z dokładnie tych samych powodów co wyżej. „Budowniczy” podejmują się zadania i co mieliby zrobić w momencie, kiedy je skończą? Zostawić w swojej kolumnie – ale to rodzi iluzoryczne wrażenie przywalenia robotą (dokładnie jak w przykładzie wyżej). Przenieść do „testy”? Ale testerzy jeszcze nie zaczęli pracy nad tym zadaniem i to znów zaciemniałoby obraz.

Jeszcze kilka porad związanych z budową tablicy znajdziesz na końcu tekstu. Tymczasem przechodzimy do kolejnego kroku, samej esencji zarządzania projektami w stylu Kanban.

KROK DRUGI: LIMIT PRACY W TOKU

Czasem aby wytrwać w jakimś szczytnym postanowieniu, należy nałożyć sobie pomocnicze chomąto. Na przykład podczas odwyku od cukru wyrzucić z domu słodycze. Chomątem, które pomoże nam częściej mówić „nie” oraz panować nad wrzutkami i ASAPami jest limit pracy w toku. Ograniczenie, które należy ustanowić dla wszystkim kolumn, w których rozgrzebanie zbyt wielu zadań jest problemem. Dla naszego przykładu numer jeden może to wyglądać tak:

Czerwona czwórka przy kolumnie „w trakcie” oznacza, że nie mają prawa znaleźć się tam więcej niż cztery zadania. Pozostałe kolumny nie potrzebują takiego limitu ponieważ więcej zadań tam nie powoduje chaosu. Analogicznie dla naszego bardziej skomplikowanego przykładu tablica taka mogłaby wyglądać tak:

Limit dla kolumny wdrożenie jest oczywisty – nie możemy tam rozgrzebać więcej niż dwa zadania. Natomiast do czego odnosi się liczba przy kolumnach „budowa” i „testy” – do „doing”, do „ready”, czy może do całości? Tutaj możemy wybrać dwie ścieżki:

  • Pragmatyczną, która może mieć sens, jeśli wdrażacie Kanbana po raz pierwszy. W takim wypadku limit odnosi się tylko do pod-kolumny „doing”. Czyli nie możecie rozgrzebać więcej niż 2 („budowa”) czy 3 („testy”) zadania, ale nic nie stanie się jeśli zadania spiętrzą się nieco w kolumnie „ready” czekając na ich podjęcie przez kolejny zespół.
  • Ortodoksyjną, do której warto dążyć. W tym wypadku limit odnosi się do całej kolumny, czyli obu podkolumn. W powyższym przykładzie oznacza to, że żadne następne zadanie nie może zacząć być realizowane, póki przynajmniej jedno z kolumny „wdrożenie” nie zostanie ukończone.

Wersja ortodoksyjna to idealny, będący marzeniem proceso-maniaków (w tym moim) system „pull”. Zadania nie są wpychane („push”) z pierwszej do drugiej kolumny korkując ją i kolejne. Zamiast tego zadania przechodzące do ostatniej kolumny („gotowe”) zwalniają miejsce, co powoduje „zassanie” kolejnych zadań.

Na powyższym przykładzie zadania ruszają się od prawej. Wdrożone zadanie (‚”raz”) zwalnia miejsce w przedostatniej kolumnie i dzięki temu „wciąga” kolejne (ruchy „dwa”, „trzy” i „cztery”). Ów elegancki przepływ wersji ortodoksyjnej ma niezaprzeczalną zaletę: zapobiega piętrzeniu się na wpół zrobionych zadań, które o ile nie powodują chaosu, to wciąż generują przestoje i nieefektywności.

Dodatkowo – jeśli tylko jest to możliwe technicznie (a jest częściej niż ci się wydaje) – taki limit niejako zmusza ludzi do lepszej wzajemnej komunikacji i pomagania sobie w “pchaniu dalej” zadań, które mają problemy. Na powyższym przykładzie aby nie siedzieć bezczynnie tester będzie zmuszony pomóc wdrożeniowcom, a osoba zajmująca się budową może czasem musieć pomóc testerom.

W ten sposób cały zespół zaczyna dążyć do dostarczania skończonych kawałków, a nie tylko wypychania zadań ze swojego podwórka niczym przysłowiowych “gorących kartofli”.

Rozważmy jednak przykład zgodny z pragmatyczną interpretacją, ale niezgodny z ortodoksyjną (limity odnoszą się tylko do podkolumn „doing” a nie całej kolumny):

kanban-przeladowany

O ile nie ma tu rozgrzebanych po trochu wielu zadań (duża ulga), to na pierwszy rzut oka widać, że w pewnym momencie będzie trzeba wstrzymać pracę osób realizujących budowę i rzucić wszystko na front testów. Inaczej (o ile budowniczych nie przejedzie autobus) zadania w fazie budowy będą piętrzyły się w nieskończoność.

Mimo tej niedoskonałości i ku przerażeniu purystów i teoretyków nie odrzucamy wersji pragmatycznej. Dwa główne powody to:

  • Wprowadzenie Kanbana z limitami pracy w toku to dla wielu zespołów naprawdę duży szok. Śrubując dodatkowo zasady i wymagania ryzykujemy, że całość eksperymentu okaże się niestrawna i przeszczep zostanie odrzucony. Wolimy coś, co i tak poprawi przepływ pracy, a w dalszej perspektywie rodzi nadzieje na przekształcenie w wersję „full-wypas”, od kompletnej porażki.
  • Ortodoksyjna wersja zakłada, że ludzie do waszego projektu dedykowani są na 100%, a do tego macie jeszcze możliwość optymalizacji składu zespołu (np. dobrać testera jeśli powstają przestoje). Podobnie luksusowa (nazwijmy rzeczy po imieniu) sytuacja niestety nie jest dana wielu zespołom, z którymi przyszło nam pracować…

Reasumując: zacznij pragmatycznie i w miarę możliwości (ale nie za wszelką cenę) dąż do ortodoksji.

KROK TRZECI: JASNA POLITYKA (I TRZYMANIE SIĘ JEJ)

Same tablice i limity nie wystarczą. Należy jeszcze określić tzw. politykę (od angielskiego policy), czyli proste i transparentne zasady, jakie będą rządziły przepływem zadań przez tablicę. Dwie spośród nich są absolutnie kluczowe i bez nich wasz system szybko się rozsypie.

CO ROBIMY W PRZYPADKU „PILNEJ WRZUTKI”?

Proponuję postępować tak:

  • Jeśli macie w trakcie rozgrzebanych kilka innych obiektywnie ważniejszych rzeczy – sprawa ląduje w pierwszej kolumnie jako coś do zrobienia później.
  • Jeśli ta nowa rzecz jest obiektywnie ważniejsza niż to, nad czym właśnie pracujecie – przerywasz pracę nad jedną z bieżących rzeczy i rozpoczynasz pracę nad wrzutką. Przerwanego zadania nie zostawiasz w stanie „w trakcie”, tylko cofasz je do kolejki „do zrobienia”.

KTO I JAK ZARZĄDZA PRIORYTETAMI W KOLUMNIE „DO ZROBIENIA”?

Sugerujemy wyżej, by w zależności od sytuacji „wrzutka” albo cofnięte zadanie wylądowało w pierwszej kolumnie jako coś do realizacji. Ważne jest jednak aby ta pierwsza kolumna była na bieżąco:

  • Priorytetyzowana – na górze kolumny, pierwsze w kolejce powinno być nie to, co ostatnie tam wpłynęło, ale to co jest najważniejsze.
  • Oczyszczana – pamiętasz wstęp? Nie da się zrobić wszystkiego. Dlatego bez regularnego remanentu w pierwszej kolumnie będzie wam ona puchła i przytłaczała swoim rozmiarem.

Uważny czytelnik zauważy, że powyższe oznacza, że nasza wrzutka albo cofnięte zadanie może nie być realizowane zaraz jak tylko zwolni się miejsce, albo co gorsza – może nie być realizowane nigdy. Dokładnie tak! Może nie być skończone w ogóle i to… bardzo dobrze.

Pracujemy w dynamicznym środowisku, priorytety zmieniają się cały czas i to, co wczoraj było super-pilne, dziś pilne jest już tylko średnio. A nawet wcale nie warto tego robić. Czasem dotyczy to nawet zadań, nad którymi praca ukończona była już w 60, czy nawet 80 procentach. Bywa, że wysiłek potrzebny na te pozostałe 20 czy 40% można spożytkować o wiele lepiej. Nie wspominając już o fakcie, że pewne zadania lubią niczym pasek postępu Windows utykać na 99%.

KROK CZWARTY, OSTATNI: CIĄGŁE DOSKONALENIE

Czy można zmieniać limity i zasady rządzące tablicą? Dodawać kolumny oraz wprowadzać udziwnienia? Oczywiście, że tak! Nie ma opcji, aby za jednym zamachem stworzyć idealny system dla Twojego zespołu lub firmy. Dużo lepiej zacząć od czegoś relatywnie prostego, a potem to doskonalić.

Radzimy jednak, by wszelkie zmiany wprowadzać w sposób ustrukturyzowany. Na przykład dyskutując pomysły raz na dwa tygodnie na spotkaniu w stylu lean coffee. Jeśli zaczniemy zmieniać zasady i limity ad-hoc – szybko stracą one swoją wagę. Co warta jest zasada, którą można w razie potrzeby „chwilowo” uchylić lub nagiąć?

Nie twierdzimy, że nie istnieją wyjątkowe sytuacje, kiedy warto zmienić coś w trakcie. Twierdzimy, że w 95% przypadków zmiany takie są zwykłym pójściem na łatwiznę, które odbije się Wam czkawką.

Zasięgnij porady doświadczonego managera!

Chcesz rozwiązać problem w projekcie lub w relacji z zespołem, klientem, czy też przełożonym? Skorzystaj z konsultacji 1:1.

Dowiedz się więcej

CZĘSTO ZADAWANE PYTANIA (FAQ)

Jeśli nie znajdziesz tu odpowiedzi na coś, co Cię nurtuje – śmiało pisz.

1) JAK DUŻE „ROZMIAROWO” ZADANIA POWINNY LĄDOWAĆ NA TABLICY KANBAN?

Nie ma oczywiście złotej reguły, ale sugerujemy między 2 a 12h. Mniejszych rzeczy często nie ma sensu tam umieszczać (oczywiście o ile nie wpada takowych dziesiątki). Większe zadania warto z kolei rozbić z dwóch powodów:

  • Jaśniejszy obraz na jakim dokładnie etapie znajduje się dane zadanie. Jeśli widzimy, że ukończone są już dwa mniejsze zadania spośród pięciu składających się na realizację większego, to całkiem dobrze wiemy na czym stoimy. Z kolei jeśli tego zadania nie rozbić i mieć je przez kilka dni wiszące w statusie “w trakcie”, to tak naprawdę nie wiadomo co się z nim dzieje. Oczywiście właściciel zapewnia, że prace się posuwają, ale doświadczeni liderzy znają te zapewnienia i to, że postęp jakoś utyka po dojściu do “prawie gotowe”.
  • Działa to motywująco. W ten sposób możesz praktycznie codziennie zamknąć jakieś zadanie, a nie ciągle wisi nad Tobą jedna wielka “niekończąca się opowieść”.

2) CZY JEDNO ZADANIE MOŻE BYĆ PRZYDZIELONE WIĘKSZEJ ILOŚCI OSÓB?

Nie. Jedno zadanie = jedna odpowiedzialna za nie osoba. A jeśli to samo zadanie ma wykonać kilka osób (np. zaliczyć wewnętrzne szkolenie z polityki bezpieczeństwa), to każdy powinien mieć swoją osobną kopię zadania. Wtedy realnie sprawdzisz jego postępy oraz sprawniej zadbasz o dotrzymanie limitów pracy w toku.

3) CZY TABLICA KANBANOWA POWINNA BYĆ STWORZNA BARDZIEJ Z MYŚLĄ O PRJEKCIE CZY ZESPOLE?

Jeśli koordynujesz tylko jeden projekt – niech Twoja główna tablica dotyczy tego projektu. Jednak jeśli koordynujesz prace grupy osób, która realizuje kilka projektów, a do tego jeszcze sporo zadań procesowych i innej “bieżączki”, to przede wszystkim potrzebujesz “jednego źródła prawdy” (ang. single source of truth). Jednej tablicy, na której zobaczysz obciążenie całego zespołu i zaplanujesz zadania na najbliższe 1-2 tygodnie. Dodatkowe tablice per-projekt mogą wtedy pomóc, ale ta główna z całością pracy w jednym miejscu da Wam największą wartość.

4) CO ZROBIĆ, GDY CZĘŚĆ NASZEJ PRACY TO TZW. TICKETY? PRZEPISYWAĆ JE NA TABLICĘ?

Jeśli cześć pracy Twojego zespołu to realizacja dużej ilości relatywnie małych zdań (nadawanie uprawnień, naprawianie małych awarii itp.), które rejestrowane są w innym systemie, to nie ma sensu przepisywać tych zadań na waszą tablicę. Zamiast tego rozważ tworzenie tygodniowych meta-zadań per członek zespołu, na których jasno zaznaczycie, że np. Adam w tym tygodniu zajmuje się realizacją ticketów na 40% etatu. W ten sposób nadal macie jasny przegląd obciążenia zespołu i tego, co się w nim dzieje, ale bez żmudnego kopiowania dziesiątek zadań.

A jeśli podejrzewacie Adama, że się nieco obija – poproście, aby w komentarzach do tamtego zadania wkleił numery zrealizowanych w danym tygodniu ticketów.

5) CZY KANBAN W ZARZĄDZANIU PROJEKTAMI WYMAGA JAKICHŚ SPOTKAŃ, CO POLECACIE?

Sam Kanban niczego nie „wymaga”, ale czasem wypadałoby się spotkać. Jeśli pracujecie w Scrum – robicie dokładnie takie same spotkania, jakie przewiduje ten framework. Jeśli nie pracujecie w Scrum (albo nie macie pojęcia o co chodzi) rozważcie:

  • Codzienne szybkie (10-15 minut) spotkanie, gdzie zaktualizujecie statusy zadań oraz pogadacie o tym co blokuje pracę i co można z tym zrobić.
  • Raz na dwa tygodnie wspomniane wyżej lessons learned, czyli spotkanie gdzie w 30-60 minut zastanowicie się, co można by usprawnić (dodać/ująć kolumnę, zmienić limit, zwolnić Marka, bo nie aktualizuje zadań) w waszym sposobie pracy z Kanbanem.
  • Nawet jeśli wasza praca składa się TYLKO z bieżączki (faktury do księgowania, błędy do poprawiania, teksty do pisania), to przynajmniej raz na miesiąc warto zrobić np. dwugodzinne planowanie. W trakcie oczyścicie waszą tablice z zadań, które i tak nie wejdą (zawsze są takie i ich obecność tylko dołuje i wprowadza bałagan) oraz zastanowicie się co czeka Was w kolejnym okresie. Kto będzie miał wolne (i jak wpłynie to na limity)? Czy spodziewamy się jakichś spiętrzeń i jak sobie z nimi poradzimy? Czy poza bieżączką chcemy dostarczyć w tym czasie coś „rozwojowego” i jak upewnimy się, że będzie miało to odpowiedni priorytet?

Być może z czasem (np. podczas lessons learned) dojdziecie do wniosku, że potrzebujecie jeszcze jakichś spotkań. Jak najbardziej dołóżcie je wtedy do swojego procesu. Pamiętajcie jednak, aby nie przesadzić. Między spotkaniami musi zostać jeszcze czas na pracę.

6) JAK NA POCZĄTKU WYZNACZYĆ LIMITY PRACY W TOKU?

Dobrym punktem wyjścia wydaje się liczba osób w zespole +1, czyli np. 6 dla pięciosobowego zespołu.

Ustalając limit, miej z tyłu głowy jego cel. Chodzi o to, aby każdy mógł skupić się nad jednym zadaniem, dzięki czemu skończy je (albo swoją część pracy nad nim) możliwie najszybciej.

7) JAKIE NARZĘDZIA POLECACIE DO ZARZĄDZANIA ZADANIAMI METODĄ KANBAN?

Mimo ich ograniczeń (trudno się dzielić w zespole zdalnym, trzeba gdzieś trzymać szczegółowy opis zadań) jesteśmy zaprzysięgłymi fanami tablic fizycznych. Jeśli się nie da, to polecamy narzędzia takie, jak:

8) JAKIE JESZCZE POLITYKI I ZASADY WARTO ROZWAŻYĆ, CO WARTO USTALIĆ?

Przede wszystkim dwa rodzaje:

Komunikacyjne: z kim konsultować ważność wrzutek? Kogo i w jaki sposób powiadamiać jeśli skończyliśmy naszą część pracy nad zadaniem? Co robić, gdy natrafiamy na problemy?

Jakościowe: sensowne minimum to dwie podstawowe definicje.

  • Co musi spełniać zadanie, aby uznać, że jest gotowe do realizacji (tzw. definition of ready) – np. jasny opis, podane osoby kontaktowe, załączone materiały.
  • Co musi spełniać dane zadanie, by uznać je za „zrobione” (tzw. definition of done) – np. aktualizacja dokumentacji, zawiadomienie klienta.

Wszystko po to, aby uniknąć niepotrzebnych nieporozumień i niedomówień, które szczególnie w chwilach większego stresu potrafią być tak niesamowicie frustrujące.

9) ZESPÓŁ / KLIENT / SZEF NIE CHCE SŁYSZEĆ O LIMITACH!

Pokaż mu ten artykuł (jego pierwszą część). Zapraszamy też na mentoring oraz szkolenia projects i leadership, gdzie dużo więcej mówimy o przekonywaniu, nawiązywaniu relacji i komunikacji. Także z tzw. „dzbanami”.

10) WARIANT „ORTODOKSYJNY” – CO Z LUDŹMI, KTÓRZY NIE MAJĄ CO ROBIĆ, BO PRZYBLOKOWAŁ LIMIT?

Jednym z nie-aż-tak-oczywistych celów pracy w wariancie ortodoksyjnym jest to, aby CAŁY zespół brał odpowiedzialność za CAŁĄ pracę. Nie tylko za swój fragment. W wypadku gdy jedni ludzie nadal mają co robić, a inni zblokowani są limitem – Ci zblokowani powinni pomóc tym, którzy wykonują prace blokującą przepływ. W poniższym przykładzie osoby, które zajmują się budową lub testami mogłyby wesprzeć wdrożeniowców.

To może wydawać się (i czasem jest) trochę utopią, ale to dobry kierunek, który dodatkowo zapewnia większe dzielenie się kompetencjami w ramach zespołu. Jeśli osoby z działu produkcji czy testów coś niecoś pomagały wcześniej przy wdrożeniach, to kiedy wdrożeniowcy połamią sobie na nartach nogi – będziemy mogli jakoś ich zastąpić.

11) PRÓBOWALIŚMY, ALE U NAS TWARDY LIMIT PRACY W KANBAN NIE DZIAŁAJĄ

Nie, nie będę do Was strzelał. Wierzę, że próbowaliście. I wiem, że nie w każdym zespole można wprowadzić je sensu-stricte.

Problemy z wdrożeniem pojawiają się np. w zespołach, w których koordynujecie wiele osób ‘luźno’ związanych w projektem (zaangażowanych na max 10-15% swojego czasu + nie mamy nad nimi żadnej specjalnej ‘władzy’). W takim wypadku już dużo da u Ciebie jako u lidera świadomość tego, by nie rozgrzebywać za wiele na raz i starać się ograniczać pracę w toku.

12) W JAKIEGO RODZAJU ZESPOŁACH I BRANŻACH SPRAWDZI SIĘ ZARZĄDZANIE PROJEKTAMI Z KANBAN?

Pomoże i poprawi przepływ pracy w każdym. W IT coraz popularniejsze staje się m.in. łączenie go ze Scrumem. Uważamy jednak, że im większy chaos panuje w zarządzaniu realizacją zadań, tym większą korzyść przyniesie Kanban. Dotyczy to na przykład:

  • Biur rachunkowych.
  • Zespołów IT, które dławią się ilością pilnych błędów do poprawy.
  • Wszelkiego rodzaju agencji kreatywnych.

I wielu, wielu innych.

13) CZY MACIE JAKIEŚ PRZYKŁADY REALNYCH TABLIC?

Tak, oczywiście. Znajdziesz je na końcu tekstu o Trello.

KANBAN W ZARZĄDZANIU PROJEKTAMI – TIPS & TRICKS

PROGNOZOWANIE CZASU REALIZACJI ZADAŃ

Każdy manager tego chce. Nawet jeśli się do tego nie przyznaje, to skrycie marzy by wiedzieć „jak wiele zrobicie w ciągu tygodnia” i „na kiedy będzie”. jak wygląda to w Kanbanie? Otóż jeśli:

  • Pracujecie już w tym systemie jakiś czas, czyli załapaliście o co chodzi i macie swój „rytm”.
  • Staracie się aby zadania, które trafiają do kolejki były mniej więcej zbliżonych rozmiarów (to generalnie dobra praktyka – nawet jeśli to księgowanie faktur, rozbijajcie większe ich kupki na zbliżone rozmiarem „partie”, które będą pojedynczymi zadaniami)

To po jakimś czasie będziecie znali (fachowe terminy kanbanowe):

  • Service Level Expectation: czyli ile mniej więcej dni potrwa realizacja zadania od jego przyjęcia do jego końca.
  • Throughput: ile zadań zostanie zamkniętych w danej jednostce czasu. Np. przeciętnie 13 zadań w dwa tygodnie.

UWAGA: w wypadku pewnych zespołów (np. w moim obecnym) to nigdy nie będzie miało sensu, bo zadania będą zbyt zmienne i różnorodne. Pomóc może trochę sztuczka, którą sugeruję w tekście o tym jak dostarczyć projekt (sekcja o wycenie zadań): przypisywanie zadań do jednej z trzech kategorii S, M albo L. Po jakimś czasie będziecie wiedzieć, że przeciętnie L-ka zajmuje tydzień, S-ka dwa dni, a M-ka trzy oraz, że w dwa tygodnie zazwyczaj robicie dwie „L”, trzy „M” oraz pięć „S”. Tu nie powstrzymam się jednak, by nie podkreślić pewnej rzeczy.

Kanban w zarządzaniu projektami nie jest od tego, by precyzyjniej przewidywać przyszłość! W chaotycznym i zmiennym środowisku z równą skutecznością możecie udać się do Wróżbity Macieja. Kanban jest od tego, abyście realizowali wasze zadania w najbardziej optymalny sposób, bez chaosu i kręcenia się w kółko.

TABLICA, KTÓRA OBEJMIE CAŁY PROCES

Właśnie projektuję tablicę, której planuje używać ze swoim zespołem od 2020 roku. Wygląda ona nieco inaczej niż najczęściej spotykane tablice:

Jak widać obejmuje cały proces od powstania pomysłu, aż do jego realizacji. Liczę, że pomoże ograniczyć bałagan, jaki nieuchronnie wprowadza się mając różne tablice. Zakładam też, że poprawi transparentność tego, co się dzieje i co jest w planach na poziomie całego zespołu. Ludzie pracują o wiele lepiej i angażują się o wiele bardziej, kiedy wiedzą „co ich czeka”.

Czemu służą poszczególne kolumny:

  • Pomysły: jeden wielki bałagan. Notowane na szybko, na kolanie. Kolumna służy temu by te spontaniczne rojenia chwilę się uleżały. Połowa z nich nigdy nie przejdzie nawet do kolejnej kolumny. To co jednego dnia wydaje mi się przebłyskiem geniuszu, często dwa dni później uznaję za idiotyzm.
  • Do analizy:  analiza polega na przemyśleniu bardzo ogólnego planu oraz rozważeniu korzyści i na tej podstawie określeniu dwóch wartości: skomplikowania (S/M/L) oraz przewidywanego zysku (S/M/L). Połowa znów nie przechodzi dalej, bo albo podczas przemyśleń okazują się bez sensu, albo nawet gdy mają sens, nakład przekracza zakładane korzyści.
  • Backlog: tutaj czekają w spokoju przeanalizowane i zaakceptowane do realizacji pomysły aż zrobi się trochę miejsca w kolumnie „do zrobienia”
  • Czerwona kreska: point of no return. Przeznaczając zadania do realizacji jeszcze raz zastanawiam się czy na pewno ma ono sens i czy to dobry moment. Kiedy zadanie przekroczy już tą kreskę to w 95% przypadków powinno zostać ukończone. Za to przed nią wręcz wskazane jest aby z tablicy zniknęło (ponownie: nie da się zrobić wszystkiego).
  • Do zrobienia: do zrobienia w ciągu najbliższych dwóch tygodni.
  • W trakcie: wiadomix.
  • Oczekujące: zadania, których dalsza realizacja zależy od czynników zewnętrznych. Np. negocjujemy pojawienie się na jakiejś konferencji, dosłaliśmy wszystkie materiały i czekamy na informacje zwrotne. Puściliśmy wici, że szukamy marketingowca i czekamy na zgłoszenia.
  • Gotowe: wiadomix.

Uważny czytelnik przyłapie mnie na braku limitów na powyższej tablicy. Powód jest prosty – ostatnio mój zespół bardzo się zmieniał i nie mam jeszcze pomysłu na limit dla kolumny „w trakcie”, ale będzie, spokojnie. Z kolei działania przed czerwoną kreską rządzą się nieco innymi prawami i mnożenie tam kolumn oraz dodawanie limitów byłoby w moim przekonaniu nieco sztuką dla sztuki. Less is more.

DWA CIEKAWE DODATKI: WIERSZ NA SPRAWY KRYTYCZNE ORAZ „STAROŚĆ” ZADANIA

W przypadku zespołu Zero BS to się nie przyda, ale jeśli realizujecie u siebie od czasu do czasu jakieś turbo-ważne „wrzutki” – warto pomyśleć o wierszu PRIO (zwanym również „olaboga”).

Dzięki takiemu oznaczeniu, bez specjalnego namysłu wiadomo, że to co tam trafiło powinno być obrabiane w pierwszej kolejności. Jeśli stosujesz tablicę elektroniczną, a Twój program nie wspiera dodatkowych wierszy (tzw. swimlanes) – można po prostu zmienić kolor takich zadań na jaskrawoczerwony i (o ile utrzymujesz na tablicy względny porządek) wyjdzie na to samo.

Innym ciekawym pomysłem jest oznaczanie „starzenia się” zadań w danym stanie. Dla każdego lidera dość oczywiste jest to, że jeśli jakieś zadanie wisi gdzieś rozgrzebane w jakiejś kolumnie (a więc pomiędzy „do zrobienia” a „zrobione”) dłużej niż np. dwa dni – warto się zainteresować co tam się dzieje. W teorii jest to oczywiste, ale w praktyce codziennej bieganiny czasem to umyka. Z pomocą przychodzą dodatki do aplikacji, które po zadanym czasie zaczynają podkreślać takie zadania. Mogłoby to wyglądać np. tak:

I od razu wiadomo, że warto podrążyć i może nieco pomóc owym dwóm zadaniom pójść w procesie dalej. W Trello załatwia to power-up Card Aging. Na fizycznej tablicy trzeba by było niestety robić to ręcznie, chociaż krążą plotki o innowacyjnej metodzie polegającej na przypięciu do kartki skórki od banana.

kanban_banan Jeśli zaczyna ciemnieć – znaczy, że jest źle. Ewidentnie zbyt długo pisałem ten tekst o Kanbanie!

Podsumowanie

Mamy nadzieję, że udało się Was zainspirować i pokazać, jak proste i ułatwiające życie jest zarządzanie projektami z Kanban. Jeszcze większą nadzieję mamy, że odpowiedzieliśmy na większość pytań i wątpliwości, jakie mogą się Wam urodzić podczas prób implementacji. Jeśli nie – śmiało piszcie a może dzięki Wam uzupełnimy ten materiał.

Po bardziej zaawansowane pytania zapraszamy na mentoring, wsparcie we wdrażaniu na doradztwo, a po kompleksową wiedzę jak połączyć to z innymi elementami mądrego systemu zarządzania – na nasze szkolenia.

PS Po dodatkowe inspiracje oraz przykładowe tablice jakich używamy w naszej firmie zapraszamy do tekstu o Trello. Bodajże najpopularniejszym programie do elektronicznych tablic Kanban.

 

igor mróz konsultingAutor tekstu:
Igor Mróz – doświadczony Project Manager, CEO Zero Bullshit Management.

 

Poznaj Podstawy zarządzania projektami, bez bullshitu

NASZ AUTORSKI KURS ONLINE: dwanaście lekkostrawnych lekcji, przykłady, materiały dodatkowe, całość zakończona certyfikatem

Zobacz i kup z gwarancją satysfakcji