Pięćdziesiąt z górką lat temu pewien programista i matematyk Dr Melvin Conway ukuł takie prawo, zwane później nie wiedzieć czemu "prawem Conwaya", które stanowi (w moim wolnym tłumaczeniu):

Systemy tworzone przez organizację są odtworzeniem struktury komunikacyjnej w tej organizacji.

Co to oznacza na polski? Wniosków z tego prawa można wysnuć wiele - poniżej przyglądam się kilku moim zdaniem kluczowym.

Prawo Conwaya, a rozmiar zespołu projektowego

Na początek proponuję przyjrzeć się rozmiarom zespołów oddelegowanych do realizacji projektów. Matematyka podpowiada, że liczba możliwych kanałów komunikacyjnych rośnie bardzo szybko w zależności od liczby członków zespołu. Obliczenia zrealizujemy zgodnie z regułą:

czyli znanym ze szkoły wzorem np. na obliczenie liczby możliwych par punktów, gdzie N to liczba punktów.

Przy 5 członkach zespołu liczba możliwych kanałów komunikacji wynosi 10, przy 10 członkach zespołu 45, zaś przy 30 już 435. W projekcie dochodzi narzut związany z zarządzaniem tą komunikacją. Dołóżmy do tego jeszcze barierę językową, różnice kulturowe, różne strefy czasowe, etc. i łatwo dojdziemy do wniosku, dlaczego projekty realizowane przez dużą liczbę ludzi dają często rezultaty mocno poniżej oczekiwań odnośnie jakości, terminowości dostarczenia oraz przydatności znalnego rezultatu.

To ile tych osób powinno być w zespole?

Bardzo dobre pytanie doktorze Watson. Tutaj dochodzimy do słynnego bezosowskiego "two large pizza team". Pan Bezos z Amazona twierdzi, że zespół powinien być co najwyżej tak liczny, aby dało się go nakarmić dwoma dużymi pizzami (niezależnie od poglądów na temat ananasa na pizzy). Wg. różnych źródeł liczność takiego zespołu będzie wynosiła między sześć a dziesięć osób.

Prawo Conwaya, a skład zespołu i oczekiwane rezultaty

Kolejnym wnioskiem z prawa Conwaya jest to, że zespół powinien być budowany pod oczekiwane rezultaty. Jeśli chcemy stworzyć narzędzie, które będzie zrozumiałe dla jakiejś grupy odbiorców, np. użytkowników technologii w wieku 60+, będzie trudno takie narzędzie zbudować zespołowi młodych zapaleńców zaraz po studiach, bez współpracy z ludźmi z grupy docelowej.

Przykłady te można mnożyć, ale konkluzja jest jedna - zespoły powinny być tak zbudowane, żeby łączyć ze sobą zarówno tych, którzy narzędzia potrazą stworzyć, z ludźmi, którzy będą mówić językiem końcowego odbiorcy (jakby ktoś się zastanawiał do czego jest potrzebny dobry UXowiec, a UX to nie koniecznie to samo co ładny webowy interfejs).

Prawo Conwaya vs Technologia

Prawo Conwaya tworzy podwaliny pod modularyzację tworzonych rozwiązań. Modularyzacja na przestrzeni dziejów objawiała się za pomocą różnych wzorców projektowych, czy architektonicznych. Dzisiaj tę "nowość" nazywamy mikroserwisami (kolejny dowód w tezie, że w branży IT tylko przepakowujemy stare koncepty w nowe nazwy).

Optymalnie zaimplementowana architektura rozwiązania informatycznego (czy to w oparciu o mikroserwisy, czy inny paradygmat określający sposób separacji poszczególnych warstw, czy modułow rozwiązani) umożliwi m.in.:

• Rozdzielenie i sprecyzowanie odpowiedzialności
• Niezależność instalacji
• Zwiększenie niezawodności / odporności na awarię
• Zwiększenie testowalości

Ale ja mam gigantyczny projekt do zrealizowania - jak się do tego zabrać i w czym ten Conway mi pomoże?

Bądź jak wódz rzymski, tudzież żoliborski - "divide et impera". Albo nie, w sumie to nie bądź. Nie chodzi nam bowiem o skłócanie podbitych nacji, czy wewnątrzpartyjnych frakcji, a bardziej o podejście "divide & conquer" w rozumieniu algorytmów, czyli dziel duże zadanie na mniejsze, których suma da oczekiwany efekt końcowy. Zespoły powinny być interdyscyplinarne, zorganizowane wokół usług biznesowych, które później będą złożone w jeden lub więcej produktów wykorzystywanych przez końcowych użytkowników.