Zarządzanie procesowe w IT - podstawy turkusowych organizacji

Jak to jest z interdyscyplinarnością?

Wszystko zaczęło się od idei. Zadawania sobie trudnych pytań i kwestionowania tego, co nie zawsze działa.
Konkretnie, skupiłem się na udawanej zwinności i pseudo-interdyscyplinarności zespołów, których doświadczyłem wiele razy. W praktyce wyglądało to zwykle tak:

• Myślimy, że jesteśmy w pełni zwinni, więc tworzymy interdyscyplinarne zespoły składające się z ludzi o różnych kompetencjach.
• Takie zespoły dostają konkretne zadania do wykonania i wtedy się zaczyna…
• Bo jednak okazuje się, że frontend developer jednak robi tylko frontend, analityk zbiera wymagania, a tester o dziwo głównie testuje.
• Gdy coś nie trybi w takim zespole to zapomnij o zwinnym wprowadzeniu zmian, bo na każdym stanowisku jest lider liniowy, który ma coś do powiedzenia. Do tego jest kierownik projektu, dyrektor czy tam jeszcze ktoś wyżej. Ci ludzie są zwykle oderwani od problemów konkretnego zespołu, jednak chcą mieć standaryzację i jasne procesy “pod sobą”.
• Sytuacja robi się patowa…

Czy odnajdujesz podobne doświadczenia w swojej pamięci? Dla mnie taka sytuacja jest nieakceptowalna. Nie lubię pracować wiedząc, że coś nie działa a ja nie mam na to wpływu.
Z drugiej strony mam świadomość, że zwalczenie opisanych problemów wymaga zmian na różnych szczeblach organizacji. Wypracowania nowej kultury i odmiennego podejścia. To nie stanie się z dnia na dzień, po jednym szkoleniu czy prezentacji.
Wiem też, że krzyczeć i protestować jest łatwo. W każdej rewolucji w końcu pojawia się to pytanie – jeśli obalimy status quo, to co w zamian?

Zadałem sobie to pytanie kilka lat temu. Wtedy zaświtała mi pewna nowatorska (jak mi się wydawało) idea. Z czasem dowiedziałem się, że mój ówczesny pomysł był mocno turkusowy i że turkus budzi skrajne emocje – od fascynacji do głębokiego sceptycyzmu. Gdzie jest prawda? Tego na razie Ci nie zdradzę.

Na potrzeby dalszej analizy przyjąłem założenie, że projekt nad którym pracuję nie wspiera interdyscyplinarności. Wymagania są złożone i lepiej żeby wąska grupa analityków przetwarzała je w pierwszej kolejności. Mamy też zespół backendowców znających dobrze logikę biznesową, więc nie ma potrzeby aby frontendowcy dotykali części serwerowej.
Wiem, że bywają też inne projekty. Możemy wtedy odpalić Scruma w modelu podręcznikowym i to też jest ok, chociaż jest to temat na osobny artykuł.

Kto jest klientem a kto dostawcą?

Proces poszukiwania optymalnego modelu współpracy zacząłem od fundamentów, na których zbudowałem kolejne piętra.
Kto weryfikuje jakość projektu IT? Już widzę las rąk wyrywających się do odpowiedzi: „testerzy” czy jak to modnie się określa – „QA”. Nie, źle. Jakość weryfikują klienci a precyzyjniej ich karty kredytowe. Jeżeli kupują konkretny produkt, to znaczy że jest on wysokiej jakości. Jak nie, to sorry. I nie ma znaczenia ile testów lokalnych przeprowadziliśmy, ile przygotowaliśmy test caseów, jakie mamy pokrycie w unit czy integration testach.

W scenariuszu, gdy klient nie chce płacić za naszą usługę czy produkt, oczywistym jest, że trzeba wyeliminować błędy i zwiększyć atrakcyjność oferty. Na razie brzmi to jak banał, ale zaraz wejdziemy dużo głębiej.
Zakładam więc, że jest coś nie tak z procesem skoro klienci narzekają i nie chcą współpracować. Co może być nie tak? Potencjalnych przyczyn może być cała masa, na przykład:

• Błędy w analizie potrzeb i wymagań
• Błędy w kodzie frontendu
• Błędy w kodzie backendu
• Nieprawidłowa architektura
• Niedokładne testy itd.

Sytuacja sprowadza się więc do wdrażania poprawek tak długo, aż klient w końcu nie potwierdzi poprawy jakości.
Poszedłem dalej tym tropem. Skoro klient zewnętrzny określa wymagania jakościowe względem produktu końcowego, to czy podobne mechanizmy nie zachodzą w przypadku klientów wewnętrznych?

Przeanalizuję na przykład na proces zbierania wymagań. Źródłem wiedzy jest klient - to oczywiste. Kto jest odbiorcą efektów pracy analityków? Często sposób definiowania, opisywania i akceptowania wymagań określa kierownik działu analityków, może nawet kierownik projektu bądź inny menedżer. Jeżeli tak jest, to proponuję zmienić podejście. Bezpośrednim odbiorcą efektów analizy biznesowej czy systemowej jest zespół programistyczny. Jeżeli analiza wymagań jest błędna bądź nieprecyzyjna, to właśnie odbiorca, nikt inny, ma prawo podać oczekiwania a potem spodziewać się odpowiedniej jakości.

Schemat przepływu między tymi dwoma działami przebiegałby na przykład tak:

Początkowo myślałem, że korzystnie będzie jeżeli każda z komórek stanie się osobną mini-firmą, mającą własny budżet, premie, klientów, normy jakościowe, procedury i wszystko co jest potrzebne aby spełniać oczekiwania tych właśnie klientów. Wkrótce przekonałem się, że nie byłoby to optymalne podejście.

Klasyczny turkus

Jakiś czas później trafiłem na genialną książkę prof. A.J.Blikle „Doktryna jakości (wydanie II turkusowe) – rzecz o turkusowej samoorganizacji” (do pobrania za darmo na stronie moznainaczej.com.pl). Autor formalnie przedstawił ten schemat w postaci:

Źródło: Andrzej Blikle, Doktryna jakości (wydanie II turkusowe) ― rzecz o turkusowej samoorganizacji.

Jak widać powyżej, to dostawca określa normy względem zamówień, dostarcza produkty i informacje o produkcie (jak z niego korzystać, dokumentacja techniczna itp.). Odbiorca oczywiście składa zamówienia, ocenia produkt i informacje o produkcie.

Proces w całej, niedużej firmie IT przedstawiałaby się na przykład tak:

Już słyszę dobiegający hejt ze strony entuzjastów Scruma - jak to, zespół developerski nie ma kontaktu z klientem?
Nawiążę więc do sedna zarządzania procesowego, czyli procesów samych w sobie. Profesor Blikle definiuje proces następująco:

“Procesem nazywamy zbiór czynności, które przetwarzają produkty o podobnym charakterze i odwołują się do wspólnego obszaru wiedzy.”

To co przedstawiłem na diagramie to nie zespoły ani stanowiska - to procesy, których celem jest dostarczenie produktu. Nic nie stoi na przeszkodzie, aby w procesie analizy wymagań obecny był doświadczony programista a w testach brał udział projektant UX.
Co jest niezmiernie istotne, proces ogranicza się wyłącznie do czynności niezbędnych do wytworzenia produktu. Jeżeli więc pewne działania np. w procesie Projektowania UI/UX nie służą temu celowi, to trzeba przypisać je do innego procesu lub wyeliminować całkowicie jako zbędne.
Drugim kluczowym czynnikiem jest obszar wiedzy - spójnych informacji na temat procesu. O tym napiszę nieco później.

Podejście to stanowi gigantyczną zmianę w porównaniu z tradycyjnym, hierarchicznym modelem skoncentrowanym na spełnieniu oczekiwań zarządu czy kierownika zespołu.

Powyższy diagram przygotowywałem zaczynając od klienta oraz jego oczekiwań, bo tak jak w każdej działalności, to spełnienie wymagań klientów generuje przychody dla firmy.
Proces ten należy czytać właśnie w ten sposób – od końca, idąc „pod prąd”, czyli:

• Klient końcowy dostarcza zamówień, a proces Zarządzania Projektami (PM) lub Obsługi Klienta pracuje z zamawiającym nad jakością tych zamówień. Nie da się przecież zrealizować projektu opisanego chaotycznie, w niespójny sposób.
• Proces Obsługi Klienta dostarcza zamówień do procesu Analizy Biznesowej. Proces ten ocenia początkowe oczekiwania, doprecyzowuje je i akceptuje dopiero wtedy, gdy spełniają określone normy. Na tej podstawie buduje zestaw wymagań.
• Dalej proces Analizy Biznesowej składa zamówienia do procesu Wytwarzanie. Razem z wymaganiami proces Wytwarzanie otrzymuje również składowe oryginalnego zamówienia - terminy, koszty, ograniczenia itp.
  Dalej analogicznie – programiści określają czego potrzebują aby jak najsprawniej zrealizować zamówienie. Może to być np. więcej scenariuszy użycia, określone diagramy itp. Przeciwnie - jeżeli czegoś nie potrzebują, to proces Analizy Biznesowej tego nie produkuje.
• W ramach procesu Wytwarzanie zachodzi kilka wewnętrznych procesów, które mogą wymieniać informacje, zamówienia i produkty na różne sposoby. Dla uproszczenia opisu traktuję to jako jeden proces.
• Kiedy produkt jest gotowy, to proces płynie „z prądem” – czyli od Wytwarzania do Klienta. Na każdym etapie odbywa się przekazanie wiedzy (co dokładnie zrobiliśmy) oraz ocena produktu.
  Gdy np. proces Development Frontend dostaje niewystarczające informacje o produkcie z procesu Development Backend (np. brak dokumentacji API) to oba procesy wspólnie szukają rozwiązań tego problemu, tak aby produkt i informacje o nim spełniły oczekiwania procesu Development Frontend.
• Na schemacie jest też obecny Dostawca Narzędzi - jest to proces odpowiedzialny za dopasowanie narzędzi adekwatnie do potrzeb poszczególnych procesów (a nie np. wybór tych obecnie najmodniejszych).
  W strukturze powinny być też procesy wspierające, jak np. Rekrutacja, Kadry, Administracja, Rozliczenia itp. Pominąłem je na schemacie, gdyż ich obecność nie wnosi wiele do głównego tematu.

Idea turkusu to nie tylko diagramy, strzałki i przepływy. Model procesowy narzuca wprost samoorganizację i odpowiedzialność od wewnątrz. A to jest logiczny krok w stronę wysokiej efektywności. Czy ma to sens? Zostań ze mną jeszcze chwilę a się przekonasz.

Struktura firmy i role kierowników

Pierwsze na co trafiłem, gdy szukałem informacji o strukturach turkusowych, to wpisy o organizacjach bez kierowników. Twierdzenie to wyjęte z kontekstu brzmi abstrakcyjnie i słusznie budzi niechęć wśród odbiorców. Wcześniejsza część dotycząca zarządzania procesowego powinna zmienić nieco perspektywę spojrzenia na samoorganizację.

W turkusie zespoły budowane są według procesów – tak aby zoptymalizować efekty. W proces Obsługi Klienta może być zaangażowany doświadczony programista, chociaż jego głównym procesem będzie programowanie. Czy w ramach dowolnego procesu potrzebny jest więc kierownik lub dyrektor, który wskazuje palcem co i kto ma robić danego dnia? (a potem z tego rozlicza).
Zdecydowanie nie. Celem procesów nie jest spełnienie oczekiwań kierownika. Celem każdego procesu jest spełnienie oczekiwań odbiorcy, co prowadzi do dostarczenia końcowemu klientowi tego, czego oczekuje. Rolę kierownika i nadzorcy przyjmuje więc odbiorca. Zespół zaangażowany w proces dostaje konkretne zlecenia i ma się z nich wywiązać. Proste.

Co więc z kierownikami? Jeżeli są w zespole ludzie, których jedynym zadaniem było do tej pory rozdzielanie i monitorowanie zadań, to obranie kierunku w stronę turkusu będzie dobrą weryfikacją przydatności takich osób. Czy zespół poradziłby sobie bez władzy z góry? Doświadczenie podpowiada mi, że tak.

Co zrobić z ludźmi, którzy są kierownikami ze względu na wysokie umiejętności i wiedzę? Ze specjalistami, bez których firma rozleci się jak domek z kart. Dla takich osób turkus przewiduje rolę Właściciela Procesu, czyli eksperta, który zarządza wiedzą na temat danego procesu.

Jest to transformacja z roli kierownika – kogoś kto mówi co robić do roli konsultanta – kogoś, kto mówi jak robić.
Wraz z nazwą zmienia się sposób komunikacji. Ze standardowego modelu „push” – polecenia od kierownika, sytuacja zmienia się na „pull” – pytania od zespołu do Właściciela Procesu.

Źródło: Andrzej Blikle, Doktryna jakości (wydanie II turkusowe) ― rzecz o turkusowej samoorganizacji.

Czy taka organizacja bez kierowników ma sens? Pójdźmy dalej.

Innowacyjność i ciągłe doskonalenie

Jeżeli w tradycyjnym modelu mówisz ludziom co mają zrobić, to to zrobią. Jeżeli zostawisz ich wyłącznie z celem (zamówienie) oraz wiedzą (Właściciel Procesu) to sami zaczną szukać rozwiązań. Uruchomi się coś, co mamy jako dzieci a co późniejsze lata szkoły, studiów i pracy korporacyjnej w nas zabijają – kreatywność.

Gdy stosowane metody nie zadziałają i produkt nie dotrze na czas do klienta, to wykonawcy procesu się o tym niechybnie dowiedzą. Pojawi się paląca potrzeba usprawnienia procesu i wyeliminowania opóźnień.
Zupełnie inaczej jest w tradycyjnym modelu, gdy w interdyscyplinarnym zespole przerzucamy się odpowiedzialnością (to testerzy opóźniają, a to backend nie dowiózł a może wymagania były do d…)

Motywacja zewnętrzna i wewnętrzna

Duża odpowiedzialność spoczywająca na wykonawcach procesu, w połączeniu z poczuciem niezależności, podnosi motywację i zaangażowanie. Każdy staje się po części szefem odpowiedzialnym za zadowolenie klienta. W tych warunkach zaczyna kiełkować najsilniejsza z możliwych motywacji, czyli ta w pełni wewnętrzna.

Jak z wszystkim co dopiero powstaje, motywację tę należy pielęgnować i uważać aby nie zniszczyć jej na starcie. A oto bardzo łatwo. Zarząd może poczuć pokusę podkręcenia wyników przez przyznanie premii dla najbardziej efektywnych procesów. Jeżeli backendowcy realizują wymagania na czas a frontendowcy nie, to należy im się premia. Brzmi logicznie.
Nie do końca. Jeżeli wynik procesu przelicza się wprost na złotówki to zaczyna się wyścig. Więcej, szybciej, niekoniecznie lepiej. Może odbiorca się nie zorientuje, że produkt zawiera błędy?

Podejście procesowe rekomenduje nagradzanie pracowników za wyniki całościowe. Albo wszyscy, albo nikt. Dzięki temu wiedza zaczyna płynąć nie tylko na linii dostawca – odbiorca, ale także bocznymi strumieniami. Backend wspiera frontend i odwrotnie bo wszyscy jadą na tym samym wózku.

Skupianie się na tym co ważne

W idealnej strukturze turkusowej panują następujące zasady:

1. Robisz to, co potrafisz.
2. Robisz to, co jest potrzebne.
3. Jesteś za to odpowiedzialny.
4. To, co robisz, możesz zmienić, ale z zachowaniem zasad: 1., 2. i 3.

Gdy zobaczyłem ten zestaw pierwszy raz to pomyślałem – abstrakcja. Każdy robi to co chce, bez ładu i składu – jak to może działać?
Ponownie, wiedza na temat procesowej organizacji sprawiła, że te cztery zdania nabrały sensu. W mojej osobistej interpretacji i rozwinięciu:

1. Każdy proces ma zdefiniowany cel. Jeżeli wiesz i potrafisz wesprzeć jego realizację, to zapraszamy. Jak nie, to poszukaj dla siebie innego procesu. Logiczne.
2. W procesie realizujemy zamówienia. Wszystko co nie dotyczy zamówień nie ma sensu. Jak chcesz robić coś innego, to patrz pkt 1.
3. Nie masz nad sobą kierownika, którzy karze i nagradza. Jak nie dowieziesz na czas, to odbiorca się o to upomni w mniej lub bardziej przyjemny sposób. To chyba wystarczająca motywacja?
4. Tak jak wcześniej – znajdź dla siebie odpowiednie miejsce.

Przepływ wiedzy

O tym już wspominałem, ale jest to niezwykle ważna zaleta turkusu. Wiedza zaczyna rozprzestrzeniać się wewnątrz procesów a potem rozlewa się na inne obszary. Dostawcy chcą zrozumieć odbiorców i odwrotnie. Gdy jeden proces się zatnie, to cały system stoi. Wtedy pomysły i wiedza spływają z różnych stron, aby tylko udrożnić przepływ.
Właściciele Procesów zbierają ją garściami, przetwarzają i wspólnie z zespołami tworzą nowe procedury, standardy i metody pracy.

Wizja firmy IT działającej w ten sposób brzmi nieco utopijnie. Ale może jest to osiągalne?

Na koniec

Przedstawiłem Ci moje przemyślenia, wnioski i wiedzę zdobytą z różnych źródeł. Chociaż wiem, że w Polsce funkcjonuje już kilka firm turkusowych, to jeszcze nie miałem okazji współpracować z żadną z nich. Potraktuj więc proszę te informacje jako inspirację a nie sprawdzony przepis na sukces. A jeżeli chcesz spróbować wdrożyć podejście procesowe w swojej firmie, to bardzo chętnie do Ciebie dołączę.