Kolejna idea pochodząca z fabryk Toyoty, ale znajdująca swoje odpowiedniki w informatyce, to minimalizacja czasu nieproduktywnego, np. czasu oczekiwania. Doskonałym przykładem środowiska, które wprowadza nieuzasadnione opóźnienia, jest kompilator. W językach takich, jak C czy C++, przetestowanie nawet najprostszego programu, zawierającego choćby jedną linijkę, wymaga przekompilowania tysięcy linii standardowych nagłówków. Inny przykład, w wymiarze bardziej organizacyjnym, to tzw. integrowanie oprogramowania. Jeżeli zespół pracuje nad różnymi fragmentami tego samego produktu, to często po pewnym czasie musi ponownie "uzgodnić wersje" systemu. Otóż taka integracja to typowy krok jałowy spowodowany jedynie podjęciem wcześniej błędnej decyzji o rozproszeniu środowisk. I wreszcie można podać przykład rozmaitych dokumentacji. W skrajnym przypadku, w jednej z firm informatycznych wymagano aż trzech dokumentacji dotyczących tego samego: jedną miał być możliwie czytelnie i prosto napisany kod, drugą - komentarze do niego, zaś trzecią - opis słowny logiki każdej procedury osobno.

Następny termin, który warto przyswoić sobie z japońskiego, to kaizen. To słowo określa drobne usprawnienie, niewielką innowację wypracowaną przez zespół i przyjętą do stosowania. Kaizen w ujęciu informatycznym może oznaczać np. prefiksowanie literami MIL tablic w bazie danych, które docelowo będą mieć więcej niż milion elementów. Dzięki temu kaizenowi każdy autor zapytania od razu zastanowi się, czy na pewno tę tablicę należy włączać do zapytania, bo może ono trwać bardzo długo. Kaizen to także proste ulepszenie komunikacyjne - np. stosowanie jednego szablonu do opisu okna dialogowego aplikacji. To również analiza zespołowa powtarzającego się błędu: dlaczego się zdarzył? Co należałoby zrobić, żeby uniknąć go w przyszłości?

Na to ostatnie pytanie odpowiedź można sformułować również po japońsku. W inżynierii przemysłowej stosowane jest tzw. poka-yoke. Najlepsze, choć rozwlekłe polskie tłumaczenie tego słowa to "stwarzanie warunków, w których błąd fizycznie nie może się zdarzyć albo będzie natychmiast widoczny". Mniej eleganckie, ale równie trafne określenie to "idiotoodporność". Doskonałym przykładem tego mechanizmu, znanym każdemu użytkownikowi telefonu komórkowego, jest ścięty róg karty SIM. Dzięki temu jest dokładnie jeden sposób włożenia karty, która zawsze będzie pasować do styków przewodzących telefonu. Podobnego mechanizmu nie zastosowano w kartach bankomatowych - są one obustronnie symetryczne, więc istnieją aż trzy niewłaściwe sposoby włożenia jej do szczeliny i tylko jeden prawidłowy. Codziennie miliony ludzi robią tysiące błędów - tylko dlatego, że karty bankomatowej nie zaprojektowano zgodnie z zasadą poka-yoke.

W informatyce mechanizm poka-yoke można stosować poprzez wbudowywanie w systemach mechanizmów kontrolnych, które uniemożliwiają propagację błędnych danych. Typowy przykład, niestety, nie zawsze stosowany, to "wyszarzanie" przycisku OK w okienku, w którym nie wpisano kompletnych danych. Użytkownik nie może kontynuować pracy z niekompletnymi informacjami, bo aplikacja nie pozwala na to. Znacznie rzadziej - niestety niesłusznie - stosowane są przykłady bardziej techniczne: np. weryfikacja liczności rekordów po replikacji danych, obliczanie sum kontrolnych CRC przy transferach, sprawdzanie klauzulą assert wartości zmiennych programu... Tymczasem stosowanie tego prostego mechanizmu pozwala w oczywisty sposób ograniczać liczbę błędów, które pojawiają się w produkcie finalnym lub - w najlepszym razie - wychodzą na testach.

A jednak warto testować

I tak doszliśmy znów do testowania oprogramowania. Jest ono niewątpliwie niezbędnym elementem procesu wytwórczego systemów informatycznych. Warto, naprawdę warto gruntownie i systematycznie przetestować system przed jego wdrożeniem. Trzeba jednak pamiętać - wyłowienie i usunięcie defektu w testach jest szalenie kosztowne, więc testowanie nie powinno zastępować pozostałych elementów systemów jakości.

Należy ograniczać możliwość pojawienia się błędów zamiast usuwać je, gdy już się wkradną w produkt. Nieuczciwie byłoby powiedzieć, że dziś, AD 2005, wiemy jak to robić dla produktów informatycznych. Jednak inspirowanie się dobrymi praktykami z systemów produkcji przemysłowej jest dobrym pomysłem, który pozwoli dołożyć jeszcze jedną cegiełkę do gmachu, któremu na imię dobre i niezawodne systemy informatyczne.