Lubisz przystępować do akcji? Chcesz działać efektywnie i szybko dostarczać produkty klientom? Świetnie! Tylko czy nie zapominasz wtedy o jakości? Jej zaniedbywanie może powodować problemy, koszty i w ostatecznym zestawieniu nie wpływa dobrze na Twoją efektywność. Przypomnijmy sobie ogólnie znaną (i uznaną) zasadę, na którą lubimy czasem machnąć ręką 😉
Czasem bywa tak, że o rzeczach oczywistych zapominamy najczęściej. Zgodzisz się pewnie bez wahania, że im wcześniej popełnimy błąd, a brniemy dalej, tym gorzej jest to naprawić. A czy tę intuicyjną prawdę przenosisz na projekty i działanie swojej firmy?
W teorii jakości mamy zasadę 1-10-100. Mówi ona o tym, że im wcześniej poprawimy błąd, tym mniejsze będą koszty naprawy.
x1
Najtańsze jest korygowanie błędów w miejscu ich powstania. Potwierdzaj wymagania, testuj koncepcje, prototypuj i weryfikuj, sprawdzaj swoje „twory” zanim wypuścisz je z rąk, przekażesz dalej i puścisz w zapomnienie!
x10
10-krotnie droższe jest poprawianie błędów w momencie, kiedy zostaną one znalezione przez kontrolę wewnętrzną. Tester czy audytor potrzebuje czasu na przeglądy, komunikowanie problemów, ponowne sprawdzanie. Do tego wykonawca znów musi wrócić do tematu, dokonać zmian, sprawdzić.
x100
Wykrycie błędu przez klienta w czasie użytkowania produktu kosztuje już 100x więcej. Aj. Mamy tu koszty zmian, wycofywania produktu, koszty utraconych możliwości (coś mógł zarobić w międzyczasie, jeśli by dobrze działał), utratę reputacji.
Zasada ma odniesienie nie tylko do błędów działania, ale także poprawności (adekwatności) założeń. Warto zweryfikować założenia, zanim się napracujemy idąc w złym kierunku. Odnosi się to do celów projektu, wymagań, projektowania użyteczności, zapewniania bezpieczeństwa, itd.
A teraz chwila refleksji. Przypomnij sobie ostatni projekt, który, z powodu błędów (lub błędnych założeń), musiałeś poprawiać, poprawiać i poprawiać… Co wtedy czułeś? 😉
Nadal chętny do „oszczędzania czasu”? Pomyśl, ile możesz zaoszczędzić poświęcając chwilę na przemyślenie i sprawdzenie!
0 komentarzy do “Zasada 1-10-100”
Z jednej strony racja, z drugiej strony ciagle jest głośno o lean startup, podejściu RERO. Pytanie na które warto znaleźć odpowiedź brzmi: kiedy lepiej na poziomie koncepcji zastanawiać się godzinami, dniami i miesiacami, a kiedy lepiej po prostu przystapic do działania i zweryfikować swoje myśli w 'boju’?
Pytanie co w danym przypadku będzie miało gorszy skutek – popełnienie błędu czy utrata okazji?
Tylko że lean startup odnosi się chyba raczej do tworzenia produktów. Czym innym jest informatyzacja procesów biznesowych, które powinny być w firmie znane. Lepiej poznać te procesy przed projektem, niż „poznawać je” podczas testowania przez klienta. Zresztą nawet w leanie – najpierw tworzysz koncepcję, a dopiero potem ją sprawdzasz w boju.
BTW. Dużo sie mówi o leanie, jakby iteracyjne i spiralne metody wytwórcze nie istniały wcześniej 😉 Albo PDCA.
Znam przykład z własnego podwórka. Analityk z klientem ustalili prostą zmianę w procesie o skrótowej nazwie w żargonie klienta „DUŚ”, ale w wymaganiach wpisali po prostu w skrócie „DUŚ”, nie rozwijając tego branżowego żargonu. Programista zrobił tę zmianę w procesie DUŚ. Dopiero tester (czyli ja) połapał się że są dwa procesy nazywane skrótem DUŚ, i po wyjaśnieniu okazało się, że programista zmienił nie ten DUŚ co trzeba. Trzeba było wycofać zmianę, zrobić ją od nowa gdzie indziej, testy obu procesów, błędy w obu procesach, w sumie prosta zmiana zajęła 3-4 razy więcej czasu niż początkowe szacunki. Można było tego uniknąć gdyby cały zespół (analityk+tester+dev) brali od początku udział w ustalaniu wymagań, wtedy może ktoś na początku by spytał „chwila chwila, a o który DUŚ konkretnie chodzi” ?
Samo życie ?