Otóż niekoniecznie. Decyzja podjęta w 5 minut potrafi kosztować 5 tygodni, jeśli zespół jej nie rozumie, nie kupuje i wdraża ją bez przekonania. W tym artykule pokażę Ci, dlaczego wspólne planowanie architektury z programistami - choć na pierwszy rzut oka wolniejsze - daje lepsze rozwiązania, większe zaangażowanie i sprawniejsze wdrożenia. Pokażę też konkretny scenariusz warsztatu, który możesz przeprowadzić w swoim zespole choćby w przyszłym tygodniu.
Dlaczego warto angażować programistów w decyzje architektoniczne
Kiedyś panowało przekonanie, że architektura to zadanie wyłącznie dla głównego architekta albo najbardziej doświadczonego seniora. Dziś wiemy, że najlepsze systemy powstają wtedy, gdy w projektowanie angażuje się cała drużyna. Simon Brown - twórca modelu C4 i autor Software Architecture for Developers - od lat powtarza, że architektura to rola, którą wykonuje cały zespół, a nie ranga jednej osoby. Diagramy C4 zaprojektował zresztą jako wspólny język zespołu, a nie prywatny artefakt architekta.
W świecie .NET brzmi to szczególnie znajomo. Decyzje typu monolit modularny czy mikroserwisy, Minimal API czy klasyczne kontrolery, EF Core czy Dapper, Clean Architecture czy Vertical Slice, MediatR czy zwykłe serwisy - to nie są wybory, które da się "zamknąć" w pojedynczej głowie bez konsekwencji. Każda z nich rozlewa się na miesiące pracy całego zespołu.
Oto co zyskujesz, gdy podejmujesz je wspólnie:
• Większe poczucie odpowiedzialności. Kiedy developerzy współtworzą decyzję, czują się współodpowiedzialni za jej powodzenie. To nie jest już "architektura, którą ktoś nam narzucił" - to "nasza architektura". A o swoje dba się inaczej niż o cudze: staranniej pisze się kod, uważniej pilnuje granic między warstwami, chętniej reaguje na dług techniczny.
• Szersza perspektywa i mniej ślepych plamek. Zespół to zbiór różnych doświadczeń. Ktoś pamięta, jak poprzedni projekt utknął na słabo dobranym message brokerze. Ktoś inny właśnie czytał o pułapkach wydajnościowych w EF Core przy dużych zestawach danych. Wspólna dyskusja wyłapuje ryzyka i szanse, które jednej osobie by umknęły - a przy okazji rodzi rozwiązania, na które sam byś nie wpadł.
• Realny buy-in zamiast cichego oporu. Jeśli cały zespół uczestniczy w wyborze kierunku, znacznie łatwiej o zrozumienie i akceptację. Decyzja narzucona z góry często spotyka się z biernym oporem ("zrobię, jak każą, ale wiedziałem, że to nie zadziała"). Decyzja wypracowana wspólnie ma za sobą ludzi, którzy naprawdę chcą, żeby się udała.
• Rozwój całego zespołu. Dyskusja architektoniczna to najlepsza forma nauki, jaką znam. Młodsi programiści obserwują tok rozumowania bardziej doświadczonych kolegów, seniorzy muszą uzasadnić swoje intuicje na głos (a to bezcenne ćwiczenie), a Ty jako lider dostajesz zespół, który z czasem sam podejmuje coraz lepsze decyzje projektowe.
Jak przeprowadzić warsztat architektoniczny - krok po kroku
Zalety brzmią dobrze, ale jak to praktycznie zorganizować, żeby nie skończyło się dwugodzinną, chaotyczną dyskusją bez konkluzji?
Oto sprawdzony schemat, który dostosujesz do swojego projektu:
1. Zdefiniuj problem i kryteria sukcesu. Nazwij jasno decyzję do podjęcia: "wybieramy sposób komunikacji między serwisami", "rozstrzygamy, czy raportowanie idzie przez osobny read model". Od razu ustal, po czym poznacie dobre rozwiązanie - wydajność, koszt utrzymania, czas wdrożenia, łatwość onboardingu nowych osób. Bez tych kryteriów dyskusja zamieni się w wojnę gustów.
2. Zaproś zespół i przygotuj przestrzeń. Umów termin i z góry powiedz, czego dotyczy spotkanie - ludzie przyjdą przemyślani, a nie zaskoczeni. Zadbaj o warunki do myślenia: tablica i karteczki na miejscu albo wirtualny board (Miro, Excalidraw) zdalnie. Chodzi o to, by każdy czuł się swobodnie, rzucając pomysł.
3. Zbierzcie propozycje (burza mózgów). Zacznijcie od rozbieżności, nie od zbieżności. Poproś, by każdy najpierw zapisał swoje pomysły samodzielnie - kilka minut w ciszy - a dopiero potem je omawiajcie. Dzięki temu głos zabiorą też ci cichsi, którzy w otwartej dyskusji przegraliby z najgłośniejszym seniorem. Często najlepsza opcja wychodzi właśnie od kogoś, po kim się jej nie spodziewałeś.
4. Przeanalizujcie opcje. Dla każdej propozycji przejdźcie mocne i słabe strony, ryzyka, koszt wdrożenia i konsekwencje długoterminowe. Tutaj Twoja rola jako tech leada to moderacja: pilnuj tematu i ram czasowych, wyciągaj do głosu cichszych, studź zbyt szybkie "przecież to oczywiste". Warto wprost zapytać: "co musiałoby się wydarzyć, żeby ta opcja okazała się złym wyborem za rok?".
5. Podejmijcie decyzję. Gdy argumenty są na stole, wyłońcie rozwiązanie. Najlepiej naturalnym konsensusem. Jeśli zdania są mocno podzielone, to Ty jako lider podejmujesz ostateczną decyzję - ale jawnie, z uzasadnieniem, uwzględniając to, co usłyszałeś. Zespół zniesie decyzję, z którą się nie zgadza, jeśli poczuje, że został wysłuchany. Nie zniesie decyzji, która spadła znikąd.
6. Zapiszcie ustalenia. Na koniec spiszcie, co postanowiliście i - co ważniejsze - dlaczego. Świetnie sprawdza się tu ADR (Architecture Decision Record): krótki plik w repozytorium opisujący kontekst, rozważane opcje i podjętą decyzję. Za pół roku, gdy ktoś zapyta "czemu to jest zrobione akurat tak?", odpowiedź będzie w gicie, a nie w cudzej pamięci.
Jak to wygląda w praktyce
Kilka projektów temu stanęliśmy przed pozornie prostą decyzją: zbudować moduł raportowy od zera czy podpiąć gotową platformę BI. Miałem już w głowie odpowiedź (BI), ale zamiast ją ogłosić, zwołałem zespół.
Ku mojemu zaskoczeniu jeden z programistów zaproponował trzecią drogę, o której w ogóle nie pomyślałem: wykorzystać nasze istniejące API i dopisać do niego cienką warstwę prezentacyjną, zamiast wtaczać do projektu cały ciężki system BI. Po burzliwej - momentami naprawdę burzliwej - dyskusji wypracowaliśmy plan oparty właśnie na tym pomyśle. Był prostszy w utrzymaniu, tańszy i lepiej pasował do tego, co już mieliśmy.
Efekt był podwójny. Zespół ruszył do implementacji zmotywowany, bo każdy czuł, że dołożył swoją cegiełkę. A ja jako lider zyskałem coś cenniejszego niż "moja" decyzja: pewność, że obrany kierunek został przemyślany z kilku stron i ma za sobą całą drużynę.
Podsumowanie
Planowanie architektury z całym zespołem to inwestycja, która się zwraca. Owszem, wymaga więcej czasu na etapie dyskusji - ale procentuje lepszymi decyzjami, wyższym morale i sprawniejszą realizacją. Developerzy czują realny wpływ, więc biorą odpowiedzialność za efekt. A Ty przestajesz być samotnym architektem, który "rzuca decyzje z góry" i modli się, żeby zadziałały.
Architektura to gra zespołowa. Zagraj w nią jak zespół.
Piszę takie rzeczy - o architekturze, dobrych decyzjach technicznych i praktycznym .NET - regularnie, ale najciekawsze przemyślenia i historie prosto z projektów (takie jak ta o module raportowym powyżej) trafiają najpierw do mojej listy VIP. To zamknięta grupa programistów, którym zależy na tym, żeby rosnąć - nie tylko w kodzie, ale i w roli technicznego lidera. Zero spamu, zero lania wody, sama konkretna wiedza wprost na skrzynkę. Jeśli chcesz do nas dołączyć, zapisz się tutaj » - do zobaczenia po drugiej stronie.
