Kuidas kirjutada veebiprojekti lähteülesannet nii, et hind ei ujuks laiali?

Veebiprojektide maailmas on üks kummaline nähtus, mis kordub visalt nagu halb suvelaul raadios.

Ettevõte küsib pakkumist.
Tegija teeb pakkumise.
Projekt algab.
Ja siis mõne aja pärast selgub, et hind on vahepeal kuskile jalutama läinud.

Klient on pahane, sest “alguses oli ju teine number”.
Tegija on pahane, sest “alguses ei räägitud sellest kõigest midagi”.
Ja lõpuks on kõik natuke solvunud, natuke väsinud ja natuke segaduses.

Väga tihti ei ole probleem selles, et keegi tahtis kedagi petta. Probleem on palju igavam. Ja seetõttu ka palju tavalisem.

Lähteülesanne oli udune.

See tähendab, et veebiprojekti alguses ei pandud piisavalt selgelt paika, mida tegelikult tegema hakatakse, kellele, mis eesmärgiga ja millise mahuga. Tulemuseks on see, et pakkumine tehakse mingite oletuste põhjal. Ja nagu elus ikka — kui suhe hakkab oletuste pealt, siis kuskil tuleb draama nagunii.

Mis asi see lähteülesanne üldse on?

Lihtsalt öeldes on lähteülesanne dokument või sisend, mis aitab veebipartneril aru saada:

• mida sul tegelikult vaja on
• miks seda vaja on
• kellele see veeb mõeldud on
• millised funktsioonid peavad olemas olema
• millised ei pea
• mis on oluline kohe ja mis võib tulla hiljem

See ei pea olema 17-leheküljeline eepos. Keegi ei oota, et sa kirjutaksid veebiprojekti “Sõja ja rahu” uue digitaalse versiooni.

Aga ta peaks olema piisavalt selge, et teine pool ei peaks ennustama, mida sa mõtled, kui ütled:
“soovime kaasaegset ja kasutajasõbralikku lahendust”.

See lause tähendab päris vähe. Umbes sama palju kui “tahaks midagi head süüa”.

Miks hind ujuma hakkab?

Sest kui alguses on info udune, siis tehakse pakkumine parima oletuse põhjal.

Näiteks klient kirjutab:

• vaja on uut kodulehte
• võiks olla ilus ja kaasaegne
• mõned teenuse lehed
• blogi
• kontaktivorm
• võib-olla mitu keelt
• hiljem võiks midagi veel lisada

See kõlab esmapilgul täiesti normaalselt. Aga tegelikult on siin terve hulk küsimusi, mille vastused mõjutavad hinda väga otseselt:

• mitu teenuse lehte?
• kas sisu on olemas või tuleb see luua?
• kas blogi vajab eri kujundusi või ainult tavalist postitust?
• mitu keelt kohe, mitu hiljem?
• kas “hiljem midagi lisada” tähendab filtritega kataloogi või lihtsalt uut alamlehte?
• kas kontaktivorm saadab ainult e-kirja või läheb ka CRM-i?

Kui neid asju alguses lahti ei räägita, siis hakkabki hind projektis sees muutuma. Mitte tingimata paha pärast. Vaid sellepärast, et töömaht muutub.

Hea lähteülesanne ei pea olema pikk. Ta peab olema konkreetne.

Kõige parem lähteülesanne on selline, millest teine inimene saab aru ilma, et peaks iga teise lause järel kirjutama:
“mõtlesite selle all täpsemalt mida?”

Hea lähteülesanne võiks katta vähemalt järgmised teemad.

1. Projekti eesmärk

Mitte “meil on uut veebi vaja”, vaid miks seda vaja on.

Näiteks:

• tuua rohkem päringuid
• esitleda teenuseid usaldusväärsemalt
• toetada müüki Eestis ja välisturul
• teha sisuhaldus lihtsamaks
• asendada aegunud ja kehvasti hallatav veeb

See on tähtis, sest eesmärk mõjutab kogu lahendust. Kui eesmärk on lihtsalt visiitkaart, on üks loogika. Kui eesmärk on aktiivselt päringuid tuua, on teine.

2. Sihtgrupp

Kellele see veeb mõeldud on?

Kui vastus on “kõigile”, siis see ei ole vastus. See on lihtsalt viis öelda, et pole veel läbi mõeldud.

Kas su klient on:

• väikeettevõtja
• tootmisettevõtte ostujuht
• turundusjuht
• eraklient
• rahvusvaheline partner
• tööotsija

Mida täpsem sihtgrupp, seda lihtsam on teha õige struktuur, sisu ja kasutajateekond.

3. Veebi sisu ja struktuur

See on koht, kus peaks võimalikult konkreetselt kirjas olema:

• millised lehed on vaja teha
• millised neist on põhilehed
• kas vaja on blogi
• kas vaja on maandumislehti
• kas vaja on mitut keelt
• kas olemasolev sisu tuleb üle tuua

Ei pea olema millimeetri täpsusega kivisse raiutud, aga mingi loogiline sisukaart võiks olemas olla.

Sest “teeme mõned lehed juurde” on veebiprojektis umbes sama ohtlik lause nagu “teeme köögis väikse remondi”.

4. Funktsionaalsused

Siin lähevad hinnad väga kiiresti ujuma, kui see osa jääb häguseks.

Pane kirja:

• kontaktivormid
• hinnapäringud
• blogi
• uudiskirjaga liitumine
• mitmekeelsus
• e-pood
• broneerimine
• kasutajakontod
• filtrid
• integratsioonid
• analüütika
• erilahendused

Mida täpsemalt funktsioonid kirjas on, seda vähem jääb ruumi “aaa, me arvasime, et see on juba sees”.

5. Sisu loomine: kes teeb?

See on klassikaline koht, kus projektid venima lähevad.

Kas tekstid kirjutab klient?
Kas partner aitab?
Kas olemasolev sisu toimetatakse ümber?
Kas pildid on olemas?
Kas keegi tegeleb tõlgetega?

Kui see osa on alguses lahti rääkimata, siis jääb projekt mingil hetkel lihtsalt seisma. Veeb on valmis, aga sisu pole. Ja ilma sisuta on veeb umbes sama kasulik nagu köögimööbel ilma tööpinnata.

6. Tehnilised ja halduslikud ootused

Väga kasulik on kohe kirja panna ka see, mis on kliendi jaoks pärast projekti oluline:

• kas veeb peab olema lihtsasti hallatav
• kas klient tahab ise sisu muuta
• kas vaja on koolitust
• kas hooldust on vaja
• kas SEO põhiseaded peavad sees olema
• kas analüütika peab olema paigas
• kas veeb peab olema mitmekeelne
• kas olemasolev domeen ja hosting jäävad kasutusse

Just siin tekib vahe “lihtsalt ilus veeb” ja “päriselt kasutatav veeb” vahel.

7. Mis on kriitiline ja mis on nice to have?

See on üks kõige kasulikumaid osi kogu lähteülesandes.

Jaga asjad kahte hunnikusse:

• peab olema
• võiks olla

Miks see hea on? Sest siis ei paisu projekt kohe alguses üle omaenda eelarve ja ambitsiooni. Kõike ei pea esimeses etapis tegema. Täiesti normaalne on ehitada veeb nii, et osa asju tehakse nüüd ja osa hiljem.

Aga kui kõik on korraga “hästi oluline”, siis ei ole tegelikult miski prioriteet.

Väike näide halvast ja heast sisendist

Halb sisend:
“Soovime kaasaegset, kiiret ja kasutajasõbralikku veebilahendust, kus oleks teenused, blogi, kontakt ja vajadusel hiljem lisavõimalused.”

Parem sisend:
“Soovime uut WordPressi kodulehte eesti ja inglise keeles. Eesmärk on tuua rohkem päringuid tootmisettevõtetelt Eestis ja Põhjamaades. Vaja on avalehte, 5 teenuse lehte, tehtud tööde lehte, blogi, kontaktilehte ja 2 maandumislehte. Kontaktivorm peab saatma päringud e-mailile. GA4, GTM ja Search Console peavad olema seadistatud. Sisu põhja anname meie, aga ootame partnerilt toimetamist ja struktuuriabi. Klient peab saama pärast ise sisu hallata.”

Näed vahet?
Teises variandis ei pea tegija kristallkuuli välja otsima.

Kuidas see aitab hinda paigal hoida?

Väga lihtsalt.

Kui töömaht on alguses selge, siis saab ka pakkumine olla täpsem. Kui pakkumine on täpsem, siis on vähem üllatusi. Kui on vähem üllatusi, siis ei hakka hind projekti jooksul iga natukese aja tagant uut elu elama.

Muidugi võib ka hea lähteülesandega tulla muudatusi. Elu ei ole kivisse raiutud. Aga siis on vähemalt kõigil aru saada:

• mis oli algses mahus
• mis tuli juurde
• miks tuli juurde
• ja miks see mõjutab hinda

See on juba palju tervem olukord kui see klassikaline “aga ma arvasin, et see käib ju asja juurde”.

Kokkuvõte: vähem segast juttu, parem projekt

Caoticas usume üsna lihtsasse asja: hea veebiprojekt ei alga disainist. Ta algab selgusest.

Mida paremini oskab klient oma vajaduse sõnastada, seda parem tuleb pakkumine, seda realistlikum on eelarve ja seda väiksem on võimalus, et projekt läheb poole tee peal laiali nagu odav aiatool jaanipäeval.

Ehk siis kui tahad, et hind ei ujuks laiali, siis ära alusta veebiprojekti lausega:
“teeme midagi ägedat.”

Alusta hoopis sellega:
mida meil päriselt vaja on, kellele, mis eesmärgiga ja mis mahus.

See ei ole ainult hea projektijuhtimine.
See on väike teene kogu ühiskonnale.