Zarządzasz najlepszym zespołem w firmie: najkrótszy czas cyklu, najwyższa dokładność planowania i najmniejsza ilość poprawek. Twój zespół ma najkrótszy czas przeglądu, najwięcej wdrożeń tygodniowo i najlepszy stosunek błędów do KLOC. A potem ktoś wysoko postawiony zamyka twój projekt — co się właśnie stało?

Paradoks wyjściowy

Jako młodszy programista nauczono mnie, że częste łączenie małych zmian jest kluczem do szybkiego dostarczania wartości. Jako młodszy kierownik ds. inżynierii powiedziano mi, że śledzenie i optymalizacja metryk są niezbędne w pracy kierownika. Pierwszy wynik w Google wskazał mi kilka terminów i akronimów, a to były moje pierwsze wprowadzenie do metryk deweloperskich.

Metryki deweloperskie to zasadniczo zestaw wskaźników, które pomagają zespołom inżynierów śledzić ich szybkość (szybkie działanie) i jakość (bez psucia rzeczy). Do pomiaru tych atrybutów można użyć różnych metryk. Czas cyklu, liczba PR lub zamknięte problemy śledzą prędkość. Aby śledzić jakość, monitoruj liczbę defektów, średni czas do rozwiązania lub liczbę wdrożeń, które powodują awarie. Każda z tych metryk zapewni inny wgląd w sprawdzany atrybut. Niektóre metryki pomagają również w analizie atrybutów proxy. Śledź przeróbki, aby analizować wydajność, która wpływa na prędkość. Dokładność planowania jest dobrym wskaźnikiem przewidywalności, która umożliwia zarówno szybkość, jak i jakość, i ma wartość samą w sobie.

Problem ze wszystkimi powyższymi wskaźnikami polega na tym, że chociaż doskonale sprawdzają się w mierzeniu wydajności, zwykle nie wystarczają do zmierzenia sukcesu. Głównym powodem jest to, że są one całkowicie oderwane od biznesowych KPI (kluczowych wskaźników wydajności, jeszcze jedna fantazyjna nazwa wskaźników). To rozłączenie często prowadzi do nieefektywnej komunikacji między organizacjami w firmie, głównie produktowymi i inżynieryjnymi. W końcu organizacja produktu (i reszta firmy) nie dba wyłącznie o szybkość lub jakość, ponieważ te śledzą wydajność . Organizacja produktowa zwykle dba o wynik — jaki przychód przyniosła nasza nowa funkcja? Ilu nowych użytkowników przyciągnęliśmy?

Jako nowy kierownik techniczny było to dla mnie zaskakujące. Z jednej strony było jasne, że dalsze mierzenie mojego zespołu w oparciu o metryki deweloperskie zamiast metryk biznesowych doprowadzi do rozbieżności z zespołem produktowym. Z drugiej strony ocenianie mojego zespołu na podstawie wskaźników biznesowych wydawało się niesprawiedliwe: jak mogą na niego wpłynąć? Czy to nasza praca? Czy będę deptać po piętach organizacji produktowej?

Mierz to, co ma znaczenie

Zrobiłem skok wiary i spróbowałem użyć wskaźników biznesowych jako mojej gwiazdy północnej. Z biegiem czasu przynosiło to coraz lepsze wyniki.

Po pierwsze, uprościło komunikację. Twojemu odpowiednikowi produktu łatwiej jest zrozumieć, dlaczego tak ważne jest nadanie priorytetu uaktualnieniu bazy danych, jeśli umieścisz go w kategoriach wspólnych wskaźników KPI, które zostaną naruszone. Tylko dlatego, że jest dla ciebie jasne, że jeśli nie uszeregujesz aktualizacji bazy danych jako priorytetu, kilka kolejnych historii użytkowników zajmie dwa razy więcej czasu i będziesz musiał poświęcić czas na konserwację, co opóźni wydanie funkcji do punktu, w którym wygrałeś To, że nie masz wystarczająco dużo czasu, aby osiągnąć cel użycia, który ustawiłeś jako KPI, nie oznacza, że ​​jest to jasne dla twojego odpowiednika produktu. To znaczy, to dużo chmielu; dlaczego nie zacząć od tego, co ma znaczenie? (nie, to nie jest aktualizacja bazy danych)

Po drugie, pomiar mojego zespołu na podstawie wskaźników biznesowych uświadomił mi, że możemy mieć na niego spory wpływ:

• Możemy zidentyfikować cechy, w których możemy zbudować 80% wartości dla użytkownika za 20% wysiłku. Może to zwolnić zasoby, aby przyspieszyć realizację naszych KPI. Aby to zrobić, zespół musi dokładnie zrozumieć cele biznesowe, potrzeby użytkowników i dążenie do ich poprawy.
• Możemy użyć wskaźników KPI, aby wskazać, jaki dług technologiczny powinniśmy zgromadzić: czy staramy się pozyskać pierwszych użytkowników funkcji, a awaria funkcji jest opcją? Wypuśćmy tak szybko, jak to możliwe i martwmy się o dług technologiczny później. Czy staramy się poprawić utrzymanie dużej bazy klientów? Zadbajmy o wysoką jakość tego.
• Możemy zasugerować rozwiązania problemów, o których produkt nawet nie wiedział, że są możliwe do rozwiązania, w oparciu o postęp w nowej technologii lub innowacyjny punkt widzenia inżynierii.
• Możemy (choć może to irytujące) wykorzystać KPI, aby zrozumieć, że nie ma sensu dążyć do konkretnego fajnego rozwiązania technologicznego, które chcemy wdrożyć, ponieważ sam problem nie jest kluczowy dla biznesu.

Jak mierzyć sukces?

Po przejściu na metryki istotne dla biznesu, mój odpowiednik produktu i ja musieliśmy wybrać platformę do ich pomiaru. W firmie Epsagon zastosowaliśmy framework OKR . Nie będę wchodził w szczegóły, ponieważ istnieje wiele świetnych zasobów do wdrażania OKR dostępnych online. Istotą jest to, że jest to doskonała platforma dla średnich i dużych organizacji, zwykle w fazie dopasowania rynkowego po wprowadzeniu produktu na rynek. Pomaga dostosować różne zespoły, grupy i organizacje w firmie do tych samych celów opartych na wynikach.

W Epsagon mieliśmy OKR dla każdego zespołu produktowego i były to cele inżynierów, produktów i projektantów, którzy tworzyli zespół produktowy. Po wdrożeniu mieliśmy lepszą współpracę między produktem a inżynierią. Mniej kłótni o wymagania i więcej współpracy w rozwiązywaniu problemów. Zauważyliśmy również, że wzrost autonomii spowodowany wyznaczaniem celów ponad zadaniami zwiększał innowacyjność i odpowiedzialność za wyniki. Zespoły wyznaczyły plan działania, a rozwiązania pochodziły zarówno z dziedziny inżynierii, jak i produktu.

Wadą tej metodologii jest to, że wymaga ona pewnego wysiłku przy wdrażaniu, a także wymaga umiejętności określania celów na przestrzeni miesięcy. Jest to zwykle trudne dla małych start-upów, zwłaszcza przed dopasowaniem produktu do rynku. Na wcześniejszych etapach można pracować z jedną podstawową metryką i nadal kierować się celem biznesowym, zachowując jednocześnie elastyczność wystarczającą do zmiany celów i skupienia się na szczegółowości tygodni lub dni.

Niezależnie od tego, czy Twój zespół jest duży, czy mały, ma jedną misję lub sprzeczne priorytety — dopóki mierzysz to, co ma znaczenie, masz większe szanse na sukces. „Jak” to tylko optymalizacja.

Komunikacja jest kluczem

Następnym krokiem po ustaleniu biznesowych wskaźników KPI jest ich kontynuacja. Z mojego doświadczenia wynika, że ​​komunikowanie i wdrażanie tej zmiany ma dwa krytyczne aspekty. Pierwszym z nich jest spójność: nie wystarczy ustawić te wskaźniki i wrócić do nich trzy miesiące później, aby dowiedzieć się, że przegapiliśmy nasze oceny. Naszym zadaniem jako liderów jest ciągłe monitorowanie tych wskaźników i upewnianie się, że ich stan i plan ich poprawy są zawsze przekazywane całemu naszemu zespołowi.

Drugim aspektem jest zaangażowanie: kuszące jest powrót do starych nawyków mierzenia jednostek za pomocą metryk deweloperskich w celu ich optymalizacji. To wyśle ​​​​niewłaściwą wiadomość do Twojego zespołu, sugerując, że chociaż mówisz, że zależy Ci na biznesowych KPI, tak naprawdę zależy Ci na wskaźnikach deweloperskich. Pamiętaj, aby zmienić swoje nawyki, aby odzwierciedlały Twoje priorytety: świętuj wyniki biznesowe, eliminuj funkcje, które nie są niezbędne, zamiast naciskać na terminy i podnoś flagi, gdy biznesowe wskaźniki KPI są niższe. Nadal możesz używać metryk deweloperskich jako wskaźników; pamiętaj tylko, aby powiązać je z ich wpływem na biznesowe KPI.

Czy metryki deweloperskie są przestarzałe?

Pomimo zachęcającego do klikania nagłówka tego artykułu, odpowiedź brzmi „nie” — powinny być po prostu używane poprawnie. Po pierwsze, metryki deweloperskie są potężnymi narzędziami do rozwiązywania problemów z metrykami biznesowymi. Na przykład spadek utrzymania użytkowników można wytłumaczyć wzrostem liczby defektów. W takim przypadku możesz użyć metryki dev jako wskaźnika wiodącego: zamiast czekać na spadek retencji, powinieneś monitorować liczbę defektów, aby zapobiec jej spadkowi (podobnie jak monitorujesz użycie procesora, aby uniknąć liczby błędów API 5xx przed zwiększaniem i wyrządzaniem rzeczywistych szkód użytkownikom). Innym przypadkiem użycia są metryki deweloperskie jako wiodący wskaźnik doświadczenia i satysfakcji programistów (co z kolei wpływa na retencję programistów).

Jednak najważniejszą rzeczą do zapamiętania jest to, że nigdy nie należy optymalizować wskaźników dev. Powinieneś zawsze optymalizować metryki biznesowe i używać optymalizacji metryk deweloperskich tylko jako narzędzia do osiągnięcia tego celu. I oczywiście powinieneś wyznaczać, śledzić lub optymalizować cele metryk deweloperskich dopiero wtedy, gdy masz jasne wyobrażenie o wyniku biznesowym , który próbujesz osiągnąć, oraz biznesowych KPI, które próbujesz osiągnąć. Świetne statystyki inżynieryjne nie uratują twojego projektu, jeśli nie ma on żadnej wartości.

Co dalej?

Jeśli kierujesz organizacją inżynieryjną, przejście na optymalizację wyników biznesowych w stosunku do wskaźników deweloperskich zwiększy szanse Twojego zespołu na wywarcie rzeczywistego wpływu na biznes. Jeśli chcesz zostać liderem zorientowanym na wyniki, zachęcam Cię do zadania sobie następujących pytań:

• Czy wiem, jakich wyników biznesowych się ode mnie oczekuje?
• Czy robię wszystko, co w mojej mocy, aby zoptymalizować te wyniki?
• Jak śledzę sukces? Jakie są kryteria wywieszenia flagi lub zmiany planów?
• Czy mój zespół jest świadomy celów biznesowych i planu ich osiągnięcia? Jaki jest ich wkład w to?
• Które z moich biznesowych wskaźników KPI można poprawić, poprawiając które wskaźniki deweloperskie?