Kuidas toimub töö FoodSoul süsteemiga: ideest tulemuseni

Hindame oma partnerite usaldust ja soovime seetõttu olla võimalikult läbipaistvad. Selles artiklis räägime, kuidas meeskond on üles ehitatud, kuidas ideed muutuvad funktsionaalsuseks, kuidas me seame prioriteete ja mis toimub kulisside taga, kui midagi läheb valesti.

FoodSoul — see on elav süsteem

FoodSoul ei ole lihtsalt rakendus. Selle taga on suur infrastruktuur: CRM, andmete säilitamine ja kaitse, veebilehtede ja mobiilirakenduste mallid ning tuhanded partnerrestoranid, millest igaühel on oma vajadused ja tööstsenaariumid.

Kuulame pidevalt: kogume ideid partneritelt tugiteenuse kaudu, otsesuhtlusest klientidega ning oma IT-osakonna analüütikutelt. Kõik see koondub backlog’i — pidevalt uuenevasse ülesannete nimekirja, mille põhjal kujuneb toote arenguteekaart.

Kuidas on meeskond ja tööstruktuur üles ehitatud

FoodSouli kallal töötab mitu spetsialistide gruppi, kellest igaühel on oma vastutusala ja loogika koostööks teistega.

Tugiteenus — esimene kontaktliin partneritega. See võtab vastu pöördumised, selgitab probleemi olemuse välja ja kas lahendab selle kohapeal või suunab edasi spetsialistile, kes tunneb vastavat süsteemi osa.

Teise liini spetsialistid — need on insenerid, kes tunnevad põhjalikult konkreetseid mooduleid: integratsioone, mobiilirakendusi, CRM-i, makseid. Just nemad kontrollivad, kas pöördumine on funktsionaalsuse eripära või tegelik viga.

Analüütikud koguvad ja struktureerivad partnerite soove, hindavad, kui vajalik muudatus on ja kuidas see mõjutab teisi kliente, enne kui ülesanne jõuab arendusse.

Arendajad ja testijad viivad ülesanded ellu ja kontrollivad neid enne väljalaset — alates väikestest parandustest kuni suurte funktsionaalsuse täiendusteni.

Projektijuhid hoiavad prioriteedid fookuses: jälgivad backlog’i, jagavad ülesandeid meeskondade vahel ja vastutavad selle eest, et oluline ei kaoks igapäevaste ülesannete hulka.

Töö on üles ehitatud tsükliliselt: meeskond vaatab regulaarselt backlog’i üle, hindab uusi pöördumisi ja soove, planeerib lähiaja ülesandeid ning jälgib juba töös olevate ülesannete staatust. Selline rütm võimaldab mitte kaotada silmist ei kiireloomulisi probleeme ega pikaajalist toote arendust ning säilitada ennustatavuse: partner saab alati tugiteenusest teada, mis etapis tema pöördumine on.

Kuidas me seame prioriteete

Kui tekib probleem, tegutseme ühe järgmise stsenaariumi järgi.

Massiline tõrge — viga, millega on päeva või mõne tunni jooksul samaaegselt kokku puutunud mitu klienti. See on kõrgeim prioriteet: testija ja arendajad asuvad kohe tööle.

Kriitiline viga ühel kliendil — kui viga mõjutab otseselt partneri käivet või mainet, on prioriteet sama kõrge. Paneme võtmeressursid tööle ja lahendame probleemi lühikese ajaga.

Tavaline viga — tugiteenuse poolt vastu võetud pöördumine, mis ei tundu katastroofina. Selle võtab käsile teise liini spetsialist, kes tunneb süsteemi hästi. Võimalikud kaks tulemust: kas selgub, et see on funktsionaalsuse eripära, mida ei arvestatud, siis selgitatakse kliendile lahendus; või probleem on tõesti olemas, siis jõuab see projektijuhini, fikseeritakse ülesannete süsteemis koos prioriteedi ja vastutajaga ning viiakse ellu järjekorras. Tugiteenuse spetsialist jälgib staatust ja annab kliendile teada, kui ülesanne on täidetud.

Väike viga — viga, mis ei mõjuta süsteemi tööd, kuid vajab parandamist: kirjaviga, nihkunud liideselement, vale nupu värv. Sellised ülesanded võetakse töösse, kui kõrgema prioriteediga pöördumisi pole.

Soovid — jälgime hoolikalt, mida partnerid soovivad. Kui sama soov tuleb mitmelt kliendilt, kasvab selle prioriteet ja võtame selle analüüsi alla. Iga muudatus mõjutab kõiki partnereid korraga, mitte ainult seda, kes soovi esitas, seetõttu kogume enne teostust tagasisidet erinevatelt klientidelt, et ühe jaoks tehtud parandus ei tekitaks ebamugavusi teistele. See on lisasamm, kuid just see muudab lõpliku otsuse läbimõeldumaks.

Miks tekivad vead

Iga keeruka toote arendus on üles ehitatud nii, et vead on protsessi regulaarne osa, mitte erand. Siin on, millest see keerukus koosneb.

Süsteem kasvab. Mida rohkem on funktsioone, integratsioone ja kasutusstsenaariume, seda rohkem on punkte, kus süsteemi erinevad osad omavahel suhtlevad. Meeskond testib kõige tüüpilisemaid stsenaariume, kuid kõiki kombinatsioone pole füüsiliselt võimalik ette näha isegi kõige kogenumal meeskonnal.

Iga partner kasutab süsteemi omamoodi. Tuhanded asutused — see tähendab tuhandeid unikaalseid tööprotsesse. Kasutajate käitumine pärisolukorras on alati rikkalikum, kui teststsenaariumides ette näha saab, ning osa kõrvalekalletest ilmneb alles pärisandmetega töötades.

Üks muudatus mõjutab teist. Kui arendaja täiustab üht moodulit, võib see mõjutada ka seotud funktsionaalsust. Mida suurem süsteem, seda pikemad on sõltuvusahelad selle osade vahel ja seda hoolikamalt tuleb iga muudatust kontrollida.

Keskkond muutub pidevalt. Brauserid, operatsioonisüsteemid, kolmandate osapoolte teenused, millega oleme integreeritud, uuenevad. See, mis eile töötas, võib pärast kolmanda ettevõtte uuendust käituda teisiti, ning jälgime selliseid muudatusi, et kiiresti reageerida.

Nõuded täpsustuvad protsessi käigus. Mõnikord on funktsioon teostatud täpselt nii, nagu oli mõeldud, kuid päris kasutuses selgub, et ideed tuleks täiendada. Nii muutub toode iga iteratsiooniga täpsemaks.

Võtame seda kui keeruka süsteemi kasvu loomulikku osa ja töötame pidevalt selle nimel, et see muutuks iga partneri jaoks stabiilsemaks, kiiremaks ja mugavamaks — tänu põhjalikumale testimisele, selgele meeskonnastruktuurile ja pidevale tagasisidele klientidelt.

Kui teil tekib probleem või soovite jagada ideed, kirjutage tugiteenusele FoodSoul. Iga pöördumine jõuab õige spetsialistini ega lähe kaduma. Oleme teie kõrval!

Lugupidamisega,

FoodSoul projektijuht