Cum funcționează procesul de lucru asupra sistemului FoodSoul: de la idee la rezultat

Prețuim încrederea partenerilor noștri și de aceea dorim să fim cât mai transparenți. În acest articol vom povesti cum este organizată echipa, cum ideile se transformă în funcționalitate, cum stabilim prioritățile și ce se întâmplă în culise atunci când ceva nu merge conform planului.

FoodSoul — un sistem viu

FoodSoul nu este doar o aplicație. În spatele ei se află o infrastructură vastă: CRM, stocare și protecție a datelor, șabloane de site-uri și aplicații mobile și mii de restaurante partenere, fiecare cu propriile nevoi și scenarii de lucru.

Ascultăm constant: colectăm idei de la parteneri prin suportul tehnic, din comunicarea directă cu clienții și de la propriii analiști ai departamentului IT. Toate acestea se acumulează într-un backlog — o listă de sarcini permanent actualizată, pe baza căreia se formează foaia de parcurs pentru dezvoltarea produsului.

Cum este organizată echipa și structura de lucru

La FoodSoul lucrează mai multe grupuri de specialiști, fiecare având propriul domeniu de responsabilitate și propria logică de interacțiune cu celelalte.

Suportul tehnic — prima linie de contact cu partenerii. Primește solicitările, analizează esența problemei și fie o rezolvă pe loc, fie o transmite mai departe specialistului care cunoaște segmentul necesar al sistemului.

Specialiștii de linia a doua — sunt ingineri care cunosc în profunzime anumite module: integrări, aplicații mobile, CRM, plăți. Ei verifică dacă solicitarea reprezintă o particularitate a funcționalității sau o eroare reală.

Analiștii colectează și structurează dorințele partenerilor, evaluează cât de solicitată este schimbarea și cum va afecta alți clienți, înainte ca sarcina să ajungă în dezvoltare.

Dezvoltatorii și testatorii implementează sarcinile și le verifică înainte de lansare — de la mici corecții până la îmbunătățiri majore ale funcționalității.

Managerii de proiect țin prioritățile în prim-plan: monitorizează backlog-ul, distribuie sarcinile între echipe și se asigură că lucrurile importante nu se pierd printre sarcinile curente.

Munca este organizată ciclic: echipa revizuiește regulat backlog-ul, evaluează noile solicitări și dorințe, planifică sarcinile apropiate și urmărește statusul celor deja preluate. Acest ritm permite să nu se piardă din vedere nici problemele urgente, nici dezvoltarea pe termen lung a produsului, menținând totodată predictibilitatea: partenerul poate afla oricând prin suportul tehnic în ce stadiu se află solicitarea sa.

Cum stabilim prioritățile

Când apare o problemă, acționăm după unul dintre următoarele scenarii.

Defecțiune de masă — o eroare cu care, în decursul unei zile sau câtorva ore, se confruntă simultan mai mulți clienți. Aceasta are cea mai mare prioritate: testatorul și dezvoltatorii intervin imediat.

Bug critic la un singur client — dacă eroarea afectează direct veniturile sau reputația partenerului, prioritatea este la fel de mare. Alocăm resursele cheie și rezolvăm problema în cel mai scurt timp.

Bug standard — o solicitare preluată de suportul tehnic, care nu pare a fi o catastrofă. Este preluată de un specialist de linia a doua, care cunoaște bine sistemul. Sunt posibile două rezultate: fie se dovedește că este o particularitate a funcționalității care nu a fost luată în calcul, caz în care clientului i se explică soluția; fie problema există cu adevărat, caz în care ajunge la managerul de proiect, este înregistrată în sistemul de sarcini cu prioritate și responsabil și este implementată în ordinea stabilită. Specialistul de suport tehnic urmărește statusul și informează clientul când sarcina este finalizată.

Bug minor — o eroare care nu afectează funcționarea sistemului, dar necesită corectare: o greșeală de scriere, un element de interfață deplasat, culoarea greșită a unui buton. Astfel de sarcini sunt preluate când nu există solicitări mai prioritare din categoriile de mai sus.

Dorințe — urmărim cu atenție ce solicită partenerii. Când aceeași cerere vine de la mai mulți clienți, prioritatea crește și o analizăm. Orice schimbare îi afectează pe toți partenerii, nu doar pe cel care a solicitat-o, de aceea, înainte de implementare, colectăm feedback de la diverși clienți, pentru ca îmbunătățirea pentru unii să nu creeze neplăceri pentru alții. Acesta este un pas suplimentar, dar tocmai el face ca decizia finală să fie mai echilibrată.

De ce apar bug-uri

Dezvoltarea oricărui produs complex este astfel încât erorile sunt o parte regulată a procesului, nu o excepție. Iată din ce rezultă această complexitate.

Sistemul crește. Cu cât sunt mai multe funcții, integrări și scenarii de utilizare, cu atât sunt mai multe puncte unde diferite părți ale sistemului interacționează între ele. Echipa testează cele mai tipice scenarii, dar este fizic imposibil să acoperi dinainte toate combinațiile, chiar și pentru cea mai experimentată echipă.

Fiecare partener folosește sistemul în felul său. Mii de localuri înseamnă mii de procese de lucru unice. Comportamentul utilizatorilor în condiții reale este întotdeauna mai bogat decât se poate prevedea în scenariile de testare, iar unele abateri apar doar pe date reale.

O schimbare influențează alta. Când un dezvoltator îmbunătățește un modul, acest lucru poate afecta funcționalitatea conexă. Cu cât sistemul este mai mare, cu atât lanțurile de dependențe între părțile sale sunt mai lungi și cu atât trebuie verificate mai atent fiecare modificare.

Mediul se schimbă constant. Se actualizează browserele, sistemele de operare, serviciile terțe cu care suntem integrați. Ceea ce a funcționat ieri se poate comporta diferit după o actualizare din partea unei companii terțe, iar noi monitorizăm astfel de schimbări pentru a reacționa rapid.

Cerințele se clarifică pe parcurs. Uneori funcția este implementată exact așa cum a fost gândită, dar în utilizarea reală se dovedește că ideea trebuie îmbunătățită. Astfel, produsul devine mai precis cu fiecare iterație.

Considerăm acest lucru ca pe o parte firească a creșterii unui sistem complex și lucrăm constant pentru ca acesta să devină mai stabil, mai rapid și mai comod pentru fiecare partener — prin testare mai aprofundată, o structură clară a echipei și feedback constant de la clienți.

Dacă v-ați confruntat cu o problemă sau doriți să împărtășiți o idee, scrieți la suportul tehnic FoodSoul. Fiecare solicitare ajunge la specialistul potrivit și nu se pierde. Suntem alături de voi!

Cu respect,

Project Manager FoodSoul