Sopeutuva suunnittelu - Sosiaalisen median suunnitteluprosessi yritysympäristössä: tapaus Alissa

Jussi Linkola - 2007-11-26

Helsingin ammattikorkeakoulu Stadialle tehty verkkoviestinnän medianomiopintojen opinnäyteteyö. Työ käsittelee sosiaalisen median suunnittelun ja projektityöskentelyn haasteita.

PDF-versio Doria-kirjastossa

Sisällys

1 JOHDANTO

Osallistuin keväällä 2007 hankkeeseen, jossa sovellettiin sosiaalisen median toimintamalleja yrityksen työntekijöille rakennettavassa verkkopalvelussa. Oman kokemukseni mukaan erilaiset sosiaalisen median sovellukset, kuten esimerkiksi wikit ja blogit, ovat tarjonneet uudenlaisia viestintätapoja ja yhteistoiminnan muotoja internetin käyttäjille, joten ajatus näiden mahdollisuuksien hyödyntämisestä yritysympäristössä tuntui houkuttelevalta. Uskoin vahvasti, että kaikista niistä toimintamalleista, jotka suuret käyttäjäjoukot ovat kokeneet hyödyllisiksi, olisi melko yksinkertaista kehitellä uudenlainen ja toimiva kokonaisuus. Houkuttelevista lähtökohdistaan huolimatta palvelun suunnitteleminen osoittautui kuitenkin hyvin haastavaksi.

Hankkeen pilottipalvelun valmistuttua aloin tarkastella käyttämiäni sosiaalisen median palveluja suunnittelijan näkökulmasta - mitkä ovat tärkeimmät ideat, joiden ympärille palvelut rakentuvat, millaisia asioita suunnittelussa on pitänyt huomioida ja kuinka eri ratkaisuihin on mahdollisesti päädytty? Ymmärsin vähitellen, että oman työryhmämme käyttämä, runsaalla alkusuunnittelulla määritelty suunnitteluprosessi ei tukenut sellaista luovaa ja ideoiden kehittelyyn perustuvaa työtapaa, joka johtaisi toimivan sosiaalisen median palvelun toteutumiseen. Toisaalta oli selvää, että jo olemassa olevassa, valmiin toimintakulttuurin omaksuneessa yritysympäristössä toimiminen edellyttäisi tiettyä suunnitelmallisuutta ja järjestelmällisyyttä, jotta työn etenemistä ja tavoitteiden toteutumista voitaisiin seurata. Vähitellen mieleeni tuli ajatus, että ehkä näiden kahden toimintatavan tarkoituksenmukainen yhdistäminen mahdollistaisi luovan kehitystyön, joka lähtisi yrityksen tarpeista ja tavoitteista ja joka etenisi hallitusti mutta joustavasti kohti tavoiteltua lopputulosta.

Työn tavoitteena on esittää sellainen verkkopalvelun suunnitteluprosessi, joka huomioi sosiaalisen median suunnittelutyön erityispiirteet ja joka perustuu jo olemassa olevan yritysympäristön tarpeista lähtevään suunnitelmallisuuteen.

Sosiaalisen median määritelmänä käytän VTT:n tiedotteessa Googlen mainokset ja muita sosiaalisen median liiketoimintamalleja esitettyä määritelmää, joka yhdistää sosiaalisen median sellaisiin sovelluksiin, jotka mahdollistavat verkossa tapahtuvan yhteistoiminnan:

Sosiaalinen media tarkoittaa sovelluksia, jotka perustuvat joko kokonaan käyttäjien tuottamaan sisältöön tai joissa käyttäjien tuottamalla sisällöllä ja käyttäjien toiminnalla on merkittävä rooli sovelluksen tai palvelun arvon lisääjänä. Sosiaalista mediaa voi tuottaa jo olemassa oleva yhteisö, tai yhteisö voi muodostua yksilöistä, jotka tuottavat sisältöä samaan palveluun. Sosiaalisen median käyttäjinä voi sen sijaan olla yksilöitä, jotka eivät kuulu yhteisöön, ja vain hyödyntävät sosiaalista mediaa.
(Kangas ym. 2007, 15.16.)

Käytän perinteisen verkkopalvelujen tuotantoprosessin lähdemateriaalina digimediatuotantojen suunnittelua, konseptisuunnittelua ja e-learning-toteutusten suunnittelua käsitteleviä teoksia. Näiden teosten esittämät toimintamallit ovat olleet myös medianomi-opintojeni aikana annetun, verkkopalvelujen suunnitteluprosessiin liittyvän opetuksen pohjana. Vertaan näitä toimintamalleja perinteisestä poikkeavaan verkkopalvelun suunnittelumalliin Getting Realiin, ja esitän näkemyksen mallista, jossa yhdistyvät hallittu suunnitelmallisuus ja Getting Realin kevyt ja joustava sovelluskehitys.

2 MIKROMOD-HANKE

Mikromod eli Mikromoduulien tehokas tuotanto ja monikanavakäyttö henkilöstön osaamisen kehittämisessä on Helsingin ammattikorkeakoulu Stadian ja Itella Oyj:n tammikuussa 2007 aloittama kaksivuotinen tutkimus- ja kehityshanke. Itella-konserni on logistiikkapalveluja tarjoava yritys, jolla on noin 25 000 työntekijää.

Mikromod-hankkeen tavoitteena on kehittää verkko-opetuksen oppimateriaalituotantoprosessin kustannustehokkuutta ja lisätä oppimateriaalin monikäyttöisyyttä sekä kehittää pedagogista lähestymistapaa, jossa henkilöstön ja opiskelijoiden osallistuminen ja vuorovaikutuksellisuus korostuvat. (Mikromod hankesuunnitelma 2006.)

Hankkeen lähtökohtana on ajatus opetuksellisen materiaalin pilkkomisesta mahdollisimman pieniksi itsenäisiksi kokonaisuuksiksi eli mikromoduleiksi, joita voidaan myöhemmin hyödyntää eri yhteyksissä ja jakelukanavissa. Moduleita yhdistelemällä on mahdollista luoda eri käyttötarkoituksiin ja erilaisille päätelaitteille soveltuvia materiaalikokonaisuuksia, joiden päivittäminen ja muokkaaminen on yksinkertaista. Esimerkiksi mobiilipäätelaitteiden hyödyntäminen on perusteltu tavoite työympäristössä, jossa työntekijöillä ei ole omaa tietokoneella varustettua työpistettä.

Tammikuun puolessa välissä 2007 pidetyssä avauskokouksessa hankkeen tematiikaksi valittiin Itellan työntekijöiden työhyvinvointiin ja ergonomiaan liittyvän hiljaisen tiedon kartoittaminen ja hyvien käytäntöjen levittäminen suunniteltavan konseptin ja teknisen järjestelmän avulla. Kevään aikana Stadian opiskelijat suorittivat hankkeessa vaihtoehtoisia, esimerkiksi konseptisuunnittelun ja käsikirjoittamisen ammattiopintoja, ja itse osallistuin hankkeeseen verkkoviestinnän opiskelijana useiden eri tehtävien kautta.

Kevään työskentelyn aikana toteutettiin pilottipalvelu Alissa, joka mahdollistaa Itellan varhaisjakajille oman materiaalintuotannon ja verkon välityksellä tapahtuvan keskustelun. Keskityn työssäni alkuperäisellä opiskelijaryhmällä toteutettuun suunnitteluvaiheeseen, joka päättyi kesäkuun alussa pidettyyn ohjausryhmän kokoukseen, jossa kevään työn tulokset esiteltiin ohjausryhmän jäsenille.

Käytän jatkossa nimeä Alissa, kun viittaan erityisesti suunniteltavaan pilottipalveluun. Yleisemmällä, koko hankkeeseen viittaavalla tasolla käytän edelleen nimeä Mikromod-hanke.

3 SOSIAALISEN MEDIAN TAUSTOJA

Mikromod-hankkeessa tavoiteltava henkilöstön osallistuminen asettaa vaatimuksia rakennettavalle verkkopalvelulle. Valmiiksi toimitetun "asiantuntijamateriaalin" lisäksi palvelun pitää antaa käyttäjille mahdollisuus luoda itse sisältöä, esittää omia näkemyksiään palvelussa jo olevasta materiaalista ja käydä keskustelua esiin nousevista asioista. Valmiin, kiinteän sisällön lisäksi palvelu parhaimmillaan mahdollistaa vuorovaikutuksen toisten käyttäjien kanssa ja lisää näin kommunikointia ja tiedon leviämistä. Vastaavia ominaisuuksia ja mahdollisuuksia hyödyntävistä verkkopalveluista käytetään niiden käyttäjälähtöisen sisällöntuotannon ja vuorovaikutusta tukevien ominaisuuksien perusteella nimitystä sosiaalinen media (Wikipedia 2007a).

Sosiaalisen median käsite juontaa juurensa vuosien 2004 ja 2005 aikana ilmestyneiden, toiminnallisuuksiltaan innovatiivisten verkkopalvelujen esiinmarssiin. O'Reilly Median ensimmäinen, vuonna 2004 järjestämä Web 2.0 -konferenssi ilmaisi nimellään näkemyksen siitä, että verkkopalvelut olivat tuolloin saavuttaneet uuden kehitysvaiheen (Graham 2005). Myöhemmin O'Reilly Median perustaja Tim O'Reilly on määritellyt Web 2.0 -terminsä tarkoittavan sitä tietotekniikassa tapahtunutta vallankumousta, joka on aiheutunut webin käyttämisestä alustana (O'Reilly 2006). Toisin sanoen internet-selaimella käytettävät verkkosovellukset ovat toiminnoiltaan ja käytettävyydeltään saavuttaneet sellaisen pisteen, ne että kilpailevat perinteisten tietokoneelle asennettavien ohjelmien kanssa.

Yleisesti käytetty esimerkki webin alustana toimimisesta on verkkotietosanakirja Wikipedia, jonka pääosin tekstimuotoiset artikkelit ovat verkossa vapaasti luettavissa, kommentoitavissa ja muokattavissa (Wikipedia 2007b). Pidemmälle viety sovellus on Helsingin ammattikorkeakoulu Stadian VIDEOS-tutkimus- ja kehityshankkeessa rakennettu, WWW-selaimella käytettävä videoeditori Fooga. Yhteistä näille toteutuksille on se, että toiminnan kohteena olevat tiedostot - Wikipedian tekstit ja Foogan videot - sijaitsevat WWW-palvelimella, jolloin niille on mahdollista määritellä erilaisia tarkastelu- ja muokkausoikeuksia kaikille verkossa liikkujille. Tiedostot voidaan altistaa toisten käyttäjien vaikutuksille, jolloin niistä tulee avoimen sosiaalisen toiminnan kohteita. Palvelun suunnittelijan tehtäväksi jää päättää niistä välineistä, joita käyttäjillä on luomansa materiaalin jakamisessa tai vastaavasti suojaamisessa. Näiden oikeuksien määritteleminen, toimintojen ja käyttöoikeuksien salliminen tai rajoittaminen, muodostavat merkittävän osan sosiaalisen median palvelun kehitystyöstä.

Sosiaaliseksi mediaksi luettavien palvelujen määrä ja suosio on lyhyessä ajassa lisääntynyt merkittävästi. Esimerkiksi sosiaalista verkottumista tarjoava yhdysvaltalainen Facebook tuplasi syksyllä 2007 suomalaisten käyttäjiensä määrän 60 000:een alle kahdessa viikossa (Mäntylä 2007). Niin ikään yhdysvaltalaisen, valokuvien jakamiseen tarkoitetun Flickrin käyttäjät ympäri maailman julkaisevat palvelun avulla päivittäin noin 8,5 miljoonaa kuvaa (YLE uutiset 2007).

Sitä mukaa kun käyttäjälähtöiseen sisältöön ja sosiaalisuuteen perustuvat verkkopalvelut yleistyvät, niiden toimintamallit ja toiminnallisuudet leviävät ja arkipäiväistyvät. Kun käyttäjät tottuvat tiettyihin toimintatapoihin, he alkavat odottaa totuttuja malleja muiltakin verkkopalveluilta, mikä taas väistämättä vaikuttaa suunnittelutyöhön. Tähän ilmiöön kiinnittää huomiota käyttökokemusasiantuntija ja veteraani-bloggaaja Marjut Mutanen weblogissaan 21.9.2007:

Ne elementit pitää tietää. Niitä halutaan muillekin sivustoille. Olen jo useaan otteeseen kuullut, kuinka tuotteeseen X on saatava "se samanlainen toiminto kuin Facebookissa". Huonoa käytettävyyttä ei kannata matkia, mutta se kokonaisuus ja sen monet pienet osat - ne kannattaa tutkia huolella.
(Mutanen 2007.)

Uusi toimintaympäristö tuo suunnitteluun uusia osa-alueita ja mahdollisuuksia. Ammattitaitoisen suunnittelijan on oltava tietoinen erilaisista vaihtoehdoista, joita palvelujen suunnittelussa voidaan hyödyntää, ja niistä vaikutuksista, joita suunnittelussa tehtävät valinnat voivat aiheuttaa.

4 SOSIAALISEN MEDIAN PALVELUN SUUNNITTELUUN LIITTYVIÄ HAASTEITA

Käyn seuraavaksi läpi sosiaalisen median yleisiä piirteitä, jotka mielestäni vaikuttavat ratkaisevasti palvelun suunnitteluun ja niihin valintoihin, joita suunnittelija joutuu työssään tekemään. Lisäksi esitän niitä erityispiirteitä, jotka tulisi ottaa huomioon yritysympäristöön sijoittuvan sosiaalisen median palvelun suunnittelussa.

4.1 Käyttäjät tuottavat palvelun sisällön

Käyttäjälähtöiseen sisällöntuotantoon perustuvassa palvelussa keskeisenä lähtökohtana on se, mitä sisältöjä tai sisältömuotoja käyttäjä voi palvelussa käsitellä. Yhteisö- ja mikroblogipalvelu Jaikun perustaja Jyri Engeström kutsuu näitä keskeisimpiä toiminnan kohteita sosiaalisiksi objekteiksi (Engeström 2007). Engeström on havainnut, että yhä suurempi osa suosituista verkkopalveluista rakentuu sosiaalisten objektien ympärille, kun taas palvelut, jotka perustuvat perinteisempiin, valmiiksi tuotettuja sisältöjä hyödyntäviin ratkaisuihin, eivät enää menesty entiseen tapaan (Engeström 2007).

Engeström esittää kolme tärkeintä kysymystä, joihin sosiaalisen verkkopalvelun suunnittelijan pitäisi palvelua rakennettaessa pystyä vastaamaan: mikä on objektisi, mitkä ovat verbisi ja kuinka ihmiset voivat jakaa objekteja (Engeström 2006)? Verbeillä Engeström tarkoittaa niitä keskeisimpiä toimintoja, joita käyttäjä voi objekteille palvelun avulla tehdä (Engeström 2006). Olisi siis ihanteellista löytää sellainen materiaalien ja julkaisutapojen yhdistelmä, jonka käyttäjä kokee itselleen tarpeelliseksi ja joka mahdollistaa sisältöihin liittyvän, mielekkään sosiaalisen toiminnan. Lisäksi näiden keskeisten ajatusten tulisi välittyä mahdollisimman selkeästi, kun käyttäjä saapuu palveluun (Engeström 2006).

Havainnollistavana esimerkkinä sosiaalisesta objektista ja sen jakamisesta toimii videopalvelu YouTubeen lisättävä video. Palvelun etusivulle saavuttaessa on selvää, että kyseessä on videoita sisältävä palvelu. Esillä on runsaasti videomateriaalia, josta vierailija voi heti valita videon katsottavakseen. Etusivulla on myös esillä linkki "Upload" - verbi, joka kertoo vierailijalle, että hän voi ladata palveluun omaa materiaalia (ks. kuva 1.). Uutta videota lisätessään käyttäjä voi muun muassa valita, onko video julkisesti kaikkien katsottavissa vai vaihtoehtoisesti vain itse valitun, pienen ryhmän nähtävissä. Jokaisen videon omalta sivulta löytyy muun muassa linkki "Share", joka kertoo, että käyttäjä voi jakaa tiedon löytämästään videosta esimerkiksi sähköposti-ilmoituksella. Videota voi myös arvostella äänestämällä tai kommentoimalla. Lisäksi video on mahdollista upottaa osaksi ulkopuolista verkkosivua tarjolla olevan "Embed"-koodin avulla (ks. kuva 2.). (YouTube 2007.)

YouTuben tarjoamat mahdollisuudet sisällön jakamiseen toimivat myös esimerkkinä sosiaalisen median avoimuuteen perustuvista toimintamalleista, joissa ulkopuolisille toimijoille avataan rajapinta oman palvelun sisältöihin. Eri palvelujen avoimia rajapintoja hyödyntämällä on mahdollista luoda uusia sovelluksia, jotka voivat perustua kokonaan ulkopuolisista palveluista yhdistettyihin sisältöihin.

KUVA 1. Videopalvelu YouTuben etusivu antaa nopeasti kuvan siitä, millaisia sisältöjä sivusto tarjoaa. Oikeassa yläkulmassa oleva linkki "Upload" kertoo, että palveluun voi ladata omia videoita. (YouTube 2007.)

KUVA 2. Videopalvelu YouTuben yksittäisen videon sivulla on videon alla linkki "Share", jonka kautta tiedon löydetystä videosta voi helposti jakaa eteenpäin. Näkyvissä ovat myös videon arvosteluun tarkoitetun äänestysjärjestelmän tähdet ja oikeassa palstassa "Embed"-koodi, jonka avulla videon voi liittää ulkopuoliselle sivustolle. (YouTube 2007.)

Mielestäni Engeströmin ajatus sosiaalisista objekteista toimii konseptointivaiheessa hyvänä lähtökohtana käyttäjälähtöiseen sisällöntuotantoon perustuvan palvelun suunnittelulle. Egströmin kolmeen kysymykseen vastaamalla on mahdollista hahmottaa ne yleiset, nimenomaan käyttäjien aktiivisuuteen tähtäävät suuntaviivat, joita kohti palvelun suunnittelussa edetään. Olen kuitenkin sitä mieltä, että yritysympäristössä toimittaessa on kiinnitettävä erityistä huomiota palvelun lähtökohtien ja tarpeiden määrittelyyn. Erittelen näitä määrityksiä tarkemmin luvussa 4.4.

4.2 Käyttäjät vaikuttavat toistensa sisältöihin

Palveluun lisättyjen objektien ympärille syntyvän sosiaalisen toiminnan luonteeseen vaikuttaa se, millaisia mahdollisuuksia käyttäjillä on vaikuttaa toisten luomaan sisältöön. Olemassa olevia sosiaalisen median palveluja tutkimalla voi löytää esimerkkejä eriasteisista vaikuttamismahdollisuuksista, jotka jakautuvat täysin rajoitetusta täysin avoimeen toimintamalliin.

Google-dokumentit on esimerkki palvelusta, jota käyttäjä voi käyttää henkilökohtaisena työvälineenä jakamatta luomiaan teksti-, taulukkolaskenta- tai esitysdokumentteja muiden käyttäjien kanssa (Google-dokumentit 2007). Näin palvelu voi olla hyödyllinen, vaikka käyttäjä ei hyödyntäisikään sen tarjoamia sosiaalisia ominaisuuksia. Verkkotietosanakirja Wikipedia sen sijaan perustuu täysin avoimeen yhteistoimintaan. Palvelun artikkelit ovat periaatteessa kaikkien käyttäjien muokattavissa, niistä voidaan keskustella ja ristiriitatilanteissa esimerkiksi äänestää parhaan lopputuloksen aikaansaamiseksi.

On olennaista ymmärtää, että edellä mainittujen kahden ääripään väliin on suunniteltavissa valtaisa joukko erilaisia mahdollisuuksia ja yhdistelmiä, joilla käyttäjien voidaan antaa suoraan vaikuttaa toistensa sisältöihin tai kuinka käyttäjien toiminnan kerryttämää dataa voidaan epäsuorasti hyödyntää erilaisten tilastointiin perustuvien ominaisuuksien pohjana.

Esimerkiksi kirjanmerkkipalvelu del.icio.us yhdistää käyttäjän oman hyötynäkökulman ja muiden käyttäjien tuoman sosiaalisen lisäarvon: kun käyttäjä tallentaa palveluun jonkin WWW-osoitteen kirjanmerkiksi, hän voi nähdä, kuinka moni muu käyttäjä on myös merkinnyt sen suosikikseen (ks. kuva 3.). Muiden samasta aiheesta kiinnostuneiden käyttäjien kirjanmerkeistä voi helposti löytyä lisää itseä kiinnostavia linkkejä. Kaiken yhdistetyn käyttäjätiedon perusteella palvelu taas luo reaaliaikaisia listoja suosituimmista sivustoista, jolloin käyttäjät omilla valinnoillaan samalla äänestävät ja luokittelevat WWW-sivustoja (ks. kuva 4.). (del.icio.us 2007.)

KUVA 3. Yksittäisen del.icio.us-käyttäjän sivulla näkyvät käyttäjän omat kirjanmerkit. Jokaiseen kirjanmerkkiin liittyy tieto siitä, kuinka moni muu käyttäjä on merkinnyt saman linkin suosikikseen. Oikeassa palstassa näkyvä "tags"-lista sisältää avainsanoja, joilla käyttäjä on lajitellut omat kirjanmerkkinsä. (del.icio.us 2007.)

KUVA 4. Kirjanmerkkipalvelu del.icio.us listaa etusivullaan linkkejä, joita useat käyttäjät ovat lyhyessä ajassa merkinneet suosikeikseen. (del.icio.us 2007.)

Tämän kaltaisten toiminnallisuuksien suunnittelussa voidaan vaikuttaa siihen, millaiseen yhteisöllisyyteen ja sosiaalisuuteen palvelu tarjoaa mahdollisuuden ja mihin se kannustaa. Esimerkiksi järjestelmän tarjoama äänestystyökalu, jolla voi antaa jollekin sisällölle negatiivisia ääniä, vaikuttaa koko palvelusta syntyvään mielikuvaan. Se voi helposti nostaa kynnystä oman materiaalin julkaisemiseen, ja yritysympäristössä tällainen työantajan tarjoaman työvälineen ominaisuus voisi olla arveluttava.

Eri ominaisuuksien hienosäätö ja palvelun oman hengen löytäminen voi olla työläs ja runsaasti kokeiluja vaativa prosessi. Suunnittelun alkuvaiheessa ongelmaa voi mielestäni lähestyä Jenny Preecen esittämän yhteisöllisyyteen tähtäävän suunnittelun näkökulmasta. Preece esittää, että ensiksi tulee määritellä ne toiminnot ja tehtävät, joita käyttäjien pitää palvelussa kyetä tekemään (Preece 2000, 112). Näiden tehtävien perusteella hahmottuvat ne toiminnallisuudet, joita käytettävän ohjelmiston tulee mahdollistaa, eli ne toimivat pohjana käytettävän ohjelmiston valinnalle tai kehittämiselle (Preece 2000, 220).

4.3 Open Source -julkaisujärjestelmien mahdollisuudet

Yksinkertaisten julkaisujärjestelmien yleistyminen on madaltanut verkkoon julkaisemisen teknistä kynnystä (Majava 2006, 88). Julkaisukäyttöön on saatavilla lukuisia erilaisia blogi-, wiki- ja sisällönhallintaohjelmistoja, joiden avulla erilaisia WWW-sivustoja on mahdollista ylläpitää ilman erityistä teknistä osaamista. Suuri osa näistä ohjelmistoista on maksutta käyttöön otettavia niin sanottuja Open Source -ohjelmia, eli ne perustuvat avoimen lähdekoodin periaatteeseen. Avoin lähdekoodi tarkoittaa käytännössä sitä, että kuka tahansa voi vapaasti käyttää ja kehittää koodia omiin tarkoituksiinsa (Wikipedia, 2007b).

Valmiin Open Source -ohjelman käyttäminen voi huomattavasti vähentää rakennettavaan verkkopalveluun tarvittavaa ohjelmoinnin määrää. Parhaassa tapauksessa omiin tarkoituksiin sopiva, esimerkiksi blogin julkaisemiseen tarkoitettu ohjelmisto on asennettu käyttövalmiiksi yhden henkilön alle työpäivän panoksella. Monimutkaisemman sisällönhallintajärjestelmän asentaminen ja muokkaaminen tarkoituksiin sopivaksi voi kuitenkin vaatia laaja-alaista osaamista ja paljon työtä.

Valmiin ohjelmiston käyttöön liittyy riski, jota olisi hyvä pyrkiä välttämään: on huolehdittava siitä, että ohjelmiston tarjoamat valmiit toiminnallisuudet eivät liiaksi rajoita ja määrittele palvelun suunnittelua, vaan ensiksi on määriteltävä palvelulta vaadittavat ominaisuudet, joiden mukaan ohjelmisto muokataan käyttöön soveltuvaksi.

4.4 Sosiaalinen media yritysympäristössä

Sosiaalisen median suosion myötä verkkoon syntyy paljon uusia palveluja, jotka kilpailevat käyttäjien ja sijoittajien huomiosta. Alalla liikkuu runsaasti riskirahoitusta, vaikka suurella osalla palveluista ei ole selkeää, jatkuvuuteen tähtäävää ansaintalogiikkaa (Kangas ym. 2007, 37). Yhtenä ansaintamallina onkin runsaasti käyttäjiä keräävän palvelun rakentaminen ja sen myyminen jollekin suuremmalle toimijalle, esim. Googlelle (Kangas ym. 2007, 37). Vaikka tällaisella uskaliaalla kehitystoiminnalla onkin paikkansa innovaatioiden synnyttämisessä, haluaisin itse kehittää sellaista suunnittelu- ja projektiosaamista, jolla sosiaalisen median toimintamalleja viedään asiakasyrityksiin, ja niitä kehitetään tavoitteellisesti yhteistyössä asiakkaan kanssa.

Mikromod-hankkeessa rakennettava palvelu sijoittuu yrityksen suljettuun ympäristöön. Näin ollen palvelu tulee osaksi jo olemassa olevaa organisaation sisäistä verkkoviestintämallia ja yrityskulttuuria. Tällaisessa tilanteessa pelkkä innovaatiokeskeinen lähestymistapa ei toimi, vaan myydäkseen palvelun asiakkaalle tulee toimittajan kyetä perustelemaan, mitä lisäarvoa tarjottavalla mallilla voidaan saavuttaa. Käytettävien sisältöobjektien ja toiminnallisuuksien lisäksi olisi hyvä huomioida myös perinteisesti palvelukonseptiin kuuluvia asioita, kuten palvelun tavoitteet, kohderyhmä ja brandi, eli millaisia mielikuvia palvelulla halutaan välittää (Jussila & Leino 2001, 127).

Itellassa olemassa olevien sisäisten verkkoviestintätyökalujen kirjo on laaja. Yrityksellä on noin 25 000 työntekijää ja runsaasti eri toimintoja ja erilaista liiketoimintaa. Tästä aiheutuen myös erilaisia tietojärjestelmiä on paljon. Toisaalta konsernissa on käytössä tarkat graafiset ohjeet, jotka määrittelevät tarkasti verkkotyökalujen ulkoasua. Uuden palvelun lisäämisessä voidaan soveltaa esimerkiksi kahta vastakkaista strategiaa. Palvelu voidaan sovittaa nykyisen ympäristön osaksi, tai sen uutuusarvoa voidaan korostaa tekemällä siitä huomiota herättävän poikkeava totuttuun linjaan verrattuna.

Yritysympäristö tuo suunnittelutyöhön muitakin haasteita. Riippuen kohderyhmän laajuudesta voi olla vaikeaa saavuttaa ns. kriittinen massa, eli riittävä määrä aktiivisia käyttäjiä, joka saa palvelun vaikuttamaan kiinnostavalta ja osallistumisen arvoiselta (Preece 2000, 171). Eräs arvio verkkoyhteisöjen aktiivisten osallistujien ja hiljaisten seuraajien välisestä suhteesta on n. 1:100 (Preece 2000, 87). Näin ollen esimerkiksi kahdenkymmenen aktiivisen osallistujan löytyminen vaatisi palvelulle 2000:n käyttäjän käyttäjäpohjan. Uskon kuitenkin, että palvelun sijoittuminen suljettuun ympäristöön voi huomattavasti laskea osallistumiskynnystä ja että esimerkiksi aktiivisella ylläpidolla palvelun mielenkiintoa voidaan ylläpitää pienemmälläkin käyttäjämäärällä. Itellan tapauksessa suuren organisaation käyttäjäpohja tarjoaa ainakin teoriassa mahdollisuuden aktiivisen verkkoyhteisön syntymiseen.

Sosiaalisen median toimintamallien käyttöönotto voi myös vaatia organisaatiolta uudenlaista suhtautumista avoimuuteen ja luottamukseen (Kokkonen 2007). Tavoiteltava käyttäjälähtöinen toimintatapa voi poiketa suurestikin olemassa olevasta yrityskulttuurista, jolloin sopeutumista vaaditaan niin yrityksen johdon kuin käyttäjienkin osalta. Edellä mainitsemani osallistumiskynnyksen laskeminen vaatii sen, että käyttäjät kokevat palveluun osallistumisen turvalliseksi ja luottavat tuottamansa sisällön avoimeen käsittelyyn. Työnantajalta vaaditaan luottamusta käyttäjien hyväntahtoisuuteen ja toisaalta kykyä käsitellä mahdollisia esille nousevia negatiivisiakin asioita rehellisesti ja avoimesti (Kokkonen 2007). Joissain organisaatioissa tämä voi vaatia perinpohjaista muutosta, joka ei varmasti toteudu nopeasti, eikä se välttämättä ole asiakasyrityksen tavoitteenakaan. Suunnittelijan on kuitenkin hyvä tiedostaa, millaisten syvälle yrityskulttuuriin ulottuvien seikkojen kanssa suunnittelutyössä saatetaan joutua tekemisiin.

Itellan tapauksessa lähtökohdat käyttäjälähtöisen sisällöntuotannon kokeilemiselle ovat suotuisat. Yrityksessä käytetään runsaasti verkko-opetusta, ja useat verkkokurssit edellyttävät opiskelijoilta omien tuotosten esittelyä verkko-oppimisympäristössä. Lisäksi Itellassa on testattu wiki-alustaa erilaisissa sisäisen viestinnän tehtävissä. Toisaalta vapaan verkkokeskustelun rakentavuudesta on vanhassa intrassa sijainneen keskustelufoorumin perusteella eriäviä mielipiteitä. Foorumilla esitetyt kriittiset puheenvuorot ovat herättäneet ristiriitaista suhtautumista kyseiseen työvälineeseen, mikä voi aiheuttaa epäilyä avointen alustojen mahdollisuuksista. Joka tapauksessa Alissan kaltainen toimintaympäristö poikkeaa huomattavasti yrityksen entisistä toimintamalleista, joten kaikkien palvelun kanssa tekemisissä olevien tahojen tiedottaminen ja toimintamallin markkinoiminen vaatii paljon työtä.

5 JOUSTAVA SUUNNITTELUMALLI GETTING REAL

Edellä esittämäni sosiaalisen median ominaisuudet tarkoittavat käytännössä sitä, että rakennettava palvelu muodostuu useista toisiinsa vaikuttavista osatekijöistä, joiden yhteen sovittaminen toivotulla tavalla voi vaatia runsaasti kokeilemista ja hienosäätöä. Tästä johtuen perinteinen verkkojulkaisun suunnitteluprosessi ei mielestäni sellaisenaan sovi käyttäjälähtöiseen sisällöntuotantoon tähtäävän palvelun suunnittelun lähtökohdaksi.

Perinteisessä käsikirjoituspohjaisessa lähestymistavassa projektin alkuvaiheessa tuotetaan joukko dokumentteja ja käsikirjoituksia, joiden perusteella palvelu rakennetaan ja jotka toimivat myös kommunikoinnin ja projektinhallinnan välineinä (Keränen ym. 2005, 29.36). Voi kuitenkin olla erittäin vaikeaa käsikirjoittaa valmiiksi palvelun kaikkia ominaisuuksia ja aikatauluttaa työvaiheita siten, että suunnitelmien pohjalta laadittu palvelu ja suunnitelmaa toteuttava työryhmä toimisivat toivotulla tavalla (Wikipedia 2007c). Ohjelmistokehityksessä tätä ongelmaa pyritään välttämään ns. ketterien menetelmien avulla.

Ketterät menetelmät ovat joukko erilaisia ohjelmistokehitysmalleja, jotka painottavat kehitystyössä toimivan ohjelmiston ensisijaisuutta, suoraa viestintää ja nopeaa muutoksiin reagoimista. Yleisenä ketteränä toimintatapana on kehitystyön jakaminen useisiin pieniin osiin, jolloin jokaisen osakokonaisuuden eli iteraation lopussa on mahdollista arvioida edistymistä ja määritellä seuraavan kokonaisuuden sisältö. Etenemisen säännöllinen arvioiminen mahdollistaa sen, että projekti voi tarvittaessa joustavasti muuttaa suuntaansa. (Wikipedia 2007c.)

Ketterien menetelmien ihanteita noudattelee myös yhdysvaltalaisen web-sovellusten kehittämiseen erikoistuneen 37signals-yrityksen työskentelytapa, joka kuvataan kirjassa Getting Real: The smarter, faster, easier way to build a successful web application (2006). Getting Real ei ole varsinainen suoraan sovellettava menetelmä, vaan suunnittelu- ja projektityöskentelyn lähtökohtiin paneutuva, välillä tarkoituksellisenkin provokatiivinen manifesti. Valitsin Getting Realin opinnäytteeseeni tarkasteltavaksi, koska koska mielestäni sen esittämät työtavat ovat helposti omaksuttavissa ja sovellettavissa nimenomaan kohtalaisen kevyen verkkopalvelun suunnitteluprosessiin. Käyn seuraavaksi läpi niitä Getting Real -ajatuksia, jotka erityisesti koskettavat Alissa-projektia.

5.1 Suunnittelutyön lähtökohdat

37signals toteuttaa verkon välityksellä käytettäviä yhteistoiminnallisia ja organisointia helpottavia, esimerkiksi projektinhallintaan ja viestintään suunnattuja sovelluksia. Lähtökohtana useille yrityksen tarjoamille sovelluksille on ollut oman työskentelyn tehostaminen, ja 37signalsin mielestä ihanteellinen kehitysprojekti onkin sellainen, joka pohjautuu kehittäjätiimin oman, yhteisen ongelman ratkaisemiseen (37signals 2006, 17).

Lähteinä käyttämieni suunnitteluoppaiden suunnitteluprosessit lähtevät siitä oletuksesta, että suunniteltava palvelu toteutetaan järjestelmällisesti tilaajan tai yritysasiakkaan tarpeiden perusteella (Alamäki & Luukkonen 2002, 194; Jussila & Leino 2001, 118; Keränen ym. 2005, 52). Vaikka perinteistä suunnitteluprosessia voi luonnollisesti hyödyntää myös omasta tarpeesta lähtevään suunnitteluun, on Getting Realin painotus kuitenkin oleellinen, koska se korostaa omasta tarpeesta syntyvää motivaatiota ja henkilökohtaista suhdetta rakennettavaan sovellukseen.

Getting Realin tavoitteena olevaa intohimoista ja motivoitunutta suhtautumista työhön ei perinteisissä prosessikuvauksissa sivuta. Perinteinen malli perustuu hierarkkiseen projektijohtamiseen, kun taas Getting Real ohjaa avoimuuteen, yhteistyöhön ja hierarkian minimoimiseen. Tällainen toimintamalli voidaan nähdä seurauksena juuri sosiaalisen median taustana olevan avoimen yhteistoiminnallisuuden lisääntymisestä (Tapscott & Williams 2006, 20). Siksi perinteisen mallin soveltaminen sosiaalisen median palvelun suunnittelussa tuntuu lähtökohtaisesti vieraalta. Getting Realin osalta haasteeksi muodostuu se, kuinka tavoiteltava motivaatio synnytetään esimerkiksi ulkopuolisen tilaajan tarpeita ratkaistaessa. Mielestäni Getting Realin esittämät työtavat voivat kuitenkin oikein sovellettuina edistää työryhmän tehokkuutta myös erilaisia ulkopuolisia toimeksiantoja toteutettaessa.

5.2 Vahva visio ohjaa työskentelyä

Kun ideoitua sovellusta aletaan toteuttaa, Getting Real esittää, että suunnittelun pohjaksi kannattaa rakennettavasta ohjelmistosta muodostaa yhden lauseen tiivis visio, joka kertoo, miksi sitä rakennetaan. Esimerkiksi projektinhallintatyökalu Basecampia suunniteltaessa 37signalsin visio oli "Projektinhallinta on viestintää". Tämän ajatuksen pohjalta syntyi kommunikointityökaluja painottava verkkosovellus, joka rohkaisee kaikkia projektin osapuolia osallistumaan projektin suunnitteluun. (37signals 2006, 42.43.) Getting Realin mukainen visio on kuin iskulause, jossa tiivistyy rakennettavan palvelun merkitys ja erityisyys ja johon koko työryhmä sitoutuu. Näin ollen visio on motivaation vahvistamista ja suuntaamista edesauttava väline. Se toimii käytännön ohjenuorana, kun työryhmä punnitsee suunnitteluprosessin aikana eteen tulevia valintoja.

Perinteisessä toimintamallissa palvelun idea tiivistetään kirjalliseen, 1.2-sivuiseen dokumenttiin eli synopsikseen, joka antaa lukijalle kuvan siitä, millaista palvelua ollaan rakentamassa (Keränen ym. 2005, 30). Synopsiksen tulisi siksi olla jo niin selkeä ja yksiselitteinen, että sen sisältämät ideat voidaan laajentaa kattavammiksi käsikirjoituksiksi (Keränen ym. 2005, 30.34). Getting Realissa palvelun kehitys alkaa kuitenkin suoraan yleisen tason vision pohjalta, eikä edes synopsiksen laajuista suunnitelmaa näin ollen katsota tarpeelliseksi.

5.3 Nopea ja joustava työtapa

Määritellyn vision toteuttaminen aloitetaan mahdollisimman kevyesti, yksinkertaisesti ja nopeasti. Ohjelmiston ensimmäisen version toteuttaa yksi työryhmä, jossa ihannetilanteessa on kolme jäsentä: yksi tekninen suunnittelija, yksi graafinen suunnittelija ja yksi molempia osa-alueita hallitseva suunnittelija. Tavoitteena on pieni, yhtenäinen ryhmä, jossa viestintä toimii tehokkaasti ja jonka tarkoituksellisesti rajalliset resurssit pakottavat keskittymään olennaiseen. (37signals 2006, 30.38.) Ihanteena on myös, että määriteltyjen päävastuiden lisäksi työryhmän jäsenet hallitsevat suunnittelusta useita eri osa-alueita aina asiakasviestinnästä lähtien, eikä kukaan keskity vain pienen erityisalueen toteuttamiseen (37signals 2006, 96). Tämä mahdollistaa joustavan resurssien kohdentamisen ja työskentelyn yli työtehtävärajojen suunnittelun edetessä.

Perinteisessä multimediatuotannon mallissa projektin alussa arvioidaan työn laajuus ja tarvittavat resurssit. Resurssit aikataulutetaan työtehtävien mukaisesti sopiviin vaiheisiin, jolloin eri osa-alueista vastaavat työntekijät toteuttavat oman osuutensa kokonaisuuden kannalta sopivalla hetkellä. (Jussila & Leino 2001, 118; Keränen ym. 2005, 38.) On selvää, että perinteisenkin mallin mukaan toimittaessa tapahtuu työtehtävärajat ylittävää työskentelyä, mutta Getting Real ei erittele ja aikatauluta eri tehtäviä ja työvaiheita valmiiksi, vaan se olettaa, että riittävän pieni mutta laaja-alainen ryhmä kykenee itsenäisesti jakamaan tehtäviä ja seuraamaan etenemistään työn edetessä.

Getting Real suosittelee heti suunnittelun alkaessa tavoittelemaan ohjelman ensimmäistä toimivaa versiota. Yksityiskohtiin ei kannata alussa kiinnittää liikaa huomiota, vaan pitää keskittyä keskeisimpien toimintojen toteuttamiseen. Tärkeintä on saada nopeasti aikaiseksi jotain konkreettista, jonka herättämän palautteen pohjalta alkaa seuraava kehityskierros. (37signals 2006, 44.45.) Toimiva ohjelma antaa työlle vauhtia, koska se johtaa aitoihin reaktioihin ja palautteeseen toisin kuin paperille laaditut suunnitelmat (37signals 2006, 66). Kehitystyö perustuu siis ketterien menetelmien mukaisiin iteraatioihin, jolloin jokaisen kehitysvaiheen tavoitteena on aina toimiva, edellistä versiota kehittyneempi sovellus.

Perinteisessä lähestymistavassa on tavoitteena suunnitella palvelu kokonaan ennen tuotantovaihetta. Tuotantovaiheen ohjeeksi laadittavan tuotantokäsikirjoituksen tulisi sisältää kaikki palvelun ominaisuudet, ulkoasun ja yksityiskohdat yksiselitteisesti määriteltyinä siten, että tuotantotiimi voi toteuttaa palvelun valmiiksi suunnitelman pohjalta. (Jussila & Leino 2001; 116; Keränen ym. 2005, 34.)

5.4 Keveyttä dokumentaatioon ja rakennettavaan palveluun

Getting Real suosittelee välttämään kaikkea ylimääräistä dokumentaatiota. Liian tarkat alkumääritykset ja käsikirjoitukset pakottavat tekemään tärkeimmät päätökset silloin, kun käytettävissä on vähiten informaatiota. Siksi suunnittelun alussa ei pitäisi yrittääkään tehdä kovin yksityiskohtaisia suunnitelmia. Ellei laadittava dokumentti ole jotain, joka muotoutuu joksikin todelliseksi ohjelmiston osaksi, sitä ei Getting Realin mukaan pidä tehdä ollenkaan. Esimerkiksi käyttöliittymäsuunnittelussa voidaan laajojen paperiprototyyppien sijasta käyttää HTML-koodausta, koska HTML muotoutuu työn edetessä palvelun osaksi. Palvelun toiminnallisuuksia kuvaavien dokumenttien sijasta taas ohjelmiston kehittämisessä on tehokkaampaa käyttää lyhyitä toiminnan kuvauksia, jotka kertovat, kuinka ohjelma jossain tietyssä tilanteessa toimii. Näiden avulla on helpompi hahmottaa ne ominaisuudet, joita todella ollaan tavoittelemassa. (37signals 2006, 100, 126.131.)

Dokumentaation minimoiminen on ristiriidassa perinteisen suunnitteluprosessin kanssa. Varsinkin yritysmaailmassa tietty dokumentaatioon ja käsikirjoitusmalleihin pohjautuva projektimalli on syvälle juurtunut. Jos asiakas odottaa projektin alkuvaiheessa saavansa synopsiksen ja asiakäsikirjoituksen, pitää tämä ristiriita ratkaista jotenkin. Jos halutaan toimia kevyesti turhaa dokumentaatiota välttäen, on asiakkaalle kyettävä perustelemaan käytettävän työtavan toimivuus ja edut perinteiseen verrattuna. Jos asiakas saa dokumenttien sijasta suoraa viestintää, nopeammin toteutetun palvelun ja enemmän vaikutusmahdollisuuksia lopputulokseen, voi uusi työtapa olla kokeilemisen arvoinen.

Suunnitteluryhmän rajalliset resurssit ja tavoite nopeasti toteutettavasta ensimmäisestä versiosta pakottavat karsimaan ohjelmiston ominaisuuksia ja miettimään jokaisen ominaisuuden kohdalla sen todellista tärkeyttä ja hyötyä käyttäjälle. Jokaisen uuden ominaisuuden lisääminen aiheuttaa välillisesti paljon työtä ja kasvattaa ohjelman massaa ja hallittavuutta. Getting Realin mukaan ei pitäisikään kysyä, mitä uusia ominaisuuksia ohjelma kaipaa, vaan mitä siitä voisi ottaa pois, että se olisi vieläkin yksinkertaisempi ja toimivampi (37signals 2006, 54.64).

Yksinkertaisuuteen pyrkiminen on varmasti eduksi toimivaa verkkopalvelua tavoiteltaessa. Hakukone Googlen perushakusivu on tästä erinomainen esimerkki. Sivulla on esillä tiedon hakemiseen tarvittavat elementit - tekstikenttä hakutermeille ja haun käynnistävä painike eikä juuri muuta (Google 2007). Yksinkertaisuus vähentää käyttöoppaiden kirjoittamista ja käyttäjien tukipyyntöjä, eli juuri lisäominaisuuksien aiheuttamaa välillistä työtä. On luonnollisesti selvää, että perinteiselläkin suunnitteluprosessilla voidaan tavoitella ja toteuttaa yksinkertaisia sovelluksia. Getting Realin toimintamalli kuitenkin ohjaa alusta lähtien yksinkertaisuuteen ja pienentää sitä mahdollisuutta, että alkusuunnittelussa määriteltyjä ominaisuuksia ei saada tuotantovaiheessa toteutettua, koska ne osoittautuvat oletettua laajemmiksi kokonaisuuksiksi.

Yritysympäristössä haasteena on se, kuinka Getting Realin mukaisen kehitystiimin työskentelyä ohjataan haluttuun suuntaan. On tärkeää, että työryhmän tavoitteet on asetettu kaikkien projektin osapuolten yhteisellä päätöksellä. Myös ryhmän edistymistä tulee säännöllisesti seurata eri iteraatioiden välissä, ja seuraavan iteraation prioriteetit pitää sopia yhteisesti eri osapuolten kesken.

6 MIKROMOD-HANKKEEN PILOTTI ALISSA

Mikromod-hanke käynnistyi tammikuun puolivälissä (15.1.2007) avauskokouksella, johon eri osapuolet kokoontuivat esittäytymään ja suunnittelemaan hanketta. Kokouksessa määritellyn alustavan aikataulun mukaan tavoitteena oli saada kesän alkuun mennessä valmiiksi mikromoduleihin perustuvan palvelun pilottiversio, jota käyttäen syksyllä tehtäisiin ensimmäinen toteutus käyttäjien kanssa. Hankkeen tematiikaksi hahmoteltiin Itellan työntekijöiden työhyvinvointiin ja ergonomiaan liittyvän hiljaisen tiedon kartoittaminen ja hyvien käytäntöjen levittäminen.

6.1 Projektin osallistujat

Itellassa hankketta koordinoi neljän hengen e-learning-tiimi, joka vastaa konsernin verkkopohjaisesta henkilöstön kehittämisestä. Ensimmäisissä kokouksissa paikalla oli koko tiimi, mutta työn edetessä hankkeen päävastuu siirtyi henkilöstökonsultti Outi Heikkilälle. Muut tiimin jäsenet osallistuivat työskentelyyn tarvittaessa omaan erityisosaamiseensa liittyvissä kysymyksissä.

Stadian työryhmään kuuluivat hankkeen alkuunpanijat, verkkoviestinnän lehtorit Matti Rantala ja Juhana Kokkonen, hankekoordinaattori Sari Penttilä sekä minun lisäkseni viisi toisen vuoden verkkoviestinnänopiskelijaa. Itse suoritin hankkeessa kolmannen vuoden opiskelijana myös työharjoitteluani. Opiskelijoiden työskentelyä ohjasi aluksi pääasiassa Juhana Kokkonen.

6.2 Työn eteneminen

Esittelen seuraavaksi Alissan suunnitteluprosessin ja esitän huomioita työn etenemiseen. Samalla esitän Gettin Realiin perustuvia, vaihtoehtoisia toimintamalleja.

6.2.1 Ensimmäiset konseptihahmotelmat

Avauskokouksen jälkeen Stadian työryhmän ensimmäisenä tehtävänä oli suunnitella muutama alustava konseptihahmotelma, joiden pohjalta palvelua kehitettäisiin eteenpäin. Syntyneet konsepti-ideat, "Medialego" ja "Toimintakortti", esiteltiin Itellalle helmikuun puolivälissä (12.2.2007) pidetyssä kokouksessa (ks. kuvat 5&6.). Esitellyistä ideoista Medialego perustui käyttäjien tuottamiin, tekstiä, kuvia ja videota sisältäviin materiaalipaketteihin, joita muut käyttäjät voivat kommentoida, luokitella ja suositella edelleen. Toimintakortti perustui enemmän valmiiden tietopakettien yhdistelemiseen erilaisiksi toiminnallisiksi kokonaisuuksiksi, joita voidaan käyttää esim. työntekijän perehdyttämiseen. Teknisenä ratkaisuna esitettiin, että tuleva palvelu toteutetaan jonkin avoimeen lähdekoodiin perustuvan eli Open Source -pohjaisen sisällönhallintajärjestelmän avulla.

Kokouksen jälkeen Itellan e-learning-tiimin tehtäväksi jäi pohtia esiteltyjen ideoiden toteuttamiseen liittyviä haasteita ja esitellä ajatukset Itellan työhyvinvointiyksikölle. Stadian työryhmä puolestaan keskittyisi sopivan teknisen alustan etsimiseen.

KUVA 5. Konseptihahmotelma Toimintakortti.

KUVA 6. Konseptihahmotelma Medialego.

6.2.2 Julkaisutyökalujen kartoitus

Helmikuun lopulla (26.2.2007) valmistui tekemäni hankkeen käyttöön mahdollisesti soveltuvien Open Source -julkaisutyökalujen kartoitus. Valitsin noin 70:n pinnallisesti testaamani julkaisujärjestelmän joukosta 20 järjestelmää, joiden ominaisuuksia ja soveltuvuutta oli tarkoitus testata ja dokumentoida tarkemmin osana hankkeen teknistä kehitystyötä. Työharjoitteluni ansiosta minulla oli runsaasti aikaa toteuttaa kartoitus, mutta muilla opiskelijoilla ei tänä aikana ollut hankkeeseen liittyviä työtehtäviä.

Jälkeenpäin arvioituna olisi mielestäni ollut parempi, jos opiskelijaryhmä olisi jo tässä vaiheessa jakautunut työtehtävien mukaisiin vastuualueisiin. Esimerkiksi tekniikasta ja graafisesta suunnittelusta vastaava kolmen hengen ryhmä olisi voinut toteuttaa julkaisutyökalujen kartoituksen. Tämä olisi luonut pohjaa ryhmän jatkotyöskentelylle, ja alustan valinta olisi ollut askeleen lähempänä. Uskon myös, että motivaatio projektia kohtaan olisi kasvanut, jos tarjolla olisi koko ajan ollut projektiin liittyviä tehtäviä.

6.2.3 Sisällön ja kohderyhmän määrittely

27.2.2007 pidetty kokous oli merkittävä askel palvelun sisällöllisessä kehittämisessä. Paikalla oli Itellan työhyvinvointiyksikön edustaja, joka kommentoi aiemmin esiteltyjä konsepteja ja esitti näkemyksiä työhyvinvointiin liittyvän materiaalin jakamisesta. Alustavista konsepteista Medialegon toiminta-ajatus todettiin jatkokehitykseen soveltuvaksi. Keskustelujen lomassa syntyi ajatus Itellan varhaisjakajien ottamisesta toteutettavan pilottipalvelun kohderyhmäksi. Varhaisjakajat olisivat haasteellinen ja yleensä tavallista vähäisemmälle huomiolle jäävä kohderyhmä, joka tekee työtään itsenäisesti juurikaan työtovereita näkemättä. Jakajille räätälöidyn verkkopalvelun avulla heillä olisi mahdollisuus jakaa ajatuksiaan ja keskustella kollegoiden kanssa.

Kokouksen jälkeen Itellan seuraavaksi tehtäväksi jäi tulevien sisältöjen suuntaviivojen määrittely työhyvinvointiyksikön ja varhaisjakelun edustajien kanssa. Stadian työryhmän tehtävänä oli paneutua edelleen teknisen alustan valintaan alustavan kartoituksen pohjalta.

Tässä vaiheessa tulevan palvelun yleiset linjaukset olivat jo tiedossa. Stadian työryhmän resursseja ei kuitenkaan vielä saatu kohdistettua mihinkään konkreettiseen tekemiseen, koska Itellan sisäinen määrittely oli kesken. Ajatuksena oli, että palvelun rakentaminen alkaisi toden teolla sisältöjen määrittelyn jälkeen. Getting Realin mukaan itse palvelun kehittämiseen tarvittava tieto oli kuitenkin jo käytössä. Alkuideoinnin pohjalta olisi voitu kiteyttää palvelulle yksinkertainen visio, jonka perusteella toteuttava kolmen hengen työryhmä olisi voinut aloittaa palvelun rakentamisen valitsemansa alustan pohjalta.

6.2.4 Stadian suunnitteluryhmän ohjattu työskentelytapa

Maaliskuun puolivälissä Stadian työryhmän vetovastuuta muutettiin siten, että minä ja projektikoordinaattori Sari Penttilä otimme vastuullemme opiskelijaryhmän ohjaamisen. Maaliskuun puolivälissä järjestimme opiskelijoiden kanssa tapaamisen, jonka tarkoituksena oli selventää projektin työnjakoa ja aikataulua. Sovimme jokaiselle opiskelijalle oman vastuualueen, minkä jälkeen työryhmässä oli yksi graafisesta suunnittelusta ja käyttöliittymäsuunnittelusta vastaava opiskelija, yksi käsikirjoittaja, yksi pedagoginen suunnittelija ja kaksi tekniikasta vastaavaa opiskelijaa. Näiden työtehtävien perusteella olimme myös laatineet projektille loppukevääksi karkean kuukausitason projektisuunnitelman. Projektisuunnitelman tarkoituksena on yleisesti määritellä suunnittelulle aikataulu ja selventää tarvittavan työn määrää (Jussila & Leino 2001, 118).

Valitsemamme työtapa perustui perinteiseen multimediatuotannon prosessiin. Määrittelimme opiskelijoille tietyt päävastuualueet, joihin liittyen odotimme työn tuloksena tiettyjä dokumentteja. Ensimmäiseksi tehtäväksi asetimme kattavan konseptisuunnitelman, joka kokoaisi yhteen kevään aikana Itellan kanssa kehitellyt ajatukset rakennettavan palvelun ominaisuuksista ja sisältäisi myös teknisiä rajauksia. Konseptisuunnitelman tarkoituksena on antaa tiivis kuvaus palvelun ideasta ja toiminnallisuuksista sekä määritellä myös tulevia sisältöjä (Jussila & Leino 2001, 118). Tavoitteenamme oli luoda kaikille projektin osapuolille yhteinen näkemys siitä, mitä seuraavaksi alkaisimme toteuttaa.

Konseptisuunnitelman ideat oli tarkoitus konkretisoida asiakäsikirjoituksessa. Asiakäsikirjoitus on multimediatuotannoissa käytettävä dokumentti, josta saa selvän kuvan valmiista palvelusta ja jota käytetään projektin osapuolten välisessä kommunikoinnissa (Keränen ym. 2005, 31). Lisäksi tuotantovaihetta varten toteutetaan yleensä tuotantokäsikirjoitus, joka toimii työohjeena palvelun teknisille toteuttajille ja graafiselle suunnittelijalle (Keränen ym. 2005, 34). Muita käsikirjoituksia oli tarkoitus tuottaa myöhemmin toteutettavia työhyvinvointiin liittyviä materiaaleja varten.

Tekniikasta vastaavien opiskelijoiden piti tehdä raportti testattujen Open Source .alustojen ominaisuuksista, palvelun tekninen määrittely ja dokumentaatio valitun alustan käyttöönotosta. Käyttöliittymäsuunnittelijan tehtävänä oli tuottaa käyttöliittymäsuunnitelma ja palvelun graafinen ulkoasu.

Koska toteutettavan palvelun yhtenä tavoitteena oli hyvien käytäntöjen levittäminen, eli tarkoituksena oli ainakin jossain määrin saavuttaa verkon välityksellä tapahtuvaa oppimista, päätimme liittää palveluun myös pedagogisen määrittelyn. Pedagoginen määrittely on e-learning-projekteissa käytettävä suunnitelma palvelussa käytettävistä pedagogisista keinoista (Alamäki & Luukkonen 2002, 193). Sen tarkoituksena on muodostaa käsitys siitä, millaista tietoa halutaan välittää ja mitä keinoja tämän tiedon välittämiseen voidaan käyttää (Alamäki & Luukkonen 2002, 197).

Käsikirjoituksiin perustuva työskentely ei toteutunut suunnitellulla tavalla. Projektisuunnitelmassa mainituista kahdeksasta dokumentista valmistui suunnitteluvaiheessa kaksi - konseptisuunnitelma ja graafinen suunnitelma, joista graafinen suunnitelma valmistui niin myöhään, ettei sitä hyödynnetty palvelun suunnittelussa. Getting Realin mukaan suuresta osasta suunnitteludokumentteja olisi voitu luopua jo aloitusvaiheessa. Näin työ olisi voitu nopeammin kohdistaa varsinaisen palvelun kehittämiseen.

6.2.5 Sisällön tarkentuminen

Toteutettavien sisältöjen tarkentamiseksi järjestettiin maaliskuun lopulla (27.3.2007) workshop, johon osallistui Stadian työryhmän lisäksi Itellan työhyvinvointiyksikön ja varhaisjakelun edustajat. Kokoontumisessa vaihdettiin ajatuksia varhaisjakajien työnkuvasta ja heille suunnattavista sisällöistä sekä työhyvinvointiin ja .turvallisuuteen liittyvistä aiheista. Lisäksi syntyi ajatus kohderyhmää kartoittavan kyselyn toteuttamisesta.

Projektin seuraaviksi välitavoitteiksi sovittiin konseptisuunnitelman valmistuminen ja käyttäjäkyselyn toteuttaminen. Kyselyllä haluttiin muun muassa selvittää käyttäjien valmiuksia ja tiedustella kiinnostavia aiheita tuleville sisällöille.

Kyselylomakkeen toteutti toinen palvelun teknisestä suunnittelusta vastaavista opiskelijoista siten, että minä pyysin lomakkeeseen kommentteja useilta Stadian opettajilta, ja lomaketta muokattiin useaan kertaan kommenttien perusteella. Myös Itellan puolelta tuli muokkauspyyntöjä, jotka luonnollisesti toteutettiin.

Suunnittelutyö keskittyi siis edelleen palvelun alkumäärityksiin ja rajauksiin, vaikka ajallisesti oltiin jo yli puolivälissä pilottipalvelun suunnittelussa. Konseptisuunnitelman hiomiseen käytettiin runsaasti aikaa, koska siinä haluttiin määritellä tulevan palvelun toimintaa mahdollisimman tarkasti, mikä kuitenkin luvussa 5 esittelemieni sosiaalisen median piirteiden vuoksi osoittautui hyvin vaikeaksi. Lisäksi käyttäjäkyselyn muokkaaminen sitoi toisen teknisen suunnittelijan työpanoksen tärkeällä hetkellä, kun alustan valinta oli vielä kesken.

Mikäli alustan kehitys olisi aloitettu aikaisemmin esittämälläni tavalla, olisi laajan konseptisuunnitelman sijasta voitu tässä vaiheessa jo tutustua varsinaisen palvelun ensimmäiseen versioon, kerätä kaikkien osapuolten kommentit ja päättää seuraavan iteraation sisällöstä. Itellan kanssa tapahtuvaa määrittelytyötä ja käyttäjäkartoitusta tekemään olisi riittänyt käsikirjoittajan ja pedagogisen suunnittelijan työpanos.

6.2.6 Konseptisuunnitelman valmistuminen

Konseptisuunnitelma valmistui 5.4.2007, ja se toimitettiin kaikille hankkeen osallistujille tutustumista varten. Suunnitelma käsiteltiin 10.4.2007 Stadian ja Itellan yhteisessä tapaamisessa, ja se hyväksyttiin palvelun kehittämisen pohjaksi.

Huomionarvoista on, että hankkeen aloituksesta oli tässä vaiheessa kulunut n. neljä kuukautta, ja pilottipalvelun valmistumiseen oli aikataulun mukaan jäljellä n. 1,5 kuukautta. Tämä selittää osaltaan sen, miksi kaikkia konseptisuunnitelman jälkeen laadittaviksi tarkoitettuja dokumentteja ja käsikirjoituksia ei saatu valmiiksi. Jos dokumentit olisi laadittu siinä laajuudessa ja tarkkuudessa, että ne olisivat sisältäneet rakennettavan palvelun toteuttamiseen tarvittavat määritykset, ei itse palvelua olisi enää ehditty toteuttaa.

6.2.7 Palvelun ensimmäinen versio

Stadian työryhmän palaverissa huhtikuun lopulla (24.4.2007) todettiin useita edistysaskeleita palvelun rakentamisessa. Testattaviksi valitut sisällönhallintajärjestelmät oli asennettu, alustava graafinen suunnitelma oli valmis, tulevia sisältökokonaisuuksia oli ideoitu runsaasti ja käyttäjäkysely oli pieniä muutoksia vaille valmis. Kyselyn valmistuminen oli viivästynyt runsaiden muokkauspyyntöjen ja lomakkeen tekijän työkiireiden takia. Kysely saatiin jakoon kohderyhmälle 26.4.2007.

Edistymisestä huolimatta palvelun pilotoitavan version valmistumisella alkoi olla kiire. Opiskelijoiden kesälomaan oli aikaa noin kuukausi, eikä varsinainen palvelu ollut vielä konkretisoitunut konseptisuunnitelmaa tarkemmalle tasolle. Seuraavaan, noin kahden viikon päästä pidettävään tapaamiseen mennessä tehtäviä töitä oli paljon, ja opiskelijoilla oli kiireitä muidenkin kurssien suoritusten ja ansiotöiden kanssa.

9.5.2007 pidettyyn Stadian työryhmän palaveriin mennessä oli käyttäjäkyselyn vastaukset analysoitu, testisisältöjä ideoitu ja palvelun tekniseksi alustaksi valittu sisällönhallintajärjestelmä Drupal. Kyselyn keskeiseksi anniksi osoittautui se, että useat vastaajat toivoivat jonkinlaista verkkopalvelua työyhteisön viestinnän tehostamiseen, joten rakenteilla olevalle palvelulle oli todellinen tarve. Lisäksi kyselystä saatiin sisällöllisiä ideoita ja yleistä työhyvinvointiin liittyvää palautetta. Kohderyhmän osalta kysely osoitti sen, että internetin käyttö oli vastaajien keskuudessa varsin aktiivista, mutta sosiaalisen median palvelut eivät olleet entuudestaan tuttuja.

Ideoituja testisisältöjä ei enää ehditty kevään työn puitteissa toteuttaa. Toteutukset olisi pitänyt suunnitella pidemmälle, olisi pitänyt järjestää kuvaukset ja vielä editoida syntynyt aineisto, mutta tähän ei enää riittänyt aikaa. Sen sijaan testaukseen soveltuvaa videomateriaalia saatiin, kun kaksi opiskelijaa jalkautui erään varhaisjakajan jakokierrokselle haastattelemaan ja dokumentoimaan eri työvaiheita.

Kesäkuun alussa pidetyssä ohjausryhmän kokouksessa esiteltiin Alissan ensimmäinen versio. Sisällönhallintajärjestelmä Drupal oli asennettu Stadian testiympäristöön, sen toiminnallisuuksia ja ulkoasua oli muokattu ja palveluun oli tuotettu jonkin verran testisisältöjä. Toiminnallisuuksiltaan Alissa täytti konseptitasolla määritellyt tavoitteet: se mahdollisti materiaalin jakamisen ja käyttäjien vuorovaikutuksen mutta kaipasi myös runsaasti jatkokehitystä. Leimallinen piirre palvelussa oli sisällönhallintajärjestelmän valmiiden ominaisuuksien kokeileva ja runsas käyttö, eli käytettävän tekniikan korostuminen varsinaiseen käyttötarkoitukseen keskittymisen kustannuksella.

KUVA 7. Alissan etusivu opinnäytetyön valmistumishetkellä marraskuussa 2007. Tapahtuneesta jatkokehityksestä huolimatta sisällönhallintajärjestelmä Drupalin perusominaisuudet ovat yhä voimakkaasti esillä.

6.3 Lisähuomioita projektin etenemisestä

Gettin Realin näkökulmasta on mielenkiintoista huomata, että alustan valinnasta kesti lopulta noin kolme viikkoa palvelun ensimmäisen esiteltävän version valmistumiseen. Vähäiseksi jääneen käsikirjoitustyön takia voisi jopa ajatella, että Getting Realin nopea kehitysihanne toteutui projektin loppuvaiheessa määräajan pakottamana. Ketterästä kehityksestä ei tässä yhteydessä voida kuitenkaan vielä puhua, koska kehitysjaksoa ei suunniteltu erikseen eikä se johtanut suunnitelmallisiin jatko-iteraatioihin. Jos palvelun kehitys kuitenkin olisi aloitettu aiemmin keväällä suunnitelmallisesti iteraatioihin perustuen, olisi tässä vaiheessa voitu jo tutustua pidemmälle kehitettyyn, useita kehityssyklejä läpikäyneeseen toteutukseen.

Omasta näkökulmastani kevään työskentelyä varjosti tietty epävarmuus siitä, kuinka palvelun suunnittelua olisi pitänyt lähestyä. Käsikirjoituslähtöinen suunnittelutapa oli toisaalta perusteltu projektityössä harjaantumisen kannalta, mutta se ei selvästikään toiminut parhaalla mahdollisella tavalla. Oma kokemattomuuteni projektin vetäjänä aiheutti sen, että minulla ei ollut kykyä ajoissa tunnistaa tiettyjen toimintatapojen toimimattomuutta eikä toisaalta myöskään välineitä vaihtoehtoisten työtapojen kokeilemiseen.

7 SOPEUTUVA SUUNNITTELU

Esitän seuraavaksi Alissa-projektin kokemusten ja Getting Realista saamieni ajatusten pohjalta suunnittelumallin, jonka tarkoituksena on yhdistää hallittu, tarvelähtöinen kokonaissuunnittelu ja toistuviin kehitysjaksoihin perustuva joustava kehitys. Olen antanut mallille nimen Sopeutuva suunnittelu, koska mielestäni se kuvaa tavoitteena olevaa, toimintaympäristön tarpeisiin reagoivaa toimintatapaa.

7.1 Työryhmä

Sopiva työryhmä ja sille soveltuvan työtavan löytäminen on ensiarvoisen tärkeää. Pieni, yhtenäinen ja kommunikoiva ryhmä toimii tehokkaasti ja kykenee ratkaisemaan eteen tulevia ongelmia itsenäisesti. Viiden hengen työryhmällä on mielestäni mahdollista saavuttaa riittävän laaja osaamispohja siten, että ryhmä pysyy vielä hyvin hallittavana. Jäsenille määritellään päävastuualueet erityisosaamisen mukaan, mutta on tärkeää, että työtehtäviä ei rajata pelkästään näiden vastuualueiden mukaan. Alusta alkaen on oltava selvää, että kaikkien ryhmäläisten työpanosta tarvitaan työn edetessä kaikissa eteen tulevissa tehtävissä.

Ryhmän päävastuualueet jakautuvat varsinaisen palvelun toteuttamisen ja yleisen tason suunnittelun mukaan. Toteuttamista varten tarvittavat päävastuut ovat graafinen suunnittelija, tekninen kehittäjä ja yleisosaaja, joka voi osallistua sekä graafiseen suunnitteluun että tekniseen kehitykseen. Yleisen tason suunnittelua varten tarvitaan konseptisuunnittelija, jolla on erityistä asiantuntemusta sosiaalisesta mediasta, ja joka keskittyy erityisesti tarkoitukseen sopivien sosiaalisten työkalujen ja menetelmien löytämiseen sekä tuottaja, joka toimii ryhmän vetäjänä ja pääyhteyshenkilönä. Koko työryhmä toimii yhteistyössä toimeksiantajan kanssa, jonka tarpeisiin palvelua kehitetään.

Jotta työryhmän pienen koon edut saadaan hyödynnettyä, pitää ryhmän jäsenille järjestää yhteistä työaikaa. Tavoitteena on välttää sellaista toimintatapaa, jossa jokaiselle työntekijälle määritellään omat työtehtävät, jotka tämä toteuttaa itsenäisesti johonkin määräaikaan mennessä. Tällainen malli johtaa hierarkkiseen toimintamalliin, jossa projektin johto jakaa tehtävät ja valvoo niiden suorittamista. Yhdessä työskentely sen sijaan mahdollistaa suoran kommunikoinnin ja osallistumisen laajemmin projektin eri tehtäviin. Jos työryhmän jäsen esimerkiksi kohtaa työssään jonkin esteen, hän voi heti pyytää muilta ryhmän jäseniltä neuvoa. Myös muiden mielipiteiden kysyminen ja päätösten tekeminen helpottuu, kun kaikki ryhmän jäsenet työskentelevät samassa tilassa. Näin ryhmän jäsenet ovat tietoisia toistensa tilanteesta, palaverien tarve vähenee ja spontaani ideoiden jakaminen ja yhteistyö lisääntyy.

Opiskelijatyössä on tavoiteltava vähintään viikoittaista usean tunnin mittaista yhteistä työrupeamaa, jonka aikana ilmenneiden seikkojen perusteella on mahdollista suunnitella muuna aikana itsenäisesti toteutettavia tehtäviä. Jos tämä työtapa aloitetaan mahdollisimman aikaisessa vaiheessa, uskon sen vahvistavan projektiin sitoutumista ja ryhmähenkeä.

Tiivis yhteistyö vähentää myös tiedottavien dokumenttien tarvetta. Tiedottamista ja projektin edistymisen seurantaa varten kannatta käyttää jotain verkossa toimivaa projektinhallintatyökalua, joka mahdollistaa kaikkien projektin osapuolten pääsyn projektiin liittyvään dokumentaatioon. Esimerkiksi Stadian VIDEOS-hankkeen työryhmän käyttämä yksinkertainen Wiki-alusta ja päivätason edistymisen seuranta antavat kaikille hankkeen osapuolille hyvän kuvan siitä, miten kehitystyö etenee (Fooga kehitys-wiki 2007).

7.2 Alkusuunnittelu

Palvelun rakentaminen aloitetaan huolellisella alkusuunnittelulla. Toimeksiantajan kanssa määritellään palvelun lähtökohdat, idea, kohderyhmä ja yleiset tavoitteet sekä projektin aikataulu. Näiden pohjalta mietitään edelleen, millaisia sisältöjä palvelulla tavoitellaan, miten palvelu istutetaan nykyiseen toimintaympäristöön ja miten sosiaaliset toiminnallisuudet rajataan. Koska yritysympäristössä palvelun tuleva käyttäjäkunta on tiedossa, kannattaa myös kohderyhmän edustajia ottaa mukaan suunnitteluun mahdollisimman varhaisessa vaiheessa. Esimerkiksi kaksi loppukäyttäjää voisi olla mukana toimeksiantajan työryhmässä ja osallistua aktiivisesti suunnitteluun.

Alkumäärityksiä tehtäessä suunnittelutyöryhmän sosiaalisen median asiantuntijuus korostuu. Ryhmä konsultoi tilaajaa erilaisista sosiaalisen median toimintamalleista ja erilaisten valintojen mahdollisista seurauksista ja antaa näkökulmia erilaisten ratkaisujen toteuttamiseen ja aikatauluihin liittyen. Eri osapuolten lähtökohtien pohjalta muodostuvat yhteiset alkumääritykset, joiden perusteella työryhmä aloittaa tarkemman jatkosuunnittelun.

Rajaavien alkumääritysten jälkeen työryhmä laatii palvelun toteuttamiseksi yleisen tason suunnitelman, jossa kiteytyy palvelun visio, käytettävät sosiaaliset objektit ja palvelun tärkeimmät toiminnallisuudet. Suunnitelma tiivistää toimeksiantajan kanssa rajatut lähtökohdat ja tavoitteet ja tarjottavat ratkaisut perusteluineen. Tämän suunnitelman pohjalta työryhmä toteuttaa palvelun ensimmäisen version.

7.3 Iteraatioihin perustuva työtapa

Työryhmä suunnittelee ensimmäisen iteraation sisällön laatimansa yleisen suunnitelman pohjalta. Tehtyjen määritysten pohjalta valitaan käytettävä alusta, suunnitellaan toteutettavat toiminnallisuudet ja alustava ulkoasu. Tavoitteena on yksinkertainen versio lopullisesta palvelusta, jota voidaan esitellä asiakkaalle ratkaisuehdotuksena perinteisen konseptisuunnitelman sijaan. Toteutettavat tehtävät jaetaan pieniksi osakokonaisuuksiksi, joista muodostettavan tehtävälistan perusteella voidaan arvioida tarvittavan työn määrä. Arvioidun työmäärän perusteella sovitaan määräaika, jolloin työn tulokset tarkistetaan tilaajan kanssa.

Iteraation loppuvaiheessa tilaaja saa tutustua palveluun ja kirjata ylös huomioita ja kehitysehdotuksia. Myös toteuttava työryhmä tekee oman esityksensä jatkokehityksestä. Yhteisessä kokouksessa näistä ideoista laaditaan uusi suunnitelma, jonka perusteella edetään toiseen iteraatioon.

Kun kehitystyö on käynyt läpi kaksi iteraatiota, ja projektin osapuolten mielestä työ etenee oikeaan suuntaan, kutsutaan palveluun pieni loppukäyttäjistä koottava testikäyttäjäryhmä. Testikäyttäjiltä kerätty palaute otetaan mukaan seuraavan iteraation suunnittelukokoukseen, jolloin saadaan tuntuma siitä, kuinka toteutunut työ palvelee loppukäyttäjiä. Seuraavassa iteraatiossa keskitytään käyttäjäpalautteen herättämiin kehityskohteisiin.

7.4 Julkaisu ja korjaukset

Alissaan verrattavissa oleva palvelu voidaan mielestäni julkaista neljän iteraation jälkeen. Tässä vaiheessa tärkeimpien toiminnallisuuksien pitäisi jo toimia niin hyvin, että palvelun hiominen ilman loppukäyttäjien palautetta ei ratkaisevasti edistä kehitystyötä. Julkistamista varten kannattaa järjestää jokin näkyvä kampanja, joka houkuttelee palveluun paljon koekäyttäjiä. Käyttäjille tarjotaan mahdollisuus palautteen antamiseen, ja sopivan testijakson jälkeen arvioidaan jälleen yhteisesti kehitystarpeet. Tarvittavat korjaukset toteutetaan vielä yhden iteraation aikana.

Palvelun lanseeraus on kriittinen vaihe tavoiteltavan aktiivisuuden ja vuorovaikutuksen kannalta. Pelkkä kävijöiden lukumäärä ei ole ratkaisevaa, vaan osallistumiskynnys pitää saada riittävän matalaksi. Suunnittelussa olisikin hyvä määritellä julkaisuvaiheeseen sopivia aktivoimiskeinoja. Palveluun kannattaa ainakin luoda valmista materiaalia, johon tutustumalla uusi käyttäjä saa kuvan palvelun ideasta. Lisäksi tarjolla voisi olla jokin pienimuotoisen osallistumisen mahdollistava ominaisuus, esimerkiksi äänestys tai mielipidekysely. Mielestäni palvelulle kannattaa määritellä myös aktivoimiseen tähtäävä toimituksellinen linja. Esimerkiksi loppukäyttäjistä koostuva aktiivinen ryhmä voisi tuottaa säännöllisesti mielenkiintoista sisältöä ja pyrkiä houkuttelemaan muita käyttäjiä mukaan toimintaan.

Seuraavassa kaavakuvassa tiivistän Sopeutuvan suunnittelun toistuviin kehitysjaksoihin perustuvan prosessimallin:

KUVA 8. Sopeutuvan suunnittelun prosessikuvaus.

Tarkennan työryhmän toimintaa ohjaavia suunnitelmia opinnäytetyön liitteessä 1. Liitteessä on yleisen tason suunnitelma, joka määrittelee palvelun tarkoitusta ja toimintaa, sekä seuraavaksi toteutettavan, jatkokehitykseen tähtäävän iteraation suunnitelma.

8 LOPUKSI

Verkkopalvelujen suunnittelu on vaihtelevaa työtä. Toteutettavan palvelun tarkoituksesta ja laajuudesta riippuen tarvitaan erilaisia työskentelymalleja, jotta tavoiteltu lopputulos voidaan saavuttaa suunnittelutilanteeseen parhaiten soveltuvilla menetelmillä. Perinteinen multimediatuotannon suunnitteluprosessi toimii perusmallina, joka on sovellettavissa monenlaisten tuotantojen tarpeisiin. On kuitenkin tilanteita, joissa toisenlaiset lähestymistavat ovat perusteltuja.

Opinnäytetyöni lähti tarpeesta ymmärtää suunnittelutyön kokonaisprosessin vaatimuksia yksittäisen projektin näkökulmasta. Mielestäni onnistuin kartoittamaan niitä ominaisuuksia, jotka tekevät sosiaalisen median palvelun suunnittelusta erilaista perinteisen verkkopalvelun suunnitteluun verrattuna. Uskon myös, että esittämäni yritysympäristössä toimimiseen liittyvät huomiot ovat perusteltuja, vaikkakin ne ovat vasta pintaraapaisu siitä, kuinka avoimuuteen ja osallistumiseen perustuvia toimintamalleja voitaisiin ottaa käyttöön olemassa olevissa organisaatioissa. Tulenkin varmasti jatkossa kiinnittämään aiempaa enemmän huomiota siihen, miten toimintaympäristö ja suunniteltavan palvelu vaikuttavat toisiinsa suunnitteluprosessin aikana.

Toteutuneen Alissa-projektin osalta huomioni ovat hyvin subjektiivisia. En voi väittää, etteikö projektia olisi voitu toteuttaa toimivammin myös perinteisen tuotantoprosessin työtavoilla. Omat keinoni eivät kuitenkaan riittäneet ohjaamaan projektia niin, että olisin kokenut työskentelyn hallituksi ja suunnitelmalliseksi, ja siksi halusin tutustua täysin erilaisiin työtapoihin. Getting Real tarjosi mielestäni hyvän vertailukohdan perinteisille menetelmille.

Olen sitä mieltä, että esittämäni suunnittelumalli vastaa sosiaalisen median avoimuutta ja osallistumista korostavaan luonteeseen paremmin kuin perinteinen malli. Mikromod-hankkeen jatkotyöskentely ja muut tulevaisuuden projektit osoittavat, missä määrin esittämäni toimintatavat palvelevat käytännön työtä. Olen kuitenkin varma siitä, että ne antavat kokeilemisen arvoisia ratkaisuja suunnittelutyön haasteisiin.

LÄHTEET

37Signals 2006 Getting Real: The smarter, faster, easier way to build a successful web application.

Alamäki, Ari & Luukkonen Jussi 2002. eLearning - Osaamisen kehittämisen digitaaliset keinot: strategia, sisällöntuotanto, teknologia ja käyttöönotto. Helsinki: Edita Prima Oy.

del.icio.us 2007. [WWW-dokumentti]
http://del.icio.us/ (Luettu 16.11.2007).

Engeström, Jyri 2006. Presentaatio MSN Innovate -tapahtumassa. [WWW-dokumentti]
http://www.campaignhost.se/msn/innovate/061207/download.html (Katsottu 15.10.2007).

Fooga kehitys-wiki 2007. [WWW-dokumentti]
http://www.wikistudies.org/fooga/ (Luettu 19.11.2007).

Google 2007. [WWW-dokumentti]
http://www.google.com (Luettu 18.11.2007)

Google-dokumentit 2007. [WWW-dokumentti]
http://www.docs.google.com (Luettu 18.11.2007)

Graham, Paul 2005. Web 2.0. [WWW-dokumentti]
http://www.paulgraham.com/web20.html (Luettu 9.10.2007).

Jussila, Markku & Leino, Antti 2001. Verkkoviestinnän käsikirja. Hämeenlinna: Karisto Oy.

Kangas, Petteri & Toivonen, Santtu & Bäck, Asta (toim.) 2007. Googlen mainokset ja muita sosiaalisen median liiketoimintamalleja. Helsinki: Edita Prima Oy.

Keränen, Vesa & Lamberg, Niko & Penttinen Jukka 2005. Digitaalinen media. Porvoo: WS Bookwell.

Kokkonen, Juhana 2007. Yhteistyö avoimessa organisaatiossa. Teoksessa Yritys 2.0. [WWW-dokumentti]
http://yritys20.com/kirjan-sisalto/luku-4-yhteistyo-avoimessa-organisaatiossa/ (Luettu 21.10.2007).

Majava, Jere 2006. Kohti sosiaalista verkkoa. Teoksessa Verkkoviestintäkirja. Aula, Pekka & Matikainen, Janne & Villi, Mikko (toim.) 2006. Helsinki: Yliopistopaino. 87.97.

Mikromod hankesuunnitelma 2006. Mikromod - Mikromoduulien tehokas tuotanto ja monikanavakäyttö henkilöstön osaamisen kehittämisessä. [Dokumentti opinnäytetyön tekijän hallussa].

Mutanen, Marjut 2007. Facebookista kuus. [WWW-dokumentti]
http://www.matkalla.org/blog/archives/2007/09/facebookista_kuus.html (Luettu 20.10.2007).

Mäntylä, Juha-Matti (toim.) 2007. Facebook tuplasi kahdessa viikossa. Tietoviikko 21.9.2007. [WWW-dokumentti]
http://www.marmai.fi/doc.te?f_id=1230157 (Luettu 15.10.2007).

O'Reilly, Tim 2006. Web 2.0 Compact Definition: Trying Again. [WWW-dokumentti]
http://radar.oreilly.com/archives/2006/12/web_20_compact.html (Luettu 20.10.2007).

Preece, Jenny 2000. Online Communities - Designing Usability, Supporting Sociability. Chichester: John Wiley & Sons, Ltd.

Tapscott, Don & Williams, Anthony D. 2006. Wikinomics - How Mass Collaboration Changes Everything. United States of America: Portfolio.

Wikipedia 2007a. Social media. [WWW-dokumentti]
http://en.wikipedia.org/wiki/Social_media (Luettu 20.10.2007).

Wikipedia 2007b. [WWW-dokumentti]
http://www.wikipedia.org/ (Luettu 18.11.2007).

Wikipedia 2007c. Avoin lähdekoodi. [WWW-dokumentti]
http://fi.wikipedia.org/wiki/Avoin_l%C3%A4hdekoodi (Luettu 25.10.2007).

Wikipedia 2007d. Ohjelmistokehitys. [WWW-dokumentti]
http://fi.wikipedia.org/wiki/Ohjelmistotuotanto (Luettu 27.10.2007).

YLE uutiset 2007. Verkostosivujen lyhyt historia. [WWW-dokumentti]
http://www.yle.fi/uutiset/kotimaa/taustat/id66470.html (Luettu 14.10.2007).

YouTube - Broadcast Yourself 2007. [WWW-dokumentti]
http://www.youtube.com/ (Luettu 18.11.2007).

blog comments powered by Disqus