2. Projektiaikataulu

Että langat pysyvät projektipäällikön käsissä ja sivusto valmistuu aikataulun mukaisesti on kaikkien sivuston tekemiseen osallistuvien käytävä yhdessä ainakin yksi palaveri, jossa sivustoprojektin aikataulu käydään läpi. Käytännössä tähän on kaksi tapaa – lopusta alkuun tai alusta loppuun. Itse pidän lopusta alkuun suunnittelemisesta, jossa määritetään ensin, milloin sivusto julkaistaan ja sen jälkeen lasketaan aikaa taaksepäin ja arvioidaan kuhunkin vaiheeseen kuluva aika. Alusta loppuun aikataulutettaessa taas lasketaan kauanko jokaiseen vaiheeseen kuluu aikaa ja määritetään mahdollinen julkaisupäivä sen mukaan.

Tässä työssä on projektipäällikön rooli todella tärkeä. Lisäksi kaikkien muiden toimijoiden on pystyttävä melko suurella varmuudella määrittämään, kuinka kauan heidän työhönsä tulee kulumaan. Projektipäällikön tehtävä on myös päättää, yhdessä tilaavan asiakkaan kanssa, mitkä ominaisuudet ovat pakollisia ja mitkä voidaan tarvittaessa jättää tehtäväksi julkaisupäivän jälkeen. Tärkeintä on kuitenkin se, että kun julkaisupäivä on lyöty lukkoon, siitä ei ilman erityisen painavaa syytä lipsuta, paitsi taaksepäin 😉

Alla olevassa listauksessa on käytetty rooleja, jotka on selitetty tarkemmin artikkelissa Kuinka sivustoprojekti organisoidaan osa 1. – Roolit

Tämä järjestys ei perustu mihinkään varsinaiseen metodiin vaan se on muotoutunut Sivustonikkarin projekteista saadun käytännön kokemuksen pohjalta.

I – Aloituspalaveri

Aloituspalaverissa päätetään julkaisupäivä, sovitaan kuka toimii projektipäällikkönä, kuka on sisällöntuottaja, kenen vastuulla on ulkoasun suunnittelu, kuka vastaa teknisestä toteutuksesta ja mistä tai keneltä hankitaan palvelintila. Tämän jälkeen aletaan pohtia sivuston toiminnallisuuksia ja ominaisuuksia. Tarvitaanko esimerkiksi laskureita, vimpaimia, erikoistoimintoja ja muuta sellaista, johon tekninen toteuttaja pääsee kertomaan, mikä on mahdollista ja mikä ei.

Tässä kohtaa on projektipäällikön tärkeää saada kaikilta osapuolilta sitoumus siihen, että sovittuun aikatauluun sitoudutaan. Aloituspalaverissa päätetään myös, millä tavoin ja kuinka usein edistymisestä raportoidaan. Varsinkin pienemmissä, nopeissa projekteissa kannattaa välttää liiallista ja liian formaalia raportointia. Itse olen kokenut parhaaksi menetelmäksi sen, että projektipäällikkö joko jonkin työkalun avulla tai puhelimen, sähköpostin ja pikaviestipalvelujen kautta välittää korjauspyyntöjä ja muutostarpeita. Pitää myös sopia kuka on vastuussa testaamisesta ja varmistaa, että testaamiseen sitoutuneet henkilöt ymmärtävät, mikä on uuden toiminnallisuuden ja virheen välinen ero.

II – Toiminnallisuudet ja ominaisuudet listattu

Tässä vaiheessa on luotu listaus, josta löytyvät ensinnäkin sivuston perusominaisuudet ja toiminnallisuudet, sekä mahdollisesti niiden toteuttamisjärjestys. Käytännössä kaikki sellainen, jota ei tällä listalla ole, ei tule toteutukseen ennen julkaisua, jos kyseessä ei ole aivan välttämätön juttu. Tässä tapauksessa projektipäällikön on saatava kaikki ymmärtämään, että lisäominaisuudet merkitsevät lisäkustannuksia ja yleensä aina myös julkaisupäivän siirtymistä.

Yleensä, varsinkin pienemmissä projekteissa tämä vaihe tapahtuu aloituspalaverissa tai sen jälkeen sähköpostilla tai muulla sovitulla viestintävälineellä. Tälle vaiheelle on annettava selkeä takaraja, jonka jälkeen uusia ominaisuuksia ei enää oteta mukaan. Tottakai käytännössä pieniä muutoksia tulee ja siksi tämän listauksen olisikin oltava mahdollisimman tarkka.

III – Ulkoasu lyöty lukkoon

Kun kaikki toiminnallisuudet on tiedossa, voidaan alkaa suunnitella ulkoasua. On erittäin tärkeää, että ulkoasulle on olemassa tarkka deadline, koska käytännössä sivuston koodaaminen, eli tekninen toteutus ei voi alkaa ennen kuin ulkoasu on tiedossa. Graafikko tai muu ulkoasun suunnittelija määrittelee, kaunko kuluu siihen, että ulkoasu on valmis kommentoitavaksi.

Ensimmäisen version jälkeen käydään pari kommentointikierrosta, joissa kaikki projektiin osallistuvat antavat panoksensa ja ulkoasun suunnittelija tekee muutokset. Siksi on tärkeää määrittää myös iteraatioille aikataulunsa, että ulkoasu saadaan ajoissa valmiiksi ja voidaan siirtyä tuotantoon. Joitakin pieniä muutoksia voi tulla sivuston responsiivisuuden takaamiseksi ja testausvaiheessa huomatuista ongelmista, mutta käytännössä osaava suunnittelija osaa ottaa myös eri näyttökoot huomioon suunnittelussa.

IV – Ensimmäinen versio testipalvelimella

Tekninen toteuttaja tai sivustonikkari on jo aloittanut työnsä hyvissä ajoin ja rakentanut testiympäristön, johon on mahdollisesti ladannut testidataa ja luonut toiminnallisuuksien vaatimat sisältötyypit. Käytännössä iso osa toiminnallisuudesta on voitu saada jo teknisesti kuntoon ennen ulkoasun valmistumista. Koska käytännössä ollaan yleensä tekemisissä kotisivutuotantoon tarkemmin perehtymättömän asiakkaan kanssa, ei rautalankamallina toimivaa sivustoa kannata yleensä vielä näyttää asiakkaalle, vaan ensimmäinen testiversio pitää jo sisällään ensimmäisen ulkoasuversion.

V – Sisällöntuotannon aloittaminen ja testaus

Kun sivusto alkaa hahmottua on aika aloittaa lopullisen sisällön luominen. Kovin pitkään ei kannata käyttää Lorem Ipsum-tekstejä ja leiskakuvia vaan mahdollisimman pian olisi siirryttävä oikeaan aineistoon, josta on vastuussa sisällöntuottaja tai -tuottajat. Tässä vaiheessa viimeistään on projektipäällikön järjestettävä tapa, jolla testaajat voivat toimittaa raporttejaan. Projektipäällikkö toimii tarvittaessa suodattimena sisällöntuottajan ja teknisen toteuttajan, sekä testaajien välissä. Projektipäällikön on myös keskusteltava näiden tahojen kanssa, että kaikille syntyy ymmärrys siitä, mikä on oikeasti virhe ja mikä on vaatimus uudesta toiminnallisuudesta. Tässä vaiheessa viitataan vaiheissa II ja III määritettyihin kokonaisuuksiin.

Tässä lyhyesti ohje virheiden raportointiin:

• Kuvaile ympäristösi (mikä laite, mikä selain, mikä versio). Liitä tämä jokaiseen raporttiisi.
• Kerro, mitä olit tekemässä mahdollisimman tarkasti (menin sivulle X, syötin nämä tiedot, painoin nappulaa Y)
• Kuvaile, mitä oletit, että tapahtuisi, kun teit edellisessä kohdassa mainitsemasi toiminnon
• Kerro, mitä todellisuudessa tapahtui, jos mahdollista liitä mukaan näyttökaappaus

Usein raportti on muotoa ”sivu ei toimi” tai ”x-toiminnalisuus on rikki”. Tällainen raportti on yhtä tyhjän kanssa ja syö aivan turhaan sivustonikkarin aikaa, kun hän joutuu miettimään mitä mahdetaan tarkoittaa. Siksi on tärkeää, että projektipäällikkö toimii filtterinä. Teknisen toteuttajan ja sisällöntuottajan on myös ilmoitettava, millä aikataululla he korjaavat löydetyn virheen.

VI – Toinen versio testipalvelimella

Vaikka iteraatiot varmasti tapahtuvat päivittäin tai jopa tunneittain on tärkeää määrittää jo alussa, mitä toiseen versioon kuuluu: Mitkä toiminnallisuudet on oltava kunnossa ja minkä sisällön on oltava paikallaan. Tämä tieto ja päivämäärä, sekä kaikkien sitoutuminen pitävät projektin vakaalla suunnalla kohti maalia.

VII – Sisällöntuotannon jatkaminen ja testaus

On tärkeää pitää testausta koko ajan yllä. Testaajien tai projektipäällikön on varmistettava, että raportoidut virheet on korjattu ja tekninen toteutus ja sisällöntuotanto on pidettävä yllä. Tälle vaiheelle on ominaista, että ilman potkimista hommat jäävät junnaamaan. On siis erittäin tärkeää, että koodaaja tai sivustonikkari ja sisällöntuottaja, kuten myös ulkoasun suunnittelija saavat riittävää palautetta kaikista sivuston toiminnoista. Tässä kohtaa on hyvä aloittaa myös mobiiliversion testaus.

VIII – Lopullinen versio testipalvelimella

Tämä on todellakin lopullinen versio. Käytännössä annetaan päivämäärä, jonka jälkeen ei enää tehdä korjauksia, eikä raportoida virheitä. Sivun on oltava siinä toiminnallisesti, sisällöllisesti ja ulkoasullisesti, että se voidaan julkaista.

IX – Lopullinen testaus

Viimeistään tässä vaiheessa on sivuston lopullisen kodin oltava valmiina. Lopullisen testauksen aikana tekninen toteuttaja ja palvelintilan tarjoaja käyvät läpi kaikki vaadittavat ominaisuudet ja testaavat, että palvelin on siinä kunnossa, että sivusto voidaan sille siirtää. Tässä vaiheessa ei pitäisi olla enää mitään muita kuin teknisiä yksityiskohtia, jotka tarkastetaan. Mukaan lukien sivuston linkkien oikea määrittäminen, tietoturva ja mm. somejulkaisuominaisuudet.

Jos ollaan siirtämässä sivustoa uudelle palveluntarjoajalle, pitää testata myös sähköpostien toimiminen. Tätä varten kannattaa luoda yksi väliaikainen sähköpostilaatikko ja suorittaa siirto sille kokeilumielessä.

X – Siirto

Riippumatta siitä, miten siirto toteutetaan, piilee siinä aina virheiden mahdollisuuksia. Siksi se on hyvä ajoittaa sellaiseen ajankohtaan, ettei sivulla ole paljon käyttäjiä. Jos kyseessä on yritys, kannattaa harkita iltoja ja viikonloppuja. Lisäksi, jos sähköposteille joudutaan tekemään ns. yliheitto, eli vaihtaa ne palvelimelta toiselle, kannattaa se tehdä myös sellaisena aikana kun liikennettä ei odoteta.

Joka tapauksessa tämä on homma, joka pitää jättä ammattilaisten huoleksi ja asia pitää ilmoittaa heille hyvissä ajoin, että vältytään ikäviltä yllätyksiltä 😉