Kuidas e-poodi luua: mida projekt tegelikult sisaldab

E-poe loomine ei ole ainult kujundusmalli valimine. Uurige, kuidas valmistada ette kataloog, makse- ja tarnekord ning taganemise protsess, ja mida kontrollida enne käivitamist.

E-pood ei ole valmis hetkel, mil seal saab avada tootelehe ja panna kauba ostukorvi, vaid siis, kui ostja näeb õiget hinda, valib tegelikult saadaoleva variandi, maksab ja saab arusaadava kinnituse, müüja aga suudab tellimuse täita ja vajaduse korral kauba tagasi võtta. Kujundus on projekti nähtavaim osa, kuid see ei otsusta, kas esimene tellimus lõpeb tarnega.

Seepärast tuleb küsimus „kuidas e-poodi luua“ kõigepealt täpsustada: milline müügiprotsess peab toimuma ilma improviseerimata? Vastus algab ühest kaubast ja ühest täielikust tellimusest, milles on selge andmeallikas, jäägi broneerimine, makse tulemus, saadetise loomine ja toimimine taganemise korral, ning iga vastamata küsimus muutub hiljem töömahuks või käsitsi tehtavaks sammuks: nimetage vastutaja, täitmisaeg ja piir, millest alates käsitsi kord enam ei kõlba, muidu toetub tehniliselt valmis pood edasi suulisele kokkuleppele ja inimese mälule.

Selles artiklis on tähelepanu projekti ettevalmistusel ja vastuvõtul, mitte platvormide hinna võrdlusel; enne arendust ja käivitamist peate ette valmistama sisendandmed, eristama poe funktsioonid ettevõtte protsessist ja võtma töö vastu päris testtellimuse, mitte ekraanipildi järgi. Selline lähenemine sobib nii siis, kui ehitate poe ise, kui ka siis, kui usaldate töö arendajale.

Alustage ühest tellimusest, mitte platvormi nimest

Enne tehnoloogia valimist kirjeldage ühte tavalist tellimust kauba leidmisest tarneni, kasutades konkreetset kaupa, hinda, makseviisi ja aadressi, ning pange kirja, mida teeb igas etapis ostja, pood ja teie töötaja. Kui vastus on „selle ajame käsitsi korda“, nimetage ka vastutav inimene, toiminguks kuluv aeg ja tellimuste arv, mille juures selline kord enam ei ole praktiline.

See kirjeldus näitab kiiresti, kas vajate standardset poodi või individuaalsemat tellimuste käsitlemist, sest kataloog, üks hinnoloogika, tavaline kaardimakse ja pakiautomaat ei nõua tavaliselt keerukat süsteemi, hinnad kliendilepingu järgi, saadavus mitmes laos või kinnitamine teises süsteemis muudavad mahtu aga juba enne kujundust. Funktsioonide loendis võivad kaks projekti paista sarnased, protsessi kirjelduses muutub vahe ühemõtteliseks, ja sellest saab vastuvõtukriteerium, mida projekti lõpus saab kontrollida ilma oletusteta selle kohta, mida tarnija silmas pidas.

Platvorm tuleb valida selle protsessi ja eeldatava kasvu järgi: WooCommerce võib olla ratsionaalne lahendus standardseks müügiks, Laravel annab rohkem vabadust ebatüüpilisele loogikale ja liidestustele, ning laiem võrdlus on artiklis selle kohta, millal valida WooCommerce või Laravel. Selles etapis on tähtsam mõista, et platvormi nimi ise ei ütle, mis teie tellimusega juhtub.

Lisage protsessi kirjeldusele ka üks erand ja kontrollige, mis juhtub, kui makse ebaõnnestub, viimast ühikut püüavad osta kaks inimest korraga, pakiautomaat ei ole saadaval või klient soovib komplektist osa tagastada. Kõiki haruldasi olukordi ei ole vaja loetleda, kuid üks ebaõnnestunud stsenaarium paljastab staatused, teavitused ja töötajate kohustused palju paremini kui kümme rohelist linnukest pakkumises.

Kataloog algab müüdava ühiku määratlusest

Toodete Exceli fail ei ole veel kataloog, sest kõigepealt tuleb kokku leppida, mis on süsteemis üks müüdav ühik: lihtsa raamatu puhul võib see olla üks kaup ühe hinna ja jäägiga, rõivastel võib igal suuruse ja värvi kombinatsioonil olla oma artikkel, pilt, triipkood ja jääk, komplekti puhul peab aga olema teada, kas see on iseseisev toode või mitme laoühiku kogum.

Valmistage enne massilist importi ette üks täielikult täidetud näidiskaup ja pange sinna nimetus, lühike ja täielik kirjeldus, hind, maksu kohaldamine, kategooria, variant, artikkel, jääk, tarne jaoks oluline kaal või mõõtmed, pildid ja muu ostjale tähtis teave. Näidis laseb märgata puuduvat välja, kuni tuleb parandada üks rida, ja annab kujundajale päris sisu, mitte ideaalset demokaarti.

Piiramatu SKU-de arv tehnilises lahenduses ei tähenda, et neljakümne ja nelja tuhande kauba ettevalmistamine nõuab sama tööd, sest poe funktsioonide hind võib jääda samaks, suuremas kataloogis kasvab aga andmete puhastamine, piltide sidumine, variantide kontroll, tõlkimine ja import. Seepärast tuleb pakkumises eraldi näidata platvormi võime kataloogi hoida ja töö, mis tuleb teha, et teie andmed oleksid kasutuskõlblikud; sellesse töösse võib kuuluda väljade vastendamine, vigaste ridade käsitlemine, piltide kontroll ja lõppimporti võrdlus lähtefailiga.

Rõivad: suurus ja värv ei ole ainult filter

Rõivapoes on suurus ja värv sageli variandid oma saadavusega, mitte ainult filtri väärtused, nii et ostja peab nägema, et sinine M on otsas, isegi kui must M on veel saadaval, pilt peab muutuma koos valitud värviga ja tellimusse peab jõudma täpne kombinatsioon. Enne kogu kataloogi sisestamist kontrollige ühte toodet vähemalt kahe suuruse, kahe värvi ja ühe mittesaadava variandiga.

Kataloogil on omanikku vaja ka pärast käivitamist, seega määrake, kes muudab hinda, lisab variandi, parandab kirjeldust ja võtab kauba müügist maha, ning kui teave tuleb tarnijalt või ettevõtte ressursside juhtimise süsteemist, tuleb määrata peamine andmeallikas ja sünkroonimise suund. Kaks kohta, kus töötajad tohivad üht hinda parandada, ei anna paindlikkust, vaid eelduse mittevastavuseks, seepärast tuleb kokku leppida muudatuste ajalugu, kinnitamisõigused ja toimimine vigase impordi korral; meeskond peab suutma selgitada, millises allikas vale väärtus tekkis ja mida see juba on mõjutanud.

Makseprotsess tuleb kirjeldada staatuste ja toimingutega

Maksete liidestus ei ole valmis makseakna avamisega, sest projektis tuleb kokku leppida, mida pood teeb pärast iga tulemust: õnnestunud makse võib muuta tellimuse staatust, saata kinnituse, vähendada saadaolevat kogust ja anda ülesande komplekteerimiseks. Ebaõnnestunud või katkestatud makse ei tohi paista tasutud tellimusena, kuid ei tohiks kaupa ka lõputult broneerida.

Igapäevakeeles võib „makse õnnestus“ tähendada, et pank kinnitas tehingu, makseteenus selle registreeris või raha on juba ettevõtte kontole laekunud, ja täitmisprotsess ei tohi toetuda nii ebaselgele sõnastusele, seega määrake, milline süsteemi staatus lubab komplekteerimist alustada ja kuidas töötaja näeb tellimust, mis vajab kontrolli. Kättesaamisel tasumise ja pangaülekande tellimusi tuleb käsitleda eraldi, mitte kaardimakse protsessi koopiana.

Tuleb otsustada ka see, kui kaua tasumata tellimus kaupa broneerituna hoiab, sest liiga lühike periood võib kauba vabastada, kuni ostja makset alles lõpetab, liiga pikk periood aga vähendab saadaolevat jääki kunstlikult. WooCommerce'i põhilaoseisu seaded lubavad hallata kogust ja määrata broneeringu aja tasumata tellimustele, nii et standardpood saab oma sisemist jääki kontrollida ilma välise laoliidestuseta.

Enne käivitamist tehke vähemalt üks õnnestunud makse, üks katkestatud makse ja üks raha tagastamine testi- või väikese päris summa režiimis ning kontrollige ostja ekraani, tellimuse staatust halduses, e-kirju, jäägi muutusi ja makseteenuse kirjet. Kui meeskond on näinud ainult õnnestunud stsenaariumi, on suur osa makseprotsessist endiselt kontrollimata, sest päris töös tuleb eristada panga hilinenud teavitust, ostja katkestatud makset ja süsteemi viga, ning iga juhtumi kohta peab haldusesse jääma arusaadav kirje.

Tarne ja tellimuse täitmine ei ole üks linnuke

Tarne liidestus võib arvutada hinna, näidata pakiautomaate, luua saadetise ja tagastada jälgimisnumbri, kuid mitte iga lahendus ei tee kõiki neid toiminguid, seega tuleb sõnastus „kuller külge panna“ asendada konkreetsete küsimustega: kas ostja valib pakiautomaadi, kas hind sõltub kaalust, korvi summast või riigist, kas pakisilt luuakse poes ja kas jälgimislink jõuab e-kirja automaatselt?

Tellimuse täitmine algab pärast selle vastuvõtmist, ja töötajal peavad olema selgelt näha tasutud ja komplekteeritavad tellimused ning toimimine vigade korral. Määrake, kes tohib staatust muuta, kas ostja saab teavituse ja kuidas jälgimisnumber fikseeritakse; väikeses poes võib seda teha üks inimene, suuremas meeskonnas võib ilma vastutuse jaotuseta ühe tellimuse ette valmistada kaks korda, samal ajal kui teine jääb märkamata.

Tarnehinda kontrollige äärmuslike näidetega, mitte ainult ühe keskmise korviga, ning proovige odavaimat ja kallimat kaupa, tasuta tarne läve, aadressi väljaspool lubatud piirkonda ja kaupa, mida ei saa pakiautomaati panna. Kui arvutus kasutab kaalu, võib üks kaaluta kaup kogu tulemuse rikkuda; fikseeritud hinna korral peab olema teada, kes katab vahe mittestandardse saadetise puhul, ja kontrollida tuleb ka mitme paki tarnet ning seda, kas meetod jääb saadavaks korvile, milles on eri suurusega kaupu.

Ka kättesaamine kontoris või poes on tarneviis oma reeglitega, seega peab ostja teadma aadressi, aega ja hetke, mil tellimus on kättesaamiseks valmis, lao töötaja aga peab sellest valikust õigel ajal teada saama. Hea test ei lõpe kirjaga „tellimus vastu võetud“, vaid pakiga või väljastamiseks ettevalmistatud kaubaga ja ostjale saadetud täpse teavitusega.

Tellimuse ja taganemise nõuded tuleb viia konkreetsetesse toimingutesse

Sidevahendi abil sõlmitud lepingu saab sõlmida veebilehel, e-kirjas, sõnumivahetuses või muus kaugsuhtluses, seega müüja kohustused ei kao, kui tellimus võetakse vastu sotsiaalvõrgustikus ja arve saadetakse hiljem, elektroonilises tellimisprotsessis peab nupp või samaväärne toiming aga ühemõtteliselt näitama, et tellimusega kaasneb maksmiskohustus. Nõuded käivad tellimise järjekorra enda, mitte ainult veebilehe jaluses oleva tingimuste lehe kohta.

Võlaõigusseadus näeb ette, et vahetult enne elektroonilist tellimust tuleb ostjale muu hulgas näidata kindlat olulist teavet, lõpphinda ja lisakulusid, makseviisid ja tarnepiirangud aga hiljemalt tellimise alguses. Kuna nõuete koosseis võib muutuda, tuleb enne käivitamist kontrollida sel päeval kehtivat redaktsiooni ja võrrelda poe ekraane konkreetsete normidega.

Tellimuse kinnitusse tuleb panna lepingutingimuste koopia või muu dokument, mida ostja saab muutmata kujul säilitada, ja ainuüksi lingist müüja ühepoolselt muudetavale lehele ei piisa, seega kontrollige, kas kinnituses on tellitud kaubad, hind, tarne, kaupleja andmed ja vajalik lepingueelne teave. Täpse dokumendikogumi ja sõnastused kooskõlastage juristiga vastavalt oma müügimudelile ning hoidke kasutatud versioon koos tellimuse kuupäevaga, et vaidluse korral saaks näidata mitte ainult praegust tingimuste lehte, vaid ka ostjale tegelikult antud teavet.

TTJA selgitab, et tarbijal on kauba puhul tavaliselt neljateistkümnepäevane taganemisõigus, mida loetakse kauba kättesaamisest, ja seaduses on nimetatud konkreetsed erandid. Projektis tuleb ette näha mitte ainult taganemise tekst, vaid ka vorm või kontakt, teate kuupäeva registreerimine, kauba kontroll, raha tagastamine ja jäägi taastamine; kui need toimingud elavad ühe töötaja mälus, töötab pood ainult seni, kuni see inimene on kättesaadav.

Pood ilma oma laota on ikka müüja protsess

Poodi saab pidada ilma oma füüsilise laota, näiteks tarnides kauba edasimüüjalt või tootjalt, mis vähendab vajadust varusid hoida, kuid ei tühista müüja vastutust ostja ees. Kui leping on sõlmitud teie ettevõttega, vastutab täitmise eest ostja ees ikka teie ettevõte, mitte tarnija.

Sellises mudelis on kriitiline saadavuse teave, ja kui tarnija tagab andmevoo või rakendusliidese, tuleb kokku leppida uuendamise sagedus, vigade käsitlemine ja toimimine ühenduse katkestuse korral. Viie minuti viivitus võib kiiresti müüdava viimase ühiku puhul olla oluline, aeglase varude käibega kataloogis võib see olla vastuvõetav, seega tuleb sünkroonimise sagedus määrata varude liikumise ja ettevõtte riski järgi ning kokku leppida ka see, kas ühenduse vea ajal kaup peidetakse, jäetakse müüki või antakse käsitsi kontrolli.

Tähtis on eristada poe sisemist laoseisu arvestust laomoodulist või välisest liidestusest: WooCommerce'i põhivõimalused võivad hoida kogust iga kauba ja variandi kohta, vähendada seda pärast tellimust ja keelata kauba tellimise ilma jäägita, ning sellest võib piisata ühele kataloogile, mida peetakse poes endas. Laomoodulit on vaja siis, kui peamine jääk on teises süsteemis, hoiukohti on mitu või tuleb sünkroonida mitu müügikanalit.

Enne käivitamist mängige läbi olukord, milles tarnija ei saa tellimust täita, kuigi kaup on poe ekraanil veel saadaval, ja määrake, kes saab teavituse, kui kiiresti võetakse ostjaga ühendust, kas pakutakse asendust ja kuidas tehakse raha tagastus. See stsenaarium ei tee mudelit halvaks, vaid muudab ootamatu keerukuse hallatavaks riskiks.

Kas e-poodi saab luua tasuta?

Tasuta e-poe loomine võib tähendada mitut eri asja, näiteks tasuta kujundusmalli, avatud lähtekoodiga tarkvara, prooviplaani või sotsiaalvõrgu vitriini. Need tööriistad võivad vähendada esialgset litsentsitasu ja aidata kontrollida, kas pakkumine inimesi huvitab, kuid need ei tühista tööd kaubaandmete, maksete, tarne, tingimuste, turvalisuse ja igapäevase haldusega.

Kui ehitate poe ise, alustage väikseimast protsessist, mida saab korrektselt täita, sest üks keel, väike kataloog, üks makseviis ja üks tarneviis lubavad nõudlust kontrollida, võtmata keerukate liidestuste ülalpidamist. Ka sellises versioonis peab ostja nägema õiget hinda ja tarnetingimusi, tellimus peab jõudma haldusesse, teie aga peate suutma kauba saata ja taganemist käsitleda.

Kulud ilmuvad tavaliselt seal, kus tasuta tööriist lõpeb: domeenis ja majutuses, maksete komisjonitasudes, tasulistes täiendustes, andmete impordis, kujunduse kohandamises, hoolduses ja teie enda ajas, seega võrrelge mitte ainult kuu tellimust, vaid ka tunde, mis kuluvad kataloogile, vigade kõrvaldamisele ja uuendustele. Juba proovijärgus pange kirja korduvad tööd, sest tasuta tööriist võib olla säästlik täpselt seni, kuni käsitsi teenindamine neelab kokkuhoitud litsentsitasu; kui teete üht käsitsi toimingut viie tellimuse puhul, võib see olla põhjendatud, viiesaja tellimuse puhul on see juba mõõdetav kulurida.

Professionaalne abi muutub ratsionaalseks siis, kui viga maksab rohkem kui juurutamine või protsess ei mahu enam ühe inimese tööpäeva, ja sellisest piirist võivad märku anda laoseisud, mis omavahel ei klapi, mitu keelt ja hinnagruppi, korduvad käsitsi andmekontrollid või liidestused raamatupidamise ja tarnijatega. Oma jõul loodud pood ei ole ebaõnnestumine ja arendaja kaasamine ei ole kohustuslik järgmine samm; otsuse määrab protsessi keerukus ja ettevõtte suutlikkus seda ülal hoida. Meeskonnas on vaja inimest, kes kontrollib regulaarselt uuendusi, varukoopiaid, turvateavitusi ja vealogisid, ning tuleb suuta ostmisprotsess pärast täienduste uuendamist taastada ja lahendus dokumenteerida nii, et pood ei jääks sõltuma ühe töötaja vabast ajast.

Täitjast sõltumata peavad domeeni, majutuse, makseteenuse ja tarne kontod olema ettevõtte kontrolli all, mitte seotud ühe töötaja või välise spetsialisti isikliku aadressiga, seega pange kirja, kus hoitakse ligipääse, kes tohib makseid kinnitada ja kuidas ligipääs taastatakse vastutaja äraolekul. Oma jõul ehitatud projektis on see kord sama tähtis kui välisteenuse puhul, sest platvormi haldusõigused ei tähenda veel kontrolli domeeni, serveri ja välisteenuste lepingute üle.

Sisu ja migratsioon tuleb ette valmistada enne arenduslõppu

Poe projekti pidurdab sageli mitte kood, vaid puuduvad kaubaandmed, pildid ja otsused, seega määrake, kes ettevõttes sisu tarnib, kes selle kinnitab ja millised väljad on kohustuslikud, ning igal vahetulemusel olgu kuupäev. Arendaja saab luua välja kirjeldusele, kuid ei saa ettevõtte asemel otsustada, mida kauba kohta tohib lubada.

Piltidel on vaja ühtset proportsiooni, piisavat eraldusvõimet ja kasutusõigusi; kontrollige failinimesid, asendustekste ja seda, milline pilt kuulub konkreetsele variandile. Kui tarnija muudab piltide aadresse hoiatamata, võib väline link kaduda, seega on kindlam protsess tavaliselt pildid kontrollitult importida ja poe keskkonnas optimeerida, hoides sidet toote identifikaatoriga.

Migratsioonis tuleb eraldi üles lugeda tooted, kategooriad, kliendid, tellimuste ajalugu, kupongid, sisu ja failid, sest kõike ei tohi ega tarvitse üle kanda, ning ajaloolisi kliendiandmeid tuleb hinnata ka andmekaitse ja säilitamistähtaegade seisukohast. Enne täismigratsiooni tehke proov väikese andmehulgaga, võrrelge kirjete arvu ja välju ning alles siis määrake hetk, millest alates vanas süsteemis enam muudatusi ei tehta; pärast lõppimporti koostage ülevaade puuduvatest kirjetest, duplikaatidest ja väärtustest, mida uus süsteem on teisiti tõlgendanud.

Veebilehte vahetades valmistage ette vana ja uue aadressi kaart, sest aadress ilma ümbersuunamiseta viib kasutaja ja otsimootori olematule lehele, ja ümbersuunamine ise ei garanteeri varasemaid otsingutulemuste positsioone, kuid aitab hoida loogilist teed ja anda signaalid vastavale uuele lehele. Pärast käivitamist kontrollige tähtsamaid toote- ja kategooriaaadresse, mitte ainult avalehte.

Enne käivitamist tehke täielik vastuvõtutest

Vastuvõtutestis kasutage realistlikku ostja stsenaariumi konkreetse kaubaga: avage pood telefonis, leidke kaup otsingu või kategooriaga, valige variant, pange see ostukorvi ja muutke kogust, seejärel kontrollige hinda koos maksudega, ettenähtud soodustust ja tarnet. Jätkake tellimuse vormistamiseni, makske ning lugege kõik ekraanid ja e-kirjad.

Jätkake testi halduses: kontrollige tellimuse staatust, jäägi vähenemist just valitud variandil, aadressi, pakiautomaati ja ostja märkust, looge saadetis, saatke jälgimisteave ja viige tellimus lõpuni. Lõpuks vormistage taganemine ja raha tagastus, sest täielik tsükkel paljastab sageli, et iga funktsioon eraldi töötab, kuid teave ei liigu ühest funktsioonist teise.

Korrake lühemat testi vigadega: kehtetu kupong, mittesaadav variant, katkestatud makse, aadress väljaspool tarnepiirkonda ja viimane kaubaühik, kusjuures veateade peab selgitama järgmist sammu ja süsteem ei tohi jätta valet broneeringut. Testi tulemusena on vaja mitte ainult vigade loendit, vaid ka otsust, millised vead blokeerivad käivitamise; iga paranduse juurde nimetage vastutaja, korduskontrolli kuupäev ja vastuvõtu tõend, seejärel veenduge, et viga ei kordu ei telefonis ega arvuti brauseris.

Kontrollige ka privaatsuse ja analüütika seadeid, sest täiendavad analüütika-, reklaami- või muud jälgimisskriptid, mille tööks on vaja nõusolekut, ei tohi alata enne vastavat valikut, ja kontroll tuleb teha ka pärast keeldumist ning nõusoleku tagasivõtmist. Tellimuseks vajalikud tehnilised toimingud ei tohi omakorda lakata töötamast, kui ostja analüütikast keeldub.

Käivitamise ajal määrake vastutajad ja valmistage ette tegevuskava tõrke korral, määrates, kes kontrollib makseid, tarnet ja sisu, kellele teatatakse kriitilisest veast ja kuidas toimida, kui makseid ei saa vastu võtta või hinnad on valed. Mõnikord on kõige kindlam otsus tellimine ajutiselt peatada, mitte koguda tellimusi, mida ei suudeta täita, ning käivitamise kontrollis võrrelge testi- ja avaliku keskkonna konfiguratsiooni, maksevõtmeid, tarnekontosid, maksuseadeid ja e-kirja saatjat, sest õnnestunud test teises keskkonnas ei tõesta veel, et samad tingimused kehtivad ostjale avatud poes.

Haldamine ja hooldus algavad enne käivitamist

Poe haldur ei ole abstraktne roll, mis antakse pärast projekti üleandmist, seega määrake enne käivitamist, kellel on õigus muuta hindu, avaldada tooteid, teha raha tagastusi ja näha kliendiandmeid, sest igal inimesel ei ole vaja kõiki õigusi. Sisu toimetajal ei tule tavaliselt muuta maksete seadeid, lao töötajal ei ole vaja näha rohkem klienditeavet, kui saadetise ettevalmistamiseks tarvis.

Lepitage kokku, kuidas paigaldatakse süsteemi, pistikprogrammide ja liidestuste uuendused, mis ei tohi esmakordselt jõuda avalikult kättesaadavasse poodi reede pärastlõunal ainult sellepärast, et halduspaneelis ilmus teavitus. Vaja on varukoopiat, testkeskkonda ja inimest, kes pärast muudatusi teeb lühikese ostutesti, sest uuendus võib puudutada mitte ainult välimust, vaid ka makse, tarne ja e-kirja liidestusi.

Määrake, kes märkab, et makseteavitused ei jõua enam poodi, saadetiste liides vastab veaga või ebaõnnestunud tellimuste arv kasvab järsult; ostja kõne ei tohi olla esimene signaal veast. Vähemalt kriitilistel liidestustel on vaja vealogi ja teavitust vastutajale, meeskonnal aga intsidendi käsitlemise korda, milles on kirjas, kus hoitakse otsust ajutise lahenduse kohta ja millise kriteeriumi järgi kontrollitakse teenuse taastamist.

Esimestel nädalatel peavad mõõtmised vastama protsessi küsimustele, mitte ainult külastusi lugema, seega võrrelge alustatud ja lõpetatud oste, maksevigu, tarnevalikuid ja klienditoe põhjuseid. Kui paljud inimesed peatuvad ühes etapis, kontrollige kõigepealt tehnilist või sisulist takistust, enne kui järeldate, et turul ei ole nõudlust.

Mida valmistada ette enne vestlust arendajaga

Et esimene vestlus oleks produktiivne, valmistage ette üks näidiskaup, üks täielik tellimuse stsenaarium ja üks erandolukord ning lisage ligikaudne kaupade ja variantide arv, keeled, riigid, makse- ja tarneviisid. Kui veebileht on juba olemas, öelge, mida soovite migreerida ja milliste süsteemidega peab pood andmeid vahetama; tehnilist lahendust teadma ei pea, kuid ettevõtte tööd peab suutma näidata.

Nimetage eraldi nõuded, mis peavad olema esimeses käivituses, ja ideed, mida tohib edasi lükata: makse ja tarne põhiprotsess on tavaliselt käivitamise nõue, keerukas lojaalsusprogramm võib olla järgmine etapp, kui ilma selleta saab tellimuse korrektselt vastu võtta ja täita. See jaotus kaitseb eelarvet paremini kui suvaline funktsioonide mahakriipsutamine, sest igal edasilükatud tööl jääb nimetatud põhjus, sõltuvus ja hetk, millal otsuse juurde tuleb pärast päris tellimuste andmeid tagasi tulla.

Näidiskaubast, tellimuse stsenaariumist ja erandolukorrast piisab, et e-poe projekti eeluuringus määrata selge ja kontrollitav töömaht ning tähtaeg ja hind. Pakkumises küsige mitte ainult funktsioonide nimesid, vaid ka piire: kes valmistab andmed, kes seadistab välisteenuse ja millise testi järel on töö vastu võetud.

Kui kataloog või protsessi visand on teil juba olemas, on järgmine samm see koos inimesega läbi vaadata, kes oskab hinnata tehnilisi sõltuvusi, ning kui visandit veel ei ole, võime alustada selle koostamisest ja öelda, mida esimeses versioonis ehitama ei pea. E-poe projekti eeluuringu tellimine on väärtuslik juba enne platvormi valikut, sest siis määrab hinna selgelt määratletud töömaht, mitte oletused selle kohta, mida sõna „pood“ peaks sisaldama; mõlemad pooled peavad juba enne arendust ühtmoodi mõistma, milline kontrollitav tulemus kinnitab, et projekt on lõppenud.