🗺️ Projektowanie organizacji
Praktyki Inżynierskie Najlepszych Firm Produktowych
Aby zebrać w jednym miejscu praktyczną i aktualną wiedzę dotyczącą praktyk inżynierskich, postanowiłem swoje doświadczenia zebrać w serii artykułów pod wspólną nazwą Praktyk Inżynierskich. Mam nadzieję że to kompendium będzie miejscem, do którego możesz wracać po wskazówki i rozwiązania.
W cyklu Praktyk Inżynierskich:
Projektowanie organizacji [TEN ARTYKUŁ]
Witaj w pierwszym odcinku cyklu praktyk inżynierskich najlepszych firm produktowych. Dzisiaj na tapet bierzemy….
🗺️ Projektowanie organizacji
Gdy silosy projektują nam system
Są jeszcze organizacje, które tworzą zespoły stricte funkcjonalne, takie jak zespół backendowy, frontendowy,czy testowy. W praktyce oznacza to jeden produkt, ale jednocześnie 3 różne zespoły i 3 różne backlogi. Jak się to może skończyć?
Produkt podzielony ze względów technicznych, a nie biznesowych.
Dużo hand-offów i długi czas naprawiania problemów.
Kłótnie o zakres odpowiedzialności i spychologia.
Ale przecież już dawno się tak nie robi, prawda?
Owszem, coraz rzadziej się spotyka takie sytuacje. Pamiętaj jednak, silosy mogą Cię zaatakować z każdej strony.
Dobrze pokazuje to przykład produktu, nad którym kiedyś pracowałem. Na pewnym etapie został zangażowany zewnętrzny administrator baz danych (DBA). Miał on za zadanie zmigrować stare dane do nowego produktu. Jednak pracował on kompletnie niezależnie od nas. Miał własnego PMa i deadline’y, narzucone przez organizację.
Jak to się skończyło? Smutny rezultat poniżej. 😥⬇️
Największą przeszkodą było to, że nie mogliśmy dostosowywać bazy danych pod własne potrzeby. Każda zmiana musiała mieć pozwolenie zewnętrznego DBA. Spowodowało to kilkutygodniowe opóźnienie we wprowadzaniu zmian. Ostatecznie skończyliśmy z „obcą” bazą danych.
Dlaczego tak się stało? Zaatakowało nas prawo Conway’a, czyli w uproszczeniu:
Struktura organizacji wpływa na projektowane rozwiązanie.
A w naszym przypadku - błędne zaprojektowanie organizacji spowodowało duże problemy z produktem.
Efektywne organizacje inżynierskie działają inaczej.
Inżynierskie projektowanie organizacji
Przed prawem Conway’a nie da się uciec. Można się do niego tylko dostosować.
Aby to zrobić, musimy inżyniersko zaprojektować strukturę organizacyjną tak, aby była dostosowana do naszych problemów biznesowych. To sprawi, że będziemy lepiej adresować podobne problemy w naszym produkcie.
Dobrze przedstawił to Nick Tune, w swoim artykule The Relationship Between Software Architecture And Business Models:
Struktura organizacyjna zostanie skopiowana przez architekturę rozwiązania. Aby zapewnić spójność pomiędzy produktem, a domeną biznesową, musimy zadbać o kształt zespołów.
Oznacza to, że projektując zespoły musimy wziąć pod uwagę dodatkowe aspekty:
Biznesowe obszary naszej domeny.
Modele współpracy pomiędzy zespołami, nastawione na efektywność pracy.
Proces migracji struktury organizacyjnej oparty o kwestie funkcjonalne i emocjonalne.
Tylko wtedy zbudujemy zespoły, które będą:
Dostosowywały rozwiązania techniczne do specyfiki określonego obszaru.
Miały głęboką odpowiedzialność za swój obszar.
Dostarczały wartość biznesową od A do Z.
To oczywiście przełoży się na bardziej zyskowny produkt 🤑
Przykład z branży
Praktycznym przykładem z wykorzystania wzorców dookoła tematyki domain-driven designu i Team Topologies podzielił się Piotr Kacała, CTO firmy Displate.
Q: W jaki sposób wykorzystaliście Team Topologies w waszej organizacji?
A: Żeby zwiększyć efektywność naszych zespołów oraz ułatwić nam migrację w stronę MACH (Microservices, API-first, Cloud-based, Headless) wykorzystaliśmy Team Topologies w kilku krokach:
Zidentyfikowaliśmy wszystkie kluczowe streamy biznesowe, nad którymi zespoły miały pracować (stream-aligned teams) u nas nazywane domenami
Oficjalnie stworzyliśmy zespół platformowy, który miał utrzymywać platformę do zwiększania autonomiczności zespołów typu stream-aligned.
Stworzyliśmy zespół Java-enabling, który pomagał zespołom z wykorzystaniem nowej technologii w naszym stacku
Przedyskutowaliśmy, jak mają wyglądać interakcje między zespołami (Collaboration, X-as-a-Service, Facilitation)
Q: Jakie zalety udało się uzyskać?
A: Sporo dobrego, a w skrócie:
Większą efektywność zespołów.
Większą wartość produktową na każdym strumieniu biznesowym (stream-aligned teams).
Większą autonomię i samoorganizację zespołów.
Mniej hand-offów i zależności między zespołami.
Lepszą architekturę kodu i rozwiązań.
Jeśli zainteresował Cię ten temat i chcesz dowiedzieć się więcej, zostawiam dwa linki z którymi możesz się zapoznać - infografikę jak zacząć z Team Topologies a także link do Product-Cards.com - mojego newslettera, w którym poruszam kwestię budowania dobrych zespołów technicznych, między innymi z wykorzystaniem Team Topologies
Po takiej zachęcie, pora na praktykę. Zajmiemy się następującymi tematami:
Podział domeny biznesowej
Odwrotny manewr Conwaya
Topologie zespołów
Wdrażanie zmian organizacyjnych
Podział domeny biznesowej
Naszym pierwszym zadaniem jest podział domeny biznesowej (części rzeczywistości, którym zajmuje się aplikacja) na mniejsze części. Celem jest wydzielenie obszarów, które:
Skupią na jasno określonym celu biznesowym.
Będą zawierały w sobie kluczowe procesy
Umożliwią wprowadzanie zmian bez informowania obszarów zewnętrznych.
Będą łatwe do przypisania niezależnym zespołom
To pozwoli stworzyć architekturę systemu, która będzie dostosowana do obszarów biznesowych.
Do tej metody podziału świetnie sprawdzają się metody tzw. strategicznego Domain-Driven Design.
Pierwszym krokiem jest ustrukturyzowanie procesów biznesowych tak, aby posiadały jasno wydzielone odpowiedzialności i wejścia / wyjścia. Chcemy zwizualizować i przedyskutować granice tych procesów, oraz to, w jaki sposób się łączą. Tutaj przydadzą się metody takie, jak:
Następnym działaniem, które powinniśmy podjąć jest podzielenie zgromadzonych procesów na poszczególne obszary biznesowe. Warto skupić się na zminimalizowaniu ilości przeskoków pomiędzy obszarami. Szukamy pojedynczych źródeł prawdy – tak, by kluczowa wiedza nie została rozpostarta na kilka obszarów.
W literaturze DDD ten krok nazywa się wydzieleniem subdomen.
Typowymi błędami są tutaj:
Skupienie na etapie procesu – procesy należące do różnych obszarów dzieją się na początku/końcu. Np. administracja produktem i jej zależność od procesów definiowania atrybutów i cen produktu.
Skupienie na rodzaju działań – działy posiadają współdzielone odpowiedzialności. Np. dział sprzedaży i dział reklamacji, a cross-działowa odpowiedzialność zarządzania dostępnością produktu.
Skupienie na przedmiocie, zamiast na działaniu – myślimy rzeczami, a nie zachowaniami. Np. produkty, a różne zachowania i potrzeby względem produktów.
Po wyznaczeniu obszarów biznesowych, pora skupić się na strukturze organizacyjnej.
Odwrotny manewr Conway’a
Prawo Conway’a ma istotny wpływ na nasze rozwiązanie. Z tego względu należy pracować wraz z nim, a nie działać mu na przekór. Na podstawie tej myśli narodził się zwrot ‘Inverse Conway Maneuver’, określony przez Jonny’ego LeRoya, konsultanta ThoughtWorks w następujący sposób:
“The ‘Inverse Conway Maneuver’ recommends evolving your team and organizational structure to promote your desired architecture.”
Czyli jeśli chcemy osiągnąć architekturę A-B-C w naszym produkcie, to powinniśmy promować strukturę organizacyjną A-B-C w naszej organizacji. Architektura systemu dostosuje swój kształt do struktury organizacyjnej.
W tym celu musimy zbudować zespoły, które nie są skupione wyłącznie na swoich własnych funkcjach. Tworzymy zespoły wielofunkcyjne (cross-functional), które opiekują się danymi obszarami, dbając o ich rozwój w systemie.
Dzięki temu pojedynczy zespół sprawniej i efektywniej zaadresuje problemy biznesowe danego obszaru, arozwiązanie techniczne będzie do niego dostosowane..
Oczywiście kształt osobowy poszczególnych zespołów musi być ustalony z dbałością o potrzeby konkretnych obszarów, przykładowo:
Więcej problemów po stronie przeglądarki = więcej UX i UI developerów.
Mocniejszy nacisk na kwestie po stronie platformy = więcej backend developerów.
Eksperymenty z nowymi technologiami – mieszanka różnych ról np. przez dodanie inżynierów ML do zespołu.
Tutaj jednak mogą pojawić się pytania:
Co, jeśli mam tylko jednego UXa w organizacji, a 5 obszarów do zaadresowania?
Czy każdy zespół musi mieć osobnego DevOpsa?
Kto obsługuje tematy pomiędzy obszarami?
Odpowiedzi możemy znaleźć aplikując wzorce topologii zespołów.
Topologie zespołów
Na początku warto podkreślić, że nie wszystkie zespoły muszą działać w ten sam sposób, ani skupiać się na tych samych celach.
Manuel Pais i Matthew Skelton w swojej książce Team Topologies 4 rodzaje zespołów i 3 modele współpracy, które możemy wykorzystywać w naszej organizacji.
Rodzaje zespołów:
Stream-aligned – skupiony na strumieniu wartości dostarczanej do klienta. Zwykle jest to pojedynczy zespół produktowy, który realizuje zdefiniowany cel biznesowy.
Enabling – ich zadaniem jest wspieranie pozostałych zespołów. Pracują jako konsultanci i trenerzy w ramach organizacji. Rozwiązują międzyzespołowe problemy i wdrażają nowe praktyki.
Complicated subsystem – skoncentrowany na rozwiązywaniu trudnego problemu biznesowego, który nie jest ściśle związany z pojedynczym strumieniem wartości.
Platform – mający za zadanie wypracowywać narzędzia, które są wykorzystywane przez zespoły wyższego poziomu. Częstych schematem jest tutaj na przykład zespół zajmujący się dostarczaniem narzędzi infrastrukturalnych.
Modele współpracy:
Collaboration – zespoły pracują ze sobą ściśle, realizując wspólny cel. Jest to podejście, dzięki któremu wymiana informacji jest szybka, a błędy naprawiane sprawnie. Jednocześnie trudno tutaj o wyskalowanie takiej współpracy.
X-as-a-service – zespoły współpracują na zasadzie klient-dostawca. Jeden zespół dostarcza narzędzia / API / biblioteki, a drugi z tego korzysta. Najbardziej efektywny model współpracy, jeśli kontrakt jest dobrze zdefiniowany i użyteczny dla odbiorcy.
Facilitating – jeden zespół pomaga się rozwinąć drugiemu, w określonym zakresie umiejętności, przez określony czas. Kiedy odbiorcy nabędą wiedzę, to eksperci migrują do kolejnego zespołu. Czasami eksperci są również zapraszani, aby rozwiązać trudny problem techniczny.
Co nam daje powyższe rozróżnienie? Trochę już sprzedał Piotr Kacała wyżej 😀
Przejdźmy przez to dokładniej.
Jeśli naszym celem jest skupienie się na nowym obszarze istniejącym pomiędzy dwoma obszarami, to:
Tworzymy nowy zespół z członków istniejących dwóch zespołów – zespół Stream-aligned.
Nowy zespół będzie początkowo blisko współpracował z obecnymi zespołami – model Collaboration.
Po pewnym czasie będziemy chcieli rozdzielić zespoły, aby nie było między nimi tak dużo komunikacji – model X-as-a-service.
Jeśli naszym celem jest wdrożenie nowej technologii, to:
Skupimy się na wydzieleniu zespołu ekspertów – zespół Enabling.
Zespół będzie pracował, ucząc danej technologii w ramach organizacji – model Facilitating.
Może również stworzyć podstawowe narzędzia, które będą udostępniane jako gotowe biblioteki – model X-as-a-Service.
Po osiągnięciu kompetencji przez organizację, eksperci dołączą do istniejących zespołów, a zespół ekspercki zostanie rozwiązany – zespół Stream-aligned.
Jakie są zalety tego typu rozwiązań? Posiadamy modele współpracy, które pozwalają nam dostosować się do zmiennych potrzeb biznesowych. Dzięki temu nasza struktura nie koncentruje się tylko na produktach. Możemy adresować różne potrzeby i wyjątkowe sytuacje.
Tylko jak teraz wdrażać takie zmiany, aby się przyjęły w organizacji? 🤔
Wdrażanie zmian organizacyjnych
Nikt nie lubi zmian organizacyjnych. Zwykle są przeprowadzane chaotycznie, bez przemyślenia dokładnych odpowiedzialności poszczególnych zespołów.
Jednak po wspólnym przejściu przez powyższe kroki, mamy za sobą 80% kluczowych analiz. Posiadamy zrozumienie obszarów biznesowych oraz wiedzę, jak powinien wyglądać docelowy kształt organizacji. Pozostaje nam jeszcze zaplanować migrację do docelowej struktury.
Najpierw należy zastanowić się w jaki sposób konkretny zespół ma zdobyć pracowników. W tym celu sugeruję wykorzystać techniki z książki Dynamic Reteaming autorstwa Heidi Helfand. Dostarcza ona wiedzy o różnych modelach restrukturyzacji:
Jeden po drugim — dodajemy pojedynczo pracowników do zespołu.
Powiększ i podziel — zespół powiększa się, a następnie dzieli na jeden lub więcej zespołów.
Łączenie — zespoły łączą się, tworząc większy zespół.
Izolacja – tworzymy zespół w separacji od pozostałych zespołów.
Wymiana — ktoś przechodzi (czasowo, lub tymczasowo) z jednego zespołu do drugiego.
Następnie można się zastanowić nad krokami migracji. Aby zrobić to możliwie najbardziej efektywnie, proponuję zastosować schemat z książki Switch: How to change things when change is hard. Lekko zmodyfikowany, wygląda następująco:
Rozpocznij od stanu początkowego – ztym rozpoczynasz migrację.
Określ stan docelowy – jaka jest docelowa struktura, do której dążysz? .
Zdefiniuj kroki migracji – tak, aby cały proces nie odbył się z dnia na dzień.
Zderz z odbiorcami – pozwól, aby pracownicy mogli zwalidować plan i wyrazić swoje uwagi.
Rozpocznij małymi krokami – sprawdzaj, jak idzie migracja, by móc szybko zareagować.
To są aspekty techniczne zmiany. Warto jednak pamiętać, że równocześnie zderzymy się z aspektem emocjonalnym zmiany. Je również można przewidzieć i należy odpowiednio zaadresować.
W tym pomaga krzywa zmiany od Kubler-Ross. Pokazuje ona czego i w jakim momencie pracownicy potrzebują z naszej strony.
Na początku skupiamy się najbardziej na czytelności przekazu. Następnie na motywacji i wsparciu. Ostatnim krokiem jest pokazywanie dobrych stron i dzielenie się wiedzą.
Oba aspekty są kluczowe dla powodzenia zmiany. Jeśli:
Skupimy się tylko na technikaliach – nasza zmiana będzie super zaplanowana, ale ludzie ją odrzucą.
Skupimy się tylko na emocjach – pracownicy przyjmą zmianę, ale jej wdrożenie będzie pasmem problemów i niepowodzeń.
Do tanga trzeba dwojga. 😉
Materiały
Powyższy tekst jest tylko pigułką wiedzy.
Jeśli chcesz dowiedzieć się wiecej, zachęcam do sięgnięcia po dodatkowe materiały, które przybliżą Ci omawiane tematy:
Prawo Conwaya w praktyce - https://radekmaziarka.pl/2019/02/25/conways-law-jak-struktura-organizacji-wplywa-na-osiagane-rezultaty/
Domain-driven Design and Team Topologies for Product-led Organizations - Nick Tune -
Podcast Better Software Design - O subdomenach biznesowych ze Sławkiem Sobótką - https://bettersoftwaredesign.pl/episodes/43
Ksiażka Team Topologies -
https://teamtopologies.com/
Książka Dynamic Reteaming - https://www.amazon.pl/Dynamic-Reteaming-Wisdom-Changing-Teams/dp/1492061298
Podsumowanie
Inżynierskie projektowanie organizacji pozwala na precyzyjne dostosowanie struktury organizacji do adresowanego problemu,co przekłada się później na architekturę produktu. W efekcie mniejsze zespoły szybciej rozwiązują złożone problemy.
Jak wygląda struktura w Twojej organizacji? Stawiacie na wielofunkcyjne zespoły, czy stare, dobre silosy?
🤦Cele → Możliwości → Rozwiązania
W kolejnym wydaniu wydaniu opowiadam o tym, jak sprawić by tworzone rozwiązania były ściśle połączone z celami organizacyjnymi: