Rzeczy, które mi sie nie udały

To, co nam się udaje, udaje się podwójnie ponieważ chcemy się tym chwalić. To, co się nie udaje chcemy ukrywać, bo pokazuje nie-100%-skuteczność, a to źle działa na wizerunek na fejsie. Nassim Nicholas Taleb w “Fooled by Randomness” walczy z archetypem zwycięzcy na wiele sposobów, ale najwyraźniej widać to na przykładzie giełdy. Opisuje wiele mechanizmów prowadzących ostatecznie do tego, że ludzie, którym wielokrotnie udało się dobrze obstawić uważamy za geniuszy o nadprzyrodzonych mocach mimo tego, że to, po prostu, statystyka (i survival bias). 

W 2014 roku byłem zaproszony jako gość na Olcamp, olsztyńskie spotkania branży technologicznej. Paweł Harajda przedstawiając mnie poprowadził prostą linię pokazującą moją ewolucję zawodową – najpierw Aula Polska, później Proseed, później o2.pl, później Senfino (wtedy jeszcze książka była na bardzo wczesnym etapie). Nawiasem mówiąc, to była bardzo innowacyjna forma konwersacji – po każdym zadanym pytaniu osoby na scenie musiały wypić shota wódki (takie rzeczy tylko w Olsztynie). Uderzyło mnie wtedy (ze zdwojoną siłą dzięki alkoholowi), że patrząc z perspektywy czasu na moją przeszłość to faktycznie, wszystko ładnie się układa i do siebie pasuje. Poprzednie doświadczenia przydają się w następnej pracy: organizacja w Auli Polskiej dała materiały na łamy Proseeda. Praca w Proseedzie otworzyła drzwi do mnóstwa zamkniętych gabinetów… i tak dalej.

Ktoś patrząc z zewnątrz może mieć wrażenie, że to perfekcyjnie przygotowany masterplan a każdy kroczek przybliża do przysłowiowej dominacji nad przysłowiowym światem (dokumentuję ją na moim vanity page). Ale to bullshit, bo ta droga usłana była mnóstwem zakrętów i problemów, przez które do tej pory zgrzytam zębami (ale tego już w vanity page nie ma).

Dzisiaj zobaczyłem w sieci artykuł o anty – CV profesora z Princeton: listę wszystkich nagród, programów i grantów, których nie otrzymał. Czytając zacząłem sięgać do moje pamięci i tworzyć własną listę. Im dłużej grzebałem tym więcej sobie przypominałem:

  • Nie dostałem się na studia dzienne. Wpakowałem w maturę całą moją energię i po wzorowym jej zdaniu puściły mi wszystkie nerwy. Zresztą uważałem, że skoro matura poszła super, to egzaminy na studią będą błahostką. NOPE. Nie dostałem się nigdzie, zawaliłem wszystkie wymarzone kierunki (tak się akurat złożyło, że chciałem iść na ekonomię na UW, SGGW i SGH –  mieszankę trudnych egzaminów i dużej popularności, not smart). Załamany tym wszystkim wybrałem pierwsze studia, które brzmiały sensownie, ale były na publicznej uczelni – wieczorową Europeistykę. Studia były płatne, więc przyjmowali wszystkich,
  • 2009 rok, studia. Uważam, że musze skupić się na nauce (=imprezowaniu) i nie jestem stworzony do pracy. No chyba, że załapię się na jakiś program staży managerskich. Wziąłem udział w rekrutacji na taki program do firmy Emperia. Wyglądało to tak, że na przedmieściach Warszawy 10 studentów przez pół dnia siedziało w salce próbując rozwiązać wspólnie (ale rywalizując) case study. Nie miałem pojęcia co to case study. W każdym rogu pokoju siedziała osoba z HR skrzętnie notując nasze zachowanie. Nie dostałem się. Ale nie to było najgorsze, bo na koniec otrzymałem wyniki mojego “assessment center”: Skala była następująca: 0 (brak ujawnienia się kompetencji), 1 (bardzo niski poziom), 2 (niski poziom), 3 (przeciętny poziom)… dalej skala już mi się nie przydała.
  • W tym samym 2009 roku pomyślałem, że skoro polskie firmy się na mnie nie poznały to trzeba poszukać szczęścia na zagranicznych uczelniach. Ambitnie wybrałem sobie dwa programy wymiany studentów: Monbukagusho Scholarship i stypendium Fulbrighta – nie mając ani odrobiny realnego researchu (o tym, żeby porozmawiać z absolwentami tych programów przyszło mi do głowy kilka miesięcy później). Najbardziej bolała negatywna odpowiedź z Fulbrighta – zabrakło mi 1 punkta, żeby się dostać. To było nawet zastanawiające, biorąc pod uwagę, że zapytany przez ambasadora USA nie wiedziałem jakie jest tuition na wybranej przeze mnie uczelni. Przy Monbukagusho trzeba było mieć formalną rekomendację Ambasady Japonii (ale o tym dowiedziałem się dużo po fakcie), więc nawet mi nie odpisali,
  • Moją niechęć do pracy kontynuowałem w wyszukiwaniu sobie coraz to nowszych programów wyjazdowych. Studiując we Wrocławiu wkręciłem się w AISEC (międzynarodowa organizacja studencka) tylko po to, żeby móc wyjechać jak najdalej, najlepiej do Chin albo Indii. Aby to się mogło udać, trzeba było znaleźć w bazie danych organizacji kogoś, kto chciałby się ze mną zamienić miejscami i postudiować w Polsce tyle, co ja w u niego. Uwziąłem się, żeby dziennie wysyłać 20 personalizowanych wiadomości i tak – było mnóstwo Chińczyków i Hindusów, którzy chcieli studiować za granicą, ale nikt nie chciał wymienić się ze mną. Nawet po 400 próbach,
  • Cały czas będąc na moich wieczorowych studiach szukałem sposobu, aby przenieść się na dzienne, więc startowałem w rekrutacjach z nadzieją, że mi przepiszą wyrobione przedmioty. Rekrutacja po drugim roku – pudło na UW i pudło na SGH, rekruatacja po trzecim roku i znów pudło na UW i pudło na SGH,
  • Gdy wreszcie zakończyłem studia Europeistyki po pięciu latach mój własny tata się mnie zapytał: “No dobrze synu, co teraz?”. A ja miałem pustkę, bo to, co potrafiłem wymienić to całkiem niezłe portfolio epickich pijackich imprez (lokalnie i zagranicą), kilka zwiedzonych krajów i siatkę znajonych z Erasmusa. Ale pytanie, jak zamierzam spieniężyć te assety pozostawało otwarte…
  • …w związku z tym zrobiłem jedyną rzecz jaka przyszła mi do głowy: po raz czwarty wystartowałem w rekrutacji na SGH,
  • aby znów się nie dostać. Ale “zapraszają na studia wieczorowe”,
  • Zacząłem więc studia uzupełniające z “Finansów i Rachunkowości” na SGH, aby wreszcie nauczyć się czegoś, co da mi realne, potrzebne na rynku pracy umiejętności. “Finanse”, które były matematyką i “Rachunkowość”, która była dla mnie najnudniejszą rzeczą na świecie. Ale cieszyłem się bardzo, bo to SGH i znów byłem studentem,
  • Jakimś cudem, przy piątej próbie, udało mi się dostać na studia dzienne na SGH – z których zostałem wywalony rok później przez błąd w systemie zaliczeń egzaminów,
  • Gdy udało mi sie wywalczyć powrót na pełni praw stwierdziłem że nic mnie na tej uczelni nie trzyma. Moja ambicja dostania się na SGH została spełniona, ale do tego, żeby tam wytrzymać już nie miałem serca,

[mija kilka lat]

  • Po jednej z burzliwych dyskusji z moim ówczesnym szefem zostałem poproszony na rozmowę z szefową HR. Szefowa HR w małym pokoiku bardzo delikatnie zakomunikowała, że w wprawdzie docenia moją pracę, ale jednak nie mam w sobie “tego czegoś”. Jestem za mało wytrwały, zbyt szybko się irytuję i powinienem mieć grubszą skórę – po prostu nie jestem dobrym materiałem na managera, szczególnie w nowych technologiach.

Nie, tutaj nie będzie porywającego, coachowego podsumowania typu “mogę wszystko!”. No, nie mogę wszystkiego. Ale na pewno znacznie więcej niż mówi mi ten pieprzony assessement center.

Niedziela, 14:42

Niedziela, 14:42.

Marcin G. zajmujący się w PizzaPortal social media wysłał maila o niespotykanie dużej liczbie komentarzy na Facebooku o zamkniętych w środku dnia restauracjach w PizzaPortal.pl na terenie Rumii, Białegostoku i Gdyni. Przeczytałem to szybko, sprawdziłem, że na moim iPhonie wszystko ok, na wszelki wypadek sprawdziłem także mobile web – nie widać nic podejrzanego. 

Na szybko w głowie znalazłem kilka powodów takiej sytuacji: chwilowa przerwa z dostępem do prądu w restauracjach, statusy ich dostępności nie odświeżyły się na czas jak w innych kanałach. Subiektywne połączenie kilku odseparowanych przypadków… Jednym słowem – wysokie prawdopodobieństwo fałszywego alarmu.

Chwilę później dostajemy wiadomość, że “Gdańsk także padł”. O 14:58 pisze do mnie Adam, nasz product owner, że sprawa zaczyna wyglądać poważnie. Minutę później zaczynamy rozmawiać przez telefon, w tym czasie zdążyłem już rozłożyć moje mobilne biuro w kawiarni na Saskiej Kępie obok której przechodziłem z moją Pauliną (widząc co się dzieje Paulina poprosiła o menu).

Podczas rozmowy sprawdziłem statystyki: zamówień wykonanych na Androidzie są trzykrotnie mniej niż powinno być w stosunku do analogicznych niedziel o tej samej porze, ale nie zauważyłem żadnych problemów z innymi platformami. Adam będąc ciągle na linii potwierdza, że aplikacja PP na Androidzie w każdym sprawdzanym mieście pokazuje wszystkie restauracje jako zamknięte. Czyli to już nie tylko Trójmiasto i Białystok…

Zaczynam w głowie wyliczać potencjalne hipotezy. Z nich ta,  że problem jest ograniczony tylko do Androida zaczyna mieć największy sens. Ma to swoje dobre i złe strony. Dobra jest taka, że tylko jeden kanał jest odcięty a zła, że to nie jest tymczasowa usterka całego backendu a systematyczny błąd.

Gdyby problem pojawił się na więcej niż jedna platformie to nasze poszukiwania skierowałyby się w stronę API, ale wszystko wskazywało na problem z samą aplikacją. Poprosiłem Adama, aby odczekał jeszcze 10 minut i jeśli nic się nie poprawi to żeby napisał wiadomość na specjalną skrzynkę Emergency do naszego działu IT Ops – chciałem dać ostatnią szansę przypadkowi. Kiedy my będziemy sprawdzać hipotezę z aplikacją, IT Ops zajmie się tematem API.

15:23. Informuję na kanale na Slacku nasz zespół w Senfino o problemie. Dawid (proxy product owner) z Marcinem L. (Android Dev) zaczynają analizować sytuację.

15:33. Wysyłam na grupę mailową managementu PP trzyakapitowe streszczenie sytuacji.

15:37. Przychodzi zamówiona przez Paulinę sałatka.

15:40. Dzwoni Tomek (CEO Senfino) i zestawia trójstronne połączenie z Dawidem (proxy product owner po stronie Senfino). Mamy dwie kwestie do przedyskutowania: skąd wziął się problem oraz, ważniejsze w tym momencie, jak możemy ograniczyć szkody.

Okazuje się, że błąd leżał w sposobie parsowania godzin otwarcia restauracji. Informacje o niedzieli podawane w API zostały źle zinterpretowane przez klienta (aplikację na Androidy). W poniedziałek sześć dni wcześniej wrzuciliśmy do Google Play wersję z ogromną dawką refactoringu kodu, w którym godziny otwarcia była jedynie małym fragmentem poprawek.

Ten błąd był na tyle paskudny, że jedynie dawał znać o sobie w niedzielę, więc nasze standardowe QA działające od poniedziałku do piątku nie miało jak go wykryć. W każdym razie błąd został znaleziony. Teraz tylko musimy szybko go naprawić, aby ograniczyć problemy.

Rozważaliśmy powrót do poprzedniej, działającej wersji, ale robiąc tak stracimy mnóstwo wartościowych poprawek, a także nasz nowy system wysyłania wiadomości do użytkowników wewnątrz aplikacji. Inną opcją było jak najszybsze wdrożenie poprawki i wgranie niej do Google Play. Obydwie z tych możliwości nie były dobre z prostego powodu: użytkownicy Androida bardzo wolno przechodzą na nową wersję software’u – większość z nich zauważyłaby aktualizację dopiero w przyszłym tygodniu, a my musimy zrobić coś teraz.

Zbliżał się wieczór, początek zwiększającego się ruchu w naszym serwisie.

Ostatecznie Tomek z Dawidem wpadają na pomysł, aby wykorzystać właśnie wdrożony system do komunikacji z użytkownikami, aby przekierować ruch z aplikacji na stronę mobilną. Każdy, kto otworzy aplikację zobaczy pełnoekranową informację, że aplikacja ma dzisiaj gorszy dzień i zapraszamy pod adres mobile.pizzaportal.pl aby wykonać zamówienie. Takie rozwiązanie nie będzie wymagało aktualizacji aplikacji, a jedynie stworzenia specjalnej kampanii reklamowej.

System komunikacji to jednak kawałek królestwa Ewy, nasze szefowej marketingu. Najpierw chcę uzyskać od niej zgodę na skorzystanie z tej metody (która może być inwazyjna dla niczego nie spodziewającego się użytkownika).
15:47. Ewa nie odbiera telefonu.

15:49. Dzwonię do Lecha, CEO PizzaPortal.pl. Tłumaczę sytuację, mówię, że nie możemy czekać. Lech daje zielone światło na akcję.

15:56. Informuję zaintresowane strony, że idziemy z planem wysłania wiadomości do użytkowników. Dawid zaczyna konfigurować komunikat – nabrał w tym wprawy przy implementacji i testowaniu systemu.

16:08. Ewa oddzwania. Tłumaczę sytuację do tego miejsca, nie może osobiście pomóc bo właśnie jedzie samochodem. Kontaktuje Dawida z Alicją z marketingu, która jest w domu przed komputerem i sprawdzi ze swojej strony poprawność konfiguracji wysyłki.

16:10. Czas posprzątać bałagan i powiązać ostatnie sznurki. Management PP dostaje aktualizację z naszym proponowanym rozwiązaniem. Customer Care i Social Media także. Kończymy z Pauliną sałatkę.

16:36. Dawid wysyła testową wiadomość. Zdzwaniamy się po raz jeszcze raz, aby poprawić ostatnie rzeczy. Spacerujemy już z Pauliną przez Saską Kępę do domu.

16:57. Nasze rozwiązanie jest aktywne. Rozmawiamy na Slacku o tym, że koniecznie musimy uodpornić nasze QA na ten przypadek – będziemy o tym dyskutować w poniedziałek na naszym product planningu.

Dotarliśmy pod nasze mieszkanie. Zasłużyliśmy na herbatę.

Straty tego dnia z braku zamówień na Androidzie bolą – nasza niedziela była całościowo gorsza o około 5% od standardowej. Widać to dobrze na wykresie zamówień poniżej – spadek niebieskiej linii 6.03 to właśnie omawiany przypadek. Nie ma jednak powodu, aby obwiniać kogoś (czy też siebie) za błąd popełniony po raz pierwszy tak jak w tym przypadku. Z czystej statystyki wynika, że przy tak wielowymiarowym produkcie to po prostu musi się zdarzyć. Ważne jest jednak jak się na nie reaguje.

  
Sytuacje takie jak ta mają swoją dynamikę podyktowaną emocjami. Wszyscy szukają klucza do zrozumienia co tak naprawdę się stało – i muszą to zrobić szybko, bo każda minuta to niezrealizowane zamówienia, a więc utracone pieniądze. Łatwo więc wpada się w paranoje i podważa swoje umiejętności, a emocje i stres potrafią doprowadzić do niepotrzebnej paniki. Dokładnie wtedy, gdy ważna jest koncentracja i jasne myślenie.

Ps. Ten wpis publikuję już po wdrożeniu poprawki i sprawdzeniu, że następnej niedzieli było już wszystko w najlepszym porządku:)

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.

Screenshot at sty 15 23-30-23
Makiety pierwszych kroków zamawiania jedzenia w PP

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.

pizza_portal_red1

 

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.

Screenshot at sty 15 22-59-13

Ś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.

IMG_3586
Czerwone linie: potencjalne wejścia z wyszukiwarki. Zielone linie: niestandardowe skakanie użytkownika między ekranami

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.

Screenshot at sty 20 10-18-24

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.

92DE9349-8ABD-4B09-AEA5-A7961137AB0B
Głosowanie na najciekawsze funkcje przyszłego produktu podczas Design Sprintu

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:)

preloader_pizza_2x
Ładowanie opcji konfiguracji jedzenia
Dodawanie do koszyka
Dodawanie do koszyka

 

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.

Zrzut_ekranu_15.01.2016__22_23
Raport ze split testów

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.

Screenshot at sty 20 10-15-08
Wersja finalna

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

Screenshot at sty 10 14-05-30
21 grudnia – premiera nowej strony

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.

Screenshot at sty 13 13-17-56

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.