Strategia inżynierska zespołów produktowych
Jak wyznaczyć kierunek działań technicznych, aby zaadresować kluczowe wyzwania.
Strategia inżynierska to temat, o którym rzadko się mówi w zespołach produktowych.
Warto przyjrzeć się jej bliżej, gdyż ma bezpośredni wpływ na efektywność organizacji.
Po co mi strategia
W zespołach produktowych codzienność zdominowana jest dostarczaniem kolejnych funkcji, naprawianiem błędów i wdrażaniem zmian.
W natłoku operacyjnych zadań nie zastanawiamy się nad szerszym kontekstem naszych decyzji technicznych. Nie wiemy nawet, że coś takiego jak strategia inżynierska może nam pomóc uporządkować chaos i nadać kierunek naszym działaniom.
Na co wpływa brak uporządkowanej strategii?
Zespoły tracą czas na powtarzające się dyskusje techniczne zamiast skupić się na dostarczaniu wartości.
Decyzje technologiczne są podejmowane ad-hoc, bez spójnej wizji.
Nowe projekty powstają w różnych technologiach, utrudniając późniejsze utrzymanie.
Trudno przekonać interesariuszy do inwestycji w aspekty techniczne
Nowe osoby muszą metodą prób i błędów poznawać 'jak tu się rzeczy robi'
Co ciekawe, nawet jeśli myślisz, że nie masz strategii, to i tak ją masz. Decyzje, które podejmujesz jako lider techniczny, każdy wybór narzędzia czy technologii – to wszystko bazuje na jakiejś strategii. Pytanie na ile ona jest spójna, oraz zrozumiała dla szerszego zespołu.
Czym jest strategia
Zanim pójdziemy dalej, warto określić czym właściwie jest strategia inżynierska.
Richard Rumelt w swojej książce "Good Strategy, Bad Strategy" definiuje ją następująco:
Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.
Przekładając to na nasz obszar inżynierski - strategia polega na identyfikacji i rozwiązaniu kluczowego problemu technicznego, który blokuje rozwój produktu. Właściwie wybrany i rozwiązany problem prowadzi do kaskadowej poprawy w wielu obszarach technicznych i biznesowych. Skuteczna strategia koncentruje zasoby zespołu na tym właśnie krytycznym elemencie.
Jak opisywałem w newsletterze o Celach -> Możliwościach -> Rozwiązaniach, skupienie się jest kluczowe by faktycznie coś osiągnąć 😉
Wg. Rumelta strategia składa się z trzech głównych elementów, które poniżej opiszę na przykładach:
Diagnosis (diagnoza) - zrozumienie obecnej sytuacji i wyzwań.
Guiding policy (Kluczowe podejście) - określenie jak zamierzamy rozwiązać zidentyfikowane problemy.
Coherent actions (Zbiór spójnych działań) - konkretnye kroki, które podejmujemy by wdrożyć nasze rozwiązanie.
Warto zaznaczyć, że strategia inżynieryjna nie powstaje w próżni. Zespół inżynierski jest częścią większej organizacji, która ma swoje cele biznesowe. Nasza strategia musi więc wspierać te cele - nie możemy skupiać się tylko na aspektach technicznych, ignorując biznesową wartość naszych działań.
Od czego rozpoczynamy? Od diagnozy!
Diagnosis
Pracę nad strategią nie rozpoczynamy od działania, a raczej od analizy tego co dookoła.
A great deal of strategy work is trying to figure out what is going on. Not just deciding what to do, but the more fundamental problem of comprehending the situation. At a minimum, a diagnosis names or classifies the situation, linking facts into patterns and suggesting that more attention be paid to some issues and less to others.
Pierwszym krokiem w budowie strategii jest dobra diagnoza - zrozumienie sytuacji, w której się znajdujemy. Nie chodzi tu o proste wylistowanie problemów, ale o głębsze zrozumienie wzorców i powiązań pomiędzy nimi.
W przypadku produktów cyfrowych musimy spojrzeć naprawdę szeroko. Źródła informacji do naszej diagnozy to:
Analiza celów biznesowych i produktowych - na czym zależy naszym interesariuszom (Cele -> Możliwości -> Rozwiązania)
Otoczenie biznesowe - czy działamy w środowisku regulowanym, jaki wielu klientów posiadamy, czy to jest B2B czy B2C
Struktura produktu - jak podzielony jest produkt na mniejsze obszary (Projektowanie organizacji)
Dojrzałość techniczna - metryki DORA, obserwowalność (Obserwowalność)
Funkcje biznesowe - obecne i przyszłe rozwiązania na roadmapie, zależności między nimi
Ludzie - skład zespołu, wiedza techniczna, jak współpracują ze sobą
Infrastruktura - stabilność środowisk, koszty utrzymania, skalowalność
Wskaźniki jakościowe - wydajność, niezawodność (Drivery architektoniczne)
Na podstawie zebranych informacji musimy zidentyfikować kluczowe problemy i wyzwania. Jednak, jak zauważa Rumelt:
Because the challenge was ill-structured, a real-world strategy could not be logically deduced from the observed facts.
Nie wystarczy więc proste ocenienie ryzyk w skali 1-5 i wybranie tego z najniższą oceną. Musimy aktywnie zdecydować, który problem jest dla nas najważniejszy i będzie miał największy wpływ na sukces produktu.
Przykład diagnozy
Przyjrzyjmy się przykładowi startupu rolniczego, który chce udostępniać rolnikom dane ze stacji pogodowych. System ma agregować i analizować informacje z wielu źródeł, by dostarczać rekomendacje upraw.
Zbierając informacje do diagnozy, zauważamy:
Wymagania skalowalności:
Kilkadziesiąt tysięcy odczytów ze stacji na początku każdej godziny.
Nocne przetwarzanie danych i generowanie wykresów.
Masowa wysyłka maili do klientów.
Bardzo skokowe obciążenie - od 0 do 10000 odczytów w ciągu 5 minut i znów 0.
Ograniczone zasoby:
Startup w początkowej fazie wzorstu z ograniczonym budżetem.
Brak dedykowanego zespołu Ops.
Konieczność optymalizacji kosztów infrastruktury.
Zespół techniczny:
4-osobowy zespół developerski.
Doświadczenie głównie w aplikacjach monolitycznych.
Niewielka wiedza na temat rozwiązań chmurowych.
Brak doświadczenia w przetwarzaniu dużych wolumenów danych.
Stan obecny:
Wszystko hostowane na pojedynczym VPSie.
Problemy z wydajnością w godzinach szczytu.
Brak automatycznego skalowania.
Ręczne procesy deploymentu.
Otoczenie biznesowe:
Firma-matka ma podpisane umowy z Microsoftem.
Klienci wymagają wysokiej dostępności danych.
Planowana ekspansja na rynki zagraniczne.
Presja czasowa:
4 miesiące do startu w kolejnym sezonie.
Główne wyzwanie staje się jasne:
jak zbudować rozwiązanie na tyle solidne technicznie, by było gotowe na szybki wzrost skali,
jednocześnie na tyle optymalne kosztowo, by startup mógł je efektywnie utrzymywać przy obecnej liczbie klientów.
Potrzebujemy infrastruktury, która pozwoli nam płynnie rosnąć wraz z biznesem, bez konieczności rewolucyjnych zmian architektonicznych w przyszłości.
Guiding Policy
Po diagnozie sytuacji, musimy określić kierunek naszych działań. To właśnie jest tzw. Guiding Policy - metoda, która pomoże nam rozwiązać zidentyfikowane problemy. Jak pisze Rumelt:
A guiding policy creates advantage by anticipating the actions and reactions of others, by reducing the complexity and ambiguity in the situation, by exploiting the leverage inherent in concentrating effort on a pivotal or decisive aspect of the situation, and by creating policies and actions that are coherent, each building on the other rather than canceling one another out.
Dobra metoda redukuje złożoność problemu i wskazuje, na czym powinniśmy się skupić.
W kontekście produktów cyfrowych może to być:
Skupienie technologiczne - wykorzystania konkretnego stosu technologicznego.
Alokacja zasobów - przesunięcie ludzi pomiędzy zespołami, aby realizowali konkretne rozwiązania.
Procesy pracy - zmiana podejścia do dostarczania.
Wymagana jakość - skupienie na konkretnych atrybutach jakościowych.
Dług technologiczny - świadome poświęcenie określonych aspektów systemu.
Partnerstwo - współpraca z zewnętrznymi dostawcami.
Poziom autonomii - określenie samodzielności zespołów.
Okrojenie funkcjonalne - zrezygnowanie z części funkcji rozwiązań z planu.
Kluczowe jest to, by nie wybierać pierwszego rozwiązania, które przychodzi nam do głowy. Trzeba wypracować kilka potencjalnych kierunków działania. Każdy z nich niesie ze sobą pewne kompromisy - musimy je zrozumieć i świadomie wybrać te, na które jesteśmy gotowi pójść.
W ramach wyboru kierunku warto rozważyć:
Jak potwierdzimy, że działa, że faktycznie rozwiązujemy problem? Aby szybko zebrać feedback, zamiast czekać miesiącami.
Co jest kompromisem? Jakie problemy musimy zaakceptować? Aby świadomie podjąć decyzje o wadach i konsekwencjach.
Które aspekty są dla nas kluczowe, a które drugorzędne.
Podobnie jak w przypadku analizy wymagań (o czym pisałem w Cele -> Możliwości -> Rozwiązania), musimy zdecydować na czym się skupiamy. Nie da się zoptymalizować wszystkiego naraz.
Przykład kierunków działania
Wróćmy do naszego startupu rolniczego. Możemy rozważyć kilka kierunków:
Dotychczasowe technologie na klasycznych VPSach:
Własne serwery z tradycyjnym stosem technologicznym.
Potwierdzenie: Szybkie wdrożenie prototypu na 2-3 serwerach.
Kompromisy:
Sami musimy zarządzać skalowaniem
Płacimy za serwery 24/7, nawet gdy nie są używane
Wysokie koszty przy większej skali
Brak wbudowanych narzędzi do analityki
Outsourcing całej infrastruktury:
Zewnętrzny partner zarządza hostingiem i skalowaniem.
Potwierdzenie: Pilotaż z małym zbiorem danych na 2 tygodnie.
Kompromisy:
Wyższe koszty miesięczne
Zależność od zewnętrznego dostawcy
Mniej kontroli nad architekturą
Trudniejsza zmiana kierunku w przyszłości
Azure i rozwiązania serverless:
Wykorzystanie chmury i automatycznego skalowania funkcji Azure.
Potwierdzenie: Proof of concept z kilkoma funkcjami i testami wydajności + kosztów.
Kompromisy:
Dłuższy czas na naukę technologii
Vendor lock-in na rozwiązania Microsoftu
Trudniejsze debugowanie rozproszonego systemu
Wyższe koszty przy stałym obciążeniu
Po analizie wybrano Azure - głównie ze względu na:
Płatność za faktyczne wykorzystanie przy mocno zmiennym obciążeniu.
Wbudowane narzędzia do przetwarzania danych.
Istniejące umowy z Microsoftem - szybki start.
Coherent Actions
Strategia musi przekładać się na konkretne działania. Jak pisze Rumelt:
Many people call the guiding policy "the strategy" and stop there. This is a mistake. Strategy is about action, about doing something. The kernel of a strategy must contain action.
Wdrażanie strategii wymaga skoordynowanych działań na wielu poziomach. Nie mogą być one przypadkowe - muszą się wzajemnie wspierać i prowadzić do celu.
Aby sobie pomóc, w ramach spójnych akcji można wykorzystać podział z artykułu Writing an engineering strategy Willa Larsona:
Egzekwowanie - jak będziemy utrzymywać spójność z wybranym kierunkiem? Bez jasnych zasad nawet najlepsza strategia pozostanie tylko na papierze.
Automatyzacja sprawdzania zgodności
Regularne przeglądy odstępstw
Audyty wdrożonych rozwiązań
Mierzenie postępu zmian
Eskalacje - jak usprawniamy obrany kierunek? Konstruktywny feedback pomoże nam wyłapać problemy, zanim staną się krytyczne.
Dedykowane kanały komunikacji
Cykliczne spotkania przeglądowe
Ustalony proces eskalacji
System proponowania zmian
Przejścia - jak przechodzimy do nowego stanu? Zmiana musi być przeprowadzona w sposób kontrolowany i bezpieczny.
Plan migracji z jasno zdefiniowanymi krokami
Ograniczenie liczby równoległych zmian
Regularna synchronizacja postępów
Jasne kryteria sukcesu
Te działania muszą się wzajemnie wspierać, jak podkreśla Rumelt:
The actions should be coherent - consistent and coordinated. The coordination of action provides the most basic source of leverage or advantage available in strategy.
Przykład spójnych kroków
Po wyborze Azure jako kierunku działania, musimy zaplanować konkretne kroki. Przede wszystkim, potrzebujemy upewnić się, że nasz zespół jest gotowy na taką zmianę technologiczną i organizacyjną. Wdrażanie rozpoczynamy od fundamentów.
Egzekwowanie:
Przeprowadzimy testy PoC by zmierzyć wydajność rozwiązania.
Ustalimy budżet dla pierwszych wdrożeń.
Stworzymy standardy pisania funkcji serverless.
Eskalacje:
Będziemy spotykać się co tydzień by omawiać postępy.
Ustalimy proces podnoszenia krytycznych problemów.
Wyznaczymy osoby odpowiedzialne za komunikację z partnerem.
Przejścia:
Przeprowadzimy cykl szkoleń Azure dla całego zespołu.
Przeniesiemy komponenty do chmury według ustalonego harmonogramu.
Przeanalizujemy wymagania wydajnościowe dla każdej funkcji.
Te działania wspierają nasz kierunek - Azure z serverless, prowadząc do coraz bardziej efektywnego wykorzystania chmury.
Podsumowanie
To tylko wprowadzenie do tematu strategii inżynierskiej. Wiele istotnych aspektów, takich jak mierzenie sukcesu strategii, najczęstsze pułapki czy rola zespołu w jej tworzeniu i realizacji, zasługuje na osobne omówienie.
Zachęcam do zgłębienia tych tematów w poniższych materiałach:
Książka Good Strategy, Bad Strategy - Richard Rumelt
Zbiór artykułów o Engineering Strategy - Will Larson
Zbiór artykułów Designing an Engineering Strategy - Aleix Morgadas
Artykuł Strategy basics - Alex Ewerlof