Jak przebiega praca nad systemem FoodSoul: od pomysłu do rezultatu

Cenimy zaufanie naszych partnerów i dlatego chcemy być maksymalnie transparentni. W tym artykule opowiemy, jak zorganizowany jest zespół, jak pomysły zamieniają się w funkcjonalności, jak ustalamy priorytety i co dzieje się za kulisami, gdy coś idzie nie tak.

FoodSoul — to żywy system

FoodSoul to nie tylko aplikacja. Za nią stoi rozbudowana infrastruktura: CRM, przechowywanie i ochrona danych, szablony stron internetowych i aplikacji mobilnych oraz tysiące restauracji-partnerów, z których każda ma swoje potrzeby i scenariusze działania.

Nieustannie słuchamy: zbieramy pomysły od partnerów przez wsparcie techniczne, z bezpośrednich rozmów z klientami oraz od własnych analityków działu IT. Wszystko to trafia do backlogu — stale aktualizowanej listy zadań, na podstawie której powstaje mapa rozwoju produktu.

Jak zorganizowany jest zespół i struktura pracy

Nad FoodSoul pracuje kilka grup specjalistów, z których każda odpowiada za swój obszar i ma własną logikę współpracy z pozostałymi.

Wsparcie techniczne — to pierwsza linia kontaktu z partnerami. Przyjmuje zgłoszenia, analizuje istotę problemu i albo rozwiązuje go na miejscu, albo przekazuje dalej do specjalisty znającego odpowiedni fragment systemu.

Specjaliści drugiej linii — to inżynierowie, którzy dogłębnie znają konkretne moduły: integracje, aplikacje mobilne, CRM, płatności. To oni sprawdzają, czy zgłoszenie wynika ze specyfiki działania funkcji, czy jest rzeczywistym błędem.

Analitycy zbierają i porządkują sugestie partnerów, oceniają, na ile zmiana jest pożądana i jak wpłynie na innych klientów, zanim zadanie trafi do realizacji.

Deweloperzy i testerzy wdrażają zadania i sprawdzają je przed wydaniem — od drobnych poprawek po duże rozbudowy funkcjonalności.

Kierownicy projektów dbają o priorytety: monitorują backlog, rozdzielają zadania między zespoły i pilnują, by ważne sprawy nie ginęły wśród bieżących zadań.

Praca przebiega cyklicznie: zespół regularnie przegląda backlog, ocenia nowe zgłoszenia i sugestie, planuje najbliższe zadania i monitoruje status już realizowanych. Taki rytm pozwala nie tracić z oczu ani pilnych problemów, ani długofalowego rozwoju produktu, a jednocześnie zachować przewidywalność: partner zawsze może dowiedzieć się przez wsparcie techniczne, na jakim etapie jest jego zgłoszenie.

Jak ustalamy priorytety

Gdy pojawia się problem, działamy według jednego z poniższych scenariuszy.

Masowa awaria — błąd, z którym w ciągu dnia lub kilku godzin zetknęło się kilku klientów jednocześnie. To najwyższy priorytet: tester i deweloperzy przystępują do działania natychmiast.

Krytyczny błąd u jednego klienta — jeśli błąd bezpośrednio wpływa na przychody lub reputację partnera, priorytet jest równie wysoki. Kierujemy kluczowe zasoby i rozwiązujemy problem w krótkim czasie.

Standardowy błąd — zgłoszenie przyjęte przez wsparcie techniczne, które nie wygląda na katastrofę. Przejmuje je specjalista drugiej linii, dobrze znający system. Możliwe są dwa scenariusze: albo okazuje się, że to specyfika działania funkcji, której nie uwzględniono, wtedy klient otrzymuje wyjaśnienie; albo problem rzeczywiście istnieje, wtedy trafia do kierownika projektu, zostaje zapisany w systemie z priorytetem i odpowiedzialnym, i realizowany według kolejności. Specjalista wsparcia technicznego śledzi status i informuje klienta, gdy zadanie zostanie wykonane.

Drobny błąd — błąd, który nie wpływa na działanie systemu, ale wymaga poprawki: literówka, przesunięty element interfejsu, niewłaściwy kolor przycisku. Takie zadania realizujemy, gdy nie ma pilniejszych zgłoszeń z powyższych kategorii.

Sugestie — uważnie śledzimy, o co proszą partnerzy. Gdy ta sama prośba pojawia się od kilku klientów, jej priorytet rośnie i trafia do analizy. Każda zmiana dotyczy wszystkich partnerów, a nie tylko tego, kto ją zgłosił, dlatego przed wdrożeniem zbieramy opinie od różnych klientów, by ulepszenie dla jednych nie powodowało niedogodności dla innych. To dodatkowy krok, ale właśnie on sprawia, że ostateczne rozwiązanie jest bardziej przemyślane.

Dlaczego pojawiają się błędy

Tworzenie każdego złożonego produktu wiąże się z tym, że błędy są regularną częścią procesu, a nie wyjątkiem. Oto, z czego wynika ta złożoność.

System się rozwija. Im więcej funkcji, integracji i scenariuszy użycia, tym więcej punktów, w których różne części systemu współdziałają ze sobą. Zespół testuje najbardziej typowe scenariusze, ale objęcie wszystkich kombinacji z góry jest fizycznie niemożliwe nawet dla najbardziej doświadczonego zespołu.

Każdy partner korzysta z systemu na swój sposób. Tysiące lokali to tysiące unikalnych procesów roboczych. Zachowanie użytkowników w rzeczywistych warunkach jest zawsze bogatsze niż można przewidzieć w scenariuszach testowych i część odchyleń ujawnia się dopiero na żywych danych.

Jedna zmiana wpływa na inną. Gdy deweloper ulepsza jeden moduł, może to wpłynąć na powiązaną funkcjonalność. Im większy system, tym dłuższe łańcuchy zależności między jego częściami i tym uważniej trzeba sprawdzać każdą zmianę.

Środowisko stale się zmienia. Aktualizowane są przeglądarki, systemy operacyjne, zewnętrzne usługi, z którymi się integrujemy. To, co działało wczoraj, może zachowywać się inaczej po aktualizacji po stronie trzeciej firmy, dlatego monitorujemy takie zmiany, by szybko reagować.

Wymagania precyzują się w trakcie. Czasem funkcja jest zrealizowana dokładnie tak, jak zaplanowano, ale w praktyce okazuje się, że warto ją dopracować. Dzięki temu produkt staje się coraz lepszy z każdą iteracją.

Traktujemy to jako naturalną część rozwoju złożonego systemu i stale pracujemy nad tym, by był on coraz stabilniejszy, szybszy i wygodniejszy dla każdego partnera — dzięki głębszym testom, przejrzystej strukturze zespołu i stałej informacji zwrotnej od klientów.

Jeśli napotkasz problem lub chcesz podzielić się pomysłem, napisz do wsparcia technicznego FoodSoul. Każde zgłoszenie trafia do odpowiedniego specjalisty i nie ginie. Jesteśmy blisko!

Z poważaniem,

Project Manager FoodSoul