Polskie IT konkuruje z gigantami z Silicon Valley, czyli nowa aplikacja mobilna dla kierowców iTaxi [case study]

Kontekst, czyli zderzenie starego i nowego świata

Środowisko taksówkarzy jest specyficzną grupą. Kierowcy przyzwyczajeni do „starego porządku” zderzają się tu z tymi, którzy z zapałem podchodzą do zmian, wynikających z rozwoju technologii. Warto sobie przypomnieć czasy, gdy nie było żadnych aplikacji, dzięki którym można zamówić taksówkę. Wtedy należało wyszukać samochód z charakterystycznym „kogutem taxi” na dachu na postojach albo wprost na ulicy, bądź też zadzwonić pod wskazany numer telefonu. A jak jest teraz? Wystarczy mieć smartfon, pobraną aplikację i po prostu sprawdzić za ile może przyjechać taksówka, w jakiej cenie, z jakim bagażnikiem, z jak dobrym kierowcą, itd. Co to powoduje? Otóż można o wiele łatwiej porównać jakość oferowanej usługi i ceny. Z perspektywy pasażera jest to bardzo ważne. Ale ważne jest też poczucie bezpieczeństwa, a to aplikacja oferuje: widać bowiem całą trasę przejazdu i o wiele trudniej jest paść ofiarą przekrętu. A nie ukrywajmy, każdy słyszał jakąś historię o nieuczciwym taksówkarzu, który przewiózł klienta okrężną trasą i zażądał na koniec zawyżonej opłaty za kurs. Pozytywnym efektem korzystania z nowoczesnych technologii jest więc regulowanie poziomu usługi: nieuczciwym jest coraz trudniej znaleźć swoje ofiary, gdyż wszystkie aspekty kursu taksówką są transparentne dla pasażera. To wielki plus. Istnieje szansa, że nawarstwiające się latami historie, podobne do wskazanej powyżej, przestaną mieć rację bytu i całe środowisko taksówkarzy na tym zyska.

iTaxi wystartowało około pięć lat temu, gdy dominował jeszcze wyżej opisany „stary porządek”. Aplikacja do zamawiania taksówek była kompletnym novum. Ale chwilę później sytuacja zaczęła się zmieniać i to na wielką skalę. Pierwszą, olbrzymią zmianę, zainicjował Uber, który wszedł na polski rynek ponad cztery lata temu. Potem dużym wydarzeniem był start Taxify, około dwóch lat temu. W tym czasie bardzo wzrosły oczekiwania pasażerów odnośnie jakości oraz niskiej ceny. Podczas gdy używanie aplikacji do zamawiania przejazdów stało się czymś normalnym, szukanie taksówki na postojach zaczęło wydawać się jakimś dziwactwem. Kto obecnie biegałby w nocy i szukał postoju, gdy wystarczy tapnąć w telefon, a samochód podjedzie dokładnie tam, gdzie się stoi.

Podsumowując: jest to wymagająca branża. Trzeba konkurować zarówno z tradycyjnymi firmami taksówkarskimi (które powoli odkrywają, że bez aplikacji nie podbiją już rynku), jak i z nielegalnymi przewoźnikami, oferującymi niższe ceny w nowoczesnej formie. Trzeba szukać złotego środka pomiędzy jak najniższą ceną dla pasażera a dobrym zarobkiem dla kierowcy. Bez pasażerów ten biznes nie ma sensu. Bez kierowców także. I kolejna rzecz: w samym środowisku taksówkarzy trzeba umieć znaleźć taką formę współpracy z kierowcami, by zarówno ci przyzwyczajeni do „starego porządku”, jak i ci śledzący nowinki technologiczne, chcieli współpracować.

W czym problem?

Gdy iTaxi startowało w 2013 roku, powstała zupełnie nowa i nowoczesna wtedy aplikacja dla kierowców. Dzięki niej możliwe było sprawdzanie, jakie kursy są dostępne (czyli jakie zamówienia złożyli pasażerowie) oraz zrealizowanie takiego kursu wraz z procesem płatności. W aplikacji były także dostępne podstawowe statystyki i widoczne wiadomości, które firma czasami wysyłała do swoich kierowców.

Po pięciu latach ta aplikacja stała się problemem. Napisana w technologii od dawna przestarzałej, obciążała dział IT nieustanną obsługą błędów. Naprawianie ich, po pierwsze, nie było wcale trywialne, a po drugie, często generowało problemy w innych jej punktach. Aplikacja została przygotowana parę lat wcześniej tak, by obsłużyć ówczesne zapotrzebowanie. Po upływie czasu stała się barierą w rozwoju, była nieskalowalna i odporna na nowoczesne rozwiązania. Zaczęła być hamulcem.

Potrzeba, czyli po co nam nowa aplikacja

Rozwiązaniem problemu aplikacji kierowcy okazało się… stworzenie jej zupełnie od zera. Zebraliśmy w iTaxi zespół, którego celem miało być przygotowanie nowej wersji:

• Małgorzata Jędryka,kierownik floty iTaxi, odpowiadała za wymagania biznesowe. To dzięki niej możliwe było stworzenie aplikacji tak, by zarówno była ona wartością dla firmy, jak i dla użytkowników końcowych, czyli kierowców.
• Katarzyna Małecka, dyrektor produktu i UX-owiec, odpowiadała za cały proces powstawania aplikacji oraz dbała o doświadczenie użytkowników i stworzenie użytecznej aplikacji.
• Anna Orłowska, senior android developer, odpowiadała za prace programistyczne oraz jakość tworzonego kodu. Dzięki niej nowa aplikacja jest prosta w utrzymaniu oraz skalowalna.
• Sylwia Okraska, senior tester, odpowiadała za cały proces testów. Zaimplementowała stosowne metody testowania oraz nadzorowała testy wewnętrzne i zewnętrzne. Odpowiadała też za agregację zgłoszeń tak, by zespół mógł skupić się na ważnych zadaniach, zamiast pracować nad wszystkim usterkami.

Zespół pracujący nad aplikacją był oczywiście większy, jednak udział tych czterech kobiet był kluczowy – decydowały one o wszystkich aspektach nowej aplikacji.

Proces, czyli jesteśmy agile

Faza formułowania potrzeb

Prace rozpoczęliśmy od zebrania wymagań biznesowych. Wybraliśmy kluczowych pięć kwestii, na które nowa aplikacja powinna odpowiadać:

1. Rosnący popyt i podaż – aplikacja powinna zachować stabilność w momencie dużej liczby kierowców logujących się do aplikacji oraz w przypadku dużej liczby zleceń;
2. Skala – w momencie pojawienia się nowych pomysłów w postaci partnerstw oraz specjalnych stref, jak chociażby lotniska czy kluby, aplikacja musi być gotowa na obsłużenie ruchu w sposób niestandardowy (pomysł na hiperlokalność);
3. Zaangażowanie – konieczne okazało się uwzględnienie w nowej aplikacji elementów grywalizacji;
4. Komunikacja z kierowcami – rozbudowanie możliwości tak, aby przekazywane informacje np. o promocjach czy dodatkowym zapotrzebowaniu na taksówki były przyjemne dla oka, ale też łatwe do odczytania;
5. Optymalizacja kosztów – poprzez zmniejszenie nakładu pracy we wszystkich działach iTaxi. Aplikacja ma pomóc zmniejszyć liczbę zadań utrzymaniowych, pochłaniających zasoby IT oraz ilość zapytań kierowanych przez kierowców do pracowników infolinii i działu floty.

Po sformułowaniu potrzeby biznesowej, iTaxi zbadało też potrzeby użytkowników końcowych. Na bazie spotkań z taksówkarzami, analizy grup kierowców w social mediach oraz przeprowadzonych ankiet, na czoło wysunęły się następujące wymagania:

• Transparentność – szczegółowy i klarowny sposób zaprezentowania finansów, historii kursów oraz statystyk i osiągnięć kierowcy;
• Użyteczność – wygoda podczas jazdy, osiągnięta poprzez takie przygotowanie aplikacji, by wszystkie niezbędne informacje były łatwe do odczytania, a akcje proste do wykonania (kliknięcia) w momencie, gdy kierowca jest w trasie. Kwestie użyteczności w przypadku aplikacji dla taksówkarzy są nierozłącznie związane z bezpieczeństwem na drodze;
• Personalizacja – dodanie zupełnie nowych funkcjonalności, dzięki którym każdy taksówkarz może dostosować aplikację pod swoje preferencje (ten aspekt jest w trakcie rozwoju).

Wymagania biznesowe i kierowców były walidowane przez cały czas trwania projektu – organizowaliśmy spotkania warsztatowe, na których zderzaliśmy wcześniej sformułowane potrzeby ze zmieniającą się sytuacją rynkową. Dzięki temu część funkcjonalności okazała się krytyczna – bez nich aplikacja nie mogłaby wystartować. Inne pozostały dodatkiem, którego premiera będzie mieć miejsce niedługo po starcie aplikacji.

Faza planowania

Zestaw funkcjonalności, zarówno kluczowych, jak i pobocznych, przygotowaliśmy w formie backlogu (pracujemy w Scrumie). Każde zadanie zostało opatrzone opisem. Wspólnie ustalaliśmy też specyfikację funkcjonalności. Uznaliśmy za istotne, aby każdy wiedział, z czego wynikają pewne decyzje, gdyż pomaga to zrozumieć lepiej produkt i zaangażować zespół w prace. Nasze zadania „wyceniliśmy” – w iTaxi ustaloną metodą szacowania złożoności jest wycena punktowa, potęgowa: 1, 2, 4, 8, 16, 32, 64, itd. Zadania większe, niż 32, uznawaliśmy za zbyt duże do realizacji i rozdzielaliśmy na mniejsze. Dzięki temu każdy dwutygodniowy sprint mógł pomieścić kilka zadań, większych i mniejszych, i kończył się gotowym kawałkiem aplikacji.

Mając wyceniony cały zakres w backlogu, dodaliśmy narzut około 20 procentowy. Przewidywaliśmy, że niektóre zadania mogą okazać się bardziej skomplikowane, niż estymowaliśmy. Mając tak przygotowaną całościową wycenę, mogliśmy popracować nad tzw. burndown – wykresem spalania punktów w czasie. Wykres ten pozwala oszacować przybliżony termin zakończenia prac oraz pomaga na bieżąco obserwować, czy prace idą w dobrym kierunku.

Burndown aplikacji kierowcy iTaxi – status prac w ostatnich sprintach. Widoczne jest, że nasze szacunki były bezpieczne, gdyż tempo pracy było lepsze, niż przewidywaliśmy. Widać także, kiedy zakres prac się zwiększył – podczas wewnętrznych testów odkryliśmy, że niektóre funkcjonalności wymagają rozwinięcia w większym stopniu, niż przewidywaliśmy na start aplikacji. Na wykresie widać skok w okolicach listopada, przez co termin udostępnienia aplikacji kierowcom się przesunął.

Faza UX

Samo przygotowanie opisów funkcjonalności to za mało, by stworzyć użyteczny produkt. Najlepszym sposobem, by wszyscy zainteresowani mieli pewność co do ostatecznego kształtu aplikacji, zanim napiszemy chociaż linijkę kodu, jest przygotowanie makiet i prototypów. Zamiana słów na schematy wyglądu aplikacji, to rozwiązanie, które w naszym przypadku pomogło nam osiągnąć sukces.

Kolejność prac była następująca:

• warsztaty (zbieranie wymagań biznesowych),
• badania (zbieranie wymagań użytkowników końcowych),
• przygotowanie ścieżki użytkownika i pierwszych makiet,
• warsztaty: biznesowe z flotą, organizacyjne z zespołem IT,
• przygotowanie kompletu makiet i pierwszy interaktywny prototyp,
• warsztaty (i tu: iteracyjnie, aż makiety i prototyp były finalne),
• przygotowanie grafik (na bazie makiet), interaktywny prototyp,
• warsztaty i badania (w tym: z kierowcami) – znowu iteracyjnie,
• projekty ekranów aplikacji.

Proces wygląda na skomplikowany, ale tak naprawdę wszystko potoczyło się sprawnie i szybko, jednocześnie oszczędzając nam nieporozumień. Zajrzenie do makiet zawsze rozwiązywało wątpliwości jak dana funkcjonalność ma działać. To pomagało też wprowadzać zmiany – znowu, zanim napisaliśmy jakikolwiek kod. Gdy doszliśmy w firmie do etapu tworzenia grafik, każdy znał już sposób działania poszczególnych elementów. Potem dopiero ustaliliśmy jak one będą wyglądać.

Przykłady (od lewej): makieta, początkowa wersja designu, finalna wersja designu. Dwie pierwsze zawierają dodatkową funkcjonalność, której start przełożyliśmy. Wersja z białym tłem wygrała – okazałą się bardziej czytelna w warunkach jazdy, co przetestowaliśmy, poruszając się po mieście samochodem!

Przykład – makieta i screen finalnego wyglądu aplikacji.

Tu warto wspomnieć, że poświęciliśmy czas na analizę trendów i konkurencji. Musieliśmy świadomie zdecydować, w którą stronę chcemy pójść z naszą aplikacją w kontekście doświadczenia użytkownika. Postanowiliśmy, że zdecydowanie nie chcemy iść w kierunku, w którym idzie np. Uber, wprowadzający drobnymi elementami formę presji na kierowcach (na przykład by pracowali dłużej, nie wylogowywali się z aplikacji, bo więcej zarobią, itd.). Uznaliśmy, że nasza aplikacja ma przede wszystkim nie zmuszać nikogo do pracy poprzez psychologiczne triki – bezpieczeństwo na drodze jest najważniejsze.

Trzeba też zaznaczyć fakt, że aplikacja została stworzona z uwzględnieniem wariantów urządzeń, z jakich korzystają kierowcy w trakcie jazdy (w tym: uchwytów i mocowań do szyby). Podczas prac zwracaliśmy uwagę na to, czy poszczególne elementy są wygodne w obsłudze i umożliwiają wykonywanie taksówkarzowi swojej pracy, przy zachowaniu bezpieczeństwa na drodze.

Przykład – screen z poprzedniej oraz z nowej aplikacji.

Faza developmentu

Aplikacja kierowcy postawiła przed nami pewne specyficzne wyzwania, których nie spotkamy w większości aplikacji mobilnych. Chodzi o to, że w aplikacji cały czas „dużo się dzieje”. Na bieżąco spływają zlecenia, pojawiają się przypomnienia i komunikaty. A nasza aplikacja musi być nieustannie „pewna swojego stanu”, zwłaszcza pozycji GPS i statusu w systemie iTaxi (wolny/zajęty). Jeśli którakolwiek z tych wielkości zawiedzie (np. mamy nieaktualną pozycję GPS), może to powodować szereg problemów, m.in. z zamówieniem taksówki. Trzeba też pamiętać, że taksówkarze, w porównaniu do pasażerów, dużo częściej są w ruchu: wjeżdżają do tuneli, na parkingi podziemne, krążą wokół wysokich budynków. Zakłóceń różnego rodzaju jest wiele i mogą one powodować utratę GPS lub internetu. Wyzwaniem wtedy jest znalezienie „złotego środka” pomiędzy alarmowaniem użytkownika o nieprawidłowościach a pomijaniem chwilowych problemów. Pewne wielkości dobieraliśmy eksperymentalnie, np. akceptujemy nieaktualną pozycję przez określoną liczbę sekund, ale jeśli trwa to dłużej, to uznajemy, że pozycja jest nieznana. Sprawdzaliśmy podczas testów, jaka wartość czasowa jest optymalna i dopiero wtedy wdrażaliśmy to rozwiązanie w aplikacji.

– Ze względu na złożoność, aplikacja powstawała zgodnie z tzw. wzorcem architektonicznym VIPER. Jest to wzorzec kojarzony częściej z aplikacjami dla iOS, ale równie dobrze sprawdza się w Androidzie. Jego zaletą jest duży podział odpowiedzialności poszczególnych komponentów aplikacji. Projekt jest więc łatwiej rozwijać i testować, a przez to szansa na popełnienie błędu jest mniejsza. VIPER pomaga też zachować jakość kodu w czasie, nawet jeżeli pracuje nad nim wielu programistów. Wzorzec może być dobrym wyborem dla złożonych projektów, dla których przewidujemy długi czas życia i rozwoju. W aplikacji wykorzystaliśmy też znane i nowoczesne frameworki, które ułatwiają development, wprowadzają pewną przejrzystość kodu i minimalizują ryzyko błędu. Wszystko to sprawia, że mamy stosunkowo niski próg wejścia nowego programisty do projektu, a sam projekt jest łatwiej utrzymywać i rozwijać – podsumowuje prace programistyczne Anna Orłowska, senior android developer.

Faza testów

Aplikacja została gruntownie przetestowana przez zespół testerów iTaxi. – Zastosowaliśmy podejście oparte na ryzyku – testy były nakierowane na obszary o największej możliwości wystąpienia nieprawidłowości oraz o największym priorytecie dla całego biznesu. Następnie zaś sprawdzane i poprawiane były zgłoszenia z obszarów UX, czy estetyki. Zorganizowaliśmy także grupę 60 testerów – kierowców, którzy sprawdzali działanie aplikacji i wygodę jej obsługi w różnych warunkach pogodowych na drodze, o różnych porach dnia i nocy, na różnych urządzeniach. Kierowcy mogli kontaktować się z nami na wiele sposobów – mogli porozmawiać z nami osobiście, zadzwonić na dedykowaną infolinię lub wysłać e-maila. Ta faza testów była o tyle trudna, że wymagała analitycznego podejścia do różnego rodzaju zgłaszanych uwag, problemów, a także subiektywnych opinii. Agregowanie zgłoszeń i wybieranie, które z nich przechodzą do backlogu, a które do dalszej obserwacji (np. pod względem rosnącej skali), wymagało dużego skupienia i zaangażowania zespołu. Warto zaznaczyć, że każde zgłoszenie przeanalizowaliśmy. Jeśli natomiast została podjęta decyzja o odrzuceniu danej zmiany w aplikacji (np. ze względów biznesowych), zespół wiedział, dlaczego tak się stało i że była to decyzja świadoma. Z ciekawych sytuacji warto wspomnieć, że testowanie aplikacji przy użyciu kilku urządzeń i w różnych punktach miasta budziło często zainteresowanie przechodniów, a nawet ochrony okolicznych obiektów. Całe szczęście, skończyło się tylko na czujnej obserwacji służb – opisuje Sylwia Okraska, senior tester w iTaxi.

Testy podzieliliśmy na fazy. Najpierw dwóch testerów gruntownie sprawdzało działanie aplikacji i zgłaszało nieprawidłowości. Dopiero po wdrożeniu poprawek zdecydowaliśmy się na udostępnienie aplikacji w wersji testowej naszym kierowcom. Było to dla nas ważne wydarzenie – kierowcy zaczęli używać aplikacji w realnych kursach. Ryzyko było duże, ale zminimalizowane zostało poprzez staranny dobór skali testów. Zaczęliśmy od 5 testerów i w ciągu jednego tygodnia stopniowo tę grupę zwiększyliśmy do ostatecznej liczby około 60.

Warto zaznaczyć, że problemy zgłoszone przez kierowców były sukcesywnie rozwiązywane przez zespół iTaxi, dzięki czemu aplikacja – można pokusić się o takie stwierdzenie – jest pracą zarówno zespołu iTaxi, jak i kierowców. To rzadki przykład sytuacji, w której użytkownik końcowy ma aż tak duży udział w powstawaniu aplikacji. Jest to potwierdzenie, że tak „się da” i warto tak podejść do projektu.

Przykład zmiany, która została zainicjowana przez testerów. Kierowcy, używając wersji testowej aplikacji w realnych kursach, zauważyli, że lista zleceń nie jest zbyt wygodna w obsłudze w warunkach jazdy. Przygotowaliśmy więc alternatywne wersje tego ekranu na bazie zgłoszonych problemów, z których dwie poddaliśmy głosowaniu kierowców. Wybrali jedną z nich i tę właśnie wdrożyliśmy bardzo szybko, jeszcze przed startem aplikacji. Dzięki temu kierowcy mogą wygodniej pracować.

Release aplikacji

Wydanie aplikacji do sklepu zaplanowaliśmy w dwóch fazach:

• faza Alfa – testowa,
• faza publiczna.

Dzięki wytężonej pracy podczas fazy Alfa przygotowaliśmy bardzo dobrą wersję do pierwszego wydania produkcyjnego, czyli dostępnego dla każdej osoby, która chciałaby aplikację pobrać ze Sklepu Google Play. Początkowo planowaliśmy wydanie produkcyjne w fazach co 10% (zaczynając od 5%). W ten sposób chcieliśmy wydawać aplikacją stopniowo i dojść do 100% w ciągu maksymalnie 2 tygodni, by mieć czas na ewentualne reagowanie na problemy. Dzięki pracom przy wersji Alfa, udało się zmniejszyć czas wydawania wersji produkcyjnej z planowanych dwóch tygodni do… dwóch dni!

Rozwój aplikacji

Pierwsze szacunki wskazywały, że stworzenie aplikacji zupełnie od zera zajmie nam około 9 miesięcy (dosyć symbolicznie). W trakcie prac pojawiło się jednak parę zmian. Doszły też zadania, które na sprint albo dwa wyłączały nasz zespół z prac nad tym projektem. W związku z tym aplikację mogliśmy uznać za gotową do przekazania kierowcom po około 12 miesiącach.
Pomimo tej zmiany udało się nam przygotować kilka funkcjonalności, których na start nie planowaliśmy. Aplikacja jest więc bogatsza. Obecnie planujemy podział prac w taki sposób, by przygotowywać nowe opcje co każdy sprint, dzieląc czas pomiędzy prace rozwojowe, a serwisowe.

Podsumowanie

Aplikacja kierowcy iTaxi jest dobrym przykładem procesu, w którym możliwe jest połączenie potrzeb biznesu z potrzebami użytkowników końcowych. Przebieg prac potwierdza też, że zastąpienie standardowej dokumentacji nowoczesnymi makietami oraz zwinne podejście do wytwarzania oprogramowania, zwiększają szanse na sukces.

– Najtrudniejsze, z mojej perspektywy, było pogodzenie ze sobą celów biznesowych, oczekiwań kierowców oraz możliwości. To niełatwa do wyważenia mikstura. Można się spodziewać, że nie każdemu będzie odpowiadać finalne rozwiązanie, ale trzeba do tego dążyć. Szczególnie zależało mi na tym, żeby aplikacja była dla kierowcy nie tylko bezosobowym narzędziem pracy, ale też swoistym pomocnikiem. Dlatego rozszerzyliśmy systemy powiadomień i alertów oraz statystyk o liczne podpowiedzi i wskazówki adekwatne do bieżących wyników pracy. Postawiliśmy na interakcję i współpracę użytkownika z aplikacją. Po wydaniu pierwszej wersji planujemy wdrożenie w kolejnych wersjach ciekawych modułów finansowych, grywalizacyjnych, społecznościowych, a nawet rozrywkowych. Wszystko po to, aby codzienna praca na aplikacji była nie tylko wygodniejsza, ale też bardziej angażująca i satysfakcjonująca – stwierdza Małgorzata Jędryka, Kierownik Floty w iTaxi.

Warto zaznaczyć, że kierowcy chcieli jak najszybciej porzucić poprzednią wersję apki na rzecz nowej i są ciągle zaangażowani w testy. Nie ustają one nawet po uruchomieniu aplikacji. Użytkownicy bardzo chętnie zgłaszają też swoje uwagi, a my mamy przez to (i dzięki temu) pełne ręce pracy!

Autorka tekstu: Katarzyna Małecka, UX designer, dyrektor produktu, iTaxi
Od 10 lat odpowiada za prowadzenie projektów IT, posiada praktyczne doświadczenie z zakresu UX: tworzenia logiki ścieżki użytkownika, prototypowania (lo-fi) oraz badań jakościowych, m.in. prowadzonych z wykorzystaniem eye trackera oraz EEG. Prywatnie: autorka bajek dla dzieci oraz właścicielka białego kota brytyjskiego o niespotykanym poziomie fajtłapowatości.

Zespół iTaxi w projekcie aplikacji dla kierowców:

• Anna Orłowska – senior android developer,
• Ewa Janik – junior tester,
• Gaweł Boguta – dyrektor IT,
• Małgorzata Jędryka – kierownik floty,
• Kamil Jagiełło – senior java developer,
• Katarzyna Małecka – UX designer, dyrektor produktu,
• Marcin Laskowski – senior android developer,
• Marek Kaleta – grafik,
• Martyn Szczepankowski – dyrektor floty,
• Piotr Rzeźniczak – IT architekt,
• Sylwia Okraska – senior tester.

Anna Orłowska, senior android developer, iTaxi
Programuje od ósmego roku życia, a zawodowo zajmuje się tym od ponad 13 lat. W tym czasie współtworzyła wiele projektów m.in z branży finansowej, ubezpieczeniowej, e-commerce i transportowej. Od 3 lat skupiona głównie na aplikacjach mobilnych. Prywatnie żona i mama dwójki dzieci. Uwielbia podróże i czekoladę. W przyszłości planuje otworzyć własną manufakturę tego przysmaku.

Małgorzata Jędryka, kierownik floty, iTaxi
Praca w start-upach daje jej dużą satysfakcję. Manager, od 5 lat zaangażowana w budowanie i rozwój ogólnopolskich spółek technologicznych związanych z branżą transportową. Lubi wyzwania i dobrą organizację pracy, perfekcjonistka. Pasjonatka gór i sztuki gotowania. Autorka artykułów o historii himalaizmu i szczęśliwa posiadaczka dwóch grubiutkich świnek morskich.

Sylwia Okraska, senior tester, iTaxi
Od 4 lat zajmuje się dbaniem o jakość produktów, głównie testowaniem. Posiada także praktyczne doświadczenie w zakresie likwidacji szkód podróżnych i rozpatrywaniu reklamacji. W wolnym czasie prowadzi zajęcia z języka hiszpańskiego, czyta hiszpańskie książki, rozwiązuje sudoku i szuka inspiracji na aranżację wnętrza swojego nowego domu. Uwielbia podróże w egzotyczne miejsca oraz psy, w szczególności rasy chow-chow.