IT-innovaatiopalvelun prosessi versio 2

Workshop Reaktorin kanssa

Pidimme Reaktorin kanssa iltapäivän mittaisen workshopin jonka tavoitteena oli kirkastaa meidän näkemystämme siitä miten tämä IT-innovaatiopalvelumalli toimii ja mitä parannuksia vielä tarvitsemme ennen toiminnan käynnistämistä. Reaktorin puolelta wokshoppiin osallistui Joonas Makkonen ja Sami Honkonen.

Workshop oli erittäin hyvin järjestetty ja iltapäivän kohokohtia olivat:

  • Keskustelun kohdentaminen oikealle tasolle “choose your focus” menetelmällä
  • Prosessin uudelleen suunnittelu kahdessa eri ryhmässä postilappujen avulla ja näiden ryhmätöiden synkronointi
  • Henkilökohtaisten tavoitteiden ja sidosryhmien tavoitteiden ymmärtäminen

Saimme myös kannustavaa palautetta toimintamallin tarpeellisuudesta ja hyödyistä. Ville kirjoittaa tarkemman blogi-postauksen workshopista, mutta tähän postaukseen hahmottelen tämän hetken ajatuksemme IT-innovaatiopalvelumallin prosessista.

IT-innovaatiopalvelumallin prosessi

Markkinointi

Haluamme markkinoiden palvelua kahdelle yhtä tärkeälle ryhmälle:

  • Ideoiden keksijöille jotka haluaisivat toteuttaa ajatuksensa
  • Rohkeille ja vaikutusmahdollisuuksia kaipaaville “early adopter” käyttäjille

Ideoita olemme jo saaneetkin kiitettävästä, mutta haluamme varmistaa että tuomme tämän mahdollisuuden lähteä toteuttamaan uusia kekseliäitä palveluita kaikkien Aaltolaisten tietoisuuteen.

Vähintäänkin yhtä tärkeää on, että saamme näille innovatiivisille uusille palveluille käyttäjiä heti niiden julkaisun jälkeen joilta saadaan palautetta ja ohjausta siihen mihin suuntaan palvelua kannattaa kehittää. Tomi on lupautunut kirjoittamaan tästä oman blogi-postauksen.

Visio

Potenttiaalinen “product owner” voi esittää omaan ideaansa IT-innovaatiopalvelumalliin tekemällä siitä maksimisaan yhden A4:n kokoisen ehdotuksen jossa hän vastaa kolmeen kysymykseen:

  1. Mikä idea on?
  2. Miten se hyödyttää Aalto-yliopistoa ja/tai siihen liittyvää yhteisöä?
  3. Miten palvelun onnistumista voidaan arvioda?

Visiot voi lähettää osoitteeseen Teemu.Toivonen@aalto.fi

Vision jalostaminen

Seuraavaksi visiota pyritään jalostamaan muotoon jossa ideaan on pohdittu hieman eri näkökulmasta. Tässä vaiheessa pyritään tekemään myös joku hyvin kevyt koe jolla validoidaan ideaa. Tämä voi olla esimerkiksi muutaman käyttäjän haastattelu. IT järjestää idean keksijälle lyhyen koulutuksen siitä miten visiota kannattaa jalostaa ja järjestää hänelle esimerkiksi kerran viikossa valmennussession missä käydään läpi vision jalostamisen etenemistä. Jalostamistyön tekee pääosin kuitenkin idean keksijän.

Lopputulosena tästä syntyy “Lean Canvas” dokumentti.

Visioiden priorisointi

Jalostettujen visio dokumenttien jälkeen seuraava vaihe on konseptin suunnittelu vision ympärille. Tämä vaihe on kuitenkin jo kohtuullisen työläs joten jos ideoita on paljon niin sitä ei välttämättä voida tehdä kaikille visioille. Tämän vuoksi tarvitaan selkeät kriteerit joiden avulla valitaan konseptointivaiheeseen pääsevät ideat. Priorisointiin haluttaisiin myös jollain tavalla Aalto-yhteisön panos, mutta emme ole vielä keksineet hyvää mekanismia tähän. Onko teillä hyviä ehdotuksia?

Konseptointi

Konseptointi vaiheessa visiosta valmistellaan konsepti jonka perusteella voidaan tehdä päätös rahoituksesta ja aloittaa palvelun kehittäminen. Tyypillisiä työvaiheita ja tuotoksia tässä vaiheessa ovat:

  • Teemojen ja epicien kuvaukset
  • Käyttäjäpersoonat
  • Paperiprototyypit
  • MMF:n eli pienimmän mahdollisen julkaisukelpoisen version kuvaaminen
  • Karkea arvio MMF:n tuottamisen vaatimasta työstä
  • Ensimmäiset käyttäjätarinat

Lisäksi tässä vaiheessa pyritään tekemään yksi tai muutama yksinkertainen koe palautteen saamiseksi. Tälläinen koe voisi olla esimerkiksi paperiprotyypin avulla tapahtuva simuloitu käyttö muutamalla käyttäjällä.

Idean keksijä on vahvasti mukana myös tässä työvaiheessa mutta saa käytännön tekemiseen halutessaan paljon apua IT:ltä.

Rahoituspäätös

Rahoituspäätös tehdään vision ja konseptin perusteella. Rahoituspäätösmallista tehdään mahdollisimman läpinäkyvä ja kriteerit tehdään julkisiksi. Yksityiskohdat tästä ovat kuitenkin vielä kovasit pohtimisen alla ja palauteesta ja ideoista olisi paljon apua.

Ensimmäisen julkaisun tuottaminen

Ensimmäinen julkaisu tuotetaan Scrum-mallin mukaisesti käyttäen mahdollisimman lyhyitä sprinttejä. Idean keksijä toimii “product owner” – roolissa.

Saimme workshopissa mielenkiintoisen idean miten laatua voisi ajatella tässä yhteydessä. Reaktor (joka on normaalisti erittäin laatuorientoitunut yritys) ehdotti emme tekisi esimerkiksi automaattitestausta ennen ensimmäistä julkaisua koska tässä vaiheessa palveluun liittyy vielä suuri riski. Tarkoituksena olisi siis päästä kokeilemaan ideaan mahdollisimman nopeasti käytännössä ja jos se osoittautuu hyväksi niin tehdä tekniseen laatuun tarvittavat investoinnit vasta sen jälkeen (automaattitestaus ja refactorointi). Eli ensimmäinen julkaisu niin sanotusti “koodataan kekkosena”.

Tässä vaiheessa huokutellaan myös aktiivisesti käyttäjiä uudelle palvelulle.

Palautteen kerääminen

Ensimmäisen julkaisun jälkeen kerätään mahdollisimman paljon palautetta siitä. Palautetta kerätään usealla eri tavalla:

  • Palvelun käytön tilastoinnin avulla (kuinka paljon käyttäjiä ja mitä osia palvelusta käytetään aktiivisesti)
  • Antamalla käyttäjille helppopalaute kanava palvelun yhteydessä
  • Avaamalla backlogi ehdotuksella ja sallimalla äänestys niistä
  • Käyttäjähaastatteluilla
  • Chat, irc, keskustelupalstat

Päätös jatkorahoituksesta

Idean keksijä voi hakea jatkokehitysrahoitusta palvelun kehittämiselle. Jatkorahoituspäätös perustuu:

  • Kehitettyyn palveluun
  • Palvelun menestymiseen alkuperäisten mittareiden perusteella
  • Käyttäjäpalautteeseen
  • Jatkokehityksen “business case”:lle

Palvelun siirto normaaliksi tuotantopalveluksi tai lopettaminen

Viimeistään 12 kuukautta ensimmäisen rahoituspäätöksen jälkeen tehdään päätös siitä, että palvelu lopetetaan tai sille myönnetään rahoitus jonka avulla siitä tehdään normaalituotantopalvelu. Tässä yhteydessä palvelulle etsitään myös omistaja Aallon organisaatiosta ja sovitaan missä roolissa alkuperäinen ideoija haluaa jatkaa palvelun kehittämisessä vai haluaako hän siirtää kehitysvastuun kokonaan eteenpäin.

Teemu Toivonen