Tytuł „u nas to działa inaczej” nie pojawił się przypadkiem. To jeden z pierwszych komunikatów, które słyszałem jako Scrum Master, kiedy przychodziłem do nowego zespołu i pytałem, dlaczego coś działa w określony sposób. Na pewnym poziomie ogólności to prawda. Każda firma ma swoją specyfikę, historię, ograniczenia i kulturę. Ale przez 18 lat pracy w IT, w różnych rolach i na różnych stanowiskach nauczyłem się, że kiedy zaczynamy schodzić do poziomu szczegółów, bardzo wiele da się uporządkować i nazwać.
Ten tekst to próba zaszczepienia spojrzenia na organizację z różnych perspektyw – z precyzją, którą wyniosłem z pracy z frameworkami zarządzania, ale bez żargonu dla samego żargonu. Chcę nim rozbroić naturalne konflikty między działaniami wewnątrz firmy i pokazać, że różnice w podejściu najczęściej nie wynikają ze złej woli, ale z odmiennych celów operacyjnych.
Zamiast szukać winnych opóźnień, biurokracji albo chaosu, wolę patrzeć na firmę jak na organizm, który jednocześnie musi dbać o stabilność i o innowację.
Projekt i proces to nie to samo
Projekt to unikalna, jednorazowa podróż w nieznane. Jego celem jest zmiana status quo. Kluczowe słowo to unikalność. Tworzymy coś, co wcześniej w tej formie nie istniało, co automatycznie wprowadza niepewność co do efektu i drogi do niego. Każdy projekt ma jasno określony początek i koniec, przypisane role, odpowiedzialności oraz budżet.
Dobrym przykładem jest stworzenie i wdrożenie nowej aplikacji mobilnej dla klientów banku. Taki wysiłek obejmuje fazę projektowania, testów, publikacji i późniejszego utrzymania. Są konkretne daty, konkretny zespół, określony zakres – i właśnie to wszystko składa się na projekt.
Proces to z kolei fabryka, która kocha przewidywalność. Ma opisane wejścia, wyjścia i standardy. W przeciwieństwie do projektu jest działaniem ciągłym i powtarzalnym. Sukcesem nie jest odkrycie czegoś nowego, ale uzyskanie identycznego wyniku za każdym razem, niezależnie od tego, kto wykonuje zadanie. W procesie skupiamy się na efektywności, jak te same kroki wykonać szybciej, taniej i z mniejszą liczbą błędów.
Przykład? Codzienne księgowanie faktur musi odbywać się według ścisłego schematu, żeby unikać błędów prawnych czy podatkowych. Albo helpdesk: każda usterka powinna zostać rozwiązana zgodnie z określonym standardem czasowym i technicznym. Właśnie po to, by klient wiedział, czego się spodziewać.
W tym kontekście nuda jest dla procesu komplementem. Jeśli jest nudno, jest stabilnie. A jeśli jest stabilnie, proces prawdopodobnie działa.
Na co dzień jednak najczęściej działamy hybrydowo. Gdy proszę ludzi, żeby wypisali trzy rzeczy, które robią w pracy, a potem zadali sobie pytanie czy jutro zrobią je dokładnie tak samo, czy może będą nastawieni na inny rezultat najczęściej odpowiedź brzmi: trochę tak, a trochę tak. Jeśli jutro znów wypełniamy ten sam raport według znanego schematu, działamy procesowo. Jeśli planujemy spotkanie z nowym klientem, żeby omówić zagadnienia, których jeszcze nie znamy. Nawet jeśli samo spotkanie jest rutyną, rezultat jest nowy. Czy to już projekt? Niekoniecznie w sensie zarządczym. Ale myślenie o tym, czego jeszcze nie wiemy, jest już myśleniem projektowym.
W projekcie zarządzamy nieznanym, w procesie – wydajnością
W projekcie planowanie nie polega na prorokowaniu przyszłości, tylko na świadomym zarządzaniu nieznanym. Dlatego uznane frameworki projektowe mają kilkadziesiąt procesów zarządczych: od zarządzania ryzykiem, przez budżet, interesariuszy i wymagania, aż po zmianę. Wszystko po to, by zawężać obszar niewiadomych.
Ponieważ poruszamy się w obszarze nowości, zmiana jest naturalnym elementem pracy, nie jest dowodem na zły plan. W podejściu tradycyjnym, kaskadowym, kolejne etapy służą potwierdzaniu ustaleń. W praktyce jednak, niezależnie od metodyki, projekt wymaga ciągłej adaptacji do nowych informacji: z rynku, z technologii, z testów, z rozmów wewnętrznych.
Wyobraźmy sobie budowę prototypu nowego samochodu elektrycznego. Założono, że wybrany akumulator będzie optymalny, ale testy na torze pokazują, że przegrzewa się w słońcu. W trybie projektowym nie udajemy, że problemu nie ma. Wracamy do deski kreślarskiej i szukamy lepszego rozwiązania. To właśnie adaptacja. Najlepsze plany projektowe to nie te, które udają nieomylność, ale te, które zakładają mechanizmy aktualizacji.
W procesie jest odwrotnie. Celem nie jest eksploracja, ale eliminacja odchyleń i dążenie do dojrzałości operacyjnej. Jeśli uda się skrócić pojedynczą operację o dwie sekundy, to przy milionie powtórzeń oszczędzamy setki godzin pracy. W rozlewni napojów butelka musi być napełniona z dużą dokładnością – za mało i klient jest niezadowolony, za dużo i firma traci produkt. Nie ma tu miejsca na kreatywną interpretację.
Dlaczego tak często się nie rozumiemy?
W jednej organizacji działają jednocześnie ludzie odpowiedzialni za zmianę i ludzie odpowiedzialni za stabilność. Jedni są rozliczani z rezultatów i nowych rozwiązań, drudzy ze stabilności i ciągłości działania. Konflikty wynikają nie z charakterów, ale ze zderzenia priorytetów: innowacja kontra bezpieczeństwo. I co najważniejsze: obie strony mają rację. Tyle że każda w kontekście własnego zadania.
Przyjrzyjmy się kilku typowym zdaniom:
„Nie możemy tego wdrożyć w piątek. A jak coś się zepsuje w weekend?” Klasyczny język procesu. Piątek jest najgorszym momentem na ryzyko – każda zmiana może zakłócić maszynę operacyjną, która ma działać bez niespodzianek.
„Po co nam ta pięćdziesięciostronicowa dokumentacja? Wymagania i tak się zmieniają.” Język projektu. Projektant wie, że zmiana jest nieunikniona, a nadmierna dokumentacja tworzona zbyt wcześnie bywa bardziej obciążeniem niż pomocą.
„Zgłosiliście błąd, a macie wypełniony formularz ZB17/C z podpisami?” Znów proces i nie musi to być biurokracja dla samej biurokracji. Formularz jest często po prostu bezpiecznikiem: dzięki niemu zgłoszenie zawiera komplet danych i nie wraca do nadawcy z pytaniem „ale jak to odtworzyć?” albo „co dokładnie nie działa?”.
„Zróbmy MVP i sprawdźmy najpierw, czy klienci w ogóle tego chcą.” Czysty język projektu. Sprawdzenie hipotezy możliwie najmniejszym kosztem.
Dobrą ilustracją tego ostatniego jest historia, którą usłyszałem podczas szkoleń SAFe prowadzonych dla linii lotniczej. Pojawił się pomysł wprowadzenia cold brew coffee na pokładach. Na pierwszy rzut oka świetna idea, ale koszty atestowanych maszyn, logistyki i magazynowania okazały się ogromne. Zamiast inwestować, zespół przeprowadził prosty eksperyment: w gazetce pokładowej pojawiła się informacja o dostępności cold brew, a jeśli pasażer zgłaszał zamówienie, załoga notowała zainteresowanie. Po chwili informowała pasażera, że napój się skończył i niestety już nie jest dostępny. Wynik? Popyt był zbyt niski, by uzasadniał realne koszty. Klasyczny fake door test – eksperyment bez inwestycji.
Największym błędem jest założenie, że ktoś przychodzi „marudzić” ze złej woli albo po to, żeby zablokować naszą pracę. Za innym podejściem najczęściej stoją cele, których po prostu nie widzimy. Zrozumienie, że druga strona nie jest złośliwa, tylko dba o inny aspekt zdrowia firmy, jest kluczem do współpracy.
Ryzyko działa inaczej po obu stronach
W projekcie ryzyko ma często charakter „wszystko albo nic”. Co więcej, koszt naprawy błędu rośnie wykładniczo wraz z czasem. Błąd wykryty w fazie koncepcji może kosztować symbolicznego dolara. Ten sam problem wykryty po wdrożeniu na produkcję, stukrotnie więcej. Za naprawą stoją zawsze ludzie, analiza, czas, komunikacja.
W procesie największym zagrożeniem jest efekt skali. Mały, powtarzalny błąd systemowy może wygenerować gigantyczne szkody, jeśli maszyna ucina każdy element o 1 mm za dużo, a produkujemy milion części, nie mówimy o drobnej odchyłce. Wadliwy proces rzadko powoduje natychmiastowy upadek firmy. Częściej wykrwawia ją powoli przez błędy wpisane w procedury i technologię.
Proces sam z siebie nie staje się lepszy
Jeśli nalejemy do szklanki herbaty i zaczniemy mieszać łyżeczką, od samego mieszania nie będzie słodsza. Trzeba coś dosypać. Do ulepszenia procesu potrzebny jest zewnętrzny impuls, najczęściej projekt. Jeśli obecny sposób pracy generuje błędy albo jest zbyt drogi, nie naprawimy go samym powtarzaniem tych samych czynności.
Przykład: dział reklamacji zauważa, że czas odpowiedzi wydłużył się do siedmiu dni. Powstaje projekt optymalizacji customer service. Zespół analizuje wąskie gardła, być może kupuje nowe oprogramowanie, być może tworzy nowy standard obsługi. Po wdrożeniu firma otrzymuje nowy, szybszy proces operacyjny. Procesy najczęściej są tworzone przez projekty, a nie odwrotnie.
Pułapką, którą często obserwuję, jest tzw. wieczny projekt, czyli sytuacja, w której zmiana nigdy nie została naprawdę domknięta i ustabilizowana. Ludzie funkcjonują w ciągłym trybie awaryjnym, jakby cały czas byli „między starym a nowym”. Dojrzały projekt powinien w pewnym momencie zakończyć się słowami: zrobione, to jest od dziś wasza nowa rutyna.
Ten moment przejścia – handover – opiera się na trzech filarach: weryfikacji i walidacji (czy rozwiązanie działa i spełnia oczekiwania), edukacji użytkowników (zarówno wewnętrznych, jak i zewnętrznych) oraz jasnym określeniu odpowiedzialności (kto przejmuje utrzymanie po zamknięciu projektu). Bez tych trzech elementów nawet genialne rozwiązanie może zostać odrzucone przez zespół operacyjny, który po prostu nie czuje się z nim bezpiecznie.
Wyobraźmy sobie dział IT kończący projekt nowego CRM-a. Żeby przekazanie się udało, nie wystarczy wdrożenie i wydanie aplikacji. Potrzebna jest walidacja, szkolenia i wskazanie osoby lub zespołu reagującego na awarie po zamknięciu projektu. Wiele innowacji przepada nie dlatego, że były złe, ale dlatego, że zostały wyrzucone przez płot – bez przygotowania codziennej obsługi i bez właściciela po stronie operacji. Nowoczesne podejścia, choćby kultura DevOps, próbują właśnie tę barierę zacierać – sprawiać, że twórcy i użytkownicy grają od początku do końca w jednej drużynie.
Run and change, czyli dwie nogi organizacji
Zdrowa organizacja potrafi jednocześnie dbać o dzisiejsze zyski i budować jutrzejszą przewagę. Dzisiejsze zyski to stabilność, przewidywalność i skuteczność operacyjna. Jutrzejsza przewaga bierze się z eksperymentowania, testowania i wdrażania zmian. Dlatego myślę o organizacji w dwóch obszarach:
🚀 Run – serce firmy, gdzie liczy się wydajność, standard, przewidywalność i doskonałość operacyjna.
🚀 Change – laboratorium firmy, gdzie przez projekty eksperymentujemy z nowościami, które być może za rok albo dwa staną się nowym standardem zarabiania pieniędzy.
Kodak jest tu często przywoływanym przykładem – i słusznie, choć historia jest bardziej złożona niż mit o firmie, która zwyczajnie zignorowała cyfrową rewolucję. Kodak w 1975 roku sam wynalazł cyfrowy aparat fotograficzny. Problem polegał na czym innym: przez długi czas cyfrowa fotografia rzeczywiście była rynkiem niszowym i ta ocena była trafna. Błąd polegał na zbyt późnym przestawieniu się, gdy rynek zmienił się szybciej niż zakładano. Zbyt duża przewaga obszaru run nad change. Zbyt dużo troski o to, co działa dziś, za mało odwagi, by zainwestować w to, co może działać jutro.
Z drugiej strony są startupy, które często żyją niemal wyłącznie change. Tam liczy się szybkość, walka o rynek, eksperyment. Na stabilność przychodzi czas później. Ale i to podejście ma swoje ryzyka: wypala ludzi, pieniądze i organizacje.
Dlatego jedno bez drugiego po prostu nie działa.
Co się dzieje, gdy źle dobieramy narzędzia?
Pojawia się chaos albo zamordowana innowacja. Można wbijać gwóźdź mikroskopem, tylko że mikroskop nie do tego służy. Tak samo jest z metodami i frameworkami. Jeśli źle zdiagnozujemy sytuację, zaczniemy stosować niewłaściwe narzędzia do niewłaściwych problemów.
Żeby to uporządkować, proponuję prostą matrycę opartą na dwóch osiach: powtarzalność i zmienność. Ta matryca pomaga zatrzymać się i odpowiedzieć: z czym pracujemy, jaki język powinniśmy przyjąć i jakich napięć możemy się spodziewać w rozmowie z interesariuszami.
| Niska zmienność | Wysoka zmienność | |
| Wysoka powtarzalność | Proces (lean, standaryzacja) | Chaos – wymaga natychmiastowej korekty |
| Niska powtarzalność | Projekt tradycyjny (kaskada) | Projekt zwinny (agile, eksperymenty) |
Wysoka powtarzalność, niska zmienność – proces. To przestrzeń standardu i optymalizacji. Tu najlepiej sprawdzają się podejścia procesowe, takie jak Lean, skupiające się na ograniczaniu strat, czekania, nadprodukcji i niepotrzebnych ruchów.
Niska powtarzalność, niska zmienność – projekt tradycyjny. Wiemy, co chcemy zrobić, i w dużej mierze wiemy, jak to zrobić. Plan jest liniowy, a zmienność celu pozostaje stosunkowo niewielka.
Niska powtarzalność, wysoka zmienność – projekt innowacyjny. To świat eksperymentów, iteracji i zwinności. Każda kolejna iteracja może przynosić nową wiedzę i wpływać zarówno na drogę, jak i na sam rezultat. Nadal skupiamy się na celu, ale odkrywamy go krok po kroku.
Wysoka powtarzalność, wysoka zmienność – chaos. To najgorsza możliwa kombinacja. Ani narzędzia procesowe, ani projektowe nie działają tu dobrze – brakuje stabilnego punktu zaczepienia. Jeśli proces, który powinien dawać przewidywalny efekt, zaczyna produkować ciągle inne wyniki, mamy sytuację wymagającą natychmiastowej korekty.
To, czy coś jest projektem czy procesem, zależy też od środowiska i skali. Dla jednych zamówienie pizzy przez telefon może być projektem życia, robią to po raz pierwszy i może ostatni. Dla innych to rutynowy proces prowadzący zawsze do tego samego rezultatu. Dlatego zanim sięgniemy po narzędzie, warto zadać sobie pytanie: gdzie właściwie jesteśmy?
Co z tego wynika?
Projekty i procesy nie są wrogami. To dwie nogi, na których stoi większość firm. Jeśli jedna jest słabsza, organizacja zaczyna utykać.
Zanim zabierzemy się za działanie, warto zadać sobie pytanie: czy mamy do czynienia z projektem, czy z procesem? A nawet jeśli ktoś coś nazywa projektem czy rzeczywiście nim jest? Zła diagnoza sprawia, że używamy młotka do wkręcania śruby. Da się, ale będzie bolało.
Potrzebujemy balansu. Zbyt dużo run i kończymy jak Kodak. Zbyt dużo change i zachowujemy się jak startup, który nieustannie biegnie, ale nie zawsze utrzymuje się na nogach. Organizacja, która chce sprawnie biec, musi równocześnie umieć zawiązać sobie buty. Brzmi groteskowo, ale dokładnie tak wygląda codzienność wielu firm.
Najważniejsze, żeby zacząć rozpoznawać wokół siebie, z czym naprawdę mamy do czynienia. Czy to, co robimy, wymaga dziś przewidywalności i standaryzacji? Czy raczej eksploracji, eksperymentu i świadomego zarządzania nieznanym? Czy trzeba tu usprawniać proces, czy uruchamiać projekt? A może najpierw po prostu nazwać problem właściwym językiem?
To jest dla mnie punkt wyjścia do dalszej rozmowy. Bo ten temat to dopiero początek – w kolejnych odsłonach warto wejść głębiej w porównanie podejścia tradycyjnego i zwinnego, w ich fundamentalne różnice, w to, kiedy pomagają, a kiedy zaczynają przeszkadzać.
A od tego wszystko się zaczyna: od zrozumienia, że „u nas to działa inaczej” wcale nie musi oznaczać chaosu. Czasem oznacza po prostu, że patrzymy na ten sam problem z dwóch różnych, ale równie potrzebnych perspektyw.
O autorze
Maciek jest związany z IT w różny sposób od blisko 20 lat. Zbierał doświadczenie jako grafik, full-stack developer, tester, Scrum Master, Team Lead, Release i Test Manager oraz trener SAFe. Od lipca 2025 r. działa w fireup.pro. Zawodowo lubi porządkować złożoność. Prywatnie jest pasjonatem rytmu i precyzji.
