Julkaisujärjestelmän valinta pähkinänkuoressa

web-application-development-startupsmith

Julkaisujärjestelmän valinta oman verkkosivuston alustaksi ja sisällöntuotantovälineeksi on lopulta varsin suoraviivainen tehtävä. Ainut todella keskeinen edellytys on, että omat suunnitelmat verkkosivustoa varten ovat kohtuullisen valmiit.

Jos konsepti on selvä ja organisaatiossa todella halutaan saada web-projekti eteenpäin, niin julkaisujärjestelmävalinta hoituu parhaimmillaan muutaman viikon tutkimisella, esittelyillä, neuvotteluilla ja ehkä parin asiantuntijatahon konsultoinnilla. Toisessa ääripäässä ovat organisaatiot joilla uuden julkaisujärjestelmän valinta kestää useita kuukausia. Tässä artikkelissa annetaan vinkit tehokkaan julkaisujärjestelmävalinnan läpivientiin.

Kulmakivet julkaisujärjestelmävalinnan tekemiseen
Fiksun julkaisujärjestelmävalinnan kulmakivinä voi pitää kolmea sääntöä:

1. Uuden verkkosivuston konsepti ja vaatimusmäärittely pitää olla valmis ennenkuin julkaisujärjestelmä valitaan. Tämä ei estä vaihtoehtoihin tutustumista aikaisemmin, mutta valintaa ei tule lukita ennenkuin vaatimusmäärittely on myös valmistunut.

2. Verkkosivuston vaatimusmäärittelyn ei tule olla liian yksityiskohtainen, vaan sen pitää antaa tilaa erilaisten julkaisujärjestelmien toimintatavoille. Vaatimusmäärittelyn tulee keskittyä erikoisimpien loppukäyttäjätoimintojen kuvaamiseen ja sisällöntuottajien todellisten käyttötapauksien kuvaamiseen.

3. Järjestelmän valintaan tulee osallistaa sisällöntuottajia ja muita järjestelmän kanssa säännöllisesti työskenteleviä henkilöitä. Näiden tulee vähintään päästä näkemään esittelytilaisuuksissa miten heidän eniten suorittamansa tehtävät hoituvat eri järjestelmillä. Sisällöntuottajat voivat näin arvioida myös järjestelmien käytettävyyden omasta näkökulmastaan.

Käytettävyyden arviointi tapahtuu sisällöntuottajien avulla
Erityisesti sisällöntuottajien tehtävien kuvaaminen on tärkeätä. Kun omat käyttötapaukset julkaisujärjestelmälle on kuvattu loogisten tarinoiden muotoon, niin toimittajia voi pyytää esittelemään julkaisujärjestelmää näiden tarinoiden kautta. Näin esittelytilaisuuksiin osallistuvat sisällöntuottajat voivat myös arvioida järjestelmän käytettävyyttä esittelytilaisuuksissa – eikä toimittaja pääse demoamaan vain oman järjestelmänsä hienoimpia toimintoja.

Kaikista arvioinneista ja tapaamisista tulisi myös pyytää kaikilta osallistujilta kirjalliset arviot. Näin oman organisaation valintaprosessi etenee systemaattisesti, eikä viimeinen päätöspalaveri mene väittelyksi.

Runsaasta tarjonnasta ei kannata hämääntyä
Tärkeintä on suhtautua valintaan realistisesti ja päättäväisesti. Markkinoilla on valtava tarjonta erilaisia työkaluja, joiden myyjät eivät välttämättä tunne kilpailijoiden tuotteita lainkaan vaan suosittelevat omaa tuotettaan surutta kaikkiin mahdollisiin tehtäviin. Lisäksi merkittävä osa ostajista tekee päätöksensä hyvässä uskossa myyntipuheisiin luottaen. Tämä valitettava tosiasia näkyy etenkin projektien jälkeisessä tyytymättömyydessä, kun kaunopuheiden takaa onkin paljastunut ei-niin-täydellinen todellisuus.

Oman projektin auditointi kannattaa usein
Ostavalla taholla on onneksi kaksi temppua joilla yllättävää tyytymättömyysriskiä voi merkittävästi vähentää:

1. Valintavaiheessa sisällöntuottajat pääsevät kokeilemaan valinnan kohteina olevia järjestelmiä demotunnuksilla tai kevyellä testiversiolla. Sisällöntuottajien tulee myös testata eri järjestelmistä aina samat käyttötapaukset eikä vain päämäärättömästi ”tutkia järjestelmää”. Jos ostavalla taholla on selkeä suunnitelma näihin testauksiin, niin toimittajat myös mielellään tarjoavat hyvät testiympäristöt. Testauksen kautta pitäisi myös selvitä käytännössä se mihin julkaisujärjestelmä pystyy “suoraan paketista”, ja mitkä asiat ovat räätälityönä tehtäviä asioita.

2. Vaatimusmäärittelytyön alussa tai lopussa ostava taho voi pyytää asiantuntija-arviota oman hankekokonaisuutensa loogisuudesta ja toteutettavuudesta. Tämä voi olla yksittäinen työpajapäivä konsultin kanssa tai toteutettavuusselvitykseksi (engl. feasibility study) kutsuttava laajempi harjoitus. Tämän projektiarvioinnin tehtävä on tarkistaa, että web-projektin sisälle ei esimerkiksi olla paketoitu asioita jotka olisi järkevämpää tehdä erillisinä projekteina (esim. extranet-toiminnot on usein järkevää eriyttää pois viestinnällisen verkkosivuston toteutusprojektista).

Osaava asiantuntija-arviointi osaa myös sanoa, että minkälaiset toiminnallisuudet ovat yleensä perustoimintoja julkaisujärjestelmissä ja mitkä kokonaisuudet vaativat todennäköisesti huomattavaa räätälöintiä. Näin voidaan parhaimmillaan jo aikaisessa vaiheessa karsia suunnitelmista pois toimintoja, jotka eivät ole kovin tärkeitä, mutta joiden kustannukset voivat potentiaalisesti olla iso osa loppusummaa.

Monella alalla vaatimuksien auditointi on aivan arkipäivää, ja työssä voidaan käyttää monenlaisia toimijoita. Esimerkiksi Microsoft SharePoint -projektien maailmassa suunnitelmien auditointi on arkipäivää niin Microsoftin konsultointiyksikölle kuin projekteja toteuttaville kumppaneille.

Tyypilliset ongelmat
Yleensä ongelmat valinnan suhteen liittyvät joko a) vielä kesken olevaan uuden verkkosivuston konseptisuunnitelmaan tai b) oman organisaation ristiriitaisiin vaatimuksiin suhteessa tehtävään projektiin. Etenkin jälkimmäiseen ongelmaan liittyy usein tahoja, jotka haluavat ehdottomasti jotakin asiaa. Esimerkiksi IT-osastolla saattaa olla tahoja, jotka ehdottomasti haluavat valittavan ratkaisun olevan “täysin avointa lähdekoodia” tai mahdollistavan “rajattoman, helpon laajentamisen” tai “kumppanin vaihtaminen tulee olla helppoa vaikka järjestelmään tulisi paljon räätälöintejä”. Nämä kaikki ovat todellisia esimerkkejä, ja eivät edes ääritapauksia – mutta kuuluvat valitettavasti asioihin joiden saaminen ei ole lainkaan helppoa. Täten hyvinkin edennyt julkaisujärjestelmävalinta saattaa pysähtyä tilanteeseen, jossa esimerkiksi IT-osaston asettamat ehdottomat reunaehdot estävät valintapäätöksen tekemisen.

Myös toteutuskumppanin valinta voi osoittautua vaikeaksi, ja joskus ongelmaksi muodostuu yksinkertaisesti se, että toimittajavalinnan ja julkaisujärjestelmävalinnan tekeminen samalla kertaa on vain liian iso haaste. Tästä syystä voikin pitää nyrkkisääntönä, että vain jos projektin arvioitu toteutusbudjetti on alle 50 000 euroa, niin kannattaa yrittää tehdä järjestelmä- ja toimittajavalinta samalla kertaa.

Hyväksy riskit, keskity nykytilanteen ongelmiin ja paina kaasua!
Järkevintä onkin tunnistaa riskit jo alkuvaiheessa, ja hyväksyä markkinan ongelmat ja omien vaatimuksien hyvinkin todennäköinen ristiriitaisuus. Näiden realiteettien hyväksymistä tulisi helpottaa se todellisuus, että verkko muuttuu nopeasti. Yli kolmen vuoden päähän on hyvin vaikea ennustaa verkon kehitystä, saatika sitä mitä oma organisaatio verkossa haluaa tehdä kolmen vuoden päästä.

Valinnassa tuleekin painottaa eniten niitä vaatimuksia joita organisaatiolla on juuri nyt. Lisäksi julkaisujärjestelmien vaihtaminen on työläydestään huolimatta kohtuullisen edullista ja järkevää, koska myös verkkopalvelut vaativat yleensä 3-5 vuoden välein isompia uudistuksia. Tästä on usein syytä muistuttaa etenkin IT-osastoa, joka saattaa herkästi ylipainottaa pitkän tähtäimen asioita joilla ei web-projekteissa ole useinkaan samanlaista merkitystä kuin muiden järjestelmäuudistusten yhteydessä casinohuone kampanjakoodi.fi.

Valintaan ei siis kannata jäädä jumiin, vaan olennaisinta on löytää riittävän hyvä julkaisujärjestelmä, jonka avulla uskoo oman organisaation verkkoviestintää pyöritettävän useamman vuoden, ja josta myös sisällöntuottajat pitävät. Jos tähän vielä onnistuu yhdistämään mukavan ja osaavan kumppanin, niin järkevintä on painaa kaasua projektille, ja alkaa keskittymään sisältöihin ja muihin oikeasti tärkeisiin asioihin!

Leave a Reply

Your email address will not be published. Required fields are marked *