Prawo Conway’a zostało zdefiniowane już w 1967 roku, ale jego ważność trwa po dziś dzień. Mówi ono, że każda organizacja kopiuje swoje struktury organizacyjne w tworzone rozwiązanie. Tylko co to znaczy i jak na nas wpływa? Samo prawo brzmi dość zagadkowo. Ma jednak ogromne przełożenie na rezultaty pracy naszych zespołów.
Pierwszy raz się z czymś takim spotykam
Pewnie zauważyliście, że pierwszej euforii związanej z tworzeniem nowego produktu albo startem nowego projektu informatycznego, współtowarzyszy radość z zaprojektowania jego nowej architektury. Oczywiście rozwiązania zgodnego z aktualnymi trendami, w oparciu o najlepsze frameworki i biblioteki, oraz budowanego przy użyciu najnowszych wersji narzędzi wspierających wywarzanie. Idylla. Nie inaczej zresztą jest przy tworzeniu nowej, dużej wersji produktu. Więc organizujemy się, mamy dobrych architektów i projektantów i na tym etapie wychodzi nam to naprawdę doskonale. Zaczynamy implementację. Po roku okazuje się jednak, że nasza wspaniała modułowa czy micro-service’owa architektura, dobrze podzielona na domeny technologiczne i biznesowe spinane przemyślaną platformą staje się jakimś dziwnym monolitycznym tworem albo tworem zmodularyzowanym, w którym panuje nieprzenikniona sieć zależności. Efektem bohaterskiej walki z niwelowaniem tych zależności jest ku naszemu zdumieniu, stały przyrost nowych. Zaś dług technologiczny rośnie, mimo że w zasadzie dopiero zaczęliśmy. Wygląda znajomo? Przecież wszystko było zaprojektowane prawidłowo! Otóż odpowiedzią (być może niejedyną) jest tzw. Prawo Conway’a, albo inaczej hipoteza lustrzana. Pewnie większość z Was słyszała, ale czy rzeczywiście potrafimy wyciągnąć z niej wnioski i praktycznie zredukować sobie powyższe ryzyka. Z tym już jest dużo gorzej. Ale zacznijmy od początku.
Dura lex, sed lex!
Czym jest hipoteza lustrzana? I czy jest to hipoteza, czy już może prawo? Wydaje się nam, że prawo jest czymś, co jest udowodnione i pewne, zaś hipoteza to tylko jakieś założenie. Nic bardziej mylnego. Najściślejsze prawa np. fizyki są tylko hipotezami. Na tyle są prawdziwymi, na ile nikt ich nie obalił. Weźmy najprostsze II Prawo Dynamiki Newtona. Jeśli ktokolwiek kiedykolwiek udowodni, że to prawo nie funkcjonuje w naszym świecie makro, to przestanie ono być prawdziwe! Tak to działa i na tym polega geniusz ludzi, którzy takie prawa tworzą. Podobnie jest z prawami w naukach badających zachowania społeczne. Z tą różnicą, że tutaj jako prawo bierze się hipotezę, która jest istotna statystycznie, tzn. badania statystyczne potwierdzają, że w wystarczająco dużej ilości przypadków występuje jakaś cecha, czy zależność. Skoro wiemy już, o czym mówimy, to czas się zapoznać z prawem Conway’a. Mówi ono: „Każda organizacja wytwarzająca jakiś system wytwarza go tak, że jest on odzwierciedleniem struktury komunikacyjnej tej organizacji”. Brzmi bełkotliwie prawda? To czas przyjrzeć się temu z bliska.
No dobrze, ale jak to działa?
Słyszeliście kiedyś określenie system socjo-technologiczny? Mocno upraszczając, nawet jak działamy w obrębie czystej technologii to produkty, które wytwarzamy, są mocno zależne od czynników ludzkich zarówno indywidualnych, jak i całej grupy, która go wytwarza (Przeczytaj o wadach i zaletach pracy w grupie). Nie jest tak, że technologia to jedno, a zespół ludzi to drugie. Obydwa te składniki są jednym systemem, czy się nam to podoba, czy nie. Systemem, który wytwarza, w naszym przypadku system informatyczny. I tu dochodzi dodatkowa komplikacja. O ile w klasycznych systemach produkcyjnych np. produkcji samochodów, system taki wytwarza produkt, tak w przypadku informatyki system wytwarza system przetwarzania informacji, sam przetwarzając informację. Brzmi dość zawile, ale takie są fakty. Może dlatego informatyka jest tak droga i tak trudna. A co jest podstawowym organem przetwarzającym informację w przyrodzie? Tak - mózg. Mózg działa tym sprawniej, im szybciej przystosowuje siebie i nasz organizm do zmieniających się warunków otoczenia. Niektórzy definiują tak nawet to, czym jest inteligencja. I tutaj dochodzimy do sedna. Tzn. system socjo-technologiczny, w którym pracujemy, musi działać jak mózg, żeby sprawnie przetwarzać informacje i sprawnie odpowiadać na zmienne warunki otoczenia, jakie nam stwarzają klienci, rynek itd. Stąd popularność ostatnimi czasy metodyk zwinnych, czy praktyk lean, które powodują poprawę adaptacji zespołów. Ale co to ma wszystko wspólnego z hipotezą lustrzaną? Otóż właśnie hipoteza lustrzana mówi o tym, że nie tylko architektura systemu powinna opowiadać na potrzeby klientów i rynku, ale też struktura naszej organizacji, w której te systemy wytwarzamy. Czyli możemy mieć najlepszych architektów, którzy zaprojektują najfantastyczniejsze i ponadczasowe rozwiązania, ale jak nie skonstruujemy zespołów i całej organizacji, która tę architekturę wyprodukuje na jej podobieństwo, to uzyskamy z czasem efekty, o których była mowa na początku tego artykułu (Przeczytaj nasz artykuł "Jak zwiększyć produktywność w projektach? Współpraca operacji i specjalistów DevOps pracujących w zespołach zwinnych"). To nie architekci odpowiadają za nowoczesne i skuteczne rozwiązanie, lecz wszyscy, którzy mają wpływ na kształt organizacji, w której jest ona tworzona. Managerowie, coachowie, team leaderzy oraz same zespoły. No dobrze, teoria teorią, ale co wynika z tego, że już wiemy, co wiemy?
W praktyce
Otóż znowu odwołajmy się do mózgu. Zauważmy, że mózg składa się z obszarów odpowiedzialnych za poszczególne funkcje życiowe, czy zmysły. Oprócz tego ma oczywiście elementy centralne, w których informacje są przetwarzane, jak i posiada coś, w rodzaju platformy, która stanowi bazę dla wszystkich tych wyższych procesów. Więc naszą organizację trzeba podzielić na samodzielne zespoły, które będą odpowiadać za tworzenie strumienia wartości w ramach grupy domen biznesowych. Może być tak, że czasem dana domena jest tak złożona, że zostanie przypisana na stałe do jednego zespołu. Oczywiście zespoły nie powinny być za duże, tak żeby móc budować modele mentalne, w tych zespołach rozumiane i współdzielone przez wszystkich jego członków. Oprócz tego, na pewno w organizacji trzeba mieć zespół lub zespoły budujące platformę technologiczną czy narzędziową dla powyższych zespołów. Ważny jest też zespół, który będzie umożliwiał i koordynował pracę we wszystkich obszarach, jak i zapewniał właściwą komunikację. Szczegóły zależą już tylko od tego jak zaprojektowaliśmy sobie konkretne rozwiązanie, jak i od tego, jakie drogi mniej lub bardziej zwinne wybraliście. Resumując - najskuteczniej implementują powyższe założenia 7-9 osobowe full stack’owe zwinne zespoły, ze skuteczną metodą skalowania. Ale to temat na osoby artykuł. Co więc warto zapamiętać z dzisiejszego materiału?
Świadomość
Jeśli pracujecie w organizacji podzielanej na działy lub departamenty, to jesteście skazani na tworzenie produktów, takich jak organizacja tych działów. Ba jeśli dwa takie same działy będą robić podobne rzeczy, to wytworzą w tym czasie takie same produkty. Czyli im bardziej są to „sztywne” struktury, tym będzie Wam trudniej wdrożyć nowe i unikatowe rozwiązania. Zaś jeśli macie możliwość stworzenia sobie w organizacji dowolnych struktur lub choćby wpływu na to, to warto dążyć do tego, żeby ta struktura odzwierciedlała architekturę Waszego systemu, a jednocześnie była sprawna jak ludzki mózg. Architekturę, która nie musi być od razu cała gotowa! Być może dużo z niej jesteśmy się w stanie nauczyć w trakcie zmian organizacji i samego procesu jej wytwarzania.
Jeżeli zainteresował Cię temat prawa Conway’a to warto, jako rozszerzenie przeczytać:
- “Team Topologies: Organizing Business and Technology Teams for Fast Flow” M. Pain, M.Skeleton
- “Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis “ A. MacCormack, J. Rusnak, C. Baldwin
- “Conway Law” M.Conway
- “Socio-technical Congruence in OSS Projects: Exploring Conway’s Law in FreeBSD” M.M. M. Syeed , I. Hammouda