Wzorce Weinberga i jak się mają do jakości?

W tym blogu zostanie przedstawiony jeden ze sposobów klasyfikowania organizacji. Analizowane jest to jak organizacja podchodzi do struktur, definicji i walki ze zmianą.
Na sam koniec artykułu przedstawione jest pare rad do tego jako podchodzić co tematu ewolucji organizacji pod względem “dorosłości”.

Ważne, by zaznaczyć, że to tylko jeden ze sposobów klasyfikowania organizacji i jest to pewien uproszczony model. Jak mawiał George Box - statystyk:

Wszystkie modele są błędne, ale niektóre są użyteczne.

Tak jest również w tym przypadku – mam nadzieję, że ta klasyfikacja oraz poniższe action pointy okażą się komuś przydatne.

Głównym tematem tego wpisu są organizacje i sposoby ich tworzenia, ale musimy zacząć od wyjaśnienia, czym jest jakość oraz zbudować w głowie pewne powiązanie między pojęciem dobrej jakości a konkretnym wzorcem.

Miłej lektury!

Czym jest dobra jakość?

Temat jakości oprogramowania przewijał się przez całą karierę Geralda Weinberga, konsultanta IT i nawet poświęcił temu zagadnieniu serie siedmu książek.
Warto więc zacząć od podstawowego pytania:

Czym jest dobra jakość?

Większość osób odpowiada na to pytanie bez wahania – „czy to nie oczywiste?” – po czym przedstawia własną definicję:

• Programista:
  „Aplikacja nie wywala się pod obciążeniem, deployment przechodzi bez błędów.”
  Przykład: System bankowy obsługuje 10 tys. przelewów na minutę bez opóźnień.

• Menedżer IT:
  „Zespół szybko reaguje na bugi, a release’y są przewidywalne.”
  Przykład: Nowa funkcja trafia na produkcję zgodnie z planem, bez cofania zmian.

• Biznes/Product Owner:
  „Użytkownik bez problemu kupuje produkt w 3 kliknięcia.”
  Przykład: Klient kończy zakupy w aplikacji w minutę, nie dzwoniąc na infolinię.

• COO:
  „System działa bez kosztownych awarii i nie trzeba ciągle dzwonić po support.”
  Przykład: Przez rok nie było potrzeby zamawiania kosztownych napraw ani zatrudniania dodatkowych konsultantów.

Każda z tych osób ma rację z własnej perspektywy i potrafi przekonująco uzasadnić swoje stanowisko. Mamy bowiem naturalną tendencję do potwierdzania własnych tez, a nie ich obalania (patrz: EFEKT POTWIERDZENIA). W efekcie zostajemy z kolekcją subiektywnych opinii na temat tego, czym jest dobra jakość.

Konserwatyzm organizacyjny – opór przed zmianą

W praktyce niemal każda organizacja technologiczna wykazuje pewien konserwatyzm. Opór przed zmianą obecnej definicji jakości – status quo – jest wysoki. Firmy wolą pozostać przy tym, co „w miarę” działa, bo po co psuć coś, co przynosi zyski lub realizuje cele. Każdy element zaburzający równowagę traktowany jest jak błąd w systemie, który należy wyeliminować.

W tematyce modelów zmian: SATIR CHANGE MODEL, ADKAR

Wzorce organizacyjne a podejście do jakości

Każdy z opisanych poniżej wzorców organizacyjnych prezentuje inne podejście do definiowania i utrzymywania jakości. Co istotne, w jednej firmie mogą współistnieć różne wzorce – różne zespoły mogą działać według różnych schematów.

Wzorzec 0: Nieświadomy

To punkt wyjścia – zazwyczaj pojedyncza osoba, która nie zastanawia się nad jakością, działa intuicyjnie. Buduje proces planowania wesela, budżetu domowego czy śledzi swoje tętno spoczynkowe, żeby zobaczyć, jak późniejsze chodzenie spać na nie wpływa.

Wzorzec 1: Zmienność

W tym modelu jakość zależy od tego, komu powierzymy zadanie. Jeden superprogramista lub supersprzedawca generuje 80% efektów. Procesy są marginalizowane, a sukces opiera się na indywidualnych talentach. Wymagania są niejasne, a optymizm często przesłania realne zagrożenia. Definicja jakości jest rozmyta – każdy wie, co robić, kierując się „zdrowym rozsądkiem”. W małych organizacjach i systemach takie podejście często się sprawdza – typowe dla startupów lub małych działów IT.

Zespół destabilizuje się wraz ze wzrostem liczby osób i pojawieniem się tzw. bus factora – kiedy kluczowa osoba wypada z gry, pojawia się chaos i potrzeba wprowadzenia rutyn.

Wzorzec 2: Niestabilne rutyny

Wprowadzenie rutyn to naturalny kolejny krok. Typowym przykładem jest firma, w której menedżerem zostaje project manager z korporacji i wdraża tzw. Cargo Cult Agile.

Liczba spotkań rośnie, pojawia się mikrozarządzanie, a jakość jest kontrolowana tylko do momentu, gdy wszystko idzie zgodnie z planem. Procesy są kopiowane z korporacji, często bez refleksji nad ich sensem. Gdy pojawiają się incydenty, reakcją są kolejne spotkania i jeszcze większa kontrola, co prowadzi do spadku jakości pracy.

Kolejne problemy obniżają jakość, a reakcją jest dokładanie nowych procedur zamiast refleksji nad tymi istotnymi. Jakość jest kontrolowana przez menedżera, który nie ufa zespołowi i nie dopuszcza do otwartej wymiany informacji.

Gdy pojawia się problem, reakcją jest dokładanie kolejnych procedur, zamiast zastanowienia się nad sensem istniejących lub robienie tego, co wcześniej, tylko bardziej.

Jak piszemy programy z błędami, to po prostu nie miejmy tych błędów, postarajcie się bardziej.

Rutyny są narzucane odgórnie, a członkowie zespołu nie czują wpływu na proces pracy, co prowadzi do spadku motywacji i kreatywności.

Retrospektywy często istnieją, ale nie są wykorzystywane do analizy przyczyn problemów. Wolno wykonane zadanie to po prostu wolno wykonane zadanie, które można było zrobić szybciej i lepiej, bez głębszej analizy (np. czy powodem jest wolne code review lub CI). Brak komunikacji ze strony zespołu często wynika z przyzwyczajenia do status quo – tylko nowy pracownik podniesie temat, a odpowiedź zwykle brzmi: “tak już po prostu jest”, co przez efekt potwierdzenia zostaje przyjęte jako pewnik.

To co łamie ten wzorzec to niepewność – incydenty i błędy destabilizują system. Ignorowanie tych sytuacji jako specjalne przypadki to niebezpieczny kierunek w stronę perfekcjonizmu. To podejście jest tożsame z ZERO DEFECTS z branży produkcyjnej. Przy produkcji tego samego produktu, jesteśmy w stanie posiadać małą ilość błędnie zrobionych dóbr. W przypadku inżynierii oprogramowania mamy do czynienia z produkcją nowego produktu przy każdorazowym stworzeniu funkcjonalności. Jedyne co może zbliżyć nas do zerowych defektów z branży produkcyjnej jest sam proces pracy i to jak podchodzimy do zmieniających się warunków.

Wzorzec 3: Sterujący

W tym wzorcu menedżer rozumie sens procesów i potrafi je dostosować do aktualnych potrzeb. Zespół zna cel, a menedżer dba o jego zgodność ze strategią firmy. Często cele ustalane są wspólnie, a procesy traktowane jak ewoluujący produkt.

Organizacja jest otwarta na informację zwrotną, a rutyny mają jasno określony cel. Zespół jest gotowy na niespodziewane wydarzenia, bo nie tylko ma proces zarządzania incydentami, ale rozumie, że ciągła praca nad błędami zapewnia stabilniejszy rozwój. Menedżer elastycznie podchodzi do procesów – czasem wprowadza większą kontrolę (np. pair programming), a czasem ją ogranicza, gdy widzi, że zespół jej nie potrzebuje.

Elastyczne podejście to np. rezygnacja z demo produktowego na rzecz krótszych, dedykowanych sesji, gdy zauważymy, że tylko konkretne grupy interesuje dane demo. Innym przykładem jest sytuacja, gdy dział finansowy i zespół produktowy odpowiedzialny za koszyki w systemie e-commerce nie są zainteresowani update’em do UX logowania. Interesariusze z różnych działów interesuje i tak tylko wąski wycinek systemu IT, a eksponowanie ich na całość jest dla nich obciążeniem poznawczym i utrudnia efektywną pracę.

Wzorzec 4 i 5: Oczekujący i Przystający

Te wzorce są bardziej enigmatyczne, są one bardzo podobne do wzorca trzeciego. W czwartym wzorcu mamy do czynienia z traktowaniem procesu tak samo jak produkt, którego mierzymy pod względem skuteczności. Dobrym przykładem jest wdrażanie DORA metrics - to pozwala traktować jako proces wydawczy jako osobny produkt.

Nie ma procesów szytych na miarę i każdorazowo wybieramy co wkładamy do procesu wytwórczego z szerszego katalogu. W przypadku zespołów platformowych np praca w Scrumie, może nie mieć aż tak dużego sensu tak jak w przypadku zespołów produktowych.

Wzorzec piąty jest dalszą iteracją tego pomysłu, każdy wie, że robi procesy i każdy chce je poprawiać z konkretnych powodów - czy to produktowych czy technicznych.

Podsumowanie - Jak ewoluować organizację?

Choć wzorce 1 i 2 mogą działać, dopiero wzorzec 3 zapewnia większe poczucie bezpieczeństwa i przewidywalności.

Dobra jakość w IT nie jest uniwersalna – zależy od perspektywy i kontekstu organizacji. Wzorce organizacyjne pomagają zrozumieć, jak różne podejścia wpływają na utrzymanie jakości. Ewolucja od nieświadomego działania, przez rutyny, po świadome sterowanie procesami to droga, która zwiększa bezpieczeństwo, przewidywalność i satysfakcję zespołu.

Oto kilka praktycznych kroków, które pomagają wejść na wyższy poziom dojrzałości organizacyjnej:

• Otwórz organizację na przepływ informacji – unikaj zamknięcia na feedback.
• Inwestuj w szkolenia, konferencje i książki, szczególnie dla najlepszych inżynierów, którzy potrafią przekazywać wiedzę dalej.
• Zapytaj menedżerów wyższego i niższego szczebla, jak obecnie wykrywają złą jakość – to pozwala lepiej zdefiniować dobrą jakość i wyeliminować zbędne straty.
• Organizuj warsztaty takie jak Event Storming i stwórz medium komunikacji między zespołem a interesariuszami – to pozwoli lepiej zrozumieć wymagania i dostosować procesy do projektu.
• Przeprowadzaj sesje bug bashing i na ich podstawie buduj runbooki – to zwiększy pewność inżynierów na dyżurach i poprawi reakcję na incydenty.
• Przemyśl w grupie, jakie mamy DRAJWERY ARCHITEKTONICZNE – czyli co oznacza jakość oprogramowania w naszym kontekście. Grupy nie są najlepsze do generowania nowych pomysłów, za to są świetne do tego rodzaju ewaluacji.