Jeżeli coś robimy dwa razy, to zwykle można założyć, że jedno wykonanie jest niepotrzebne. To dość śmiała teza, ale postaram się ją w kilku krokach przedstawić tak, aby broniła się sama. Uwaga! W dzisiejszym tekście będzie pełno tzw. buzzowrds, jak np. agile, waste, redundancja.
Czym jest redundancja?
Redundancja w naszej branży rozumiana jest najczęściej jako duplikacja pewnych mechanizmów bądź danych, która umożliwia nominalną pracę systemu nawet, gdy niektóre elementy zostaną uszkodzone. Słownikowo, redundancja to „cecha komunikatu zawierającego więcej informacji, niż jest to niezbędne do przekazania jego treści” (SJP PWN). W obu przypadkach mamy więc do czynienia z celową nadmiarowością.
Typowe inżynierskie przykłady redundancji to zwielokrotnianie zabezpieczeń, które może okazać się pomocne w przypadku wykrycia luki bądź złamania jednego z nich oraz duplikowanie danych, gdzie np. w macierzach RAID albo klastrach przechowywane są te same dane, na wypadek uszkodzenia któregoś z elementów składowych (np. dysku). Co jakiś czas pojawiają się na naszym blogu przykłady z okolic lotnictwa, a nowoczesny samolot jest idealnym przykładem, żeby omówić redundancję.
W samolocie większość systemów występuje w kilku kopiach. To znaczy, że gdy z jakiegokolwiek powodu (zwykle usterka mechaniczna) padnie nam możliwość obsługiwania sterów, to jest dostępny drugi system, który potrafi zrobić dokładnie to samo, a który jest mechanicznie i elektrycznie niezależny od tego pierwszego. Redundancja większości elementów w samolocie składa się na bezpieczeństwo. Ba, nawet silniki są redundantne – dwusilnikowy samolot jest w stanie wykonać wszystkie operacje (start, przelot, lądowanie) przy użyciu tylko jednego silnika.
Oczywiście, jeżeli nasz samolot ma tylko jeden silnik, to sytuacja wygląda zupełnie inaczej…
Co ma redundancja do marnotrawstwa?
Łukasz w tekście „Waste czyli marnotrawstwo” przedstawiał lean’owe i kanbanowe podejście do marnotrawstwa, czyli waste’ów. Zainteresowanych odsyłam tam, a podstawy przypominam tu.
Aby budować efektywne procesy, wspomniane powyżej teorie głoszą, że powinniśmy ciągle walczyć z rozrzutnością, przeciążeniami i nierównościami objawiającymi się takimi zbędnymi rzeczami jak transport, magazynowanie, przesunięcia, oczekiwanie, nadprodukcja, nadgorliwość i błędy. Pamiętajmy jednak, że każdy kij ma dwa końce i czasami uciekając od jednej pułapki, ładujemy się w drugą.
Walcząc z marnotrawstwem możemy przesadzić i zacząć budować procesy skrajnie niebezpieczne. Np. ograniczając magazynowanie możemy zrezygnować w ogóle z zapasów. Pamiętajmy jednak, że wtedy przy najdrobniejszym potknięciu pojawi nam się waste w postaci oczekiwania i/lub transportu. Teoria leanowa dość zgrabnie obejmuje tyle aspektów procesów, że trudno jest tu przesadzić w jedną stronę, nie powodując problemów gdzie indziej.
Jedną z możliwych pułapek, która na pierwszy rzut oka nie powoduje powstawania dodatkowych waste’ów jest bohaterka dzisiejszego tekstu, czyli redundancja. Ale jak tylko zaczniemy się przyglądać naszym rozwiązaniom bliżej, to okaże się, że redundancja w jednym przypadku może powodować magazynowanie, a w innym nadprodukcję bądź nadgorliwość.
Nie każdy jednak działa leanowo i analizuje, czy to, co robimy nie powoduje marnotrawstwa. A przecież argumenty o potrzebie redundancji z pierwszych kilku akapitów tego tekstu brzmią dość przekonująco. Co więc może być nie tak z działaniem na zapas bądź zabezpieczaniem się przed wyjątkowymi sytuacjami?
Marnotrawienie agile’a
I tu dochodzimy do sedna problemu, czyli do tego, czemu redundancja ma służyć. Jeśli jest to wymaganie samo z siebie (patrz: samolot), to pewnie ma ona sens. Jeżeli jednak chodzi o nasze szeroko rozumiane procesy, w tym te wytwórcze, to zastanówmy się, czy w ogóle mamy z niej korzyść. Nawet potencjalną.
Nazywanie redundancji „największym marnotrawstwem” może i jest nieco na wyrost, do czasu aż nie porozmawiamy o typowych przykładach. Dwa systemy do zarządzania zadaniami. Dwie instancje tego samego narzędzia. Raportowanie czasu pracy w dwóch miejscach. Wycena wymagań osobno w man-day’ach, a osobno w Story Pointach. Akceptacja zadań przez kilka różnych osób po kolei. Składanie podpisów przed wdrożeniem. Osobne prezentacje dla kierownictwa, a osobne dla zarządu. I tak dalej…
„Zbędne operacje technologiczne i kontrolne”, to hasło które aż się prosi, żeby użyć go do opisania powyższych sytuacji. A to jest oczywiste marnotrawstwo. Może kiedyś one czemuś służyło, a może to po prostu kolejna emanacja dupokrytki. Zdarzają się też takie sytuacje, że coś jest robione, bo „zawsze tak robiliśmy„. Czasami nikt się po prostu nie zastanawia, czemu dana redundancja ma służyć.
Sytuacja nie jest taka oczywista, bo ktoś może powiedzieć, że ta konkretna redundancja jest potrzebna do zapewnienia jakości. Testy na środowisku deweloperskim to nie to samo co UAT-y, więc nie ma niczego złego w podwójnym testowaniu tego samego. Naprawdę? Jeżeli testujemy dokładnie to samo, to jest to zbędna redundancja. A jeżeli testujemy coś innego i w inny sposób, to… zastanówmy się, czy nie jesteśmy w stanie zapewnić „UAT-owej jakości” już na wcześniejszym etapie.
Nie mówię, że zawsze się da, ani że jest to proste. Ale każdy, absolutnie każdy przykład redundancji w naszych procesach powinien być przeanalizowany jako potencjalne marnotrawstwo. Czyż zamiast robić coś kilka razy, nie lepiej jest zrobić raz a dobrze?
