Czy droga Toyoty do doskonałej jakości może znaleźć zastosowanie poza produkcją? Czy może zostać wykorzystana w branży usługowej, a nawet w środowisku tak specyficznym jak programowanie? Fabrice Bernhard, współzałożyciel i dyrektor techniczny firmy Theodo, wyjaśnia, w jaki sposób jego organizacja wykorzystała opracowane w Toyocie metody osiągnięcia jakości Dantotsu w pracach programistycznych. Dzięki temu możecie dowiedzieć się, jak owe metody mogą zmienić standardy tworzenia oprogramowania i spektakularnie zmniejszyć liczbę błędów w kodzie.
Oprogramowanie dotyczy całego świata i każdego jego aspektu, co oznacza, że branża nie może „produkować” średnio 10 błędów na 1000 linii kodu. Jednym z rozwiązań jest przyjęcie standardów przemysłu lotniczego: zespół inżynierów oprogramowania dla promu kosmicznego wypuścił jeden błąd na 400 000 linii kodu, co oznacza 4000 razy lepszy standard jakości. Ale jakim kosztem? Ich procesy obejmują pisanie czterech stron specyfikacji na każde dziesięć linii kodu. Nie jest to podejście skalowalne do takiej ilości oprogramowania, jakiej potrzebuje świat.
Szukając alternatywnych rozwiązań w celu osiągnięcia jakości w niezbędnej skali, natknęliśmy się na książkę Sadao Nomury Droga Toyoty do doskonałej jakości, w której autor opisuje swoje niesamowite osiągnięcia w zakresie jakości w Toyota Logistics & Forklift (TL&F).
Sadao Nomura pracował w Toyota Motor Corporation od 1965 roku, a w roku 2006 kierownictwo powierzyło mu zadanie poprawy jakości w TL&F. Nie było to jego pierwsze zetknięcie się z problemami jakościowymi. Wcześniej z powodzeniem usprawniał fabrykę GM w Australii i pomógł Toyocie w RPA osiągnąć poziom jakości, którego centrala potrzebowała do autoryzacji globalnego eksportu.
W TL&F pełnił funkcję doradcy w siedmiu zakładach w pięciu krajach, z których większość została niedawno przejęta przez firmę. Zaczął w sposób typowy dla Lean, często odwiedzając gemba. Swoje spostrzeżenia dotyczące rozwiązywania problemów zapisywał na kartach formatu A3 i dzielił się nimi z kierownictwem. Ale nie nastąpiła żadna zmiana. Wyglądało na to, że nikt nie zwracał uwagi na jego rady. Nie pomagał też fakt, że jakość zakładów była – w porównaniu do standardów w branży – stosunkowo dobra.
Nomura jeszcze dwukrotnie próbował podzielić się swoją wiedzą i doświadczeniem, ale bez powodzenia. Po tym, jak trzecia próba zakończyła się niepowodzeniem i minął rok, zmienił swoją strategię. Tym razem chciał być pewien, że jakość stanie się priorytetem dla wszystkich. Przy wsparciu centrali stworzył program o nazwie „Działania na rzecz jakości Dantotsu”. Dantotsu to japoński termin oznaczający „spektakularny”, „radykalny” lub „niezrównany”. Program miał na celu przeszkolenie pracowników i zmotywowanie ich do osiągnięcia ambitnego celu, jakim było zmniejszenie o połowę liczby wad rocznie. Dzięki nieustannemu przestrzeganiu działań Dantotsu zespół powinien osiągnąć trzyletni cel zmniejszenia liczby wad o 88%.
Członkowie zespołów w zakładach widzieli już wcześniej porażki programów jakościowych, więc tylko częściowo ufali nowemu. Pracownicy zdali sobie jednak sprawę z potrzeby czegoś nowego, a podejście Nomury do Dantotsu było zdecydowanie inne. Konsekwentnie koncentrując się na poprawie jakości, w końcu wprowadził zmiany w fabrykach. Po ośmiu latach siedem fabryk zmniejszyło liczbę wad o 91-98%. Amerykańska fabryka Raymond Corporation została uhonorowana „Best Plant Award”, przyznawaną przez magazyn „Industry Week”.
Historia Nomury dotyczy poprawy jakości w zakładach produkcyjnych. Niemniej zainspirowała nas ona do przyjęcia podejścia „dobrze za pierwszym razem” (right-first-time) w pracach nad oprogramowaniem. Oto trzy pomysły, które zaczerpnęliśmy z książki i przenieśliśmy na grunt programistyczny.
Nowe podejście do analizy błędów
Sposób na poprawę jakości jest prosty – zmniejszyć liczbę wad, lub – w naszym wypadku – błędów w kodzie. Ale najprostszym sposobem na zmniejszenie liczby wad jest poświęcenie mniejszego wysiłku na ich poszukiwanie. Aby tego uniknąć, Nomura kategoryzuje problemy według etapu ich wykrywania i kładzie nacisk nie na zmniejszanie liczby wad, ale na wykrywanie ich na jak najwcześniejszym etapie produkcji. Zastosowaliśmy to do inżynierii oprogramowania i zdefiniowaliśmy następujące etapy identyfikacji błędów:
- etap A, jeśli błąd został wykryty przez programistę podczas końcowego przeglądu przed opublikowaniem kodu;
- etap B, jeśli został wykryty przez kogoś innego w zespole lub w łańcuchu ciągłej integracji przed dotarciem do klienta wewnętrznego;
- etap C, jeśli został wykryty po dotarciu do klienta wewnętrznego (kierownik projektu, QA itp.) i przed przekazaniem na produkcję;
- etap D, jeśli został wykryty po wdrożeniu do produkcji, gdzie mógł mieć wpływ na klienta zewnętrznego, przed otrzymaniem reklamacji;
- etap E, jeśli spowodowało to reklamację klienta.
Ta kategoryzacja zapewnia rozsądny cel. Zespoły starają się wykrywać błędy na etapach A i B, zanim przedostaną się one na użytkowników końcowych. Łatwiej i taniej jest również korygować błędy na tych etapach. W ten sposób zespoły mogą uniknąć błędów na etapach D i E, zanim wpłyną one na użytkowników końcowych.
Systematyczna analiza wad/błędów
Dzięki systematycznemu podejściu do analizy powstających błędów zespoły mogą szybko zidentyfikować źródło problemów z jakością i sposoby zapobiegania im. Pomaga to również liderom zespołów w postrzeganiu wyzwań związanych z jakością jako okazji do nauki. Analiza wad ujawnia luki w wiedzy, które można następnie uzupełnić poprzez szkolenia.
Ryc. 1. Przykład analizy Dantotsu w firmie Theodo
Książka Sadao Nomury znacząco poprawiła nasze podejście do analizy błędów, w tym rozstrzygnęła starą debatę na temat tego, czy należy skupić się na zapobieganiu im, czy na ich wcześniejszym wykrywaniu. Odpowiedź Nomury jest prosta: powinniśmy przeanalizować zarówno to, jak zespół mógł zapobiec błędowi, jak i to, jak mógł go wcześniej wykryć.
Przyjęcie praktyki zarządzania słabymi punktami (ang. weak point management)
Dzięki systematycznej analizie błędów zespoły zaczynają dostrzegać prawidłowości i identyfikować kategorie ich przyczyn. Nomura nazywa je słabymi punktami (ang. weak point). Gdy zespół zidentyfikuje słabe punkty, może wybrać jeden z nich i wyeliminować go raz na zawsze.
Na przykład przez dłuższy czas borykaliśmy się ze sporadycznymi błędami w automatycznym testowaniu naszego kodu. Nie były one związane z podstawowymi problemami w kodzie, lecz z głębszymi problemami w używanej przez nas bibliotece testowej typu open-source, a pracownicy traktowali je jako „nieuniknione”. Ponieważ była to znana kwestia, dotycząca wielu naszych i innych zespołów na całym świecie, postanowiliśmy zbadać ją dokładniej. Problem okazał się trudny do rozwiązania, ale dzięki skoncentrowanemu wysiłkowi opracowaliśmy łatkę, którą dostarczyliśmy do biblioteki open-source. Problem został rozwiązany w sposób trwały nie tylko dla naszych zespołów, lecz także dla wszystkich innych użytkowników biblioteki.
Po dwóch latach wdrażania takich praktyk w Theodo w 80% naszych projektów analizujemy obecnie liczbę błędów w kategoriach etapów wykrywania od A do E. Udoskonaliliśmy standard skutecznej analizy tych błędów, aby pomóc liderom technicznym przyjąć go w swoich zespołach. Pracujemy też nad tym, by owa analiza stała się częścią rutyny zespołu, tak żeby przyspieszyć naukę i zidentyfikować powtarzające się problemy.
Kilka zespołów eksperymentuje nawet z systematyczną analizą błędów na etapie A. Oznaczają swój fragment jako błędny, jeśli nie przejdzie pierwszego testu przez człowieka. Jest to oryginalne podejście, ponieważ inżynierowie kodują iteracyjne, jednak wspomniane zespoły postanowiły dążyć do poprawnego kodu za pierwszym razem. Wyniki są obiecujące. Jeden z zespołów zbudował aplikację medyczną z 6000 linii kodu i dostarczył tylko dwa błędy na produkcję. To 30 razy mniej niż średnia w branży bez konieczności dokumentowania każdej linii kodu na setkach stron.
Wciąż jesteśmy na początku naszej drogi przenoszenia treści książki Sadao Nomury na oprogramowanie, ale obserwacja tak spektakularnej poprawy okazała się bardzo inspirująca. Kolejny raz okazuje się, że Lean jest niezbędnym źródłem wiedzy, bez względu na branżę, jeśli chodzi o osiąganie jakości na dużą skalę.
O autorze artykułu
Fabrice Bernhard jest współautorem The Lean Tech Manifesto i dyrektorem technicznym Theodo, wiodącej firmy konsultingowej w dziedzinie technologii, którą założył wspólnie z Benoît Charles-Lavauzelle. Firma osiągnęła wzrost od 1 miliona dolarów przychodu i 10 zatrudnionych osób w 2012 roku do 100 milionów dolarów przychodu i 700 osób w 2022 roku.
Jest ekspertem w dziedzinie technologii i transformacji na dużą skalę i przyczynił się do bardziej zrównoważonego skalowania wielu start-upów dzięki podejściu Lean. Występował na licznych konferencjach międzynarodowych, gdzie nieustannie dzieli się swoim doświadczeniem.
Artykuł oryginalnie ukazał się w języku angielskim i jest dostępny tutaj. Książka Droga Toyoty do doskonałej jakości ukazała się nakładem Wydawnictwa Lean Enterprise Institute Polska i jest dostępna w naszej księgarni leanbooks.pl. Książka została objęta patronatem firmy Toyota Material Handling Polska.