Milloin kannattaa tehdä html-proto, milloin leiskat, milloin vaatimusmäärittely, milloin riittää tuotevisio?

Vierityspalkin artikkelisarjassa on aiheena verkkosivujen konseptisuunnittelu ja siihen liittyvät vaiheet, menetelmät, käsitteet ja dokumentit.

Verkkopalveluiden suunnittelu- ja valmisteluvaiheessa ideoita ja vaatimuksia työstetään monin eri tavoin, ja onpa eri mallien välillä myös ideologisia erimielisyyksiä tekijöiden välillä.

Ketteryyden nimeen vannova jengi haluaisi yleensä lähteä aina koodaamaan mahdollisimman nopeasti. Designerit haluaisivat tehdä klikkailtavia ja toimivia käyttöliittymäprototyyppejä. Moni digitoimisto tekee edelleen suunnitelmansa isona kasana Photoshop-leiskoja. Asiakas voi jäädä tässä taistelussa helposti alakynteen ja ihmettelemään, että miten nämä eri lähestymistavat eroavat hänen kannaltaan.

Käyn tässä jutussa läpi pääosin omia kokemuksiani eri malleista, ja kannustan etenkin asiakkaita ottamaan jämäkämmin kantaa projekteissaan siihen, että millaisia lopputuloksia tehdään. Liian usein näen tilanteita, joissa asiakas on valinnut kumppaninsa suunnitteluvaiheeseen, mutta ei ole ottanut kantaa siihen miten valittu toimisto dokumentoi tekemänsä suunnitelmat. Toimisto taas yleensä preferoi sitä mallia, josta heillä on eniten kokemusta ja jonka “kaikkivoipaisuuteen” he sattuvat uskomaan.

Mallin valinta ei kuitenkaan saisi riippua siitä, että mistä kukin toimisto tykkää, vaan siitä, että mikä on asiakkaan valitsema malli projektin läpivientiin, aiotaanko seuraavassa vaiheessa kilpailuttaa kumppaneita tai esimerkiksi pitääkö suunnitelmia testauttaa asiakkailla ennen toteutusta.

Konseptisuunnitteluvaiheen lopputulosten muodon määrittely on yksi tärkeimmistä päätöksistä, joita asiakkaan puolella tulee tehdä ennen konseptisuunnittelun tai määrittelyvaiheen aloittamista, ja viimeistään suunnitteluvaiheen loppupuolella.

Toiminnalliset käyttöliittymäprototyypit

Erilaiset html-prototyypit tai jollain ohjelmalla tehdyt klikkailtavat prototyypit ovat varmasti isoin uudenlainen tapa dokumentoida suunnitelmia, joita viimeisen kymmenen vuoden aikana on tullut. Toimivia protomalleja tehdään erittäin monilla eri tavoilla, ja protoja pidetään yleensä hyödyllisinä niin suunnittelijoiden kuin toteuttajien näkökulmasta. Hyvä proto helpottaa aina asioiden konkretisointia ja kommunikointia toisille osapuolille. Etenkin täysin uusien palveluiden kohdalla kevyeen käyttöliittymäprotoon investointi on yleensä hyvin suositeltavaa.

Järkevästi toimivan proton, jopa jonkin verran toiminnallisuutta sisältävästä palvelusta, saa yleensä parin kymppitonnin investoinnilla, ja sen avulla suunnitelmia pystyy testauttamaan asiakkailla, ja johtokin pääsee hyvin mukaan siihen mitä ollaan tekemässä. Yleensä tällaisen näennäisesti toimivan käyttöliittymäproton tekeminen on nopein ja halvin tapa selvittää, onko uudelle palvelulle tilausta ja ovatko alustavat oletukset palvelun toimintalogiikasta olleet oikeansuuntaisia.

Melko perinteisiin verkkosivustoihin tai verkkokauppoihin ei protoja yleensä tehdä, ellei olla muuttamassa jotain olennaista toimintalogiikkaa tai palvelun peruskonseptia. Käyttöliittymäproton toteutus on kuitenkin usein ihan huomattava investointi, eikä siihen tehtyä työtä saada siirrettyä eteenpäin toteutusvaiheeseen (ja useimmissa tapauksissa ei edes kannata yrittää). Yleensä itse suosittelen proton tekemistä vain jos uuden palvelun yksityiskohdista käydään merkittävää sisäistä vääntöä tai halutaan testauttaa uutta konseptia todellisilla loppuasiakkailla. Etenkin jos todellista, kunnollista asiakastestausta ei aiota tehdä, tai koeta tarpeelliseksi, niin protoon panostaminen ei välttämättä ole hintansa ja ylimääräisen ajankäytön arvoinen harjoitus.

Käyttöliittymäproto voi esimerkiksi kilpailutuksen kannalta olla kuitenkin ihan hyvä investointi, koska riippumatta kilpailutuksen mallista, voi protoa käyttää kilpailutuksessa joko vaatimusmäärittelyn konkretisoijana tai sitten tukimateriaalina ketterän tiimin kilpailutuksessa. Ainoaksi kilpailutuksen tukidokumentiksi käyttöliittymäproto ei kuitenkaan riitä. Yksikään tekninen toteuttaja ei pysty pelkkää protoa tutkimalla arvioimaan millainen työ olisi oikeasti toteuttaa kyseinen verkkopalvelu. Tämä on yllättävän yleinen ostajien tekemä virhearvio.

Loistavakin käyttöliittymäprototyyppi tarvitsee rinnalleen laadukkaan vaatimusmäärittelyn, jos tekninen toteutus aiotaan kilpailuttaa projektitoimituksena. Vain jos kilpailutus aiotaan kohdistaa vain tiimiin, ja toteutus aiotaan johtaa itse ketterien mallien mukaisesti, niin käyttöliittymäprototyyppi voi riittää briiffaukseksi tiimille siitä millainen palvelu on tavoitteena.

Klassinen, leiskavetoinen konseptisuunnitelma

Monien digitoimistojen edelleen suosima malli on tehdä verkkopalvelun suunnitteluvaiheessa paksu dekki powerpointtia ja iso kasa visuaalisia leiskoja. Työn lopputuloksena asiakas saa ison kasan sekalaisia suunnitelmia, joista voi olla yllättävän vaikea hahmottaa kokonaisuutta – ja vaikka kokonaisuuden saisikin hahmotettua, niin yksityiskohtia on avoinna sadoittain, ja parhaimmillaan leiskoissa on seassa myös keskenään ristiriitaisia ideoita.

Noh, hyvää suunnittelutyötä on usein silti tehty ja tärkeitä ongelmia ratkaistu. Asiakkaan kannalta tilanne on kuitenkin hankala. Miten tästä eteenpäin? (Digitoimisto tietysti haluaisi vain jatkaa hommia suoraan tekniseen toteutukseen, koska heillä on “paras ymmärrys kaikesta päässään”.)

Kilpailutuksien kannalta klassinen, sekava konseptisuunnitelma-powerpointti on käytännössä aina liian hajanainen kokoelma ajatuksia, jotta sen avulla voisi järkevästi kilpailuttaa tekijöitä varsinaiseen toteutukseen. Siksi monet päätyvät jatkamaan suunnittelutoimiston kanssa tekniseen toteutukseen, koska tällä toimistolla on paras ymmärrys siitä mitä tavoitellaan. (Ehkä siksikin nämä dokumentit ovat edelleen niin sekavia, koska tekijöiden intressissä ei ole tehdä niistä parempia.)

Voi myös perustellusti kysyä, että onko valtava määrä leiskoja järkevä tapa suunnitella verkkopalveluita. Oma kantani on, että se ei ole järkevä tapa suunnitella edes yksinkertaisia verkkopalveluita. Alkuvaiheen suunnittelu on kyllä tärkeätä, mutta yksityiskohtainen leiskaaminen ja Photoshopissa tapahtuva käyttöliittymäsuunnittelu pitäisi jättää toteutusvaiheeseen. Alkuvaiheen konsepti-, sisältö- ja toiminnallisuussuunnittelussa riittää karkeampi mallinnustaso, jossa esimerkiksi tehdään vain karkeita rautalankamalleja, ja ei välttämättä edes niitä. (Esimerkiksi edustamani firma, North Patrol, tekee alkuvaiheen suunnittelua juuri tällä tavalla.)

Ainut poikkeus tähän sääntöön on tilanne, jossa leiskavetoista suunnittelua tekevä digitoimisto tulee myös automaattisesti vastaamaan teknisestä toteutuksesta. Monilla isoilla asiakasorganisaatioillahan on luotettuja digitoimistokumppaneita, joille annetaan koko projekti tehtäväksi alusta saakka, ja luotetun kumppanin kanssa ei tarvita yksityiskohtaisia hintaneuvotteluitakaan. Tällaisessa prosessissa on mielestäni asiakkaan edun mukaista mennä juuri sillä mallilla millä luottokumppani haluaa töitä tehdä, joten klassinen leiskavetoinen meininkikin on aivan toimiva malli.

Jos tekniseen toteutukseen kuitenkin liittyy avoimia kysymyksiä, tai se halutaan kilpailuttaa usean toimiston välillä, niin klassinen leiskavetoinen konseptisuunnittelu kannattaisi unohtaa. Se suosii vain suhteettomasti suunnittelutyön tekevää tahoa, eikä johda hyvään kilpailutukseen, eikä tekniseen toteutukseen (ellei voittaja ole suunnittelun tehnyt taho).

Toki sekavankin konseptisuunnitelmapaketin voi saada käyttökelpoiseksi kilpailutusmateriaaliksi kirjoittamalla vaatimusmäärittelydokumentin nojaten tehtyyn materiaaliin (ja esim. North Patrol on tehnyt näitä paljonkin), mutta tällainen prosessi on kaukana järkevästä ja hyvin käytetystä rahasta ja ajasta – ja lopputulos on kilpailutuksenkin kannalta silti yleensä vain säällinen.

Ketterä malli: tuotevisio ja tuotteen kehitysjono

Ketterät mallit ovat tuoneet tähän soppaan mukanaan varsin paljonkin uusia kulmia.

Isoimpana uutuutena voidaan pitää mallia, jossa isot (digi-)toimistot myyvät kokonaisia tiimejä asiakkaiden käyttöön, ja ideana on lähteä lähes samantien koodaamaan uutta palvelua, ilman erillistä alkuvaiheen suunnitteluvaihetta (alan konkarit toki tietävät, että oikeastihan tätä mallia on tehty IT-alallakin aina, ketterät menetelmät ovat vain tarjonneet sille uudenlaisen kehyksen ja perustelut). Tällaisen mallin perusteena on yleensä valtava kiire tai halukkuus kokeilla täysin uudenlaista toimintamallia. Malli edellyttääkin hyvin tiivistä yhteistyötä alusta saakka, ja käytännössähän mallissa korvataan dokumentit intensiivisellä vuorovaikutuksella ja “lennosta määrittelemällä” – eli tarkentamalla suunnitelmia toteutuksen edetessä.

Dokumenttityyppisten tuotosten sijasta yleensä rakennetaan jonkinlaista elävää tyyli/malli-kirjastoa tai tuotetaan suoraan teknisen toteutuksen tarpeisiin soveltuvia määrityksiä. Eniten mallia käyttävät startupit ja hyvin startup-maisesti toimivat pysyvät tiimit. Laajoja verkkopalvelukokonaisuuksia hyvin harvoin uudistetaan tällaisella mallilla, vaan niissä käytetään perinteisempää tilaaja-toimittaja-tyyppistä yhteistyösuhdetta.

Selväähän on, että oman ketterän tiimin malli on poikkeuksetta perinteisempiä malleja merkittävästi kalliimpi työskentelymalli, joten nopeudelle ja tiiviimmälle yhteistyölle on löydyttävä hyvät perustelut. On kuitenkin tilanteita, joissa äärimmäistä nopeutta ja tiivistä vuorovaikutusta tarvitaan – ja siitä ollaan valmiita maksamaan.

Täysin asiakkaan omassa johdossa toimivien tiimien lisäksi ketteryys on tuonut mukanaan valmisteluvaiheisiin myös pari uutta dokumenttityyppiä. Suomessakin puhutaan jo nykyisin varsin laajalti tuotevisioista ja tuotteen kehitysjonoista, jotka muodostavat usein ketterien menetelmien keskeisimmät dokumentit, joiden pohjalta työtä johdetaan ja ohjataan. Voisikin arvioida, että harvassa ovat ne koodausfirmat, jotka eivät ketteriä menetelmiä jollain muotoa sisäisessä toiminnassaan sovella, joten monille asiakkaillekin nämä ovat jo tuttuja dokumentteja.

Joskus tuotevisiota ja tuotteen kehitysjonoa myös käytetään kilpailutuksissa kuvaamaan tavoiteltavaa kokonaisuutta. Tuotevisio ja tuotteen kehitysjono ovat kuitenkin vahvasti teknisen toteutuksen tarpeisiin tehtyjä dokumentteja, joiden käyttäminen projektitoimituksen kilpailutuksessa ei yleensä tuota hyviä tuloksia. Näiden keskeisin ongelmahan on kilpailutuksen kannalta se, että tuotevisio ja tuotteen kehitysjono eivät rajaa asioita yleensä juurikaan, eivätkä välttämättä edes muodosta kovin selkeätä kuvaa tavoiteltavasta palvelukokonaisuudesta. Täten kilpailutuksen pohjana ne toimivat huonosti, jos tavoitteena on jonkinlainen projektitoimitus, jossa toimitaan tilaaja-toimittaja-yhteistyösuhteessa.

Pelkästään toteuttavan tiimin kilpailuttamisessa tuotevisio ja tuotejono ovat toki varsin toimivia, jos kilpailutuksessa ei tavoitella minkäänlaista kiinteätä hintaa. Pelkästään tiimiä ostettaessa ei kilpailutuksen kannalta ole yksinkertaisesti olennaista, että muodostavatko pohjamateriaalit selkeätä kokonaisuutta vai eivät.

Täten voinee sanoa, että jos on ostamassa pelkkää toteuttavaa tiimiä omaan johtoonsa, niin tiimin kilpailutuksen kannalta suunnitteluvaiheen lopputulosmateriaaleilla ei ole kovin paljon merkitystä, mutta vähintään alustava tuotevisio ja tuotteen kehitysjono toki olisi hyvä suunnitteluvaiheessa tuottaa. Tämän lisäksi erilaiset prototyypit, jopa leiskamuotoiset konseptisuunnitelmat voivat olla perusteltuja täydennyksiä, jotka auttavat kilpailutuksessa ja erityisesti varsinaisen toteutuksen käynnistämisessä.

Ketteristä menetelmistä lainatut valmistelu- ja suunnittelumenetelmät ovat yleisesti ottaen varsin suositeltavia, koska yleensä niissä on aina mukana jonkinlaista priorisointia ja toteutettavuuden arviointia. Leiskavetoiset menetelmät ja prototyypit kärsivät varsin usein liiallisesta huomion kiinnittymisestä ”pintaan” ja ”hienoihin juttuihin”, eikä prosessissa saateta keskustella ollenkaan eri ideoiden mahdollisista kustannuksista tai niiden toteutettavuudesta. On esimerkiksi valitettavan tyypillistä, että pintaan keskittynyt konseptisuunnittelu ja käyttöliittymäproto ei kuvaa lainkaan kokonaisuuden edellyttämiä taustajärjestelmiä ja näiden vaatimuksia. Ketterien menetelmien mallit sentään pakottavat edes jonkinlaiseen priorisointiin ja kaikkien keskeisten osa-alueiden tunnistamiseen (myös niiden tylsempien juttujen, kuten vaikkapa integraatioiden ja sisällön ylläpidon näkökulman).

Jos haluat kilpailuttaa: vaatimusmäärittelydokumentti

Jos et kuitenkaan ole ostamassa pelkkiä resursseja omaan johtoosi, niin hyvän kilpailutuksen edellytyksenä on laadukas vaatimusmäärittely. Ja kuten todettua, vaatimusmäärittely on enemmän kuin pelkkä kokoelma powerpoint-slaideja ja leiskoja.

Hyvä vaatimusmäärittely muodostaa tarinan, tarinan siitä millaisen palvelun ostava organisaatio haluaa saada. Vaatimusmäärittely rajaa kokonaisuuden, asettaa tavoitteet, kuvaa palvelun peruskonseptin, kuvaa keskeiset toiminnallisuudet, määrittää keskeiset rajapinnat, ehkä tarjoilee suuntaa-antavia malleja käyttöliittymistä, mutta ei kuitenkaan sanele liikaa yksityiskohtia, jättäen toteuttavalle taholle tilaa soveltaa omaa asiantuntemustaan. Vaatimusmäärittelyn kertoman tarinan tehtävänä on ensisijaisesti antaa kilpailutukseen osallistuville kandidaateille tasapuolinen ja yksiselitteinen kuva kokonaisuudesta jota ollaan ostamassa, jotta kandidaatit voivat tehdä realistisen työmääräarvioinnin tälle kokonaisuudelle.

Yksi esimerkki hyvän vaatimusmäärittelyn elementeistä ja rajauksista löytyy aiemmasta blogiartikkelista, jossa myös linkitetään esimerkkidokumenttiin. Tämä on toki vain North Patrolin malli hyvästä vaatimusmäärittelystä verkkopalvelu-uudistukselle, mutta kuvastanee silti varsin hyvin sitä lähestymistapaa, jota hyvät vaatimusmäärittelyt tyypillisesti edustavat.

Menetelmällisesti vaatimusmäärittelyitä tehdään yleensä vähemmän “pintavetoisesti” kuin esimerkiksi prototyyppejä ja leiskavetoista työtä. Hyvä vaatimusmäärittelytyö sisältääkin ketterien menetelmien kaltaista priorisointia ja rajauksia, ja hyvästä vaatimusmäärittelystä saakin yleensä käännettyä hyvin pienellä työllä ensimmäisen version tuotteen kehitysjonosta, kun kilpailutusvaihe on saatu päätökseen.

Kilpailutus edellyttää yksiselitteisen tarinan, leiskat voisi jo unohtaa

Yleisesti ottaen voi myös sanoa, että mitä enemmän on dokumentteja, sitä vaikeampaa on saada aikaan hyvä kilpailutus varsinaisesta toteutusvaiheesta. Hyvän kilpailutuksen edellytys on laadukas, yksiselitteinen tavoiteltavan kokonaisuuden dokumentointi. Tällaiseen vaatimukseen vastaa parhaiten tasalaatuinen, selkeän tarinan kertova vaatimusmäärittelydokumentti. Muutkin dokumentit toimivat, ja voivat toimia hyvän kilpailutuksen pohjana, mutta vaativat yleensä enemmän selittävää materiaalia tuekseen.

Teknisen toteutuksen kunnollisesta kilpailutuksesta haaveilevien tulisi aina tähdätä vaatimusmäärittelydokumenttiin suunnitteluvaiheen lopputuloksena.

Jos kuitenkin tähtäimessä on pelkkä toteuttavan tiimin ostaminen, ilman lupauksia kiinteästä hinnasta, niin lähes mikä tahansa dokumentaation malli voi toimia hyvän kilpailutuksen pohjana. Käytännössä nykyaikainen pohjamateriaali ketterälle tiimille rakentuu laadukkaan tuotevision ja tuotteen kehitysjonon ympärille, ja varsin usein sitä kannattaa täydentää myös käyttöliittymäprototyypilllä.

Klassinen, leiskavetoinen, yksityiskohtainen konseptisuunnittelu kannattaisi jo siirtää historiaan. Nykyaikaiset verkkopalvelut ovat hyvin toiminnallisia, vaativia tietojärjestelmiä. Näiden suunnittelussa yksityiskohtaiset visuaaliset leiskat eivät ole järkevä työväline. Joko tarkkuustasoa kannattaisi madaltaa (esimerkiksi suuntaa-antaviin rautalankamalleihin tai hyvin karkeaan prototyyppiin) tai sitten tarkempi suunnittelu kannattaisi jättää suosiolla toteutusvaiheeseen.

Jos siis digitoimistosi edelleen tuottaa kasoittain leiskoja konseptisuunnitteluvaiheessa, niin ehkä olisi kehityskeskustelun paikka.

—

PS. Jatkolukemiseksi sopii: Verkkopalvelun konseptisuunnittelu North Patrolissa tai Vaatimusmäärittelyn monta eri tehtävää

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee Drupalin, WordPressin sekä monet muut teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja verkkopalveluiden jatkokehityksen suunnittelussa.