Jak zamienić śledzenie Analytics w ciągły proces współpracy

Uwaga edytora: ten artykuł został pierwotnie opublikowany na blogu Iteratively 1 lutego 2021 r.

Wszyscy wiemy, że każda organizacja tworząca produkty i usługi cyfrowe będzie gromadzić dane. Wiemy również, że samo gromadzenie danych to nie to samo, co efektywne ich wykorzystanie. Nawet jeśli masz niesamowity plan śledzenia, wspierany przez solidny zestaw narzędzi, Twoja strategia zawiedzie, jeśli nie poświęcisz czasu na zaangażowanie się w jedną kluczową rzecz: współpracę.

Analityka dotyczy wszystkich w firmie opartej na danych

Pomyśl o zbudowaniu nowej funkcji dla swojego produktu. W grę wchodzą tutaj dwie główne kwestie: jakie nowe punkty danych wprowadzi ta funkcja i kim są odbiorcy tych punktów danych? Cóż, jeśli naprawdę chcesz podejmować decyzje w oparciu o dane, mniej więcej wszyscy będą odbiorcami danych Twoich klientów.

Wszyscy kluczowi interesariusze zaangażowani w śledzenie danych analitycznych wniosą do tej historii swoje unikalne pomysły i wiedzę fachową — zdrową mieszankę wiedzy dziedzinowej i technicznego know-how. Mamy:

• Kierownictwo / kierownictwo
• Menedżerowie produktu
• Analitycy/zespoły danych
• Deweloperzy

Każdy z tych zespołów będzie miał swoje odrębne zadania i cele, ale ostatecznie będą pracować według tego samego planu śledzenia.

Wskazówka : zbyt wielu kucharzy może być koszmarem — przeczytaj ten post, aby dowiedzieć się więcej o tym, kto powinien być właścicielem planu śledzenia.

Jak te zespoły (powinny) współpracować ze sobą w zakresie analiz.

Kierownictwo / kierownictwo

Zacznijmy od zespołów, które będą chciały mieć najbardziej zaawansowany wgląd w śledzenie zdarzeń. Tworząc nową funkcję, dyrektorowi najbardziej zależy na tym, jakie są cele tej nowej funkcji i jakie wskaźniki zostaną użyte do pomiaru sukcesu.

Oznacza to, że zespoły pracujące pod kierownictwem muszą być przygotowane do tworzenia wysokiej jakości raportów. Dobry zespół przywódczy nie będzie chciał podejmować ważnych decyzji dotyczących przyszłości firmy na podstawie przeczuć — będzie chciał twardych dowodów na to, co działa, a co nie.

Kluczowe zachowania współpracujące tego zespołu:

• Przywództwo powinno dołożyć wszelkich starań, aby inspirować współpracę w całej organizacji i wspierać kulturę, która rozumie wartość podejmowania decyzji w oparciu o dane.
• Świętuj sukcesy wynikające z podejmowania decyzji na podstawie danych.
• Z grubsza, jeśli twój menedżer nie dba o dobre śledzenie danych analitycznych, to dlaczego ty miałbyś to robić? ‍

Menedżerowie produktu

Menedżerowie produktu dokładnie znają Twój produkt i jego pozycję na rynku/branży. Są odpowiedzialni za udostępnienie tej nowej funkcji i jako tacy będą starali się przekształcić te wskaźniki, na których zależy kierownictwu, w rzeczywiste zdarzenia, które chcą śledzić. Aby tworzyć wiarygodne raporty dotyczące tej nowej funkcji, śledzenie zdarzeń musi być wbudowane od samego początku.

Chociaż menedżer produktu jest uzbrojony w dużą wiedzę specjalistyczną w danej dziedzinie, może nie mieć umiejętności technicznych potrzebnych do samodzielnego zdefiniowania planu śledzenia. Oznacza to, że muszą współpracować z innymi zespołami, aby wykonać zadanie. Dobry menedżer produktu jest mniej skłonny do dyktowania listy zdarzeń, które chce śledzić, i oczekuje, że wyniknie z tego doskonały raport. Zamiast tego mogą dyskutować i uzgadniać, co jest możliwe z analitykami i programistami, ponieważ są to zespoły, które będą wdrażać plan śledzenia i tworzyć raporty.

Tak więc menedżerowie produktu będą wiedzieć, które wskaźniki są ważne, ale mogą polegać na innych, aby przekształcili je w możliwe do śledzenia zdarzenia. Posłużą do zadawania właściwych pytań dotyczących danych, decydowania, kiedy przeprowadzać testy A/B i tworzenia odpowiednich pętli sprzężenia zwrotnego: przyglądania się skuteczności wcześniejszych decyzji i powtarzania ich.

Kluczowe zachowania współpracujące tego zespołu:

• Regularne kontrole z analitykami dotyczące tego, jakie zdarzenia są śledzone i dlaczego, oraz utrzymywanie wszystkich na tej samej stronie dzięki taksonomii i konwencjom nazewnictwa
• Współpraca z programistami w celu ustalenia, jakie zmiany w planie śledzenia wymagają wdrożenia i czy te zmiany są możliwe, biorąc pod uwagę infrastrukturę, i ile czasu to zajmie
• Upewnienie się, że przekazują kierownictwu informacje zwrotne za pomocą wysokiej jakości raportów

analitycy

Twój zespół analityków danych jest jak centralne centrum raportowania w firmie. Najprawdopodobniej to oni jako pierwsi dostają surowe dane (prawdopodobnie jedyni). Będą pracować nad łączeniem, modelowaniem i wizualizacją danych. Pomagają przekształcić dane we wgląd.

Ważna uwaga dotycząca zespołu analityków : nie należy ich postrzegać jako zasobów organizacyjnych, tj. „ludzi, których można zapytać”, gdy potrzebujesz czegoś związanego z danymi. W takim przypadku analitycy mogą stwierdzić, że ich wydajność jest zajęta spełnianiem codziennych próśb innych zespołów, zamiast faktycznego budowania spostrzeżeń i generowania znaczących raportów.

Częścią procesu współpracy analityka jest umożliwienie innym zespołom samoobsługi w jak największym stopniu. Podstawowym tego przykładem może być współpraca z menedżerami produktów i marketerami w celu zbudowania predefiniowanych zapytań w narzędziu takim jak Tableau, tak aby na najczęściej zadawane pytania można było odpowiedzieć jednym kliknięciem. Zespoły ds. produktów i marketingu mogą również korzystać z samoobsługowej cyfrowej platformy analitycznej, takiej jak Amplitude, do samodzielnego tworzenia wykresów i analizowania zachowań klientów.

Kluczowe zachowania współpracujące tego zespołu:

• Współpraca z menedżerami produktu w celu lepszego zrozumienia osób stojących za danymi: mogą pracować z abstrakcyjnymi danymi, nie wiedząc zbyt wiele o użytkownikach końcowych, ale będą tym bardziej efektywni, jeśli lepiej zrozumieją, dlaczego te dane są ważne
• Ułatwianie trudnych rozmów na temat tego, jakie pytania są najbardziej przydatne do zadawania danych i jakie inne zespoły chcą śledzić (np. wiedzieć, kiedy odrzucić, jeśli zespoły proszą o zebranie większej ilości danych niż jest to potrzebne)

Deweloperzy

Oczywiście programiści to ci, którzy faktycznie budują produkt, a tym samym wdrażają Twój plan śledzenia. Technicznie rzecz biorąc, inżynier oprogramowania nie musi dużo wiedzieć o branży, w której działasz, ani o zachowaniu użytkowników końcowych. Nie jest to prawdą we wszystkich przypadkach i doprowadziło do założenia, że ​​programiści nie dbają o analitykę.

W rzeczywistości zespół inżynierów może mieć trudności z wprowadzeniem analiz w znaczący sposób, jeśli nie ma usystematyzowanego procesu współpracy. Podczas tworzenia nowej funkcji otrzymywanie arkusza kalkulacyjnego zawierającego informacje o zdarzeniach do śledzenia może być frustrujące, ponieważ stanowi ogromne zakłócenie przepływu pracy. Przełączanie się między IDE, arkuszem kalkulacyjnym i biletem Jira jest uciążliwe i bardzo łatwo prowadzi do błędów i niespójności.

Dobrym programistom znacznie bardziej zależy na tym, jak działają tworzone przez nich produkty — wiedzą też więcej niż ktokolwiek inny, jak produkt faktycznie działa, więc są najlepiej przygotowani do wdrożenia planu śledzenia w najbardziej efektywny sposób.

Kluczowe zachowania współpracujące tego zespołu:

• Upewnienie się, że menedżerowie produktu rozumieją ograniczenia infrastruktury swoich produktów, kiedy i gdzie śledzenie jest właściwe oraz jak długo może zająć wdrożenie
• Ścisła współpraca z analitykami w celu tworzenia potoków danych i analiz oraz upewnianie się, że wszystko idzie tam, gdzie powinno.
• Pomaganie wszystkim pozostałym zespołom w zrozumieniu, że aby skutecznie śledzić zdarzenia, potrzebują czasu na wbudowanie śledzenia w funkcje od samego początku, a nie po namyśle

Wspieranie współpracy wokół śledzenia danych analitycznych

Dzięki temu szerokiemu zrozumieniu, w jaki sposób zespoły mogą współpracować przy śledzeniu danych analitycznych, powinno być łatwiej rozpocząć opracowywanie wspólnego procesu. Jest całkiem jasne, że jeśli wszyscy pracują nad stworzeniem i utrzymaniem tego samego produktu, komunikacja między zespołami będzie niezwykle ważna.

Zacznij myśleć o analityce jako kluczowym punkcie projektowym w zapleczu swojego produktu. To nie tylko coś, do czego przyczepiasz się po dostarczeniu funkcji, ale integralna część SDLC.

Wiele firm, zwłaszcza z branży technologicznej, będzie już swobodnie korzystać z narzędzi do współpracy i dzielenia się wiedzą, takich jak Jira, Slack i oczywiście Amplitude. Jeśli pasjonujesz się wdrażaniem silniejszych procesów współpracy w swojej organizacji, radzimy, abyś przedstawił swoją sprawę chętnym . Uzyskanie poparcia dla nowych procesów jest często najtrudniejszą częścią.

Nie ma potrzeby wymyślania koła na nowo. Zastosuj istniejące procesy, które już działają.

Dość często przyjmowanie nowych procesów (takich jak efektywna współpraca w zakresie analiz) nie ma prawie nic wspólnego z technologią, a wszystko z kulturą. Jeśli chodzi o analitykę, wiedza nie istnieje w pojedynczej osobie lub zespole — wszyscy muszą ze sobą współpracować, aby jak najlepiej wykorzystać dane.

Należy zauważyć, że nikt nie przyjmie nowego procesu (bez względu na to, jak dobry jest), jeśli nie zobaczy jego sensu. W praktyce świetnym sposobem na uzyskanie akceptacji nowego procesu w całej firmie jest wykazanie wartości tego procesu poprzez porównanie go z innymi istniejącymi wcześniej. Kilka przykładów:

GitHub: Nie przesadzę, jeśli powiem, że praktycznie każda osoba/firma/organizacja tworząca oprogramowanie korzysta z GitHub. Jest to bardzo elegancki, ale zakodowany na stałe proces: każdy napisany fragment kodu podlega rozgałęzieniu, zatwierdzeniu i scaleniu. Tak więc Github jest w rzeczywistości mniej narzędziem, a bardziej procesem: po prostu nie działałby, gdyby wszyscy go nie używali.

Figma: narzędzie, które doskonale demonstruje bezproblemową współpracę między zespołami; Figma umożliwia projektantom produktów przekazanie deweloperom prototypów, które wyraźnie pokazują, w jaki sposób wszystkie elementy pasują do siebie. Wskazówka: skorzystaj z narzędzia Amplitude Event Planner w aplikacji Figma.

Amplitude jest tutaj, aby pomóc Ci współpracować

Przydatne jest myślenie o funkcjach zarządzania danymi Amplitude jako o GitHubie do celów analitycznych. Amplitude ułatwia przejrzysty, podlegający audytowi proces planowania wydarzeń, w który może być zaangażowany każdy kluczowy interesariusz, niezależnie od umiejętności technicznych.

Najlepsze procesy to te, których nawet nie zauważasz: mamy narzędzia programistyczne, dzięki którym nikt nie zakłóca przepływu pracy, umożliwiając inżynierom łatwe i dokładne wdrażanie śledzenia analitycznego za pomocą bezpiecznych pod względem typów zestawów SDK typu open source, CLI i CI/CD integracja.

Amplitude to przede wszystkim platforma współpracy, wymuszająca wiarygodne źródło prawdy do analiz. Oznacza to, że ci, którzy konsumują dane, wiedzą , że mogą im ufać. Jeśli uzyskałeś znaczące poparcie dla nowych procesów współpracy, Amplitude z pewnością może odegrać rolę w ich wspieraniu. Poproś o bezpłatną wersję demonstracyjną i rozpocznij eksplorację już dziś.