Mis teeb WordPressi projekti hinnapakkumise võrreldavaks?

Kaks WordPressi hinnapakkumist võivad erineda mitu korda ning mõlemad võivad olla oma eelduste piires mõistlikud. Üks võib sisaldada valmis kujunduse tehnilist teostust, teine aga ka sisustruktuuri, kasutajakogemuse tööd, migratsiooni, integratsioone, testimist ja avaldamisjärgset tuge.

WordPressi hinnapakkumine on võrreldav alles siis, kui saad aru, millise tulemuse ja millise vastutuse iga number sisaldab. Hinna vaatamine enne ulatuse kõrvutamist võib muuta odavama dokumendi hiljem kallimaks projektiks, kuid sama vale oleks eeldada, et kõrgem hind tähendab automaatselt paremat lahendust.

Alusta ühest ja samast lähteülesandest

Pakkumisi on raske võrrelda, kui iga partner on vastanud erinevale küsimusele. Enne päringu saatmist pane lühidalt kirja praegune olukord, projekti eesmärk, vajalikud kasutajarühmad, olulised funktsioonid, soovitud ajakava ja teadaolevad piirangud.

Sa ei pea ette määrama tehnilist lahendust ega koostama kümnete lehekülgede pikkust dokumenti. Hea partner aitab ebaselge osa kaardistada. Oluline on, et kõik pakkujad näeksid samu lähteandmeid ja märgiksid selgelt, milliseid eeldusi nad hinna koostamisel tegid.

1. Eesmärk ja valmis projekti tähendus

“Uus veebileht” ei ole veel tulemus. Täpsem eesmärk võib olla müügipäringute kvaliteedi parandamine, mitme käsitsi tehtava sammu eemaldamine, uuele turule sisenemine või aegunud halduse asendamine.

Vaata, kas pakkumises on kirjas, mida loetakse valmis tööks. Kas valmis tähendab arendust testkeskkonnas, sisestatud sisu, koolitatud haldureid või juba avaldatud ja kontrollitud veebilehte? Kui vastuvõtukriteeriumid puuduvad, võib sama sõna tähendada tellijale ja arendajale eri asja.

2. Lehed, sisu ja sisumudel

Lehtede arv üksi ei näita sisu keerukust. Teenused, projektid, meeskonnaliikmed ja artiklid võivad olla eraldi sisutüübid, mida saab mugavalt filtreerida ning eri kohtades taaskasutada. Teises pakkumises võivad samad vaated olla käsitsi koostatud tavalehed.

Kontrolli, kas pakkumine täpsustab:

• millised sisutüübid ja väljad luuakse;
• milliseid korduvkasutatavaid leheplokke saab haldur kasutada;
• kes kirjutab, sisestab ja tõlgib sisu;
• kui palju näidissisu või pärissisu hinna sees sisestatakse;
• kas olemasolev sisu migreeritakse automaatselt või käsitsi.

Kui vajad hallatavat ettevõtte veebi, saad võrrelda ulatust meie ettevõtte veebilehe arenduse kirjeldusega. See aitab eristada nähtavat kujundust sisustruktuurist ja tehnilisest alusest.

3. Disain ja kasutajakogemus

“Kohandatud disain” võib tähendada valmis kujundussüsteemi värvide muutmist või nullist loodud kasutajateekondi, prototüüpi ja eri ekraanisuuruste vaateid. Mõlemad võivad olla õiged valikud, kuid nende töömaht ei ole sama.

Vaata, mitu unikaalset vaadet kavandatakse, mitu tagasisideringi on hinnas ja kas arvestatud on mobiili, vormide olekute ning veateadetega. UI/UX-i ja veebidisaini teenuse kirjeldus annab orientiiri, millised otsused võivad toimuda enne visuaalset viimistlust.

4. Funktsioonid ja integratsioonid

Funktsioon peab pakkumises olema kirjeldatud kasutaja tegevuse ja ärireegli kaudu. “Kontaktvorm” võib olla lihtne e-kiri, aga ka tingimuslik vorm, mis salvestab andmed CRM-i, saadab eri teavitusi ning järgib nõusolekureegleid.

Integratsiooni puhul ei piisa reast “ühendame ERP-iga”. Pakkumine peaks näitama andmete suunda, autentimist, veaolukordi, testimist ja seda, kes vastutab välise süsteemi muudatuste eest. Loe lähemalt artiklist WordPressi integratsiooni tegelik hind või vaata meie API integratsioonide teenust.

5. Migratsioon, URL-id ja SEO

Uue veebi avaldamisel tuleb sageli säilitada vanade lehtede aadressid või suunata need kõige sobivamale uuele lehele. Lisaks vajavad kontrolli pealkirjad, metaandmed, jagamispildid, indekseerimise seaded, saidikaart ja analüütika.

Google’i ametlik URL-ide muutmise juhend soovitab koostada vana ja uue aadressi vastenduse, seadistada püsivad ümbersuunamised ning uuendada siselinke ja saidikaarti. Kui üks pakkumine sisaldab seda tööd ja teine mitte, ei ole nende avaldamise ulatus sama.

6. Ligipääsetavus, jõudlus ja testimine

Kvaliteeti on lihtne lubada, kuid pakkumises peaks olema näha, kuidas seda kontrollitakse. Kas testitakse erinevaid ekraanisuurusi ja brausereid? Kas vorme saab kasutada klaviatuuriga? Kas piltidel on asjakohased alternatiivtekstid? Kas enne avaldamist mõõdetakse laadimiskiirust?

Ligipääsetavuse puhul tasub küsida, millist taset ja milliseid vaateid kontrollitakse. W3C WCAG-i ülevaade kirjeldab rahvusvahelist standardit, mille põhimõtted on tajutavus, kasutatavus, arusaadavus ja töökindlus. Sõna “ligipääsetav” ilma kokkulepitud kontrollita on liiga üldine.

Samamoodi peaks olema selge, kes teeb funktsionaalse testimise, kes sisulise kontrolli ja kuidas parandatakse vead, mis leitakse enne või vahetult pärast avaldamist.

7. Ajakava, rollid ja sõltuvused

Ajakava peab näitama rohkem kui lõppkuupäeva. Olulised on vaheetapid, kliendi sisendit vajavad otsused ja välised sõltuvused. Kui sisu, tõlked või API ligipääsud hilinevad, peab olema teada, kuidas see mõjutab ülejäänud plaani.

Kontrolli, kes vastutab projektijuhtimise, disaini, arenduse, sisu, testimise ja avaldamise eest. Väikese tiimi puhul võib üks inimene täita mitut rolli, kuid vastutus peab siiski olema selge. Samuti tasub teada, kes on sinu igapäevane kontakt ja kuidas otsused kinnitatakse.

8. Mis jääb teadlikult hinnast välja?

Hea pakkumine ei pea sisaldama kõike. See peab ausalt nimetama, mida see ei sisalda. Välja võivad jääda näiteks tekstide kirjutamine, tootefotod, tasulised litsentsid, majutus, andmesisestus või kolmanda osapoole API muudatused.

Välistused ei ole ohumärk, kui need on nähtavad ja sobivad sinu plaaniga. Probleem tekib siis, kui vältimatu töö jääb mainimata ning ilmub projekti keskel ootamatu lisana.

Fikseeritud hind, ajapõhine töö või hübriid?

Fikseeritud hind sobib hästi siis, kui ulatus, eeldused ja vastuvõtukriteeriumid on piisavalt selged. Muudatuste kord peab olema kirjeldatud, et uus soov ei muutuks vaidluseks selle üle, kas see kuulus algsesse töösse.

Ajapõhine töö sobib paremini uuriva arenduse, olemasoleva süsteemi korrastamise või kiiresti muutuva prioriteediga töö puhul. Sel juhul on oluline läbipaistev tööde arvestus, regulaarne ülevaade ja kokkulepitud eelarvepiir.

Hübriidmudel ühendab fikseeritud põhiosa ja eraldi reservi või ajapõhise osa teemadele, mille ulatust ei saa enne tehnilist kaardistust ausalt lukustada. Mudeli nimi on vähem oluline kui see, kas riski jaotus on mõlemale poolele arusaadav.

Ohumärgid, mida tasub enne otsust täpsustada

• üks kogusumma ilma tööde või eelduste kirjelduseta;
• “kõik vajalik” ilma valmis tulemuse määratluseta;
• integratsioonid, migratsioon või sisu on mainitud ainult vajaduse korral;
• testimise ja paranduste vastutus puudub;
• ajakava ei arvesta kliendi sisendi ega väliste süsteemidega;
• pärast avaldamist puudub garantii-, toe- või hoolduskord;
• konto, kood või litsentsid jäävad ebaselgelt pakkuja omandisse.

Ükski neist ei tähenda automaatselt halba pakkujat. Need on küsimused, mille vastus aitab sul hinnata tegelikku ulatust ja koostööviisi.

Praktiline 30 minuti võrdlus

Tee lihtne tabel, kus veergudes on pakkujad ja ridades järgmised teemad: eesmärk, sisumudel, disain, funktsioonid, integratsioonid, sisu, migratsioon, ligipääsetavus, testimine, projektijuhtimine, avaldamine ning hooldus. Märgi iga rea juurde üks neljast vastusest: sisaldub, ei sisaldu, vajab täpsustust või hinnastatakse eraldi.

Seejärel vaata hinda uuesti. Sageli muutub suure erinevuse põhjus kohe nähtavaks. Kui mitte, saada kõigile pakkujatele samad täpsustavad küsimused. Vastuste selgus on ise oluline märk sellest, milline saab olema koostöö projekti ajal.

Viis küsimust enne valikut

1. Millised eeldused mõjutavad hinda kõige rohkem?
2. Milline töö ei ole pakkumises, kuid on tõenäoliselt vajalik?
3. Kuidas kinnitatakse muudatused ja nende mõju eelarvele?
4. Kes vastutab testimise, avaldamise ja esimeste nädalate toe eest?
5. Milliste sarnaste projektidega saab pakkuja oma lähenemist tõendada?

Kui sinu lähteülesanne on veel ebaselge, ei muuda see päringut halvaks. Mõistlik on alustada kaardistusest ja saada esmalt hinnavahemik või tasuline analüüs, mitte näiliselt täpne lõpphind teadmata ulatusele.

Codeteami esmase vestluse eesmärk on selgitada, milline järgmine samm annab otsustamiseks piisavalt infot. Mõnikord on see kohe pakkumine, keerukama projekti puhul aga lühike audit või töötuba.

Parim pakkumine ei ole kõige pikem ega kõige kallim. See on dokument, mille põhjal saad aru, mida ehitatakse, kes mille eest vastutab ja kuidas käitutakse siis, kui projekti jooksul selgub midagi uut.