Problem zgłasza się sam, ktoś go bierze, naprawia, wdraża, sprawdza i zamyka — a po drodze zostaje ślad. O pętli, która pilnuje, żeby usterki nie wyciekały.
Jeden język usterek
Zamiast ręcznego listy usterek trzymanej w głowie, cały zespół mówi jednym językiem: problem staje się kartą, karta ma właściciela, a praca nad nią ciągnie się od zgłoszenia do zamknięcia. Każda naprawa zostawia ślad, po którym widać, co było, kto to wziął i co z tego wynikło. To nie jest zarządzanie zadaniami wraku – to pętla, którą da się zamknąć sama.
Obserwacja, nie zgadywanie
Kiedy coś przestaje działać, ktoś to zauważa – człowiek albo automat. Ta obserwacja ląduje w jednym wspólnym miejscu, z odciskiem tego, co dokładnie pękło. Jeśli to samo psuje się już wcześniej, nie rozjeżdżamy się po temacie od nowa – do pasującego śladu dopisujemy tylko nowy komentarz. Dzięki temu na górze zawsze widać świeże i unikatowe problemy, nie pudło ze stu kopii tej samej usterki.
Od zgłoszenia do zamknięcia
Konkretną kartę bierze na warsztat ta osoba, która akurat jest wolna. Bierze zamiast czekać na rozdzielnik. Po drodze ostatecznie: poprawia, wdraża na produkcję i uruchamia testy, które sprawdzają, czy naprawa faktycznie zadziałała. Dopiero gdy testy świecą na zielono, temat idzie do zamknięcia – z własnym opisem tego, co zostało zrobione. Nikt nie mówi „zrobione” tylko dlatego, że coś wpisano w edytorze.
Koło, nie jednorazowy trik
Najciekawsze w tej pętli jest to, że każdy jej kawałek da się podpiąć pod automat. Gdy monitor zobaczy, że usterka wróciła, sam przypomni o otwartej karcie. Gdy zobaczy, że już działa, sam zamknie temat. A człowiek nie musi nic rubrykować – jego rola to naprawa, nie księgowość. Całość układa się w koło, które przypomina wiosenne porządki: pod warunkiem, że ktoś w ogóle z niego korzysta. U mnie te koła kręcą się najbardziej tam, gdzie praca jest codzienna – w operatorze strony.