Powrót z rodzinnego urlopu. Mamy samolot o 7:30, więc musimy odpowiednio wcześniej wstać, aby spakować rzeczy, dojechać do lotniska i wsiąść do samolotu.
To zawsze jest dla mnie stresująca sytuacja. Jakoś naturalnie biorę na siebie odpowiedzialność za plany związane z koordynacją tego, kto gdzie i kiedy powinien być. Buduję przy tym możliwe scenariusze: zapomniane dokumenty, zepsuty samochód, opóźnienie samolotu i inne katastrofy. Tworzę w głowie ścieżki krytyczne i wąskie gardła i metody, aby temu zaradzić. Szkicuję plan organizacyjny i wysyłam wszystkim, aby wiedzieli co ich czeka. Once product owner, always product owner.
Efekt jest taki, że w dniu wyjazdu jestem dla wszystkich bardzo trudny do życia, stresuję się i wszystkich pogadaniam, ale jedną cechą to równoważę – moje plany działają. Dostarczam grupę delikwentów (łącznie z sobą) w wyznaczone miejsce w wyznaczonym czasie, niezależnie od okoliczności.
Mój sposób jest prosty, nie wymaga niesamowitych umiejętności ani predyspozycji: to buforowanie. Bufor to dodatkowy niewykorzystany zasób. I choć brzmi to banalnie, to jest wręcz niesamowite jak dużo problemów buforowanie potrafi rozwiązać.
Bufory działają wszędzie: w finansach (rzeczy kosztują więcej niż wskazuje na to rachunek), w organizacjach (potrzeba więcej, żeby osiągnąć cel), w planowaniu czasu (podróże trwają dłużej niż pokazuje bilet), w rozwoju personalnym (mniejsze wymagania wobec swoich umiejętności dają lepsze efekty). Jedynym wyjątkiem jest życie emocjonalne. Nie polecam buforowania relacji z partnerami – to niemoralne. (A może moralność to bufor na relacje międzyludzkie? Muszę się nad tym zastanowić).
Kluczowe w tym wszystkim jest buforowanie własnego czasu. I ciekawe rzeczy się dzieją, gdy zaczyna się to robić.
Żyjemy w środowisku, które premiuje optymalizację czasu: szybszy dojazd do pracy jest lepszy, większa produktywność jest lepsza, szybkie przeczytanie książki jest lepsze niż wolne przeczytanie książki. Optymalizacja czasu to po prostu przedłużenie ekonomicznego myślenia: jak uzyskać jak najwięcej jak najmniejszymi środkami. Problem polega na tym, że gdyby ekonomiści mogli zoptymalizować ludzkie ciało, to mielibyśmy tylko jedno płuco i jedną nerkę (bo przecież Te wystarczają do nominalnego funkcjonowania)*
Z tej perspektywy buforowanie, czyli intencjonalnie zwiększanie zasobów potrzebnych do osiągnięcia tego samego celu, to działanie wbrew ekonomicznemu rozsądkowi, anty-optymalizacja. To wałęsanie się bez celu jak flaner zamiast skorzystanie ze zorganizowanej wycieczki all-inclusive.
Myśląc ogólniej, bufor jako narzędzie zarządcze ma swoje głębokie, filozoficzne znaczenie.
W całym wachlarzu narzędzi jakimi dysponujemy mamy bowiem takie, którym można ujarzmić nieprzewidywalną przyszłość. Statystyka i rachunek prawdopodobieństwa może nam powiedzieć jaka jest szansa, że coś może się wydarzyć.
Buforowanie daje sposób na ochronę wobec tych negatywnych wydarzeń – niezależnie od tego jak duże mają prawdopodobieństwo wystąpienia. Jest metodą planowania na wszelki wypadek, przewidywania konsekwencji nieprzewidywalnych wydarzeń. Let it sink for a moment.
I choć często nam się zdarza, że jesteśmy na lotnisku dużo za wcześnie przez co potrafię się nasłuchać zgryźliwych komentarzy to jednak wiem, że nigdy nie będę w tej milczącej grupie ludzi, którzy spóźnili się na samolot, bo nie mieli wystarczająco dużo czasu, aby wrócić się po paszport, więc spóźnili się na autobus, więc uciekł im pociąg, a w konsekwencji zamknęli im gejty przed nosem.
—
* Idea zaczerpnięta z książek NN Taleba, który pasjami nienawidzi ekonomistów za ich poczucie nieomylności.
Podczas studiów lubiłem czytać o lifehackingu – wiecie, takie popkulturowe sprawy typu: top 10 metod zarządzania swoim życiem. Na Reddicie trafiłem wtedy na pytanie typu „jakie jest najlepsze możliwe ćwiczenie na siłowni”? I kilka najpopularniejszych odpowiedzi spójnie potwierdzało: przysiad ze sztangą, czyli squat.
Siłownia, ciężary i sztangi kojarzyły mi się wtedy jedynie z napakowanymi byczkami, którzy komunikują się warknięciami i przyglądają swoim łydkom w lustrze. Mimo to zacząłem zgłębiać temat, ale jedynie teoretycznie. Wszystkie mądre głowy w internecie kierowały do jednego źródła: najlepszy specjalista od przysiadów to Mark Rippertoe. Wszystko co trzeba wiedzieć o squatach jest w jego książce… Ale zaczęły się egzaminy, na Lifehackerze pisali już o top 5 najlepszych appek mailowych i wątek mi się urwał.
Minęło 10 lat.
Jedną z rzeczy, których człowiek uczy się na własnej skórze po urodzeniu dziecka, to że faktycznie posiada kręgosłup. Nie ten moralny (o jego posiadaniu można dowiedzieć się na inne sposoby), ale fizyczny. Codzienne, wielokrotne podnoszenie i odkładanie do łóżeczka, bujanie, noszenie, huśtanie, przytulanie… to wszystko uświadamia ile ma się kręgów i mięśni do nich podłączonych. I choć kręgosłup rodzica przyzwyczaja się do tego z czasem (dziecko na szczęście nie waży od razu 10 kilogramów) to jednak powtarzające się doległości uwierały coraz mocniej.
W pierwszych miesiącach życia mojego syna żarłocznie pochłaniałem twórczość NN Taleba. Na etapie czytania „Antifrigile” trafiłem na opis (między innymi) metod rozwoju w chaotycznym środowisku. Wśród przykładów Taleb podaje… podnoszenie ciężarów i Marka Rippertoe. Uzasadnia, że ludzki organizm to faktycznie kompleksowy system poddawany chaotycznym impulsom – w takim środowisku wyewoluował. A więc jeśli ma być sprawny to należy zwiększać mu amplitudę sygnałów i powiększać ekspozycję na skrajne bodźce, a wśród nich podnoszenie i noszenie ciężkich rzeczy wydaje się najlepsze (tutaj więcej).
NN Taleb (56 lat) podnoszący 300lbs (136kg)
To był moment w którym postanowiłem odszukać książkę Rippa, aby wreszcie sprawdzić, czy to coś dla mnie. Ripp to surowy gość, który nie lubi bullshitu i wygląda jakby jeździł truckiem i nosił ze sobą wielki pistolet. Nie można mu jednak odmówić obsesji w temacie podnoszenia ciężarów. W Starting Strength jest rozpisany każdy ruch, na poziomie fizyki (punkt ciężkości, lewarowanie) i biomechaniki (mięśnie, relacje między nimi). Ripp ma też dużo mocnych przekonań o ćwiczeniach. Jest całkowicie przeciwny nowym modom na kluby fitness w których rezygnuje się z ćwiczeń ogólnorozwojowych na rzecz błyszczących maszyn pomagających w stymulacji pojedyńczych partii mięśni. Tak samo jak Taleb, Ripp twierdzi, że organizm to kompleksowy system – jeśli chce się w nim coś poprawić, to należy to robić całościowo, a nie w sztucznej izolacji. Dlatego chcąc być silnym należy szukać ćwiczeń odzwierciedlających ewolucyjne uwarunkowania budowy ludzkiego organizmu, przywyczajonego do noszenia ciężarów w rękach i na plecach – a więc aktywności stymulujących cały system.
Gdzieś dopiero w 3/4 w głąb książki pojawia się przykładowy, niedbale rozrysowany plan ćwiczeń. Generalnie plan jest prosty:
Każde z tych trzech ćwiczeń robisz w kolejności po 3-5 razy – rozkładając ciężar od minimalnego (sama sztanga) po obecne maksimum. Każdy raz po 3 serie, w serii jest 5 powtórzeń. Co drugi trening zmieniasz ławkę na podnoszenie na stojąco (jak). W pewnym momencie na zmianę robisz martwy ciąg i power clean (jak). Ćwiczenia są tak poustawiane, że poprzednie stanowi rozgrzewkę przed następnym a kulminacja skupia się na martym ciągu, gdzie im większy ciężar tym mocniejszy stres dla organizmu.
Ćwiczysz 3 razy w tygodniu, poniedziałek, środa, piątek – lub w inne dni ale z podobnie długimi przerwamy na regenerację. Każda wypad na siłownię powinnien odbywać się z coraz większym ciężarem, ale zaczynając od bardzo niskiego poziomu i cierpliwie wspinać się do swoich limitów. Bez chojrakowania.
I tyle. Reszta to już tylko drobne eksperymenty, aby dopasować się do rytmu. Początkowo trening zabierał mi 1.5 godziny, teraz jest już ponad 2h. Ćwiczę rano gdy siłownia jest pusta. Na szczęście siłownię mam 500 metrów od domu i na trasie do pracy.
Efekty?
Po siedmiu miesiącach ćwiczeń z małymi przerwami: waga stoi w miejscu, rosną plecy, barki i ręce. Kręgosłup nie boli przy podnoszeniu dziecka. Siła wzrosła niespotykanie, co czuć przy codziennych aktywnościach.
Tak wygląda ciężary, które podnoszę ostatnio (120kgx5x1). Cały czas mam dziwne uczucie, że to niemożliwe, że taki kawał żelastwa jestem w stanie wziąć na siebie i się przy tym nie złamać w pół. Gdyby ktoś mi to pokazał pół roku temu to był nie uwierzył.
Moje pierwsze treningi w lutym tego roku. Skoki co 5-10 kilogramów, dramatyczny progres z każdą sesją.
Moje ostatnie treningi, powolne ale satysfakcjonujące wspinanie się co 2.5kg.
Muszę egoistycznie przyznać, że to świetne poczucie, gdy ma się najwięcej nałożone na sztandze w całej sali. Inaczej też patrzę na lokalne dziki, gdy wiem ile czasu i wysiłku zajmuje wypracowanie tej faktycznej siły liczonej w załadowanym ciężarze, a nie koszulce wypchanej sześciopakiem. To mi tylko pokazało jak wcześniej, jako zaczytany w książkach typ, deprecjonowałem znaczenie pracy nad własnym ciałem.
I choć nigdy nie będę miał idealnej figury jak wyczynowi pływacy czy modele (takie geny) to poczucie fizycznej siły i świadomość jak dużo mogę zrobić z moim organizmem daje satysfakcję. Tak Ripp o tym pisze we wstępie do Starting Strength:
„Physical strength is the most important thing in life. This is true whether we want it to be or not. As humanity has developed throughout history, physical strength has become less critical to our daily existence, but no less important to our lives. Our strength, more than any other thing we possess, still determines the quality and the quantity of our time here in these bodies. Whereas previously our physical strength determined how much food we ate and how warm and dry we stayed, it now merely determines how well we function in these new surroundings we have crafted for ourselves as our culture has accumulated. But we are still animals –our physical existence is, in the final analysis, the only one that actually matters. A weak man is not as happy as that same man would be if he were strong. This reality is offensive to some people who would like the intellectual or spiritual to take precedence. It is instructive to see what happens to these very people as their squat strength goes up.”
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.
Nasza stara strona mobilna na dużym ekranie
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:
Nasze produkty nigdy nie są skończone. Widzimy swoje braki i ciągle je poprawiamy,
Nie jesteśmy bezduszną maszyną; mamy charakter. Jesteśmy ludźmi, którzy korzystają ze swojego produktu,
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:
Strona służy do budowania zasięgu, gdyż pozwala na najłatwiejsze odkrywanie nowych miejsc,
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.
Jeden z wielu szkiców stworzonych podczas Design Sprintu
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.
Kolorowa makieta Lo-Fi w Adobe Comp
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.
Czwarty dzień tygodniowego Design Sprintu
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.
Przepływ użytkownika
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.
Zmiana siatki w zależności od szerokości ekranu
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.
Strona RWD 320px i Android
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.
Przykład tunelowania
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.
Timeline prac nad produktami PP
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.
Zmiany w szybkości ładowania nowej strony PP
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).
Lista najgorzej performujących wariacji
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.
Wycinek listy rzeczy, które muszą działać
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.
Rozkład statusów krytycznych elementów systemu przed startem
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ń.
Razem z Adamem obserwujemy start nowego serwisu
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).
Problemy z indeksowaniem stron
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 :)
Wariacje fontuNowe logo i ikona
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ą:
Lista restauracji w starej wersji (web, wariacja szwedzka)
A tak po odświeżeniu:
Lista restauracji w nowej wersji (web)
Aplikacja na Androida:
Ekran restauracji w starej wersji (Android)Ekran restauracji w nowej wersji (Android)
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:
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.
Wzrost indeksowanych fraz i poprawa średniego rankingu słów kluczowych. Im wyższy słupek tym lepiej, im niżej linia tym lepiej.
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:
Zmiana proporcji ocen po premierze nowej aplikacji na Androida
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.
Moje pierwsze treningi w lutym tego roku. Skoki co 5-10 kilogramów, dramatyczny progres z każdą sesją.
