Lean to filozofia zarządzania, w której priorytetem jest dostarczanie wartości dla klienta przy równoczesnej eliminacji marnotrawstwa (japońskie muda) na każdym etapie procesu. Projekt lean przenosi te założenia na grunt zarządzania projektami: zamiast optymalizować pojedyncze zadania, patrzysz na cały strumień pracy od pomysłu do wdrożenia i usuwasz z niego to, co nie przekłada się na korzyść dla odbiorcy.

Podejście wywodzi się z Systemu Produkcyjnego Toyoty (TPS), opracowanego po II wojnie światowej przez Taiichiego Ohno i Eijiego Toyodę. Firma nie miała środków na utrzymywanie dużych zapasów, dlatego zbudowała system produkcji sterowanej rzeczywistym zapotrzebowaniem. Więcej o źródłach tego podejścia znajdziesz na stronach System Produkcyjny Toyoty – Toyota Polska oraz Lean Thinking and Practice – Lean Enterprise Institute.

Pięć zasad lean według Womacka i Jonesa

Klasyczne ujęcie lean opisali James Womack i Daniel Jones. Sprowadza się do pięciu kroków, które tworzą cykl:

• zdefiniuj wartość oczami klienta, a nie przez pryzmat własnych procesów;
• zmapuj strumień wartości (Value Stream Mapping), żeby zobaczyć, gdzie powstają opóźnienia;
• zbuduj ciągły przepływ pracy bez przestojów między etapami;
• wdróż system ssący (pull), w którym pracę uruchamia realne zapotrzebowanie;
• dąż do perfekcji przez ciągłe doskonalenie (Kaizen).

Dwa filary Systemu Produkcyjnego Toyoty

TPS opiera się na dwóch mechanizmach, które warto rozumieć osobno. Jidoka to automatyzacja z ludzką twarzą – proces zatrzymuje się natychmiast po wykryciu błędu, żeby wada nie przeszła dalej. Just-In-Time oznacza wytwarzanie wyłącznie tego, co jest potrzebne, dokładnie wtedy, kiedy jest potrzebne. W projekcie IT ten drugi filar odpowiada limitowaniu pracy w toku i unikaniu budowania funkcji na zapas.

Lean Software Development i marnotrawstwo w IT

Zasady lean zaadaptowali do wytwarzania oprogramowania Mary i Tom Poppendieck. Nazwali to podejście Lean Software Development i wskazali siedem rodzajów marnotrawstwa charakterystycznych dla projektów informatycznych:

• częściowo ukończona praca, która czeka i traci na wartości;
• nadmiarowe funkcjonalności, których nikt nie używa;
• zbędna dokumentacja tworzona na wszelki wypadek;
• przełączanie kontekstu między zadaniami;
• oczekiwanie na decyzje, testy lub środowiska;
• defekty i związane z nimi poprawki;
• nadmierna biurokracja spowalniająca przepływ.

Opis metody wraz z kontekstem znajdziesz w opracowaniu Lean Software Development – mfiles.pl.

Lean a Agile – czym się różnią

Te dwie koncepcje bywają mylone, choć działają na różnych poziomach. Lean to systemowa filozofia optymalizacji całego strumienia wartości i eliminacji strat, natomiast Agile to zbiór metod skupionych na iteracyjnym, przyrostowym dostarczaniu oprogramowania. W praktyce stosuje się je łącznie: lean nadaje kierunek całej organizacji pracy, a Agile porządkuje sposób dostarczania kolejnych przyrostów. Zestawienie metodyk opisuje Czym jest metodyka Lean? – Atlassian.

Narzędzia lean w projektach IT

Filozofia bez konkretnych narzędzi zostaje na poziomie deklaracji. W Lean IT najczęściej sięgasz po:

• tablice Kanban z limitem WIP (Work In Progress), które ograniczają liczbę zadań w toku;
• mapowanie strumienia wartości (VSM) dla procesów cyfrowych, żeby zlokalizować oczekiwanie i zbędne kroki;
• automatyzację powtarzalnych zadań, co skraca lead time i podnosi jakość usług.

Badania empiryczne nad projektami informatycznymi wskazują, że najszerzej stosowane i najskuteczniejsze są dwa z tych narzędzi. Kanban ogranicza częściowo ukończoną pracę i liczbę defektów, a VSM eliminuje oczekiwanie i nadmiarowe procesy. Jeśli dopiero zaczynasz wdrażać lean w zespole, od tych dwóch najłatwiej ruszyć.

FAQ

Czy lean nadaje się tylko do produkcji?

Nie. Choć lean powstał na hali Toyoty, jego zasady stosuje się w wytwarzaniu oprogramowania, zarządzaniu usługami IT i procesach administracyjnych. Wszędzie tam, gdzie istnieje strumień pracy i ryzyko marnotrawstwa, mapowanie wartości i system ssący mają sens.

Od czego zacząć wdrażanie lean w projekcie IT?

Zacznij od zmapowania strumienia wartości, żeby zobaczyć, gdzie praca czeka najdłużej. Następnie wprowadź tablicę Kanban z limitem WIP dla najbardziej obciążonego etapu. Te dwa kroki dają szybki obraz strat bez konieczności przebudowy całej organizacji.

Czym różni się muda od pozostałych rodzajów strat?

Muda to marnotrawstwo, czyli działania niedodające wartości, na przykład oczekiwanie czy nadprodukcja funkcji. W klasycznym ujęciu Toyoty występują też mura (nierównomierność obciążenia) i muri (przeciążenie zasobów), ale to muda jest najczęściej adresowana w projektach IT.