Jaka jest rola Tech Leada w Discovery?

W tym tygodniu rozpoczynamy kolejny mini cykl. Tym razem chciałbym przeprowadzić Cię przez kolejne obszary odpowiedzialności Tech Leada. Z tego, oraz kolejnych artykułów dowiesz się jak wszechstronna jest to rola, oraz co wchodzi w jej zakres. Rozpoczynamy od Discovery, następnie będzie Delivery i Maintenance.

Praca lidera w ramach Discovery

Dawniej 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:

If the first time your developers see an idea is at sprint planning, you have failed. We need to ensure the feasibility before we decide to build, not after. Not only does this end up saving a lot of wasted time, but it turns out that getting the engineer’s perspective earlier also tends to improve the solution itself, and it’s critical for shared learning.

Więc jeśli działania techniczne w ramach Discovery są kluczowe, to czym jest właściwie samo Discovery?

Czym jest Discovery

Opis 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:

• Zrozumienie problemu, jaki staramy się rozwiązać.

• Wypracowanie różnych rozwiązań do dobrze zrozumiałego problemu.

• Zweryfikowanie technologiczne i biznesowe tego, co chcemy zrealizować.

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:

• Wartości– Czy klienci to kupią?

• Użyteczności– Czy klienci będą wiedzieć jak z tego korzystać?

• Wykonalności– Czy wiemy, jak to zbudować?

• Rentowności biznesowej– Czy to faktycznie pomoże nam biznesowo?

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ów

Wydawał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:

• może nie być wykonalne,

• może być zbyt drogie w stosunku do zysków,

• może wcale nie adresować problemu danej osoby.

Świetnie to podsumowuje historia przytoczona w artykule Oskara Dudycza Bring me problems, not solutions:

In this situation, it turned out that the user’s ability to fill out their time sheets wasn’t the actual problem to solve. If we were to ask what the actual problem is, we might conclude that you may not need to create a new web application.

Tutaj mała porada na początek poszukiwań problemu - jeśli to co masz nie przekłada się nawet w luźny na:

• zarabianie więcej,

• oszczędzanie czasu.

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:

Niemal każdy dylemat ma co najmniej dwa rozwiązania: dobre i praktyczne. Najczęściej są one od siebie różne.

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:

• Dostępne technologie– która z nich jest faktycznie przetestowana, gotowa dla danego rozwiązania. Wykorzystanie zbyt młodej biblioteki do stabilnych procesów kończy się dużymi kosztami utrzymania.

• Zgodność z obecną architekturą i infrastrukturą– rozwiązanie musi pasować do tego, co mamy obecnie. Często samo rozwiązanie nie jest tak kosztowne, jak zmienianie wszystkiego dookoła.

• Atrybuty jakościowe– sprawdzamy, czy rozwiązanie spełni wymagania dotyczące danej potrzeby klienta pod względem wydajności, skalowalności, bezpieczeństwa. Rozwiązanie może wizualnie działać, ale jednocześnie nie spełniać wymagań jakościowych.

• Ścieżki graniczne– sprawdzamy, czy rozwiązanie poradzi sobie również z przypadkami szczególnymi. Osoby decyzyjne w biznesie zwykle myślą scenariuszami pozytywnymi, co ostatecznie kończy się dziesiątkami błędów na produkcji.

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ść biznesowa

Ten 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:

• dostarczenia,

• pracy operacyjnej.

Jest więc możliwe, że:

• Rozwiązanie będzie droższe w dostarczeniu niż ogólny zysk (koszt całego zespołu * liczba osobogodzin).

• Praca systemu całkowicie pochłonie wygenerowane zyski – np. infrastruktura wymagana do poprawnego działania będzie tak droga, że kompletnie nieopłacalna.

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 interesariuszy

Gdy już stworzymy pierwsze propozycje rozwiązania, do gry wkraczają dodatkowi interesariusze. Nie zawsze jest to tylko biznes. Często mogą to też być:

• Inne zespoły produktowe– modyfikujemy nasze API lubpotrzebujemy dodatkowych danych.

• SRE– musimy zmienić konfigurację infrastruktury w niestandardowy sposób.

• Dział bezpieczeństwa– dotykamy obszarów wrażliwych, które wymagają specjalnych dostępów.

• Dział prawny– modyfikujemy dane w nietypowy sposób, importujemy dodatkowe do systemu.

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ł prac

Na 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:

• Frontend, backend

  • Interfejsy

  • Logika biznesowa

  • Połączenia do serwisów zew.

  • Struktura bazy

  • Porządkowanie, refactoring

• Infrastruktura

• CI/CD

• Data - metryki

• Observability - logi, tablice

• Testy

• Migracje ze starej wersji

Zagadnienia procesowo-organizacyjne:

• Dalsze analizy

• Ryzyka i ich walidacje

• Tematy prawne

• Ustalenia z innymi zespołami / spotkania

• Dostęp do API i testowanie

Jak widzisz, jest całkiem sporo rzeczy, o których można pomyśleć. 🤔

Określenie zależności zewnętrznych

Kiedy 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:

• Poinformowanie osób zależnych o przyszłej pracy.

• Kalkulację czy w ogóle uda się to w danej iteracji przeprowadzić.

Bez tych informacji zostaniemy podczas Delivery jak dzieci we mgle.

Informowanie o ryzyku

Mał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:

• Koszt poświęcony w fazie Discovery na analizę.

• Koszt poświęcony w fazie Delivery na opóźnienia, dogrywanie tematów, rework.

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:

• Określ główne ryzyka projektowe.

• Ułóż je według priorytetów, szansy wystąpienia i mocy rażenia.

• Projektuj rozwiązanie tak, aby odpowiadało na główne ryzyka i je zmniejszało.

• Zakończ projektowanie, kiedy koszt zmniejszania ryzyka jest wyższy niż jego akceptacja.

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!