Jaka jest rola Tech Leada w Discovery?2024-02-24Cześć! W tym tygodniu rozpoczynamy kolejny mini cykl. Tym razem chciałbym przeprowadzić Cię przez kolejne obszary odpowiedzialności Tech Leada. Z tego, oraz kolejnych maili dowiesz się jak wszechstronna jest to rola, oraz co wchodzi w jej zakres. Rozpoczynamy od Discovery, następnie będzie Delivery i Maintenance. Dodatkowo przygotowałem dla Ciebie małą zajawkę najbliższego szkolenia oraz Inżynierską prasówkę z 5 najświeższymi materiałami z branży. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaTen tydzień rozpoczynamy od mocnego wywiadu dwóch legend z obszaru Engineering Managementu. A co dalej? Czytaj poniżej👇
Szkolenie Tech Lead – 8 kwietniaNa początku kwietnia spotykamy w ramach kolejnej edycji szkolenia Tech Lead. To świetna okazja dla:
Dzięki szkoleniu nabierzesz umiejętności, które pozwolą Ci prowadzić pracę techniczną zespołu produktowego. Szkolenie składa się z 5 sesji po 4 godziny:
A jeśli ten termin Ci nie pasuje, to daj znać – przy kolejnym terminie pierwszy dostaniesz zapytanie o wybór terminu. Praca lidera w ramach DiscoveryDawniej praca w obszarze Discovery dla ról technicznych nie istniała. Praca wpadała na backlog sprintowy zespołu. Lider ewentualnie zarządzał dostarczeniem. Same zadania za to wykonywały inne zespoły, czy nawet inne firmy. Dużo zmieniło się jednak w procesie rewolucji produktowej, która przyszła ze Stanów. Zauważono, że wciągniecie inżynierów w proces discovery zdecydowanie usprawnia cały proces rozwoju produktów. Jak to pisał Marty Cagan:
Więc jeśli działania techniczne w ramach Discovery są kluczowe, to czym jest właściwie samo Discovery? Czym jest DiscoveryOpis procesu najłatwiej zacząć od graficznej wizualizacji. Świetny przykład dostarcza tutaj Aktia Solutions w swoim artykule Product Discovery Framework:
Można powiedzieć, że Discovery to nadanie ram i struktury procesowi, który zwykle był, owszem, realizowany, ale bardzo chaotycznie. Celem Discovery jest:
Discovery ma na celu minimalizację ryzyka budowania produktu, który nie spełnia oczekiwań rynku lub jest technicznie niewykonalny. Aby tę definicję poszerzyć, można znów nawiązać do Martiego Cagana i jego 4 ryzyk:
Praca w Discovery jest mocno produktowa, analityczna, ux’owa, ale również i techniczna. I to o tej ostatniej odsłonie, dzisiaj będziemy mówić najwięcej, jako o odpowiedzialności Tech Leada.
Potrzeby klientówWydawałoby się, że ten aspekt nie należy do zakresu odpowiedzialności Tech Leada. Nic bardziej mylnego. Mamy tutaj naprawdę dużo do powiedzenia. Aby zaproponować sensowne rozwiązanie, potrzebujemy najpierw poznać głębsze potrzeby naszych klientów. Problem w tym, że nierzadko klienci nie przychodzą do nas z problemami. Przychodzą od razu z gotowymi rozwiązaniami. A to naraża nas na dużo problemów – dane rozwiązanie:
Świetnie to podsumowuje historia przytoczona w artykule Oskara Dudycza Bring me problems, not solutions:
Tutaj mała porada na początek poszukiwań problemu - jeśli to co masz nie przekłada się nawet w luźny na:
To znaczy, że dalej masz rozwiązanie, nie problem. I musisz kopać głębiej. Pomiędzy potrzebami, a analizą rozwiązań, jest zwykle jeszcze potwierdzanie potrzeb klientów. Tym jednak w 95% przypadków nie zajmie się lider techniczny. Dlatego zakładam, że mamy dobrze zrozumiałą i potwierdzoną potrzebę i przechodzimy dalej do… Analiza rozwiązańWiemy już, co rozwiązujemy. Naturalnie więc w kolejnym kroku chcemy zdefiniować potencjalne rozwiązania. Jeśli dobrze określiliśmy problem, to powinno dać się zaproponować więcej niż jedno (przynajmniej dla części problemu). Dlaczego? Posiadanie tylko jednego rozwiązania jest często wskaźnikiem, że wychodzimy od rozwiązania, a nie potrzeby. Warto mieć z tyłu głowy poradę od Michała Bartyzela z Dwie zasady skutecznego rozwiązywania problemów:
Dla wybranych rozwiązań lider techniczny zarządza analizą dwóch obszarów ryzyka: Wykonalności i Rentowności biznesowej. WykonalnośćW ramach wykonalności sprawdzamy, czy rozwiązanie wzięte do docelowego Delivery, nie stworzy dużych problemów. To co warto określić, to:
W tym momencie lider techniczny nierzadko powinien przeprowadzić dodatkowe Spike i Proof of Concepts, aby potwierdzić, czy rozwiązanie nie zaniedba żadnego z powyższych problemów. Rentowność biznesowaTen punkt może Cię zdziwić – co ja mam wspólnego z tym, czy biznes zarabia? Otóż okazuje się, że całkiem sporo. Rozwiązania są kosztowne pod względem:
Jest więc możliwe, że:
Tutaj również warto przeprowadzić Proof of Concept, ale już w innym celu – nie chcemy potwierdzać czy coś się da zbudować, ale czy to jest sens budować. Inny problem i inne podejście. Aby odpowiednio zarządzać tym ryzykiem, musimy pracować ramię w ramię z biznesem. Bez biznesu nie rozumiemy, jak się rozkładają zyski, a bez osób technicznych biznes nie pojmie dokładnej struktury kosztów. Wymagania interesariuszyGdy już stworzymy pierwsze propozycje rozwiązania, do gry wkraczają dodatkowi interesariusze. Nie zawsze jest to tylko biznes. Często mogą to też być:
W takiej sytuacji to lider techniczny musi wziąć na siebie karb obowiązków synchronizacji z takimi interesariuszami. Nieodpowiednio zarządzani, interesariusze potrafią wbić stopę w drzwi i wstrzymać całe wdrożenie gotowego produktu. Podział pracNa początku zaznaczam, że ten aspekt nie zawsze jest częścią Discovery. Uważam jednak, że warto poświęcić mu przynajmniej godzinkę, gdy już mamy docelowe rozwiązanie. Dobrą metaforą dla podziału prac jest Work Breakdown Structure, znany ze świata budowlanego:
Chcemy więc wydzielić mniejsze zadania, tak, by dało się określić zakres prac i potencjalnie je zrównoleglić. Co można tak wydzielić? Zagadnienia techniczne:
Zagadnienia procesowo-organizacyjne:
Jak widzisz, jest całkiem sporo rzeczy, o których można pomyśleć. 🤔 Określenie zależności zewnętrznychKiedy podzielisz dane zadanie bardziej dokładnie, zauważysz coś ciekawego – część zadań nie zależy bezpośrednio od Ciebie. Czasami wymagana jest praca od innego zespołu produktowego, działu, managera itd. Taką informację warto w ramach danego zadania gdzieś zanotować, bo wczesne rozpoznanie tych zależności pozwala na:
Bez tych informacji zostaniemy podczas Delivery jak dzieci we mgle. Informowanie o ryzykuMałe zadania mają tę zaletę, że łatwiej w nich widać co się może nie udać. I z tą informacją można zrobić coś wspaniałego – poinformować uprzednio zespół, że takie ryzyko istnieje. Zwykle na tym etapie nie chcesz wchodzić głębiej w dane rozwiązanie. Jednocześnie informacja o ryzyku pozwoli lepiej zaplanować dalszą pracę, aby próbować je zmitygować. A jeśli samo ryzyko się zmaterializuje, zespół będzie na to już przygotowany. Czasem do takiej analizy ryzyka można wykorzystać narzędzia dookoła Risk Stormingu:
Jednocześnie zwykle już sam podział zadań pozwala zauważyć najważniejsze obszary ryzyka. Kiedy Discovery jest „good enough"?Discovery można przeciągać w nieskończoność, nie rozpoczynając Delivery. Nie o to nam chodzi. Jako lider techniczny musisz brać pod uwagę dwie zmienne:
Wyważenie tego jest trudne i nie zawsze Ci się w 100% powiedzie. Co nie znaczy, że złoty środek nie istnieje. W tym aspekcie mogę polecić podejście z książki Just Enough Software Architecture: A Risk-Driven Approach, które można streścić następująco:
Nie musisz zaprojektować i przewidzieć wszystkiego. Ale jakieś ryzyka warto byłoby zmitygować 😉 A jak ty pracujesz w Discovery?Powyżej starałem się przystępnie streścić moje spojrzenie na Discovery. Ale nie wykluczam, że o czymś zapomniałem. 😅 Wiesz, o czym? Daj znać odpowiadając na tego maila! 📧 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 :) |
