Mitä tapahtuu päätöksen ja julkaisun välillä: verkkosivuprojektin vaiheet

Sopimus on allekirjoitettu, ennakkomaksu on maksettu, ja sitten tulee hiljaisuus. Yritys odottaa, milloin verkkosivusto ilmestyy, kehittäjä odottaa tekstejä ja valokuvia, eikä kumpikaan ajattele odottavansa juuri samaa viikkoa, joten kuukauden kuluttua molemmat osapuolet ovat tyytymättömiä eikä kumpikaan ole tehnyt mitään väärin; kukaan ei vain ollut kirjannut, kuka toimittaa mitä ja mihin päivään mennessä.

Tämä artikkeli kertoo, mitä tapahtuu päätöksen ja julkaisun välillä, ja ennen kaikkea työn jaosta kahden osapuolen kesken, koska juuri se ratkaisee aikataulun paljon useammin kuin toteutuksen nopeus tai valittu teknologia. Tilaajien virheistä olemme kirjoittaneet erikseen artikkelissa kymmenestä virheestä verkkosivujen tilaamisessa, emmekä toista niitä tässä. Tässä ei myöskään ole hintoja eikä vertailua itse tekemisen ja tilaamisen välillä, koska molemmat ovat toisten artikkeleiden aiheita, ja kyse on vain järjestyksestä ja siitä, mitä kussakin vaiheessa on valmisteltava.

Kartoitus ei ole rakentamisen alku

Lähes jokainen toteutus alkaa vaiheesta, jota kutsutaan kartoitukseksi tai selvitykseksi, ja juuri tämä vaihe ymmärretään useimmin väärin, koska tilaaja pitää sitä muodollisuutena ennen varsinaista työtä. Nielsen Norman Group, joka käyttää käsitettä ammatillisesti, määrittelee sen valmisteluvaiheeksi, jossa tutkitaan itse ongelmaa ja sen kontekstia, muotoillaan, mikä on ratkaistavissa, ja kootaan riittävästi näyttöä, jotta tiedetään, mitä tehdä seuraavaksi, ja korostaa nimenomaan, että kartoituksessa ei testata ratkaisuja.

Julkisella sektorilla tämä ajatus on formalisoitu vielä tiukemmin, koska Britannian hallituksen digitaalisten palvelujen käsikirja erottaa viisi vaihetta, eli kartoituksen, alfan, betan, tuotantokäytön ja käytöstä poistamisen, ja kartoituksesta siellä sanotaan yksinkertaisesti: tässä vaiheessa palvelua ei aleta rakentaa. Vaiheen lopussa tiimi päättää, jatketaanko vai pysähdytäänkö, eikä käsikirja itse aseta määräaikaa, vaikka se toteaa, että käytännössä tämä vaihe kestää yleensä neljästä kahdeksaan viikkoa.

Tässä on heti tehtävä varaus, koska muuten syntyy väärä kuva: mainittu käsikirja kuvaa valtion digitaalisen palvelun elinkaarta, ei kymmenen sivun yrityssivustoa, ja sen aikataulujen siirtäminen tavalliseen toteutusprojektiin olisi harhaanjohtavaa. Arvokasta siinä on periaate, ei kalenteri: ennen rakentamista on vaihe, jonka tavoite on ymmärtää tehtävä, ja tämän vaiheen tulos voi olla myös päätös olla rakentamatta lainkaan.

Käytännön hankkeessa tämä vaihe ilmenee yleensä keskusteluna prosesseista, käyttäjärooleista ja laajuudesta, ja sen tulos on kirjallinen suunnitelma, ei suunnitteluluonnos, vaikka tilaaja usein haluaisi nähdä juuri jälkimmäisen. Tilaajalle tästä seuraa kaksi suoraa seurausta, ja ensimmäinen on se, että ilman kirjallista kartoituksen tulosta myöhemmin ei yksinkertaisesti ole mihin verrata sitä, mitä rakennettiin, joten riita laajuudesta jää ilman näyttöä kummallekaan osapuolelle. Toinen on se, että juuri tässä vaiheessa mielen muuttaminen on halpaa, kun taas rakentamisen alettua jokainen muutos maksaa myös sen, mikä on jo rakennettu ja mikä joudutaan tekemään uudelleen.

Prototyyppi on halvin paikka muuttaa mieltä

Suunnitelman ja rakentamisen välissä on vaihe, jota tilaajat joskus pitävät turhana kuluna, ja se on juuri se vaihe, joka useimmin säästää rahaa. Prototyyppi on sivuston klikattava versio ilman varsinaista koodia, jossa voi kulkea keskeiset polut läpi ja nähdä, mistä jotakin puuttuu, ja sen ainoa tavoite on antaa muuttaa mieltä silloin, kun mielen muuttaminen on vielä halpaa.

Britannian hallituksen käsikirja sanoo tämän ajatuksen säälimättä, kun se kirjoittaa alfavaiheesta, että on varauduttava siihen, että kaikki tässä vaiheessa kirjoitettu koodi ja suuri osa testatuista ideoista heitetään vaiheen lopussa pois, eikä se ole ristiriidassa hyvän työn kanssa vaan sen tarkoitus: prototyypin heittäminen pois on halpaa, valmiin järjestelmän heittäminen pois ei ole. Yrityssivuston mittakaavassa sama periaate toimii pienemmässä laajuudessa, ja juuri siksi me valmistelemme prototyypin ennen ensimmäistä tuotantokoodin riviä.

Tilaajalle tästä seuraa käytännön vaatimus, joka kannattaa sanoa ääneen: prototyypin hyväksyminen ei ole muodollinen rastin laittaminen, vaan ainoa kerta, jolloin muutokset maksavat vain aikaa, joten juuri siinä hetkessä kannattaa kutsua mukaan ne ihmiset, jotka myöhemmin sanovat, ettei heiltä kysytty mitään. Prototyypin hyväksymisen jälkeen jokainen sellainen keskustelu maksaa jo rakennetun.

Toinen, mikä tässä vaiheessa kannattaa, on sisältö luonnoksena, koska täytetekstillä varustetun prototyypin voi hyväksyä helposti ja huomata sitten, etteivät oikeat tekstit mahdu tai että osio, jolle oli varattu yksi kappale, tarvitseekin kolme. Jos tekstit eivät ole vielä valmiit, prototyyppiin kannattaa laittaa ainakin suurin piirtein oikean pituisia luonnoksia, koska pituus muuttaa asettelua enemmän kuin mikään väri.

Suurin osa odottamisesta tapahtuu tilaajan puolella

Hankkeen aikataulun ratkaisee useimmin se, kuinka nopeasti tilaaja toimittaa sisällön, ei toteutuksen nopeus, ja meidän kokemuksessamme se on yleisin viivästyksen syy. Alalta ei ole riippumatonta tutkimusta, jolla olisi menetelmä ja päiväys, joten sanomme tämän omana kokemuksenamme emmekä teeskentele, että sen takana olisi prosentteja.

Tässä kannattaa tehdä vielä yksi varaus, koska muuten tämä jakso kuulostaisi syyn siirtämiseltä: julkisella sektorilla sisällöntuotanto on erillinen ammatti ja tiimin rooli, ja hallituksen käsikirjassa sisällönsuunnittelija on lueteltu tarvittavien taitojen joukossa, mutta siitä ei seuraa, että tavallisessa toteutusprojektissa tekstit kirjoittaisi kehittäjä. Kuka ne kirjoittaa, on sopimuskysymys, ja ainoa väärä vastaus on se, ettei kukaan ole selvittänyt sitä ennen työn alkua.

Tilaajan puolella on yleensä viisi toimitusta, ja kullekin niistä kannattaa panna konkreettinen päivä jo sopimukseen, ei jättää sitä keskustelun tasolle. Ensimmäinen on tekstit, ja ne ovat kaikista raskain, koska niitä ei voi kirjoittaa yhdessä illassa ja niitä kirjoittaa yleensä ihminen, jolle kirjoittaminen ei ole perustyötä ja jolle se on mahdutettava muiden tehtävien väliin. Toinen on valokuvat ja logot vektorimuodossa, kolmas on pääsyt olemassa oleviin järjestelmiin, jos niistä on siirrettävä jotakin, neljäs on hyväksynnät määrätyissä hankkeen kohdissa, ja viides, joka ei ole asiakirja vaan ihminen, on yksi hyväksyjä, joka saa yrityksen nimissä sanoa kyllä.

Tämä viides puuttuu useimmin, ja sen puute maksaa enemmän kuin mikään tekninen mutkikkuus: hanke, jossa hyväksynnän antaa komitea, venyy ei siksi, että joku työskentelisi huonosti, vaan siksi, että jokainen hyväksyntä vaatii kokouksen, kokoukset ovat joka toinen viikko, ja niiden välillä työ vain seisoo. Jos yrityksessä on useita sidosryhmiä, oikea ratkaisu ei ole yrittää sulkea niitä ulos, vaan sopia, kuka heistä on lopullinen päättäjä ja missä määräajassa vastausta odotetaan.

Suomessa ei ole säännöstä, joka nimeäisi viraston päällikön virallisen verkkosivuston sisällöstä vastaavaksi, eikä sellainen sääntö sitoisi yksityistä yritystä muutenkaan. Ajatus on silti sama ja se kannattaa ottaa vapaaehtoisesti: sisällön vastuu kuuluu tilaajalle, ja se on pantava nimetylle ihmiselle.

Kuvat ovat oikeuskysymys, ei tiedostokysymys

Valokuvat ovat paikka, jossa tilaajat toimivat parhain aikein ja silti luovat riskin, koska ajatellaan, että tiedosto, joka on tietokoneella, on myös tiedosto, jota saa käyttää; tekijänoikeuslaissa valokuva on suojattu teos, tekijänoikeus syntyy teoksen luomishetkellä ilman rekisteröintiä, ja tekijä on aina se ihminen, joka kuvan otti.

Siitä seuraa johtopäätös, joka yllättää lähes jokaisen yrityksen: maksu kuvauksesta ei itsessään merkitse, että tilaaja olisi saanut tekijänoikeuden. Valokuvaaja jää tekijäksi, moraaliset oikeudet, mukaan lukien oikeus tulla nimetyksi, jäävät tekijälle, ja taloudelliset oikeudet siirtyvät vain tekijänoikeuslisenssillä tai luovutussopimuksella, ja yritykselle, joka aikoo käyttää valokuvia verkkosivustolla, sosiaalisessa mediassa ja painotuotteissa, se merkitsee, että lisenssissä on lueteltava juuri nämä käyttötavat.

Kuvapankkien kanssa on juuri samoin, vain siellä ehdot on kirjoitettu selvästi ja julkisesti, joten ne voi lukea ennen ostamista: Shutterstockin vakiolisenssi antaa ei-yksinomaisen ja siirtokelvottoman oikeuden käyttää kuvaa, myös verkkosivustoilla, ja samalla sivulla todetaan, ettei asiakas saa omistusoikeutta eikä yksinoikeuksia. Siinä on myös rajoituksia, joita rikotaan vahingossa: kuvaa ei saa luovuttaa eteenpäin, sitä ei saa käyttää logona tai tavaramerkkinä, eikä kuvia, jotka on merkitty vain toimitukselliseen käyttöön, saa käyttää kaupallisesti. Yritys, joka on ostanut vakiolisenssin, on saanut oikeuden käyttää kuvaa sivustolla, ei tiedostoa, jonka voisi luovuttaa kehittäjälle omana omaisuutenaan.

On vielä yksi tapaus, joka ymmärretään lähes aina väärin. Tekijänoikeuslain 25 a § sallii julkiselle paikalle pysyvästi sijoitetun taideteoksen kuvaamisen, mutta jos teos on kuvan pääaihe, kuvaa ei saa käyttää ansiotarkoituksessa; rakennuksen saa sen sijaan kuvata vapaasti. Yrityksen verkkosivusto on kaupallinen käyttö, joten veistos tai muu taideteos pääaiheena tarvitsee yhä luvan, kun taas toisen rakennuksen julkisivusta otettu kuva 25 a §:n 4 momentin mukaan ei.

Lopuksi, ihmiset kuvissa ovat henkilötietokysymys, ei vain kohteliaisuuskysymys: tunnistettava valokuva on henkilötieto, ja yleisen tietosuoja-asetuksen mukaan käsittelylle tarvitaan oikeusperuste, joka voi olla suostumus tai sopimus, ja suostumuksen on oltava vapaaehtoinen, yksilöity, tietoinen ja yksiselitteinen. Tärkein käytännön johtopäätös on se, että suostumuksen voi peruuttaa, ja peruuttamisen jälkeen kuvat on poistettava julkisesta ympäristöstä, joten tiimivalokuvat verkkosivustolla on järjestettävä niin, ettei lähtevästä työntekijästä tule ongelmaa.

Kehitysympäristö ja virhe, joka tehdään hyvää tarkoittaen

Ennen julkaisua työ tapahtuu erillisessä ympäristössä, ja se on tarpeen yksinkertaisesta syystä: tilaajan on nähtävä oikea sivu oikeassa selaimessa, ei kuvaa suunnittelutyökalusta, ja virheet on saatava kiinni paikassa, jossa asiakkaat eivät niitä näe. Kysymys on vain siitä, miten tämä ympäristö suljetaan, ja juuri tässä tehdään virhe, joka näyttää oikealta.

Yleinen ratkaisu on kirjoittaa kielto robots.txt-tiedostoon, eikä se tee sitä, mitä ihmiset luulevat, koska Google kirjoittaa dokumentaatiossaan juuri tämän: tiedosto kertoo hakuroboteille, mille osoitteille ne saavat mennä, ja se palvelee pääasiassa sitä, ettei sivustoa kuormiteta pyynnöillä, mutta se ei ole mekanismi, jolla sivu pidetään Googlen ulkopuolella. Jotta sivu ei näkyisi hakutuloksissa, on käytettävä noindex-ohjetta tai suojattava ympäristö salasanalla.

Seuraa yksityiskohta, jonka takia molemmat menetelmät yhdessä toimivat huonommin kuin kumpikin erikseen. Noindex-ohje toimii vain, jos hakurobotti pääsee sivulle, koska sen on luettava ohje; jos sivu on kielletty robots.txt-tiedostossa, robotti ei koskaan näe tätä ohjetta, ja sivu voi silti näkyä tuloksissa, esimerkiksi jos siihen johtaa linkkejä muualta; lisäksi Google ei tue noindex-ohjetta robots.txt-tiedostossa lainkaan.

On myös toinen syy, miksi tämä ei ole teoreettinen ongelma, nimittäin jos kehitysympäristö sisältää saman sisällön kuin valmis sivusto, hakukone voi pitää juuri sitä pääversiona ja näyttää sen tuloksissa sivustosi sijasta, mikä merkitsee, että kävijä päätyy keskeneräiselle sivulle testisaineistolla. Tämä virhe on vaikea huomata, koska itse sivusto toimii moitteettomasti ja ongelma näkyy vain hakutuloksissa.

Käytännön vastaus on siksi yksinkertainen, ja se kannattaa vaatia suoraan: kehitysympäristö suojataan salasanalla. Se on ainoa ratkaisu, joka hakurobottien käyttäytymisestä riippumatta varmistaa, ettei keskeneräinen sivusto näy missään, ja samalla se poistaa toisen riskin, jota ajatellaan harvemmin, nimittäin sen, että samalla sisällöllä oleva kehitysympäristö voidaan pitää pääversiona ja se alkaa kilpailla oikean sivuston kanssa.

Mitkä valinnat maksavat eniten julkaisun jälkeen

Suurin osa verkkosivuhankkeen päätöksistä on muutettavissa myös julkaisun jälkeen, ja se kannattaa sanoa selvästi, koska tilaajat usein murehtivat juuri niistä asioista, joita myöhemmin muutetaan helpoiten. Värit, asettelu, sivupohja, tekstit ja jopa sivujen paikka valikossa ovat muutettavissa käytännössä milloin tahansa, ja se maksaa vain työtunteja, ei uudelleenrakentamista, mutta kaksi asiaa on silti toisenlaisia, ja juuri niistä kannattaa ajatella ennen julkaisua, kun muutos ei vielä maksa mitään.

Ensimmäinen on osoiterakenne, ja siitä tulee päätös juuri siinä hetkessä, kun sivut on indeksoitu ja niihin johtaa ulkopuolisia linkkejä, koska siitä hetkestä osoitteiden vaihto ei ole enää visuaalinen valinta vaan siirto, jota Google kuvaa erillisenä menettelynä omine vaatimuksineen. On käytettävä palvelimen pysyviä uudelleenohjauksia ja ne on säilytettävä vähintään vuoden; Google myös varoittaa, ettei samalla kertaa pidä vaihtaa sekä osoitteita, sisällönhallintajärjestelmää että asettelua, ja tavalliselle yrityssivustolle se suosittaa siirtämään kaikki osoitteet yhdellä kertaa, ei osissa, ja samassa kohdassa on hyödyllinen lisäys, joka vähentää pelkoa: pysyvät uudelleenohjaukset eivät itsessään vie sivun painoarvoa, vaikka sijoitukset hakutuloksissa voivat hetken vaihdella.

Toinen on itse verkkotunnus, koska verkkotunnuksen vaihto on sama siirto kaikkine vaatimuksineen, vain suuremmassa mittakaavassa, ja siihen liittyy kaikki, mikä on jo painettu käyntikortteihin ja kirjelomakkeisiin. Siitä, kenen nimiin verkkotunnus rekisteröidään, olemme kirjoittaneet artikkelissa kymmenestä virheestä verkkosivujen tilaamisessa, emmekä toista sitä tässä; tässä kannattaa vain sanoa, että verkkotunnuksen valinta on yksi harvoja päätöksiä, joiden muuttaminen myöhemmin maksaa enemmän kuin sen tekeminen heti oikein.

On yksi menettelyn yksityiskohta, joka kannattaa tuntea, jotta sitä ei vaadita turhaan: osoitteenmuutosilmoitus hakukoneen työkaluissa jätetään vain, jos vaihtuu verkkotunnus tai aliverkkotunnus; siirtymään suojaamattomasta suojattuun yhteyteen tai valintaan osoitteen välillä, jossa on etuliite tai ei, samassa verkkotunnuksessa sitä ei ole tarkoitettu, ja siinä riittävät oikeat uudelleenohjaukset. Yritykselle se merkitsee, että suurin osa muutoksista hoidetaan palvelimella, ei jossakin lomakkeessa.

Käytännössä tästä seuraa yksi suositus ennen julkaisua: jos vanha sivusto on jo olemassa ja sillä on kävijöitä hakukoneista, osoiteluettelo uudelleenohjauksineen uusiin osoitteisiin on valmisteltava ennen julkaisua, ei sen jälkeen, kun joku huomaa pudonneet käynnit. Tämä luettelo on myös yksi niistä töistä, jonka tilaaja voi valmistella itse, ja joka, jos kukaan ei sitä valmistele, muuttuu julkaisun jälkeen viikon etsintätyöksi.

Saavutettavuus: kenelle se on velvollisuus ja kenelle ei

Julkisen sektorin viranomaisille saavutettavuus on ollut velvollisuus jo useita vuosia; yksityiselle yritykselle vain silloin, jos se tarjoaa laissa lueteltua palvelua, useimmin verkkokauppaa, eikä ole mikroyritys. Informatiivinen sivusto, joka ei myy mitään, ei kuulu luetteloon. Markkinoilla nämä kaksi säädöstä sekoitetaan usein, ja se on virhe, joka maksaa.

Ensimmäinen koskee julkista sektoria, ja se on ollut voimassa jo useita vuosia, joten viranomaisille se ei ole uutinen. Euroopan unionin direktiivin julkisen sektorin verkkosivustojen saavutettavuudesta panee Suomessa täytäntöön laki digitaalisten palvelujen tarjoamisesta, joka vaatii noudattamaan neljää periaatetta, eli havaittavuutta, hallittavuutta, ymmärrettävyyttä ja toimintavarmuutta, sekä julkaisemaan erillisen saavutettavuusselosteen. Tämä sääntely sitoo viranomaisia eikä koske tavallista yksityistä yritystä, vaikka markkinoilla sitä joskus tarjotaan yleisenä vaatimuksena.

Toinen on uudempi, ja juuri se synnyttää suurimman osan väärinkäsityksistä, koska sen soveltamisen ajankohta on kerrottu laajasti, mutta soveltamisala ei: Euroopan esteettömyysdirektiivin panee Suomessa täytäntöön laki eräiden tuotteiden esteettömyysvaatimuksista sekä digipalvelulakiin lisätty 3 a luku, jota sovelletaan 28. kesäkuuta 2025 alkaen. Se ei merkitse, että tuosta päivästä lähtien jokaisen yrityksen verkkosivuston pitäisi täyttää saavutettavuusstandardi, ja juuri tämä liian laaja väite toistuu markkinoilla useimmin, joskus yhdessä tarjouksen kanssa korjata se.

Lakia sovelletaan tiettyyn palveluluetteloon, ei mihin tahansa sivustoon, ja siihen kuuluvat henkilöliikennepalvelujen, sähkökirjojen ja verkkokauppojen palvelut, luetellut kuluttajien rahoituspalvelut sekä audiovisuaalisiin sisältöpalveluihin pääsyn tarjoavat palvelut ja viestintäpalvelut. Verkkokaupan palvelu on digipalvelulaissa digitaalinen palvelu, jossa voidaan tehdä etämyyntisopimus. Yrityksen informatiivinen sivusto, joka ei myy mitään eikä ole pankki, liikenneoperaattori tai kirja-alusta, ei kuulu tähän luetteloon.

On myös poikkeus pienille yrityksille, ja se on muotoiltava täsmälleen, koska se kerrotaan usein liian laajasti. Yritys, jonka palveluksessa on alle kymmenen työntekijää ja jonka vuosittainen liikevaihto on enintään kaksi miljoonaa euroa tai jonka vuosittainen taseen loppusumma on enintään kaksi miljoonaa euroa ja joka tarjoaa lain alaan kuuluvaa palvelua, on vapautettu palvelujen saavutettavuusvaatimuksista. Poikkeus koskee palveluja; tuotteisiin liittyvät velvollisuudet ovat mikroyrityksille kevyempiä, mutta eivät kumottuja, joten lause, että mikroyritykset on vapautettu laista, ei ole oikein.

Käytännön johtopäätös tilaajalle on lyhyt: jos rakennat verkkokauppaa etkä ole mikroyritys, saavutettavuusvaatimukset on kirjoitettava jo vaatimusmäärittelyyn, koska myöhemmin ne merkitsevät uudelleentyöstöä. Jos rakennat informatiivista sivustoa, juridista velvollisuutta todennäköisesti ei ole, mutta se on silti peruste sille, että sivu on käytettävissä näppäimistöllä ja luettavissa ruudunlukuohjelmalla, koska osa asiakkaistasi käyttää niitä laista riippumatta.

Kuinka kauan tämä kaikki kestää

Aikataulun kysymys on se, johon tilaaja haluaa vastauksen ensin, ja se on myös se, johon rehellisen vastauksen antaminen on vaikeinta. Alalla julkaistut ajat tulevat lähes aina kehittäjien omilta sivuilta, joissa ne palvelevat lupauksena nopeudesta, joten niitä ei voi käyttää riippumattomana tietopisteenä, emmekä löytäneet riippumatonta tutkimusta, jolla olisi menetelmä.

Siksi on oikeampaa puhua siitä, mikä aikataulun ratkaisee, kuin etsiä keskilukua, joka ei silti sovi yhdellekään konkreettiselle hankkeelle: aikataulun ratkaisevat laajuus, hyväksyntöjen nopeus ja sisällön valmius, ja kahdessa jälkimmäisessä näistä kolmesta ratkaiseva vaikutus on tilaajan puolella. Hanke, jossa tekstit ovat valmiit ennen alkua ja päätökset tekee yksi ihminen, etenee huomattavasti nopeammin kuin saman laajuinen hanke ilman näitä kahta ehtoa, ja se on ero, joka voidaan mitata viikkoina.

Oma julkaistu aikamme WordPress-toteutuksen sivulla on neljästä kymmeneen viikkoa, ja se koskee tavallista yrityssivustoa, kun taas mutkikkaammille hankkeille se on pidempi, ja verkkokaupalle vielä pidempi, mutta konkreettiselle hankkeelle ainoa hyödyllinen aika on se, joka seuraa laajuudesta, ei keskiluvusta.

On vielä yksi tapa katsoa tätä kysymystä, ja se on tilaajalle yleensä hyödyllisempi kuin mikään luku: kysy kehittäjältä ei sitä, kuinka kauan tämä kestää, vaan mitkä viikot riippuvat sinusta ja mitkä hänestä. Vastaus tähän kysymykseen on tarkistettavissa, ja se näyttää heti, kuinka suuren osan aikataulusta itse hallitset.

Ja vielä yksi asia, joka vaikuttaa aikatauluun enemmän kuin näyttää, on laajuuden kasvu työn kuluessa: jokainen uusi ehdotus on erikseen pieni ja perusteltu, mutta yhdessä ne siirtävät luovutuspäivää, ja se tapahtuu huomaamatta, koska yksikään niistä ei koskaan näytä päätökseltä pidentää hanketta. Ainoa, mikä sitä vastaan auttaa, on sopimus siitä, että alkuperäisen laajuuden ulkopuoliset muutokset kirjataan erikseen yhdessä niiden vaikutuksen kanssa aikatauluun, ei sisällytetä vaikenemalla.

Mistä sopia, ennen kuin työ alkaa

Ennen ensimmäistä laskuriviä kannattaa puhua ja kirjata sisältöaikataulu päivämäärineen: kuka kirjoittaa tekstit, mihin päivään mennessä ne ovat kehittäjän käsissä ja mitä tapahtuu, jos ne myöhästyvät, koska ilman tätä kohtaa viivästys näyttää aina kehittäjän syyltä.

Toinen on kuvien alkuperä ja oikeudet, eli mistä valokuvat tulevat, millainen lisenssi niillä on, onko lisenssissä mainittu käyttö juuri sivustolla ja ovatko kuvissa olevat ihmiset antaneet suostumuksen, jonka he voivat myöhemmin peruuttaa. Kolmas on yksi hyväksyjä etu- ja sukunimellä sekä sopimus siitä, missä työpäivissä vastausta hyväksyntäpyyntöön odotetaan, koska ilman määräaikaa hyväksyntä ei ole suunniteltavissa oleva suure.

Neljäs on kehitysympäristö, joka on suojattu salasanalla, ei kiellolla robots.txt-tiedostossa, ja viides on uudelleenohjausluettelo vanhoista osoitteista uusiin, jos vanha sivusto on jo olemassa ja sillä on kävijöitä. Kuudes on kysymys saavutettavuudesta, johon vastaus riippuu siitä, mitä sivustosi tekee, ja jonka on paljon halvempaa kysyä vaatimusmäärittelyä kirjoitettaessa kuin luovutuksen jälkeen.

Tämä luettelo kannattaa käydä yhdessä keskustelussa, ei osissa, koska juuri yhdessä se näyttää, kuinka suuri osa hankkeesta riippuu tilaajasta, ja se on yleensä suurempi kuin tilaaja odotti. Yksikään näistä vaatimuksista ei ole kallis, eikä yksikään niistä vaadi teknistä osaamista; ne vaativat vain sen, että joku esittää ne ennen työn alkua.

Ja seitsemäs, joka ei ole tekninen mutta ratkaisee enemmän kuin muut kuusi: sopimus siitä, mikä on pienin laajuus, jolla sivuston voi julkaista. Hanke, jossa julkaisu tapahtuu vasta, kun kaikki on valmista, jää usein julkaisematta lainkaan, kun taas hanke, jolla on selvä minimilaajuus, julkaistaan ajallaan ja kasvaa sen jälkeen. Jos haluat, että käymme tämän keskustelun kanssasi, ota yhteyttä.