Jaka jest rola Tech Leada po wdrożeniu?2024-04-20Cześć! W dzisiejszym odcinku chciałbym Ci przedstawić odpowiedzialności lidera technicznego, kiedy rozwiązanie jest już na produkcji. Okazuje się, że tam również czeka na Ciebie praca 😃 Jak zwykle mam również dla Ciebie parę ciekawych materiałów z ostatnich tygodni. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaRozpocznijmy tym razem od krótkiej autopromocji – podcastu wokół liderstwa technicznego. Następnie przejdziemy przez szeroki wachlarz tematów: od BDD i serverless, po architekturę Reddita.
Nad czym pracuje Tech Lead po wdrożeniu?Wrzuciłem swoje rozwiązanie na produkcję. Uruchomiłem i działa. Czym mój trud skończony? Niestety bycie liderem technicznym to nie żywot łotewskiego chłopa. Tutaj praca się nie kończy 😃 Najciekawsze zaczyna się właśnie na produkcji. Jako liderzy mamy tu spory zakres odpowiedzialności, które dotyczą zarówno utrzymania naszego produktu jak i procesów dookoła. Dopiero taka praca nad produktem pozwala osiągać długofalowe zyski dla nas i organizacji. Dobrze opisują to słowa z książki Software Engineering at Google:
Większość problemów (ale też dobrych praktyk) przynosi efekty dopiero po dłuższym czasie. Tylko wtedy widać jak nasza praca procentuje, lub powoduje, że produkt upada. Przejdźmy więc przez 5 odpowiedzialności, jakie ma lider w ramach pracy nad swoim produktem. Rozpoczniemy od chyba najważniejszej – obserwowalności. Obserwowanie produkcjiJeśli dobrze wykonałeś swoją pracę, to twój zespół w ramach rozwiązania wbudował również obserwowalność. Ale uważaj, bo samo posiadanie funkcji obserwowalności nie sprawia, że obserwujemy produkt 😉 Wskaźniki jakie warto obserwowaćW gąszczu różnych danych, metryk i wskaźników łatwo poczuć się zagubionym. Jako lider zwróć więc uwagę by najpierw wybrać te kluczowe tak, by zespół wiedział na co zwracać uwagę. Wybierając to, co obserwować warto rozpocząć dyskusję od:
Na miary możemy patrzeć zarówno od strony biznesowej, jak i technicznej – oto kilka propozycji, co obserwować:
Dobrze wybrane miary potrafią znacząco obniżyć złożoność operacyjną samego produktu. A dzięki temu staną się przydatne zarówno dla zespołu, jak i jego interesariuszy. Cykliczne sprawdzanie wskaźnikówProblemem w pracy z obserwowalnością może być nie tyle Co, ale Kiedy. Zespół może nie wiedzieć kiedy sprawdzać i w efekcie nie będzie tego robić w ogóle. (Przynajmniej na początku) Dobrą praktyką jest posiadanie ustalonego zespołowo etapu pracy, poświęconego na metryki. Przykładowo zespół po każdym daily może sprawdzać, jak zachowuje się produkt. Ocenia, czy nie ma żadnych odstępstw od normy, czy coś się nie psuje. Coś podobnego tylko w większej skali rekomendował Amazon z swoim Weekly Business Review. Zwiększanie zasobów wiedzyZadaj sobie pytanie:
Warto dbać o równomierny rozwój umiejętności wykorzystywania narzędzi dookoła obserwowalności. To, że my je znamy, nie znaczy, że zespół i interesariusze są ich świadomi. O tym warto pamiętać podczas szerzenia wiedzy:
Powyższe praktyki obserwowalności pozwolą zdecydowanie zredukować koszty dookoła kolejnego obszaru.
Procesy utrzymanioweNikt nie lubi utrzymywać, każdy chciałby robić nowe. A jednak nie da się mieć produktu, który nie wymaga żadnej pracy utrzymaniowej. Co można rozumieć jako pracę utrzymaniową? Spójrz na poniższy schemat:
Na potrzeby tego newsletteru załóżmy, że utrzymanie to wszystko co nie mieści się w definicji Planned/Functional. Możesz jeszcze wnioskować, że Planned/Non-Functional to też jest praca produktowa, a nie utrzymaniowa – nie będę kruszyć kopii. 😉 Produkt, w którym utrzymanie jest robione ad-hoc potrafi angażować bardzo mocno cały zespół i dezorganizować pracę. Dlatego też pierwszym obowiązkiem lidera jest uporządkowanie tego tematu. Zarządzanie utrzymaniemPracą utrzymaniową trzeba zarządzać tak, jak pracą funkcjonalną. To, o co warto zadbać w ramach samej pracy:
Jeśli otrzymujemy zgłoszenia zewnętrzne to warto też zadbać o, to jak reagujemy na dane zgłoszenie:
Ostatnia kwestia jest najtrudniejsza, bo jeśli ktoś zgłasza problem, to zawsze będzie on najbardziej pilny. 🤣 Co wtedy robić? Wpływ na produktJeśli chcemy dobrze ocenić priorytet zewnętrznego zgłoszenia to musimy mieć do tego odpowiednie narzędzie. Takim narzędziem może być wpływ na produkt. Jednak by było to dobrze zrozumiane przez zespół, warto najpierw zadbać o kategoryzację. Jako lider musisz umiejętnie zdefiniować poziomy wpływu – może to być np.:
Jeśli osoby z zewnątrz zgłaszają zadania to możesz od razu zdefiniować takie pole w twoim narzędziu. Po krótkim wprowadzeniu interesanci powinni sami być w stanie określić wpływ na produkt. A to oszczędzi pracy twojemu zespołowi. Pozostaje jeszcze jedno pytanie – czy wszyscy jedocześnie wykonują taką pracę utrzymaniową? Lider utrzymaniaJeśli pracy utrzymaniowej jest mało, to można rozdzielać ją po prostu ad-hoc. Gdy pojawia się jej więcej to zespół będzie już notorycznie rozpraszany przez wrzutki. Aby zmniejszyć poziom rozproszenia zespołu możesz zdefiniować osobę, która:
Warto zdefiniować tę rolę jako rotacyjną (vide marszałek rotacyjny). Chodzi o to aby nie stworzyć takiej czarnej owcy, która za karę robi utrzymanie przez 3 miesiące. No i oczywiście lider musi również pełnić tą funkcję. Obserwowanie utrzymaniaNiekiedy pracy utrzymaniowej mamy zwyczajnie zbyt wiele. Ale nie wiemy skąd się ona bierze. W efekcie nie mamy, jak jej optymalizować. Aby poradzić sobie z takim problemem możesz podejść do niego następująco:
To pozwoli poradzić sobie z bardziej złożonymi problemami, których rozwiązania nie widać na pierwszy rzut oka. Zapewnienie jakości pracyDużo mówi się teraz o Developer Experience. To też miejsce, w którym Tech Lead może dbać o to, aby pracownikom dobrze się działało z danym produktem. To w dłuższej perspektywie pozwoli nam zwiększyć ogólną efektywność dostarczania. O co zadbać? Ocena zadowolenia z pracyAby dowiedzieć się jak ludzie oceniają pracę, najlepiej jest sięgnąć do źródła – samych pracowników. Nawet jeśli do dyspozycji masz wskaźniki liczbowe, to ludzka percepcja może być skrajnie odmienna. Część wskaźników również jest trudno mierzalna, dlatego też trzeba sięgnąć po dane jakościowe. O co pytać swoich kolegów i koleżanki? Warto sięgnąć do poważnej literatury. Tutaj przykład z ostatniej pracy DevEx – What Actually Drives Productivity:
Nie musisz od razu pytać o wszystko – warto wybrać kilka elementów, w zależności od specyfiki produktu. Np. jeśli często słyszysz o tym, że mamy spaghetti code – zapytaj o ocenę złożoności waszego code-base. Dbanie o dług w produkcieDług w produkcie niejedno ma imię:
Lider techniczny wraz z zespołem ocenia dług, który powstał podczas wcześniejszych etapów rozwoju produktu. Analiza ta pozwala zidentyfikować obszary kodu, które wymagają refaktoryzacji lub optymalizacji. Po zidentyfikowaniu tych punktów, Tech Lead musi przekonać interesariuszy, że inwestycja w spłatę długu się opłaci. Tutaj potrzebne są solidne umiejętności interpersonalne – często trzeba opowiadać o skomplikowanych aspektach technicznych w bardzo biznesowy sposób. Drobne usprawnienia utrzymanioweNie zawsze na każde zadane musimy mieć rozpisaną dużą inicjatywę w Jirze. Pomiędzy jednym a drugim zadaniem funkcyjnym warto zadbać o poprawki, które zwiększają wydajność i przyjemność pracy:
Łatwiej to robić małymi partiami częściej niż jedną dużą inicjatywą. Opieka nad dokumentacją zespołowąNikt nie lubi dokumentować. Każdy kocha dobrą dokumentację. Jako lider techniczny musisz zadbać, aby zespół dokumentował przynajmniej niezbędne minimum. A ponieważ nie jest to najprzyjemniejsza część pracy, to bez dobrych praktyk zespołowych się tutaj nie obędzie. Dobrą podstawą będą:
Czym jest minimum dokumentacji? To już opisałem w poprzednim newsletterze – Minimum dokumentacji w zespole produktowym. Poprawa procesów pracyNaturalnie twój zespół poszerza swój zakres odpowiedzialności wraz z rozwojem produktu. Wobec czego powinny się również zmienić procesy pracy. To, o co powinieneś zadbać:
Każda z powyższych inicjatyw wymaga szerszego spojrzenia na pracę zespołu – pracujesz nad procesami, a nie wewnątrz procesów. Analogicznie jak pisali w książce E-Myth Busted:
Kiedy wszystko działa jak dobrze naoliwiona maszyna to zyskasz też chwilę na współpracę z innymi zespołami. Koordynacja z resztą organizacjiZespół produktowy nie działa w próżni. Mamy obok przecież zarówno inne zespoły produktowe, jak i „the business", jak i wyższą kadrę zarządzającą. Z całą tą pajęczą siecią trzeba umieć współpracować. Regularne spotkania z innymi działamiCzłowiek jest istotą stadną. Ufa dopiero kiedy poznał drugą osobę, zrozumiał cele drugiej strony. Nie ufa, kiedy kogoś nie widział w życiu na oczy. Aby dobrze ze sobą współpracować dobrze więc się najpierw spotkać i dogadać warunki współpracy. O tym warto porozmawiać, aby takie spotkania były efektywne:
Techniką, z której może skorzystać lider do ustalenia odpowiedzialności, jest zaadaptowany Spectrum Mapping :
Ustalamy tu, jakie zadania składają się na współpracę międzyzespołową. Następnie nanosimy na spektrum:
Na tych spotkaniach nie jest koniecznie wymagana obecność lidera technicznego, tylko kogoś z zespołu. Ale warto pamiętać, że to lider dba o to by spotkanie się odbywało i aby przedstawiciel zespołu tam się pojawił. Współtworzenie roadmapy organizacjiW wielu organizacjach inicjatywy przenikają przez wiele zespołów. Pojedynczych zespół rzadko kiedy ma możliwość dowiezienia dużej zmiany End-To-End. To sprawia, że lider techniczny musi wychodzić poza zespół, aby współpracować z organizacją odnośnie ustalenia kierunku prac. Zwykle ta praca odbywa się ramię w ramię z Product Managerem tak, aby:
Więcej o tym zagadnieniu pisałem w poprzednim newsletterze - Inżynierski wkład w roadmapę produktu. Wymiana technologii wewnątrz organizacjiW zespołach często wypracowywane są praktyki techniczne wartościowe szerzej dla organizacji. Aby cała organizacja podnosiła swoją efektywność, trzeba dzielić się tymi wynikami dalej. Zwykle to lider techniczny jest odpowiedzialny za tego typu wymianę praktyk pomiędzy zespołami, czyli:
Warto również wspomnieć temat gildii architektonicznej. W organizacjach to liderzy techniczni są członkami takich gildii i wypracowują wspólne wzorce dla reszty organizacji. Jeśli organizacja posiada rolę Staff Engineera to bardzo często to właśnie z nim współpracuje lider techniczny by wymieniać się wiedzą. Wtedy wypracowywanie kierunku technicznego jest często delegowane do SE, a lider jedynie udziela wskazówek. Lider musi natomiast wybrać jakie praktyki faktycznie zinternalizować w swoim zespole. I to kieruje nas bezpośrednio do ostatniego zagadnienia. Praca strategiczna zespołuLider nie może zwracać uwagi tylko na kolejny sprint. Jeśli tak będzie to po pół roku może już nie być czego zbierać. Co w takim razie warto zrobić? Określenie długoterminowej strategiiZespół pracuje w określonym otoczeniu biznesowym. Są elementy otoczenia, które przeszkadzają i takie które pomagają. Część zadań idzie dobrze, a część leje się jak krew z nosa. Czyli mamy dużo drobnych elementów, które można poprawiać, bądź usprawniać. W takich sytuacjach liderzy często próbują wykonywać zbyt wiele działań naraz. To powoduje rozdrobnienie inicjatyw i brak jakichkolwiek rezultatów. Kluczowe jest tu wypracowanie kluczowego aspektu – strategii inżynierskiej zespołu. Podstawową jest określenie:
Tak określona strategia pozwoli skupić się na 1-2 kluczowych obecnie inicjatywach. Dzięki czemu będzie łatwiej monitorować postęp i adaptować rozwiązania. Więcej o tym można poczytać np. u Willa Larsona w Engineering strategy, bazującej mocno na książce Good Strategy, Bad Strategy:
Definiowanie kierunku zmian produktuPo ogólnej dyskusji, pora wejść w temat głębiej. Taktycznie, lider techniczny określa w którym kierunku rozwija się dane rozwiązanie. Oczywiście nie robi tego sam, ale faktycznie musi zaaprobować podejmowane decyzje. A tych nie jest mało. Oto kilka pytań, które można sobie zadać:
Często odpowiedzi są proste, ale faktyczne wdrożenie w życie odpowiedzi już wiele trudniejsze. Wymaga też współpracy zarówno z innymi rolami zespołowymi, jak i interesariuszami. I o tym należy pamiętać. PodsumowanieSporo tego, prawda? 😀 Okazuje się, że wbrew pozorom lider techniczny musi ciężko pracować także po wdrożeniu. Ale to dobrze – ponieważ jeśli jest praca po wdrożeniu, to znaczy, że produkt żyje. I zarabia na siebie. Tego Ci właśnie życzę! A jeśli widzisz, że czegoś zabrakło w moim tekście to daj znać w odpowiedzi 😊 📧 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 :) |
