Kaizen po japońsku dosłownie znaczy "zmiana na lepsze". Samo pojęcie pochodzi z fabryk Toyoty, a jedna z zasad kaizen brzmi: pięć razy zapytaj "dlaczego?".

Masaaki Imai, guru i popularyzator kaizen, w swojej książce podaje ciekawy przykład. W fabryce menedżer zauważył, że robotnik wysypał podłogę piaskiem. Zapytał "dlaczego?" i dowiedział się, że była śliska. "Dlaczego?" - zapytał ponownie i dowiedział się, że na podłodze był olej. Gdy dalej stawiał pytanie "dlaczego?", robotnik powiedział, że olej wyciekł z maszyny. "Dlaczego?" Bo się rozszczelniła jedna z przekładni. Po kolejnym "dlaczego?" znał już przyczynę źródłową: nity zastosowane do łączenia stali były zbyt słabe jak na naprężenia i wibracje, przekładnia się rozszczelniała i olej wyciekał. Wysypanie podłogi piaskiem usunęło skutek; zmiana nitów w maszynie nie tylko poprawiła bezpieczeństwo pracy, ale i przedłużyła żywotność maszyny.

Kiedy zacząłem programować na dobre, starano się mnie skutecznie oduczyć pytania "dlaczego?". Liczyło się, by program był szybko dostępny (mówiono: "prawie gotowy" i bardzo późno zdałem sobie sprawę, jak wielką różnicę robi "prawie"). Każdy błąd należało szybko usunąć i przywrócić działanie programu. Kiedy zaś program działał, nikt nie suszył mi głowy, żebym cokolwiek poprawiał albo szukał rzeczywistej przyczyny źródłowej.

Dopiero parę lat później, pod wpływem autorów paru dobrych książek, zacząłem zadawać sobie pytanie "dlaczego?" Zajmowałem się już wtedy prowadzeniem projektów i wdrożeniami. Kiedyś przyłapałem się na tym, że nie doszacowałem czasu potrzebnego na testy w projekcie - pomyliłem się o, bagatela, 400%. Dlaczego? Bo przyjąłem, że wszystko uda się za pierwszym razem i potrzebne będą minimalne zmiany. Dlaczego? Bo nie miałem doświadczeń i danych z poprzednich projektów. Dlaczego - bo nie wysiliłem się, by je zdobyć, a nikt nie zakwestionował mojego harmonogramu. Dlaczego? Zapewne dlatego, że myślałem, że jestem tak cholernie dobry, że nie muszę pytać innych o opinię na temat swoich planów. Dlaczego? Bo zarówno mój szef, jak i mój klient nie byli dostatecznie "silni" merytorycznie, żebym miał ich pytać o zdanie.

Oto więc nauka. Nie tylko nauczyłem się przewidywać dłuższy czas na testy. Nauczyłem się robić tzw. analizę ryzyk. Nabyłem także nawyku, by zawsze planować przy użyciu danych z rzeczywistych projektów. Zacząłem także pytać innych o zdanie. Nadal się mylę, ale rzadziej i mniej.

Zanim nasypiecie piasku, nie zapomnijcie zapytać: "dlaczego?"