Filozofia DevOps, gdzie rozwój łączy się z utrzymaniem oprogramowania, nikogo już nie zaskakuje. Nowym trendem, który nabiera mocy, jest DevOps 2.0 lub BizDevOps. Łączy on w jedno trzy elementy: biznes, rozwój i wsparcie. Tak jak w DevOps praktyki inżynieryjne stanowią podstawę połączenia rozwoju z wsparciem, tak w BizDevOps analityka pełni rolę „kleju”, łączącego rozwój z biznesem.
Muszę od razu przyznać: że osiągnęliśmy prawdziwy BizDevOps, dowiedzieliśmy się dopiero teraz, czytając mądre książki. Jakoś samo się to ułożyło dzięki inicjatywie pracowników i nieograniczonej pasji do usprawnień. Obecnie analityka jest częścią procesu produkcyjnego rozwoju, znacznie skracającą pętle feedbacku i regularnie dostarczającą wartościowych informacji. Szczegółowo opowiem, jak to u nas wygląda.
Wady klasycznego DevOps
Kiedy myśli się o nowych produktach dla klientów, biznes tworzy idealny model zachowań klientów i liczy na dobrą konwersję, na podstawie czego ustala swoje cele biznesowe i wyniki. Zespół deweloperski z kolei stara się napisać bardzo dobry, wysokiej jakości kod. Wsparcie natomiast liczy na pełną automatyzację procesów, łatwość i wygodę w obsłudze nowego produktu.
Rzeczywistość zazwyczaj wygląda tak, że klienci otrzymują dość skomplikowany proces, biznes napotyka niski wskaźnik konwersji, zespoły deweloperskie wydają poprawki za poprawkami, a wsparcie tonie w strumieniu zapytań od klientów. Znasz to?
Korzeń problemu tkwi w długiej i niskiej jakości pętli feedbacku wbudowanej w proces. Biznes i deweloperzy, zbierając wymagania i uzyskując feedback podczas sprintów, rozmawiają z ograniczoną liczbą klientów, którzy mają duży wpływ na losy produktu. Często to, co jest ważne dla jednego, wcale nie jest charakterystyczne dla całej docelowej grupy.
Zrozumienie, czy rozwój produktu zmierza w dobrym kierunku, przychodzi razem z raportami finansowymi i wynikami badań marketingowych wiele miesięcy po uruchomieniu. A i one, ze względu na ograniczenie próby, nie dają możliwości weryfikacji hipotez na dużej liczbie klientów. Ogólnie rzecz biorąc, wychodzi długo, niedokładnie i nieskutecznie.
Trofiejne narzędzie
Znaleźliśmy dobry sposób, aby się od tego uwolnić. Narzędzie, które wcześniej pomagało tylko marketerom, trafiło w ręce przedsiębiorstw i deweloperów. Zaczęliśmy aktywnie wykorzystywać analitykę internetową, aby monitorować proces w czasie rzeczywistym, rozumieć, co się dzieje tutaj i teraz. Na podstawie tych danych planujemy sam produkt oraz jego wprowadzenie do dużej grupy klientów.
Jeśli planowane jest jakieś ulepszenie produktu, można od razu sprawdzić, z jakimi wskaźnikami jest związane i jak te wskaźniki wpływają na sprzedaż oraz kluczowe cechy dla biznesu. Dzięki temu można od razu odrzucić hipotezy o niskim wpływie. Na przykład można wprowadzić nową funkcję dla statystycznie znaczącej grupy użytkowników i w czasie rzeczywistym śledzić wskaźniki, aby zobaczyć, czy wszystko działa zgodnie z zamierzeniami. Nie czekać na informacje zwrotne w postaci zgłoszeń czy raportów, lecz samodzielnie monitorować i szybko korygować proces tworzenia produktu. Możemy wprowadzić nową funkcję, a po trzech dniach zebrać statystycznie wiarygodne dane, wprowadzić zmiany jeszcze w ciągu trzech dni — i w ciągu tygodnia mieć gotowy doskonały nowy produkt.
Można śledzić cały lejek, wszystkich klientów, którzy miały kontakt z nowym produktem, odkryć punkty, w których lejek nagle się zawężał, i zrozumieć przyczyny. Zarówno deweloperzy, jak i biznes teraz to śledzą, to część codziennej pracy. Widzą tę samą ścieżkę klienta i razem mogą generować pomysły oraz hipotezy dotyczące usprawnień.
Taka integracja biznesu i rozwoju z analityką umożliwia ciągłe tworzenie produktów, stałe optymalizowanie, szukanie i dostrzeganie wąskich gardeł, a także całego procesu jako całości.
Wszystko sprowadza się do złożoności.
Kiedy tworzymy nowy produkt, zaczynamy nie od czystej kartki, lecz wbudowujemy go w już istniejącą sieć usług. Klient, zbliżając się do nowego produktu, najczęściej kontaktuje się z kilkoma działami. Może rozmawiać z pracownikami centrum kontaktowego, menedżerami w biurze, może skontaktować się z pomocą techniczną, czatami online. Dzięki metrykom możemy zobaczyć na przykład, jakie obciążenie ma centrum kontaktowe, jak najlepiej obsługiwać napływające zapytania. Możemy także zrozumieć, ile ludzi dociera do biura, i zasugerować, jak dalej doradzać klientowi.
Z systemami informacyjnymi jest dokładnie tak samo. Nasz bank istnieje już od ponad 20 lat, w tym czasie stworzono i do dziś funkcjonuje wiele różnych systemów. Interakcje między systemami zaplecza mogą być czasami nieprzewidywalne. Na przykład, w jakimś starym systemie na określonym polu istnieją ograniczenia co do liczby znaków, co czasami powoduje awarie nowego serwisu. Wykrycie błędu standardowymi metodami jest dość trudne, a z pomocą analityki internetowej — wręcz proste.
Doszło do tego, że zaczęliśmy zbierać i analizować teksty błędów z wszystkich zaangażowanych systemów, które pokazują się klientom. Okazało się, że wiele z nich jest przestarzałych, a nie mogliśmy sobie nawet wyobrazić, że w jakiś sposób uczestniczą w naszym procesie.
Praca z analityką
Nasi analitycy internetowi i zespoły SCRUM programistów pracują w tym samym pomieszczeniu. Nieustannie współpracują ze sobą. Gdy zajdzie potrzeba, specjaliści pomagają w ustawieniu metryk lub wyciągnięciu danych, w głównej mierze jednak członkowie zespołów samodzielnie pracują z serwisem analitycznym, gdzie nie ma nic skomplikowanego.
Pomoc jest potrzebna, jeśli na przykład wymagane są jakieś zależności, dodatkowe filtry według ograniczonego typu klientów lub źródeł. Jednak w obecnej architekturze rzadko się z tym spotykamy.
Ciekawe, że wdrożenie analityki nie wymagało instalacji nowego systemu IT. Korzystamy z tego samego oprogramowania, z którego wcześniej korzystali marketerzy. Trzeba było jedynie uzgodnić jego wykorzystanie i wdrożyć w biznesie oraz w rozwoju. Oczywiście nie mogliśmy po prostu wziąć tego, co mieli marketerzy, konieczne było wszystko skonfigurować od nowa i dać dostęp marketerom do nowego środowiska, aby byli z nami w jednym obiegu informacyjnym.
W przyszłości planujemy zakupić ulepszoną wersję oprogramowania do analityki internetowej, które umożliwi nam radzenie sobie z rosnącymi wolumenami przetwarzanych sesji.
Również aktywnie trwa proces integracji analityki internetowej i wewnętrznych baz danych z CRM oraz systemami księgowymi. Łącząc dane, uzyskujemy pełny obraz klienta we wszystkich potrzebnych ujęciach: według źródeł, typów klientów, produktów. Usługi BI, które pomagają wizualizować dane, wkrótce będą dostępne dla wszystkich działów.
Co z tego wynikło? W rzeczywistości uczyniliśmy analizę i podejmowanie decyzji na jej podstawie częścią procesu produkcji, co przyniosło widoczne efekty.
Analiza: nie stąpaj po tym samym palcu
Na koniec chciałbym podzielić się wskazówkami, które pomogą uniknąć uderzenia w ścianę podczas budowania BizDevOps.
- Jeśli nie możesz szybko przeprowadzić analizy, to znaczy, że nie robisz właściwej analizy. Trzeba iść prostą drogą od jednego produktu, a potem skalować.
- Oczywiście musisz mieć zespół lub osobę, która dobrze rozumie przyszłą architekturę analizy. Musisz także wcześniej określić, jak będziesz skalować analizę, integrować ją z innymi systemami i ponownie wykorzystywać dane.
- Nie generuj zbędnych danych. Statystyka internetowa to oprócz użytecznych informacji także ogromny złom z niskiej jakości i niepotrzebnymi danymi. Ten śmieć przeszkodzi w podejmowaniu decyzji i ocenie, jeśli nie ma wyraźnych celów.
- Nie rób analizy dla samej analizy. Najpierw cele, wybór narzędzia, a dopiero później — analiza tam, gdzie przyniesie efekty.
Materiał przygotowany we współpracy z Ołgą Cebotari ().
Źródło: habr.com
