STATIK to sekwencja 9 kroków, licząc z krokiem zerowym. Aby zapoznać się z pierwszymi sześcioma krokami, sięgnij po artykuły z 38. i 39. wydania Strefy PMI. W niniejszej, trzeciej części serii, opisuję ostatnie trzy kroki.
Czas zatem na grand finale, czyli zaprojektowanie systemu Kanban:
- Krok 6: Identyfikacja klas serwisu
- Krok 7: Zaprojektowanie systemu Kanban
- Krok 8: Dostosowanie systemu oraz projektu tablicy
Tak jak poprzednio – potraktuj STATIK jak przewodnik w odkrywaniu swojej organizacji, nie musisz odtwarzać kolejnych kroków zgodnie z kolejnością podaną powyżej.
Krok 6: Identyfikacja klas serwisu
Nadszedł czas, aby porozmawiać z zespołem, na jakie kategorie możemy podzielić realizowane przez nas elementy pracy. Klasy serwisowe to zbiór elementów pracy, które mają być traktowane w oparciu o te same zasady. Posługując się metaforą KanBahn udostępnioną przez Kanban University (kanban.university/kanban-guide/#kan-bahn), opiszemy wyróżnione kategorie pojazdów oraz wyróżnione kategorie elementów pracy. W Kanbanie koncepcję taką nazywamy „klasami usług”, które określają, w jaki sposób będą traktowane elementy pracy wchodzące do systemu.
Expedite
Wyobraź sobie autostradę, po której poruszają się pojazdy różnych kategorii. Pojazdy uprzywilejowane, takie jak karetki pogotowia, poruszają się według specjalnych, uzgodnionych zasad. Wszyscy uczestnicy ruchu rozumieją, że inne pojazdy muszą ustąpić pierwszeństwa ruchu pojazdom uprzywilejowanym. Analogiczna sytuacja w kontekście metody Kanban ilustruje pracę, która jest niezbędna w sytuacji kryzysowej – na przykład błędu blokującego na produkcji. Taka praca otrzymuje kategorię Expedite (priorytetowe, pilne). Tej klasy usług nie należy nadużywać. Zespół powinien dążyć do tego, żeby elementy typu Expedite pojawiały się możliwe rzadko. Jednocześnie na tablicy powinien występować maksymalnie jeden taki element. To gwarantuje, że zespół rozwiąże sytuację krytyczną priorytetowo, stosując podejście „wszystkie ręce na pokład”.
W ruchu drogowym pojazdy uprzywilejowane powinny być łatwo rozpoznawalne. Tak samo na tablicy powinniśmy wyraźnie zasygnalizować, że pojawił się element Expedite – na przykład za pomocą koloru karty.
Fixed Date
W metaforze ruchu drogowego możemy wyróżnić pojazdy, które poruszają się według wcześniej określonego harmonogramu. Na przykład autobusy dalekobieżne, które w określonym czasie powinny dotrzeć na ustalone miejsce. Podobnie jest z pracą należącą do klasy Fixed Date. Ta kategoria wskazuje nie tylko, co ma zostać zrobione, ale również na kiedy. Wyróżniając elementy z tej klasy serwisowej, zwróć szczególną uwagę na to, czy konkretna data jest w racjonalny sposób uzasadniona. Na przykład, nie będziemy dyskutować z zarezerwowanymi na konkretną datę testami wydajnościowymi rozwiązania. Natomiast warto być wyczulonym na daty, które zostały „przyklejone” bez wskazania uzasadnienia.
Aby odróżnić elementy Fixed Date od standardowych, warto zadać sobie pytanie: co się stanie, jeśli praca nie zostanie dostarczona na wskazaną datę? Jakie koszty poniesie organizacja? Czy ktoś jest od dostarczonej przez nas pracy zależny i czy wskazał właśnie tę datę? Czy znamy uzasadnienie dla tej daty?
Standard
W końcu możemy zastanowić się, do jakiej kategorii skierować większość pojazdów będących uczestnikami ruchu. Trzecia z omawianych kategorii to Standard. W metodzie Kanban klasa standard jest domyślna dla pracy, która nie kwalifikuje się do żadnej z pozostałych kategorii. Klasy tej dotyczą przede wszystkim ustalenia określające oczekiwania co do przepływu wartości przez system (SLA – Service Level Agreement).
Czym jest SLA? Aby odpowiedzieć na to pytanie, musimy wprowadzić metrykę “cycle time”. Cycle Time dla pojedynczego elementu pracy to czas, jaki zespół spędził pracując nad tym elementem od podjęcia go aż do dostarczenia. W metodzie Kanban SLA definiujemy jako oczekiwany Cycle Time elementu pracy oraz prawdopodobieństwo, z jakim ten warunek zespół spełni.
Załóżmy, że na podstawie danych historycznych widać, że 95% elementów pracy zostało zrealizowane w ciągu 5 dni. Zatem, nieco upraszczając, możemy powiedzieć że w przyszłości element pracy będzie realizowany w ciągu 5 dni z prawdopodobieństwem 0,95. Czyli nasze SLA to 5 dni.
Uwaga: Jeśli chcemy przykładać SLA do innych klas serwisowych, pamiętajmy, że dla każdej klasy powinno być określone inne SLA. Zastanów się przez chwilę nad klasą Expedite – dla niej SLA powinno być krótsze. Mamy tutaj przecież sytuację krytyczną i wszyscy rzucają wszystko, aby element klasy Expedite zrealizować jak najszybciej.
Intangible
Omawiając tę klasę, nie będę odnosić się już do naszej metafory. Skupmy się na Twoim zespole i tych wszystkich zadaniach, które są ważne oraz nie są pilne. Czasami wpada do tej kategorii rozwój kompetencji, które mogą się przydać w przyszłości. Czasem regularne spłacanie długu technicznego lub organizacyjnego. Wymiana doświadczeń i kompetencji z innymi zespołami. Ta praca powinna mieć swoją kategorię, ponieważ niewidoczna może być odkładana w nieskończoność i w konsekwencji mogą pojawiać się zaniedbania w ważnych, dotychczas niepilnych, obszarach. Klasa Intangible (praca nienamacalna) jest inwestycją, która chroni zdrowy balans zespołu. Pozwala pracować szybko, ale bez nerwowości i pośpiechu. Gdy zaniedbujemy klasę Intangible, wcześniej lub później zespół traci balans i zaczynamy gasić pożary zamiast inwestować w przyszłość. Pracujemy w pośpiechu, chaotycznie, rozpoczynając kilka tematów jednocześnie, a w konsekwencji znacznie wydłużając cycle time i ustalone SLA.
Jak zrealizować ten krok w zespole?
Warsztat, podczas którego zespół wskazuje poszczególne klasy serwisowe, można poprowadzić w oparciu o metaforę KanBahn. Na stronie Kanban University znajdziesz pomocną infografikę. Możecie też zebrać przykłady różnorodnych elementów pracy na tablicy fizycznej lub cyfrowej i zastanowić się, do której z wymienionych wyżej kategorii należą. Do wyodrębniania klas serwisowych można podejść iteracyjnie. Najpierw umawiamy się, jak oznaczamy element Expedite, jeśli się pojawi, i pilnujemy, żeby był co najwyżej jeden. Potem możemy umówić się, jak oznaczamy elementy Fixed Date. Następnie pozostałym elementom nadajemy klasę Standard, zbieramy dane, aby zbadać cycle time i określić SLA. Wreszcie, wyodrębniamy elementy Intangible z klasy Standard.
Krok 7: Analiza zdolności i wydajności systemu
Za nami dużo pracy i ciekawych rozmów. Najprawdopodobniej macie już w zespole zwizualizowany przepływ pracy. Gratuluję! Nawet najprostsza tablica z trzema statusami ToDo/In Progress/Done jest dobrym początkiem do zbierania danych i badania systemu, w którym jest zanurzony Twój zespół.
Przykładowe tematy, które sukcesywnie powinniście omawiać, są spisane hasłowo w poniższej liście. Potraktuj ją jako dobry początek tej analizy.
- Statusy przepływu pracy. Może warto dodatkowo pokazać, że trwa projektowanie, implementacja czy testy.
- Zależności. Zwizualizowanymi zależnościami łatwiej będzie zarządzać.
- Ograniczenie Pracy w Toku (WIP). Umawiamy się, że w danych statusie danych elementów może być nie więcej niż określona liczba (np. WIP=3).
- Polityki, czyli zasady określające, kiedy element pracy może zmienić status.
- Metryki – warto zacząć od podstawowych metryk metody Kanban, takich jak cycle time. Lead time to czas od skomunikowania potrzeby (jeszcze przed podjęciem pracy przez zespół) aż do momentu realizacji. Delivery Rate to liczba ukończonych jednostek pracy w ustalonym okresie.
Krok 8: Dostosowanie systemu
Masz w tym ostatnim już kroku całkiem dojrzałą wizualizację przepływu. Może ona wyglądać podobnie do ilustracji na Rysunku 1. Zwróć uwagę na punkt podjęcia zobowiązania przez zespół (Commitment) i bramkę, która pokazuje zakończenie pracy zespołu developerskiego (Delivery). Porozmawiaj z zespołem na temat grafiki poniżej. Przydatne do tej rozmowy informacje znajdziesz w Przewodniku po metodzie i w książce Essential Kanban, z której pochodzi ilustracja.
Rys. 1. Wizualizacja przepływu
Źródło: D. J. Anderson, Essential Kanban CondensedTo już wszystkie kroki metody STATIK. Tutaj się zatrzymamy. Spróbuj, Drogi Czytelniku, zaimplementować opisane kroki w swojej organizacji. W razie pytań – chętnie porozmawiam. Powodzenia!
Od ponad 20 lat związana z branżą IT. W trakcie swojej kariery pracowała m.in. jako actuarial developer, analityk, project manager, Scrum Master, Product Owner i Agile Coach, dzięki czemu może spojrzeć na organizacje i zespoły z szerszej perspektywy. Aktualnie w Bupa Global pełni rolę konsultanta w obszarze nowoczesnych metod zarządzania i mentora dla organizacji, które chcą osiągać zwinność.