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

Vážíme si důvěry našich partnerů a proto chceme být co nejtransparentnější. V tomto článku vám přiblíží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. Stojí za ním 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 shromažďuje 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á příslušnou čá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í funkce, nebo skutečnou chybou.

Analytici shromažďují 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 těch, které jsou již v řešení. 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 se jeho požadavek nachází.

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. Řeší 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 funkce, kterou klientovi vysvětlíme; nebo problém skutečně existuje, pak jej převezme projektový manažer, zaznamená jej do systému úkolů s prioritou a odpovědnou osobou 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 chod 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 analytiky. Každá změna se dotýká všech partnerů 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. 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ředví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 proto tyto 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 provozu 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 technické podpoře 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