IT-innovaatiopalvelun vision jalostaminen – osa II

Ulos kammioista!

Aikaisemmassa blogikirjoituksessa kerroimme, että käytämme IT-innovaatiopalvelussa vision jalostamiseen Steve Blankin kehittämän nelivaiheisen asiakaskehitysprosessin (Customer Developement, Kuva 1) ensimmäistä vaihetta. Lyhyesti kuvattuna Blankin koko asiakaskehitysprosessi menee siten, että ensimmäisessä vaiheessa (Customer Discovery) tarkoituksena on selvittää ketkä ovat potentiaalisia asiakkaita kehitettävälle tuotteelle ja onko ongelma, jota yritetään ratkaista, asiakkaiden mielestä ratkaisemisen arvoinen. Toisessa vaiheessa (Customer Validation) tarkoituksena rakentaa toistettava myynnin tiekartta (road map) myynti- ja markkinointitiimeille, jota he seuraavat myöhemmin. Myynnin tiekartta on toimiva ja monistettava myyntiprosessi, jonka toimivuus on todistettu myymällä tuotetta varhaisille omaksujille (early adopters). Kolmannessa vaiheessa (Customer Creation) tavoitteena on luoda tuotteelle kysyntää käyttäjien keskuudessa erilaisten markkinointimekanismien avulla ja ohjata kysyntä myyntikanaviin. Neljännessä vaiheessa (Company Building) yritys siirtyy epämuodollisesta ja kokeilevasta toimintamallistaan kohti järjestäytyneempää rakennetta, jossa toiminnot on hajautettu omiin myynti-, markkinointi ja kehitysyksiköihin. Yrityksen edelleen kypsyessä toimina usein  alkaa järjestäytyä eri prosessien ympärille, jolloin yritys muuntuu prosessiorganisaatioksi.

Kuva 1: Blankin Customer Developement -malli. (http://pathfindersoftware.com/2011/01/exploring-customer-validation/)

IT-innovaatiopalvelumallissa vision jalostamien tapahtuu siis Customer Discovery -vaiheen periaatteita mukaillen. Lähtökohtana on, että idean keksijä tai keksijät tekevät itse jalostustyön ja IT tarjoaa tukea tarpeen mukaan, jolloin idean keksijä pystyy syventämään käsitystään ja oppimaan lisää ideastaan. Jalostusvaihe pitää sisällään  ideaan liittyvien alkuolettamusten määrittelemisen ja vähintään kaksi haastattelukierrosta, joiden avulla pyritään oppimaan pitivätkö olettamukset paikkansa.  Jalostusprosessi koostuu viidestä eri vaiheesta:

  1. Vision jalostusvaiheen esittely. IT-innovaatiopalveluun A4-muodossa saapuneiden ideoiden pohjalta otamme yhteyttä ideoiden esittäjiin ja esittelemme heille kuinka idean jalostamisprosessi etenee tästä eteenpäin.
  2. Määritellään arvolupaus ja olettamukset. Seuraavaksi kirjoitetaan ylös A4-visodokumentin pohjalta myöhemmin tässä kirjoituksessa esitettävälle Lean Canvas -pohjalle (Kuva 2) joukko olettamuksia, jotka linkittyvät idean arvolupaukseen (visioon). Olettamuksia tehdään asiakkaista, ongelmasta jota yritetään ratkaista, tuotteen tai palvelun ominaisuuksista, hyödyistä, kustannuksista ja markkinoista. Muissa vaiheissa testataan näiden olettamusten oikeellisuutta.
  3. Testataan asiakas- ja ongelmahypoteesi. Tässä vaiheessa Lean Canvakasella olevat asiat ovat vain joukko olettamuksia, ja faktat osaavat kertoa vain palvelun tai tuotteen oikeat käyttäjät. Se että vastaako mielikuvitus todellisuutta, selviää vain lähtemällä työhuoneesta päätteen äärestä ulos oikeaan oikeiden ihmisten pariin. Tässä vaiheessa halutaan puhua vähän, mutta kuunnella sitäkin enemmän. Tavoitteena on haastattelujen avulla ymmärtää asiakasta ja heidän ongelmiaan ja samalla saada syvällinen käsitys heidän työstään, työskentelytavoistaan, organisaatiosta ja tarpeistaan. Haastattelujen jälkeen päivitetään saatu tieto Lean Canvakselle. Tarkoitus ei ole kuulla, että rakastaisivatko käyttäjät suunnitella olevaa tuotetta tai palvelua, vaan oppia ovatko olettamukset käyttäjien ongelmista oikeita. Jos ne ovat vääriä, ei ole mitään väliä miten hyvä tuote tai palvelu on, sillä kukaan ei käytä niitä.
  4. Testataan tuotekonseptia. Neljännessä vaiheessa testataan suunniteltua ja Lean Canvaksessa kuvailtua tuote- tai palvelukonseptin ominaisuuksia asiakkailla samalla tavalla haastattelujen avulla kuin edellisessäkin vaiheessa. Tavoitteena ei ole myydä tuotetta tai palvelua, vaan arvioida  olettamuksia ja toivoa, että asiakas sanoo: “Kyllä, nuo ovat niitä ominaisuuksia, jotka ratkaisevat ongelmamme!” Sammalla kun testataan tuotteen tai palvelun ominaisuuksia, testaan myös suurempaa ideaa: koko idean järkevyyttä. Järkevä idea pitää sisällään asiakkaan, joka arvostaa idean ratkaisun korkealle, ja että ratkaisu jota tarjotaan, on heidän toiminnan kannalta kriittinen. Haastattelujen jälkeen päivitetään jälleen Lean Canvas -pohjaa.
  5. Varmennetaan olettamukset ja tehdään jatkopäätös. Viimeisessä vaiheessa pysähdytään arvioimaan, että ymmärretäänkö mikä asiakkaan ongelma on, ratkaiseeko tuote tai palvelu ne ongelmat, ja onko idean toteuttaminen ylipäätään järkevää.  Tässä vaiheessa päätetään ollaanko opittu tarpeeksi, jotta voidaan jatkaa seuraavaan vaiheeseen, joka on idean konseptointi, vai pitääkö palata takaisin asiakkaiden luokse oppimaan lisää. Kolmas vaihtoehto on, että idean toteuttamien ei olekaan järkevää, ja päätetään prosessi siihen.

IT-innovaatiopalvelun Lean Canvas

Lean Canvasta (Kuva 2) päivitetään siis jatkuvasti prosessin edetessä. Aluksi siihen kirjataan visiodokumentin pohjalta olettamuksia ideaan liittyvistä eri asioita. Näitä olettamuksia testataan aiemmin kuvatun prosessin mukaisesti ja samalla päivitetään tai täydennetään Lean Canvsta haastatteluista saatujen havaintojen pohjalta. Ei siis haittaa, vaikka heti aluksi kaikkiin kysymyksiin ei olisikaan selkeää näkemystä, sillä näkemyksiä on tarkoitus selventää matkan varrella.

Idean jalostusprosessissa käytettävä Lean Canvas

Kuva 2: IT-Innovaationpalvelun Lean Canvas

Lean Canvas koostuu seuraavista kentistä:

  • Arvolupaus kertoo lyhyesti ja ytimekkäästi miksi suunniteltava tuote tai palvelu on erilainen ja kannattaa toteuttaa. Arvolupaus on maali tai tavoite, johon tähdätään. Arvolupausta voisi myös kuvata majakaksi, joka auttaa pitämään laivan oikeassa kurssissa, kun joudutaan väistelemään matkan aikana eteen tulevia karikoita, jotka saattavat ohjata laivaa väärälle kurssille.
  • Asiakassegmentit pitää sisällään ne käyttäjät tai käyttäjäryhmät, joiden kuvitellaan olevan palvelun tai tuotteen kohderyhmää. Aluksi on siis vain olettamus, että keitä he voisivat olla. Heistä myös aloitetaan ensimmäiset haastattelut, joiden myötä sitten selviää, että ovatko olettamukset asiakassegmenteistä pitäneet paikkaansa.
  • Ongelman kuvaus kuvaa mikä tai mitkä ongelmat idean avulla halutaan ratkaista. Kuten asiakaskunnankin tapauksessa, tämä on aluksi vain olettamus, joka sitten täsmentyy ensimmäisen haastattelukierroksen aikana.
  • Nykyinen ratkaisu kertoo miten ongelma ollaan yritetty tällä hetkellä ratkaista. Se siis kuvaa nykytilaa. Nykytilanne voi olla se, että ongelmaa ei ole edes tunnistettu, tai se voi olla tunnistettu, mutta sitä ei ole koettu niin kriittiseksi, että sen eteen olisi yritetty tehdä jotain. Voi myös olla, että ongelma on koettu niin haittaavaksi, että siihen ollaan mietitty joitain ratkaisuja, mutta niitä ei ole syystä tai toisesta pystytty toteuttamaan. On myös mahdollista, että ongelma on ratkaistu jollain kiertotiellä, joka ei kuitenkaan ole ehkä optimaalisin tapa ratkaista ongelma. Nämä kaksi jälkimmäisintä skenaariota ovat kaikista otollisinta maaperää omaa ratkaisuehdotusta ajatellen.
  • Ratkaisuehdotussa esitellään lyhyesti miten ongelma kannattaisi idean esittäjän mielestä ratkaista. Se on siis jokin parempi tai uusi toteutustapa verrattuna nykytilanteeseen. Tässä vaiheessa ratkaisuehdotus on vain hyvin yleisellä tasolla, ja haastattelujen yhteydessä kannattaakin kysyä haastateltavien näkemyksiä ratkaisuehdotuksen toimivuudesta, eikä esittää sitä lopullisena ratkaisuna ongelmaan.

Jos haastattelujen ensimmäisen vaiheen jälkeen voidaan todeta, että olettamukset käyttäjillä olevista ongelmista olivat oikeaan osuneita ja että ehdotettu ratkaisutapa voisi olla toimiva, aloitetaan itse ratkaisuehdotuksen tarkempi testaaminen myöskin haastattelujen avulla.

  • Tärkeimmät ominaisuudet pitävät sisällään tuotteen tai palvelun ne päätoiminnallisuudet, joiden oletetaan tuottavan käyttäjille lisäarvoa. Tässä ovat vain minimaaliset päätoiminnallisuudet, jotka ovat tarpeen ensimmäisen julkaisukelpoisen tuotteen tai palvelun (MMF – Minimum Marketable Features) toteuttamiseksi. Sitä että ovatko ne oleellisia ja välttämättömiä ongelman ratkaisemiseksi, tutkitaan haastatteluiden avulla.
  • Hyödyt Aalto-yhteisölle -kohdassa listataan niitä hyötyjä mitä palvelusta tai tuotteesta syntyy Aalto-yhteisölle ja kuinka niitä voidaan mitata. Liiketoimintaympäristössä tässä kuvattaisiin miten tuote synnyttää tuottoja.
  • Sijoittuminen ympäristöön kuvaa tuotteen tai palvelun markkinatilannetta. Voi olla, että ratkaistavaan ongelmaan on jo tällä hetkellä jokin ratkaisu olemassa, mutta ehdotettu ratkaisu onkin jollain tavalla parempi: se on halvempi, nopeampi tai siinä on enemmän ominaisuuksia yms. Vaihtoehtoisesti esitetty ratkaisu voi olla täysin uusi. Täysin uuden ratkaisun tapauksessa yleensä suurin haaste on, että kuinka käyttäjät ja asiakkaat saadaan vakuuttuneiksi, että he ylipäätään tarvitsevat kyseistä tuotetta tai palvelua? Tässä yhteydessä kannattaa myös miettiä, että miltä ympäristö ja tulevaisuus oman ratkaisun ympärillä vaikuttaa, esimerkiksi näyttävätkö trendit siltä että kysytä tulee tulevaisuudessa kasvamaan, vai alkaako jokin käytettäväksi suunniteltu ratkaisu olla menneen talven lumia.
  • Kustannusten arviointi on aina hieman haastavaa, mutta niiden aiheuttajia on kuitenkin syytä miettiä. Itse palvelun toteuttamisesta syntyvät kustannukset määritellään IT-innovaatiopalvelumallin mukaisesti, mutta kustannuksia aiheutuu myös muista asioita. Tuotteen tai palvelun käyttöönotto saattaa vaatia käyttäjien kouluttamista ja ohjemateriaalin tuottamista, jonkun ehkä pitää huolehtia palveluun liittyvän tietokannan tai asiakasrekisterin ylläpitämisestä ja niin edelleen.
  • Kanavat kuvaavat kuinka tuote tai palvelu saadaan asiakkaalle asti. IT-innovaatiopalvelumallissa on määritelty tietyt alustat joiden päälle palvelut toteutetaan, mutta silti täytyy miettiä että kuinka sen käyttäjät löytävät kyseisen palvelun ja saavat tietoa sen käytöstä. Palvelulla on tuskin kovin valoisaa tulevaisuutta, jos kukaan ei tiedä sen olemassa olosta.

Saimme IT-innovaatiopalveluun jo syksyllä joitakin ideaehdotuksia. Seuraavaksi esittelemme ideoiden ehdottajille vision jalostusmalliprosessiamme ja Lean Canvas -pohjamme. Tarkoituksena on, vision jalostusprosessin idean mukaisesti, kokeilla kehittämämme mallin toimivuutta käytännössä ja sitä kautta testata ja oppia, että kuinka hyvin lähestymistapamme toimii oikeassa maailmassa. Otamme myös mielellämme vastaan uusia ideoita innovaatiopalveluun jalostettavaksi ja myös palautetta nykyiseen malliimme liittyen!

Posted by Ville

Uncategorized - 1 Comment

IT-innovaatiopalvelun vision jalostaminen – osa I

Askeleet oivallukseen

IT-innovaatiopalvelumallissa A4-muodossa toimitetun ideaehdotuksen jalostus aloitetaan vision jalostusvaiheessa. Loppusyksystä pidetyssä työpajassa Reaktorin kanssa saimme heiltä ehdotuksen, että vision jalostuksessa voisi käyttää syksyllä Aalto-yliopistossakin vierailleen start up -gurun, Steve Blankin, kehittämää Customer Developement -mallia.

Blankin mukaan yksi aloittavien yritysten suuri ongelma on, että heillä on idea tuotteesta (tai palvelusta), jota kehitetään perinteisen lineaarisen tuotekehitysmallin mukaisesti. Perinteinen tuotekehitysmalli alkaa idean konseptoinnilla, jonka jälkeen on alkaa itse tuotekehitys.  Kun tuote on saatu lähes valmiiksi, aloitetaan beta- tai alpha-testaus, joita seuraa tuotteen julkaiseminen. Saamanaikaisesti tuotekehityksen edetessä ja julkaisupäivän lähestyessä aletaan panostamaan markkinointiin ja myyntiin, jotta julkaisupäivän koittaessa kaikki olisivat halukkaita ja valmiita ostamaan uuden tuotteen itselleen.

Blankin mukaan tästä perinteisestä tuotekehitysmallista aiheutuu joitakin ongelmia. Yksi ongelma on, että idean ja kehitettävän tuotteen hyvyys perustuu usein vain kehittäjien omiin näkemyksiin, eikä heillä ole todellista varmuutta siitä, että myös mahdolliset asiakkaat olisivat samaa mieltä heidän tuotteensa hyvyydestä. Toinen ongelma on, että vaikka tuotteesta olisi saatu hyvää palautetta, niin se ei vielä takaa sitä, että tuotteesta oltaisiin valmiita maksamaan. Kolmas ongelma on, että ennen kuin aloittavalla yrityksellä on ainuttakaan maksavaa asiakasta, niin samanaikaisesti vähiä rahavaroja käytetään myynti- ja markkinointikoneiston rakentamiseen.

Edellä mainituista ongelmista seuraa usein se, että julkaisupäivän jälkeen tuotteen kysyntä ei olekaan niin suurta kuin on etukäteen laskelmoitu. Kun tuotteen kysyntä ei vastannutkaan etukäteisodotuksia, tehdään usein se virheellinen johtopäätös, että ei oltu panostettu riittävästi myyntiin ja markkinointiin. Tämän seurauksena päätetään laittaa markkinointi- ja myyntiorganisaatiot  sekä strategiat uusiksi, mutta lopputulos ei yleensä ole yhtään sen parempi.  Usein karu totuus on, että ei olla epäonnistuttu markkinoinnissa ja myynnissä, vaan kukaan ei yksinkertaisesti ole kiinnostunut tuotteesta. Tai tuote voi olla omalla tavallaan kiinnostava, mutta ei niin kiinnostava, että siitä oltaisiin valmiita maksamaan.

Blankin ehdotus ratkaisuksi on, että jo tuotekehityksen yhteydessä etsitään sopivia käyttäjiä ja markkinoita sekä yritetään myydä, ei täydellistä, mutta riittävän hyvää tuotetta ja sammalla kerätään palautetta prosessin eri tekijöistä. Hän käyttää tästä lähestymistavasta nimitystä Customer Developement, joka voitaneen suomentaa asiakaskehitykseksi, koska Blank ehdottaa malliaan vastineeksi perinteiselle tuotekehitykselle (Product Developement). Blankin asiakaskehitysmallissa ideana on siis jo heti alkuvaiheessa saada käyttäjiltä palautetta siitä, että ratkaiseeko kehitteillä oleva tuote heillä olevia ongelmia, olisivatko he valmiita käyttämään tuotetta ongelmiensa ratkaisemiseen ja ennen kaikkea, olisivatko he valmiita maksamaan tuotteesta? Prosessi ei etene lineaarisesti vaan on iteratiivinen, mikä mahdollistaa sen, että asiakkailta saadun palautteen perusteella voidaan arvioida tuotteen ominaisuuksia, hinnoittelua, käyttäjien ja markkinoiden sekä liiketoimintamallin oikeellisuutta, ja tehdä niihin muutoksia jo aikaisessa vaiheessa.

Blankin mallin tarkoituksena on ennen kaikkea oppia keitä asiakkaat ovat, mitä he oikeasti haluavat ja mistä he ovat valmiita maksamaan. Hyvin usein käy nimittäin niin, että lopulta miljoonia myyvä idea ei olekaan alkuperäinen idea A, eikä siitä jalostettu idea B, vaan niiden pohjalta keksitty idea C tai D, jotka voivat olla jotain aivan muuta kuin mitä alunperin visioitiin. Kun tuotekonsepti ja liiketoimintamalli on käytännössä testattu ja havaittu toimivaksi sekä saatu monistettavaksi, aloitetaan vasta laajemman yritystoiminnan luominen ja laajentaminen. Tästä lähestymistavasta on myös se etu, että kustannukset eivät perinteiseen tapaan painotu niin voimakkaasti prosessin alkupäähän, vaan toimintaa laajennetaan vasta todellisen kysynnän kasvaessa, ja sitä voidaan mahdollisesti rahoittaa alkuvaiheen myynnistä saatavilla tuotoilla. Usein tilanne on kuitenkin se, että edes idea D tai E ei osoittaudu kannattavaksi.  On kuitenkin edullisempaa huomata tämä jo mahdollisimman aikaisessa vaiheessa, eikä vasta sitten kun tuote on jo julkaistu markkinoilla.  Steve Blankin ideoista voi lukea lisää vaikka hänen klassikkokirjastaan “The Four Steps to the Epiphany – Successful Strategies for Products that Win” tai hänen kotisivuiltaan: http://steveblank.com/

IT-innovaatiopalvelumallin Vision jalostamisosuudessa sovellamme omin pienin muutoksin Blankin nelivaiheisen asiakaskehitysprosessin ensimmäistä vaihetta (Customer Discovery), missä tarkoituksena on testata ja arvioida, että ratkaiseeko A4-dokumentissä hahmoteltu idea ongelman, joka on oikeasti ratkaisemisen arvoinen, ja myöskin onko ideassa kaavailtu ratkaisuehdotus mahdollista tai kannattavaa toteuttaa. Asian jäsentelemiseen käytämme jo aikaisemmin esitettyä Lean Canvas -viitekehystä, jota olemme hieman muokanneet paremmin vastaamaan IT-innovaatiopalvelumallin lähestymistapaa ja Aallon tarpeita.

Posted by Ville

Uncategorized - Leave a comment

Innovaatiopalvelumallin kilpailutus julkisella puolella

IT-innovaatiopalvelun on tarkoitus olla jotain uutta ja erilaista. Tapa tehdä innovatiivisia ideoita luovasti, ketterästi, tehdä kokeiluja, toimi “high risk high gain”-periaattellaa ja reagoida nopeasti tarpeisiin. Innovaatiopalvelua kehittäessä koettiin lamppujen syttymisiä moneen kertaan. Tapa ryhtyä tekemään palveluita ja lähestyä aihetta oli jotain uutta.

Samalla myös kertauksena, ettei IT-innovaatiopalvelu sovellu kaikkiin palveluihin, vaan luovimpiin ideoihin.

Minun työkseni jäi pohtia miten tämä saadaan kilpailutuksen muotoon. Puitesopimus, jolla voidaan tilata nopeasti ketterällä ohjelmistokehityksellä tapahtuvia töitä. Puitesopimus, jossa avainasemassa on laadun tilaaminen. Ei ole takuuta, vaan tilataan mahdollisimman hyvää ja tehokasta osaamista käytettyä euroa kohti, jonka työn ohjauksesta me itse vastaamme.

Ensimmäiset ideat? Helppoa, homma on hoidettu kuukaudessa paperille!

Lokakuussa 2011 kun asiaa ryhdyttiin tutkimaan alkoi problematiikka vasta valjeta. Kerron seuraavassa omia pohdintoja, päätelmiä ja oppimista siinä kronologisessa järjestyksessä kun muistan:

  • Jos haluamme käyttää samaa tiimiä töihin, joutuu toimittaja varaamaan tämän tiimin käyttöömme koko ajaksi.
  • Haluamme kuitenkin tilata töitä lyhyellä vasteajalla, jolloin näiden kahden summa muodosti tilanteen, jossa toimittaja joutuisi pitämään yhtä tiimiä koko ajan varattuna meille. Keskustelut eri toimittajien kanssa ja asian tutkiskelu paljasti, ettei kyseessä olisi kovin halpa malli.
  • Jos käytämme osittain samaa tiimiä, jossa ydinjäsenet pysyisivät samana, jottei aina tarvitse opetella uutta mallia. Tämä voisi olla toimittajalle joustavampaa. Todellisuus osoittautui kuitenkin hieman haastavaksi, koska tässä hyvin erikokoiset firmat olivat eri lähtökohdissa, joka vaikuttaisi huomattavissa määrin hinnoitteluun.
  • Äh! Etsitään vain osaava toimittaja, ainahan heilläkin on uuden asiakkaan kanssa sama problematiikka ja he ovat ammattilaisia “asiakkaan haltuunotossa”. Päätettiin karsia pois vaatimukset samoista tiimin jäsenistä.
  • Peruskriteeristö osaamiselle saatiin raavittua kasaan, jossa päätettiin jakaa osaaminen kahteen kategoriaan: Vanhempi softakonkari ja nuorempi ohjelmoija. Lisäksi tiimille yhteisiä vaatimuksia kirjattiin, kuten nyt kilpailutettavan, Atlassian Confluencen, osaaminen.
  • Reality sets in, tarjouspyynnön ja sen 9 liitetteen työstäminen alkaa. Paljon opeteltavia asioita itsellekin, jotta voi työskennellä tehokkaammin.
  • Codento järjesti mahtavan tilaisuuden julkisen puolen hankinnoista, jossa keskityttiin ketterän ohjelmistokehityksen kilpailuttamiseen. Töitä esiteltiin muutamien toteutusten perusteella. Sitran kilpailutus on näistä ehkä eniten medioissa huomiota saanut (linkki). Codenton järjestämä tilaisuus oli yksittäinen tässä hankkeessa oppimisen, verkostoitumisen ja heureka lampun syttymisen hetkiä. http://opencorporatesite.posterous.com/
  • Sitran ja muutaman muun tahon kanssa vaihdettiin sähköposteja, miten kukin olivat tapauksensa hoitaneet. Tästä ja mm. Sitran blogin lukemisesta tuli paljon hyviä ideoita.
  • Tässä vaiheessa on hyvä muistuttaa, että me olemme tekemässä puitesopimusta, jossa ollaan ostamassa monta toisistaan täysin eriävää toteutusta, joka yksistään asettaa riman korkealla. Samalla tuli huomattua, että taidetaan olla tekemässä tätä ensimmäistä kertaa hankintalain puitteissa Suomessa.
  • Castren&Snellman oli hoitanut Sitrankin tapauksen sopimus ja kilpailutuspuolta, joten sieltä löytyi luonteva kumppani myös meidänkin tapaukseen.
  • Mallia työstäessä huomattiin, että ehkä pelkkä sopimussakko ei ole hyvä tapa edetä, vaan onnistuneista hankkeista tulisi myöntää bonus toimittajalle. Tämä mahdollistaa tarjousta tehdessä toimittajan itsearvioinnin omasta onnistumista ja ottaa tämä huomioon hinnoittelussa sekä varmistaa parempia tuloksia kun projekteja aletaan tehdä.
  • Kilpailutusta muokattiin siihen suuntaan, jota olimme ajatelleet, mutta emme saaneet ehkä paperille yksiselitteisesti C&S:n kanssa yhteistyössä. C&S:stä oli iso apu lakipuolessa. Meidän substanssin ja heidän laki- sekä sopimusosaamisen yhdistämällä saatiin huomattavasti parempi lopputulos.
  • Useiden iteraatioiden jälkeen oli iso läjä paperia kasassa, joka simuloinninkin jälkeen vaikutti mahdolliselta onnistua. Oli hauska huomata, miten paljon vaivaa tähän mennessä on nähty iteraatioden, kirjoitus ja ajatustyön muodossa, että uskalletaan laittaa kilpailutus ulos.
  • Nyt eletään mielenkiintoisia viimeisiä päiviä ennen kilpailutuksen julkaisemista.

Tässä lyhyt kuvaus kuinka kilpailutus etenee julkaisusta eteenpäin:

Toivomme kilpailutukseen osallistujilta avointa mieltä ja rohkeutta. Toivomme myös, että monet osallistuvat kilpailutukseen ja löydämme tästä joukosta toimittajan, josta tulisi pitkäaikainen kumppani näiden ketterien ja mielenkiintoisten toteutusten tekijöinä.

Aalto-yliopiston tutkijat ja opiskelijat ovat osoittaneet mielenkiintoa mallia kohtaan, mikä mahdollistaisi erittäin mielenkiintoisten ryhmien tekemisen tulevaisuudessa valitun toimittajan kanssa. Malli on rakennettu niin, että ensimmäisten tapausten täytyy onnistua, jotta lisätilauksia tehdään. Tämä on sekä meidän Aalto IT:ssä intressi, että myöskin valitun toimittajan.

Suurkiitokset Jukka Kataiselle Aalto IT:n hankinnoista, joka on Aalto IT:n puolelta vastannut hankintaosaamisesta, missä blogin kirjoittaja on toiminut substanssin edustajana.

Näin puolivälissä matkaa voisi todeta, että ketterän sovelluskehityksen kilpailutus julkisella puolella on vaativaa ja varsinkin sellaisen puitesopimuksen tekeminen asettaa aikamoisia haasteita. Hankintalakia ei ole pohdittu ketterän sovelluskehityksen näkökulmasta, joten tiettyjä hyviä ideoita jäi kilpailutuspaperin ulkopuolelle, joita toivittavasti voidaan hyödyntää tulevassa kumppanuussuhteessa toimittajan kanssa.

Mitäs sitten saatiin aikaiseksi?

Kilpailutuspaperi, jossa laadulla on 60% painoarvo ja hinnalla 40% painoarvo. Laatua pyöriteltiin monesta eri vinkkelistä, mm. miten työn tehokkuutta voidaan mitata kannustimen vinkkelistä, koska SCRUM-mallissa tiimi määrää itse otettavan työmäärän. Tiimi tulee pääosin toimittajalta, joten tätä arvioitaessa on pieni luonnollinen ristiriita.

Laatua tullaan arvioimaan erityisesti onnistuneista asiakkuussuhteista, näiden jatkuvuudesta sekä kyvykkyydestä ylläpitää ja valmentaa tiimiä.

Kuten aina työelämässä, tämä ei ole ainut tärkeä asia, joten työtä on jouduttu pilkkomaan paljon muiden kiireiden vuoksi ja sisäisestikin on aiheutettu rinnakkaisuudella viivästymistä vuoden 2011 lopun tavoitteesta. Matkalla on kuitenkin opittu erittäin paljon ja tätä samaa mallia voidaan lähes tällaisenaan hyödyntää seuraavaan kilpailutukseen, jossa on tarkoitus kilpailuttaa tapa tehdä muitakin kuin web-sovelluksia :) Joten oppi, onnistumiset ja epäonnistumiset eivät tässäkään tapauksessa mene hukkaan. Jo tähän mennessä on kertynyt allekirjoittajalle lisää verkostoja, oppia ja osaamista kilpailutuksesta.

Vaikka malli toimiessaan onkin ketterä ja taipuisa, niin ikävä kyllä mallin rakentamista kahlitsee julkisen puolen hankinnan laki. Varmasti kaikki osapuolet olisivat tekemässä töitä pilottien kautta 3 kuukauden kilpailutuksen jättöaikojen sijasta :)

Kun kilpailutus on saatu pakettiin, oma roolini tulee olemaan varmaan enemmän taka-alalla ja jotenkin on haikea olo muihin tehtäviin siirtyessä. Miksi? Eihän kilpailutus voi niin kivaa olla? Ei se olekkaan, mutta tiedän, että IT-innovaatiopalvelusta tulee jotain mahtavaa kun byrokratia on saatu hoidettua!

Moikka,

Meillä olisi tarkoitus pistää ulos huomenna ketterän softakehityksen puittari kilpailutukseen.

Ajattelin, että kertoisin blogissani seuraavaa Codentosta:

”Codento järjesti mahtavan tilaisuuden julkisen puolen hankinnoista, jossa keskityttiin ketterän ohjelmistokehityksen kilpailuttamiseen. Töitä esiteltiin muutamien toteutusten perusteella. Sitran kilpailutus on näistä ehkä eniten medioissa huomiota saanut (linkki). Codenton järjestämä tilaisuus oli yksittäinen tässä hankkeessa oppimisen, verkostoitumisen ja heureka lampun syttymisen hetkiä.”

Ajattelin vain, että on hyvien tapojen mukaista kysyä tästä, vaikka tuo onkin pelkkää plussaa teille J Teksti saattaa hieman muuttua, kun oikoluen ja järjestelen koko blogipostin lopulliseen muotoonsa.

Jos ei ole mitään sitä vastaan, niin pistän linkin vielä tulemaan koko postiin, kun se on valmis.

yt,

Tomi Lamminsalo
IT Service Excellence Leader

Aalto-yliopisto / IT
tomi.lamminsalo@aalto.fi
p. 050 314 1544

http://fi.linkedin.com/in/tomilamminsalo

Posted by Tomi

Uncategorized - 2 Comments

Innovaatiopalvelumallin groomaus

Ketterien menetelmien ja etenkin Scrumin yhteydessä puhutaan usein kehitysjonon “groomauksesta” (Backlog grooming). Groomauksella ei ole virallista asemaa Scrumissa, mutta silti se on hyödyllinen ja paljon käytetty menetelmä.

Groomauksessa on yksinkertaisesti kyse vain siitä, että muun muassa sprinttien alussa uudelleentarkastellaan kehitysjonoa ja siinä olevia tehtäviä: epikkejä pilkotaan seuraavassa sprintissä toteutettaviksi käyttäjätarinoiksi, käyttäjätarinoita priorisoidaan uudelleen ja joitakin epikkejä tai käyttäjätarinoita saatetaan poistaa kokonaan, koska ollaan havaittu ne tarpeettomiksi. Kyse on vain siis tehtävälistan siivoamisesta, jotta voidaan keskittyä olennaiseen eli toteuttamaan tuotteen käyttäjille lisäarvoa tuottavien toiminnalisuuksien toteuttamiseen. Pidimme Reaktorin kanssa työpajan, jossa “groomasimme” Reaktorin konsulttien fasilitoimana innovaatiopalvelumalliamme.

Työpajan aluksi sovimme työpajallemme pelisäännöt, jotta pystyisimme keskittymään innovaatiopalvelumallin kannalta olennaisiin asioihin. Tässä käytimme hyväksemme David Rockin valmennusmallia, jossa on viisi eri tasoa:

  1. Visio
  2. Suunnittelu
  3. Yksityskohdat
  4. Ongelmat
  5. Draama

Totesimme, että pyrimme keskittymään visioon, suunnitteluun sekä ongelmiin ja välttämään draamaa sekä juuttumista yksityiskohtiin, mitä väistämättä usein esiintyy kun laitetaan joukko ihmisiä työskentelemään yhdessä. Pelisääntöjen sopimisen jälkeen sovimme työpajallemme yhteisen teeman, jota vasten tulisimme peilaamaan työpajan onnistumista sen lopuksi. Pienen jumppaamisen jälkeen saimme muotoiltua teemaksi “yhteisen ymmärryksen luomisen tavoitteista ja toimintatavoista”. Tämä oli tärkeää, sillä palvelumallin parissa työskentelee useita henkilöitä eri ryhmistä IT:ssä, joilla kaikilla oli hieman erilaisia näkemyksiä ja käsityksiä itse mallista ja sen toiminnasta.

Työpaja Reaktorin kanssa

Kuva 1. Innovaatiopalveluprosessin groomausta

Tämän jälkeen aloimme pohtimaan asioita, joihin halusimme lisävalaistusta työpajan avulla. Näitä olivat:

  • Palvelun tavoitteen kirkastaminen
  • Palvelun toteuttamisen oletetut rajoitteet
  • Eri tahojen tavoitteet
  • Prosessin parantaminen
  • Palveluun tulevan iden isän tukeminen

Aloitimme palvelun tavoitteen eli vision kirkastamisesta. Aktiivisen keskustelun jälkeen saimme tiivistettyä  vision yhdeksi lauseeksi: “Rohkeaa uusien palveluiden tuottamista ja niistä oppimista”. Visiolauseen “rohkeaa” -sanan taustalla oli ajatus, että haluamme innovaatiopalvelumallin avulla ennakkoluulottomasti kokeilla erilaisten palveluiden tuottamista ja ideoiden toteuttamista, mutta myös samaan aikaan huomioida pitää mielessä että valtaosa palveluista tulee lopulta jäämään vain kokeiluksi. “Oppimista” -sanan taustalla ajatuksena taas oli, että toteutettavat palvelut jäisivät vain kokeiluiksi, niin oppisimme silti niiden totetuksen aikana jotain, joka voi hyödyntää meitä myöhemmin kuten esimerkiksi pystymme parantamaan prosessiamme tai opimme uusia tekniikoita ja työasketelymalleja.

Innovaatiopalvelumallin rajoitteita miettiessämme päällimmäisenä esiin nousivat rajoitteet rahan, resurssien ja teknologioiden suhteen sekä siitä, että kuinka asiakkaan edustaja on valmis sitoutumaan toteutusprojektiin. Innovaatiopalvelumallin rahoituksen suhteen koettiin ongelmaksi, että jos asiakas ei itse ole vastuussa rahoituksesta, niin sitoutuminen projektiin voi olla vajavaista. Samalla kuitenkin todettiin, että käytettävissä oleva absoluuttinen rahasumma ei ole ainoa mittari, vaan summan täytyy olla asiakkaalle merkittävä. Myös palvelun rahoitusmallin totustapa aiheutti keskustelua: miten rahoitusta tulisi jakaa tuotekehitysken eri vaiheissa; mitä jos huomataan jo heti alkuvaiheessa; että ideaa ei kannatakkaan tai pystytä toteuttamaan; kuinka idean jatkorahoitus tapahtuu, kun palvelu on kulkenut innovaatiopalveluprosessiputken läpi?

Resurssien suhteen haasteiksi nähtiin, että kuinka pitkäksi aikaa resurssit halutaan sitoa yhteen projektiin ja kuinka toimitaan, jos tuleekin eteen vielä mielenkiintoisempi idea, johon haluttaisiin panostaa työvoimaa. Asiakkaan sitotuminen muutenkin kuin taloudellisessa mielessä mietitytti, sillä tyydyttävään lopputulokseen on mahdotonta päästä ilman että asiakas itse on aktiivisesti mukana antamassa palautetta vastaako kehitettävä tuote hänen tarpeitaan. Myös käytettävät teknologiat asettavat omat rajoitteensa, sillä vaikka kyse on innovaatiopalvelusta, niin mitä tahansa ei ole mahdollista toteuttaa tehtyjen teknologia-alustavalintojen vuoksi.

Eri tahojen tavoitteita pohtiessamme esiin nousi lähinnä eri sidosryhmiä kuten Aallon ja IT:n johto, IT, asiakas ja sen edustajat kuten opetus ja tutkimus. Totesimme myös, että  meillä itsellämme on tavoiteita palvelumalliin liittyen kuten esimerkiksi oppiminen ketteristä menetelmistä ja uusista teknologoista.  Jossain vaiheessa työpajaa totesimme, että aika ei riitä kaikkien työpajan asioiden läpikäymiseen. Päätimme keskittyä lopuksi miettimään kuinka voisimme parantaa itse prosessia ja jättää palvelun idean isän tukemisen kehittämisen mahdolliseen seuraavaan työpajaan. Teemu Toivonen on kuvaunnut blogikirjoituksessaan yksityiskohtaisemmin, millaisia kehityskohteita löysimme itse prosessiin.

Yhteenvetona voi todeta, että työpaja onnistui hyvin, sillä saimme työpajan aikana luotua yhteisen ymmärryksen mitä olemme tekemässä ja millä tavalla. Samalla saimme jäsenneltyä ja tarkennettua itse innovaatiopalveluprosessia, minkä seurauksena pystyimme määrittelemään seuraavaksi toteutettavat tehtävät. Ja kuten groomauksessa usein myös käy, totesimme että osa asioista ei olekkaan niin olennaisia tai eivät vain tulisi käytännössä toimimaan  kuin mitä olimme etukäteen kuvitelleet.

Posted by Ville

Uncategorized - Leave a comment

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

Posted by Teemu

Uncategorized - Leave a comment

Käyttäjätarinoita ja planning pokeria

Käyttäjätarina kuvaa yksittäisen toiminnallisuuden käyttäjän näkökulmasta ja hänen “kielellään”. Käyttäjätarina on yksikkö, jonka perusteella voidaan toteuttaa jokin tilaajalle hyödyllinen toiminnallisuus. Testasimme käyttäjätarinoiden suunnittelua ja niiden työmäärien arviointia työpajassa, jossa mukana oli Product Owner (PO), Product Owner-tutorit sekä kehittäjät.  Tätä ennen olimme hahmotelleet teemat ja epicit valmiiksi. Aloitimme kyselemällä PO:lta, mitä kukin Epic sisältää, ja PO:n vastausten perusteella kirjasimme ylös käyttäjätarinoita. Kirjaukset tehtiin tässä vaiheessa Post It -lapuille. Aina kun yksi Epic oli purettu käyttäjätarinaksi, huomasimme hyödylliseksi, että aikaan saatu tarina validoidaan saman tien PO:lla. Tämä tarkoittaa sitä, että varmistimme, että tarinat ovat juuri sellaisia kuin PO haluaa käymällä syntyneet tarinat kertaalleen läpi.

Keskusteluissa sekä kehittäjiltä että PO-tutoreilta tuli kysymyksiä, jotka tukivat PO:n idean kehittämistä ja tarinoiden tarkentamista.  Huomasimme, että olisi ollut hyödyllistä jakaa työpaja kahteen osaan, jossa ensimmäisessä työstetään käyttäjätarinat ja toisessa tehdään työmääräarviot. Tässä välissä on hyvä olla aikaa kirjoittaa tarinat puhtaaksi ja varmistaa, että tarinat ovat ymmärrettäviä kaikkien osapuolten näkökulmasta.

Kun tarinat oli työstetty ja kuvattu Post It -lapuille, annettiin kaikille tarinoille työmääräarvio. Tämä tapahtui siten, että kukin kehittäjä esitti oman arvionsa työmäärästä tunteina. Jos työmäärät erosivat toisistaan, niistä keskusteltiin lyhyesti ja haettiin yhteinen näkemys työmäärästä. Alkuvaiheeseen työmääräarvioiden riski on suurin, joten tietty määrä epävarmuutta kuuluu asiaan. Kehittäjät saattavat huomaamattaan vaikuttaa toistensa työmääräarvioihin, mikäli arviot sanotaan ääneen vuoron perään. Yksi keino tämän ongelman välttämiseksi on Planning Poker: jokainen kehittäjä valitsee korttipakasta numeroidun kortin, joka kertoo hänen työmääräarvionsa. Kortit pidetään nurinpäin käännettynä, kunnes kaikki ovat valinneet arvionsa. Sitten kaikki avaavat korttinsa, ja keskustelu voi jatkua.

Tämän työpajan tuloksena meillä oli 14 käyttäjätarinaa työmääräarviolla varustettuna. Tässä voisi olla hyvä kokonaisuus vaikka ensimmäiseksi julkaisuksi!

.

Posted by Anne

Uncategorized - Leave a comment

Scrum ja tuoteomistajan rooli

Innovaatiopalvelumallissa palvelut toteutetaan käyttämällä Scrum-viitekehystä. Asiakas toimii palvelun toteutuksen aikana tuoteomistajana (Product Owner, PO), joka on yksi Scrumiin kuuluvista rooleista.  Palvelun toteuttamisen kannalta ei haittaa, jos tuoteomistajan rooli ei ole asiakkaalle entuudestaan tuttu, sillä IT antaa valmennusta ja tukea roolissa toimimiseksi. Tässä kirjoituksessa käydään lyhyesti läpi tuoteomistjan roolia Scrumissa, mitä tuoteomistajana toimiminen pitää käytännössä sisällään ja kuinka rooli ja tehtävienjako poikkeavat perinteisemmistä tuotekehitykseen liittyvistä rooleista ja tehtävienjaosta.

Vaativa mutta palkitseva tehtävä

Tuoteomistajan rooli on vastuullinen ja vaativa tehtävä, mutta myös palkitseva, sillä tehtävässä pääsee vaikuttamaan kokonaisvaltaisesti kehitettävään tuotteeseen. Tuoteomistaja vastaa tuotteen korkean tason visiosta eli mitä projekti tuottaa, ketä varten ja miksi. Hänen tehtävänsä on hankkia rahoitusta tuotekehitystä varten ja optimoida kehitysinvestoinille saatavaa tuottoa eli ROI:ta. Lisäksi hän edustaa tuotteen sidosryhmien näkemyksiä ja vastaa tiedon keräämisestä  mitä ominaisuuksia tuotteessa pitää olla ja mikä on niiden suhteellinen arvo toisiinsa nähden, eli mitä ominaisuuksia toteutetaan ensin, mikä on julkaisun laajuus ja ajankohta. Käytännön kannalta merkittävä asia on, että tuoteomistaja omistaa tuotteeseen liittyvän tuotteen kehitysjonon (Product Backlog).  Hän on kehitysjonon ainoa omistaja ja vain hänellä on oikeus tehdä päätöksiä tai muutoksia siihen liittyen. Toki kehitysjonoon liittyviä päätöksiä varten tuoteomistaja kerää tietoa tuotteeseen liittyviltä sidosryhmiltä, joten aikaa kuluu yhteistyöhön sidosryhimen kanssa kokouksien, viestinnän ja raportoinnin muodossa.

Läpinäkyvyyttä, tarkastelua ja sopeuttamista

Tuoteomistaja on siis yksi Scrum-viitekehykseen kuuluvista rooleista. Tuoteomistajan lisäksi Scrumissa on kaksi muuta roolia:  Scrumaster ja kehitystiimi (Team). Scrum on menetelmä, joka pohjautuu empiiriseen prosessikontrolliin, ja siihen kuuluu kolme tukijalkaa:

  1. Läpinäkyvyyden luominen, mikä tarkoittaa että prosessin lopputulokseen vaikuttavien tekijöiden tulee olla näkyvissä prosessiin vaikuttaville henkilöille;
  2. Prosessin säännöllisen tarkastelun avulla pyritään havaitsemaan haitalliset poikkeamat riittävän ajoissa;
  3. Prosessin ja tuotteen kehitykseen liittyvien asioiden sopeuttamisella tuotteesta saadaan hyväksyttävä ja myöhemmät poikkeamat minimoidaan.

Scrumissa  (Kuva 1.) on kolme tapaa tarkastelun ja sopeuttamisen toteuttamiseen:

  1. Päivän Scrum -kokouksessa (Daily Scrum) seurataan edistymistä kohti sprintin tavoitetta ja tehdään sopeutuksia, joiden avulla työnteko olisi mahdollisimman tehokasta tavoitteisiin nähden.
  2. Sprintin suunnittelu- (Sprint Planning) ja katselmointikokouksissa (Sprint review meeting) suunnitellaan kuinka  tuotteen julkaisutavoitetteseen päästään. Vastaavasti tarkastellaan kuinka hyvin päättyneessä sprintissä onnistuttiin  ja mietitään mitä muutoksia (sopeutuksia) pitää tehdä, jotta seuraavan sprintin jälkeen tuote vastaisi entistä paremmin tavoitteita.
  3. Sprintin retrospektiivikokouksessa (Retrospective meeting) tarkastellaan kuinka kehitystiimin työskentely sujui sprintin aikana ja mietitään, että miten työntekoa voitaisiin kehittää,  jotta seuraavassa sprintistä työskentely olisi tuottavampaa ja mukavampaa.
Scrum-prosessi

Kuva 1. Scrum-prosessi (http://www.waterfall-model.com/agile-scrum/)

Yhteistyötä kehitystiimin kanssa

Scrum-viitekehyksen mukaan tuoteomistajan kuuluu olla läsnä tuotteen kehitysjonon (Product Backlog) refaktoroinnissa,  sprintin suunnittelukokouksessa ja sprintin katselmointikokouksessa (review). Tuotteen kehitysjonossa listataan kaikki vaatimukset tuotteelle, jota kehitystiimi(t) kehittävät.  Scrumin sääntöjen mukaan kehitystiimi voi käyttää kehitysjonon refaktiorointiin 5-10% ajastaan.

Sprintin suunnittelukokouksessa suunnitellaan alkava kehitysjakso eli sprintti. Sprintin suunnittelukokous koostuu  “mitä?”  ja “miten?” osista. Suunnittelukokouksen “mitä” -osassa  tuoteomistaja esittelee kehitystiimille listan tuotteen vaatimuksista (kehitysjonon) sekä niiden prioriteetit.  Tämän jälkeen kehitystiimi ja tuoteomistaja yhdessä miettivät mitä asioita kehitysjonosta valitaan työstettävksi seuraavassa sprintissä.

Suunnittelukokouksen “miten” -osassa tuoteomistaja ja kehitystiimi  miettivät kuinka “mitä” -osiossa valitut asiat saadaan sprintin aikana toteutettua. Tuoteomistaja tarkentaa tarvittaessa kehitystiimille tuotteen kehitysjonon sisältöä ja auttaa löytämään kompromisseja. Sprintille valitaan myös tavoite, jonka tarkoituksena on antaa kehitystiimille konkreettinen näkökulma ja perustelu, miksi se on kehittämässä tuotteen ominaisuuksia. Jos kehitystiimi huomaa, että sprintissä onkin liikaa tai liian vähän tehtäviä, se voi neuvotella uudestaan tuoteomistajan kanssa kehistysjonon sisällöstä. Kehitystiimi ja tuoteomistaja voivat kutsua suunnittelukokoukseen mukaan muitakin henkilöitä saadakseen teknisiä tai liiketoiminnallisia neuvoja kehitettävään tuotteeseen liittyen.

Sprintin katselmoinnissa scrumtiimi ja muut asianosaiset henkilöt käyvät yhdessä läpi sprintin saavutukset. Katselmoinnin ja tuoteomistajan päivittämän tuotteen kehitysjonon perusteella selvitetään mitä seuraavaksi kannattaa tehdä.  Tuoteomistaja selvittää kehitystiimin kanssa mitkä sprinttiin valituista kehitysjonon kohdista on saatu valmiiksi ja mitkä ovat vielä kesken. Kehitystiimi keskustelee mikä sujui hyvin, mitä ongelmia ilmeni ja kuinka ongelmat ratkaistiin. Kehitystiimi myös esittelee tekemänsä työn ja vastaa kysymyksiin.

Scrumissä määriteltyjen tapahtumien lisäksi tuoteomistaja  on jatkuvassa  yhteistyössä kehitystiimin kanssa myös sprintin kuluessa muun muassa vastaamalla kehitystiimin hänelle esittämiin kysymyksiin.

Uskoa asiaansa, tietoa, valtaa ja aikaa

Kenen tulisi toimia tuoteomistajana? Koska tuoteomistaja joutuu perustelemaan eri sidosryhmille, kuten rahoittajille, käyttäjille sekä kehitystiimille, miksi tuotetta ollaan kehittämässä, täytyy hänen itsensä myös “uskoa asiaansa“, jotta hän saisi myös muut vakuuttuneiksi ja sitoutumaan tavoitteisiin. Pelkällä tahdonvoimalla ei kuitenkaan tule valmista, vaan tuotteen omistajalla pitää olla myös riittävästi tietoa kehitettävään tuotteeseen ja tuotekehitysprosessiin liittyen. Tuoteomistajalla tulisi olla tietoa liiketoimintaprosessista, jossa tuotetta tullaan käyttämään ja hänen pitäisi ymmärtää tuotetta myös loppukäyttäjän näkökulmasta. Tuoteomistajalla on hyvä olla myös riittävästi valtaa, sillä hän on vastuussa tuotteeseen liittyvistä päätöksistä, ja päätöksenteko usein edellyttää eri sidosryhmien näkökulmien huomioimista. Tuoteomistajalla täytyy myös olla riittävästi aikaa, sillä ilman aktiivista yhteistyötä tuotteen toutettavan kehitystiimin ja eri sidosryhmien kanssa, ei käyttäjilleen lisäarvoa tuottavan tuotteen toteuttaminen ole mahdollista.

Perinteisenen tuotekehitys ja Scrum

Tuoteomistaja vastaa tehtävistä, jotka perinteisesti ovat kuuluneet markkinointipäällikölle ja tuotepäällikölle. Tuoteomistajan pitää muun muassa ymmärtää markkinoita ja osata myös itse markkinoida, ylläpitää tuotteen tiekarttaa (road map) ja seurata tuotteen tuomia kumulatiivisia voittoja eri julkaisujen välillä. Suuremman kuvan ymmärtämisen lisäksi tuoteomistajan pitää kuitenkin pystyä kuvaamaan ja priorisoimaan tuotteen ominaisuuksia yksityiskohtaisemminkin ja keskustelemaan niistä kehitystiimin kanssa. Koska perinteisesti eri rooleille jakaantuneet tähtävät ovat nyt yhden ja saman henkilön vastuulla, vältytään tiedon siirtämiseltä eri yksiköiden välillä, jolloin syntyy vähemmän odottelua, viiveitä sekä väärinymmärryksiä että virheitä.

Sen lisäksi, että Scrumissa tuoteomistaja vastaa markkinointipäällikön ja tuotepäällikön tehtävistä,  kehitystiimi ottaa vastuun monista perinteisesti projektipäällikölle kuuluvista tehtävistä. Tiimi esimerkiksi tunnistaa itse sprintin tavoitteen sanelemat osatehtävät ja vastaa niiden työmäärien arvioinnista. Samoin tiimi itse hallinnoi tehtävien toteutusta ja toteutustapaa, aikataultusta ja allokointia sprintin aikana. Jos ongelmia tulee eteen, on tiimin itsensä, eikä siis projektipäällikön,  vastuulla puuttua niihin ja keksiä kuinka ne saadaan ratkaistua. Tiimi on siis itse vastuussa, että se tekee oikeita asioita oikeaan aikaan ja oikealla tavalla.

Posted by Ville

Uncategorized - Leave a comment

Käyttäjäpersoonat herättävät käyttäjät eloon

Palvelun käyttäjät ovat todellisia ihmisiä ominaisuuksineen, tavoitteineen ja tarpeineen. Toimiva ja tehokas palvelu suunnitellaan todellisten käyttäjien näkökulmasta, ja tässä apuna toimivat käyttäjäpersoonat. Käyttäjäpersoona on esimerkki kuvitteellisesta käyttäjästä, joka on tavalla tai toisella tekemisissä palvelun kanssa. Näihin personiin liitämme sitä tietoa, jota meillä on käyttäjistä. Käyttäjäpersoonat eroavat perinteisemmästä tavasta kuvata käyttäjiä tietyn roolin edustajana kuten vaikkapa virkailija tai pääkäyttäjä. Persoona on yksittäinen esimerkki käyttäjäroolin edustajasta; hän ei ole keskiarvo, vaan todellisen kaltainen persoona.

Käyttäjäpersoonat herättävät käyttäjät eloon kehittäjien mielissä. Hyvä käyttäjäpersoona on kuvaava sekä sanallisesti että visuaalisesti, ja valokuva auttaakin persoonan elävöittämisessä. Jokaisella palvelun kehittäjällä on mielessä jonkinlainen kuva tyypillisestä käyttäjästä, mutta mielikuvat voivat vaihdella henkilön mukaan. Käyttäjäpersoonat auttavat yhteisen näkökulman luomisessa, ja näin ollen koko ryhmälle syntyy selkeä mielikuva siitä, minkälaiselle käyttäjälle palvelua tehdään. Käyttäjäpersoonat ovat yksi työkalu hyvän kokonaisnäkemyksen saavuttamiseksi.

Sähköisen ostoslistan tapauksesta löysimme seuraavanlaisia käyttäjäpersoonia:

Nimi: Maija
Ikä: 40 v
Koulutus: Tekniikan tohtori
Ammatti: Tutkija
Asuu: Espoossa rivitalossa, josta on noin kolmen kilometrin matka lähimpään ostoskeskukseen
Perhe: Aviomies, poika Joonas 12-v ja tytär Johanna 9-v
Mitä tekee: Perheen äitinä pitää huolta siitä, että perhe syö ekologisesti ja terveellisesti. Käy myös usein kaupassa, vaikka myös Joonas ja Mikko osallistuvat ostosten tekemiseen.
Arvostaa: Ekologisuutta, vapaa-aikaa perheen ja harrastusten parissa
Tavoittelee: Professorin paikkaa, lisää laatuaikaa harrastustensa ja perheensä kanssa

Nimi: Mikko
Ikä:
41 v
Koulutus:
Tekniikan tohtoriAmmatti: Tutkija VTT:llä
Mitä tekee:
Käy silloin tällöin kaupassa Maijan ohjeiden mukaan. Mikko haluaa suoritutua ostoksista mahdollisimman nopeasti, eikä hän ole kiinnostunut shoppailusta. Hän perustaa ostoskäyttäytymisensä faktoille kuten kauppamatkan minimoininen ja ostosten edullisuus.
Arvostaa:
Vapaa-aikaa perheen sekä lenkkeily- ja pienoisrautatieharrastusten parissa. Välillä Mikko tarvitsee aikaa tutkimustyöhön myös illalla kotona.
Tavoittelee: Paikkaa kansainvälisessä tutkijaryhmässä ja lisää aikaa pienoisrautatieharrastukselle.

Nimi: Joonas
Ikä: 12 v
Koulutus: koululainen
Mitä tekee: Käy välillä kaupassa Maija-äidin kanssa ja esittää toivomuksia illallisista sekä välipaloista.
Arvostaa: Jääkiekkoa ja äidin laittamaa hyvää ruokaa. Urheilijana terveellinen ruokavalio on Joonakselle tärkeä.
Tavoittelee: Paikkaa C-junioreiden SM-sarjassa, haluaa olla cool ja suosittu koulu- sekä jääkiekkokavereiden keskuudessa.

Sähköisen ostoslistan kehityksessä käyttäjäpersoonat ovat apuna vastatessa kysymyksiin kuten ”Tarvitseeko Maija tätä toimintoa?” tai ”Miten Mikko löytää helpoiten lähimpään kauppaan?”.

Minkälaisia käyttäjäpersoonia Sinun ideaasi voisi liittyä?

Posted by Anne

Uncategorized - Leave a comment

Lean Canvas – Työkalu vision jalostamiseen

Ketteristä toimintamalleista puhuttaessa usein viitataan kenraalina ja presidenttinä toimineen Dwight D. Eisenhowerin lausahdukseen, missä hän toteaa: “Valmistautuessani taisteluun olen aina huomannut, että suunnitelmat ovat turhia, mutta suunnitteleminen on välttämätöntä.” Lause kuvastaa sitä, että taistelut eivät koskaan mene etukätesissuunnitelmien mukaan, mutta suunnitteleminen on kuitenkin tärkeää, jotta ollaan etukäteen huomiotu taistelun kulkuun vaikuttavat tekijät  ja pystytään siten reagoimaan paremmin eteen tuleviin ennakoimattomiin tilanteisiin – olemaan siis ketteriä.

Kun visiodokumentti on kirjoitettu ja sen perusteella idealle on näytetty vihreää valoa, alkaa vision työstämien sen käytännön toteuttamiseksi. Taisteluvertauskuvaa käyttäen voitaisiin todeta, että visiodokumentin perusteella taisteluun ryhtyminen näyttäisi olevan hyvä ratkaisu, minkä jälkeen edessä on vision jalostaminen, eli suunnitelman laatiminen taistelua varten.

Suunnittelemista varten on olemassa useita erilaisia työkaluja. Yksi hyvä ja yksinkertainen työkalu on Ash Mauryan (Kuva 1.) luoma viitekehys liiketoimintasuunnitelman kirjoittamista varten.  Viitekehys on yksinkertainen, mutta pyrkii samalla vangitsemaan kaikki oleelliset asiat, jotka on hyvä ottaa huomioon suunniteltaessa uuttu liiketoimintaa. Suunnitelma mahtuu yhdelle A4-arkille, jolloin sen lukeminen ja päivittäminen on helppoa ja nopeaa. Vaikka viitekehys on luotu yritysmaailman lähtökohdista, voidaan sitä käyttää hieman soveltaen myös yliopistomaailmassa, ja siksi malli sopii hyvin myös työkaluksi innovaatiopalvelun vision jalostamiseen ja dokumentoimiseen.

Kuva 1. Ash Mauryan Lean Canvas -viitekehys

Seuraavassa käydään läpi Lean Canvas -viitekehystä ja sovelletaan sitä esimerkki-innovaationa olevaan sähköiseen ostoslistaan.

1. Liikkelle voidaan lähteä kuvaamalla lyhyesti kolme tärkeintä ongelmaa (Problem), joihin uusi palvelu tai tuote tarjoaa ratkaisun. Sähköisen ostoslista tarjoaa rartkaisun esimerkiksi seuraavanlaisiin ongelmiin:

  • Perheen ostostarpeet eivät olet ajantasalla, ja joskus jää jotain tarpeellista ostamatta, ja vastaavasti joskus ostetaan jotain tarpeetonta.
  • Kun kauppaan mentäessä on selkeä ostoslista, on kaupassa käyminen  helpompaa ja mahdollisesti halvempaa, koska ei tehdä turhia heräteostoksia.
  • Ostoslistan avulla perheen ostoskäyttäytyminen tulee näkyväksi jolloin nähdään, että ostetaanko esimerkiksi halpoja tai terveellisiä tuotteita.

2. Asiakasryhmien (Customer Segments) avulla kuvataan, että ketkä ovat palvelun pääasiallisia asiakasryhmiä ja käyttäjiä:

  • perheen ostoksen tekijät
  • perheenjäsenet, jotka haluavat jotain kaupasta
  • kauppiaat

3. Palvelun arvolupaus (Unique Value Proposition) kertoo, että miksi palvelu on erilainen kuin muut olemassa olevat palvelut ja miksi tuottaa lisäarvoa käyttäjilleen:

  • Ostoksilla käyminen on aikasempaa helpompaa, tehokkaampaa ja vähentää perheen kommunikaatio-ongelmia liittyen kaupassa käyntiin.
  • Auttaa perhettä tekemään parempia päätöksiä ostettavien tuotteiden suhteen ja siteen säästämään kustannuksia.
  • Auttaa kauppiaita mainostamaan kauppojaan ja tekemään ostoskokemuksesta miellyttävämmän.

4. Ratkaisun (Solution) määrittelee mikä on pienin joukko ominaisuuksia joita tarvitaan, jotta palvelun tai tuotteen käyttäjä saa kohdassa kolme kuvattua lisäarvoa:

  • Ostoslistan päivittäminen
  • Ostoslistan tulostaminen
  • Tehtyjen ostosten tarkastelu

5. Päätoiminnot (Key Activity), joita palvelun käyttäjät käyttävät, minkä vuoksi palvelua ollaan valmiita käyttämään myös uudelleen tai palvelun käytöstä ollaan valmiita maksamaan. Tai toisella tavalla imaistuna, ne toiminnot joiden puuttumisen vuoksi palvelua ei tulla käyttämään toistamiseen:

  • Ostolistan tekeminen ja päivittäminen
  • Ostostilstan käyttäminen ostoksilla käymisen aikana
  • Tehtyjen ostoksien analyysi

6. Kanavat (Channels), joiden avulla palvelua käyttävät asiakkaat voidaan tavoittaa. Nämä voivat olla ilmaisia tai maksullisia (esimerkiksi TV tai radio):

  • Aallon IT-innovaatiopalvelun tiedotuskanavien kautta
  • Aallon intranetti (inside)
  • Lehtiartikkelit
  • Suusta suuhun

7. Kustannusrakenne  (Cost Structure) kertoo, että mistä palvelun tai tuotteen kiinteät ja muuttuvat kustannukset muodostuvat:

  • Sovelluskehityskustannukset
  • Palveluoperointikustannukset
  • Hintavertailuintegraatio
  • Suhteiden muodostaminen ja ylläpito kauppoihin
  • Kauppakarttojen tekeminen ja päivittäminen

8. Tulovirrat (Revenue Streams) kuvaa palvelun ansaintalogiikkaa, eli miten palvelun avulla saadaan  tuloja, mistä tulot muodostuvat (esimerkiksi tilauksmaksut, mainokset), millä on katteella palelua tarjotaan, mikä investoinnin on takaisinmaksuaika ja niin edelleen. Koska julkisella sektorilla palveluja ei pääsääntöisesti pyritä tarjoamaan taloudellisen voiton maksimoinnin lähtökohdista, voidaan tässä kuvata vaikkapa palvelun avulla saatavia säästöjä tai kuten visiodokumentissa mainittiin, että mitä hyöytjä palvelu tarjoaa Aalto-yliopiston ja sen henkilökunnan  näkökulmasta:

  • Säästää aaltolaisten aikaa ostoksilla käymisestä
  • Luo esimerkin innovatiivisista palveluista

9. Usein liiketoimintasuunnitelmissa kuvataan kilpailueduiksi asioita, jotka eivät oikeasti anna kilpailuetua. “Epäreilu kilpailuetu” (Unfair Advantage) kuvaa, että miksi palvelua ei voida helposti kopioida tai ostaa:

  • Tuotteistettu alusta mahdollistaa nopean ja ketterän kehityksen.
  • Innovaatiopalvelumallin avulla aika palvelun suunnittelusta sen lanseeraamiseen loppukäyttäjille (time to market, TTM) on pieni. Pienen TTM:n avulla on mahdollisuus päästä hyödyntämään markkinoilla ensimmäisen toimijan etuja (first-mover advantage).
  • Markkinaetua on mahdollista vahvistaa, jos pystytään neuvottelemaan sopimuksia palvelussa olevien kauppojen kanssa.

Lean Canvas -viitekehyksen avulla meille muodostuu suunnitelma, mitkä tekijät ovat oleellisia ja aiheuttavat reunaehtoja lähtiessämme taisteluun sähköisen ostoslistaamme toteuttamiseksi. Itse toteutuksen (taistelun) aikana eteen voin tulla tilanteita, joita emme ole osanneet ennakoida.  Mutta koska olemme systemaattisesti  kartoittaneet palvelumme suuntaviivat, pystymme paremmin arvioimaan kuinka oleellisia esiintulleet seikat ovat haluamaamme lopputulokseen pääsemisen kannalta, ja tarvittaessa pystymme muuttamaan toteutustamme vastaamaan muuttuneita tarpeita.

Posted by Ville

Uncategorized - 1 Comment

Lähdekoodin versionhallinta

Tällä kertaa aihe on hieman aiempaa käytännönläheisempi ja melko tekninen. Kerromme miten lähdekoodin versionhallinta hoidetaan innovaatiopalvelua toteutettaessa.

Versionhallintatyökaluksi on valittu Git, joka on Linus Torvaldsin kehittämä avoimen lähdekoodin hajautettu versionhallintaohjelmisto. Linus tarvitsi Linux käyttöjärjestelmän ytimen lähdekoodin versionhallintaan sopivan versionhallintaohjelmiston, mutta koska sellaista ei löytynyt, hän päätti koodata sellaisen itse. Omien sanojensa mukaan hän toteutti enimmäisen toimivan version Git:istä kahdessa viikossa.

Versionhallinta ohjelmistokehityksessä ei ole niin yksinkertainen asia kuin miltä se saattaa kuulostaa. Versiohallinnassa voidaan määrittää tietty versio ohjelmasta koostuvaksi tiettyjen tiedostojen tietyistä versiosta, ja kehittää eri versioita rinnan. Versionhallinnalla voidaan myös estää päällekkäisten muutosten, eli konfliktien syntyminen, silloin kun samaa sovellusta kehittää useampi ohjelmoija samaan aikaan. Hajautettu versionhallinta mahdollistaa myös paikasta riippumattoman työskentelyn. Jokainen sovelluskehittäjä voi kloonata koko versionhallintasäilön omalle koneelleen ja koodata vaikka kesämökillä ilman internetyhteyttä (vaikka tämä on mahdollista, niin kesämökillä pitää tietysti tehdä kaikkea muuta kuin koodata).

Ennen kuin versionhallinta voidaan ottaa käyttöön ohjelmistokehitysprojektissa, täytyy sopia metodit joiden mukaan versiohallintaa käytetään. Varsinkin git on niin joustava työkalu, että ilman yhteisesti sovittuja käytäntöjä sen käytöstä olisi todennäköisesti vain haittaa. Onneksi näitä ei tarvitse keksiä itse, vaan monet ovat ystävällisesti dokumentoineet omia käytäntöjään internettiin muiden saataville. Innovaatiopalvelumallin projekteissa käytämme tätä mallia:http://nvie.com/posts/a-successful-git-branching-model/

Tärkeintä ei ole käyttää parasta versionhallintakäytäntöä, vaan se, että käytetään edes jotain yhteisesti sovittua käytäntöä.



Esimerkki Git:in käytöstä sovitun käytännön mukaan Rails-sovelluksen kehityksessä

Esimerkki on melko pitkä, mutta se kattaa uuden Git-säilön luonnin, develop ja feature-haarojen luonnin, säilön kloonamisen käyttäjäkohtaisesti, muutosten tekemisen feature-haaroihin, ja niiden sulauttamisen (merge)  develop haaraan, sekä konfliktien ratkomisen.

Luodaan yhteinen git-säilö (origin), johon kaikki sovelluskehittäjät “työntävät” omat muutoksensa. Yhteinen säilö luodaan –bare-määritteellä, jolloin se ei sisällä lainkaan varsinaisia lähdekooditiedostoja, ainoastaan versiohistorian. Tällä estetään se, että kukaan ei mene vahigossa koodaamaan suoraan origin-sailöön, joka aiheuttaisi tarpeettomia ongelmia.

git init --bare project1.git
Initialized empty Git repository in /l/rails/project1.git/

Kloonataan se käyttäjäkohtaisesti

cd jsalmela
git clone ../project1.git
Initialized empty Git repository in /l/rails/jsalmela/project1/.git/
warning: You appear to have cloned an empty repository.
cd project1

Luodaan rails projekti

rails new .
git add .
git commit -a -m "projektin luonti"

Luodaan develop haara ja työnnetään muutokset originille

git checkout -b develop master
git push origin master
git push origin develop

Tämän jälkeen joku toinen voi kloonata säilön. Leikitään, että olen nyt toinen käyttäjä (käyttäjätunnus: jokumuu). Todellisuudessa voisin kloonata säilön vaikka eri koneelle, mutta tässä esimerkissä käytetään vain toista hakemistoa samalla palvelimella.

cd /l/rails/jokumuu
git clone ../project1.git
cd project1
ls
Gemfile  Gemfile.lock  README  Rakefile  app  config  config.ru  db  doc  lib  log public script  test  vendor

Luodaan lokaali develop-haara originin develop-haarasta

git checkout -b develop origin/develop
Branch develop set up to track remote branch develop from origin.
Switched to a new branch 'develop'

Nyt voidaan luoda uusi feature-haara develop-haarasta jossa voidaan alkaa koodaamaan.

Luodaan tietokanta ja home-controlleri.

git checkout -b feature1 develop
Switched to a new branch 'feature1'
rake db:create
rails generate controller home index

Sulautetaan develop -haaraan ja poistetaan feature-haara

git checkout develop
git merge --no-ff feature1
git branch -d feature1

Ja työnnetään muutokset origin-repoon

git push origin develop

Vaihdetaan käyttäjää (jsalmela)

cd /l/rails/jsalmela/project1
git branch -a
* develop
master
remotes/origin/develop
remotes/origin/master

Ollaan näköjään develop-haarassa, joten päivitetään se ajan tasalle originista

git pull origin develop

Luodaan uusi feature-haara (feature-haarat ovat lokaaleja, joten voidaan käyttää samaa nimeä kuin aiemmin)

git checkout -b feature1 develop

Koodataan: Luodaan tietokanta, muutetaan home/index näkymää, poistetaan oletussivu ja asetetaan oletusreitti osoittamaan home-controllerin index-toimintoon.

rake db:create
echo "<h1>Hello, Rails</h1>" > app/views/home/index.html.erb
rm public/index.html
vim config/routes.rb
------------------
# You can have the root of your site routed with "root"
# just remember to delete public/index.html.
root :to => 'home#index'
-------------------

käynnistetään sovellus

rails server

Testataan

<Ctrl-Z>
bg
curl localhost:3000
-----------
Started GET "/" for 127.0.0.1 at 2011-09-27 17:17:17 +0300
Processing by HomeController#index as */*
Rendered home/index.html.erb within layouts/application (0.4ms)
Completed 200 OK in 13ms (Views: 12.3ms | ActiveRecord: 0.0ms)
<!DOCTYPE html>
....
<body>
<h1>Hello, Rails</h1>
</body>
</html>
-------------

Toimii, pysäytetään sovellus

fg
<Ctrl-C>

Commit

git commit -a -m "muoks"

Jokumuu muokkaa myös index.html:ää

cd /l/rails/jokumuu/project1
git branch -a
* develop
f1
master
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master
git pull origin develop
From /l/rails/jokumuu/../project1
* branch            develop    -> FETCH_HEAD
Already up-to-date.
git checkout -b feature2 develop
Switched to a new branch 'feature2'
echo "<h1>Hello World</h1><p>test</p>" > app/views/home/index.html.erb
git commit -a -m "index.html muokattu"
git checkout develop
git pull origin develop
git merge --no-ff feature2
git branch -d feature2
git push origin develop

Jsalmela yrittää nyt päivittää omia muutoksiaan originille

cd /l/rails/jsalmela/project1
git checkout develop
git pull origin develop

Saadaan aikaiseksi konflikti

git merge --no-ff feature1
Auto-merging app/views/home/index.html.erb
CONFLICT (content): Merge conflict in app/views/home/index.html.erb
Removing public/index.html
Automatic merge failed; fix conflicts and then commit the result.
[1] 10652 exit 1 git merge --no-ff feature1

korjataan se

vim app/views/home/index.html.erb

Tiedosto näyttää tältä:

<<<<<<< HEAD
<h1>Hello World</h1><p>test</p>
=======
<h1>Hello, Rails</h1>
>>>>>>> feature1
~

Muokataan:

<h1>Hello Rails</h1><p>test</p>

Konflikti ratkottu

git add app/views/home/index.html.erb
git commit -a -m "konflikti ratkottu app/views/home/index.html.erb"

Voidaan päivittää originiin

git push origin develop

Posted by Jaakko

Uncategorized - Leave a comment