Podsumowanie Panelu – Identyfikacja Strat w IT

Wprowadzenie

Jeśli uczestniczyliście w tym roku w konferencji TestWarez 2018, podczas drugiego dnia konferencji mogliście znaleźć następującą pozycję w agendzie:

• Identyfikacja strat w procesie wytwarzania oprogramowania. Zero waste w IT – czy to możliwe?

O godzinie 12:20 w piątek w Rysy V w hotelu Nosalowy Dwór grupa około 12 osób zebrała się aby wymienić się doświadczeniami dotyczącymi jak identyfikować i radzić sobie ze stratą.

Możecie słusznie zapytać kto stracił a kto zyskał po tej dyskusji. I będzie to pytanie słuszne – jesteśmy przekonani, że wszyscy zyskali. Ale nie o stratę w sensie dosłownym nam chodzi a o marnotrawstwo. 

Zacznijmy jednak od początku.

Lean Management

Cofnijmy się do lat 70 ubiegłego wieku i przenieśmy do Japonii. Tamtejszy rynek motoryzacyjny podniósł się po wojnie i drakońskich sankcjach nałożonych przez społeczność międzynarodową.

Japończycy byli gotowi na ekspansje na inne rynki, w szczególności na rynek amerykański. Toyota jako lider tego wyścigu w ojczyźnie rozpoczął marsz ku pierwszemu miejscu także w USA. Po kilku pracowitych latach amerykańskie koncerny zaniepokojone tym jak poczyna sobie obca firma zaczęły się interesować procesem wytwarzania jaki stosowała Toyota właśnie.

Tak w dużym uproszczeniu wygląda historia Toyota Production System czyli inspiracji koncepcji, która znana jest pod nazwą lean management. W dużym skrócie to ona stała za sukcesem Toyoty i innych japońskich koncernów motoryzacyjnych.

Jednym z filarów tej idei są 3 pojęcia, opisane pojedyncznym japońskim słowem:

• muda – marnotrawstwo, strata.
• mura – nieregularność.
• muri – nadmierne obciążenie pracą.

Esencją szczupłego zarządzania jest minimalizacja a nawet eliminacja w trzech wymienionych obszarach. Co ważniejsze, to nie jest stan, który możemy osiągnąć a ciągły proces doskonalenia wspierany eksperymentami i weryfikacją hipotez w cyklu PDCA (Plan, Do, Check, Act).

Najważniejszą umiejętnością jeśli chodzi o zwalczanie marnotrawstw, jest ich identyfikacja. Bez tego nie jesteśmy w stanie nawet zauważyć, że marnujemy zasoby (np. czas, pieniądze, talent) lub generujemy nowe straty.

Oryginalnie TPS i lean management definiowały 7 podstawowych strat, jednak z biegiem czasu oraz próbą dostosowywania tych koncepcji także do sektora usługowego pojawiły się 2 dodatkowe definicje.

Oto pełna lista, z zachowaniem kolejności – siedem pierwszych strat opisywanych jest przez oryginalne opracowanie:  

1. Zapas (Inventory)
2. Nadprodukcja (Overproduction)
3. Nadmierne przetwarzanie (Overprocessing)
4. Transport (Transportation)
5. Oczekiwanie (Waiting)
6. Zbędny ruch (Motion)
7. Błędy (Defects)
8. Strata talentu pracownika (Waste of Talent)
9. Utrata zasobów (Waste of Resources)

Przebieg dyskusji

Podczas dyskusji korzystaliśmy z poniższej prezentacji:

Chodziło głównie o ramy (lista 9 marnotrawstw) i pytania pomocnicze, które przywracały zatrzymaną dyskusję na właściwe tory.

Ku naszemu zaskoczeniu nie mieliśmy problemu z przełożeniem większości wymienionych definicji na realia IT i procesu wytwarzania oprogramowania. Na pierwszy rzut oka mogłoby się wydawać, że koncepcje jak zbędny ruch lub transport nie odnoszą się do realiów sektora usług. Jednak nic bardziej mylnego – zobaczcie sami jakie obserwacje oraz pomysły na usprawnienia wypracowaliśmy kolektywnie jako grupa.

Pomysły, wnioski i obserwacje

1. Walka z marnotrawstwem może generować inne straty.
   • Po przeczytaniu tego akapitu to może brzmieć jak oczywistość, ale nie można o tym zapominać – podczas szaleńczej walki ze stratami możemy zatracić się w chaosie. Skończymy na przeprowadzaniu wielu eksperymentów równolegle, a to wszystko bez odpowiedniej organizacji i standaryzacji, co doprowadzi do rychłej katastrofy i kolejnych marnotrawstw.
   • Warto skupić się na jednym problemie i zmieniać tylko jeden element w danym momencie.
   • Kolejną bardzo ważną obserwacją było to, że efektywne wdrożenie usprawnień to wyzwanie samo w sobie. Konsekwencja we wdrażaniu poprawek po retrospekcji to tylko wierzchołek góry lodowej. Co zrobić z usprawnieniami zanotowanymi podczas spotkania, którymi się nie zajmiemy – czy powinniśy tworzyć zadania, do których być może nigdy nie wrócimy? Jak zachęcić ludzi do zmiany przyzwyczajeń i efektywnie przejść przez zmianę.
   • Powyższe pytania były w większości przypadków adresowane odpowiednią grywalizacją (przejście przez zmianę) oraz poleganiem na szczerości i zgraniu zespołu (ważne nierozwiązane i niezaadresowane problemy zostaną ponownie zasygnalizowane).
2. Koncepcja mianowanego lidera jest przyczyną wielu marnotrawstw.
   • Na pierwszy rzut oka to brzmi jak bardzo kontrowersyjny temat, jednak co do którego zgodziliśmy się jako grupa w 100%.
   • Po pierwsze: bardzo często kryteria takiego awansu nie mają nic wspólnego z merytorycznymi umiejętnościami. To rodzi opór grupy w związku z brakiem autorytetu.
   • Po drugie: namaszczenie świetnego pracownika na lidera, bez jego inicjatywy może spowodować, że stracimy dobrego pracownika i zyskamy słabego lidera.
   • Powinniśmy się zainspirować koncepcją lidera w kontekście lean management. Mówi ona że, liderem całej linii produkcyjnej może zostać człowiek, który przepracował określoną ilość godzin na każdym stanowisku z linii, którą będzie obserwował.
   • Innym rozwiązaniem, które pojawiło się w trakcie dyskusji (pozdrawiamy czerwonego królika od Remigiusza) była koncepcja przechodniego lidera. Dzięki temu mamy zachowaną samoorganizację zespołu projektowego oraz jednolity punkt komunikacji np. z klientem lub wyższą kadrą menadżerską.
3. Brak standaryzacji zawsze powoduje straty.
   • Kolejna bardzo szeroka obserwacja, która stosuje się w zasadzie do każdego elementu procesu wytwarzania oprogramowania. Rozpoczynając od standardów formatowania kodu źródłowego do standaryzacji mechanizmu spotkań.
   • Zgodziliśmy się co do tego, że powinniśmy stosować standardy i wypracowywać je kolektywnie jak najszybciej. Pomocny może być tutaj mechanizm kontraktu, który podpiszą wszyscy członkowie zespołu.
   • Ważne, aby pamiętać o tym, że mamy na myśli standard w kontekście definicji, która mówi akceptowanym przez cały zespół i najlepszym na dany moment sposobie wykonywania pewnej czynności. Nie mamy tutaj na myśli nienaruszalnej księgi zapisanej w kamieniu. 
   • Jest jeszcze jedna korzyść, którą może zaowocować solidna standaryzacja – po pewnym czasie, gdy przejdziemy w tryb automatycznego egzekwowania standardów, będziemy w stanie mierzyć i porównywać poszczególne elementy. A to znacząco ułatwi zarządzanie eksperymentami i weryfikację hipotez dotyczących usprawnień.
4. Pomysły oderwane od biznesowych realiów to marnotrastwo.
   • To kolejna bardzo ważna obserwacja. Jej esencją jest skierowanie swojej uwagi jako zespołu technicznego na wartość dostarczaną klientowi i odbiorcom końcowym.
   • Tutaj bardzo ważnym wnioskiem, jaki wypłynał z dyskusji, był temat odpowiedzialności za estymacje i jasnej komunikacji ze strony zespołów technicznych na temat terminów realizacji, a przede wszystkim realności pewnych założeń.
   • Następnie zauważyliśmy, że to na zespole technicznym ciąży odpowiedzialność na odpowiednim zakomunikowaniu priorytetów i ważności zadań o charakterze czysto technicznym. Oznacza to, że każdy refaktoring lub obsługa długu technicznego powinna być uargumentowana i „sprzedana” decydentom wyłącznie pod kątem biznesowym.
   • Możemy tego dokonać prezentując bilans zysków i strat wynikający na przykład z marnej jakości oprogramowania (z powodu skupienia się na początku na szybkości możemy zaobserwować wzrost liczby błędów), powolnego rozwoju jeśli chodzi o nową funkcjonalność (moglibyśmy przygotowywać nową funkcjonalność 2x szybciej jeśli…) lub niestabilnych wdrożeń. Warto podkreślić, że przy odpowiednim przekazie opartym na języku biznesowym i wysokim poziomie abstrakcji oraz przygotowaniu twardych danych na temat ROI (ang. return of investment, zwrot z inwestycji) w większości przypadków uda nam się uzyskać zgodę na takie zadanie. Albo przynajmniej otrzymamy jasną informację, dlaczego nie powinniśmy się na tym skupiać (np. przygotowywana funkcjonalność jest eksperymentem).
5. Brak wymiany wiedzy to również marnotrawstwo.
   • Bardzo ważny punkt, co do którego szybko doszliśmy do kolektywnego porozumienia i rozpoczęliśmy wymianę doświadczeń.
   • Rozwiązaniem, które było wymienione przez wszystkie osoby była jakaś forma cyklicznej wymiany wiedzy (w zależności od preferencji – ustrukturyzowana mniej lub bardziej np. cotygodniowe spotkanie w ramach całej firmy lub lean coffee) oraz programowanie/testowanie w parach lub odmiana tego mechanizmu przeznaczona dla większych grup tzw. mob programming/testing.
   • Najważniejszym wnioskiem było samo posiadanie takich mechanizmów wewnątrz zespołu lub organizacji.  
   • Innym równie ważnym aspektem, który został poruszony był proces wdrażania nowych pracowników, który jest szczególnym przypadkiem powyższego mechanizmu.
   • Tutaj również królowały propozycje uwzględniające pracę w parach lub grywalizację. Na szczególną uwagę zasługuje prosty, ale bardzo skuteczny mechanizm w formie personalizowanego immiennego powitania listy punktów do wykonania w pierwszy dzień pracy, zawierający różnorakie aktywności (np. rozmowa z przełożonymi i prezesem, uczestnictwo w porannych rytuałach zespołu, wizyty w dziale IT/księgowości itp.) zakończona punktem, który prosi o przygotowanie imiennego powitania dla następnej osoby.
6. Błędy w na wysokim poziomie (np. wymagań, dokumentacji) generują najwięcej strat.
   • Ten punkt po raz kolejny wygląda jak oczywista oczywistwość. To co oczywiste jednak nie jest to identyfikacja takich błędów na jak najwcześniejszym etapie.
   • Poza mechanizmami przeglądania kodu (code review) jedną z propozycji jaka padła podczas dyskusji było przygotowanie tzw. approach documents w których jesteśmy w stanie weryfikować decyzje dotyczące architektury i procesów biznesowych.
   • W powyższym przypadku zadaniem zespołu technicznego, w tym architektów i analityków biznesowych jest wspólna dyskusja nad proponowanym rozwiązaniem. Ważne, aby wspomniany dokument opisywał sposób podejścia do problemu i tzw. logikę biznesową bez konkretnych szczegółów implementacyjnych.
   • Ten punkt również doprowadził do bardzo ciekawej dyskusji na temat projektów typu fixed time/fixed scope i tego jak relatywnie mało czasu, w stosunku do samego wytwarzania i utrzymania, poświęca się na przegląd specyfikacji i dyskutowanie dokumentacji (szczególnie jeśli chodzi o projekty finansowane ze środków publicznych i dokumenty SIWZ). 

Co dalej?

Poza usprawnieniami wymienionymi wyżej, musimy wspomnieć o książkach i materiałach, które są fantastycznym rozszerzeniem i pozwolą Ci pogłębić wiedzę w tym temacie.

Jeśli zainteresował Cię temat lean management i chcesz zastosować te koncepcje w praktyce, bardzo polecamy książkę i wszelkie materiały przygotowane przez małżeństwo Poppendieck: 

To jedno z najlepszych opracowań dostępnych w tym temacie, bezpośrednio odnoszących się do IT.

Jeśli zainteresował Cię temat samego szczupłego zarządzania i historii firmy Toyota możemy polecić tą pozycję:

Nie wahaj się również zadawać pytań i dzielić się przemyśleniami dotyczącymi tematyki Lean w komentarzach – bardzo chętnie podyskutujemy.

Dodatkowo, jeśli masz pomysły na inne usprawnienia, albo wskazówki jak identyfikować i eliminować straty podziel się z nami – zostaw komentarz poniżej, nie pozwól aby inni cierpieli z powodu marnotrawstw!