Poka-yoke – a gdyby tak nie dało się nie dać?
Zaktualizowano: 23 cze 2021
Czyli o tym co stolik z IKEA, rejestracja w Mailchimpie i twój proces i produkt powinny mieć wspólnego?
Epizod I – Stolik
Stolik IKEA, który kupiłem pod drukarkę składał się z dokładnie 10 części i jednego dołączonego narzędzia. Jak każdy inżynier rzuciłem się w wir montażu.. bez szczegółowej lektury instrukcji.
Zaczynamy:
4 wsporniki i górny blat. Jak to zmontować?
Nie, narzędzia nie będą potrzebne.
Nie, nie ma śrub, które można pomylić lub zgubić.
W blacie znajduje się 8 otworów, po 2 na każdym z rogów. Nie są jednakowe. Są wyprofilowane tak, że wsporniki da się umieścić w nich tylko jeden – prawidłowy sposób. Wciskasz, wykonujesz obrót o 90 stopni, również możliwy tylko jedną stronę, co powoduje dociągnięcie „nóg” i stop. O ile nie użyjemy sił super bohatera wiemy, że to już koniec. Zrobione.
Pozostały montaż to wkręcenie 4 śrub zintegrowanych z kółkami, które mocują dno stolika do wsporników. Po prostu nie da się nie zrobić tego dobrze. Wiem, wiem, że jak się człowiek postara to można coś złamać, przekręcić, itp., ale nie o to chodzi.
Poka-yoke to japoński termin ze słownika lean, który oznacza taką konstrukcję (przedmiotu czy procesu), która zapobiega nieumyślnym błędom.
Epizod drugi – rejestracja w Mailchimpie
Masz to za sobą? Pewnie wiesz o czym mówię. Seria zajmujących cały ekran kroków, prostych pytań, wizualizacja i natychmiastowa informacja zwrotna, czy możesz iść dalej. Nawet jeśli nie masz większego pojęcia o profesjonalnym marketingu i mailingu to w kilka minut jesteś tam, gdzie trzeba. Przygoda nie kończy się na rejestracji, bo jaka z tego wartość dla użytkownika? Podróż kończy się gotowością do stworzenia i wysłania pierwszej kampanii mailingowej.
Oczywiście można się na siłę postarać odnieść porażkę, ale kto tak robi? Chyba tylko testerzy (sam kiedyś nim byłem to wiem co mówię 😊)
Epizod trzeci – Twój proces lub produkt
A jak jest z dowolnym procesem w Twoim zespole czy firmie? Jak jest z Twoim produktem?
Jak wygląda proces od wprowadzania zmiany w kodzie, przez pull request i przegląd i aż do deploymentu? Da się nie wiedzieć jak? Ale po co zapytasz? Postaw się w sytuacji osoby z innego zespołu, którą poprosiłeś o pomoc w Twoim kodzie?
Narzekasz na Jirę? Świetnie, a da się w niej źle kliknąć? Przenieść zadanie do statusu bez odwrotu? Przypisać to do osoby z czapy? Powiem Ci coś to nie wina Jiry 🙂
Jeśli budujesz produkt to raczej chcesz, żeby użytkownikowi się udało. Udało? Udało znaczy, że z czymś musiał się borykać, żeby dokończyć rejestrację lub skorzystać z jakiejś opcji. Udało oznacza, że mogło się nie udać. Nie chcesz przecież żeby wypadł z “lejka” i zakończył swoją podróż przedwcześnie. Pomyśl, jak skazać go na sukces aż do momentu, kiedy naciśnie „Zapłać” albo jeszcze lepiej. Do momentu, kiedy z pełnym przekonaniem będzie mógł podzielić się opinią (pozytywną) o Twoim produkcie.
Nawet jeśli Twój klient lub użytkownik nie płaci bezpośrednio to warto pomyśleć o poka-yoke tak by uwolnić np. klienta wewnętrznego od skupiania się nad oczywistymi oczywistościami. Tak jak wtyczki USB-C nie da się włożyć źle, tak może nie powinno udać się źle użyć waszego API, a jeśli ktoś już się bardzo postara to niech przynajmniej tak szybko, jak to możliwe o tym wie.
Pamiętaj, że wszelkie akcje kończące się niepowodzeniem powodują generowanie dodatkowej pracy Tobie i innym. Zjadają czas. Od prostego „Daj pokażę Ci jak to zrobić”, po niepotrzebny telefon/mail do obsługi klienta, założenie ticketu, jego analizę, z której i tak wyniknie, że „to nie bug a ficzer”, a użytkownik powinien przecież wiedzieć, że…
Serio? Powinien?
Jak ugryźć poka-yoke?
Osobiście zacząłbym od testu na procesie lub produkcie przeprowadzonym przez kogoś z zewnątrz. Poprośmy kogoś choćby z wewnątrz firmy, może innego zespołu, a już najlepiej z zewnątrz i zobaczmy co – które kroki sprawiają mu potencjalne problemy.
Nie wszystko na raz. Skupmy się na jednym kroku i pomyślmy o rozwiązaniu, które uchroni tę osobę następnym razem przez niezamierzoną pomyłką. To prostsze niż myślisz.