Gera techninė užduotis nėra ilgas pageidavimų sąrašas. Tai susitarimas, kaip būsima internetinė parduotuvė aptarnaus pirkėją, kaip joje dirbs komanda ir kaip duomenys judės tarp katalogo, apskaitos, sandėlio, mokėjimų bei pristatymo sistemų.
Trumpai, ką išsinešti
Prieš prašant kainos verta aprašyti ne puslapių skaičių, o verslo taisykles. Kūrėjas turi suprasti, iš kur atkeliauja prekės ir kainos, kaip pirkėjas randa produktą, kokios integracijos būtinos ir pagal ką bus priimamas atliktas darbas.
- Atskirkite pirmam paleidimui būtinas funkcijas nuo vėlesnių idėjų.
- Nurodykite pagrindinį kiekvieno duomens šaltinį ir jo atnaujinimo dažnį.
- Kiekvienai svarbiai funkcijai aprašykite konkretų naudotojo scenarijų ir priėmimo kriterijų.
01
Kodėl techninė užduotis lemia projekto kainą ir terminą
Kai į užklausą įrašoma tik „reikia modernios internetinės parduotuvės“, skirtingi kūrėjai skaičiuoja visiškai skirtingus sprendimus. Vienas numato standartinį šabloną, kitas – individualų dizainą, trečias į kainą įtraukia duomenų importą ir integracijas. Pasiūlymų neįmanoma objektyviai palyginti, nes skiriasi ne tik kaina, bet ir pati apimtis.
Techninė užduotis sumažina šią nežinomybę. Ji padeda iš anksto pamatyti, kur pakanka standartinės PrestaShop funkcijos, kur reikalingas modulis, o kur teks programuoti individualią verslo taisyklę. Tai svarbu ne vien biudžetui. Aiškiai aprašyta apimtis leidžia sudaryti etapų planą, paskirti atsakomybes ir susitarti, ką reiškia „darbas baigtas“.
Dokumentas neturi būti parašytas programuotojų kalba. Vertingiausia informacija dažniausiai ateina iš pardavimų, sandėlio, klientų aptarnavimo ir buhalterijos komandos. Jie žino išimtis, kurios demonstracinėje parduotuvėje nematomos, tačiau kasdien sukuria daugiausia rankinio darbo.
02
Pradėkite nuo verslo tikslo ir pirkėjų scenarijų
Pirmasis techninės užduoties skyrius turėtų atsakyti, kodėl projektas apskritai kuriamas. Ar nauja parduotuvė turi pakeisti pasenusią sistemą, sumažinti užsakymų administravimą, atverti B2B kanalą, pradėti prekybą užsienyje, ar padidinti organinį matomumą? Skirtingas tikslas keičia prioritetus.
Toliau aprašykite pagrindinius pirkėjų tipus. Naujas mažmeninis klientas, nuolatinis didmeninis partneris ir vadybininkas, užsakantis kliento vardu, turi skirtingas teises bei poreikius. Verta užrašyti 3–5 realius scenarijus: nuo įėjimo į svetainę iki apmokėjimo, užklausos arba pakartotinio užsakymo.
Scenarijus turi būti konkretus. Vietoje „patogūs filtrai“ rašykite, pagal kokius parametrus žmogus rinksis, ar galima pasirinkti kelias reikšmes, kaip elgsis filtras neradęs rezultatų ir ar pasirinktus parametrus galima perduoti nuoroda. Toks aprašymas iš karto parodo ir UX, ir duomenų reikalavimus.
03
Katalogas: kategorijos, variantai ir produktų duomenys
Katalogas yra būsimos sistemos pamatas. Techninėje užduotyje nurodykite apytikslį prekių, kategorijų, gamintojų ir kalbų skaičių. Paaiškinkite, ar prekės turi dydžių, spalvų, komplektacijų, techninių parametrų, priedų arba suderinamumo ryšių. Svarbu žinoti, kurie laukai bus naudojami filtruose ir palyginime.
Atskiras klausimas – duomenų šaltinis. Jei informaciją siunčia ERP, tiekėjo XML ar PIM sistema, reikia pavyzdinio failo arba API dokumentacijos. Sutarkite, kas yra pagrindinis pavadinimo, kainos, likučio, aprašymo ir nuotraukos šaltinis. Kai tą patį lauką gali keisti dvi sistemos, anksčiau ar vėliau viena perrašo kitos informaciją.
Migracijos atveju aprašykite, ką būtina perkelti iš senos parduotuvės: produktus, klientus, užsakymų istoriją, nuolaidų kodus, straipsnius, SEO laukus ir senus URL. Reikia ne tik perkelti duomenis, bet ir patikrinti jų kokybę. Pasikartojančios kategorijos, tušti atributai ar skirtingai užrašyti gamintojai naujoje sistemoje tampa brangesne problema.
04
Kainodara, likučiai, mokėjimai ir pristatymas
Internetinės parduotuvės funkcionalumą stipriai keičia kainodaros taisyklės. Nurodykite, ar kainos vienodos visiems, ar priklauso nuo klientų grupės, kiekio, sutarties, rinkos arba valiutos. Aprašykite akcijų prioritetus: kas nutinka, kai produktui tuo pačiu metu galioja kategorijos nuolaida, kuponas ir individuali kliento kaina.
Likučiams svarbu ne vien parodyti skaičių. Reikia sutarti, ar leidžiami išankstiniai užsakymai, rezervacija krepšelyje, keli sandėliai ir skirtingi pristatymo terminai. Jei likutis gaunamas iš išorinės sistemos, techninėje užduotyje turi atsirasti atnaujinimo dažnis ir elgesys nutrūkus ryšiui.
Mokėjimų ir pristatymo dalyje išvardykite realiai naudojamus tiekėjus, šalis, svorio arba kainos taisykles, nemokamo pristatymo ribas, atsiėmimo vietas ir grąžinimo procesą. Vien „integruoti kurjerį“ nepakanka: siuntos etiketė, sekimo numeris, kelių pakuočių užsakymas ir būsenų grąžinimas yra atskiri darbai.
05
Integracijos: nupieškite duomenų kelią
Prie kiekvienos integracijos nurodykite siunčiamus laukus, kryptį ir dažnį. Pavyzdžiui, produktai ir likučiai keliauja iš apskaitos į parduotuvę kas penkiolika minučių, o patvirtintas užsakymas į apskaitą perduodamas iš karto. Sąskaitos numeris ir siuntos kodas grįžta atgal į parduotuvę bei kliento laišką.
Būtina aprašyti klaidas. Kas nutinka, jei užsakymas apmokėtas, bet ERP jo nepriėmė? Ar komanda gauna pranešimą, ar sistema bando pakartoti, kur matomas nepavykęs įrašas? Patikima integracija turi ne tik laimingą scenarijų, bet ir aiškią incidento būseną.
Jei API dokumentacijos dar nėra, į užduotį įrašykite atsakingą tiekėją ir techninio suderinimo etapą. Kūrimo grafikas negali remtis prielaida, kad trečiosios šalies sistema tikrai turi visus reikalingus metodus.
06
UX, turinys ir mobilus pirkimo kelias
Dizaino reikalavimai turi remtis turiniu. Paruoškite logotipą, spalvų taisykles, šriftus, produktų nuotraukų pavyzdžius ir svarbiausių kategorijų tekstus. Jei turinys bus kuriamas projekto metu, nurodykite, kas jį rengia, tvirtina ir sukelia.
Techninėje užduotyje pažymėkite svarbiausius šablonus: pagrindinį puslapį, kategoriją, paiešką, produkto puslapį, krepšelį, atsiskaitymą, kliento paskyrą ir turinio puslapį. Kiekvienam užrašykite pagrindinį veiksmą. Taip dizainas vertinamas pagal tai, ar padeda atlikti užduotį, o ne vien pagal asmeninį skonį.
Mobilus scenarijus nėra sumažinta kompiuterio versija. Reikia patikrinti filtrų atidarymą, variantų pasirinkimą, lentelių skaitymą, adreso įvedimą, mokėjimo grįžimą ir klaidų pranešimus mažame ekrane. Jei didžioji dalis srauto ateina telefonu, šis scenarijus turi būti projektuojamas pirmiausia.
07
SEO, analitika ir migracija turi būti apimtyje nuo pradžių
Jeigu organinis srautas svarbus, techninis SEO negali likti paskutinei savaitei. Užduotyje numatykite URL struktūrą, indeksuojamus filtrus, canonical taisykles, meta laukus, struktūrinius duomenis, XML sitemap, robots valdymą ir vidinių nuorodų logiką.
Keičiant veikiančią parduotuvę būtinas senų ir naujų URL žemėlapis. Kiekvienas vertingas senas adresas turi gauti tikslinį 301 peradresavimą, o ne būti siunčiamas į pagrindinį puslapį. Prieš paleidimą užfiksuokite indeksuojamus puslapius, organinį srautą ir svarbiausias pozicijas, kad po migracijos būtų ką palyginti.
Analitikoje iš anksto susitarkite dėl matuojamų įvykių: produkto peržiūra, pridėjimas į krepšelį, atsiskaitymo pradžia, pirkimas, paieška be rezultatų, formos pateikimas ir B2B užklausa. Be šių duomenų po paleidimo bus sunku atskirti techninę problemą nuo silpno pasiūlymo.
08
Priėmimo kriterijai, testavimas ir priežiūra
Kiekviena svarbi funkcija turi turėti patikrinamą rezultatą. Pavyzdžiui: „prisijungęs B2B klientas mato savo kainoraštį, o neprisijungęs jo nemato“, „apmokėtas užsakymas per dvi minutes perduodamas į ERP“, „nutrūkus perdavimui administratorius gauna pranešimą“. Tokius kriterijus galima testuoti ir priimti.
Numatykite, kas testuoja produktų duomenis, mokėjimus, siuntas, mokesčius, laiškus ir mobiliąją versiją. Reikalingi bandomieji vartotojai, mokėjimų aplinka ir realistiškas produktų rinkinys. Vien kūrėjo patikrinimo nepakanka, nes tik jūsų komanda žino visas kasdienes išimtis.
Galiausiai susitarkite dėl garantijos, atnaujinimų, atsarginių kopijų, stebėjimo ir reakcijos į incidentus. Profesionalus internetinių parduotuvių kūrimas apima ne tik paleidimą, bet ir aiškų sistemos perdavimą žmonėms, kurie ją valdys.
Kontrolinis sąrašas
18 klausimų, kuriuos įrašykite į techninę užduotį
- Koks pagrindinis projekto tikslas ir kaip matuosime rezultatą?
- Kas yra pagrindiniai pirkėjų tipai ir kuo skiriasi jų keliai?
- Kiek bus produktų, kategorijų, kalbų ir rinkų?
- Kokie produkto variantai, atributai ir filtrai būtini?
- Iš kurios sistemos atkeliauja produktai, kainos ir likučiai?
- Kokios kainodaros, akcijų ir klientų grupių taisyklės galioja?
- Kokie mokėjimo ir pristatymo būdai bus naudojami?
- Kokie duomenys turi keliauti į apskaitą, ERP ar sandėlį?
- Kaip sistema elgsis nutrūkus integracijai?
- Kokius duomenis ir URL perkeliame iš senos parduotuvės?
- Kokie puslapiai ir filtrai turi būti indeksuojami?
- Kas rengia produktų nuotraukas, aprašymus ir vertimus?
- Kokie veiksmai bus matuojami analitikoje?
- Kokie vaidmenys ir teisės reikalingi administravime?
- Kas atliks priėmimo testus ir pagal kokius kriterijus?
- Kaip bus vykdomos atsarginės kopijos ir saugumo atnaujinimai?
- Kokia garantija ir reakcijos laikas po paleidimo?
- Kurios funkcijos būtinos pirmajam etapui, o kurios gali palaukti?
DUK
Dažniausi klausimai
Ar techninę užduotį turi parengti pats užsakovas?
Ne. Užsakovas geriausiai aprašo verslo procesus ir išimtis, o techninis partneris padeda juos paversti sistemos reikalavimais, duomenų žemėlapiu ir priėmimo kriterijais.
Kokio ilgio turi būti internetinės parduotuvės techninė užduotis?
Svarbu ne puslapių skaičius, o aiškumas. Mažai parduotuvei gali pakakti kelių tikslių puslapių ir schemų, o integruotai B2B sistemai reikės išsamesnio dokumento bei API priedų.
Ar galima pradėti kūrimą neaprašius visų ateities funkcijų?
Taip. Būtina aiškiai aprašyti pirmą etapą ir žinomas plėtros kryptis. Taip architektūra neblokuos augimo, bet biudžetas nebus eikvojamas dar nepatikrintoms idėjoms.
Prieš prašant kainos verta aprašyti ne puslapių skaičių, o verslo taisykles. Kūrėjas turi suprasti, iš kur atkeliauja prekės ir kainos, kaip pirkėjas randa produktą, kokios integracijos būtinos ir pagal ką bus priimamas atliktas darbas.
Aiški internetinės parduotuvės techninė užduotis leidžia gauti palyginamus pasiūlymus, sumažina ginčų riziką ir padeda kūrimą vertinti kaip verslo projektą. Jei tokio dokumento dar neturite, pradėkite nuo 18 klausimų ir vieno realaus pirkėjo kelio.