Jak powstawał nowy serwis mobilny PizzaPortal.pl

Wraz z objęciem roli szefa produktów w PizzaPortal.pl jednym z moich pierwszych zadań było zweryfikowanie stanu obecnych stron i aplikacji oraz przygotowanie planu ich rozwoju.

Zdecydowałem się zacząć od stworzenia zupełnie nowej strony mobilnej. To był wtedy (jeszcze) względnie mały procentowo kanał sprzedaży więc pozwalał na odważniejsze eksperymenty – nawet jeśli efekt finalny okaże się słaby to wpływ na bottom line byłby do przełknięcia. Z drugiej strony miałem przeświadczenie, że mobile web to klucz do odblokowania potencjału tego fragmentu rynku.

W połowie czerwca przejąłem więc kontrolę na rozwojem nowej strony mobilnej PP ustawiając jej powstanie jako podstawowy priorytet na 2015 rok. 21 grudnia, czyli prawie pół roku później, serwis publicznie wystartował i po miesiącu generuje 2.5-3 krotnie więcej zamówień niż poprzednia wersja. Poniżej przeczytacie jak do tego doszło.

Sytuacja zastana

Sam koncept na nową stronę mobilną pojawił się w organizacji jeszcze przed moim przyjściem. Jednak brak jasnej ścieżki spowodował, że kształt produktu wynikał z doraźnych potrzeb zaangażowanych działów. Gdy brakuje faktycznego właściciela filtrującego potrzeby interesariuszy to efektem jest „design by committee”. Prowadziło to do sytuacji, gdy nad jedną dostarczoną grafiką wypowiadało się dziesięć osób z których każda dodawała swoje 3 grosze. Dużo było opinii, mało decyzji.

Efekt był taki, że strona główna była przeładowana informacjami do tego stopnia, że na smartfonach naszych klientów nie mieściła się cała. Ale za to mamy duże logo! I do tego mówimy jak zamawianie u nas jest proste zamiast pokazać to na faktach.

 

Pierwszym krokiem jako Product Owner było zrewidowanie tego, co już zostało zrobione z tym, co faktycznie ma być zrobione. Każdy interesariusz dowiedział się, że to ja teraz ponoszę odpowiedzialność za produkt, co też daje mi prawo (i obowiązek) podejmowania decyzji o rozwoju produktu. Stałem się też SPOC (Single Point of Contact) dla wszystkich, którzy w jakikolwiek sposób byli zaangażowani w rozwój nowej strony mobilnej – niezależnie czy chcieli dodać istotną dla nich funkcję czy pytali się jaki ma być kolor przycisku.

W praktyce oznaczało to, że ciągle mówiłem „nie” we wszystkich możliwych odmianach („nie teraz”, „świetny pomysł na future dev”, „nie, dopóki X jest nie zrobione” itd.). Choć brzmiało to czasami oschle to jednak było potrzebne, żeby faktycznie wyklarować co ma faktyczną wartość i musi być zrobione najpierw.

Sprinty i maraton

Rytm pracy wyznaczały tygodniowe sprinty. W każdy poniedziałek kończył się jeden sprint i zaczynał następny. W tym czasie robiliśmy Review – podsumowanie zmian z ostatniego tygodnia oraz Planning czyli określenie pracy na nowy tydzień.

Pół dnia zajmowały nam te dwie czynności, ale dzięki temu reszta tygodnia była spokojna – choć pierwotnie narzut komunikacyjny wydaje się duży to wraz w wejściem w rytm pracy znacznie ułatwia komunikację a mi dawał kontrolę nad losem produktu.

Tygodniowe iteracje mają jeszcze jedną przewagę: jeśli prace idą w złym kierunku to można szybko reagować i robić korektę kursu minimalizując straty czasu i energii.

Każdy członek zespołu miał dostęp do backloga w Pivotal Trackerze, który stanowił nasze główne narzędzie planowania. W czasie tych 6 miesięcy pracy zostało dowiezionych 35 userstories podzielonych na niezliczoną ilość zadań.

Połączyłem Pivotala z naszym firmowym Slackiem więc każdy zainteresowany w organizacji widział od razu jeśli konkretne userstory zostało wzięte na sprint lub zmieniło swoje miejsce w backlogu.

Ślepe zaułki

W trakcie prac wpadliśmy na wiele pułapek. Dla mnie największa z nich to myślenie o zamawianiu jak o jednorodnym i jednokierunkowym procesie – tak jak przyzwyczaiły mnie do tego aplikacje mobilne. Jednak strona rządzi się swoimi prawami – użytkownik może pojawić się na niej w innym miejscu niż tylko strona główna – na przykład po wpisaniu w wyszukiwarce „Bobby Burger Kabaty” trafia na stronę tej restauracji w naszym systemie. Witryna wtedy musi w sprytny sposób przeprowadzić użytkownika przez proces uwzględniając, że wcześniej nie podał istotnych dla nas informacji.

Problem polegał na tym, że nie mieliśmy jego adresu więc nie mogliśmy mu powiedzieć czy może z niej zamówić – trzeba było przemyśleć jak obsłużyć taką sytuację, żeby nie zamknął strony wkurzony. W aplikacji jest to prostsze: nie zobaczysz listy restauracji jeśli nie wpiszesz swojego adresu.

To zbudowało w nas potrzebę myślenia „nieliniowego” przy korzystaniu z serwisu. Rozpisaliśmy jeszcze raz poszczególne etapy i podstawową logikę zamawiania uzupełniając ją o „zewnętrzny” ruch, który wchodzi na stronę gdzieś w trakcie zaprojektowanego procesu. Na to nanieśliśmy możliwość skakania między etapami i nasze możliwości przenoszenia danych wraz z użytkownikiem.

Taka wizualizacja była ważna, abyśmy wiedzieli gdzie powinniśmy utrzymywać zawartość koszyka użytkownika a gdzie możemy go już wyczyścić. Lub też, tak jak opisałem wyżej, kiedy wymagać podania adresu – przed pokazaniem restauracji czy dopiero przy próbie dodania jedzenia do koszyka. Długo się spieraliśmy co go wkurzy bardziej: brak możliwości sprawdzenia menu bez podania adresu czy poczucie straconego czasu po wybraniu dania gdy okazuje się, że restauracja nie dowozi do miejsca zamieszkania użytkownika.

Takich dyskusji mieliśmy mnóstwo – na przykład czy pozwalać usuwać produkty w checkoucie lub jaką ikona powinna przedstawiać filtrowanie.

Dodawanie, usuwanie i kompromisy

Każdy Planning to zderzanie priorytetów: czy lepiej poprawić design czy popracować nad SEO? Czy ulepszyć obsługę błędów, a może dodać filtrowanie? A może sortowanie wcześniej?

Dyskusje na ten temat długo ciągnęły się podczas naszych poniedziałkowych spotkań. Czasami ich efekty były sprzeczne z intuicją. Na przykład zdecydowaliśmy się wystartować stronę bez jakiejkolwiek opcji sortowania i filtrowania listy restauracji. O wiele ważniejsze było dla nas uruchomienie nowego serwisu, który już przy inicjalnych testach dawał lepsze wyniki niż zwlekanie aż dojedzie nowa funkcja.

I wiecie co się okazało? Nikt nie narzekał na brak filtrowania.

Staraliśmy się sprytnie przyśpieszać cały proces zamawiania. Jedna z największych trudności to wpisywanie adresu na klawiaturze telefonu. Dlatego zawsze pokazujemy podpowiedzi miast i ulic na bazie wpisanych liter.

Teraz jednak poszliśmy krok dalej i nawet bez żadnego wpisywania (wystarczy, że znacznik pokaże się w polu wpisywania, tzw. „focus na inpucie”:) pokazujemy pięć miast z największą liczbą zamówień w naszym systemie. Jest bowiem ponad 75% szansa, że zamówienie będzie pochodzić właśnie z jednego z tych miejsc.

Podczas prac nad mobile webem przeprowadzaliśmy znany z Google Ventures Design Sprint (książka na ten temat) zupełnie innego produktu. Jednym z wniosków, których się nie spodziewaliśmy (takie są najlepsze) było to, że użytkownicy często boją się zamawiać, jeśli nie mogą podać swojego numeru mieszkania na samym początku. Mają bowiem przypuszczenie, że nikt się ich o to nie zapyta w dalszym procesie zamawiania, więc ostatecznie ich jedzenie trafi do sąsiada albo na inne piętro.

Intuicja podpowiada, że im mniej pól do wypełnienia tym lepiej, ale nasi użytkownicy dali nam do zrozumienia, że jest pewna granica, po przekroczeniu użytkownik której traci kontrolę, a w efekcie zaufanie do procesu. Rozwiązaniem tego dylematu było dla nas dodanie nieobowiązkowego pola „nr mieszkania” na pierwszym ekranie.

Przez „środkowe” miesiące naszej pracy niewiele zmieniało się wizualnie. Ja sam jako Product Owner zaczynałem się frustrować jak zadawano mi pytania jak idzie projekt i jedyne co mogłem powiedzieć to, że dobrze – „programiści programują”. Tymczasem ja nie miałem co pokazać – zmiany wizualne w prototypie nie odzwierciedlają ogromnej pracy wykonanej na poziomie logiki systemu co daje poczucie, że nic nie posuwa się do przodu.

Ostatecznie jednak, gdy przyszła pora na łączenie ze sobą elementów widocznych dla użytkownika z faktycznych silnikiem to szybkość zmian była więcej niż satysfakcjonująca.

Jednym z naszych wąskich gardeł jest ekran konfiguracji dania. Ze względów logiki systemu, zaszłości technologicznych a przede wszystkim liczby możliwych konfiguracji  jedzenia ten ekran potrafił się ładować i przesyłać dane z opóźnieniem. To, z perspektywy użytkownika, mogło oznaczać, że strona nie działa. Aby zniwelować takie poczucie dodaliśmy… cóż, dodaliśmy to co wszyscy lubią najbardziej – GIFy:)

 

Jedną z głównych motywacji zmiany strony mobilnej była jej niska czytelność dla crawlerów wyszukiwarek przez co musieliśmy zwiększać nasze nakłady na SEM, aby nadrobić niską skuteczność SEO. Faktyczny problem powstał jednak, gdy Google ogłosił w kwietniu 2015 zmiany w swoim algorytmie, czego efektem było stawianie w wynikach wyszukiwania wyżej stron, które mają wersje mobilne. Branża SEO nazwała to „mobilegeddonem”. Dlatego tworząc nową stronę od samego początku myśleliśmy o transparentnej strukturze danych, łatwej do przyswojenia przez Google’a.

Testowanie

Nawet jeśli mobile web nie jest najważniejszym kanałem sprzedaży w PP to jednak proces podmiany starego serwisu na nowy musi być przeprowadzany w przewidywalny i bezpieczny sposób.

9 grudnia rozpoczęliśmy współpracę z zespołem A/B testów z naszego berlińskiego biura. Do tej pory ten zespół zajmował się optymalizacją poszczególnych elementów, aby małymi krokami podwyższać konwersję (np. przez zmianę koloru przycisków albo wielkości zdjęć). My natomiast postawiliśmy przed nimi zadanie na zupełnie nowym poziomie: a co jeśli chcemy zrobić split testy dwóch zupełnie różnych stron, aby sprawdzić czy to, co stworzyliśmy faktycznie działa w dużej skali?

To było poważne wyzwanie, które wymagało naukowego badania i skoordynowania kilku systemów (Visual Website Optimizer i Advanced Segmentation w Google Analytics) do badania efektów statystycznych z uwzględnieniem odpowiedniej wielkości próbki i poziomu istotności. Postawiliśmy na środowisku produkcyjnym alternatywną stronę z przedrostkiem beta i codziennie patrzyliśmy na raport z fluktuującymi wynikami % Delta eCom CVR.

Chcieliśmy nasze testy wykonywać w jak najmniej inwazyjny sposób więc zaczynaliśmy z niskiego pułapu i zwiększaliśmy z czasem próbkę. Na samym początku z całego ruchu wyznaczyliśmy i oflagowaliśmy 10% użytkowników, którzy zobaczą nową stronę mobilną. Następne 10% zobaczy starą stronę ale także zostanie oflagowana – jako grupa kontrolna. Pozostałe 80% ruchu nie uczestniczyło w badaniu.

Wraz z pozytywnymi efektami zwiększaliśmy obciążenie na 20% – 20% i ostatecznie 50% – 50%. To było przydatne także dla naszego zespołu developerskiego, który mógł badań w kontrolowanym środowisku obciążenie i szukać błędów, które mogą stawać się widoczne dopiero przy większej grupie realnych użytkowników.

Ship it!

Efekty testów przeszły całkowicie nasze przypuszczenia. Lech (CEO PizzaPortal.pl) gdy zobaczył wyniki testów zapytał się, ile tracimy dziennie pieniędzy nie mając już zaimplementowanej nowej strony. Gdy to obliczyłem to trochę pobladłem.

Co zrozumiałe, Lech mocno argumentował, abyśmy nie czekali już dłużej i upublicznili stronę jak najszybciej. Ja chciałem jeszcze dać sobie i zespołowi trochę czasu na następne poprawki i resztę funkcji, ale ostatecznie przyśpieszyłem start z 28.12 na 21.12.

I dobrze, że dałem się przekonać. Dopiero presja Lecha pozwoliła mi zauważyć, że mógłbym cyzelować produkt dodając „jeszcze jeden ostatni feature” w nieskończoność. Zreszta, mam takie tendencje patrząc po doświadczeniach z Play24.

Dzień deploymentu – poniedziałek 21.12-  to jednocześnie czas naszej firmowej wigilii w firmie. Gdy inni się bawili my nerwowo zerkaliśmy na telefony pod stołem obserwując na żywo, czy wszystko idzie dobrze, koordynując warszawski zespół developerski, szwedzki dział backendowy oraz nasz łódzko-berliński dział marketingu.

Tutaj jeszcze jedna nauczka: produkt to nie tylko produkt, ale także jego infrastruktura. Nie doceniliśmy ile zamieszania może wywołać podmiana klucza API, podmiana domen i rekonfiguracja usług trzecich w nowym produkcie. Najgorsze jest to, że za każdym razem jest to niezwykle indywidualna sprawa i tak rzadko wykonywana, że brakuje uniwersalnej formuły, dzięki której wszystkie kroki w odpowiedniej kolejności zostaną wykonane.

Efekty

Efekt możecie sprawdzić  tutaj.

Minął już miesiąc od startu tej strony – historycznie jest to dla nas zarówno najgorszy (Gwiazdka) jak i najlepszy czas (1-2 stycznia) jeśli chodzi o zamówienia. Mieliśmy więc możliwość przetestować skrajne sytuacje działania strony. I co się okazało?

Z najgorzej działającego kanału nowy Mobile Web awansuje bardzo szybko w naszym wewnętrznym zestawieniu liczby zamówień na dzień – od razu wyprzedził iOSa a teraz, wraz ze wzmacnianiem się SEO, wyrównuje się już z Androidem. Konsekwentnie, dzień za dniem generuje 2.5-3x lepszą konwersję od poprzedniej wersji. Jest jeszcze jedna wyjątkowa rzecz: nowy Mobile Web ma też najlepszy średni koszyk ze wszystkich kanałów – 40,5 zł. Te dwa fakty powodują, że nowy mobile web nagle stał się zauważalną częścią strumienia przychodów.

I choć pod względem optymalizacji czasu ładowania jeszcze długa droga przed nami to bardzo miło się patrzy na wyniki automatycznych testów Google’a które pokazuję maksymalną liczbę punktów w zakresie wygody użytkowników.

Mój pierwotny plan zakładał stworzenie nowej strony mobilnej w trzy miesiące. Ostatecznie zajęło to prawie dwa razy więcej czasu, co też przekłada się na znacznie wyższe koszty. To jednak jest jeszcze akceptowalne biorąc pod uwagę, że w międzyczasie zespół developerski nam się rozpadł (z pierwotnych czterech osób została tylko jedna) i należało go odbudować niemal od początku – i to w połowie prac. W większości przypadków taka sytuacja prowadzi do zabicia produktu i konieczności rozpoczęcia od nowa. Na szczęście Scrum i transparentność procesu pozwoliły, że nowy zespół szybko wdrożył się w produkt i w znacznym stopniu zniwelował opóźnienia.

Co dalej

Mam silne poczucie, że udało nam się zbudować dobre fundamenty do dalszej pracy a z każdą nową funkcją otwierają się także nowe możliwości. I choć przez te pół roku zrealizowaliśmy 35 userstories to mamy jeszcze 32 następne do wykonania (i ciągle przybywają nowe!). Jednocześnie doświadczenia zebrane przy tworzeniu nowego Mobile Web są dla nas podstawą do prac nad następnymi projektami – tym razem o skalę wielkości większymi. Trzymajcie kciuki!

Dziękuję obydwu teamom dzięki którym ten projekt był możliwy oraz za wiarę Lecha i całej PizzyPortal.pl w moje metody.

ps. w 2013 roku napisałem podobny tekst, ale o powstawaniu innego mojego projektu – Play24.