Intencjonalny lider - Obserwacja otoczenia
Jak systematycznie zbierać informacje o zespole, żeby podejmować świadome decyzje liderskie
W poprzednim artykule Intencjonalny Lider - Pętla OODA przedstawiliśmy całościowy model działania lidera. Teraz czas zagłębić się w pierwszy element tej pętli - Observe.
Wobec czego nasuwa się pytanie...
Czym jest Observe?
W książce Science, Strategy and War opisano podejście Boyda do pętli OODA. Boyd, podkreślał, że skuteczne podejmowanie decyzji wymaga obserwacji z wielu perspektyw:
"We must be able to examine the world from a number of perspectives so that we can generate mental images or impressions that correspond to that world."
Obserwacja to pierwszy krok w pętli OODA. Bez dobrej obserwacji następne etapy - Orient, Decide, Act - będą oparte na błędnych założeniach. Jako lider nie możesz polegać tylko na jednym źródle informacji. Potrzebujesz wielu punktów widzenia, żeby zbudować pełny obraz rzeczywistości swojego zespołu.
Celem obserwacji jest rozumieć jak najlepiej nasze otoczenie i zbierać jak najszybciej informacje, by móc dostosowywać nasze działanie. Chodzi o to, żeby widzieć nie tylko to, co dzieje się na powierzchni, ale także ukryte wzorce, potencjalne problemy i możliwości rozwoju. Dzięki temu możesz wyprzedzać problemy zamiast tylko na nie reagować.
To jest oczywiście ciągły proces (stąd pętla), ale od czegoś trzeba rozpocząć.
Moje podejście do Observe
Przykłady u Johna Boyda są skupione na sferze wojennej. Nie do końca aplikuje się to do produktów cyfrowych 😅
Wobec czego wypracowałem 6 wymiarów obserwacji otoczenia zespołu produktowego:
Domenowy - co robimy
Organizacyjny - z kim robimy
Produktowy - dla kogo robimy
Techniczny - jakimi technologiami
Delivery - jakimi procesami
Zespołowy - jakie osoby mamy w zespole
Dla każdego wymiaru możesz wspomóc się materiałami:
Pytania - kierują naszą uwagę na kluczowe aspekty danego wymiaru. Zamiast zgadywać, zadajesz konkretne pytania, które odsłaniają sytuację zespołu. Dzięki nim nie przegapisz ważnych sygnałów.
Spektrum - sposób na zobrazowanie, gdzie znajduje się naszzespół w danym wymiarze. Nie wszystko jest binarne - często sytuacja jest gdzieś pośrodku. Spektrum pokazuje Ci zakres możliwości i pomaga zrozumieć, w którą stronę się kierować.
Nie musimy skupiać się na wszystkich wymiarach naraz. Jednak musimy wiedzieć, że obszar obserwacji istnieje, by ocenić go jako istotny - niektóre wymiary będą ważniejsze od innych.
Żeby jednak materiały miały wymiar praktyczny to warto je oprzeć o przykładową domenę. A nie ma bardziej przystępnej domeny niż ecommerce 🙃
Domena przykładowa - ecommerce
Wyobraźmy sobie firmę TechShop, która tworzy platformę ecommerce dla średnich przedsiębiorstw:
Firma istnieje od 5 lat i obsługuje około 200 sklepów internetowych w różnych branżach - od odzieży po elektronikę
Platforma oferuje kompletne rozwiązanie: zarządzanie produktami, obsługę płatności, system logistyczny i analitykę sprzedaży
W firmie pracuje kilka zespołów produktowych
W ramach tej domeny pracujesz w zespole odpowiedzialnym za "Checkout & Payments" - proces finalizacji zakupów i obsługi płatności:
To kluczowy obszar dla całej platformy, bo tu klienci podejmują ostateczną decyzję o zakupie
Zespół składa się z 7 osób: Product Managera, lidera zespołu (Ciebie) 4 programistów (frontend, backend, 2x fullstack) i QA
Odpowiadacie za cały proces od koszyka, przez wybór opcji dostawy, metod płatności, aż po potwierdzenie zamówienia
Skoro przykładową domenę mamy za sobą to przejdźmy do poszczególnych wymiarów obserwacji.
Wymiary obserwacji
Przejdźmy przez każdy wymiar i zobaczmy, jak zastosować go w praktyce.
Poniższy zbiór pytań i spektrum jest oczywiście do rozwinięcia - potraktuj go jako wstęp do twojego własnego narzędziownika 😊
Domenowy
Ten wymiar pomaga zrozumieć, w jakiej dziedzinie biznesowej działamy i jakie są kluczowe elementy tej domeny. Tutaj skupiamy się na mapowaniu poddomen, zrozumieniu ich dojrzałości i wartości biznesowej.
Pytania
Struktura domenowa
Jakie poddomeny składają się na naszą domenę główną?
Jak różnią się te poddomeny pod względem złożoności i stabilności?
Na jakim etapie ewolucji jest każda z poddomen np. 3X: Explore, Expand, Extract?
Jak dobrze zintegrowane są procesy między poddomenami?
Wartość biznesowa
Które poddomeny generują największą wartość biznesową?
Jak szybko rosną wymagania w każdej poddomenie?
Które części domeny są krytyczne dla działania całego produktu?
Jak silne są zależności biznesowe między subdomenami?
Spektrum
Przykład dla ecommerce
W przypadku zespołu "Checkout & Payments" widzimy, że nasza poddomena znajduje się w centrum platformy ecommerce. Składa się z kilku mniejszych obszarów: zarządzanie koszykiem, kalkulacja kosztów dostawy, integracja z operatorami płatności i potwierdzenie zamówienia.
Pod względem stabilności jesteśmy raczej ustabilizowani - podstawowe funkcje działają, ale ciągle dodajemy nowe metody płatności i opcje dostawy. Złożoność jest średnia do wysokiej ze względu na integracje z zewnętrznymi systemami płatności. Wartość biznesowa to absolutny priorytet - każdy błąd w checkout oznacza bezpośrednią stratę przychodów dla naszych klientów.
Organizacyjny
Ten wymiar pomaga zrozumieć, jak nasza domena funkcjonuje w kontekście całej organizacji i jakie są relacje z interesariuszami. Tutaj obserwujemy strukturę odpowiedzialności, autonomię zespołu i bliskość z biznesem.
Pytania
Struktura organizacyjna
Jak wygląda podział ról naszej domeny - czy mamy jednego głównego interesariusza czy kilku?
Jakie są główne zależności organizacyjne między naszym zespołem a innymi?
Czy jesteś zespołem produktowym z wpływem na roadmapę czy raczej feature factory?
Jak silny jest konflikt interesów między różnymi grupami interesariuszy?
Bliskość z biznesem
Jak blisko współpracujemy z kluczowymi interesariuszami?
Czy mamy bezpośredni dostęp do feedbacku od użytkowników końcowych?
Jak często zmieniają się priorytety i kto je ustala?
Jakie są główne wyzwania i ograniczenia organizacyjne?
Spektrum
Przykład odpowiedzi dla ecommerce
Mamy problem z rozproszonymi interesariuszami. Head of Product ustala jedne priorytety, ale Customer Success przychodzi z "pilnymi" prośbami od dużych klientów, które kłócą się z roadmapą. Dodatkowo zespół Logistics często zmienia wymagania dotyczące kalkulacji kosztów dostawy na ostatnią chwilę.
Jesteśmy gdzieś pomiędzy feature factory, a pełną decyzyjnością. Mamy wpływ na niektóre decyzje, ale często czujemy się jak wykonawcy cudzych pomysłów. Największym problemem organizacyjnym jest chaos w komunikacji - nie wiadomo kto podejmuje ostateczne decyzje o priorytetach i jak rozwiązywać konflikty między różnymi działami.
Produktowy
Ten wymiar pomaga zrozumieć, dla kogo robimy nasz produkt i jak mierzymy jego skuteczność. Tutaj skupiamy się na segmentach użytkowników, ich potrzebach i metrykach produktowych.
Pytania
Segmenty użytkowników
Kim są nasi główni użytkownicy i jak różnią się ich potrzeby?
Które segmenty użytkowników są dla nas najważniejsze biznesowo?
Jak dobrze rozumiemy ścieżki użytkowników (user journeys) w naszej domenie?
Jakie są główne problemy i frustracje naszych użytkowników?
Metryki i mierzenie
Jakie kluczowe metryki produktowe śledzimy i jak często?
Czy mamy dostęp do danych behawioralnych użytkowników?
Jak mierzymy sukces nowych funkcji i zmian?
Jakie mamy mechanizmy zbierania feedbacku od użytkowników?
Spektrum
Przykład odpowiedzi dla ecommerce
Rozumiemy podstawowe potrzeby użytkowników, ale brakuje nam głębszej wiedzy. Wiemy, że kupujący chcą szybkiego procesu, administratorzy elastyczności, ale nie wiemy dlaczego 15% użytkowników porzuca proces na etapie wyboru dostawy.
Brakuje nam bezpośredniego dostępu do danych - musimy prosić zespół Analytics o raporty z tygodniowym opóźnieniem. Feedback to głównie skargi przez Customer Success, nie mamy A/B testów. Podejmujemy decyzje na podstawie domysłów, a nie danych.
Techniczny
Ten wymiar pomaga zrozumieć stan techniczny systemu i możliwości dostarczania wartości. Tutaj badamy architekturę, dług techniczny i jakość rozwiązań technicznych.
Pytania
Architektura i struktura
Jak wygląda podział na systemy/serwisy i ich zależności?
Które części to legacy vs nowoczesne technologie?
Czy struktura techniczna odzwierciedla strukturę zespołów (prawo Conwaya)?
Jak dobrze zmodularyzowana jest architektura - czy możemy rozwijać części niezależnie?
Stan techniczny i jakość
Jaki jest poziom długu technicznego w różnych częściach systemu?
Jak wygląda pokrycie testami i automatyzacja?
Czy mamy monitoring, obserwowalność i alerting na produkcji?
Jak często występują błędy produkcyjne i jak szybko je naprawiamy?
Spektrum
Przykład odpowiedzi dla ecommerce
Pracujemy z mieszanką technologii. Frontend to React z TypeScript, backend to Node.js z PostgreSQL. Mamy mikrousługi dla płatności i jedną większą aplikację dla checkout. Legacy to stary system rabatów napisany w PHP sprzed 4 lat - kod bez testów, dokumentacji i z bardzo słabym monitoringiem.
W nowych częściach testy chronią nas przed regresją, ale stary system rabatów musimy testować ręcznie. Monitoring pokazuje tylko podstawowe błędy, brakuje alertingu biznesowego. Błędy produkcyjne zdarzają się co tydzień, głównie przez niestabilne integracje z operatorami płatności i brak retry mechanizmów w starym kodzie. Największym długiem technicznym jest system rabatów - refaktoring zajmie minimum 3 miesiące.
Delivery
Ten wymiar pomaga zrozumieć, jakimi procesami dostarczamy wartość i jak sprawnie funkcjonujemy jako zespół. Tutaj skupiamy się na cyklu dostarczania, automatyzacji i rytmie pracy.
Pytania
Proces dostarczania
Jak długo trwa cykl od pomysłu do produkcji?
Czy możemy wdrażać niezależnie w różnych domenach?
Jaki poziom automatyzacji mamy (testy, CI/CD)?
Czy istnieją feature flags i możliwość stopniowego rollout?
Rytm i planowanie
Jak wygląda nasz rytm pracy (sprinty, kanban, continuous flow)?
Jak planujemy i priorytetyzujemy zadania?
Czy mamy regularne retrospektywy i czy z nich wynikają zmiany?
Jak radzenie sobie z nieprzewidzianymi sytuacjami i bugami?
Spektrum
Przykład odpowiedzi dla ecommerce
Próbujemy pracować w 2-tygodniowych sprintach, ale ciągle coś nam przerywa rytm pracy. Od pomysłu do produkcji mija 3-4 sprinty przez problemy z testowaniem i długą procedurą wdrożeniową. Wdrażamy 1-2 razy w tygodniu, ale każde wdrożenie to stres.
CI/CD mamy tylko częściowo - testy uruchamiają się automatycznie, ale deployment wymaga manualnych kroków i często się wywala. Brak feature flags sprawia, że każda zmiana idzie od razu do wszystkich użytkowników. Retrospektywy robimy, ale zmiany wprowadzamy rzadko. Największym problemem są ciągłe przerywniki - "pilne" poprawki, które rujnują całe planowanie sprintów.
Zespołowy
Ten wymiar pomaga zrozumieć, jakie osoby tworzą zespół i jakie są ich kompetencje oraz potrzeby rozwojowe. Tutaj rozpoznajemy kompetencje, dynamikę zespołu i potrzeby rozwojowe.
Pytania
Kompetencje i doświadczenie
Jakie są kluczowe kompetencje członków zespołu i gdzie są luki?
Jak rozkładają się seniorzy vs juniorzy w zespole?
Czy mamy single points of failure w wiedzy lub umiejętnościach?
Jak dobrze zespół zna domenę biznesową, w której pracuje?
Dynamika zespołu
Jak długo członkowie zespołu ze sobą współpracują?
Jaka jest motywacja i zaangażowanie poszczególnych osób?
Czy są konflikty interpersonalne lub różnice w podejściu do pracy?
Jakie są indywidualne cele kariery i jak wpływają na pracę zespołu?
Spektrum
Przykład odpowiedzi dla ecommerce
Mamy doświadczony zespół - większość osób pracuje razem od 2 lat. Ja i senior backend developer świetnie znają domenę płatności, ale junior frontend developer dopiero uczy się biznesowych niuansów.
Zespół jest zmotywowany i autonomiczny - ludzie sami podejmują decyzje techniczne w swoich obszarach. Jedynym wyzwaniem jest różnica w tempie pracy między seniorem a juniorem, co czasem prowadzi do frustracji. Wszyscy chcą rozwijać się technicznie, QA rozważa przejście na automation testing.
Perspektywy innych osób
Boyd podkreślał wagę różnorodnych punktów widzenia w procesie obserwacji:
"We can't just look at our own personal experiences or use the same mental recipes over and over again"
O obserwacje dla wymiarów warto pytać inne osoby, by pokazywały swój punkt widzenia. Product Manager będzie inaczej postrzegał wymiar produktowy niż programista. Designer spojrzy na użytkowników z innej perspektywy niż QA Manager będzie miał inne obserwacje organizacyjne niż Tech Lead.
Kluczem jest zbieranie tych różnych perspektyw i konfrontowanie ich ze sobą. Tam gdzie widzisz stabilność, ktoś inny może dostrzec problemy. Tam gdzie ty widzisz wysoką jakość techniczną, Product Manager może widzieć powolne dostarczanie wartości.
Te różnice w postrzeganiu są cennym źródłem informacji - pokazują pełniejszy obraz rzeczywistości zespołu.
W kolejnym odcinku przeniesiemy nasze obserwacje na obszar Orient - naszego odniesienia się do zaobserwowanej sytuacji.