Architektura w skali to model mentalny2024-09-22Cześć! Twojej organizacji przybywa inżynierów. Liczba zespołów przekracza już coraz mocniej możliwość manualnego koordynowania wszystkimi pracami. Pozostaje jedno rozwiązanie: delegować część pracy w dół. Tylko jak to zrobić, by nie zabić efektywności? O tym będzie w dzisiejszym wydaniu.💪 Standardowo, czeka na Ciebie również Inżynierska Prasówka. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaDziś będzie Marty Cagan aż dwa razy 😃 najpierw w publikacji o roli liderów inżynierów, a później o modelu produktowym w outsourcingu. A poza tym kompromisy architektoniczne, asystenci GenAI i kilka gorzkich słów o Story Pointach.
Architektura w skaliPrzy pracy w każdej większej organizacji prędzej czy później pojawia się problem jak pracować architektonicznie, wspólnie i w jednym kierunku. Możesz kojarzyć ten popularny obrazek z artykułu Balancing Autonomy and Alignment with Accountability:
Zwykle na początku dajemy inżynierom dużą autonomię. A to rodzi swoje problemy. Problemy pracy zespołowejW miarę rozrastania się organizacji, coraz więcej zespołów zaczyna pracować równolegle nad różnymi elementami systemu. Każdy zespół chce działać autonomicznie i efektywnie. W rezultacie, często obserwujemy sytuację, gdzie każda grupa:
Ta swoboda na pierwszy rzut jest oka korzystna dla produktywności poszczególnych zespołów. Długofalowo niesie ona jednak ze sobą poważne wyzwania na poziomie całej organizacji. Prowadzi to do:
A takie techniczne bolączki mogą ostatecznie wpływać na biznes powodując:
Część organizacji rozwiązuje ten problem przez dodanie dodatkowej warstwy procesów i struktury organizacyjnej na pracę zespołową. Chcemy mieć swego rodzaju spoiwo ponad zespołami, aby architektonicznie na pewno szły w jednym kierunku. Jednak takie podejście może się okazać krótkowzroczne. Dlaczego same procesy nie wystarcząZ drugiej strony, jeśli skupimy się tylko na procesach i strukturze, doprowadzi to do szeregu problemów:
Przepalanie czasuNadmiarowe procesy prowadzą do przepalania czasu na nieefektywne działania. Zespoły tracą całe godziny na wypełnianie formularzy, uczestniczenie w spotkaniach i przygotowywanie dokumentów. A wtedy nie skupiają się na faktycznym rozwiązywaniu problemów technicznych. W efekcie, zamiast przyśpieszać pracę, procesy ją spowalniają i utrudniają wprowadzanie zmian w architekturze. Brak myślenia krytycznegoNadmierne poleganie na procesach zastępuje krytyczne myślenie. Inżynierowie działają mechanicznie, podążając za ustalonymi procedurami, zamiast rozumieć sytuację architektoniczną. To prowadzi do powielania nieefektywnych wzorców i hamuje nowe podejścia do rozwiązywania problemów technicznych. A to łączy się z kolejnym punktem… Tylko architekci myśląDecyzje architektoniczne są podejmowane tylko przez architektów i menadżerów. Jednak wiele istotnych wyborów architektonicznych dzieje się na poziomie codziennej pracy programistycznej - w sposobie strukturyzowania kodu, projektowania interfejsów czy integracji komponentów. Bez wiedzy i zrozumienia szerszego kontekstu architektonicznego, deweloperzy nie są w stanie podejmować tych decyzji w sposób spójny z ogólną wizją systemu. To prowadzi do fragmentacji architektury i tworzenia rozwiązań, które trudno później zintegrować w spójną całość. Niska elastycznośćSztywne procesy hamują szybkość reakcji na zmieniające się wymagania techniczne. Organizacja traci zdolność do adaptacji architektury w odpowiedzi na nowe wyzwania technologiczne. Wszystko musi przejść przez warstwę “architektów”. Rozmycie odpowiedzialnościNadmiar procesów rozprasza odpowiedzialność za architekturę. Gdy każda decyzja architektoniczna musi przejść przez wiele szczebli zatwierdzenia, trudno określić, kto faktycznie odpowiada za dany obszar. To prowadzi do sytuacji, gdzie nikt nie czuje się w pełni odpowiedzialny za spójność i efektywność architektury systemu. Uważam, że same procesy nie są rozwiązaniem problemu architektury w skali. Potrzebne jest podejście, które
To właśnie tutaj kluczową rolę zaczyna odgrywać architektura jako wspólny model mentalny.
Architektura jako model mentalnyArchitektura jako wspólny model mentalny to podejście rozszerzające tradycyjne procesy i dokumentacje. To sposób myślenia o systemach, którymi żyje organizacja.
Kluczowe elementy tego podejścia to:
Gdy cała organizacja podziela ten sam model mentalny, przynosi to szereg korzyści:
Aby lepiej zrozumieć, jak taki model mentalny może wyglądać w praktyce, przyjrzyjmy się przykładom z Amazona i AWS. Amazon i modele mentalnePrzykłady wspólnego modelu mentalnego na podstawie:
pokazują, jak spójne zasady mogą kształtować kulturę organizacyjną i wpływać na decyzje architektoniczne. Przyjrzyjmy się trzem kluczowym elementom:
“Frugality” - Oszczędność jako podstawa architekturyAmazon promuje kulturę oszczędności, która przekłada się bezpośrednio na decyzje architektoniczne:
Ta zasada sprawia, że każdy inżynier w Amazonie myśli o kosztach operacyjnych, a nie tylko o dostarczeniu funkcjonalności. “Ownership” - Poczucie własności w architekturzeAmazon promuje kulturę własności, która ma głęboki wpływ na podejście do architektury:
Takie podejście sprawia, że zarówno architekci, jak i inżynierowie czują się odpowiedzialni za długoterminowy sukces systemów, które tworzą. Architektura jako seria kompromisówW Amazonie rozumie się, że każda decyzja architektoniczna wiąże się z kompromisami:
To pomaga w podejmowaniu świadomych decyzji architektonicznych, które uwzględniają różnorodne aspekty i konsekwencje. Dzięki tym zasadom, Amazon stworzył kulturę, w której każdy pracownik, od inżyniera po architekta, musi się przede wszystkim skupiać na istotnych aspektach architektury. Dzięki temu jest też większa szansa, że podejmie decyzje zgodne z długoterminową wizją firmy. Rola liderówLiderzy są tymi, którzy kształtują modele mentalne w organizacji. Dyrektorzy, managerowie i liderzy liniowi mają możliwość bezpośredniego wpływania na sposób, w jaki cały zespół myśli o architekturze i podejmuje decyzje techniczne.
Możemy tutaj wyróżnić 4 obszary tej odpowiedzialności:
Efektywne wdrożenie tych praktyk tworzy kulturę, w której decyzje architektoniczne są podejmowane świadomie, spójnie i z myślą o długoterminowym sukcesie organizacji. Co dalej?Aby nie tworzyć artykułów-tasiemców tutaj na dziś postawię kropkę. W kolejnych wydaniach porozmawiamy dokładniej o tym, jak to wdrożyć w życie. Będzie o kierunku architektury, staff engineerach, gildiach architektonicznych, review boardach, czy ADRach. Stay tuned, a w między czasie daj znać, jak wygląda podejmowanie decyzji w skali u Ciebie 😊 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
