Jaka jest rola Tech Leada po wdrożeniu?

W dzisiejszym wydaniu 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 😃

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:

“Software engineering is programming integrated over time.”

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 produkcji

Jeś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:

• Głównych celów.

• Najważniejszych klientów.

• Najczęstszych problemów.

Na miary możemy patrzeć zarówno od strony biznesowej, jak i technicznej – oto kilka propozycji, co obserwować:

• Biznesowe

  • Czasy odpowiedzi dla głównych procesów biznesowych.

  • Liczba odrzuceń z procesów.

  • Wykorzystanie poszczególnych flag / konfiguracji.

• Techniczne

  • Percentyle czasów odpowiedzi.

  • Liczba błędów różnego poziomu.

  • Procent wykorzystywanych zasobów.

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

Problemem 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 wiedzy

Zadaj sobie pytanie:

Czy bez mojej pomocy osoba ABC będzie w stanie wyszukać coś w danym narzędziu?

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:

• Ucz przez przykład– pokazuj konkretny scenariusz biznesowy i jak sobie z nim poradzić.

• Ucz przez praktykę– niech sami uczący się wykonują konkretne scenariusze.

• Ucz przez dokumentację– by nie powtarzać tego samego po 3 razy – vide Hanselmanowskie Your words are wasted.

Powyższe praktyki obserwowalności pozwolą zdecydowanie zredukować koszty dookoła kolejnego obszaru.

Procesy utrzymaniowe

Nikt 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 utrzymaniem

Pracą utrzymaniową trzeba zarządzać tak, jak pracą funkcjonalną.

To, o co warto zadbać w ramach samej pracy:

• Jasno wyznaczone miejsce i metoda zgłaszania pracy - nie zawsze pochodzi ona od nas.

• Spójne miejsce, w którym trzymamy pracę.

• Wybór do jakiego obszaru należy praca.

Jeśli otrzymujemy zgłoszenia zewnętrzne to warto też zadbać o, to jak reagujemy na dane zgłoszenie:

• Ocena czy to jest w ogóle coś czym trzeba się zająć.

• Ocena gabarytu.

• Ocena priorytetu.

Ostatnia kwestia jest najtrudniejsza, bo jeśli ktoś zgłasza problem, to zawsze będzie on najbardziej pilny. 🤣 Co wtedy robić?

Wpływ na produkt

Jeś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.:

• Cały system

• Pojedynczy proces

• Pojedynczy market

• Jeden klient

• Niefunkcjonalne - dane analityczne

• Niefunkcjonalne - obserwowalność

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 utrzymania

Jeś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:

• Jest odpowiedzialna za pierwszą linię wsparcia w zespole.

• Skupia się głównie na zadaniach utrzymaniowych.

• Stara się zdejmować operacyjne zadania z innych członków zespołu.

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 utrzymania

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

• Zbieraj każdego ad-hoca – np. w formie screenshotów na tablicy wirtualnej.

• Kategoryzuj – dziel na różne wymiary np. skąd pochodzą, jakiego obszaru dotyczą, którego rynku.

• Agreguj – podsumuj po kilku tygodniach zebrane dane, aby znaleźć połączenia pomiędzy problemami i zebrać najczęściej powtarzane.

• Stwórz inicjatywę naprawczą – aby rozwiązać to co faktycznie najbardziej przeszkadza.

To pozwoli poradzić sobie z bardziej złożonymi problemami, których rozwiązania nie widać na pierwszy rzut oka.

Zapewnienie jakości pracy

Duż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 pracy

Aby 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 produkcie

Dług w produkcie niejedno ma imię:

• Techniczny – narastające problemy programistyczne.

• Biznesowy – zmiany modelu działania firmy, które nie zostały uwzględnione w produkcie.

• Organizacyjny – problemy komunikacyjne czy strukturalne, które wpływają na produkt.

• Użytecznościowy – błędny model działania, do którego przyzwyczaił się klient, przez co zmiana jest problematyczna.

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 utrzymaniowe

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

• Optymalizacja skryptów CI/CD.

• Poprawienie flaky testów.

• Drobne poprawki refaktoryzacyjne.

• Aktualizacja bibliotek.

• Automatyzacja rutynowych zadań.

Ł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ą:

• Dokumentacja jako część zadania.

• Dostęp edycyjny do narzędzi dokumentacji dla każdej osoby.

• Zapisywanie braków w dokumentacji blisko niej.

Czym jest minimum dokumentacji? To już opisałem w poprzednim newsletterze – Minimum dokumentacji w zespole produktowym.

Poprawa procesów pracy

Naturalnie 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ć:

• Sprawdzenie wskaźników pracy – np. z metryk DORA wychodzi wam, że strasznie długo trwają PR Review. Czy nie powinniśmy tutaj zainicjować dyskusji jak ten problem zmniejszyć?

• Ocena czy obecne praktyki są dalej aktualne – np. wysyłaliście podsumowania do interesariuszy, a w międzyczasie odeszła ostatnia osoba, która je czytała. Czy dalej ma więc sens ich wysyłanie?

• Ocena czy i jak usprawnić obecne praktyki – np. review zespołowe stało się ostatnio nudne i powtarzalne. Może je zdynamizować np. przez dyskusję o realnym wpływie zespołu i liczbach?

• Wprowadzanie nowych praktyk – np. widzisz, że w zespole stworzyły się silosy z wiedzą. Może pomogłyby sesje wymiany wiedzy, po zakończonym cyklu pracy?

• Dokumentacja obecnych procesów – np. w przypadku błędów w jednej części produktu ludzie chaotycznie szukają rozwiązania, kiedy ogólnie wiadomo co robić. Może warto spisać / wizualnie zaprezentować co i gdzie klikać, by ograniczyć zamieszanie?

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:

Work ON your business, not IN it

Kiedy wszystko działa jak dobrze naoliwiona maszyna to zyskasz też chwilę na współpracę z innymi zespołami.

Koordynacja z resztą organizacji

Zespół 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łami

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

• Wspólne / rozbieżne cele.

• Obecny zakres prac i jak możemy sobie nawzajem pomóc.

• Problemy we współpracy, które wymagają zaadresowania.

• Kanały komunikacyjne, przeznaczone do wykorzystywania poza spotkaniami.

• Podział odpowiedzialności nad kolejnymi wspólnymi zadaniami.

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:

• Zespół A / Zespół B – bezpośrednia odpowiedzialność któregoś z zespołów.

• Do przegadania – na pograniczu, musimy podjąć decyzję jak to zaadresować, ponieważ nie ma na ten moment jednoznacznej odpowiedzi.

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 organizacji

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

• Proponować najlepsze rozwiązania do celów biznesowych.

• Dyskutować nad technicznymi i infrastrukturalnymi zależnościami.

• Przekazywać realne możliwości zespołu do wprowadzania wymaganych zmian.

• Przekonywać do uruchamiania inicjatyw, które poprawiają atrybuty jakościowe produktu.

Więcej o tym zagadnieniu pisałem w poprzednim newsletterze - Inżynierski wkład w roadmapę produktu.

Wymiana technologii wewnątrz organizacji

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

• Dzielenie się wewnętrznymi praktykami szerzej.

• Przynoszenie dobrych praktyk z innych zespołów.

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

Lider 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 strategii

Zespół 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:

• Diagnozy – w jakim otoczeniem biznesowym się znajduje zespół, z czym mamy problemy, co jest naszym głównym blokerem?

• Metody – co jest potencjalnym rozwiązaniem głównego blokera, jakie mamy alternatywy, co tracimy wybierając jedną lub drugą opcję, jak będziemy mierzyli postęp, co ostatecznie wybieramy?

• Planu – jak wdrożymy wybrane rozwiązanie w życie, od czego rozpoczniemy, kogo musimy powiadomić?

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 produktu

Po 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ć:

• Czy wykonać aktualizację frameworku, czy poczekać na pierwsze poprawki?

• Czy wejść w kolejną technologię, czy trzymać się nudnych technologii?

• Które ryzyka nowej technologii zaadresujemy jako pierwsze?

• Czy istnieją wymagania jakościowe, które długofalowo musimy zaadresować?

• Jaki mamy plan migracji technicznej?

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ć.

Podsumowanie

Sporo 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 😊