Svetainės kūrimo klaidos: 10 dažniausių, kurias daro verslininkai

Tik apie 31 proc. technologijų projektų užbaigiami laiku, neviršijus biudžeto ir sutartos apimties. Dauguma priežasčių susiformuoja dar prieš pirmąją kodo eilutę – dešimt dažniausių klaidų ir kaip jų išvengti.

Svetainės kūrimas yra viena iš tų investicijų, kuri gali arba gerokai paspartinti įmonės augimą, arba tapti brangia ir varginančia patirtimi, pasibaigiančia rezultatu, kuris neatitinka lūkesčių, viršija biudžetą ir jau po kelių mėnesių reikalauja perdarymo. Šakos statistika kelia nerimą — tik apie 31% technologijų projektų užbaigiami laiku, neviršijant biudžeto ir laikantis iš pradžių sutartos apimties, o svetainių kūrimo projektai šiuo požiūriu nėra išimtis, nes žiniatinklio kūrimas patenka į tą pačią statistiką: likusieji projektai, maždaug du trečdaliai, priskiriami arba „probleminiams“ (viršytas biudžetas ar terminas, sumažinta apimtis), arba nesėkmingiems. Vis dėlto didžioji dalis šių nesėkmių nesusijusi su technologijų trūkumais ar kūrėjų nekompetencija — tai žmogiškųjų ir organizacinių veiksnių padarinys, atsirandantis dar prieš parašant pirmąją kodo eilutę, ir jų visiškai galima išvengti, jei verslininkas žino, kokios klaidos daromos dažniausiai ir kaip jų nepadaryti.

Šiame straipsnyje apžvelgsime dešimt dažniausių klaidų, kurias verslininkai ir organizacijos daro užsakydami svetainės kūrimą, ir prie kiekvienos jų paaiškinsime, kodėl ji atsiranda, kokios jos pasekmės ir ką Jūs galite padaryti, kad jos išvengtumėte.

1. Sprendimas vien pagal kainą

Tai turbūt dažniausia ir brangiausiai kainuojanti klaida, kurią verslininkai daro užsakydami svetainės kūrimą, — jie palygina kelis pasiūlymus ir pasirenka pigiausią, manydami, kad svetainė yra svetainė, nesvarbu, kas ją kuria, ir kad skirtumas tarp 500 eurų ir 5000 eurų pasiūlymo tėra kūrėjo pelno marža. Iš tikrųjų šis skirtumas beveik visada atspindi esminius kūrimo kokybės, kodo tvarkingumo, saugumo lygio, mastelio keitimo galimybių ir palaikymo po pardavimo skirtumus, o pigiausias pasiūlymas ilgainiui neretai tampa brangiausiu sprendimu, nes prastos kokybės kodas sukuria vadinamąją „techninę skolą“ — problemų sankaupą, dėl kurios reikia nuolatinių taisymų, kuri riboja svetainės plėtrą ir galiausiai priverčia viską perdaryti nuo nulio.

Mažos kainos pasiūlymai dažnai slepia reikšmingą riziką: kūrėjas gali naudoti nemokamas ar piratines temas, kuriose esama saugumo pažeidžiamumų arba paslėpto kenkėjiško kodo; kodas gali būti neoptimizuotas ir nestruktūruotas, todėl vėlesnė priežiūra ir plėtimas tampa sudėtingi ir brangūs; testavimas gali būti nepakankamas, o tai reiškia, kad klaidos išaiškės tik po paleidimo; palaikymas po pardavimo gali būti minimalus arba jo apskritai nebūti, ir Jūs liksite be pagalbos tada, kai jos labiausiai reikia. Teisingas požiūris — vertinti pasiūlymus ne pagal kainą, o pagal vertę: išnagrinėti kūrėjo atliktų darbų portfelį, pasikalbėti su ankstesniais klientais, patikrinti jo sukurtų svetainių techninę kokybę ir aiškiai suprasti, kas konkrečiai į kainą įskaičiuota, o kas ne, nes neretai „pigus“ pasiūlymas neapima to, kas „brangiame“ yra standartas, pavyzdžiui, adaptyvaus dizaino, bazinės SEO optimizacijos, saugumo konfigūracijos ar redaktorių mokymų dirbti su svetaine.

Šį skirtumą verta suskaičiuoti iki galo, nes pigus pasiūlymas paprastai subyra ne pasiūlyme, o sąskaitoje, kuri ateina po pusantrų metų. Tarkime, pigi svetainė tiek ir atitarnauja, o paskui ją tenka statyti iš naujo: už antrąjį kūrimą sumokate visą kainą — mūsų WordPress svetainių kūrimas prasideda nuo 2 500 € —, o prie to prisideda turinio perkėlimas, iš naujo rengiami tekstai ir vaizdai bei 301 peradresacijos nuo senųjų URL, be kurių per metus užsiaugintos pozicijos Google rezultatuose dingsta kartu su senąja adresų struktūra. Vadinasi, sutaupyta suma buvo ne nuolaida, o atidėtas mokėjimas su palūkanomis. O jei per tą laiką svetainė dar ir nulaužiama per gatavą temą ar pasenusį įskiepį, atkūrimas pagal mūsų kainoraštį kainuoja 90 € per valandą be PVM, taikant aštuonių valandų minimumą, ir vien tai suėda didžiąją dalį to, kas iš pradžių buvo sutaupyta. Tai nereiškia, kad pigi svetainė visada yra klaidingas pasirinkimas: trims puslapiams, kurių vienintelis uždavinys — parodyti kontaktus ir darbo laiką, gatavas šablonas yra racionalus sprendimas, ir mes tai pasakome. Klaida prasideda ten, kur svetainė yra pardavimo kanalas, bet perkama kaip vizitinė kortelė.

2. Neaiškiai apibrėžti reikalavimai ir tikslai

Antra pagal dažnumą klaida — pradėti projektą neturint aiškiai apibrėžtų reikalavimų, tikslų ir laukiamų rezultatų: verslininkas kreipiasi į kūrėją ir pasako maždaug taip: „man reikia modernios ir profesionalios svetainės“, nesugebėdamas konkrečiai įvardyti, kokių funkcijų svetainei reikia, kas yra tikslinė auditorija, kokius veiksmus lankytojai turėtų atlikti svetainėje ir kaip bus matuojama svetainės sėkmė. Dėl tokio neapibrėžtumo kūrėjas priverstas pats daryti prielaidas apie tai, ko klientas nori, o šios prielaidos neretai pasirodo esančios klaidingos, todėl nusivilia abi pusės ir jau atliktą darbą tenka perdaryti, eikvojant papildomą laiką ir pinigus. Būtent šis neapibrėžtumas yra pagrindinė „apimties išsiplėtimo“ (scope creep) varomoji jėga — reiškinio, kuris paliečia daugiau nei pusę visų šakos projektų ir reiškia, kad projekto eigoje nuolat pridedama naujų funkcijų ir reikalavimų, kurių pradiniame plane nebuvo, o tai padidina išlaidas nuo 10% iki 25% ir neretai gerokai pailgina kūrimo terminus.

Sprendimas — skirti laiko ir pastangų tyrimo etapui (discovery phase) prieš pradedant bet kokius kūrimo darbus: šiame etape apibrėžiami konkretūs verslo tikslai (pavyzdžiui, padidinti užklausų skaičių 30%, sumažinti atmetimo rodiklį žemiau 40%, pasiekti vidutinę sesijos trukmę, viršijančią 3 minutes), sukuriamos naudotojų personos, sudaromi naudotojų kelių žemėlapiai, nustatoma svetainės struktūra ir funkciniai reikalavimai, parengiama detali techninė užduotis, kuri visą projekto laiką tarnauja kaip atskaitos dokumentas. Toks dokumentas apsaugo abi puses: verslininkas žino, ką gaus už savo pinigus, o kūrėjas žino, ko iš jo tikimasi, ir bet kokie pakeitimai, viršijantys dokumente nustatytą apimtį, įforminami kaip papildomi darbai su atskiru biudžetu ir terminais.

3. Dizaino pervertinimas ir techninės pusės nuvertinimas

Trečia klaida, ypač paplitusi tarp verslininkų, — perdėtas dėmesys vizualiniam dizainui visiškai ignoruojant arba nuvertinant techninę pusę: verslininkas renkasi kūrėją remdamasis vien tuo, kaip gražiai atrodo jo darbų portfelyje esančios svetainės, neuždavęs klausimų apie kodo kokybę, svetainės greitį, saugumo praktiką, mastelio keitimo galimybes ar SEO optimizaciją. Vizualinis dizainas ir techninis įgyvendinimas yra dvi skirtingos disciplinos, o graži svetainė, kuri kraunasi dešimt sekundžių, yra pažeidžiama atakų ir nerandama paieškos sistemose, verta gerokai mažiau nei vizualiai paprastesnė svetainė, kuri yra greita, saugi ir gerai optimizuota.

Tyrimai nuosekliai rodo, kad 53 % mobiliųjų įrenginių naudotojų palieka svetainę, jei ji kraunasi ilgiau nei tris sekundes, o vienos sekundės delsa įkeliant puslapį gali pastebimai sumažinti konversijas, nes, kaip rodo Akamai ir SOASTA tyrimas, jau 100 milisekundžių delsa sumažina konversijos rodiklius net 7 % — šie skaičiai reiškia, kad svetainės našumas tiesiogiai veikia Jūsų pajamas, ir joks gražus dizainas to nekompensuos, jei techniniame įgyvendinime padaryta klaidų. Teisingas požiūris — vertinti kūrėją ne tik pagal jo darbų vizualinę išvaizdą, bet ir pagal tai, kaip jis geba paaiškinti savo techninį požiūrį: kokią architektūrą naudoja, kaip užtikrina svetainės greitį, kaip sprendžia saugumo klausimus ir kaip planuoja svetainės mastelio keitimą, jei verslas augs, o reikalavimai keisis.

4. SEO atidėjimas „vėlesniam laikui“

Paieškos sistemų optimizaciją verslininkai labai dažnai laiko kažkuo, ką prie svetainės galima pridėti ją jau sukūrus, panašiai kaip nudažyti sieną pastačius namą, tačiau iš tikrųjų techninis SEO yra fundamentali svetainės architektūros dalis, ir jo įdiegimas jau paleidus svetainę yra gerokai brangesnis, sudėtingesnis ir mažiau veiksmingas nei tada, kai jis įtraukiamas į kūrimo procesą nuo pat pradžių. URL struktūra, puslapių hierarchija, vidinių nuorodų architektūra, antraščių struktūra, struktūrinių duomenų žymėjimas (schema markup), vaizdų optimizavimas, Core Web Vitals metrikos ir naudojimosi mobiliaisiais įrenginiais patirtis — visus šiuos elementus daug lengviau ir pigiau tinkamai įgyvendinti kūrimo procese nei perdaryti jau baigtoje svetainėje.

Google taiko mobiliosios versijos pirmenybinį indeksavimą (mobile-first indexing) — tai reiškia, kad Jūsų svetainės mobilioji versija yra ta, pagal kurią Google vertina ir reitinguoja Jūsų turinį; jei mobilioji patirtis prasta, Jūsų pozicijos nukentės, kad ir kokia gera būtų kompiuterio versija. Mobilioji prekyba, Statista duomenimis, 2024 metais pasiekė maždaug 2,07 trilijono dolerių, o Google duomenys rodo, kad 2015–2017 metais mobiliosios paieškos su pirkimo ketinimu ir fraze „netoliese“ (near me) išaugo daugiau nei penkis kartus — mobilioji optimizacija nėra tiesiog „maloni papildoma galimybė“, o verslo būtinybė, ypač vietos įmonėms, norinčioms pritraukti klientų savo regione. Teisingas požiūris — SEO reikalavimus nurodyti jau pasiūlymo užklausoje (RFP) kaip privalomą kūrimo dalį, o ne kaip atskirą, papildomai apmokamą paslaugą. Konkrečiai tai reiškia, kad kūrėjas nuo pat pradžių turi suplanuoti SEO draugišką URL struktūrą, užtikrinti teisingą antraščių hierarchiją (H1, H2, H3), įdiegti struktūrinius duomenis (schema markup), optimizuoti vaizdus su alt tekstais ir šiuolaikiniais formatais, sukonfigūruoti XML svetainės žemėlapį ir robots.txt failą bei užtikrinti, kad svetainės greitis atitiktų Core Web Vitals standartus — jau baigtoje svetainėje tie patys pakeitimai gali pareikalauti esminio architektūros perdarymo.

5. Turinio rengimo ignoravimas arba atidėjimas paskutinei minutei

Penktoji klaida yra viena dažniausių priežasčių, kodėl svetainių kūrimo projektai vėluoja: verslininkai mano, kad turinys yra kažkas, ką galima „surašyti“ paskutinę minutę, ir visą dėmesį sutelkia į dizainą bei funkcionalumą, o tekstai, vaizdai ir kiti turinio elementai lieka neparengti iki pat projekto pabaigos. Problema ta, kad dizainas kuriamas aplink turinį, o ne atvirkščiai — jei turinys neparuoštas, dizaineris priverstas dirbti su užpildomuoju tekstu (lorem ipsum), o dėl to dizainas neatitinka realaus turinio apimties ir struktūros, ir, kai galiausiai įdedamas tikrasis tekstas, vaizdas gali smarkiai pasikeisti, ir ne į gerąją pusę.

Turinio parengimo vėlavimas yra viena dažniausiai minimų projektų vėlavimo priežasčių šioje srityje, ir tai logiška, nes kokybiško turinio sukūrimas reikalauja laiko — tekstus reikia parašyti, suderinti su įmonės tonu ir žinute, optimizuoti SEO tikslais, o vaizdus reikia parinkti arba sukurti taip, kad jie atitiktų prekės ženklo identitetą ir dizaino reikalavimus. Teisingas požiūris — laikyti turinio rengimą kritiškai svarbiu projekto etapu, turinčiu savo terminus ir atsakingus asmenis, kuris prasideda lygiagrečiai su dizaino darbais ar net prieš juos, o ne papildoma užduotimi, atliekama „kai atsiras laiko“. Jei įmonė neturi vidinių išteklių turiniui parengti, tai turi būti įtraukta į projekto biudžetą kaip atskira eilutė, pasitelkiant profesionalų tekstų kūrėją arba turinio specialistą.

6. Nesuplanuota popardavimo priežiūra

Šešta klaida tiesiogiai susijusi su priežiūros tema, kurią jau nagrinėjome straipsnyje apie nulaužtų svetainių atkūrimą — daugelis verslininkų mano, kad svetainė yra vienkartinis produktas, kuris ją sukūrus tiesiog „veikia“, ir negalvoja apie tai, kas nutiks paleidus svetainę, kai prireiks saugumo atnaujinimų, turinio pakeitimų, klaidų taisymo, našumo optimizavimo ir suderinamumo su naujomis naršyklių versijomis bei įrenginiais užtikrinimo. Toks požiūris yra pavojingas, nes neprižiūrima svetainė yra neapsaugota svetainė — Sucuri duomenimis, daugiau nei pusė nulaužtų CMS svetainių užkrėtimo metu veikė su pasenusia programinės įrangos versija, o plačiai cituojamas Sophos vertinimas, jau daugiau nei dešimties metų senumo, kalba apie maždaug 30 000 naujų svetainių per dieną, kuriose aptinkamas kenkėjiškas kodas.

Priežiūros klausimą reikia spręsti dar projekto planavimo stadijoje, o ne tada, kai svetainė jau paleista, nes tai lemia ir technologijų pasirinkimą (vienas platformas prižiūrėti lengviau nei kitas), ir biudžeto planavimą (priežiūros išlaidos turi būti įtrauktos į bendrą svetainės gyvavimo ciklo biudžetą), ir kūrėjo pasirinkimą (reikia išsiaiškinti, ar kūrėjas teikia ir priežiūros paslaugas bei kokios yra jų sąlygos). Idealiu atveju jau į pagrindinę sutartį įtraukiamas popardavimo palaikymo susitarimas (SLA — Service Level Agreement), kuriame apibrėžiama, kokie priežiūros darbai bus atliekami, kaip dažnai, koks yra reakcijos laikas kilus problemoms ir kiek ši paslauga kainuoja.

7. Domeno ir prieglobos kontrolės perdavimas kūrėjui

Septinta klaida yra viena iš tų, kurios gali sukelti sunkiausių ilgalaikių padarinių, ir vis dėlto ji daroma stebėtinai dažnai — verslininkas leidžia kūrėjui registruoti domeno vardą ir įsigyti prieglobos paslaugą kūrėjo, o ne įmonės vardu, ir taip praranda savo kritiškai svarbaus skaitmeninio turto kontrolę. Jei bendradarbiavimas su kūrėju dėl kokios nors priežasties baigiasi — nesvarbu, ar tai įvyksta draugiškai, ar dėl konflikto — verslininkas gali atsidurti situacijoje, kai negali prieiti prie savo domeno, perkelti savo svetainės į kitą serverį ar net praranda savo domeno vardą, jei kūrėjas nepratęsia registracijos.

Domeno vardas ir prieglobos paskyra yra jūsų verslo skaitmeninis turtas, todėl jie turi priklausyti jums ir būti jūsų kontroliuojami, panašiai kaip jūsų įmonės buveinės adresas ar prekės ženklas — jūs neleistumėte savo buhalteriui registruoti jūsų įmonės buveinės adreso savo vardu, ir lygiai taip pat neturėtumėte leisti kūrėjui kontroliuoti jūsų skaitmeninės tapatybės. Teisingas požiūris — pačiam užregistruoti domeno vardą pas patikimą registratorių, prieglobos paslaugą įsigyti savo įmonės vardu arba nuomotis ją iš partnerio, kuris pareikalavus perduoda konfigūraciją ir duomenis, o kūrėjui suteikti tik techninę prieigą, būtiną svetainei sukurti ir įdiegti, bet ne administracinę šių išteklių kontrolę. Tas pats galioja ir Google Search Console, Google Analytics bei kitoms analitikos ir rinkodaros paskyroms — jos turi būti sukurtos įmonės vardu, o kūrėjui suteikiama prieiga su ribotomis teisėmis.

8. Testavimo ir kokybės užtikrinimo ignoravimas

Aštuntoji klaida susijusi su tuo, kad daugelis verslininkų neskiria pakankamai dėmesio testavimo procesui ir priima svetainę jos nuodugniai nepatikrinę, pasikliaudami kūrėjo patikinimu, kad „viskas veikia“ — nors iš tikrųjų kokybiškas testavimas yra sudėtingas ir daug laiko reikalaujantis procesas, apimantis kur kas daugiau nei paprastą naršymą po puslapius ir kelių mygtukų paspaudimą. Nepakankamas kokybės užtikrinimas yra viena dažniausių priežasčių, kodėl paleistose svetainėse išryškėja klaidų, kurios veikia naudotojų patirtį, konversijas ir net saugumą, o jų taisymas jau baigtoje svetainėje visada kainuoja brangiau ir yra sudėtingesnis, nei būtų buvę aptikti ir pašalinti problemas kūrimo proceso metu.

Testavimas turėtų apimti kelias sritis: funkcinis testavimas tikrina, ar visos svetainės funkcijos veikia teisingai — formos, paieška, navigacija, naudotojų registracija, krepšelio ir atsiskaitymo procesai, turinio filtravimas ir rikiavimas; suderinamumo testavimas tikrina, ar svetainė tinkamai veikia skirtingose naršyklėse (Chrome, Firefox, Safari, Edge), operacinėse sistemose ir įrenginiuose (kompiuteriuose, planšetėse, išmaniuosiuose telefonuose su įvairaus dydžio ekranais); našumo testavimas vertina svetainės įkėlimo greitį, atsako laiką ir elgseną esant apkrovai; saugumo testavimas nustato galimus pažeidžiamumus, pavyzdžiui, SQL injekcijas, XSS atakų galimybes ir netinkamą prieigos kontrolę; o prieinamumo testavimas tikrina, ar svetaine gali naudotis įvairių funkcinių sutrikimų turintys žmonės, kaip numato WCAG standartai.

Teisingas požiūris — jau sutartyje numatyti testavimo etapą su aiškiai apibrėžtais priėmimo kriterijais: tai reiškia, kad dokumentuota, kas tiksliai bus testuojama, kokie rezultatai laikomi priimtinais ir kokia tvarka taikoma, jei testuojant aptinkama problemų. Verslininkui patartina priėmimo testavimą atlikti ir pačiam arba pasitelkus nepriklausomą specialistą, o ne visiškai pasikliauti kūrėjo paties atliktu vertinimu, nes kūrėjas, testuojantis savo paties darbą, yra tarsi studentas, taisantis savo paties egzaminą.

9. Sprendimų priėmimas komitete, kai nėra vieno atsakingo asmens

Devintoji klaida yra organizacinė ir ypač būdinga didesnėms įmonėms bei organizacijoms, kuriose svetainės kūrimo projekte dalyvauja keli sprendimų priėmėjai — rinkodaros skyrius, pardavimų komanda, vadovybė, IT departamentas, o kartais net teisininkai — ir kiekvienas iš jų dalyvauja dizaino bei turinio tvirtinimo procese turėdamas vienodą balso teisę. Toks „dizaino komitete“ principas beveik visada lemia kompromisų kupiną rezultatą, kuris netenkina nė vieno, nes kiekvienas sprendimų priėmėjas stengiasi įsprausti į svetainę savo prioritetus ir pageidavimus, o galutinis rezultatas tampa perkrautas, nenuoseklus ir nesuderintas su verslo tikslais.

Tyrimai ir sektoriaus patirtis nuosekliai rodo, kad projektai, kuriuose yra vienas aiškiai paskirtas sprendimų priėmėjas, turintis įgaliojimus tvirtinti dizainą, turinį ir funkcionalumą, baigiami greičiau, dažniau telpa į biudžetą ir duoda geresnių rezultatų nei tie, kuriuose sprendimus priima grupė. Tai nereiškia, kad kitų dalyvaujančių šalių nuomonė nesvarbi — tai reiškia, kad turi būti aiškus procesas, kuriame visos šalys gali išsakyti savo nuomonę ir pateikti pastabų, tačiau galutinį sprendimą priima vienas žmogus, įgaliotas ir atsakingas už projekto rezultatą. RACI matrica (Responsible, Accountable, Consulted, Informed) yra veiksminga tokio proceso struktūravimo priemonė — ji aiškiai apibrėžia, kas atsakingas už darbo atlikimą, kas yra galutinis sprendimų priėmėjas, su kuo reikia konsultuotis ir kas turi būti informuotas apie priimtus sprendimus.

10. Intelektinės nuosavybės ir sutartinių klausimų ignoravimas

Dešimtoji klaida susijusi su teisine puse, kurią daugelis verslininkų, ypač mažesnių įmonių savininkai, linkę ignoruoti arba laikyti nereikalinga biurokratija — jie pradeda bendradarbiauti su kūrėju be oficialios sutarties, be aiškiai apibrėžtų intelektinės nuosavybės teisių ir be konfidencialumo susitarimo (NDA), o tai gali sukelti rimtų problemų tiek projekto metu, tiek jam pasibaigus. Neturėdamas aiškiai apibrėžtų intelektinės nuosavybės teisių, verslininkas gali atsidurti situacijoje, kai jam faktiškai nepriklauso pirminis kodas, už kurį jis sumokėjo, o kūrėjas gali tą patį kodą panaudoti kitiems klientams ar net atsisakyti perduoti pirminį kodą, jei bendradarbiavimas nutrūksta anksčiau laiko.

Sutartyje turėtų būti aiškiai nustatyta, kad visa kūrimo proceso metu sukurta intelektinė nuosavybė — pirminis kodas, dizaino failai, grafika, duomenų struktūros ir dokumentacija — gavus visą apmokėjimą priklauso užsakovui, o kūrėjas neturi teisės jos naudoti kitiems tikslams be užsakovo sutikimo. Sutartyje taip pat turi būti apibrėžta projekto apimtis, terminai, mokėjimų grafikas (pageidautina susietas su tarpinių etapų įvykdymu, o ne su praėjusiu laiku), garantinis laikotarpis, konfidencialumo nuostatos ir ginčų sprendimo tvarka. Mokėjimų struktūra, susieta su konkrečiais, patvirtintais tarpiniais etapais (milestone-based payments), o ne tiesiog su laikotarpiu, skatina kūrėją laikytis terminų ir užtikrina, kad verslininkas mokėtų tik už faktiškai atliktą darbą, o ne už neapibrėžtas laiko sąnaudas; didesniems ir nestandartiniams projektams tinka ir laiko bei medžiagų modelis su savaitine riba, jei apimtis ir riba nustatytos raštu.

Konfidencialumo sutartis (NDA) ypač svarbi tada, kai kūrimo proceso metu kūrėjui atskleidžiama jautri verslo informacija — klientų duomenys, verslo procesai, kainų politika ar kita konfidenciali informacija, kuri, patekusi konkurentams, gali pakenkti jūsų verslui. Daugeliui verslininkų atrodo, kad NDA yra didelių korporacijų įrankis, tačiau iš tikrųjų ji vienodai svarbi kiekvienai įmonei, kuri dalijasi jautria informacija su išoriniais partneriais. Be to, gerai struktūruota sutartis su aiškiais tarpiniais etapais ir priėmimo kriterijais tarnauja ir kaip projektų valdymo įrankis — ji užtikrina, kad abi šalys sutaria, kas yra daroma, kada tai bus baigta ir kokio rezultato tikimasi kiekviename etape, o tai gerokai sumažina nesusipratimų ir konfliktų riziką projekto eigoje.

Papildomos svetainės kūrimo klaidos, kurias verta paminėti

Nors aprašėme dešimt pagrindinių klaidų, yra dar kelios dažnai daromos spragos, nusipelnančios atskiro paminėjimo, nes jos gali iš esmės paveikti svetainės kūrimo projekto sėkmę. Viena iš jų — per didelis pasikliovimas kūrėjo nuomone visais klausimais, įskaitant verslo strategiją: kūrėjas yra technologijų ekspertas, tačiau jis retai kada supranta jūsų verslo specifiką, tikslinę auditoriją ir rinkos dinamiką taip gerai kaip jūs pats, ir, jei visus sprendimus visiškai perleisite kūrėjui, rizikuojate gauti techniškai gerą, bet verslo požiūriu neveiksmingą svetainę.

Antra dažnai daroma klaida — prieinamumo (accessibility) ignoravimas: daugelis verslininkų net nesuvokia, kad jų svetainė turi būti prieinama žmonėms su negalia ir kad daugelyje jurisdikcijų tai yra įstatymo nustatytas reikalavimas, o ne tiesiog gera praktika. Užtikrinti prieinamumą jau kūrimo proceso metu yra gerokai paprasčiau ir pigiau nei pridėti jį prie jau parengtos svetainės, be to, tai išplečia jūsų potencialią auditoriją, nes maždaug 16 % pasaulio gyventojų — 1,3 milijardo žmonių — gyvena su reikšmingais funkciniais sutrikimais.

Trečia papildoma klaida — analitikos ir konversijų sekimo neįdiegimas: daugelis svetainių paleidžiamos nesukonfigūravus Google Analytics, Google Search Console ar kitų analitikos įrankių, o tai reiškia, kad verslininkas negali įvertinti svetainės efektyvumo, nustatyti problemų ir priimti duomenimis pagrįstų sprendimų dėl tolesnio optimizavimo. Analitikos įdiegimas turi būti įtrauktas į kūrimo projekto apimtį kaip privalomas reikalavimas, o ne kaip kažkas, ką „padarysime vėliau“. Be analitikos duomenų jūs iš esmės veikiate aklai — nežinote, kiek lankytojų pritraukia jūsų svetainė, iš kur jie ateina, kuriuose puslapiuose lankosi, kur jie „pasitraukia“ ir ar jūsų svetainė apskritai atlieka savo verslo funkciją.

Ketvirta paminėjimo verta papildoma klaida — svetainės teisinės atitikties neužtikrinimas: daugelis naujų svetainių paleidžiamos be privatumo politikos, slapukų pranešimo, naudojimo taisyklių ar kitų teisinių dokumentų, kurie yra privalomi pagal BDAR ir kitus taikomus teisės aktus, o šis aplaidumas gali sukelti rimtų teisinių pasekmių, įskaitant baudas iki 20 mln. eurų arba 4 % bendros metinės pasaulinės įmonės apyvartos — atsižvelgiant į tai, kuri suma yra didesnė. Teisinė atitiktis — ne vien formalus reikalavimas: tai ir pasitikėjimo signalas jūsų lankytojams, rodantis, kad rimtai žiūrite į jų duomenų apsaugą ir privatumą, o šiuolaikiniai vartotojai vis dažniau atkreipia dėmesį į tai, kaip įmonės tvarko jų asmens duomenis.