Zespoły deweloperskie czasem poruszają się po produkcie jak żeglarze bez mapy. Mają statek i narzędzia, a za cel – dostarczenie funkcjonalności. Jednak bez punktów odniesienia łatwo zboczyć z kursu, kręcić się w kółko albo naprawiać coś, czego nikt nie używa. Tymczasem nad naszymi głowami od zawsze świecą gwiazdy – różnorodne dane o naszym produkcie. Można z nich odczytać kierunek, ocenić ryzyko, zaplanować trasę i wspólnie z biznesem płynąć do jednego portu. Trzeba tylko nauczyć się w nie patrzeć.
W tym artykule opowiadam, dlaczego warto, aby zespół deweloperski sięgał po dane produktowe, jak może to robić na co dzień i jakie realne korzyści mogą z tego wynikać. Wiele zespołów deweloperskich nie przygląda się danym o zachowaniu użytkowników – według nich jest to coś, czym zajmuje się biznes. Z drugiej strony, przedstawiciele biznesu mogą nie widzieć konieczności dzielenia się tymi danymi z zespołem deweloperskim. Nie jest to spowodowane chęcią zatrzymania informacji, ale bardziej przekonaniem, że dostęp do takich danych nie wpłynie znacząco na pracę zespołu deweloperskiego. Często bowiem relacje biznesu z IT postrzegane są przez obie strony jako relacja klient – dostawca, a przecież to właśnie ta różnorodność może wzbogacić produkt. Nie w każdym zespole znajdują się dedykowane osoby, które zajmują się analityką produktową. Nie zawsze jednak trzeba być specjalistą, aby wprowadzać kulturę wykorzystywania danych w organizacji. Wystarczy chęć do nauki i inicjatywa.
Które gwiazdy chcemy obserwować?
Kiedy w moim produkcie cyfrowym wprowadzano narzędzie do analityki, musieliśmy odpowiedzieć sobie na pytanie – jakie dane właściwie chcemy zbierać jako zespół deweloperski. Część wymagań dostaliśmy od biznesu i uzupełniliśmy je swoimi, bazując na naszym spojrzeniu na produkt. Dzięki temu zakres zbieranych danych jest maksymalnie szeroki. Inspirację stanowiły dla nas metryki z różnych grup, które przedstawione są na Rys. 1. Dodatkowo koncepcja ta zakłada, że podobnie jak w piramidzie Maslowa, tylko zadowalający poziom metryk na niższym poziomie pozwala przejść na wyższe piętro. Czyli produkt, który cechuje się wysoką awaryjnością, nigdy nie osiągnie wystarczającego poziomu zadowolenia użytkowników, a więc nigdy nie zdobędzie wystarczającej liczby lojalnych użytkowników i nie spełni celów biznesowych. Wybór metryk uzależniony jest oczywiście od specyfiki produktu i obszaru biznesowego. Rys. 2. przedstawia kilka przykładowych metryk produktowych, które zbierane są w aplikacji służącej do sprzedaży ubezpieczeń.
Co możemy wyczytać z mapy nieba?
Poniżej przedstawiam kilka przykładów wykorzystania danych w moim zespole deweloperskim.
- Analiza urządzeń wykazała, że rośnie procent użytkowników korzystających z telefonów komórkowych. Dostarczyło nam to argumentów, aby przekonać biznes do inwestycji w RWD (Responsive Web Design), co uatrakcyjni naszą aplikację na urządzeniach mobilnych. W pierwszym kroku część aplikacji otrzymała RWD. Następnie nadal analizowaliśmy dane i sprawdzaliśmy, czy warto inwestować w RWD w kolejnych częściach aplikacji.
- Jeśli poziom wykorzystania nowych funkcjonalności jest wysoki, warto rozmawiać z biznesem na temat udoskonalania ich. Można to postrzegać również w drugą stronę. Z pewnością każda aplikacja ma takie miejsca w kodzie, których utrzymanie sporo kosztuje i przyprawia o ból głowy. Jeśli wykorzystywanie takich funkcjonalności nie generuje dużo wartości, łatwiej przekonać lubiący cyferki biznes do jej ograniczenia lub wyłączenia.
- Analiza nawigacji pokazała, że użytkownicy chętniej do przechodzenia między krokami procesu używają buttonów niż klikanych ikonek. Jest to (o dziwo!) odwrotna preferencja niż ta w zespole deweloperskim. Stąd też, kiedy dodajemy coś nowego w procesie, musimy pamiętać o dodaniu w pierwszej kolejności nawigacji w postaci buttonów.
- Audyt UX wykazał, że na jednym ekranie znajdują się trzy buttony w różnych miejscach, które prowadzą do tej samej strony. W celu „wyczyszczenia” wyglądu aplikacji padła propozycja, aby zmierzyć liczbę kliknięć i na tej podstawie wybrać najbardziej popularny button. Okazało się jednak, że kliknięcia rozkładały się równomiernie, więc pozostawiliśmy wszystkie buttony, żeby nie irytować użytkowników.
- Analiza najczęstszych błędów może wskazać, które walidacje lub logiki są niezrozumiałe dla użytkowników. Na podstawie najczęściej występujących błędów planujemy stworzenie wirtualnego asystenta, który przeprowadzi użytkownika przez dany proces.
- Deweloperzy zgłosili, że konkretne zachowanie użytkownika wywoła błąd systemowy. Od razu można było sprawdzić częstość występowania takiego zachowania, aby zorientować się, jak priorytetowo potraktować dane ryzyko błędu.
Jak uformować flotę morską?
Zespół deweloperski w różny sposób może przyczynić się do budowania w organizacji kultury podejmowania decyzji w oparciu o dane.
Przede wszystkim warto, aby osoby chętne do zajęcia się analityką ustaliły sobie regularny czas, w którym spojrzą na aktualne dane i będą rozwijać tworzone raporty. Zyska na tym z pewnością nasz produkt, ale również my sami, ponieważ to doskonała okazja do rozwoju i podnoszenia kwalifikacji.
Bardzo dobrze sprawdza się klarowna dokumentacja – źródło prawdy na temat zbieranych danych. Dążymy bowiem do osiągnięcia wspólnego zrozumienia – legendy, używane pojęcia czy też definicje metryk powinny być zrozumiałe dla wszystkich, niezależnie od strony barykady.
Osoby, które zajmują się analityką, mogą w ramach Community of Practice dzielić się wiedzą z innymi członkami zespołu lub z innymi zespołami. Sprawia to, że osoby techniczne uzyskują dostęp do pełnego kontekstu, w jakim używane są tworzone przez nich produkty cyfrowe, co pozwala im działać samodzielnie oraz proponować rozwiązania dopasowane do ograniczeń biznesowych i preferencji użytkowników. Mój zespół organizuje cykliczne spotkania dla biznesu, na których dzielimy się naszymi wnioskami z analityki produktowej. Pokazujemy nasze spojrzenie na dane, które pięknie uzupełnia spojrzenie strony biznesowej. Wspólnie z naszymi interesariuszami zastanawiamy się, jakie dane powinny być jeszcze zbieranie i analizowane.
Z czasem jako zespół deweloperski osiągnęliśmy dojrzałość i w przypadku implementowania nowych funkcjonalności zawsze myślimy już o dodaniu ich do analityki. Zakres danych, które zbieramy, ciągle ewoluuje – tak, jak nasz produkt.
Przez długi czas dane produktowe były postrzegane jako coś zarezerwowanego dla biznesu – niczym luneta w rękach kapitana, do której załoga nie ma dostępu. Ale dziś, w dojrzałych organizacjach, każdy może spojrzeć w gwiazdy. Zespół deweloperski, który rozumie produkt i użytkownika, przestaje być tylko wykonawcą – staje się równorzędnym partnerem dla biznesu w tworzeniu produktu. Dane nie muszą być trudne. Wystarczy ciekawość, odrobina systematyczności i otwartość na współpracę. Bo gdy wszyscy patrzymy w tym samym kierunku, znacznie łatwiej płynąć przez wzburzone morza.
Zawodowo analityczka biznesowa w IT. Nieustannie poszerza swoją wiedzę oraz szuka nowych inspiracji. Uwielbia pracę zespołową i pozytywną energię, jaka się przy niej wyzwala. W wolnych chwilach ćwiczy fitness na stepie oraz przemierza kolejne kilometry na rowerze. Nie wyobraża sobie życia bez podróży i poznawania świata.
Renata works as a business analyst in IT. She is constantly expanding her knowledge and looking for new inspirations. She loves teamwork and the positive energy released by it. In her free time, Renata practices step fitness and rides her bicycle. She can’t imagine life without traveling and exploring the world.