Jak powstawały nowe produkty PizzaPortal.pl

To prawdopodobnie mój najdłużej pisany i najczęściej zmieniany tekst. Zacząłem w styczniu 2016 i pisałem go do teraz - na bieżąco uzupełniając o kolejne zwroty akcji. W związku z tym może się wydawać chaotyczny i niepoukładany - to efekt dodawania kolejnych zwrotów akcji.

Wstęp

Pierwszym punktem planu modernizacji produktowej PizzaPortal.pl była zmiana strony mobilnej. Opisałem to w poprzednim wpisie.

Następny etap to zmiana strona desktopowej. Około 70% wszystkich zamówień pochodzi u nas z „dużej” strony, więc wiedzieliśmy, że właśnie tutaj mieliśmy najlepszą dźwignię. Wdrożenie nowej funkcji na desktopie ma dziesięciokrotnie większy wpływ na biznes niż ta sama na stronie mobilnej (MW). Oczywiste jest więc, że ulepszanie desktopu to nasz najważniejszy cel produktowy – ale też jednocześnie największe ryzyko. Aby jednak nie wypuszczać się na głęboką wodę od razu rozpoczęliśmy zmiany od mniejszego kanału sprzedaży.

Choć o tym nie mówiliśmy głośno, to tak naprawdę nasza nowa strona mobilna miała drugie dno. Jej rozkład był tak przemyślany, aby (koślawo, ale jednak) działała także na dużych ekranach. Choć nie było to optymalne rozwiązanie, to miało dla nas ogromne znaczenie strategiczne.  To fundament, na którym zbudowaliśmy nasz docelowy serwis www i z czego garściami czerpały nasze aplikacje mobilne.

Aby jednak dobrze opisać ten proces, muszę najpierw zrobić jeden krok wstecz i opisać naszą strategię produktową.

Strategia produktowa PP

Po jednej z niezliczonych dyskusji o przyszłości PP zapisałem sobie w notatniku, że nie wiem jakie nasze produkty mają być, ale „za każdym razem coraz lepsze”. To okazał się dobry punkt zaczepienia.

Im dłużej obracałem w głowie to stwierdzenie tym bardziej mi pasowało. Podobały mi się konsekwencje takiego postawienia sprawy, bo to oznacza, że:

1. Nasze produkty nigdy nie są skończone. Widzimy swoje braki i ciągle je poprawiamy,
2. Nie jesteśmy bezduszną maszyną; mamy charakter. Jesteśmy ludźmi, którzy korzystają ze swojego produktu,
3. Jesteśmy częścią ekosystemu, zarabiamy na nim, ale „lepszy” nie oznacza tylko „generujący więcej pieniędzy”.

Brzmi górnolotnie, prawda? Ja jednak lubię mieć nad sobą konkretny sztandar i wiedzieć za czym stoję. Istotne teraz stało się przełożenie tych założeń w praktykę.

PizzaPortal.pl jest usługą masową, skierowaną w domyśle do każdego człowieka z dostępem do Internetu w Polsce. To oznacza, że produktowym imperatywem jest zapewnienie jak największej kompatybilności produktu z urządzeniami użytkowników teraz i w przyszłości.

Do tej pory byliśmy zmuszeni stopniowo „zamrażać” nasze kanały sprzedaży w celu zapewnienia ich zgodności z aktualnie najpopularniejszymi urządzeniami. To jednak zamykało nam coraz bardziej drogę do nowych technologii i typów urządzeń, czyli równaliśmy w dół.

Dodatkowa komplikacja wynikała z mnogości typów urządzeń użytkowników. Nasz statyczny serwis dawał nam bardzo małe możliwości w obsłudze coraz to nowych rozdzielczości, wersji systemów operacyjnych i przeglądarek. Zostawaliśmy w tyle, zamiast być coraz lepszymi.

Sposobem na rozwiązanie tego problemu było podejście catch-all. W systemach mailowych catch-all pozwala na przechwycenie poczty nawet gdy nadawca maila pomyli się w adresie – wystarczy jedynie, że @domena.pl będzie poprawna. To, co przed małpką już nie musi – system będzie wiedział, że mail miał przyjść do kogoś w ramach tej domeny, przechwyci go i wyśle pod adres „catch-all”. Dzięki temu poczta nigdy nie zaginie przez literówkę.

W przypadku PizzaPortal takim mechanizmem „catch-all” ma być właśnie nowy serwis www. To właśnie tam ma być zawsze możliwość zamówienia: gdy nie możesz (lub nie chcesz) zainstalować aplikacji mobilnej lub jeśli korzystasz z wyjątkowo egzotycznego urządzenia, masz po prostu normalny komputer, Smart TV, gogle VR czy telebim. Nie ważne, strona www zawsze ma działać, zawsze będzie wspólnym mianownikiem.

Z tej perspektywy nasza strona www ma być jednocześnie naszym najpopularniejszym kanałem sprzedaży, ale także planem awaryjnym (tzw. „fallbackiem”) jeśli inne, bardziej zaawansowane albo eksperymentalne kanały sprzedaży zawiodą.

Bycie coraz lepszym w internecie i w aplikacjach oznacza dwie różne rzeczy. Stało się dla nas oczywiste, że:

1. Strona służy do budowania zasięgu, gdyż pozwala na najłatwiejsze odkrywanie nowych miejsc,
2. Aplikacje służą do budowania lojalności, bo są bliżej użytkownika i gwarantują lepszy user experience.

Biorąc to pod uwagę wraz z podejście „catch-all” doszedłem do wniosku, że naturalnym rozwiązaniem będzie budowanie ścieżki, gdzie strona jest platformą, której zadaniem jest ułatwić pierwsze zamówienie (odkrywanie) natomiast każde następne powinno odbywać się w aplikacji (lojalność).

Trzeba zrobić dwie rzeczy, aby ten plan mógł się udać: nową stronę według zasad RWD i dwie bardzo dobre aplikacje mobilne (iOS i Android). Tutaj skupiam się głównie na kwestii RWD, ale przeplatam też tekście wątki o aplikacjach, które powstawały równolegle.

RWD

RWD (Responsive Web Design) to zestaw zasad, mechanizmów i wspierających technologii, które pozwalają tworzyć serwisy internetowe optymalnie wykorzystujące wielkość ekranu i typ interakcji. W dużym uproszczeniu: silnik strony sprawdza parametry urządzenia i serwuje na nie wersję serwisu, który najlepiej wyświetla się na komputerze, tablecie czy smartfonie. Zaleta tego podejścia leży w tym, że silnik i logika jest ciągle ta sama, więc nową funkcję wdraża się raz i jest dostępna we wszystkich wersjach.

Wadą jest jednak to, że wymaga znacznie większych zasobów w początkowym okresie, aby stworzyć spójną logikę systemu: na tyle elastyczną, aby dopasować się do różnych metod interakcji, ale także na tyle spójną, aby gwarantować poczucie ciągłości wśród użytkowników i minimalizować chaos organizacyjny w zespole produktowym.

Z moich obliczeń wynika, że inicjalne koszty (czyli czas) stworzenia naszego serwisu RWD były 2.5 wyższe w stosunku do postawienia trzech niezależnych wersji na smartfona, tablet i desktop.

Co daje nam taka inwestycja? Obniża się (w długim okresie) koszt obsługi kodu, czyli czas poprawy błędów i integracji nowych funkcji będzie relatywnie krótszy.

Przede wszystkim jednak stajemy się „screen agnostic”. Jednym produktem jesteśmy w stanie obsłużyć każde nowe urządzenie, niezależnie jakim miksem technologicznym jest – ogromnym smartfonem (phabletem), laptopem udającym tablet (MS Surface) czy tabletem o mocy laptopa (iPad Pro). Będziemy na to gotowi.

Zaczynamy

Nasz serwis mobilny dał nam dobre fundamenty w postaci opisanego wcześniej serwisu mobileweb – ale tylko tyle. Niemal z biegu, zaczęliśmy budować na tych samych zasadach i tej samej bazie serwis RWD (styczeń 2016).

Na bazie własnych wniosków z wywiadów i statystyk oraz dobrych praktyk w ramach DeliveryHero Holding zaczęliśmy przelewać pierwsze idee na papier wykorzystując Google Design Sprint. Tygodniowy proces zakończył się mnóstwem szkiców i wspólną wizją idealnego produktu.

Jednym z największych wyzwań każdego RWD jest przedstawienie sensownego układu stron przy zachowaniu spójności wizualnej, ale jednocześnie wykorzystać unikatowe przewagi każdej z platform. No i oczywiście zagwarantować dostępność technologiczną oraz zgodność z brandbookiem.

No pressure.

Mieliśmy na to kilka sposobów. Już przy pierwszej wersji strony mobilnej PP pojawił się górny czerwony pasek, który szybko stał się naszym znakiem rozpoznawczym. To szybka wizualna podpowiedź, że użytkownik korzysta właśnie z naszej strony. Ten czerwony pasek towarzyszy użytkownikowi na każdej wariacji strony i przy każdej rozdzielczości – tak samo jak niebieski pasek Facebooka.

Oprócz myślenia responsywnego trenowaliśmy projektowanie przepływu. Użytkownik rozumie korzystanie z serwisu jako serię logicznych i następujących po sobie akcji. Chcieliśmy więc zachować ten proces: najbardziej na lewo jest filtrowanie po kuchniach, później wybór restauracji oraz przeładowanie strony, następnie na nowej stronie menu tej restauracji i najbardziej na prawo koszyk. W ten sposób użytkownik mentalnie „przesuwa” się wraz z serwisem od lewej do prawej, od największego ogółu do faktycznego wyboru. Towarzyszą mu bardzo proste wizualne sugestie: akcje negatywne są zawsze w asyście czerwonego (wracanie, odejmowanie), a akcje pozytywne (dalej, wybierz, dodaj) w asyście zielonego.

Trafiliśmy więc szybko na jeden z największych problemów z przestawieniem się na myślenie RWD: element strony musi być zaprojektowany i wdrożony tak, aby był użyteczny niezależnie od szerokości ekranu. To wymaga modularności – większość przycisków, ekranów, mechanizmów musi być samodzielnymi jednostkami, niewymagającą wspierania się na innych, bo możliwe, że w innej rozdzielczości wspierające elementy będą już w innym rogu ekranu.

Szkice zaczęły się zamieniać w makiety, makiety w designy i szybko rozpoczęliśmy prace nad zamianą naszych pomysłów na faktyczny produkt, tak aby po zachować balans między wytycznymi.

Niestety nie wszystkie smaczki dało się powtórzyć na mniejszych urządzeniach ze względu na wielkość ekranów. Dlatego zarówno filtry jak i koszyk są ukryte pod dodatkowymi warstwami, które wjeżdżają nad główną treść strony gdy jest to potrzebne. W tym wypadku skorzystaliśmy ze sprawdzonych wzorców Material Design – języka wizualnego stworzonego w Google’u.

Zrobiliśmy tak, ponieważ Android ma dominujący udział w naszym ruchu mobilnym. Material Design został stworzony tak, aby był użyteczny zarówno na www jak i w aplikacjach, nie gryzie się też z naszą identyfikacją ani podejściem RWD. W ten sposób użytkownik, który wykonał pierwszą operację na webie nie będzie zaskoczony aplikacją na Androidzie. Wracamy tutaj do wyżej wymienionej potrzeby zamiany zasięgu w lojalność.

Wraz z uproszczeniem procesu zamawiania zmieniliśmy też strukturę informacji w serwisie – i to od razu na kilku frontach. Po pierwsze: wdrożyliśmy schema.org. Teraz dane dostępne w PP są łatwo przekładalne na wyniki wyszukiwań, więc użytkownik będzie widział, na przykład, godziny otwarcia restauracji lub oceny w naszym systemie jeszcze na poziomie wyników wyszukiwania w Google’u.

Poza tym zmieniliśmy mapowanie URLi i teraz ktoś, kto mieszka na Wąwozowej 11 w Warszawie może od razu trafić na listę wyników wpisując https://pizzaportal.pl/warszawa/restauracje/wawozowa/11 zamiast przechodzić przez cały flow.

Inna zmiana to bardzo intensywne stosowanie walidacji i wizualnych podpowiedzi. Chyba najlepiej to widać na ekranie checkoutu. Popełnienie błędu na tym poziomie jest dla wszystkich stron bardzo szkodliwe, dlatego robimy co możemy, aby użytkownik skupił się na poprawnym wpisaniu swoich danych i numeru telefonu. Robimy to przez oczywiste walidowanie ilości wyrazów i cyfr, ale także przez tunelowanie uwagi na tym, co właśnie teraz jest ważne.

Transformers

Nasze wewnętrzna badania potwierdziły dosyć oczywistą prawdę, że im strona jest szybsza tym konwersja się zwiększa. Dlatego na poziomie infrastrukturalnym zależało nam posiadaniu platformy, która jak najszybciej zaserwuje nam potrzebne dane. Aby zrozumieć co to znaczy, muszę pokazać większy kawałek układanki – jak już wspominałem we wpisie o MW: produkt to nie tylko produkt, ale także jego infrastruktura.

W naszym przypadku były dwa kluczowe elementy tej infrastruktury: nowa platforma z bazą danych oraz nowe API („API 2.0”). Cały projekt zamiany infrastruktury spoczywa na barkach szwedzkiego zespołu OnlinePizza (to nasza spółka-matka; współdzielimy z nimi backend) i nosił nazwę kodową „Transformers”.

Nowe platforma i API to dla nas bardzo ważna sprawa: pozwala na dwukrotnie szybsze wdrażanie zmian, nie mówiąc o skalowalności i otwarciu na zupełnie nowe technologie i lepsze zarządzanie obciążeniem systemu.

W idealnym świecie te elementy powinny być gotowe na samym początku, zanim zaczniemy prace nad nowymi produktami dla konsumentów. Ale każdy product owner Wam powie, że nie istnieje idealny świat (to jest argument za tym aby wyrzucić do kosza większość teorytycznych porad jak powinno się tworzyć produkty cyfrowe). Tworzenie produktów zawsze odbywa się w mało sterylnych warunkach.

Nasze nowe API spóźniało się na tyle, że podjęliśmy decyzję o stworzeniu pierwszej wersji nowej strony w oparciu o starą infrastrukturą z okrojoną funkcjonalnością. Z tyłu głowy mieliśmy myśl, że w tym czasie przyjdzie moment, że backend dojedzie, a my tylko podmienimy wcześniej przygotowaną warstwę komunikacji na API 2.0 i będziemy na tym wdrażać już czekające funkcje.

I wtedy API 2.0 zaczęło się spóźniać jeszcze bardziej (kwiecień 2016). W związku z tym dodaliśmy etap „Product gap” czyli czas, gdy nasze frontendowe minimum jest już gotowy, ale czekamy na API 2.0. W trakcie tej przerwy budowaliśmy następne funkcje z naszego backlogu, także te, które miały się pojawić już po Transformersie.

Jednocześnie rozpoczęliśmy A/B testy nowej strony zwiększając po malutku jej udział w ruchu z 1% do 5%. Dzięki temu mogliśmy na żywym organizmie sprawdzić wszystkie podstawowe metryki nowej strony jak bounce rate, czas ładowania, konwersję, ścieżki przepływu użytkowników itd.

Ostatni etap to faktyczne przejście na nową platformę. Ze względu na specyfikę tej zmiany switch musi się odbyć jednocześnie na wszystkich platformach, aby wyeliminować duplikację danych w różnych bazach danych. Ale z perspektywy kwietnia 2016 mieliśmy jeszcze dużo czasu na pracę nad naszymi odcinkiem: przyśpieszaniem i uszczelnianiem i upraszczaniem aplikacji klienckich.

Przyśpieszanie

Po wdrożeniu testowej wersji zacząłem zbierać informacje o szybkości działania stron podobnych usług – naszej konkurencji i naszych znajomych z DeliveryHero. Korzystając z Webpagetest.org zbierałem dane o szybkości ładowania strony listy restauracji dla przykładowego adresu. Webpagetest jest dobrym narzędziem, bo badania odbywają się na faktycznym komputerze z faktyczną przeglądarką w kraju gdzie usługa jest aktywna. Jest więc wiarygodnym sposobem na porównywanie jakości stron.

Moim celem było doścignięcie szybkości strony naszego flagowca czyli niemieckiego Lieferheld. Jako bazę dałem sobie wtedy dostępną desktopową stronę PizzaPortal.pl, której loadtime wynosił 17,64 sek.

Jak widać nasza pierwsza wersja RWD jest niewiele lepsza od starej strony. Jednak po każdym refactorze kodu było coraz lepiej, aż dotarliśmy do loadtime ponad trzykrotnie lepszego od bazowego desktopu. Co więcej: przez chwilę nieznacznie wyprzedziliśmy nawet Lieferheld i Grubhub! Ostatecznie jednak czas się nieznacznie wydłużył ze względu na konieczność dostosowania się do docelowych serwerów, dodania marketingowych trackerów i wykorzystania grafik o większej rozdzielczości.

Jeszcze sporo przed nami, ale postawiłem tutaj nowy cel do osiągnięcia: przekroczyć psychologiczną barierę dwóch sekund. Jeśli nam się uda, będziemy najlepsi w branży na całym świecie. A widzimy jeszcze sporo miejsc, w których możemy optymalizować, choć wchodzimy już w dywagacje o obciążeniu infrastruktury dostawców Internetu w Polsce.

Uszczelnianie

Innym wyzwaniem jakie przed nami stało to eliminacja wszystkich istotnych błędów związanych z renderowaniem stron. Nie ma znaczenia jak szybko działa strona, jeśli wyświetla się niepoprawnie. Tym bardziej, że jak najszersza dostępność naszej usługi jest kluczowym elementem strategii produktowej.

Po głębszym badaniu danych z Google Analytics stworzyliśmy listę 37 kombinacji urządzenie + przeglądarka w których widzieliśmy duże niekorzystne odchylenie od średniej konwersji. Aby wiedzieć, które przypadki badać najpierw zrobiliśmy przy każdym przypadku symulacje ile więcej zamówień (oraz pieniędzy) miesięcznie by nam przybyło, jeśli konwersja wróci do standardowej wartości (przy założeniu, że ruch będzie podobny).

Mając to pod ręką zaczęliśmy pracować nad uszczelnianiem RWD uwzględniając przeglądarki z listy. Często jednak okazywało się, że pewne aspekty renderowania stron, które dla nas są kluczowe nie współgrają z daną wariacją urządzenia i przeglądarki. Wtedy patrzyliśmy na jakie ryzyko biznesowe się wystawiamy i jeśli nie była to popularna kombinacja odcinaliśmy fragment długiego ogona wiedząc, że w ten sposób zyskamy czas na uszczelnianie tam, gdzie jest większe natężenie naszych użytkowników.

O stacku technologicznym i procesie produkcji samego kodu Senfino napisało dwuczęściowy artykuł tutaj i tutaj.

Upraszczanie

Szybkość wyświetlania stron i ich poprawne renderowanie i tak nic nie da, jeśli serwis jest chaotyczny i nieprzewidywalny.

W tym wypadku byliśmy brutalni i obcinaliśmy do kości wszystko, co nie było kluczową funkcją systemu. Pierwsza wersja strony wystartowała bez jakiejkolwiek opcji sortowania oraz bez możliwości logowania i rejestracji użytkowników (co oczywiście oznacza brak historii zamówień i opcji ponownego zamówienia).

Skoro nawet tak fundamentalne rzeczy są niżej na backlogu, to praktycznie każda funkcja mogła iść pod nóż. To dobrze, bo zmusiło nas do odświeżenia myślenia i pozwalało zadawać twarde pytania „czy to jest przydatne?”. Dużo rzeczy okazało się po prostu nieprzydatne, ale dzięki temu zyskaliśmy klarowność, prostotę i spokój, tak potrzebny w dzisiejszej sieci.

Innym aspektem naszego upraszczania było rozpoczęcie współpracy z Fundacją Integracja, której pracownicy i testerzy pomogli nam zrozumieć jak wygląda Internet oczami i uszami osób niewidzących bądź niedowidzących. Jest to fascynujący świat, pełen niesamowitych rozwiązań i kultur.

W 2015 roku w Polsce żyło 1,8 mln osób niewidomych bądź słabowidzących. Już nawet pomijając kwestie czysto biznesowe (to świetny rynek dla takich usług jak nasza) uważam, że jest naszym obowiązkiem moralnym i etycznym, aby tworzyć produkty, które nie dyskryminują mniejszości, tak samo jak architekci obok schodów stawiają podjazdy dla wózków inwalidzkich.

Wszystko, co może pójść źle

Jednym z dokumentów, na który ciągle patrzyliśmy nazywał się „Missing features” – zbierał wszystkie funkcje, których brakowało do odtworzenia możliwości starej strony. Dotyczyło to głównie kwestii administracyjnych i logistycznych (jak zmiany w wystawianiu faktur dla restauracji). Głównym celem było zapewnienie naszym działom jak najszybciej ciągłości procesowej i ograniczać zamieszanie związane ze zmianą.

Na przykład: nasz dział sprzedaży sprzedaje coś, co nazywa się „premium placement”. To gwarancja pojawienia się na liście wyników na samej górze dla danego adresu (tak jak reklamy w wynikach Google). Ta sprzedaż odbywa się z góry za następne tygodnie i miesiące, co oznacza, że miejsca w nowym systemie zostały już sprzedane – a więc muszą się pojawić

Ale najważniejszy dokument nosił niezwykle przyjazną nazwę „All the things that could go wrong”. Lista szybko spęczniała do 70 bardzo poważnych lub krytycznych rzeczy, które muszą działać, abyśmy mogli uznać, że migracja odbyła się pomyślnie. Każda z nich, jako samodzielne wydarzenie, ma niskie prawdopodobieństwo na zaistnienie. Ale gdy mamy cały worek to ryzyko wzrasta. Zresztą, mówimy tutaj o migracji serwisu, który generuje sześciocyfrowe ilości zamówień miesięcznie, co przekłada się na dziesiątki milionów dokumentów w bazie danych. Nie ufajcie nikomu, kto mówi, że jest w stanie bezbłędnie przeprowadzić taki proces.

Takie wydarzenie to gwarantowany ból głowy, bo oznacza jakąś formę niewydolności systemowej, która odbija się na użytkownikach, a to rozpoczyna lawinę. Na przykład problem z mailem potwierdzającym zamówienie powoduje zwiększenie zapytań do naszego Customer Care, który powoduje wydłużenie czasu oczekiwania na połączenie innych dzwoniących. Naczynia połączone.

Od czasu stworzenia listy walczyliśmy z każdym punktem na liście. Lista była podzielona na kategorie: „Product”, „Marketing”, „Sales”, „Customer Care”, „Finances” i „HR”, a każdy element na niej był sprawdzany (checked) i dodatkowo sprawdzany (doublechecked) przez dwie niezależne osoby, aby wychwycić błędy ludzkie. Dopiero gdy element został pozytywnie zweryfikowany był traktowany jako checked positive.

Jak widzicie, nawet przy Final Check były rzeczy na „not sure” i co gorsza „checked negative”. Wynikało to z faktu, że niektórych elementów nie da się sprawdzić w 100% w testowym środowisku: na przykład płatności, struktury redirectów domen czy kampanii SEM. To mogliśmy sprawdzić jedynie na żywym organizmie, co mnie bardzo stresowało.

Lista 70 punktów to oczywiście rzeczy, o których wiedzieliśmy. A jest jeszcze katalog rzeczy o których nie wiedzieliśmy. Oraz tych o których nie wiedzieliśmy, że nie wiemy – ale dowiemy się po starcie.

I faktycznie po premierze katalog błędów wzrósł do 79. Wspominałem już, że nie istnieje idealny świat? Nie wyprzedzajmy jednak faktów, jeszcze przyjdzie na to czas.

Falstart

Start nowego systemu planowaliśmy na 29 czerwca. Już nawet nie liczyliśmy, który z kolei to był ostateczny deadline, ale prawdopodobnie około szóstego.

Dwa dni przed planowanym startem wszystkie zaangażowane strony rozsiane między Sztokholmem, Berlinem, Łodzią i Warszawą uczestniczyły w telekonferencji i deklarowały poziom gotowości.

Po tylu miesiącach pracy, ciągle odkrywanych nowych komplikacjach, czasami nieprzespanych nocach przez programistów oraz rosnących oczekiwaniach biznesu, każdy miał psychologiczną potrzebę wreszcie zakończenia tego bolesnego etapu i wyjścia wreszcie na głęboką wodę. Panowało ogólne przekonanie, że jesteśmy już tak blisko, że wszystkie obecne problemy to po prostu strach przed zmianą. Jeśli będziemy pozytywnie nastawieni wszystko nam się uda.

Wszyscy tak myśleli oprócz mnie. Choć czułem, że kopię leżącego (i w ten sposób także siebie) to jednak nie potrafiłem dać zielonego światła z czystym sumieniem. Zbyt dużo błędów jeszcze widzimy, zbyt duża jest niestabilność nowego API. Do tego nasze zespoły w Polsce i Szwecji zbyt długo pracowały i są po prostu przemęczone. Wykonali świetną robotę, ale nawet najlepsi programiści muszą kiedyś spać (ale zadziwiające ilu z nich jest w stanie oszukiwać samych siebie, że są nieśmiertelni).

Bałem się, że zaraz po premierze całe ciśnienie opadnie, wszyscy przybiją sobie piątki i wezmą urlopy. A właśnie wtedy będą najbardziej potrzebni. Premiera produktu brzmi jak dobry kamień milowy, ale to właśnie wtedy jest najwięcej pracy. Start to dopiero pierwszy test systemu w pełnej skali, dopiero teraz zaczną się pojawiać prawdziwe problemy, bo użytkownicy to najlepsze generatory wyjątków.

Kto więc będzie miał energię, aby znalezione problemy naprawiać, gdy wszyscy będą wypaleni sprintem na tą iluzoryczną datę premiery produktu?

Było mi bardzo ciężko być posłańcem złej nowiny, ale gdy wreszcie powiedziałem co myślę, klapki hurraoptymizmu powoli zaczęły opadać. Gdybyśmy byli świeżym startupem to wręcz naciskałbym na jak najszybszy start i naprawianie dziur w locie. Nie możemy jednak tak zrobić, gdy obsługujemy sześciocyfrową liczbę zamówień miesięcznie. To zupełnie inny poziom odpowiedzialności.

Nawiasem mówiąc to także przeoczony czynnik przewagi startupów nad dorosłymi firmami – brak (albo mała) baza użytkowników to mniejsze ryzyko i większa ochota na eksperymenty.

Tym razem, zamiast dawać sobie kilka dni więcej zdecydowaliśmy się na 2 tygodnie przerwy, podczas których zespoły będą miały czas na relaks, odseparowanie się od pracy i regenerację. Tak, wiem, że mało kto zdjął z siebie w pełni ten balast zbliżającej się premiery, ale była to niedogodność, którą musieliśmy zaakceptować.

Nowa data to 12 lipca. My tak zdobyte dwa tygodnie przeznaczyliśmy na bardziej agresywne testy stabilności, aby wykryć resztę niedociągnięć. Byliśmy w śmiesznej sytuacji: im mniej błędów znajdziemy tym lepiej… Ale zarówno im więcej błędów znajdziemy tym lepiej.

Proszę wyłączyć te błędy na produkcji

Największa migracja w historii naszych firm zacznie się o 0:01 we wtorek 12 lipca. Noc z poniedziałku na wtorek wybraliśmy specjalnie, bo na początku tygodnia rano mamy najmniej zamówień, ale też chcieliśmy, że każdy pracownik mentalnie wrócił już do pracy po weekendzie. Nasz release plan liczył 48 podpunktów z podziałem na rzeczy do zrobienia po stronie backendu i frontendu.

Nasz polski dział produktu w tym planie uaktywniał się o 8:00 rano, a o 9:00 według planu mieliśmy ruszyć z nową stroną. Faktycznie ten start odbył się dopiero o 10:30, w ostatnim momencie przed rozpoczęciem lunchowej fali zamówień.

W międzyczasie niemal wszystko co mogło nam popsuć start się wydarzyło – łącznie z niedziałającym chwilo Internetem w budynku i odkrytym w ostatnim momencie błędzie w aplikacjach mobilnych.

Gdy minął dzień mogliśmy oszacować nasze wyniki. Biorąc pod uwagę jak duża to była zmiana spodziewaliśmy się mocnych spadków zamówień wywołanych zamieszaniem. Mentalnie już dawno spisałem ten dzień (a nawet tydzień) na straty jeśli chodzi o liczbę zamówień. Byłem jednak zaskoczony, że mimo tylu krytycznych rzeczy, które się rozłożyły osiągnęliśmy średnio 65% zamówień z analogicznego dnia w poprzednim tygodniu.

Baliśmy się, że nowy wygląd strony będzie zbyt dramatycznie różny od tego, do czego przyzwyczaili się użytkownicy. Przyzwyczajenia jednak mają to do siebie, że ich zmiana boli tylko przez chwilę… A nowe i lepsze staje się przyzwyczajeniem bardzo szybko. Byliśmy za to często chwaleni za szybkość strony, minimalizm i łatwość zamawiania.

Na powierzchni było wszystko ładnie, ale pod spodem kipiało. Nasz Customer Care nie nadążał z odbieraniem telefonów i odpisywaniem na maile. Dzwonili restauratorzy, którzy nie połapali się w nowym systemie, użytkownicy, którym zamówienia nie przyszły (albo tacy, którzy dostali maile, że zamówienie anulowano, ale jednak przyszło). Do tego cały czas dochodziły problemy skali, których się spodziewaliśmy, ale na które nigdy do końca nie da się być przygotowanym.

Dodatkowo okazało się, że niezależnie od wcześniej wspomnianych nieoczekiwanych błędów jest jeszcze jeden, który potęguje pozostałe: z niewyjaśnionych przyczyn nasza baza danych zapycha się ze względu na zbyt dużo zapytań. Takie zapchanie powoduje, że pojawiają się rozbieżności między tym, co się faktycznie stało (zamówienie potwierdzone), a tym co mamy w systemie (zamówienie anulowane) bo dane nie docierają do bazy na czas.

Gdy osiąga się odpowiednią skalę, to takie problemy są gwarantowane (to jeden z powodów dlaczego systemy bankowe tak rzadko są aktualizowane; lepiej nie ruszać jeśli działa). Mamy tysiące restauracji, z których każde menu na minimum 20 pozycji. Liczba kombinacji zamówień jest tak duża, że fakt błędu technicznego bądź przy imporcie danych to nie jest coś nad czym się zastanawiamy – to, coś co na pewno się zdarzy.

Gdy ma się tego świadomość, to łatwiej się przyjmuje taki stan rzeczy; zdecydowanie łatwiej rozwiązuje się problemy skali gdy nikt nie biega panikując i machając rękami. Skrajne przypadki ze względu na swoją naturę są najgłośniejsze i wypływają na powierzchnie – mimo, że jest ich mniej to zajmują nieproporcjonalnie dużo energii umysłowej.

W środowisku lean startupowym lubi się mówić, że pierwszej iteracji każdego produktu powinno się wstydzić – inaczej wystartowało się po prostu zbyt późno. Tak właśnie było u nas. Cały tydzień od startu debatowaliśmy czy lepiej łatać nowy system czy wrócić do starego. Każdego dnia liczba zamówień oscylowała w granicach 50-70% poprzednich poziomów, ale teraz, gdy już nowa strona się opatrzyła powinniśmy zacząć przebijać stare wyniki zamówień, a nie ciągle się wykrwawiać.

Choć głosy o potrzebie powrotu do starego systemu były coraz mocniejsze to jednak zdecydowaliśmy się pozostać z nową infrastrukturą i systematyczne naprawiać największe błędy. Ustalaliśmy codziennie z zespołem top 3 największych problemów związanych z systemem. Na bieżąco, jeden po drugim je usuwaliśmy wygrzebując się z tej stresującej sytuacji. Na szczęście nasza nowa strona sprawowała się świetnie, więc całe nasze zasoby skierowaliśmy na pomoc szwedzkiemu zespołowi backendowemu. Wygrzebanie się z tych problemów zajęło nam pięć dramatycznych i wyczerpujących emocjonalnie tygodni.

Cztery tygodnie z tego zajęło nam przywracanie bazy restauracji do stanu standardowej używalności. Niemal co dzień znajdowaliśmy problemy wynikające z braku (bądź zbyt luźnej) walidacji danych: od brakujących sosów, przez brak adresów po konfliktujące godziny otwarcia. Stosowaliśmy wszystkie możliwe sposoby – walidację przy importach, skrypty scrapujące nasz własny serwis po zewnętrznych testerów. Kombinacja tych wszystkich metod i tytaniczna praca wykonana przez Adama (drugiego obok mnie product ownera w zespole) pozwoliła nam wrócić do poprzedniego stanu.

Gdy już wykaraskaliśmy się z problemów z bazą danych dostaliśmy sygnał od berlińskiego zespołu SEO, że coraz gorzej jest z indeksowaniem nowej strony – codziennie traciliśmy 2-3% ruchu z SEO. Było to dla nas szokujące, bo przeszliśmy trzy niezależne audyty SEO oraz tworzyliśmy strukturę dokładnie z wytycznymi Google’a.

Niestety okazało się, że dokumentacja Google’a jest trochę zbyt optymistyczna względem rzeczywistości i crawlery wyszukiwarki nie radzą sobie dobrze z dynamicznie renderowanymi stronami i cachem. Mimo tego, że Google utrzymuje, że potrafi takie strony indeksować to boleśnie przekonaliśmy się, że jest inaczej (zresztą tak samo jak Hulu).

W dużym skrócie problem polegał na tym, że choć użytkownik widział naszą stronę dobrze, że crawler Google’a nie potrafił jej wyrenderować i myślał, że tak samo ma żywy człowiek. Gdy jednak próbowaliśmy temu zaradzić narażaliśmy się na karę bo Google penalizuje (co jest zrozumiałe) witryny, które mają dwie różne wersje: jedną dla crawlerów i drugą dla użytkowników. Ostatecznie skorzystaliśmy z narzedzia prerender.io i nasz ruch z SEO zaczął się poprawiać.

Problem jest o wiele bardziej skomplikowany i wychodzi poza moje kompetencje, ale mam nadzieję, że ktoś to jeszcze dobrze opisze.

Wspominałem już, że nie ma świata idealnego? Trzeba się z tym pogodzić. Nie da się zrobić omleta bez rozbijania kilku jajek.

Branding

Zmiana wizualna nowej strony i aplikacji nie byłaby pełna bez nowego brandingu. Na początku wydawało nam się, że inkorporowanie nowego logo, ikon i teł będzie proste i szybkie. Okazało się, że zrobienie tego jednocześnie na każdej platformie (web, iOS, Android) gdzie wymagane są różne rozmiary grafik, a sklepy mają różny czas reakcji nie jest już tak banalne. Szczególnie, że musieliśmy się zsynchronizować z marketingiem, który podobne zmiany zrobił w swoich kampaniach reklamowych, mailingach i social media.

Nasz marketing wraz z brand teamem w Berlinie przygotował 4 propozycje logotypów i fontów do wykorzystania. Następnie wszystkie zostały wysłane do testowania wśród użytkowników, którzy informowali nas jak emocjonalnie konotują nowe wersje i która podoba im się najbardziej. Na szczęście okazało się, że ta, która podobała się mi jest jednocześnie najlepsza w oczach userów :)

Za zmianę brandu zdecydowaliśmy się zabrać dopiero półtora miesiąca po starcie RWD, ale dokładnie z momentem wdrożenia nowej aplikacji na Androida. Ciężko nam było myśleć o brandingu, gdy mieliśmy na głowie palące problemy z bazą danych. Gdy już jednak kurz opadł mogliśmy się zająć także tym i efekt był lepszy niż się spodziewałem:

Efekty

Największą zmianę widać przede wszystkim w wyglądzie serwisu. Tak strona PP wyglądała przed zmianą:

A tak po odświeżeniu:

Aplikacja na Androida:

Sam wygląd to tylko powierzchnia – to, co faktycznie nas interesowało najbardziej to konwersja. W przypadku serwisów do zamawiania jedzenia patrzy się nie tylko na końcową konwersję, ale także na jej składowe, czyli tzw. mikrokonwersje. Mikrokonwersje to przepływy użytkowników pomiędzy głównymi etapami interakcji z serwisem. W serwisach do zamawiania jedzenia online (niezależnie od tego z jakiej są szerokości geograficznej) znajdziecie takie:

• Home Page (HP),
• Restaurant Listing Page (RLP),
• Details Menu (DM),
• Checkout Page (CP)
• Order Confirmation (OC).

A więc mikrokonwersje, które nas interesowały to: HP>RLP, RLP>DM, DM>CP i CP>OC. Trzy miesiące po starcie, gdy nasze statystyki się ustabilizowały uzyskaliśmy takie wyniki:

HP>RLP +25,41%
RLP>DM +4,78%
DM>CP +29,29%
CP>OP +9,32%

Suma przyrostów mikrokonwersji przełożyła się na około 70% wzrost konwersji końcowej. To efekt przede wszystkim trzykrotnego przyśpieszenie ładowania strony, zmiany architektury informacji, minimalizację szumu informacyjnego w procesie zakupowym oraz zwiększeniu spektrum obsługiwanych urządzeń.

Całkiem niezłe sukcesy osiągnęliśmy także na polu SEO, mimo wcześniej opisywanych problemów. Na wykresie widać niebieską i pomarańczową linię – im jest niżej tym lepiej dla nas bo to oznacza, że jesteśmy wyżej w rankingach słów kluczowych.

Przeniesienie naszej strony na nową infrastrukturę oznaczało konieczność ponownego crawlowania przez pająki Google’a naszej strony i wszystkich przyległości (jak strony white labels czy landing pages). Zawsze zajmuje to trochę czasu i może skutkować chwilowym pogorszeniem wyników – na wykresie wyraźnie widać to na przy nagłym skoku linii do góry. Ostatecznie jednak nasza pozycja zaczęła wracać do normy a chwilę później zaczęliśmy czerpać pierwsze korzyści ze wdrożenia schema.org – zajęło nam około miesiąca, aby uzyskać najlepszą średnią pozycję w SEO od początku tego roku.

Wraz z premierą nowej wersji aplikacji podniosły się też oceny w Google Play:

To wszystko było możliwe, dzięki niezwykle skomplikowanej i bolesnej migracji na nową infrastrukturę. Choć jeszcze dużo jest do poprawiania to najważniejsze kroki już za nami: zmigrowaliśmy na nowy backend, nowa strona www oraz dwie całkowicie zmienione aplikacje mobilne. I to wszystko w ciągu niecałych 8 miesięcy. To, co teraz czeka produkt to mozolne ulepszanie na nowych fundamentach.

Zespół

Podczas spotkań zespołu w pokoju konferencyjnym w zależności od sytuacji siedziało 5 – 9 osób jednocześnie (a przewinęło się w sumie ze 20); podobnej wielkości był zespół szwedzki. Dodatkowe kilka(naście) osób wspomagało nas w Berlinie w zakresie brandingu, SEO i UX.

Trzonem całej układanki był zespół stworzony specjalnie dla PP w Senfino (czapki z głów Dawid, Kamil, Piotr, Paweł, Sylwek, Marcin, Zbyszek, Kuba, Grzesiek, Marta, Zuza, Olga oraz cała reszta!).

Specjalne podziękowania dla Adama, który przez brał na siebie najmniej wdzięczne elementy pracy product ownera, ale dzięki temu zna teraz produkty PizzaPortal lepiej ode mnie.

The end

…a tak naprawdę wcale nie. Choć zmiana infrastruktury i strony jest dla nas ogromnym kamieniem milowym to w gruncie rzeczy to tylko początek wdrażania strategii. Ostatni rok skupienia na zmianie infrastruktury dał nam wszystkim mocno w kość, teraz czas na realizacje wszystkich rzeczy, które obiecaliśmy, że staną się „po Transformersie”.

Personalnie był to dla mnie bardzo intensywny czas. To był największy proces zmiany technologicznej, jakim zarządzałem i sam już się gubiłem kiedy mój optymizm był marzeniem ściętej głowy, a kiedy ma solidne podstawy.

Ostatecznie, dzięki współpracy wielu zupełnie różnych zespołów rozsianych między kilka miast i organizacji udało nam się osiągnąć coś z czego jestem bardzo, bardzo dumny. Nawet mimo tego, że (autentycznie) pojawiły mi się pierwsze siwe włosy.