Kujuta ette, et oled saanud kaks pakkumist täpselt sama idee peale. Üks on tuhande euro võrra odavam, teine tundub põhjalikum. Kumba valid? Tõde on see, et neid numbreid ei saa omavahel võrrelda enne, kui oled lasknud mõlemal pakkujal vastata samadele küsimustele. Just siin lähebki veebiarendus sageli rappa: kaks pakkumist võivad tunduda sarnased, aga tegelikult varjavad täiesti erinevat skoopi, omandiküsimusi ja üleandmise korda.
Hea uudis on see, et sa ei pea olema jurist, et enda huve kaitsta. Piisab neljast asjast, mille pead enne allkirja selgeks rääkima. Selles postituses vaatamegi samm-sammult läbi, mida kontrollida: mis on töös sees ja mis väljas, kellele jääb kood, disain ja andmed, millal loetakse töö vastuvõetuks ning mis peab sinuni jõudma üleandmise hetkel. Näitame ka, kuidas panna erinevad pakkumused ühte võrreldavasse kontroll-loendisse, ja toome välja levinumad vead, mida tellijad korduvalt teevad. Need otsused tehakse lepingu sõlmimise hetkel, hiljem on nende muutmine kallis ja tüütu.
Miks kaks pakkumust sama idee peale võivad olla võrreldamatud
Kaks veebiarenduse pakkumust võivad kõrvuti seistes tunduda peaaegu identsed. Üks sisaldab sisu migreerimist ja tehnilist SEO põhja, teine ainult kujundust ja paigaldust. Lõppnumber üksi ei ütle, mida sa tegelikult saad.
Sama kehtib kodulehtede ja e-poodide arenduse ning Magento arenduse puhul. Üks pakkuja eeldab, et sisu ja tooted tulevad sinult, teine on arvestanud nende üleslaadimisega. Just need eeldused viivad pakkumused lahku, isegi kui hind on sama.
Omandus, testimine ja üleandmine otsustatakse lepingu sõlmimise hetkel. Hiljem nende ümberläbirääkimine tähendab enamasti lisakulu, venimist või vaidlust, sest töö on juba tehtud.
Mõtle autopakkumistele: kui ühes on rehvid hinnas ja teises mitte, ei saa võrrelda ainult lõppnumbrit. Arenduses kehtib sama loogika.
Sinu töö ei ole valida ilusaim pakkumus, vaid suruda kõik pakkumused ühele ja samale kontroll-loendile enne allkirja. Abi leiab näiteks artiklist 7 küsimust, mida küsida enne kodulehe pakkuja valimist. Iga klausli juures on omad kontrollpunktid, mida tasub pakkujalt kirjalikult küsida.
Enne pakkumuste küsimist: mis peab sul endal selge olema
Enne kui pakkumusi üldse küsid, pane enda poolel kirja ärieesmärk ja esimese versiooni kohustuslikud funktsioonid. Tee eraldi nimekiri ka sellest, mis jääb teadlikult välja. See hoiab ära skoobi paisumise, kui keegi ütleb hiljem „see on ju elementaarne“.
Määra, kes sinu poolel otsuseid teeb ja kui kiiresti ta kinnitab. Kui otsustaja on puhkusel, seisab arendus, seega peab see olema pakkumuses eeldusena kirjas.
Loetle olemasolevad süsteemid ja kolmanda osapoole API liidestused: ERP, maksed, logistika, uudiskiri, raamatupidamine. Iga integratsioon on skoobi rida, mis peab pakkumuses nähtavale tulema. Millal tasub pöörduda arenduspartneri poole enne integreerimist tuleb kasuks, kui liidestad kolmanda osapoole API-t.
Otsusta ette, kelle nimel on domeen, hosting, analüütika, reklaamikontod ja olemasolev andmestik. Kui need on täna kellegi teise nimel, on see üleandmise risk, mitte pisiasi.
Küsi, mida projekti alguses tehtav analüüs endast kujutab ja kas see on hinnas. BigEye lubab iga projekti alguses põhjalikku analüüsi, seega küsi, millise dokumendi see annab ja kas see on eraldi tasustatud.
Mõtle läbi keeleversioonid, e-poe ligipääsetavusnõuded ja andmekaitse. Need jäävad pakkumusest tihti välja ja tulevad lisakuluna tagasi. Ligipääsetavuse nõuete puhul tasub tutvuda Euroopa ligipääsetavuse aktiga.
Samm 1. Skoop: mis on sees ja mis on väljas
Kui sul on nüüd selge, mida ise tahad, on aeg skoop kirja panna: töövõtuleping on kokkulepe tulemuse kohta ja just skoop ütleb, mis tulemus see on.
Sees (eraldi nimekirjana): lehtede ja mallide arv, e-poe funktsioonid, integratsioonid, olemasoleva sisu migreerimine, tehniline SEO põhi (metaandmed, URL-struktuur, saidikaart), analüütika ülesseadmine ja koolitus.
Väljas (samuti eraldi real, muidu arvab iga pakkuja neist erinevalt): sisutekstide kirjutamine, tootepildid, tõlked, kolmandate osapoolte litsentsitasud, reklaamieelarved ja jooksev hooldus.
Leppige kokku ka revisjonide ringide arv ja see, mis loetakse muudatustaotluseks. Pane kirja lisatöö tunnihind, et skoobist välja minev soov ei muutuks vaidluseks.
Platvorm mõjutab skoopi otseselt. WordPressi koduleht on tavaliselt kitsam ja kiirem alustada, Magento arendus tähendab enamasti suuremat integratsioonide ja hostingunõuete mahtu. Võrdle pakkumusi sama platvormi eeldusel. Kui kaalud WordPressi, vaata enne, millal WordPress ei sobi.
Lisa pakkumusele lisana funktsioonide ja lehtede nimekiri versiooniga. Ilma kirjaliku lisata ei ole skoop lepingu osa ja iga pool mäletab seda erinevalt.
Küsi ka eelduste nimekiri: mida pakkuja eeldab, et sina teed, millal ja mis kujul. Just eeldused eristavad kahte sarnase hinnaga pakkumust.
Kui skoop on kirjas, saab järgmiseks vaadata, kellele jäävad kood, disain ja andmed.
Samm 2. Omandus: kellele jääb kood, disain ja andmed
Skoop on paigas, aga järgmine lõks ootab allkirja juures: kellele jääb see, mille eest maksad. Autoriõiguse seaduse paragrahv 16 järgi kuulub autoriõigus autorile sõltumata selle eseme omandist, milles teos väljendub (Justiitsministeeriumi materjal). Maksmine ise õigusi üle ei anna. Leping peab ütlema, kas õigused antakse üle või antakse litsents.
Justiitsministeeriumi materjal toob selgelt välja autoriõiguse ja asjaomandi eristuse. See on koht, kus tellijad kõige rohkem eksivad: maksad valmis lahenduse eest, kuid koodile õigusi ei pruugi olla. Tarkvaral on ELis omaette kaitse (direktiiv 2009/24/EÜ), seega sõnasta koodi puudutavad tingimused eraldi ja üheselt.
Lepingus täpsusta: kas litsents on ainuõiguslik, millises ulatuses, kas tohid edasi arendada teise partneriga. Vaata üle ka disainifailid, fondid ja fotod, sest nende litsentsid võivad olla eraldi piiratud.
Andmed kuuluvad sulle. Kliendiandmebaas, analüütika, domeen ja hostingukontod olgu sinu nimel; ligipääsud antakse üle üleandmise hetkel. Kui andmebaas jääb pakkuja kontole, on vahetus hiljem valus. Mõtle läbi ka stsenaarium, kus koostöö lõpeb või pakkuja tegevus katkeb: kes pääseb hoidla juurde, kelle nimel on kolmandate osapoolte litsentsid ja kuidas jätkab teine meeskond. Andmevoogude ja ligipääsetavuse hindamisel tasub vaadata Samm 3: Hinda andmevoogude kvaliteeti ja ligipääsetavust.
Kontrolli enne avaldamist autoriõiguse seaduse kehtiv terviktekst ja töösuhtes loodud teoste reeglid, sest sõnastus võib olla uuendatud.
Samm 3. Testimine ja vastuvõtmine: millal on töö tehtud
Kui omandus on paigas, on järgmine küsimus: millal loetakse töö tehtuks? Vastuvõtukriteeriumid pane kirja enne töö algust. See on soovitus, mitte seadusenorm: ilma kirjalike kriteeriumiteta ei ole kummalgi poolel hiljem alust, mille põhjal öelda, kas töö on valmis.
Kokkuleppes peab olema kirjas, kus testitakse (testkeskkond), milliste andmetega ja kes testib. Tavaliselt teeb pakkuja sisemise kontrolli ja sina teed vastuvõtutesti päris kasutajana. Vastuvõtutest katab peamised kasutajateekonnad: ostuprotsess, vormid, maksed, integratsioonid, mobiilivaade ja lehe kiirus. Üleandmise eeldus on, et need teekonnad töötavad päris keskkonnas, mitte ainult arendaja arvutis. Kui testkäigus selgub, et mõni korduv samm käib endiselt käsitsi, viitab see, et keegi meeskonnas ei taha seda tööd teha, ja see protsess tasub automatiseerida.
Tee vahet veal ja muudatussoovil ning leppige kokku vigade raskusastmed ja parandustähtajad. Nii ei muutu kriitiline viga ja ilusam nüanss üheks ja samaks vaidluseks: kui ostukorv katki on, ei ole see maitseküsimus.
Vastuvõtmine toimub kirjaliku protokolliga, millele järgneb garantiiaeg. Kirjuta üles, mida garantii katab ja kui kiiresti reageeritakse, sest see mõjutab sinu esimesi kuid pärast käivitamist. Vaidluse korral on maht, hind ja tähtaeg kergem tõendada siis, kui need on kirjas.
Kui leppisite kokku mõõdetavad sihid, nagu kiirus, turvalisus ja leitavus, märkige need lepingusse üheselt. Ümmargused lubadused ei ole vastuvõtukriteerium, mõõdetav siht on.
Samm 4. Üleandmine: mis peab sinuni jõudma ja millal
Kui vastuvõtmise protokoll on allkirjastatud, algab osa, mille peale paljud tellijad mõtlevad alles siis, kui midagi katki läheb. Üleandmine ei ole üks e-kiri, vaid nimekiri asjadest, mis peavad sinu kätte jõudma.
Koodi hoidla. Sul peab olema ligipääs versioonihaldusele koos kogu ajaloo ja harudega. Kõige kindlam on, kui hoidla kuulub sinu organisatsioonile, mitte pakkuja erakontole; siis ei sõltu ligipääs kunagi ühest inimesest ega ühest e-postist.
Kontod ja ligipääsud. Domeen, DNS, hosting, sisuhalduse administraator, maksekontod, e-post, analüütika, otsingukonsool ja reklaamikontod. Just siin tekib kõige levinum üleandmise auk: kood on käes, aga kontod jäävad pakkuja nimele.
Dokumentatsioon. Arhitektuuri kirjeldus, juurutamisprotsess, keskkondade seadistus ja kolmandate osapoolte litsentside nimekiri koos uuendamise ja jooksvate kuludega. Ilma selleta jääd ühest partnerist sõltuma.
Koolitus ja sisseelamine. Lühike üleandmise sessioon, kus sinu meeskond näeb, kuidas sisu muuta, tellimusi vaadata ja levinumaid probleeme ise lahendada.
Tähtajad ja maksed. Kirjuta lepingusse, millal iga osa liigub, millal toimub koolitus ja kuidas on lõppmakse seotud vastuvõtmise ja üleandmisega, mitte ainult käivitamisega. Kui koostöö kunagi lõpeb, peab olema selge, mis vormingus saad andmed ja sisu eksportida ja mis aja jooksul. Vastasel juhul muutub partneri vahetus ootamatult kalliks.
Üks võrreldav kontroll-loend: kuidas pakkumused kõrvuti panna
Üleandmise nimekiri on olemas, aga võrdlemiseks pressi kõik pakkumused ühte vormi. Tee tabel nelja veeruga: skoop, omandus, testimine, üleandmine. Iga rida vastab kas jah, ei või lühikirjeldusega, ja iga pakkuja täidab sama vormi samade küsimustega. Nii ei jää mõni pakkumus ilusama sõnastuse taha peitu.
Saada küsimused e-kirjaga ja nõua vastuseid kirjalikult. Kirjalik vastus on hiljem lepingu lisa alus, suuline lubadus ei ole. Hea abivahend on Praktiline kontrollnimekiri: mida oma arendajalt nõuda?, millele kannad pakkujate vastused kõrvuti.
Võrdle kogukulu, mitte ainult arendushinda: litsentsid, hosting, hooldus, tulevased muudatused ja sinu meeskonna ajakulu. Odavaim pakkumus on sageli kalleim kolme aasta vaates.
Märgi punased lipud: omanduse klausel puudub, vastuvõtukriteeriume ei ole, ligipääsud jäävad pakkujale või üleandmine lükatakse ebamäärasesse tulevikku.
Ja kõrvuta eeldusi, mitte ainult lubadusi. Kaks pakkumust on võrreldavad alles siis, kui mõlemas on kirjas, mida pakkuja eeldab sinult ja mida ta kohustub ise tegema.
Levinumad vead, mida tellijad teevad
Kui võrdlev tabel on ees, paistavad tüüpvead kohe silma. Neid tasub siiski ette teada, sest igaüks neist maksab hiljem raha või aega.
Eeldus, et maksmine tähendab omandit. Autoriõigus lähtub autorlusest, mitte sellest, kes arve kinni maksis. Kui leping ei ütle, et õigused antakse üle või antakse litsents, jäävad need töövõtjale.
Ainult lõpphinna võrdlemine. Kaks sama hinnaga pakkumust võivad sisaldada täiesti erinevat mahtu. Hind ilma skoobi kirjelduseta ei ütle midagi.
Skoobi avatuks jätmine. "Vaatame siis, kui hakkame pihta" on kindlaim viis, kuidas projekt venib ja eelarve paisub. Sama loogika kehtib väiksemate töölõikude valimisel: kolme kriteeriumiga raamistik aitab otsustada, mida üldse ette võtta.
Vastuvõtukriteeriumide puudumine. Ilma kirjaliku kriteeriumita otsustab töö valmimise üle see, kes kõvemini ütleb. Üks lause lepingus hoiab ära pika vaidluse.
Ligipääsude ja andmete üleandmise edasilükkamine. See on nagu jätaksid korteri võtmed müüja kätte lootuses, et ta need kunagi üle annab.
Kolmandate osapoolte litsentsid. Nende jooksvad kulud ilmnevad alles siis, kui arve saabub ja muudatust on vaja.
Kõik need vead on ennetatavad ühe küsimusega: kas see on kirjas?
Kokkuvõte: neli asja, mis tuleb enne allkirja paika saada
Kui need neli punkti on kirjas, on sul käes midagi, mida saab päriselt võrrelda. Tee endale kontroll-loend ja lase iga pakkuja selle täita.
Skoop. Kirjalik nimekiri sellest, mis on sees ja mis väljas, pluss muudatustaotluse hind. Ilma selleta ei ole pakkumused võrreldavad.
Omandus. Leping ütleb üheselt, kas õigused koodile, disainile ja andmetele lähevad üle või antakse litsentsina. Domeen, hosting ja kontod on sinu nimel.
Testimine. Vastuvõtukriteeriumid ja testitavad kasutajateekonnad on kirjas enne töö algust, mitte pärast esimest viga.
Üleandmine. Hoidla, ligipääsud, dokumentatsioon ja koolitus on seotud tähtaegadega ning lõppmakse on seotud vastuvõtmisega.
Kui soovid oma arendusprojekti mahu, eeldused ja üleandmise enne pakkumuse kinnitamist läbi arutada, kirjuta lauri@bigeye.ee ja lepime kokku tasuta konsultatsiooni.
