🗺️ Projektowanie organizacji2023-06-07Cześć! Witaj w drugim odcinku cyklu praktyk inżynierskich najlepszych firm produktowych. Dzisiaj na tapet bierzemy: Projektowanie organizacji A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 🗺️ Projektowanie organizacjiGdy silosy projektują nam systemSą 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ć?
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:
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 organizacjiPrzed 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:
Tylko wtedy zbudujemy zespoły, które będą:
To oczywiście przełoży się na bardziej zyskowny produkt 🤑 Przykład z branżyPraktycznym przykładem z wykorzystania wzorców dookoła tematyki domain-driven designu i Team Topologies podzielił się Piotr Kacała, CTO firmy Displate.
Po takiej zachęcie, pora na praktykę. Zajmiemy się następującymi tematami:
Podział domeny biznesowejNaszym 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:
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:
Po wyznaczeniu obszarów biznesowych, pora skupić się na strukturze organizacyjnej. Odwrotny manewr Conway’aPrawo 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:
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:
Tutaj jednak mogą pojawić się pytania:
Odpowiedzi możemy znaleźć aplikując wzorce topologii zespołów. Topologie zespołówNa 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:
Modele współpracy:
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:
Jeśli naszym celem jest wdrożenie nowej technologii, to:
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 organizacyjnychNikt nie lubi zmian organizacyjnych. Zwykle są przeprowadzane chaotycznie, bez przemyślenia dokładnych odpowiedzialności poszczególnych zespołów.
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:
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:
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:
Do tanga trzeba dwojga. 😉 MateriałyPowyż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:
PodsumowanieInż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? 🤦Postmortem - poprzedni odcinekW poprzednim odcinku opowiadałem o praktykach i kulturze Postmortem. Jeśli interesuje Ciebie ten temat to zachęcam do spojrzenia do artykułu. Domyślnie wszystkie artykuły będą dostępne online, jak tylko je napiszę. 😃 📧 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 :) |
