Złota zasada

Nawet gdyby czytać niezmiernie mało – co nie jest łatwe w dzisiejszych czasach – nie sposób w przyswajanych treściach, nie natknąć się na krótkie, zwięzłe zdania, pełniące rolę „złotych myśli”.

I tak, w IT mamy: „dopiero sieć to komputer”, „moc obliczeniowa komputerów podwaja się co 24 miesiące”, „jeżeli coś może się nie udać – nie uda się na pewno”, „kompozycja jest lepsza od dziedziczenia”, czy niesławne „Internet? Nie, dziękuję, nie jesteśmy zainteresowani”. Jedna z tych złotych zasad przykuła moją uwagę i już od dawna i do dzisiaj nie daje mi spokoju. Pewnie dlatego, że regularnie obserwuje jej coraz większą słuszność.

Pewien informatyk, programista (także haker) znany jako Melvin Edward Conway wykombinował i opublikował zasadę, można by rzec prawo, które w nieznacznie swobodnym tłumaczeniu brzmi tak:

Każda organizacja, która projektuje system, stworzy projekt, którego struktura jest kopią struktury komunikacyjnej organizacji

Dlaczego to zdanie uważam za ogromnie ważne? Każda organizacja z definicji składa się z pewniej struktury, struktura ta posiada wydzielone elementy składowe (dział, zespół, stanowisko) z ustaleniem hierarchii i podziałem kompetencji, oraz ustala zasady komunikacji pomiędzy tymi elementami (kto, z kim, kiedy, jak). Zauważyliście?

To brzmi jakbym opisywał tworzenie architektury systemu informatycznego:

podział, hierarchia, odpowiedzialność, interfejs, komunikacja

Przecież to jest kopia 1:1! Czy zatem organizacja to taki system informatyczny … tak, prawie dokładnie tak. Wiemy to a Pan Conway zauważył coś więcej. Żyjąc w organizacjach, tworząc systemy, kopiujemy je wzorując się na zasadach komunikacji obowiązujących w naszych organizacjach. Przykłady?

W pewnej, znanej mi firmie, nie ma kultury pracy zespołowej. Każdy działa na swoje konto, każdy ma swój moduł za który odpowiada, czasem wręcz „swoich klientów”. Poszczególne osoby nie są nastawione na współpracę, tyko na rywalizację i zdobywanie przewagi nad innymi. Produkt który produkuje ta firma początkowo miał być jednym spójnym systemem. Aktualnie jest zbiorem odrębnych, dedykowanych aplikacji, z których każdy wygląda, działa i zachowuje się inaczej. W wielu z nich dublowane są informacje, często używane są specyficzne nie znane innym twórcą technologie. Wypuszczenie nowej wersji systemu to „koszmar”, trwa wiele dni, trzeba „uzgadniać niezgodności” itd. W tej organizacji motorem twórców nie jest realizacja wspólnego celu, tylko konkurencja i rywalizacja. Przekłada się to 1:1 na tworzony produkt.

W kolejnej organizacji którą pobieżnie znam, istnieje mocny podział na działy. Każdy z działów jest silnie obłożony targetami, musi zrealizować pewne plany sprzedaży usług i towarów wyrażone w konkretnych kwotach. Zespoły posiadają biura w różnych lokalizacjach, zasady pracy, wynagradzania czy standardy zarządzania są mocno indywidualne z silną autonomią lidera działu. Komunikacja pomiędzy działami odbywa się poprzez zarząd. Komunikacja bezpośrednia jest szczątkowa i jeżeli występuje to tylko w celu otrzymania jakiś informacji potrzebnych do realizacji targetu. Produkt dostarczany do klienta jest na tyle złożony, że składa się z elementów wytwarzanych przez więcej niż jeden dział. W takiej organizacji powstaje mało powtarzalny produkt, który charakteryzuje się nikłą spójnością i ogromnymi różnicami standardów jakości w modułach składowych. Organizacja ta aktualnie szuka rozwiązania problemu.

Trzeci przykład to organizacja w której działa mikro zespół (jeden z wielu) liczący 3 osoby. Zespół został stworzony z osób z różnych zespołów początkowo jako zespół projektowy, a w efekcie na stałe przejął do utrzymania kilka odrębnych ale w pewien sposób związanych ze sobą aplikacji. Zespół jest mały, doskonale skomunikowany, pracują dosłownie „biurko w biurko”. Po pewnym czasie aplikacje te zaczęły wyglądać podobnie, wręcz prawie tak samo. Pojawiły się nawet propozycje zunifikowania funkcji przez nie realizowanych, w jedną aplikację z kilkoma modułami. Czy słusznie … nie wiem, ale taki jest właśnie wpływ prawa Conway’a.

Jako ostatni przykład, coś z naszego podwórka. Dawno temu kiedy nasz zespół urósł i nie mieścił się już w jednym pomieszczeniu, a spacery po firmie i głośne rozmowy coraz bardziej zaczęły nam doskwierać, poczuliśmy ogromną potrzebę komunikowania się w jakiś inny sposób. Dodatkowo brakowało nam wiedzy kto siedzi przy biurku, kto wyszedł, kto jest na urlopie, z kim i kiedy mamy umówione spotkanie. Te wszystkie potrzeby przełożyły się na produkt. Powstał zatem komunikator wewnątrz-firmowy, zintegrowany z innymi systemami w firmie. Komunikator ten zaspokoił nasze potrzeby i … stał się produktem handlowym firmy, zaspokajając podobne potrzeby w innych firmach.

Co ciekawe, zasada Pana Conway’a zainspirowała innych do wygłoszenia tez podobnych, pokrewnych, i tak:

• „Struktura dowolnego systemu zaprojektowanego przez organizację jest jednoznaczna w stosunku do struktury organizacji”
• „Jeśli części organizacji nie odzwierciedlają ściśle istotnych części produktu lub jeśli relacje między organizacjami nie odzwierciedlają relacji między częściami produktu, wtedy produkt będzie miał kłopoty”
• „Upewnij się, że organizacja jest zgodna z architekturą produktu”
• „Jeśli masz cztery grupy pracujące nad kompilatorem, otrzymasz kompilator cztero-przebiegowy” 🙂
• „produkt opracowany przez luźno związaną organizację jest znacznie bardziej modułowy niż produkt z organizacji ściśle związanej”

Co zatem z tego wynika? Jeżeli sukces rynkowy (lub porażkę) odnosić ma produkt a jego kształt wynika z kształtu (struktury i komunikacji) organizacji to nasuwa się wniosek, że o sukcesie rynkowym decyduje komunikacja i struktura organizacji. I to jest dla mnie wciąż wyraźnie zaskakujące.

Czy Pan Conway ma rację? Proponuję przeanalizujcie swoje organizacje i zastanówcie się czy w waszym przypadku tak jest, czy nie koniecznie.