Kto naprawdę powinien posiadać Twój plan śledzenia?

Uwaga edytora: ten artykuł został pierwotnie opublikowany na blogu Iteratively 11 stycznia 2021 r.

„Dane to sport zespołowy” to coś, w co mocno wierzymy i o czym często mówimy w Amplitude. Plany śledzenia Analytics nie różnią się niczym — plany śledzenia (i ich oprzyrządowanie) są z natury oparte na współpracy. Działają najlepiej, gdy spotykają się odpowiednie zespoły.

Weźmy przykład nowej wersji funkcji. Zespół produktu zdefiniował cele i metryki dla tej nowej funkcji i będzie miał wgląd w to, jakie śledzenie zdarzeń jest potrzebne do mierzenia tych metryk. Zespoły ds. systemów iOS, Android i sieci Web są odpowiedzialne za oprzyrządowanie (a najlepiej przetestowanie) tych zdarzeń w kodzie i będą miały opinię na temat tego, co jest wykonalne. Analityk lub inżynier analityk jest odpowiedzialny za modelowanie danych i dba o ich strukturę, a Ty możesz mieć kilka zespołów odpowiedzialnych za budowanie raportów i analizowanie danych w kilku narzędziach. Krótko mówiąc, analityka firmy oparta na danych dotyczy prawie wszystkich.

Przykład pokazuje, jak złożone jest naprawdę śledzenie analityczne, a także mówi o znaczeniu współpracy przy definiowaniu i rejestrowaniu właściwych zdarzeń, ich dokładnym wdrażaniu i ułatwianiu konsumentom danych ich eksploracji. To powiedziawszy, przy tak wielu zaangażowanych osobach śledzenie analityczne łatwo staje się gorącym ziemniakiem.

Jeśli jest własnością wszystkich, nie jest własnością nikogo

Przy tak wielu zaangażowanych interesariuszach plan śledzenia często staje się wspólną odpowiedzialnością, bez wyraźnego właściciela. A ze wspólną odpowiedzialnością wiąże się niewielka odpowiedzialność.

Rozmawialiśmy z wieloma firmami, które chcą (od)tworzyć procesy związane ze śledzeniem danych analitycznych. Zwykle obraca się wokół arkusza kalkulacyjnego lub strony Confluence lub Notion. Chociaż jest to w większości ręczne i nie ma możliwości wyegzekwowania planu śledzenia w kodzie, okazuje się przydatne na początku i zmusza zespoły do ​​większego zastanowienia się nad śledzeniem zdarzeń.

Jednak po kilku miesiącach strona Notion lub Arkusz kalkulacyjny Google stają się nieaktualne: śledzenie najnowszej wersji zostało udokumentowane tylko w historii Jira, a w przypadku kilku innych wydań funkcji nie jest teraz jasne, czy śledzenie zostało zaimplementowane, czy nie. Nikt nie nakłada na siebie odpowiedzialności za aktualizowanie planu śledzenia.

Jak więc zmienić to na lepsze i kto jest najlepiej przygotowany do posiadania śledzenia danych analitycznych?

Zacznij od umieszczenia analityki na pierwszym planie

Zanim przejdziemy do kwestii własności, musimy wspomnieć o podstawach niezbędnych do skutecznego śledzenia danych analitycznych: śledzenie zdarzeń ma znaczenie, a bez niego pozostajesz w ciemności. Rzeczywistość jest taka, że ​​dla większości zespołów analityka jest kwestią późniejszej refleksji. Oto przykład, który widzimy cały czas:

• PM pracuje nad wydaniem
• Wydanie się zdarza
• CEO pyta premiera, jak to działa
• PM: „Pozwól, że zapytam zespół ds. danych”
• Zespół ds. danych: „Nigdy nas nie sprowadziłeś — nie ma danych na temat tej funkcji”.
• PM wraca do CEO bez odpowiedzi
• Zespół ds. danych i PM są zrozpaczeni

Jeśli analityka nie stanie się integralną częścią każdej wersji, będzie się to powtarzać w kółko i nie ma znaczenia, czy Twój plan śledzenia wygląda naprawdę sprytnie i na bieżąco. Potrzebujesz zgody wszystkich interesariuszy (a także zespołów kierowniczych), że śledzenie analityczne jest tak samo ważne jak sama funkcja. Bez śledzenia, bez wydania.

Potrzebujesz wyraźnej odpowiedzialności, czasu i zasobów, aby wzmocnić odpowiednie zespoły, a następnie musisz osadzić śledzenie zdarzeń i metryki sukcesu aż do poziomu zgłoszenia Jira (gotowe jest wykonywane tylko wtedy, gdy kod śledzenia jest wysyłany wraz z resztą kodu).

Czego nauczyliśmy się z ponad 400 wywiadów z ekspertami ds. danych i produktów

W ciągu dwóch lat przeprowadziliśmy wywiady z ponad 400 menedżerami produktów, zespołami danych i inżynierami. Widzieliśmy kilka rzeczy.

Oczywiście Twój plan śledzenia i związany z nim proces są unikalne dla Twojej firmy, struktury zespołu i branży (i prawdopodobnie dlatego tak trudno jest zrobić to dobrze). Plan śledzenia dla firmy e-commerce będzie wyglądał zupełnie inaczej niż plan śledzenia dla firmy B2B SaaS. Mają różnych interesariuszy i rozwiązują problemy w całkowicie odrębnych rzeczywistościach. Najczęściej możemy podzielić to, co widzieliśmy, według wielkości firmy.

Startupy

W przypadku małych firm proces śledzenia odbywa się zwykle ad hoc. Jest to naturalne, ponieważ zaangażowanych jest bardzo niewiele osób i sprawia, że ​​​​złożoność jest łatwa (ish) do zarządzania. Najczęściej widzimy, jak szef produktu lub kierownik ds. wzrostu przejmuje odpowiedzialność na tym etapie podróży firmy.

MŚP

W średniej wielkości firmie proces zwykle spada na szefa danych/analityki. Obecnie zaangażowanych jest więcej interesariuszy, a złożoność może łatwo stać się problemem. Na tym etapie istnieje wyraźna potrzeba własności w celu ograniczenia szkód i zwykle spada to na kogoś z zespołu danych.

Przedsiębiorstwa

W większych firmach osoba ostatecznie będąca właścicielem planu śledzenia zwykle jest szefem analityki produktu. W przypadku firm e-commerce często będzie to szef e-commerce. Często nie będą oni rzeczywistą osobą na co dzień utrzymującą plan lub egzekwującą proces, będzie to ktoś z ich zespołu, który jest odpowiedzialny.

Widzieliśmy różne stopnie sukcesu z tego typu konfiguracji. Co naszym zdaniem działa najlepiej?

Co działa: zespół ds. produktu jest ostatecznym właścicielem

Oto, co wiemy: najlepszy proces własności ma miejsce, gdy zespół produktu działa jako ostateczny właściciel. Menedżerowie produktu powinni być głównym motorem i zapewnić, że śledzenie analityczne jest częścią każdej wersji funkcji . W zależności od wielkości zespołu może to być jeden lub więcej menedżerów produktu lub dedykowany analityk produktu. Powinni być pociągnięci do odpowiedzialności za śledzenie danych analitycznych w ramach swojej roli i OKR.

Ale jak wspomnieliśmy wcześniej, dane to sport zespołowy i zalecamy, aby zespoły wspólnie definiowały takie rzeczy, jak nazewnictwo wydarzeń i taksonomia. Inżynierowie i zespoły ds. danych będą miały ważne perspektywy, ponieważ wpływa to również na ich codzienność. Chociaż zespół produktowy jest organem egzekucyjnym i ostatecznym właścicielem, nigdy nie powinien pracować w silosie ani podejmować ważnych decyzji bez zaangażowania odpowiednich interesariuszy.

Ustanowienie rady doradczej reprezentującej wszystkie zainteresowane strony dobrze sprawdziło się w firmach, z którymi współpracowaliśmy. Nie każda decyzja trafia do rady doradczej, ale powinna ona być kierowcą na początku, definiując twoją taksonomię i proces oraz regularnie spotykając się w zależności od tego, ile przełomowych zmian nastąpi w czasie.

Aby zespoły produktowe mogły z powodzeniem to posiadać, potrzebny jest jasny proces:

• Miej jasne kryteria sukcesu zarówno dla wskaźników jakościowych, jak i ilościowych jako część każdej historyjki użytkownika. Powinny one zostać zdefiniowane przez PM i skonsultowane z zespołem danych lub analitykami.
• Brak śledzenia? Niepowodzenie kompilacji. Pojęcie „gotowe” musi ewoluować, aby uwzględnić śledzenie analityczne jako część każdej wersji. Nie oznacza to blokowania wydań tuż przed uruchomieniem, oznacza wdrożenie procesu, który obejmuje śledzenie rozważań od samego początku.
• Kluczowa jest współpraca. Podczas gdy kierownik projektu będzie właścicielem specyfikacji śledzenia zdarzeń, zespół ds. danych lub analitycy powinni być dostępni, aby wkroczyć i pomóc określić szczegóły tego, co powinno być śledzone.

Daj swoim menedżerom produktów możliwość przejęcia odpowiedzialności

Dla niektórych PM posiadanie planu śledzenia jest dla nich czymś naturalnym. Chcą kontroli i mają doświadczenie. Nie boją się też prosić o pomoc, gdy jej potrzebują. Ale nie wszystkim premierom przychodzi to naturalnie.

Po pierwsze, musi nastąpić zmiana kulturowa: świętuj wydajność i sukces nowej funkcji lub wydania produktu, a nie fakt, że został wysłany! Zaskakujące jest to, że dla wielu osób pochwały wciąż dotyczą wysyłki, a nie tego, czy produkt działa, czy nie.

Jak więc zapewnić zespołowi produktowemu kontrolę nad planem śledzenia? To nie jest wyczerpująca lista, ale mam nadzieję, że jest to miejsce, w którym ludzie mogą zacząć:

• Regularne szkolenia : prawidłowe śledzenie zdarzeń jest zarówno sztuką, jak i nauką (tj. nie jest łatwe), więc upewnij się, że Twój zespół jest wyposażony w wiedzę potrzebną do wygodnego przejęcia odpowiedzialności. Szkolenie może mieć formę lunchu i nauki stylu, warsztatów lub sesji indywidualnych (pamiętaj, aby nagrać swoje sesje dla przyszłych pracowników).
• Godziny pracy : odnieśliśmy wielki sukces, gdy zespoły ds. danych organizowały regularne godziny pracy dla innych zespołów, aby wykorzystać wiedzę i doświadczenie zespołu ds. danych. Upewnij się, że zespoły przychodzą przygotowane z agendą lub konkretnymi pytaniami, aby uniknąć przekształcenia spotkania w styl „wsparcia technicznego”.
• Jasny proces i punkty kontrolne: Nie możemy wystarczająco podkreślić znaczenia określonego procesu. Upewnij się, że masz jasny proces, o którym wszyscy wiedzą, rozumieją i którego przestrzegają, oraz uwzględnij regularne punkty przeglądu, aby zapewnić jakość, podobnie jak przeglądy kodu i prośby o scalenie w tworzeniu oprogramowania.
• Osadzenie analityka : oczywiście nie zawsze jest to możliwe, ale widzieliśmy, jak odnoszące sukcesy zespoły osadzają analityka danych w zespole produktowym w pełnym lub niepełnym wymiarze godzin, aby był właścicielem śledzenia danych analitycznych i pomagał kierownikom projektów w eksploracji i analizie danych.
• Analityka samoobsługowa: uważamy, że najlepszą praktyką jest umożliwienie kierownikom projektów i wszystkim innym osobom w organizacji łatwego eksplorowania zestawów danych i szybkiego uzyskiwania odpowiedzi na pytania. Amplitude doskonale się do tego nadaje i zapewnia wysoki poziom umiejętności korzystania z danych w całej firmie.

Przypomnienie: dobry PM nie musi znać SQL

Po co przejmować się śledzeniem zdarzeń, jeśli i tak nie możesz samodzielnie eksplorować danych? Aby rozwinąć ostatni punkt powyżej, widzieliśmy firmy z centralnymi zespołami danych, które są właścicielami wszystkich raportów i analiz danych. Ma to swoje zalety, ale z naszego doświadczenia wynika, że ​​może ograniczać PM i inne osoby, które będą mniej przejmować się śledzeniem analiz lub jakością danych.

Pamiętaj, że zapewnienie PM i innym osobom dostępu do Redash lub innych narzędzi opartych na SQL nie jest równoznaczne z umożliwieniem PM do samoobsługi. Nie oczekuj, że Twoi PM będą znać (lub uczyć się) SQL. To nie jest ich zadanie. Zamiast tego zapewnij im łatwy w użyciu interfejs użytkownika i wiele szkoleń związanych z narzędziem i zestawami danych. Oczywiście znajomość SQL ma swoje oczywiste zalety i jeśli jesteś w stanie znaleźć lub wyszkolić talenty w całej firmie (pomyśl o produkcie, marketingu, sukcesie klienta itp.), Możesz sprawić, by działała, ale ma swoje oczywiste wady i ograniczenia.

Jeśli PM są zdolni do samoobsługi, są bardziej skłonni do eksploracji danych, powiedzmy, z niedawnej wersji. Podczas eksploracji danych bardziej zależy im na ich jakości, bogactwie i dostępności. Stwórz kulturę wzmacniania i zbuduj solidny proces wokół śledzenia analiz, a będziesz mieć szczęśliwych kierowników projektów, szczęśliwych analityków, szczęśliwy zespół ds. danych, a nawet szczęśliwych programistów.

Amplitude jest tutaj, aby Ci pomóc

Amplitude pomaga zespołom ds. danych, menedżerom produktów i inżynierom definiować, instrumentować, weryfikować i współpracować przy śledzeniu analiz. Proaktywnie rozwiązujemy problemy z jakością danych wynikające z niespójnego nazewnictwa zdarzeń i braku śledzenia oraz zapewniamy przepływ pracy do zarządzania ewolucją śledzenia.

Umożliwiamy menedżerom produktu przejęcie odpowiedzialności za plan śledzenia i wyrównanie poziomu współpracy między zespołami . Jeśli chcesz wypróbować Amplitude w swojej firmie, utwórz konto już dziś lub zarezerwuj demo z naszym zespołem, aby dowiedzieć się więcej.