Odcinek 88. Flow Engineering
Czujesz, że wszystko trwa u Was za długo, choć wszyscy dają z siebie wszystko? To bolączka wielu organizacji, szczególnie tych, które rosną, czy to pod kątem liczby swoich klientów, czy też pracowników.
A co powiesz na skrócenie czasu onboardingu klienta z 4 tygodni do kilku dni? Dziś niby mamy AI i automatyzacje, a dla wielu osób i organizacji taka sytuacja nadal pozostaje w sferze marzeń. A może warto spojrzeć na proces i zastanowić się, gdzie przyłożyć klucz, by usprawnić ten proces?
Posłuchaj historii Steve’a Pereiry – współautora książki i koncepcji „Flow Engineering”, który pełniąc rolę CTO osiągnął takie usprawnienie.
W ostatnich latach obserwuję, że organizacje mają dostęp do niezliczonych narzędzi i metodyk: Kanban, Value Stream Mapping, Team Topologies, Impact Mapping… Lista jest długa. Jednak wiele z nich, mimo świetnych podstaw teoretycznych, nie przechodzi od rezultatów warsztatu do rzeczywistych zmian w systemie pracy.
Historia, która zmieniła wszystko
Steve zaczął jako CTO w firmie z egzystencjalnym problemem: szybko włączać nowych klientów. Niestety ich proces onboardingu zajmował aż 6 tygodni. W tempie, w którym pracowali, była to prosta droga do bankructwa…
Zamiast panikować, Steve robił coś prostego: zmapował, co się dzieje.
Realia? 6 tygodni. Ambicje? 4 dni!
Tylko czy to w ogóle możliwe? I jak?
Flow Engineering: Czy to coś dla inżynierów?
Steve wyjaśnił w rozmowie, dlaczego wybrał słowo „engineering”:
I tą trafną obserwacją (oraz nazwą) Steve stworzył coś, co inżynierów nie odstrasza. Na przestrzeni lat obserwuję, że inżynierowie i tech leadzi czują frustację – nie z powodu technologii, ale z powodu szumu, chaosu i braku jasności w przepływie pracy.
Pięć składników Flow Engineering
Flow Engineering to kombinacja pięciu elementów, każdy z nich istotny:
1. Outcome Mapping
Zaczynamy od końca, a nie od środka. Co jest rzeczywiście ważne dla organizacji? Dla klientów? Dla zespołów? Ustalamy to zanim w ogóle dotykamy mapy. To łączy Flow Engineering z biznesem, unika przepalanie czasu na optymalizacjęę rzeczy, które nikogo nie interesują.
2. Value Stream Mapa – ale inna
Steve nie neguje VSM (czyli value stream mappingu), ale tradycyjne VSM pochodzi z produkcji, jest pełne fabrycznych ikon i ciężarówek. W świecie cyfrowym wygląda to dziwnie i niezrozumiale. Flow Engineering upraszcza to do czystej mapy przepływu: kto robi co, ile czasu to zajmuje, gdzie czekamy.
Ale ważne: nie robimy 2000-elementowych map. Steve wspominał o firmach, które spędzały dwa tygodnie na mapowaniu – wszyscy byli wyczerpani, mapa była zbyt złożona, nikt na nią patrzył, nie mówiąc już o energii do zmiany.
3. Data-Driven Analysis
To jest moment, w którym mapa ożywa. Dodajemy liczby:
- Ile czasu trwa każdy etap pracy?
- Ile czasu spędzamy czekając pomiędzy etapami?
- Gdzie spędzamy go najwięcej tworząc wartość, a gdzie nie?
Dane sprawiają, że przeszłyśmy z „czujemy, że coś jest nie tak” na „wiemy dokładnie, gdzie problem”.
4. Wybierzcie jedno miejsce!
W każdej mapie przepływu, którą Steve widział, zawsze pojawia się jedno miejsce, które się wyróżnia. To może być:
- wąskie gardło w procesie review
- czekanie na zatwierdzenie
- brakujące informacje, które powodują, że zespół marnuje czas szukając ich lub robiąc coś innego
- skomplikowana integracja z innymi systemami
To miejsce – ten hotspot – zwykle jest odpowiedzialne za więcej opóźnień niż wszystkie inne elementy razem wzięte.
Zamiast próbować naprawiać wszystko, skupiamy się na tym jednym miejscu. Jest to moment, w którym problem zmienia się w okazję.
5. Effective Action
I teraz – kluczowe słowo – działamy.
To jest różnica między Flow Engineering a setkami retro, podczas których znalezieliśmy 50 rzeczy do poprawienia
Flow Engineering zakłada, że:
- mapujemy i analizujemy (sesje workshop ~90 minut),
- wybieramy 3-5 działań na usprawnienie w jednym kluczowym miejscu,
- wdrażamy przez następne 3 miesiące,
- obserwujemy wyniki przez 3 miesiące,
- po 6 miesiącach robimy to znowu (bo system pracy się zmienił, pojawił się nowy hotspot).
To cykl, nie jednorazowa aktywność.
Konkretne korzyści, czyli co z tego wynika?
Steve miał na to odpowiedź opartą na doświadczeniu:
Mierzalne: 20% redukcja lead time zaraz po mapowaniu
W każdym przypadku, w którym Steve brał udział, już po sesji mapowania pojawia się lista rzeczy, które można przestać robić lub zrobić inaczej. To nie wymagało rewolucji – a małych zmiany organizacyjnych. I zaraz to się widzi w metrykach.
Emocjonalne: poczucie kontroli i wzmocnienia
Zespoły, które pracowały w chaosie, nagle widzą jasny obraz. Wiedzą, gdzie są problemy. Wiedzą, na czym się skupiać. To zmienia morale. Zamiast patrzenia na rosnące backlog i skargi, działają.
Strategiczne: działanie wokół jednego celu
Gdy weź ekipę (czy to DevOps, czy Product, czy QA) i wspólnie popatrzćie na mapę. Gdy się na nią patrzy przychodzi czas na:
„Aha, czekam na was, bo…”.
„Nie wiedziałem, że to jest takie bolesne dla was”.
Te konwersacje zmieniają dynamikę zespołu.
Skalowalne: System, który ewoluuje
Mapy nie znikają po sesji. Steve poleca budować je w Miro lub Mural jako żywe dokumenty, które rosną razem ze zmianami w systemie pracy.
Za każdym razem, gdy robisz flow engineering (co 6 miesięcy), jest łatwiej. Masz już mapy, robisz refinement zamiast zaczynać od zera. Przychodzą Ci do głowy pytania bardziej zaawansowane. Proces staje się praktyką.
Czy to jest dla mnie?
Steve wyjaśnił, że pierwotnie Flow Engineering był jego rozwiązaniem jego problemów.
Ale rzeczywistość jest szersza. Komu może przydać się Flow Engineering?
- Liderzy techniczni i Engineering Managerowie – musicie zrobić więcej z tą samą liczbą osób? To dla was.
- Product Ownerzy – chcecie zrozumieć, dlaczego dostarczanie zajmuje tyle czasu? To dla was.
- Inżynierowie – czujecie się zmęczeni chaosem i zmianami priorytetów? To dla was.
- Procesowcy, osoby z HR, sprzedaży, marketingu – wszyscy, którzy mają jakiś proces, w którym czekają, tracą czas, brakuje im jasności – to dla was.
Jak zacząć? Praktyczne kroki
Steve oferuje kilka sposobów na wejście w Flow Engineering, od najmniej zagrażającego do pełnego wdrażania:
🎮 Krok 1: Gra edukacyjna (~30 minut)
Najprostszy sposób. Gracie z fikcyjnym przepływem pracy (np. product development, incident response, onboarding). Losowo generujecie dane. Obserwujecie, co się wyróżnia. Dowiadujecie się, co to znaczy „hotspot”. Unikacie całej politycznej zawiłości prawdziwego zespołu –> najpierw rozumiecie koncepcję.
Uwaga: Steve oferuje darmowe 30-minutowe sesje gry dla firm, które chcą spróbować.
📋 Krok 2: Mapowanie „naprawdę”
Gdy zrozumiecie koncepcję, robicie to naprawdę. Zapraszacie zespół, mapujecie rzeczywisty przepływ pracy (outcome mapping, value stream mapping, dojecie tak dobre dane jakie macie).
Struktura: 5 warsztatów po ~90 minut. Można je rozciągnąć na cały tydzień, dwa dni, czy nawet jeden dzień, w zależności od czasu zespołu.
🛠️ Krok 3: Wdrażanie i obserwacja
Flow roadmap –> co będziemy zmieniać przez następne 3 miesiące. Następnie obserwujemy przez 3 miesiące. Po 6 miesiącach robimy to znowu.

Gdzie szukać więcej?
Jeśli interesuje Cię Flow Engineering, Steve wskazał kilka miejsc:
- 📖 Książka: „Flow Engineering” (Steve Pereira + Andrew Davis)
- 🎮 Szablony: Miro / Mural Marketplace
- 🎥 Materiały wideo: YouTube, konferencje (DevOps Enterprise Summit, Atlassian Community Events)
- 📰 Blog/Newsletter: visibleconsulting.substack.com (artykuły dłuższe)
- 💬 LinkedIn: Steve Pereira publikuje regularnie
