English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

gość
1 / ?
powrót do lekcji

看板 — Szyld

Kanban (看板) to słowo japońskie. Znaki rozkładają się na: (kan), patrzeć, widzieć, & (ban): tablica, deska, szyld. Razem: wizualny szyld sygnałowy.

Słowo poprzedza system zarządzania o wiele wieków. Każdy sklep w Japonii okresu Edo miał kanban: drewniany szyld na zewnątrz ogłaszający, co się sprzedaje w środku. Sygnał wizualny był jednocześnie reklamą, wskaźnikiem zapasów & wyzwalaczem ponownego zamówienia.

Wgląd supermarketu Taiichi Ohno

W latach 50. inżynier Toyota Taiichi Ohno odwiedził amerykańskie supermarkety. To, co widział, zmieniło historię produkcji.

W tradycyjnej fabryce model push produkcja przebiegała zgodnie z harmonogramem. Prognoza mówi: "będziemy potrzebować 500 jednostek w przyszłym miesiącu", więc fabryka wytwórzyła 500 jednostek & wpchnie je na półkę. Jeśli popyt był zły, półka się przepełniła. Jeśli popyt przekroczył prognozę, półka była pusta. Tak czy owak, ktoś się pomylił.

Supermarkety pracowały inaczej. Półki zawierały stałą ilość każdego artykułu. Gdy klient zabrał ostatnią słoik masła orzechowego, pusta szczelina sama w sobie była sygnałem do ponownego zamówienia. Pracownicy magazynu nie potrzebowali kierownika, by powiedzieć im, że należy zamówić ponownie: półka im powiedziała. To jest model pull: sygnał popytu z dołu aktywuje uzupełnianie z góry.

Pull vs. Push: Origins of Kanban

Ohno wrócił z tym wglądem do Toyota. Fizyczna karta (kanban) dołączona do pojemnika części stała się sygnałem: "ten pojemnik jest pusty: produkuj więcej." Żadna prognoza nie jest potrzebna. Żaden centralny planista. Praca ciągnęła się do przodu sama.

Push vs. Pull

Rozróżnienie push/pull jest podstawą wszystkiego, co następuje.

Własnymi słowami, jaka jest różnica między systemem push & pull? Podaj przykład każdego z dowolnej domeny: fabryka, oprogramowanie, obsługa gastronomiczna, cokolwiek przychodzi ci do głowy.

Kolumny jako stany

Tablica kanban sprawia, że praca jest widoczna. Każda część pracy to karta. Karty przesuwają się od lewej do prawej przez kolumny reprezentujące stany.

Klasyczne kolumny to: Backlog → Wybrane → W trakcie → Przegląd → Gotowe

Ale dokładne kolumny nie mają znaczenia. Ważne jest, aby każda karta miała dokładnie jeden obecny stan, & aby ten stan był widoczny dla wszystkich, którzy pracują w tym systemie.

A Basic Kanban Board

Co reprezentuje karta

Karta reprezentuje jednostkę pracy, którą można niezależnie ukończyć. Nie projekt. Nie cel. Konkretna, ograniczona rzecz z jasną definicją zakończenia.

Dobra karta: Obrócić klucze SSH na serwerach prod: gotowe, gdy wszystkie serwery pokazują nowy klucz w authorized_keys & stary klucz jest usunięty.

Zła karta: Popraw bezpieczeństwo. (To jest projekt, a nie zadanie. Rozbij to.)

Limity WIP

Kolumna W trakcie na diagramie pokazuje limit WIP: 3. Oznacza to, że nie więcej niż trzy karty mogą być W trakcie w tym samym czasie. Jeśli chcesz wciągnąć czwartą kartę, musisz najpierw ukończyć jedną.

To wygląda na ograniczenie. Tak, jest to ograniczenie: celowo. Limity WIP zmuszają cię do ukończenia tego, co zacząłeś, zanim zaczniesz coś nowego. Więcej o tym, dlaczego to ma znaczenie, w dalszej sekcji.

Określanie zakresu kart pracy

Najtrudniejsza umiejętność w kanban to nie rysowanie tablicy. To określanie zakresu kart. Za duża & karta siedzi W trakcie przez tygodnie, blokując inną pracę. Za mała & tablica wypełnia się hałasem.

Konfigurujesz tablicę kanban dla zespołu infrastruktury sieciowej. Ktoś sugeruje dodanie karty o nazwie "Uaktualnij wszystkie przełączniki sieciowe." Zidentyfikuj dwa problemy z tą kartą, takiej jaka jest napisana, & przepisz ją jako dwie lub więcej prawidłowo określonych kart.

Silosy działają dobrze

Każda operacja wielofunkcyjna ma funkcjonalne centra pracy: piekarnia ma wypieki, pieczywo, słone & ladę przednią. Studio produktowe ma design, treść, budowanie & ops. Projekt budowlany ma ramy, hydraulikę, elektrykę & wykończenie. Te centra istnieją z dobrych powodów: głębokie specjalizacje wymagają skoncentrowanego posiadania.

Kanban nie rozpuszcza tych podziałów. Sprawia, że operacje handover między nimi są widoczne & jawne.

Work Centers & Handoffs

Karta handover

Gdy jednostka pracy przechodzi z jednego centrum pracy do drugiego, powiedzmy zasób projektowy, który potrzebuje napisanego tekstu zanim konstruktor będzie mógł zmontować stronę, karta handover podróżuje z nią. Następne centrum widzi kartę pojawiającą się w ich Backlog. Ciągną ją, gdy mają pojemność. Żaden e-mail nie jest wymagany. Żadne spotkanie koordynacyjne. Karta to sygnał.

Co pokazuje diagram

Bilet ★ zaczyna się w Design (W trakcie: zasoby wizualne). Gdy Design kończy swoją część, tworzona jest karta handover & bilet ★ pojawia się w backlog centru Build. Build go ciągnie. Potem Ops ciągnie go. Każde centrum ma swoją własną tablicę. Każda tablica pokazuje tylko obecną pracę tego centrum. Ale ★ podróżuje przez wszystkie & wszyscy mogą zobaczyć, gdzie jest.

To jest wgląd supermarketu zastosowany do organizacji: każde centrum pracy to półka. Karty uzupełniają półki dolne tylko wtedy, gdy praca z góry zostaje wciągnięta & zużyta.

Projektowanie operacji handover

Karta handover to umowa między centrami pracy. Musi zawierać wystarczającą ilość kontekstu, aby zespół odbiorczy mógł działać bez spotkania.

Nowy produkt wychodzi na rynek. Praca dotyka czterech centrów: Design (zasoby marki, zdjęcia produktów), Content (opis produktu, tekst strony głównej), Build (strona internetowa, integracja kasy), & Ops (ustawienia procesora płatności, briefing partnera logistycznego, zmiana konfiguracji analityki). Opisz, jak modelowałbyś to jako pracę kanban. Jakie karty by istniały? Jak działają handover? Gdzie zaczyna się praca?

Przestań zaczynać. Zacznij kończyć.

WIP oznacza Work In Progress. Limit WIP to limit, ile kart może być w danej kolumnie jednocześnie.

To wygląda jak ograniczenie. Tak, jest. To jest sens.

Dlaczego limity pomagają

Za każdym razem, gdy zaczynacie nowe zadanie bez ukończenia poprzedniego, płacicie podatek przełączania kontekstu. Twój mózg ładuje kontekst nowego zadania & częściowo rozładowuje stare. Gdy wracasz do starego zadania, przeładowujesz go. Do pracy poznawczej, pisania, debugowania, projektowania, recenzji, ten koszt ponownego załadowania mierzy się w godzinach, a nie sekundach.

Limity WIP uniemożliwiają gromadzenie się niedokończonej pracy. Robią też coś bardziej wartościowego: ujawniają wąskie gardła.

Wąskie gardła stają się widoczne

Jeśli kolumna Przegląd ma limit WIP wynoszący 2 & zawsze jest na 2, to sygnał: przegląd jest wolniejszy niż produkcja. Więcej pracy ukończonej W trakcie nie może być konsumowane przez Przegląd. Bez limitu WIP, tablica wypełnia się kartami "gotowe-ale-czekające-na-przegląd" & wąskie gardło jest niewidoczne. Z limitem WIP, kolumna W trakcie nie może zaakceptować nowych kart, & cały zespół widzi ograniczenie.

To nie jest niepowodzenie. To informacja. System ci mówi, aby naprawić Przegląd, zatrudnić, parować, zmniejszyć rozmiar partii, zamiast ślepo wpychać więcej pracy.

Prawo Little'ego (nieformalnie)

Czas realizacji (jak długo karta zajmuje od startu do konca) = Work In Progress ÷ Throughput (karty ukończone na jednostkę czasu). Jeśli chcesz krótszych czasów realizacji bez zatrudniania, zmniejsz WIP. Mniej rzeczy w locie oznacza, że każda rzecz kończy się szybciej.

R = (W × C) + T

Limity WIP chronią trzy zmienne. Konsultant ds. efektywności Brian Tracy nazwał je w 1986 roku.

R = (W × C) + T

- R: Rezultat: wynik, którego chcesz

- W: Jasność celu: jak dokładnie wiesz, czego chcesz (0–10)

- C: Koncentracja: intensywność skupionego wysiłku (0–10)

- T: Czas pracy bez rozpraszaczy (niezakłócone godziny)

Dlaczego W & C mnożą się

Jasność & koncentracja nie są niezależne. Wysoka koncentracja na niejasnym celu powoduje szybki ruch w złym kierunku. Idealna jasność celu bez koncentracji nic nie produkuje. Oddziaływają: dlatego Tracy napisał je jako produkt, a nie sumę. 9/10 na każdego daje R = 81 + T. 3/10 na każdego daje R = 9 + T. Różnica nie jest dodawana.

Dlaczego T dodaje

Każda niezakłócona godzina dodaje liniowo do wyniku. T nie może łączyć W & C: może tylko umieścić na szczycie produktu. To wyjaśnia, dlaczego pierwszy ruch zawsze polega na poprawie W & C, a nie na pracy dłużej. Więcej T na niski (W × C) produkt to wciąż słaby wynik.

Co tablica kanban robi z każdą zmienną

- W: Dobrze określona karta (jasny tytuł, mierzalne kryteria akceptacji, jeden właściciel) podnosi W zanim praca się zaczyna. Niejasne karty obniżają to automatycznie.

- C: Limity WIP wymuszają koncentrację. Jedna karta w Active oznacza pełną uwagę na jeden problem. Trzy karty w Active oznacza C jest podzielone na trzy sposoby.

- T: Bloki Pomodoro & ochrona kalendarza tworzą niezakłócone godziny T mierzy. Czasomierz tablicy to nie dekoracja: śledzi T w czasie rzeczywistym.

Tracy twierdził, że każdy problem można rozwiązać w 30 minut, gdy W, C, & T są wszystkie zoptymalizowane. Tablica kanban to instrument do jednoczesnego optymalizowania wszystkich trzech.

Solo ma trzy karty w kolumnie Active. Każda karta ma tylko tytuł: brak kryteriów akceptacji. Sprawdza wiadomości co 15 minut. Oceń każdą zmienną (W, C, T) w przybliżonej skali 1–10 & wyjaśnij, którą zmienną tablica kanban bezpośrednio naprawiłaby, gdyby przeszła do jednej karty Active z w pełni określoną specyfikacją.

Czytanie tablicy

Ćwicz czytanie wąskich gardeł ze stanu tablicy.

Tablica kanban zespołu produktowego pokazuje: Backlog, 12 kart. Selected, 3 karty. W trakcie, 3 karty (limit WIP: 3). Przegląd, 5 kart (limit WIP: 3). Gotowe: 8 kart. Co ci mówi ten stan tablicy? Co powinien zrobić zespół dalej, & dlaczego?

Nie Agile. Nie Waterfall.

Agile to metodologia. Waterfall to metodologia. Kanban to system.

Metodologie nakazują, jak pracujesz. Systemy opisują, co jest prawdziwe o pracy. Kanban nie mówi ci, aby mieć dwutygodniowe sprinty, codzienne standupy, ani retrospektywy. Mówi ci jedno: sprawiaj, że praca jest widoczna, ogranicz WIP, & ciągnij.

Problem z metodologiami

Agile działa dobrze dla zespołów budujących produkty iteracyjnie, oprogramowanie, najczęściej. Waterfall działa dobrze dla projektów ze stałymi wymaganiami & znanymi niewiadomymi, budowanie, hardware manufacturing. Żaden nie mapuje się czysto na pracę wielodyscyplinową, gdzie zadanie projektowe & zadanie logistyczne mają zupełnie inne czasy cyklu & definicje "gotowe".

Zmuszenie centrum designu & centrum ops do tego samego tempa sprintu to błąd kategorii. Dwutygodniowy sprint, który działa dla tworzenia treści, tworzy sztuczną pilność w pracy logistycznej. Ritual standup zbudowany dla zespołów współlokalizowanych tworzy opóźnienie dla niezależnych solów.

Znajdź wspólny grunt w pracy do wykonania

Podejście un: znajdź pracę do wykonania. Znajdź ludzi lub partnerów najlepiej pozycjonowanych, aby to zrobić. Nie nakładaj proces na to: pozwól pracy ujawnić swój własny proces przez współdzielony system widoczności.

To nie jest brak procesu. To właściwa ilość procesu: wystarczająco do koordynacji, niewystarczająco do tworzenia opóźnienia koordynacji, które przewyższa wartość pracy.

Nie buduj tego, co możesz kupić. Nie kupuj tego, co możesz uprawiać.

Zanim jakakolwiek karta pracy zostanie utworzona, zapytaj: czy to powinno w ogóle istnieć? Każdą pracę, którą budujesz, posiadasz na zawsze. Każdy SaaS, na który się subskrybujesz, zależysz na zawsze. Każdą zależność open-source, którą rozdzielasz, utrzymujesz na zawsze.

Drzewo decyzji: Czy możemy to uprawiać? Proces, umiejętność, relacja, która w zrównoważony sposób produkuje zdolność, wolisz to. Jeśli uprawianie nie jest żywotne: Czy możemy to kupić? Gotowe narzędzie, które rozwiązuje 80% problemu bez niestandardowej pracy, wolisz to. Jeśli zakup nie jest żywotny: Buduj to. & buduj, wiedząc, że teraz je posiadasz.

Większość organizacji odwraca tę kolejność. Budują niestandardową infrastrukturę dla problemów, które narzędzia towarowe dobrze rozwiązują, potem rozpaczliwie utrzymują to, co zbudowali. Kanban to sprawia widocznym: każda karta w twoim Backlog to rzecz, którą wybrałeś budować. Uczciwe pytanie to czy powinna być tam w ogóle.

Buduj / Kupuj / Uprawiaj

Zastosuj ramy decyzji.

Twoje małe studio produktowe chce zbudować od podstaw niestandardowy system newslettera e-mailowego: planowanie kampanii, listy subskrybentów, analityka współczynnika otwarcia, obsługa anulowania subskrypcji. Narzędzie komercyjne istnieje, które obsługuje to wszystko za 30 dolarów/miesiąc. Twoje studio ma 3 osoby. Uargumentuj za ALBO przeciwko budowaniu go samemu. Użyj ramy "nie buduj tego, co możesz kupić, nie kupuj tego, co możesz uprawiać".

Zaprojektuj tablicę

Złóż to razem. Zaprojektujesz system kanban dla konkretnego scenariusza wielofunkcyjnego.

Scenariusz

Małe studio relancuje swój produkt z nową marką. Praca obejmuje cztery centra:

- Design: nowe logo, tożsamość wizualna, zdjęcia produktów, układy stron

- Content: przepisane opisy produktów, tekst strony głównej, ogłoszenie e-mailowe

- Build: zaktualizowana strona internetowa, nowy przepływ kasy, przekierowania ze starych adresów URL

- Ops: zaktualizowane ustawienia procesora płatności, briefing partnera logistycznego, zmiana konfiguracji analityki

Relaunch ma twardą datę graniczną: targi branżowe za 45 dni, gdzie nowa marka zostaje publiczna.

Zaprojektuj system kanban dla tej migracji. Twoja odpowiedź powinna obejmować: (1) tablice każdego zespołu, (2) jak działają handover między zespołami, (3) co najmniej jeden limit WIP & dlaczego go tam ustawiłeś, & (4) jedną kartę, którą bym NIE położył na tablicy kanban & dlaczego.

Solos pozostają silami

W większości organizacji kanban istnieje, aby sprawić, że praca jest widoczna w całej hierarchii zarządzania. Menedżerowie koordynują między silami. Kanban zmniejsza opóźnienie koordynacji.

W modelu un nie ma menedżerów. Są solos. Solo operuje przedsiębiorstwo niezależnie: solo designer, solo builder, solo writer, solo ops. Każdy solo to z definicji silo. Nie ma wykresu organizacyjnego, który ich łączy. Żadna relacja raportowania. Żaden menedżer, aby wymusić koordynację.

Kanban staje się warstwą koordynacji. Nie poprzez spłaszczanie silów, solos pozostają w pełni niezależne, ale poprzez sprawienie, że handover między nimi są widoczne & jawne. Solo nie wysyła e-maila ani nie planuje spotkania, aby przekazać pracę. Kładzie kartę na wspólnej tablicy. Przyjmujący solo ciągnie ją, gdy mają pojemność.

To wyjaśnia, dlaczego kanban pasuje do modelu un lepiej niż agile czy waterfall: nie wymaga wspólnego tempa, wspólnych retro, zsynchronizowanego planowania. Każdy solo ustawia własne limity WIP, własny czas cyklu, własną definicję gotowe. Koordynacja następuje na poziomie karty, nie na poziomie procesu.

Jesteś solo designerem & solo builderem. Nie dzielisz menedżera. Nie masz stałych spotkań. Klient właśnie zatwierdził nową funkcję: designer musi najpierw stworzyć makiety, potem builder montuje stronę. Ale builder już jest na limicie WIP. Jak koordynujesz tę pracę używając tylko kanban? Żadne spotkania. Żadne nici e-mailowe. Tylko tablice & karty.