Sprzątanie mieszkań na pierwszy rzut oka nie wygląda jak interesujący temat. Chyba że masz 100 pracowników, setki zadowolonych klientów i chcesz przenieść swój biznes na kolejny level. To jest właśnie historia Strykfritta.
Jeśli mieszkasz w większym mieście jak np. Sztokholm prawdopodobnie nie przepadasz za sprzątaniem swojego domu czy mieszkania. W dzisiejszych czasach życie i praca dużo od nas wymagają i bardzo lubimy delegować takie zadania. Dlatego właśnie powstał Strykfrit.
Ale co jeśli już jesteś liderem w swojej branży na lokalnym rynku i chcesz pójść o krok dalej? Wtedy powinieneś zaprzyjaźnić się z technologią!
Kiedy Strykfrit skontaktował się z nami, wiedzieliśmy że biznes w stolicy Szwecji wychodzi im świetnie, a głównym celem stworzenia aplikacji było rozszerzenie działalności na inne miasta oraz zredukowanie kosztów zarządzania poprzez zautomatyzowanie rezerwacji i płatności.
Wiedzieliśmy, że Szwecja jest dość specyficznym rynkiem, a gęstość zaludnienia jest unikatowa – ~23% Szwedów mieszka w Sztokholmie. Musieliśmy wziąć to pod uwagę, ponieważ inne strategie biznesowe powinny być zastosowane w małych miastach, a inne w dużych.
Wszystkie te strategie i decyzje miały bezpośredni wpływ na produkt cyfrowy jaki budowaliśmy.
Product Discovery i Product Design
Najważniejszy jest użytkownik
Zaczęliśmy naszą przygodę od zrozumienia ścieżki użytkownika i profilu klienta. Zawsze ważne jest aby zrozumieć, kto będzie użytkownikiem końcowym produktu, który staramy się stworzyć. Często mamy ochotę pominąć ten krok i zacząć rozmowy o technologii, makietach i innych rzeczach.
Pamiętajcie proszę, że jeśli chcecie stworzyć aplikację dla ludzi z wielkich miast musicie najpierw zrozumieć ich zabiegane życie, zachowania, codzienną rutynę. Jeśli to osiągniesz, masz większe szanse stworzyć produkt, który sprosta ich oczekiwaniom.
Wizualizuj wszystko
Wizualizacja… nie bój się, nie będziemy tutaj bawić się w żadnych coachów. Chcemy tylko pokazać jak ważne jest przekształcenie pomysły w coś widocznego gołym okiem. Każdy z nas ma inne doświadczenia, inne nastawienie do życia i jeśli poprosisz kilka osób o narysowanie domu, dostaniesz kilka różniących się od siebie rysunków.
Większośc elemntów domu będzie podobna, ale zapewne będzie ktoś kto narysuje płot, ktoś inny narysuje koło domu psa… Finalnie każdy z tych domów będzie inny.
Dokładnie to samo dzieje się przy projektowaniu aplikacji. Dopóki nie zwizualizujemy interfejsu aplikacji, każdy będzie miał inną wizję. Dlatego używamy narzędzi takich jak Miro.com czy Moqups.com żeby przygotować proste szkice i makiety wizualizujące pomysł klienta.
To samo zrobiliśmy w tym projekcie. Kiedy poznaliśmy profile klientów, byliśmy gotowi na rozpisanie historyjek użytkowników dla 4 ról: gościa, klienta, pracownika i managera.
Opierając się na rolach i historyjkach użytkowników zaprojektowaliśmy wszystkie widoki aplikacji i mogliśmy łatwo uzyskać feedback od naszego klienta i wprowadzić poprawki na podstawie jego uwag.
Tworzenie aplikacji
W przeszłości zbudowaliśmy wiele aplikacji i wiedzieliśmy, że w tym projekcie najlepiej sprawdzi się podejście agile. Pozwalało nam ono na elastyczność i ulepszenia w designach podczas pracy w sposób przyrostowy i iteracyny
Do pracy nad projektem stworzyliśmy wielofunkcyjny zespół:
- Marcin jako Backend Developer
- Wojtek jako Frontend JS Developer
- Daniel jako Frontend Developer
- Sebastian jako Backend Developer
- Krzysztof jako Backend Developer
- Oskar jako UI/UX Designer
- Piotr jako Scrum Master
Projekt został podzielony na 8 tygodniowych sprintów.
Wyzwanie #1 – Dostępność pracowników i tworzenie grafików
Niezależnie czy jesteś wolnym ptakiem czy mistrzem planowania znasz wyzwanie jakim jest zarządzanie czasem. Może być to powodem frustracji w życiu prywatnym, a co dopiero kiedy zarządzasz 100 pracownikami w różnych lokalizacjach.
Rozwiązanie
Jeżeli twój pomysł obejmuje złożone moduły lub funkcje powinieneś zacząć od:
- Sprawdź czy jest już na rynku rozwiązanie, które spełnia twoje wymagania.
- Sprawdź czy możesz użyć tego oprogramowania, biblioteki czy API w twoim projekcie. Dla przykładu jeśli chcesz wykorzystać kalendarz warto przyjrzeć się Cronofy.com albo Google Calendar API. Oczywiście musisz sprawdzić czy rozwiązanie będzie dla ciebie odpowiednie. Zawsze są jakieś plusy i minusy korzystanie z gotowych rozwiązań. Rzadko kiedy można znaleźć coś co spełni wszystkie twoje wymagania bez dodatkowej pracy. Sprawdź to zarówno od strony biznesowej jak i technicznej.
- Jeśli nie jesteś pewien czy rozwiązanie jest odpowiednie dla twojego projektu możesz zbudować techniczny proof-of-concept. Twój zespół powinien być w stanie zbudować PoC w kilka dni żeby zwalidować twoje przypuszczenia. Nie oczekuj, że PoC będzie finalnym rozwiązaniem. W większości przypadków jest to po prostu test, który nie kosztuje cię dużo. Bazując na wynikach PoC powinieneś być w stanie zdecydować co dalej.
Dokładnie tak zrobiliśmy w tym projekcie. Planem było zintegrowanie obecnie używanego oprogramowania używanego przez firmę do zarządzania pracownikami (https://www.timewave.se/).
Na początku sprawdziliśmy dokumentację API i skontaktowaliśmy się z supportem TimeWave, żeby sprawdzić czy jest to najnowsza dokumentacja.
Dowiedzieliśmy się, że w niedługim czasie wyjdzie nowa wersja opisująca funkcjonalności, które nas interesowały. Ponieważ nigdy wcześniej nie pracowaliśmy z tym rozwiązaniem postanowiliśmy dowiedzieć się więcej i zbudować małe proof-of-concept, żeby sprawdzić czy wszystko będzie działać tak jak oczekujemy.
W tym wypadku wynik był negatywny – dowiedzieliśmy się, że nie możemy użyć TimeWave jako podstawy naszego modułu. API nie pozwalało nam na zmianę czasu zaplanowanych działań i nie zapowiadało się, żeby było to wprowadzone w najbliższej przyszłości.
Po tym teście sprawdziliśmy inne możliwości. Nie było na rynku narzędzia, które spełniałoby nasze wymagania. Jedyne co mogliśmy zrobić to stworzyć takie narzędzie.
Brzmi to jak proste rozwiązanie sprawy. Niestety tak nie jest. Firmy jak Google czy TimeWave pracowały latami nad swoimi kalendarzami jakie widzimy dzisiaj. Jeśli nie posiadamy siedmiocyfrowego budżetu musimy zdecydować, które z funkcjonalności dla klientów są najważniejsze i oprzeć się na gotowym rozwiązaniu, które je oferuje. Jeśli rozwiążemy ich problemy możemy się spodziewać, że zostaną naszymi lojalnymi, szczęśliwymi i płacącymi klientami.
Zrobiliśmy więc krok do tyłu żeby lepiej zrozumieć proces planowania wizyt, który miał być obsługiwany przez gotowy produkt. Najważniejszym etapem w branży technologicznej jest właśnie zrozumienie i zidentyfikowanie problemów jakie staramy się rozwiązać. Bez tego nie jest możliwe zbudowanie wartościowego produktu.
Kiedy zdefiniowaliśmy wymagania mogliśmy zacząć prace programistyczne. Po kilku iteracjach mieliśmy aplikację gotową na testy alpha.
Wyzwanie #2 – Faktury i płatności w Szwecji
Na rynku są setki dostawców płatności. Większość integracji jest bardzo prosta. Ale jeśli chcesz dodać bramki płatności do swojego projektu musisz przemyśleć jakie rozwiązanie będzie odpowiednie na rynku na jaki wychodzisz.
W wymaganiach projektu zawarliśmy dostarczenie sposobu opłacania faktur na szwedzkich klientów. Postanowiliśmy zrobić research na temat dostępnych opcji i zaplanować na jego podstawie kolejne kroki. Jeśli mielibyśmy szczęście i nie pojawiłyby się żadne niespodziewane problemy wtedy w 5 dni powinniśmy zakończyć research razem z PoC.
Dostawcami wartymi uwagi byli Klarna i Payson. Po szybkim PoC postanowiliśmy użyć rozwiązania firmy Payson dla szwedzkich klientów.
Wyzwanie #3 – Zjedz żabę. Priorytety
Jako główny inicjator prawdopodobnie masz swoją wizję i wiele wspaniałych pomysłów. Bardzo ważne jest mieć plan na swoją firmę na kolejne 5, 10, 15 lat.
Jednak niemożliwe jest zmienić swoją wizję w rezultaty w 1 dzień. Finalny rezultat zależy od tego jak dobry jesteś w dążeniu małymi kroczkami do celu. Nastawienie na sukces to coś, co pomoże osiągnąć ci twoje cele. Tak samo jak sukces twojego produktu.
“Duże rzeczy mają małe początki.”
Jeśli wiemy, że nie skończymy projektu w jeden dzień powinno być oczywiste, że musimy ustalić swoje priorytety. Z doświadczenia wiemy, że jest jedna z najważniejszych rzeczy w tworzeniu oprogramowania.
Doświadczony Product Owner, który jest w stanie decydować o priorytetach jest jak samuraj dzierżący miecz. Nieoceniony w każdym projekcie.
Product Owner po stronie Strykfritta nie był dostępny cały czas, więc rozpoczęcie prac nad nową funkcjonalnością było dla nas często problematyczne. Z tego powodu po jakimś czasie mniejsze funkcje były już ukończone, ale nasz produkt backlog był zapełniony tymi większymi i ważniejszymi.
Podczas omawiania dotychczasowych prac doszliśmy do sytuacji, gdzie rezultaty nie były satysfakcjonujące i projekt mógł okazać się porażką.
Postanowiliśmy zatrzymać proces developmentu i zweryfikować nasz backlog i jego priorytety. Jako GMI wierzymy, że w relacji z naszymi klientami najważniejsza jest transparentność, więc postanowiliśmy porozmawiać otwarcie i wspólnie znaleźć rozwiązanie.
Po zweryfikowaniu naszego backlogu już nie obawialiśmy “żaby”, którą mieliśmy do zjedzenia. Wiedzieliśmy, że po rozwiązaniu najważniejszych problemów możemy ruszać dalej z pozostałymi zadaniami.
Dlatego teraz zadajemy trudne i “niewygodne” pytania już od początku współpracy. Nie miejcie nam tego za złe 🙂
Technologie użyte w projekcie
- PHP Symfony
- Angular
- CSS / HTML
- Webpack
Narzędzia
Codzienna komunikacja odbywała się przy pomocy Google Meet i Slacka. Narzędziem do zarządzania taskami było Trello, które umożliwiło nam gładką i transparentną współpracę.
Rezultaty
W wyniku tych prac wypuściliśmy aplikację do umawiania wizyt dla firmy świadczącej usługi sprzątające w Szwecji. Wspieraliśmy naszego klienta od etapu koncepcyjnego do istniejącego oprogramowania online. Dowiedzieliśmy się wiele o klientach ze Szwecji i bardzo cieszymy się, że mogliśmy pracować nad projektem działającym na rynku skandynawskim.
Planujesz stworzenie oprogramowania do umawiania wizyt? Trafiłeś w dobre miejsce! Skontaktuj się z nami w sprawie wyceny projektu!
