Jak powstawały aplikacje iTaxi 3


Ściągnij PDF z tym tekstem (43 strony, 11.5 Mb)


Zamiast wstępu

iTaxi to polski startup oferujący przejazdy licencjonowanymi taksówkami dzięki aplikacji mobilnej. Został stworzony w 2012 roku przez Stefana Batorego. W 2016 roku firmą zaczął kierować Lech Kaniuk co wiązało się także z powstaniem w firmie działu produkowego pod moim kierownictwem.

W listopadzie 2016 roku, po kilkutygodniowym okresie analizy produktu naszkicowaliśmy z zespołem kierunki na pierwsze 12 miesięcy:

  1. Sytuacja zastana
    • Za dużo zamówień z centrali telefonicznej
    • Przestarzałe i rozdmuchane aplikacje mobilne
    • Duże rozbieżności rozwojowe między aplikacjami
  2. Diagnoza
    • Aplikacje są rozwijane ad hoc mimo tego, że wiemy, że to musi być nasz główny kanał sprzedaży
  3. Priorytety rozwoju
    • Uproszczenie korzystania z aplikacji
    • Ustabilizowanie cykli rozwojowych iOS i Android
    • Priorytetyzacja user-facing features
    • Konwertowanie klientów B2B także na B2C
  4. Kroki
    • Backlog produktowy oprócz technicznego
    • Usuwanie najmniej wykorzystywanych funkcji
    • Stworzenie nowych wizualizacji aplikacji
    • Wdrażanie poprawek do obecnych aplikacji
    • Jednoczesna praca nad nowymi aplikacjami

Rozłóżmy to na części pierwsze.

To co zastaliśmy to był (w naszej ocenie) rozbudowany produkt, efekt dokładania funkcji budujących poczucie kontroli wśród pasażerów i dopasowania do potrzeb rynkowych właścicieli biznesowych.

Choć to zdanie brzmi dobrze, to wszystkie te pozorne pozytywy mają swoją mroczną stronę. Rozbudowany produkt to synonim problemów z zarządzaniem kodem – co z kolei zwiastuje powolny rozwój. Dodane funkcje wprawdzie zwiększały poczucie kontroli – ale to było, no właśnie, tylko poczucie. Zamiast zautomatyzować i skalować promowaliśmy manualne rozwiązania i ślepe zaułki. Przykład: ręczne zamawianie taksówek, które kończy się odmową kierowcy – zamiast wykorzystania algorytmów, które są w stanie znaleźć odpowiednią taksówkę nieskończenie razy szybciej. Poczucie dopasowania do potrzeb rynkowych było w tym wypadku synonimem braku rygoru i krytycznego spojrzenia na spójność całego produktu.

Innym problemem była nierówność rozwojowa aplikacji: Android był wyraźnie do przodu w stosunku do iOSa pod względem funkcji. Brakowało synchronizacji między platformami nie tylko na poziomie cyklów rozwojowych, ale też stylu i kierunku. Aplikacje rozwijane są przy okazji – mimo tego, że organizacja uznaje je za jeden z filarów strategii wzrostu. Nasz szybki rozwój przy obecnej strukturze generuje także równie szybki wzrost kosztów związanych z obsługą zamówień telefonicznych. Przy tej skali działalności każdy punkt procentowy zamówień przeniesiownych z centrali na aplikacje to realne oszczędności, bo koszt rozwoju aplikacji jest, uogólniając, niezależny od liczby zamówień z niej.

Dochodził jeszcze problem zespołu. W koordynacji z naszym CTO, mogliśmy korzystać z programistów jego działu – układ był między nami taki, że dział produktu decyduje o tym *co* ma być zrobione, a dział IT decyduje *jak* ma być zrobione. Jednak, aby faktycznie pójść do przodu z produktem iTaxi, musimy mieć ludzi skupionych na pracy stricte produktowej. Mieliśmy wtedy do dyspozycji programistkę Java/Android, która dzieli swój czas między aplikację pasażera, aplikację kierowcy i część prac serwerowych, developera iOS, który pracował u nas po godzinach, graficzkę pracującą dla nas zdalnie i głównie dla działu marketingu oraz wsparcie i dobrą wolę reszty działu IT w zakresie koordynacyjno-logistycznym. Jak z tego zbudować sprawny zespół?

Rozpoczęliśmy od wprowadzenia faktycznego Scruma, konsolidację zespołu i synchronizację sprintów iOS i Android. Udało nam się przekonać developera iOS do przyłączenia się do nas na stałe. Natomiast z graficzką miałem komunikację bezpośrednią – wspólnie przygotowywaliśmy materiały potrzebne do realizacji zadań do sprintu.

Nie poszliśmy jednak drogą zwiększania składu osobowego – to nie był najlepszy moment ze względu na cykl rozwoju firmy. Poza tym małe zespoły (mimo potencjalnego bus factora) mają przewagę elastyczności nad wielkimi machinami trawionymi potrzebą skomunikowania wszystkich ze wszystkimi.

Adnotacja do synchronizacji sprintów: „synchronizacja” nie oznaczała w naszym przypadku pełnego zrównania. Małe, zarządzalne przesunięcie między sprintami platform (ale o tej samej „długości”) ma swoje plusy: pozwala na rozpoznanie potencjalnych problemów mniejszym kosztem (druga platforma wchodzi wtedy na „gotowe” rozwiązanie).

Przed samym startem sprintów zaczęliśmy budować sobie lepsze rozeznanie szczegółów mechaniki aplikacji i jej interakcji z serwerem. Z pomocą dłużej pracujących w iTaxi osób naszkicowaliśmy userflow systemu i zaczęliśmy uczyć się języka i definicji specyficznych dla tego środowiska. Niezależnie powstawał nowy backlog w Trello. Wysłaliśmy do najbardziej obeznanych w kluczowych działach osób zapytanie o to, jakie najważniejsze funkcje chcieliby widzieć w produkcie, gdyby nie istniały żadne ograniczenia techniczne –  potraktowaliśmy to jako drogowskaz na początek, gdy jeszcze brakowało pełnego obeznania z ograniczeniami samego systemu.

Do tego zaczęły szybko dochodzić elementy, które były czystym koncertem życzeń lub z drugiej strony: optymalizacje na poziomie kodu i poprawki małych błędów. Z czasem mieszanka tych elementów pozwoliła na wyklarowanie się najboleśniejszych problemów i (jak to się ładnie mówi) low hanging fruits.

Te ruchy miały jeszcze jeden, fundamentalny powód: iTaxi 3. Musieliśmy znaleźć sposób, aby nawiązać walkę produktową ze znacznie mocniejszą i bogatszą konkurencją. Stawka była wysoka, bo nie dość, że mocno odstawaliśmy to jeszcze mieliśmy poczucie, że dystans się zwiększa z każdym miesiącem. A więc skok jakościowy musi być ogromny – mamy do nadrobienia trzy lata w około rok.

Na końcu mojego planu zawarto potrzebę dualnego rozwoju: jednoczesne poprawianie obecnego produktu (iTaxi 2.x) oraz prace nad nowym (iTaxi 3). Ten, kto pamięta wcześniejsze zmagania z PizzaPortal kojarzy feature freeze (zablokowanie rozwoju obecnego produktu, aby skupić wszystkie siły na nowym). Tym razem chcieliśmy sprobować innego podejścia.

W listopadzie 2016 roku, mniej więcej w tym samym momencie gdy wysłaliśmy plan do reszty management teamu, przeprowadziliśmy w Senfino warsztat, którego celem było wyobrażenie sobie idealnego produktu iTaxi. Następnie strategia zakładała powolne przepoczwarzanie iTaxi 2.x tak, aby użytkownik małymi kroczkami przyzwyczajał się do zmian strukturalnych (kolejność ekranów, elementów w menu, mikrointerakcji, komunikacji aplikacja-serwer, logiki biznesowej itp), ale bez drastycznych zmian graficznych, które wejdą dopiero w finalnym etapie.

Zaraz po warsztatach wysłaliśmy makiety do najważniejszych osób w firmie i tym sposobem rozpoczęła się ponad roczne żonglowanie wymaganiami i zależnościami dwóch filozofii produktowych (manualna kontrola i skalowanie dzięki algorytmowi), trzech platform (iOS, Android i backend), kilkunastu interesariuszy i naszych ambicji.

Strategia

Od początku wisiał nad nami problem konkurowania z przeciwnikami, których kieszenie wydają się bez dna. Część z nas ma doświadczenia z pracy po drugiej stronie i obserwowania produktowego centrum organizacji o kapitalizacji ponad 1 mld Euro i tamtych metod radzenia sobie z konkurencją. Czy było tam cokolwiek, co mogę teraz wykorzystać w odwrotnej sytuacji?

Kluczem okazało się schowanie ambicji do kieszeni i twarde spojrzenie w rzeczywistość:

  • nie zrobimy najlepszego produktu w tej branży, to jest fizycznie niemożliwe i nie ma co zakrzywiać rzeczywistości,
  • tego typu produkt cyfrowy jest na tyle dobry jak jego rzeczywista, fizyczna dostępność,
  • duże firmy mają różne kultury organizacyjne, ale wewnętrzne dynamiki ciągle się powtarzają,

A to oznacza, że:

  • możemy doszusować do konkurencji, tam gdzie relacja progresu do kosztu jest przyzwoita,
  • to jak wygląda aplikacja jest wtórne do tego czy wykona swoją pracę,
  • możemy zmienić pole gry na takie, które nam sprzyja – takie, w którym duże ogranizacje są zbyt powolne,

To nam dało trzy główne kierunki rozwoju:

1. Mały zespół to szybki zespół

Naturalną cechą małych zespołów jest ich spójność i łatwość synchronizacji. Skupiliśmt się na tym, aby chronić zespół przed zewnętrznymi przeszkadzajkami. Mieliśmy jasno postawione cele i każdy fajerwerk, paraliż decyzyjny i inna dekoncentracja była po prostu stratą. Nie mieliśmy tolerancji na stratę czasu i energii. Prowadziło to do poważnego odgrodzenia zespołu od reszty firmy, z mocnymi, czasami autorytarnymi filtrami mówiącymi, co jest ważne a co nie. To ucięło wiele dyskusji, ale wprowadziło sporo napięć poza zespołem.

2. Punkt przegięcia funkcji jakości do kosztu

Tom Gilb lubi powtarzać, że kosztem perfekcji jest nieskończoność. Dla nas oznacza to, że krańcowy wzrost wartości jakości produktu będzie spadać wraz ze wzrostem kosztu (i odwrotnie):

Dwa punkty są ważne na tym wykresie: ten na górze to najlepszy produkt w swojej dziedzinie – najlepszy za każdą cenę. Ma to swoją wartość, gdyż będąc top of mind ma się dużą rynkową przewagę. Problem polega na tym, że koszty bycia w tym miejscu są niewspółmierne. Każdy następny progres produktowy jest robiony z coraz większym wysiłkiem, efektywność włożonej pracy spada z czasem.

Drugi (niższy) punkt na mapie to miejsce, które my wybraliśmy. To punkt przegięcia – miejsce tuż za którym zaczyna się spadanie inkrementalnej wartości. Skąd wiedzieć gdzie znajduje się ten punkt? Wykorzystywaliśmy do tego narzędzie Impact Estimation Table autorstwa wspomnianego wyżej Toma Gilba. Przykładowo moglibyśmy mieć lepiej rozwiązane podpowiadanie adresów tworząc samodzielny mechanizm lub kupując taki od Google’a. To jednak przekraczało nasz zasoby czasowe i finansowe, a więc stosunek wpływu do kosztu był dla nas zbyt niski. Gdyby chodziło o ambicje to byśmy o to mocno walczyli, ale personalne ambicje odłożyliśmy na bok. Aby zapewnić dostarczenie produktu na czas bez marnowania energii zespołu stawialiśmy intencjonalnie poprzeczkę niżej jeśli chodzi o fajewerski i wyżej jeśli chodzi o relacje wpływu do kosztu- tak, aby tego punktu przegięcia nie przekroczyć. Było nam ciężko pracować z takim kompromisem, ale w pełni rozumieliśmy jego potrzebę.

Ten wykres wydaje się prawdziwy także dla poszczególnych funkcji realizowanych w aplikacji. To był moment, w którym zrozumieliśmy, gdzie szukać naszych unfair advantages – tam, gdzie zaspokajanie potrzeb nie jest skorelowane z liczbą osób w dziale IT.

3. Skalowalna hiperlokalność

Jaki jest problem z wielorynkowymi firmami ze scentralizowanym produktem? Koszt alternatywny.

Gdy jesteś szefem produktu działającego na kilku(nastu) rynkach musisz ciągle podejmować decyzje na bazie kalkulacji kosztów alternatywnych. Czy wdrażać najpierw funkcję dla kluczowego, średniego czy peryferyjnego kraju? Co jeśli funkcja dla kluczowego rynku jest kosztowna a dla małego prosta?

Z naszych doświadczeń wynika, że w większości przypadków wybierany jest kluczowy rynek kosztem tych mniejszych – stoi za tym czysty rachunek ekonomiczny (szybciej się zwróci) i mechanizm psychologiczny (większa pewność dobrej decyzji).

Wiedząc, że żaden z naszych konkurentów nie ma programistów na miejscu i decyzje są podejmowane w San Francisco, Hamburgu i Tallinie/Pekinie zaczęliśmy myśleć o budowaniu backlogu biorąc pod uwagę jakie funkcje powinniśmy robić, aby być trudno replikowalnym przez konkurencję, tj. takich, które są dla nas ważne, ale mikroskopijne w oczach międzynarodowej konkurencji.

Chcieliśmy doprowadzić do sytuacji, w której konkurent proszący o replikację naszej funkcji został odesłany z kwitkiem ze względu na istotniejsze projekty. Centralizacja prac powoduje też, że lokalni przedstawiciele zawsze będą mieli związane ręce – sami sobie tych funkcji nie dorobią, bo nie mają kompetencji – a nawet jeśli mają, to ich przewalczenie nie jest warte ryzykowania swojej pozycji w organizacji.

Organizujemy się

Do tej pory w iTaxi pracowano na Redmine. Choć o zmianie na jakiś bardziej współczesny pakiet zarządczy mówiło się od dawna to jednak dwa argumenty przeważały: Redmine jest znany i darmowy. Zamiast z tym walczyć stwierdziliśmy, że łatwiej będzie nam zbudować między zespołem a Redminem lepszy interfejs. Stąd też Trello, które po kilku eksperymentach okazało się dobrym narzędziem, o ile mieliśmy czas na manualną synchronizację między obydwoma narzędzami.

Pierwszy sprint iOSa i Androida rozpoczął się 18.11.2016. Zespół postanowił pracować w sprintach dwutygodniowych. Po około 3 sprintach (1.5 miesiąca) zaczęła budować się rutyna i przewidywalność związana z rytuałami Scruma: sprint review, retrospektywa (tutaj było najtrudniej), planowanie nowego sprintu. Do wyceniania zadań przyjęliśmy potęgi: 1, 2, 4, 8, 16, 32; jeśli zadanie miało 32 punkty to uznawaliśmy je za zbyt duże i wymagające dekompozycji.

W chwili pisania tych słów kończymy sprint #31 z czego 25 było zarządzanych przez tandem Redmine+Trello. Trello stanowiło dobrą wizualną nakładkę na topornego Redmine’a. Ten jednak miał dla nas wielką wartość jako archiwum ponad 7000 wcześniejszych zadań do których mogliśmy się odwoływać. Po sprincie 25 przestawiliśmy się na JIRĘ ze względu na coraz większą kompleksowość podejmowanych zadań.

Każdy sprint backlog miał swoją kolumnę. W każdej kolumnie były zadania, większość z nich ma wskazany kolorem koszt (żółty 2 pkt, pomarańczowy 4 pkt itd). Te cztery cyfry na końcu to numer ticketu w Redmine, w którym są szczegóły techniczne i materiały potrzebne do realizacji zadania. Przesunięcie zadania pod DONE oznaczało, że zadanie zostało wykonane. Jeśli na koniec sprintu jakieś zostało ponad DONE to trafiało do następnego sprintu.

Na koniec każdego sprintu robiliśmy podsumowanie mailowe zawierające efekty naszego Review (listę zrobionych rzeczy wraz z liczbą wyrobionych punktów) i Planningu (lista rzeczy do zrobienia na najbliższy sprint) i rozsyłałem je do całej firmy. Poniżej fragment jednego z takich raportów na koniec sprintu:

Często bywało tak, że wypracowane przez nas funkcje muszą czekać, aż jakiś inny element systemu dojedzie na produkcję, a to oznacza że może minąć miesiąc lub więcej zanim będą widoczne. To co dla nas jest zakończone w lutym zostanie wdrożone w marcu, a w kwietniu stanie się zauważalną zmianą dla organizacji. Z drugiej strony wdrożenie Scruma i wzmocnienie zespołu produktowego szybko dało efekty w postaci dużych i szybkich zmian produktowych. Sporo osób jednak wyrażało zaskoczenie i niezadowolenie z tego, że nie wiedzą, czego i kiedy mogą się spodziewać – brak przewidywalności był stresujący.

Dlatego w maju 2017 roku rozpoczęliśmy tradycję Product Show – comiesięcznych spotkań dla wszystkich chętnych pracowników, gdzie pokazujemy, co robimy w ramach obecnego produktu jak i iTaxi 3. Product Show miało potrójną rolę:

  • zaznajamianie organizacji z iTaxi 3,
  • mechanizm sugerowania nowych rozwiązań,
  • System wczesnego ostrzegania o zmianach.

Nasze spotkania trwały zazwyczaj godzinę naprzemiennych prezentacji zmian i pytań o ich konsekwencje.

Droga do iTaxi 3

Choć obecna transformacja iTaxi 2 na iTaxi 3 wydaje się dużą zmianą widoczną dopiero teraz, to przepoczwarzanie rozpoczęło się rok wcześniej. Podmienialiśmy najbardziej kompleksowe elementy stopniowo rozkładając ryzyko na wiele miesięcy zamiast robić jedną wielką aktualizację (tak musieliśmy zrobić w przypadku PizzaPortal ze względu na problem duplikacji danych w bazie). Dzięki temu mogliśmy testować fragmenty nowego kodu stopniowo i szybciej reagować na problemy.

Z perspektywy użytkownika iTaxi 3 miało premierę niedawno, ale faktycznie z wielu usprawnień tego produktu korzystali już dużo wcześniej. Aby dopasować się do wizji iTaxi 3:

  • wyłączyliśmy zamawianie „z mapy” (12.2016)
  • usunęliśmy samouczek (12.2016)
  • uprościliśmy logowanie i rejestrację (03.2017)
  • zmieniliśmy strukturę menu (05.2017)
  • zreorganizowaliśmy kategorie taksówek (z czterech zeszliśmy do dwóch) (07.2017)
  • usunęliśmy filtry (07.2017)
  • zmieniliśmy logikę zamawiania (07.2017)
  • zakopaliśmy głębiej wybieranie taksówki z listy (07.2017)

I to wszystko zanim jeszcze ktokolwiek zobaczył pierwszy działający prototyp iTaxi 3. Takie podejście spotkało się to ze spodziewanym oporem zarówno ze strony taksówkarzy (dlaczego zabieracie pasażerom kontrolę?), jak i pasażerów (dlaczego zmuszacie mnie do zmiany nawyków?). Te zmiany były potrzebne, choć wtedy, bez kontekstu, wydawały się mało sensowne i wręcz wrogie wobec użytkowników.

Nawiasem mówiąc to jedna z tych wielkich ironii pracy jako produktowiec: aby coś poprawić dla użytkownika, trzeba najpierw mu się przeciwstawić.

To były duże i odważne eksperymenty. W gruncie rzeczy odcinaliśmy fragmenty aplikacji i czekaliśmy na to, kto i kiedy zacznie głośno narzekać. Jeśli nikt, to znaczy, że nikomu na nich nie zależało – czyli postąpiliśmy dobrze. Jeśli pojawiały się negatywne komentarze to wspieraliśmy się danymi statystycznymi, aby sprawdzić czy ci, którzy są głośni są także liczni. To był też czas, gdy wreszcie mieliśmy okazję intensywnie przetestować Google DataStudio – narzędzie do Business Intelligence agregującego sygnały z wielu różnych źródeł (ale najlepiej google’owych). W efekcie zbudowaliśmy system raportowy w skali tygodnia, miesiąca i roku z podziałem na iOSa i Androida:Oraz bardzo mikroskopijny obraz per platforma na najważniejsze kroki w aplikacji:
Traktowaliśmy te wykresy jak bicie serca u pacjenta. Każda zmiana rezonowała na wykresie, nawet te o których nie wiedzieliśmy – jak nagłe załamania pogody czy koncerty. Ten wzrost na wykresach to oczywiście efekt sylwestra i syndrom dnia następnego. Przy okazji pokazuje jak duże mogą być amplitudy popytu w tym biznesie.

Design i UX

W lutym 2017 wizualizacje stworzone przez Senfino zostały wykorzystane jako materiał referencyjny dla naszych własnych prac graficznych. Rozpoczęła się żmudna praca dekomponowania górnolotnego konceptu na realne zadania.

Naszym pierwszym zajęciem było rozpisywanie kolejnych kroków zamawiania i realizacji kursu taksówką: włączenie, logowanie/rejestracja, zamówienie, czekanie na przyjazd, w kursie oraz płatność. Wydaje się proste, ale im głębiej w las tym ciemniej. Userflow rozgałęzia się wielokrotnie ze względu na różne typy użytkowników (prywatni, biznesowi), różne sposoby zamawiania (z mapy, z algorytmu, z listy) czy różne sposoby płatności (aplikacją, gotówką, na fakturę). Celem było wyeliminowanie zbędnych elementów, ale musieliśmy uważać w naszym redukcjoniźmie, aby przypadkiem nie usunąć czegoś, co rozpocznie lawinę nieoczywistych problemów.

To była nasza nauczka przy wspomnianej już modyfikacji potrzebnej przed iTaxi 3 – zmianie kategorii taksówek z czterech do dwóch. Modyfikacja, która miała przynieść łatwiejsze rozeznanie i przyśpieszenie zamawiania, wprowadziła nieoczekiwane zamieszanie po stronie obsługi: taksówki, które do tej pory były w niższej kategorii wpadły do wyższej przez co spadła im liczba zamówień (bo naturalnie bardziej luksusowa kategoria miała mniej amatorów). Byli też taksówkarze, którzy poczuli się zdegradowani, gdy spadli ze zlikwidowanej kategorii środkowej do najniższej. Gdyby tego było mało ,musieliśmy ze względów technicznych i biznesowych utrzymać wewnętrzną nomenklaturę nazewnictwa, więc w efekcie zamiast zredukować problem to wydłużyliśmy katalog zależności i definicji do zapamiętania. Brak myślenia o efektach drugiego rzędu w praktyce – i nauczka na przyszłość.

Nasze makiety lo-fi powstawały z wykorzystaniem trio iPad Pro, Apple Pencil i aplikacji Goodnotes. Techniczna walidacja tak narysowanych idei nastąpi dopiero gdy developerzy wdrożą elementy przygotowane na ich podstawie – nie przywiązywaliśmy się więc do nich zbyt mocno.

Podczas wewnętrznych warsztatów i wywiadów z użytkownikami zebraliśmy listę najważniejszych problemów i frustracji. Było ich sporo, ale dominowało poczucie niepewności. Po zanalizowaniu wszystkich artefaktów badań powstało podsumowanie do managementu:

„iTaxi jest postrzegane jako usługa niepewna. To znaczy, że deklarowany czas różni się od faktycznego, jakość samochodu i profesjonalizm kierowcy to ruletka, nie wiadomo też czy kierowca faktycznie wykona to, o co się go prosi. W przypadku kursów B2C jest to rynkowo akceptowane ze względu na bardzo niską cenę i price dumping, ale podobne sytuacje w B2B mają o wiele gorsze konsekwencje (…)”

Na ten problem składało się mnóstwo elementów: od takich których nie kontrolujemy (percepcja zawodu taksówkarza), takie na które mamy wpływ (standard floty i zachowanie naszych kierowców) i takie, które są w pełni zależne od nas (interakcja z aplikacją). Na poziomie aplikacji mieliśmy ograniczone możliwości budowania zaufania (większość interakcji odbywa się podczas samego przejazdu, a najmocniej w głowie zapada zakończenie kursu) więc skupiliśmy się na tworzeniu interfejsu, który jest zgodny z oczekiwaniami, znajomy i wyglądający współcześnie. Co to oznacza w praktyce?

  • upraszczanie likwiduje ślepe uliczki (minimalizuje niepewność związaną z brakiem zrozumienia logiki systemu),
  • poprzestawianie przepływu ekranów i kolejności elementów na ekranach (lepiej informuje o istotności funkcji: najważniejsze jest najlepiej widoczne),
  • dodanie bardziej dynamicznych animacji przy mikrointerakcjach (zwiększa zaufanie do szybkości aplikacji),
  • zmiana designu i ikon (zwiększa przewidywalność przez znajomość – korzystaliśmy z zasobów Material Design i Human Interface Guidelines)

Rysowanie makiet Lo-Fi to była ciągła walka: dwa kroki do przodu, jeden do tyłu. Ekrany „płyną” – jeden zależy od drugiego i muszą trzymać się tych samych wzorców, aby użytkownik miał intuicyjne poczucie, gdzie się znajduje. Do tego dochodzi jeszcze następny wymiar skomplikowania – trzeci wymiar. Tutaj czuję, że poległem w odpowiednim rozplanowaniu osi Z w aplikacji. Nie udało się uprościć aplikacji na tyle żeby utrzymać tylko dwie warstwy głębokości aplikacji, co było moją pierwotną ambicją.

Rysowanie makiet przeplatało się z obserwowaniem jak konkretne problemy są rozwiązywane przez inne aplikacje okupujące podobną niszę – nie tylko bezpośrednią konkurencję, ale także interfejsy związane z przemieszczaniem ludzi lub przedmiotów w przestrzeni. Na przykład studiowaliśmy wnikliwie jak wygląda wpisywanie adresu startowego i docelowego – czy są to dwa oddzielne ekrany, jeden wielowątkowy czy sekwencyjny? Jak duże powinno być zagęszczenie informacji? Gdzie umieścić (jak wysoko w hierarchii) ulubione adresy w kontrze do historycznych adresów? Czy przy pojawieniu się ekranu adresu klawiatura powinna być (uwaga, anglicyzmy) od razu widoczna z focusem na inputfieldzie? Czy tooltip na inputfieldzie powinien znikać gdy pojawia się tam focus? Czy wyszukiwanie powinno odbywać się po wpisaniu jednej, dwóch czy trzech liter?

Decyzje na tym etapie kaskadowo roznosiły się na resztę aplikacji, bo użytkownik oczekuje, że każdy powtarzalny element interfejsu zachowuje się tak samo niezależnie od miejsca w systemie. To miało znaczenie nie tylko estetyczne, ale także biznesowe: im mniejszy wysiłek kognitywny związany z korzystaniem z usługi tym większy zysk dla użytkownika i potencjalnie większa jego powracalność.

Menu główne – przykład na przemodelowanie hierarchii funkcji. Z długiej listy elementów wizualnie sugerującej podobną istotność usunęliśmy część funkcji, zwiększyliśmy istotność (wielkość) kategorii głównych, przesunęliśmy dalej we flow inne oraz przenieśliśmy na wierzch opcję przełączania się między kontami.Szczegóły kursu – ułatwiliśmy zamawianie przez szybkie adresy widoczne od razu, eliminacje natłoku niezrozumiałych ikon i mocniejsze kontrastowanie elementów. Filtry/opcje – wynieśliśmy kategorie taksówek z obecnych czterech (Economic, Comfort, Premium i Wszystkie jeśli nic/wszystko zaznaczone) do dwóch widocznych na ekranie wcześniej (Popularna, Luksusowa) z domyślnym zaznaczeniem Popularnej. Przemyśleliśmy na nowo wybór liczby pasażerów i zmniejszyliśmy liczbę filtrów, aby nie przytłaczać możliwościami.

Animacje – są bardziej dynamiczne dzięki czemu użytkownik czuje większą przyjemność w interakcji.

Aby dać Wam pewien obraz skali tego procesu: przetestowaliśmy w tym czasie fizycznie (tam gdzie są geograficznie dostępne) i wirtualnie (spoofując geolokalizację i resztę dopasowując na bazie tutoriali na Youtube i FAQu na stronach firm) 23 aplikacje – rynkowych liderów z każdego kontynentu oraz najpopularniejsze rozwiązania w Polsce. To, do czego dążylismy to asymilacja przydatnych rozwiązań, do których użytkownicy już się wystarczająco przyzwyczaili (pamiętając o tym, żeby obniżyć ich wysiłek kognitywny) przy jednoczesnym odrzuceniu niepasujących logicznie lub strategicznie resztek oraz nadaniu całości naszego własnego sznytu.

Mniej wiecej w połowie moich prac na makietami swoją część rozpoczęła nasza graficzka. Łącząc artystyczny kierunek nadany wcześniej z naszymi makietami lo-fi zaczęła wizualizować je w formie makiet hi-fi. Aby to ułatwić i pokazać progresję z ekranu do ekranu połączyliśmy je ze sobą korzystając z Marvela. Przygotowaliśmy też spis wymagań dla makiet hi-fi. Plik był krótki:

Im dalej w las tym grafiki powstawały szybciej. Tak samo jak w przypadku makiet lo-fi wiedzieliśmy, że w przeciągu następnych 8 miesięcy jeszcze sporo będzie się zmieniać, ale coraz większa baza elementów dawała coraz większą pewność co do kierunku i kształtu iTaxi 3.

Jest kilka rzeczy, które chcieliśmy zaznaczyć tym projektem. Pierwszą z nich jest przekonanie, że dobry design zwiększa lojalność użytkowników. Wierzymy mocno w to, że ludzie świadomie i podświadomie lubią obcować z ładnymi rzeczami, takimi, które mają swój przemyślany styl i rytm. Chcieliśmy też złożyć hołd dla fontu Lato autorstwa Łukasza Dziedzica. To jeden z najlepszych produktów jakie eksportujemy – powinnismy być z tego bardzo dumni.

Spalanie punktów

Wróćmy jednak do maja 2017 – do tego czasu wytrzymała idea dualnego rozwoju iTaxi 2.x i iTaxi 3. Chwilę wcześniej oszacowaliśmy sumę punktów potrzebnych do zakończenia iTaxi 3 w oparciu o dotychczasowe wyceny i uśrednione tempo spalania punktów w sprincie. Jedno stało się jasne: jeśli nic się nie zmieni to nie wyrobimy się w roku 2017 z premierą.

Było kilka możliwości do rozważenia – najpopularniejsze to zatrudnienie dodatkowych ludzi do zespołu lub wyniesienie części pracy na zewnątrz. Pierwsza jednak wcale by nie przyśpieszyła prac, bo nowi developerzy muszą dostosować się do metod pracy zespołu i zaznajomić z kodem, co trwa, a do tego także zajmuje czas obecnego zespołu. Druga propozycja była dla nas na tamten moment zbyt droga (i też wymagałaby czasochłonnej synchronizacji). Ostatecznie więc byliśmy zmuszeni znów zastosować feature freeze i generalne usztywnienie na wdrażanie nowych rzeczy w iTaxi 2.x poza szczególnymi przypadkami jak naprawa krytycznych błędów.

W sierpniu 2017 wiedzieliśmy, że nawet całkowite skupienie na iTaxi 3 nie gwarantuje nam dostarczenia na listopadowy termin. Wybraliśmy listopad ponieważ grudzień jest w tej branży bardzo chaotycznym miesiącem: zła pogoda oraz firmowe imprezy świąteczne jednocześnie generują duży popyt i ograniczają podaż. Następnie są święta i zapotrzebowanie na taksówki szoruje po ziemi. Chwilę później jest nowy rok i nasza infrastruktura grzeje się do czerwoności. Wydawanie nowej aplikacji w tym czasie nie pozwoli nam zrozumieć jak została odebrana przez pasażerów – zbyt mocne siły rynkowe zaszumiłyby nasze dane. Dlatego ostatecznie zdecydowaliśmy sie wystartować w połowie stycznia, gdy warunki zewnętrzne będą bardziej przewidywalne.

Burndown Chart to prawdopodobnie najczęściej wykorzystywane przez nas narzędzie przy pracy nad iTaxi 3. Przedstawialiśmy go co tydzień na naszych management meetings. Pokazuje jak szybko zespół pracuje („spala” zakres pracy). Burndown jest podzielony na dwa wykresy – iOS i Android. Zaczyna się w okolicach 320 punktów – na tyle oszacowaliśmy ciężar na platformę (na bazie wcześniejszych doświadczeń przy iTaxi 2.x). Niebieska linia to optymistyczny wariant tempa pracy a zielona pesymistyczny (choć wolę go nazywać realistyczym). Obydwie powstały na bazie wcześniejszego tempa pracy z uwzględnieniem bus factora, urlopów, narzutu komunikacyjnego i spowolnienia wynikającego z badań. Ostatecznie oznaczało to zdjęcie 30-50% z szybkości zespołu. Żółta linia to faktyczna szybkość pracy. Gdy linia osiągnie zero to teoretycznie oznacza, że prace są zakończone.

Kilka rzeczy więcej można z tych wykresów wyczytać – na przykład jak Android zaczął swoją pracę przed czasem a iOS był trochę do tylu i przez cały czas gonił. Poziome wypłaszczenia na żółtej linii to święta i urlopy a więc generalne spowolnienie. Widać też wyraźnie, że przez 2/3 czasu pracy szło nam gorzej niż się spodziewaliśmy, a później nastąpiło przebicie zielonej linii i przyśpieszenie. Jest to normalne (na tyle na ile możemy powiedzieć z naszego doświadczenia), bo ta pierwsza faza to pokrywanie całego flow projektu, a więc najwięcej nieoczekiwanych korekt, druga faza to przewidywalne poprawianie istniejącego kodu, a więc wzrost szybkości.

Samo spalanie punktów odbywało się wzdłuż flow użytkownika. To znaczy, że nie szukaliśmy największych ani najmniejszych zadań na początek tylko szliśmy kolejnością ekranów jakie widzi użytkownik. Po korekcie terminu startu z listopada na styczeń oraz coraz mocniejszym żonglowaniu zakresem prac im bliżej startu udało nam się dojechać do końca projektu dokładnie na środku między optymistyczną a realistyczną linią spalania punktów – co uznajemy za duży sukces.

Jobs To Be Done

Jobs To Be Done to metoda myślenia o produktach i usługach zaproponowana przez Claytona Christiensena, autora fenomentalnych książek biznesowych o disruptive innovation. Główne założenie jest takie, że ludzie nie *kupują* rzeczy a *zatrudniają* je do zrobienia konkretnej pracy (video prezentacją na ten temat można znaleźć tutaj). Aby wyobrazić sobie jak duże to ma znaczenie i jak stawia do góry nogami myślenie strategiczne pomyślcie o tym: o realizację pracy jaką jest „spotkanie twarzą w twarz z klientem na drugim kontynencie” konkurują ze sobą i linie lotnicze i software do telekonferencji, dwie zupełnie różne kategorie firm i branż.

Byliśmy przekonani, że możemy dużo zyskać korzystając z JTBD w praktyce. Do czego ludzie zatrudniają taksówki? Kto z nami konkuruje oprócz oczywistych przewoźników? W tym miejscu nie powiemy dużo więcej, bo wnioski stanowią ważną część naszej strategii.

Podczas wywiadów z pasażerami doszliśmy do wniosków, że przestrzeń taksówki jest traktowana przez pasażera i kierowce jako własność kierowcy. Świadczy o tym personalizacja jaką kierowcy nadają swoim samochodom: różne umiejscowienie taksometru, ulotki, naklejki, odświeżacze powietrza i inne osobiste dodatki odzwierciedlające charakter kierowcy tak, aby czuł się „u siebie”. Pasażerowie jednak, ze względu na brak standaryzacji i neutralności przestrzeni w jakiej się znajdują podczas kursu, świadomie i podświadomie unikają modyfikacji tej przestrzeni, gdyż nie czują się „u siebie”. Czują, że zasady tego 20-30 minutowego kontraktu zostały już z góry ustalone. Jednocześnie jednak kierowcy czują silną potrzebę dostosowania się do pasażerów. Mają misję i chcą dbać o dobre warunki pasażera, wiedzą, że jego przewóz ma kluczowe znaczenie dla całego dnia tej osoby. Są więc otwarci na sugestie i modyfikacje tego kontraktu. Wokół tego zbudowany jest etos taksówkarza.

W jaki sposób godzić takie rozbieżności?

Coraz większą grupą naszych użytkowników są klienci biznesowi. To ludzie, którzy jadą na spotkania biznesowe na drugą część miasta, aby zrobić prezentację, uczestniczyć w konferencji, walczyć w negocjacjach, wygrywać przetargi. Każdy z tych przypadków wymaga wcześniejszego merytorycznego przygotowania i, w odczuciu naszych klientów, czas w taksówce jest do tego idealny. To moment na ostatnie poprawki w prezentacji, ostatnie przećwiczenie przemówienia.

Łącząc te sygnały zdecydowaliśmy się wdrożyć jako jedną z ostatnich funkcji przed premierą opcję Cichy przejazd. Jeśli pasażer w swoim profilu zaznaczy opcję „Cichy przejazd” to kierowca w komentarzu do zlecenia dostanie informację, aby ściszyć radio i nie rozpoczynać dyskusji, bo pasażer potrzebuje skupić sie na pracy lub chce odpocząć. Choć ta funkcja spotkała się z kilkoma krytycznymi głosami (głównie o przedmiotowe traktowanie kierowców) to czuję, że to jeden z elementów negocjowania kontraktu – tak, aby osiągnąć win-win najniższym emocjonalnym kosztem.

Czas dojazdu na miejsce – na bazie wyżej opisanego wniosku o klientach biznesowych zdecydowaliśmy sie wdrożyć także inną pożyteczną funkcję: dynamiczne pokazywanie ETA (estimated time of arrival) podczas dojazdu. Jednym z największych lęków przy przejazdach biznesowych jest ryzyko spóźnienia na spotkanie – to nigdy nie buduje dobrego piewszego wrażenia. Klienci zamawiający przejazdy biznesowe zazwyczaj w głowie kalkulują ile czasu zajmie im przejazd, dodają sobie w pamięci kilka minut zapasu, ale nie mają pełni wiedzy o obecnym stanie przepustowości ulic. Aby obniżyć stres pasażera w trakcie kursu pokazujemy więc na dole ekranu czas do miejsca docelowego oraz godzinę, o której będzie na miejscu. Dzięki temu wie, czy wyrobi się na swoje spotkanie o 9:30 czy należy informować o spóźnieniu jeszcze gdy jest to społecznie akceptowalne.

Dalsze tego typu rozwiązania będą pojawiać się z czasem.

Testy

Jeśli mielibyśmy opisać różnicę w skomplikowaniu iTaxi i PizzaPortal to chyba najlepiej to porównać tak: iTaxi to tysiące restauracji, które ciągle zmieniają swoje adresy. To przemieszczanie się jest dużym problemem przy testowaniu naszych rozwiązań: czas reakcji systemu i szybkość parowania obiektów ma fundamentalne znaczenie dla odbioru usługi. Ten czas jest zależny od wielu elementów, zależnych i niezależnych od nas: pozycji geograficznej, jakości sygnału GPS, kierunku jazdy, korków, remontów drogowych, wypadków, specyficznych zachowań mieszkańców konkretnych miast i tak dalej. To wszystko jest dodatkowo potęgowane przez bardzo mocny efekt sieciowy: więcej taksówek to więcej pasażerów więc więcej taksówek. Poza tym o ile na pizzę ludzie są gotowi czekać 30 minut lub godzinę, to taksówkę chcą mieć w przeciągu kilku minut.

To wszystko powoduje, że testowanie nowych rozwiązań staje się bardzo kłopotliwe bo ciężko jest wyizolować grupę odniesienia: codziennie warunki się zmieniają więc wszystkie eksperymenty obarczone są dużym ryzykiem powstawania false positives.

W połowie listopada 2017 wysłałem do management teamu maila z planem testów:

B3E5A6AF-B8D6-43E2-ABBE-C0D801E7D634

Pierwszy testowy kurs wykonaliśmy 25.11, chwilę później zaczęła jeździć grupa 50 wewnętrznych betatesterów uzbrojonych w listę ponad 40 przypadków testowych. Ten moment dobrze ilustruje szybkość przyrostu zadań na wykresie kumulatywnym iOSa (poniżej). W kulminacyjnym momencie mieliśmy ponad 200 wykrytych błędów – od krytycznych jak zrywanie sesji w trakcie korzystania z aplikacji do trywialnych jak font niezgodny z designem. W tym samym czasie wydawaliśmy wersje średnio co 2-3 dni naprawiające po kilka-kilkanaście z nich.

Przykład na cyzelowanie aplikacji – dopasowywanie wersji beta do grafik. Przechodziłem razem z działem testów przez każdy ekran, aby wyszukiwać rozbieżności między „idealną” wersją aplikacji a stanem faktycznym.

Start!

Termin startu mieliśmy wyznaczony na poniedziałek 15 stycznia 2018. Ostatnie sprinty były usłane wieloma trudnymi decyzjami: co wchodzi, a co nie wchodzi do pierwszej wersji? 28 grudnia przygotowaliśmy listę rzeczy, które powinny znaleźć się w aplikacji przed startem:

Musieliśmy być realistami i powiedzieć sobie jasno co jeszcze możemy zmieścić, a co musimy odrzucić. Z każdym następnym dniem mieliśmy coraz mniejsze pole do manewru. Wiedzieliśmy jednak, że bez jasnej i namacalnej (choć sztucznej) daty startu będziemy rozciągać nasze prace w nieskonczoność mówiąc sobie, że zawsze możemy dać sobie jeszcze dzień, albo tydzień, albo miesiąc. Woleliśmy już wypuścić niepełną wersję niż czekać na ideał. Ostatecznie największe i najtrudniejsze rzeczy (jak usuwanie terminówki i rejestracja B2B) zeszły na sam koniec, co w praktyce eliminuje je z listy premierowych funkcji. Ktoś może zapytać jak to się stało, że ekran pomocy czy uśmieszek na pinie okazały się ważniejsze mimo swojej trywialności? Bo to są elementy, które 100% użytkowników doświadczy, a te powyższe rzeczy będą istotne, ale dopiero jak ktoś je zobaczy. Czego oczy nie widzą, tego sercu nie żal.

Mieliśmy do wykonania kilka żmudnych, nudnych ale potrzebnych rzeczy jak poprawa literówek i weryfikację angielskich tłumaczeń. Aby mieć pewność, że omijamy jak najmniej rzeczy (bo nie mamy złudzeń, że wszystko wychwycimy, nie przy tak złożonym projekcie) zrobiliśmy spotkanie przy dużym stole – po jednej stronie developerzy ze swoimi komputerami, marketing, ja i dwie osoby z działu testów. Sprawdzaliśmy ekran po ekranie obydwie platformy i jak tylko pojawiała się nieścisłość to programiści od razu je poprawiali w kodzie.

Mimo to nie wyrobiliśmy się. Ciągle odkrywaliśmy nowe niezałatane dziury, których nie chcieliśmy mieć w pierwszej publicznej wersji. Cały dzień spłynął nam na poprawkach.

16 stycznia 2018 do sklepu Google Play trafiła wersja na Androida. Chwilę później wersja na iOS. Choć mieliśmy jeszcze kilka problemów po drodze (jak szybkie napisanie poprawki na starsze wersje iOSa i niedziałający App Store w najgorszym momencie) to otworzyliśmy już wtedy szampana, żeby symbolicznie zamknąć klamrą ten 15 miesięczny projekt.

Miesiąc to za mało, żeby mieć pewność, że nowa wersja poprawia nasze wyniki jako organizacji. Choć widzimy znaczną poprawę w konwersji to nie wiemy w jakim stopniu wpłynęły na to zmiany pogody czy ferie. Musimy poczekać na inne dane, szczególnie analizy kohortowe, aby wyrobić sobie zdanie. Do tego czasu pozostają nam jedynie dane anegdotyczne:

Z których wynika, że chyba poszło nam całkiem dobrze :)

Jeśli jednak chcesz się sam(a) przekonać jak nam poszło to zapraszam do ściągnięcia iTaxi 3!


Nota od autora

Ten tekst to próba odtworzenia kilkunastu miesięcy pracy naszego zespołu w iTaxi. Pierwsza wersja tego artykułu miała bardziej personalny wydźwięk, ale teraz, pozbywając się tego liczę, że jest bardziej obiektywny i wyważony. Przez wszystkie akapity powyżej wypowiadałem się jako pracownik iTaxi, ale poniższa część to już moje osobiste posłowie, nie należące już bezpośredni do analizy.

Codziennie w biurze iTaxi przechodzę obok tego plakatu:

Jego przekaz wbił mi się w mocno w moją świadomość. Mam w głowię jakąś potrzebę do dążenia do szczerości produktu. Ta szczerość oznacza, że każdy naciśnięty przycisk spełnia swoją obietnicę. Wierzę w to, że drogą do tej szczerości jest prostota formy i funkcji. Z tym podejściem walczy jednak drugi z moich pryncypiów: odpowiedzialność za użytkownika. Często prostota jest błędnie zastępowana kontrolą. To znaczy, że zamiast upraszczać rzeczy użytkownikowi biorąc na siebie chaos, który jest pod spodem, przerzuca się na niego odpowiedzialność maskując to większą liczbą opcji, funkcji i innych symboli kontroli. Uważam to za błąd, bo wymusza na kliencie niepotrzebny kognitywny ciężar. Nasz świat już teraz jest zbyt kompleksowy i skomplikowany, aby jeszcze bardziej go utrudniać.

Nowa wersja aplikacji iTaxi to próba wzięcia tej odpowiedzialności za ten chaos, zatrzymanie i odwrócenie procesu komplikowania i ostatecznie obniżenie ciężaru kognitywnego. Ironia losu polega na tym, że nigdy nie będę wiedział czy to się udało. To co jest najważniejsze jest najtrudniejsze do policzenia i nawet liczby w Excelu i wykresy w Data Studio nie są wstanie pokazywać tylko mały fragment tej historii. Czas oceni te zmagania.

Dziękuję całemu zespołowi (Ania, Marcin, Kasia, Gaweł, Kamil, reszta działu IT) za zaufanie oraz ponownie Lechowi za danie mi wolnej ręki. Mam nadzieję, że było warto!

Marcin Zaremba
Chief Product Officer
iTaxi

2017

Zgodnie z wieloletnią już tradycją (2013, 2014, 2015, 2016) piszę podsumowanie ostatnich 12 miesięcy

Ciężary

Prawdopodnie jedną z najbardziej odczuwalnych zmian w tym roku było u mnie zainwestowanie czasu w siłownię i podnoszenie ciężarów. Z pominięciem dwóch dużych dziur związanych z wyjazdami ćwiczyłem siłowo 2-3 razy w tygodniu przez 9 miesięcy, a w szczycie formy udało mi się w martwym ciągu podnieść 142,5kg i 132,5kg w przysiadzie. Czuję z tego dużą satysfakcję i ciągle siedzą mi w głowie słowa Marka Rippertoe, który dobrze podsumowywuje także moje podejście:

„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.”

Jedyne zdjęcie na którym widać, że faktycznie coś podnoszę

Odcięcie

Drugą największą zmianą jaką odczułem w tym roku było odcięcie od (social) mediów. Zaczynałem od małych kroczków: zainstalowałem aplikację „Moment” sprawdzającą ile czasu spędzam na telefonie (wyszło 4-5h dziennie). Przeraziło mnie to odrobinę. Aby temu zaradzić zainstalowałem inną: „Freedom” – VPN, który pozwala filtrować w jakim czasie jakie aplikacje mają dostęp do Internetu (to taka kontrola rodzicelska nałożona na samego siebie). Odciąłem wszystkie serwisy newsowe, Youtube, Facebooka, Twittera, Amazona, Instagrama, Linkedina itd. Zaczynałem od kilku godzin dziennie, później robiłem sobie czas na media podczas lunchów w pracy. Teraz jestem na etapie, że w dni robocze mam blokadę 9:30-16:00 a w weekendy 12:00-19:00. Do tego w każdy wieczór między 20:00 a 21:00 – wtedy, gdy moje dziecko powinno (teoretycznie) zasypiać.

Cały czas czuję syndrom odstawienia, ale widzę w tym ruchu dużą wartość osobistą. Mam poczucie, że umiejętność odcięcia się od internetowego fastfoodu stanie się (staje się?) jakąś formą personalnej przewagi konkurencyjnej.

Smog

Co poszło nie tak? Największe pogorszenie mojego życia jakie odczułem to jakość powietrza w Warszawie i w sumie całej Polsce. Oczywiście zdaje sobie sprawę z tego, że to nie jest nowy fenomen, ale w 2017 był dla mnie szczególnie istotny bo uświadomił mi, że wychodząc w zimę na spacer po stolicy zmuszam moje dziecko do biernego palenia kilku papierosów. Najbardziej frustruje mnie bezsilność. Co mogę zrobić? Wstawić kilka oczyszczaczy do domu i przeczekać najgorsze, ale przecież to nie rozwiązanie, bo problem jest systemowy.

Jeśli miałbym się wyprowadzać z Warszawy, to jedną z głównych motywacji byłaby jakość powietrza.

Książki

Zaużyłem ciekawą zmianę w moim guście książkowym: w tym roku pojawiły się na liście biografie (Halik, Lem, Sat-Okh). Niespodziewałem się, że zaczne czerpać przyjemność w głębokim poznawaniu życia konkretnych jednostek. Do tej pory interesowały mnie bardziej tematy makro (idee, procesy, systemy, ) a nie mikro. Nie wiem z czym to jest związane, może to próba odnalezienia się w świecie, w ktorym nie istnieje platoniczny puryzm? Ludzie-wzory mają swoje ciemne strony, ideały nie są idealne, a dobre intencje mają niezamierzone konsekwencje…

Podmywanie fundamentów

W zeszłym roku pisałem o tym, że buduje osobiste ideologiczne fundamenty. Ten rok z kolei to czas ich podmywania na kilku poziomach. Szymon (w ramach Otwieracza) od samego początku atakował moją wiarę w technologiczny solucjonizm, ale w tym roku trafiał bardzo celnie. Moja wiara w obiektywizm nauki została zweryfikowana przez NN Taleba, opisującego jak ludzie się kaleczą siebie i innych metodą naukową. Moja wiara w samokorekcyjny mechanizm systemów państwowych została nadszarpana przez obecną sytuacją polityczną.

Ostatecznie jednak uświadomiłem sobie jedną rzecz: „puryzm” nie istnieje, to pojęcie platoniczne. Nie ma złych i dobrych ludzi – spektrum jest znacznie szersze i wszyscy się na nim poruszamy świadomie i nieświadomie (to mi pokazują przeczytane biografie)

Mam więcej wątpliwości niż rok temu. Nie czuję jednak, aby to było złe. Choć posiadanie ich jest mentalnie nieprzyjemne (nic tak nie ułatwia życia jak fanatycznie niewzruszony światopogląd) to jednak traktuję to jako coś pozytywnego. Tegoroczne lektury dały mi do zrozumienia, że posiadanie wątpliwości jest potrzebne do rozwoju.

Ewolucja myślenia

2017 to był klejny rok mojej ewolucji myślenia o sobie w kontekście rozwoju zawodowego. Mam poczucie, że kontynuuje proces jednoczesnego pogłębiania, ale i uogólniania tego, co czuję, że: powinienem robić, wnosi wartość i przynosi mi satysfakcję.

Na początku moich podsumowań opisywałem siebie jako specjalistę od aplikacji mobilnych (o tym napisałem w końcu książkę). Moje wnioski i doświadczenia zacząłem przenosić na pole rozwoju produktów technologicznych, a teraz czuję, że powinienem skupić się konkretnie na polu metod podejmowania decyzji w zarządzaniu produktami technologicznymi. To jest sfera, która mnie w tym roku najbardziej interesowała: dlaczego konkretne firmy podejmują konkretne decyzje; co pcha ludzi w stronę strategii A a nie B; jak dobrze decydować w przypadku niepełnych danych; modele podejmowania racjonalnych decyzji; sposoby dekompozycji decyzji i tym podobne. Mam poczucie, że to otwiera przede mną nowe obszary i daje nowe narzędzia do pracy.

Bycie ojcem, cz. 2

Dwanaście miesięcy w życiu dziecka to bardzo długo, ale mi minęło bardzo szybko, bo nie ma tygodnia, aby mój syn nie nauczył się czegoś nowego. Niemal naocznie widać jak formują mu się nowe umiejętności kognitywne, katalog rozpoznawanych rzeczy i czynności, rozpoznawanie emocji, kontrolowanie własnego ciała czy umiejętność mówienia „nie” (to pierwsza oznaka samoświadomości i poczucia odrębności). Co to oznacza? Że mogę mu powiedzieć, żeby wyrzucił papierek do śmieci i to zrobi. I jestem z tego dumny.

Staram się ze Stasiem spędzać jak najwięcej czasu, ale ma to swoją drugą stronę: przestałem być właścicielem tego czasu. Coraz mniej udaje mi się „oszukiwać” – dać dziecku zajęcie i samemu się zrelaksować. Młody już to wyczuwa. I tutaj znów nauczka z pochopnego oceniania innych: bardzo mnie oburzało jak widziałem matki i ojców rozmawiających w kawiarniach, gdy dziecko ogląda bajkę na Youtube. Jak oni mogą tak olewać jego wychowanie? Teraz już wiem: może oni po prostu zrozumieli, że najpierw sami muszą się dobrze czuć, jeśli ich dziecko ma się dobrze czuć.

Miałem w tym roku kilka sytuacji, gdy na parę dni byłem daleko od Stasia. I, przyznam się szczerze, czekałem na te momenty bo „odzyskiwałem” mój czas. Jednak po maksymalnie dobie docierało do mnie tak mocne poczucie tęsknoty, że traciłem energię do robienia tych wszystkich rzeczy, które tak bardzo chciałem w spokoju zrobić (a nie jestem ckliwym człowiekiem). Najbliższa rzecz do jakiej mogę to porównać to syndrom sztokholmski. A może po prostu to zwyczajna bezinteresowna, organiczna miłość.

Podróże

Mój dysonans spowodował, że niemal zapomniałem jak dużo miejsc udało mi się w tym roku zobaczyć. Zaczynając od pierwszego wspólnego wypadu na narty do włoskiej Marillevy 1400 (najbardziej brutalny brutalizm architektoniczny jaki widziałem), chwilę później powrót do San Francisco znów na zaproszenie Google’a, wakacje w Toskanii z całą rodziną w miejscu tak pięknym, że do tej pory nie mogę uwierzyć. I końcówka roku odwiedziny u mojego studiującego brata w Holandii.

Większość tych podróży odbyła się ze Stasiem. Jesteśmy żywym przykładem, że z dzieckiem, nawet najmniejszym, da się podróżować.

Na opak

Jako, że czerpiemy z Pauliną przyjemność z robienia rzeczy na opak to postanowiliśmy z Pauliną wziąć ślub, rok po tym jak urodził nam się syn. Zamast robić z tego pompę zorganizowaliśmy małe wydarzenie dla najbliższych w parku. Czy to coś zmienia w naszym życiu? Nie. Czy było nam potrzebne? Nie. Czy było warto? Tak, i niebagatelną rolę miało w tym dla mnie to, że wyszliśmy poza schemat i stereotyp.

Widzę ostatnio wyjątkowo dużo plusów społecznego „przesunięcia fazowego”: robienia rzeczy nie w czasie, w innej skali, w odwrotnym kierunku, po sezonie, poniżej radaru, poza algorytmem. Poza satysfakcją osobistą są także plusy ekonomiczne: rzeczy są tańsze i łatwiej dostępne a infrastruktura nie jest rozgrzana do czerwoności. Polecam na przykład wypad na basen, gdy wszyscy stoją w kolejce po zakupy świąteczne.

Podsumowując

Zabawna sprawa, która w tym roku odkryłem: faktycznie jest lepiej niż uważam, że jest. Gdy siadałem do tego podsumowania myślałem, że w tym roku mało podróżowałem, a tymczasem wyjeżdżałem częściej niż raz w miesiącu. Myślałem, że siedzę ciągle nieruchomo w pracy a 5-7h w tygodniu spędzam na intensywnej aktywności fizycznej (nie licząc bieganiem za dzieckiem:). Byłem przekonany, że mam mało czasu na czytanie a przecież mam przeczytane 23 książki (4 więcej niż w 2016). Skąd ten dysonans?

2017 to rok, który potwierdza jeden z moich wcześniejszych wniosków: dorosłość dla mnie oznacza zrozumienie, że jest się częścią większej całości. Nie byłoby mnie tutaj, gdyby nie ogromne wsparcie mojej wspaniałej żony, niekończącej się cierpliwości rodziców (i teściów!) i całej rzeszy ludzi, którzy czynnie i biernie pomagają mi realizować moje plany. Macie moją wdzięczność, nawet jeśli nie potrafię tego okazywać.

2018

Wchodziłem w 2017 rok zaniepokojony tym, co przyniesie nowy rok. Mam poczucie, że moje obawy są ciągle uzasadnione, ale odłożone na wysoką półkę. Mogą się zmaerializować, spaść i rozbić się z hukiem, ale to chyba jeszcze nie jest ten moment. Natomiast przyzwyczaiłem się, że one ciągle tam są i trzeba z nimi żyć.

Wchodzę w 2018 rok z poczuciem, że to nie będzie standardowy rok. Kilka osobistych i zawodowych inwestycji rozpoczętych we wcześniejszych latach może się w nim zrealizować co w połączeniu z sytuacją dookoła może mieć piorunujący efekt na życie moje i moich najbliższych.

Albo i nie. Przekonamy się!

Na wszelki wypadek

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.

FF7E4F7E-DC1D-46D9-8744-F4F28BE094C9

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.