Jak probíhá práce na systému FoodSoul: od nápadu k výsledku

Oceňujeme důvěru našich partnerů a proto chceme být co nejtransparentnější. V tomto článku vám povíme, jak je tým organizován, jak se nápady mění ve funkce, jak stanovujeme priority a co se děje v zákulisí, když se něco pokazí.

FoodSoul — to je živý systém

FoodSoul není jen aplikace. Za ní stojí rozsáhlá infrastruktura: CRM, ukládání a ochrana dat, šablony webových stránek a mobilních aplikací a tisíce partnerských restaurací, z nichž každá má své potřeby a pracovní scénáře.

Neustále nasloucháme: sbíráme nápady od partnerů prostřednictvím technické podpory, z přímé komunikace se zákazníky i od vlastních analytiků IT oddělení. Vše se kumuluje do backlogu — neustále aktualizovaného seznamu úkolů, na jehož základě vzniká roadmapa rozvoje produktu.

Jak je tým a práce organizována

Na FoodSoul pracuje několik skupin specialistů a každá z nich má svůj úsek odpovědnosti a vlastní logiku spolupráce s ostatními.

Technická podpora — první linie kontaktu s partnery. Přijímá požadavky, zjišťuje podstatu problému a buď jej řeší na místě, nebo předává dál specialistovi, který zná potřebnou část systému.

Specialisté druhé linie — to jsou inženýři, kteří se detailně vyznají v konkrétních modulech: integracích, mobilních aplikacích, CRM, platbách. Právě oni ověřují, zda je požadavek zvláštností fungování systému, nebo skutečnou chybou.

Analytici sbírají a strukturalizují přání partnerů, hodnotí, jak je změna žádaná a jak ovlivní ostatní klienty, než se úkol dostane do vývoje.

Vývojáři a testeři realizují úkoly a ověřují je před vydáním — od drobných úprav po rozsáhlé rozšíření funkcionality.

Projektoví manažeři drží v centru pozornosti priority: sledují backlog, rozdělují úkoly mezi týmy a dbají na to, aby důležité věci nezapadly mezi běžnými úkoly.

Práce je organizována cyklicky: tým pravidelně reviduje backlog, hodnotí nové požadavky a přání, plánuje nejbližší úkoly a sleduje stav již rozpracovaných. Tento rytmus umožňuje neztratit ze zřetele ani urgentní problémy, ani dlouhodobý rozvoj produktu a zároveň zachovat předvídatelnost: partner se vždy může přes technickou podporu dozvědět, v jaké fázi je jeho požadavek.

Jak stanovujeme priority

Když nastane problém, postupujeme podle jednoho ze scénářů.

Hromadný výpadek — chyba, se kterou se během dne nebo několika hodin setkalo více klientů současně. To je nejvyšší priorita: tester a vývojáři se zapojují okamžitě.

Kritická chyba u jednoho klienta — pokud chyba přímo ovlivňuje tržby nebo reputaci partnera, priorita je stejně vysoká. Nasazujeme klíčové zdroje a problém řešíme v krátkém čase.

Standardní chyba — požadavek přijatý technickou podporou, který nevypadá jako katastrofa. Zpracovává jej specialista druhé linie, který systém dobře zná. Jsou možné dva výsledky: buď se ukáže, že jde o zvláštnost fungování, kterou nebylo zohledněno, pak je klientovi vysvětleno řešení; nebo problém skutečně existuje, pak se dostává k projektovému manažerovi, je zaznamenán v systému úkolů s prioritou a odpovědným a realizuje se podle pořadí. Specialista technické podpory sleduje stav a informuje klienta, když je úkol splněn.

Menší chyba — chyba, která neovlivňuje fungování systému, ale vyžaduje opravu: překlep, posunutý prvek rozhraní, nesprávná barva tlačítka. Takové úkoly se řeší, když nejsou naléhavější požadavky z výše uvedených bodů.

Přání — pečlivě sledujeme, co si partneři přejí. Když stejný požadavek přijde od více klientů, priorita roste a zařazujeme jej do analýzy. Každá změna ovlivňuje všechny partnery najednou, nejen toho, kdo o ni požádal, proto před realizací sbíráme zpětnou vazbu od různých klientů, aby zlepšení pro jedny nezpůsobilo nepříjemnosti jiným. Je to další krok, ale právě ten činí konečné rozhodnutí promyšlenějším.

Proč vznikají chyby

Vývoj jakéhokoliv složitého produktu je nastaven tak, že chyby jsou pravidelnou součástí procesu, nikoliv výjimkou. Zde je, z čeho tato složitost pramení.

Systém roste. Čím více funkcí, integrací a scénářů použití, tím více bodů, kde různé části systému spolupracují. Tým testuje nejběžnější scénáře, ale zcela pokrýt všechny kombinace předem není fyzicky možné ani pro ten nejzkušenější tým.

Každý partner používá systém po svém. Tisíce podniků znamenají tisíce unikátních pracovních procesů. Chování uživatelů v reálných podmínkách je vždy bohatší, než lze předpokládat v testovacích scénářích, a některé odchylky se projeví až na živých datech.

Jedna změna ovlivňuje druhou. Když vývojář vylepší jeden modul, může to zasáhnout související funkce. Čím větší je systém, tím delší jsou řetězce závislostí mezi jeho částmi a tím pečlivěji je třeba každou změnu ověřovat.

Prostředí se neustále mění. Aktualizují se prohlížeče, operační systémy, externí služby, se kterými jsme integrováni. To, co včera fungovalo, se může po aktualizaci na straně třetí společnosti chovat jinak, a takové změny sledujeme, abychom mohli rychle reagovat.

Požadavky se upřesňují v průběhu procesu. Někdy je funkce realizována přesně tak, jak byla zamýšlena, ale v reálném použití se ukáže, že je třeba ji upravit. Tak se produkt s každou iterací zpřesňuje.

Považujeme to za normální součást růstu složitého systému a neustále pracujeme na tom, aby byl stabilnější, rychlejší a pohodlnější pro každého partnera — díky hlubšímu testování, jasné struktuře týmu a stálé zpětné vazbě od klientů.

Pokud jste narazili na problém nebo se chcete podělit o nápad, napište do technické podpory FoodSoul. Každý požadavek se dostane ke správnému specialistovi a neztratí se. Jsme tu pro vás!

S pozdravem,

Project Manager FoodSoul