Leanillä tehoa liiketoimintaan – Codenton uutiskirje 12/2015

Leanin on tarkoitus vähentää turhaa taustahälyä ja omissa poteroissa istumista. Sen sijaan töitä tehdään yhdessä, yhteistä päämäärää kohti.

Mukavaa joulukuuta!

Lean on jatkuvan kehittämisen tapa, jossa tunnistetaan mikä tuottaa liiketoiminnalle ja asiakkaille arvoa, keskitytään siihen ja karsitaan turhaa. Oikein toteutettuna lean parantaa organisaation tuloksellisuutta, asiakkaiden tyytyväisyyttä ja henkilöstön flowta, ja me Codentolla liputamme etenkin leaniyttävän ohjelmistokehityksen puolesta. Tässä uutiskirjeessä:

  •    Lean leviää suomalaisessa terveydenhuollossa
  •    Tätä on lean
  •    Video: Jeffrey Likerin arvio Toyota Kata –kirjasta
  •    Lean-ajattelu ohjelmistoprojektin valmistelussa
  •    Jatkuvan parantamisen lähtökohdat
  •    Video: Obeya – tiiviimpää yhteistyötä
  •    Lean intranet

Lean leviää terveydenhuollossa

Potilaan lääkärilehti uutisoi 1.12., että lean-mallin käyttö leviää suomalaisen terveydenhuollon parissa. Menetelmän avulla parannetaan paitsi yksiköiden toimintaa, myös sairauksien hoitoja. Lähtökohtana on potilaan näkökulma.

Tätä on lean

Tätä on lean on helppolukuinen ja oivaltava kirja, josta saa hyvän peruskäsityksen, miksi joskus kannattaa katsoa mieluummin asioiden virtaa kuin yksittäisten toimijoiden resurssitehokkuutta.

Video: Jeffrey Likerin arvio Toyota Kata –kirjasta

Tässä 20 minuutin videossa Toyota Way –kirjan kirjoittaja Jeffrey Liker kertoo omasta lean-historiastaan ja arvioi Mike Rotherin Toyota Kata –kirjaa. Molemmat kirjat ovat hyviä jokaiselle, joka haluaa sukeltaa syvemmälle leaniin.

Lean-ajattelu ohjelmistoprojektin valmistelussa

Codento-lean-visiolakana

 

Miten voit tuottaa ohjelmistolla asiakkaallesi ja liiketoiminnallesi eniten arvoa? Entä miten saat ohjelmiston tehtyä tehokkaimmin? Näistä peruskysymyksistä lähtee lean ohjelmistoprojekti.

Konsulttimme Karoliina Luoto on kiteyttänyt lean-visiolakana –työkaluun tärkeimmät kysymyksesi ohjelmistoprojektin suunnittelussa. Karoliina kirjoitti myös kattavat ohjeet visiolakanan täyttämiseen. Tilaa maksutta joko täytettävä PDF tai juliste tiimitilan seinälle.

Jatkuvan parantamisen lähtökohdat

Jotta leanillä tavoiteltavalla jatkuvalla parantamisella on mahdollisuus tulla organisaation kulttuuriksi, on hyvä ymmärtää oman organisaation suhde toisiin. Silloin on mahdollista kiteyttää visio, haaste ja tavoitetila – edellytykset parannusrutiinin toimivuudelle.
Siksipä Simon Wardley johdattelee arvoketjun tilannekartoitukseen.
Ja tässä esimerkki siitä, miten Uber sijoittuisi kyseiselle arvokartalle.

Video: Obeya – tiiviimpää yhteistyötä

Kun jatkuva parantaminen on otettu osaksi toimintaa, on syytä sopia, miten aloitettua muutosta ylläpidetään ja vahvistetaan. Obeya, suuri huone, on tehokas tapa tähän.

Lean intranet

Lean ja intranet – miten ne liittyvät yhteen? Lean intranet syntyy, kun intraa tehdessä saadaan maksimoitua arvo liiketoiminnalle ja minimoitua toissijainen. Katso blogistamme Karoliina Luodon kalvosarja aiheesta.

Rauhaisaa joulunodotusta kaikille!

Petri ja koko Codento-tiimi

P.S. Tykkäsitkö tämän uutiskirjeen sisällöstä? Kiitos siitä kuuluu pitkälti uudelle lean-valmentajallemme Miika Kuhalle. Tervetuloa Codenton riveihin, Miika!

Haluatko tutustua aiempiin uutiskirjeisiimme?

Jos haluat lukea aiempia uutiskirjeitämme, tässä linkit muutamaan niistä.

Lisenssit ja avoin lähdekoodi (09/2015)
Aamiaisseminaarin antia: tietojärjestelmien omistusoikeudet (06/2015)
Tiedolla johtaminen tuo parempia tuloksia (08/2014)
Inspiraatiota uuden IT:n päättäjille (06/2014)
Uutiset IT:n päättäjille (03/2014)

Jos taas haluat saada tulevat uutiskirjeemme ensimmäisten joukossa suoraan sähköpostiisi, voit liittyä uutiskirjeemme tilaajaksi vaivattomasti blogimme sivupalkissa olevalla lomakkeella.

***

Ylempi kuva: Flickr Creative Commons, opensource.com.

Integroituuko sote-uudistus?

Sipilän hallitus julkaisi 10. syyskuuta 2015 asettamispäätöksen sosiaali- ja terveydenhuollon uudistamiseksi. Asettamispäätöksen mukaan Suomeen perustetaan 18 tai 19 itsehallintoaluetta. Niistä 15 tuottaa tai järjestää itse sote-palvelut alueensa asukkaille ja jäljelle jäävät 3 tai 4 yhdessä muiden itsehallintoalueiden kanssa. Itsehallintoalueet voivat myös ostaa sote-palveluita yksityisiltä ja kolmannen sektorin palveluntuottajilta.

Tämän uuden rakenteen myötä seuraavat tavoitteet täyttyvät

sotetavoitteetMA

Horisontaalinen ja vertikaalinen integraatio

Palveluiden vertikaalinen integraatio tarkoittaa perus- ja erikoistason sairaanhoidon integraatiota eli hoitamista samassa organisaatiossa. Horisontaalinen integraatio tarkoittaa sosiaali- ja terveysasioiden hoitamista samassa organisaatiossa. Integraation ja säästöjen lisäksi uudessa sote-mallissa tavoitteena on kansalaisten valinnanvapauden lisääntyminen.

Raha seuraa potilasta

Hallituksen tavoitteena on myös periaatteen “raha seuraa potilasta” toteuttaminen. Kansalaisten valinnanvapaus lisääntyy ja he voivat valita palveluntuottajien joukosta mieluisimman. Kun raha seuraa potilasta, niin potilasta koskevien tietojenkin on seurattava potilasta eri palveluntuottajien välillä. Tietojen on siirryttävä sekä horisontaalisesti että vertikaalisesti.

Rajapintoja tarvitaan monia

ICT-kielellä täydellinen integraatio, rahan ja tietojen siirtyminen itsehallintoalueiden ja eri palveluntuottajien välillä tarkoittaa tietojärjestelmien välisten rajapintojen rakentamista. Kun vaatimuksiin vielä liitetään asettamispäätöksessä mainittu valtion tarve valvoa itsehallintoalueiden toimintaa tarkasti, kasvaa tarvittavien rajapintojen määrä huomattavasti. Koska nykyisin maassamme on käytössä useita eri järjestelmiä kuhunkin tarpeeseen, rajapinnat ovat myös keskenään erilaisia.

Rajapintojen toteuttaminen voi olla vaikeaa

Rajapintojen toteuttaminen saattaa osoittautua hyvin vaikeaksi. Vaikeuteen on monia eri syitä, jotka tulevat vastaan jokaisessa integraatioprojektissa:

  • toisiinsa liitettävien järjestelmien määrä ei ole tiedossa. Niitä voi olla yllättävän paljon, koska kunnat ovat ostaneet kukin omat järjestelmänsä.
  • samankin järjestelmän eri ilmentymät – esimerkiksi eri kunnissa – ovat hyvin erilaisia. Kukin kunta on tilannut ja räätälöittänyt oman järjestelmänsä.
  • järjestelmiä ei ole suunniteltu toisiinsa liitettäviksi eikä niissä ole valmiina rajapintoja. Rajapinnat on siis rakennettava kuhunkin järjestelmään erikseen.
  • jopa samannimisten järjestelmien käsitemallit lienevät kaikesta yhtenäistämistyöstä huolimatta hieman erilaiset.
  • järjestelmissä on ristiriitaista tietoa ja tietojen yhtenäistäminen vaatii paljon käsityötä.

Mikä avuksi?

Onneksi näihin vaikeuksiin voi vastata monin eri keinoin.

  • Osan ongelmista voi ratkaista Kanta-järjestelmällä. Mitä enemmän SoTe-tietoa on Kanta-järjestelmässä, sen helpompaa järjestelmien on keskustella keskenään Kanta-järjestelmän kautta.
  • Kansallinen palveluväylä helpottaa tietojen siirtämistä monin tavoin.
  • Osan ongelmista voi ratkaista yhtenäistämisellä. Valtiohan voi vaatia, että kaikki 19 itsehallintoaluetta käyttävät samoja tietojärjestelmiä – aivan samaan tapaan kuin ison yrityksen osastot käyttävät samoja talous- ja henkilöstöjärjestelmiä. Missään tapauksessa valtion ei pidä sallia itsehallintoalueiden ostaa järjestelmiään toisistaan riippumatta.

Napsahtaako toimittajaloukku?

Yhtenäistämisestä huolimatta nykyisin käytössä olevien järjestelmien integroiminen toisiinsa voi osoittautua erittäin vaikeaksi. Tämä ongelma liittyy järjestelmät toimittaneisiin yrityksiin ja niiden liiketoimintaan. Onko järjestelmien integroiminen järjestelmätoimittajien etujen mukaista vai ei? Jokaisella tietojärjestelmän SoTe-sektorille rakentaneella yrityksellä on tavallaan veto-oikeus sote-uudistuksen integrointiin – tai ainakin melko suuri vapaus hinnoitella rajapintojen kehitystyö.

SoTe-uudistus kaipaa ICT-asiantuntijaa

Asettamispäätöksessä ohjaus- ja projektiryhmään ei ole nimetty yhtäkään ICT-asiantuntijaa. SoTe-uudistuksen tavoitteet toteutuvat vain, jos integraatioihin liittyvät ongelmat otetaan heti alusta alkaen vakavasti. ICT-työhön on varattava riittävästi rahaa, riippumattomia asiantuntijoita ja poliittista tahtoa. Sote-järjestelmien integroiminen ei onnistu vahingossa.

Kuva: Flickr Creative Commons, luonut Maria Boehling opensource.com:lle.

Mitä mittaat, sitä saat

Työkoneisiin ei laiteta koreilumittareita. (Kuva: Beatrice Murch)

Nykyaikaiset verkkopalvelut tuottavat suuria määriä dataa. Pienenkin startupin käyttäjämäärä mitataan helposti miljoonissa, ja pilviteknologiat ovat tehneet skaalautuvuuden helpoksi.
Mutta mistä tietää, mitä kuuluisi mitata? Moni mittaa kaikkea mahdollista, mutta ei kuitenkaan osaa toimia saatujen tulosten mukaan. Google Analytics on hyvä työkalu, mutta valitettavasti se tarjoaa ensimmäiseksi lähinnä merkityksetöntä dataa.

Eri mittarit – engl. metrics tai joskus suomeksi metriikat – voidaan karkeasti jaotella kahteen ryhmään:

  1. Koreilumittarit (engl. vanity metrics), jotka ovat käytännössä hyödyttömiä, ja
  2. Ohjausmittarit (engl. actionable metrics), joiden avulla voi tehdä päätöksiä.

Koreilumittarit

Tyypillisiä koreilumittareita ovat käyttäjämäärät (etenkin palveluun ikinä koskaan tunnuksen luoneiden määrä), sivulatausten lukumäärä, API-kutsujen määrä, videoiden ja kuvien katsojamäärä jne.  Palvelun kannalta on itse asiassa se ja sama, onko palvelulla tuhat vai miljoona käyttäjää; ja on herttisen yhdentekevää, montako lukijaa blogipostauksesi tavoittaa.

Tämä kuulostaa yllättävältä, sillä olemme tottuneet siihen, että esimerkiksi verkkosivustoja laitetaan järjestykseen niiden käyttäjämäärien mukaan, tai että mainostulot saadaan lukijamäärien perusteella.  Miksi siis kohdella näitä numeroita näin julmasti?

Yhteinen tekijä koreilumittareille on se, että ne eivät kerro sinulle, kuinka parantaa palveluasi. Jos päivittäinen lukijakuntasi kasvaa, miksi se kasvaa? Jos se laskee, miksi se laskee?  Jos roskapostittaja keksii tavan lisätä miljoona tunnusta järjestelmääsi, onko todellinen käyttäjämääräsi kasvanut ja onko aika paukutella samppanjapulloja auki?

Koreilumittareiden seuraaminen vie fokuksen pois niistä asioista, joita sinun oikeasti tulisi mitata.

Paremmat mittarit

Mitä mittareita sitten tulisi katsoa?

Hyville mittareille yhteistä on se, että niiden tulee olla yhteismitallisia ajan funktiona, jotta voit verrata omaa suoritustasi. Ne sallivat helpon kokeilun, ne ovat helposti ymmärrettäviä, ja ne tarjoavat apua päätöksien tekemiseen.

Kasvusuhde

Käyttäjämäärän kasvua voidaan esimerkiksi mitata absoluuttisissa määrissä: “Tänään saimme tuhat uutta käyttäjää.” Hyvä, mutta kuinka se suhteutuu olemassaolevaan käyttäjämäärään? Jos vuosi sitten palvelulla oli tuhat käyttäjää, ja nyt miljoona, oliko tuhat käyttäjää tänään hyvä vai huono asia?  Entä vuosi sitten? Tyypillisesti tätä mallinnetaan kasvusuhteella (growth rate), joka on prosentuaalinen – tällöin voit verrata kasvuasi vuodentakaiseen (“Vuosi sitten kasvoimme 15 % kuukaudessa, nyt kasvamme vain 9 %. Missä on ongelma?”).

Konversiosuhde

Toinen tyypillinen mitattava asia on konversiosuhde (conversion rate). Tämä on tärkeä etenkin verkkokaupoille, sillä se vastaa kysymykseen: kuinka iso osa sivustolleni tulevista vierailijoista ostaa minulta jotain?  Viivan alle päätyvän rahan voi laskea yksinkertaisesti (tuotteen keskihinta x konversiosuhde x käyttäjien määrä). Jos lisäät käyttäjien määrää vaikkapa mainostamalla, mutta mainostat väärässä paikassa ja saat vääränlaisia vierailijoita, konversiosuhde laskee, liikevaihto pysyy samana ja mainostus meni hukkaan.  Sen sijaan voit esimerkiksi kokeilla erilaisia tapoja parantaa konversiosuhdetta – tee maksamisesta helpompaa tai nosta houkuttelevia tuotteita helpommin löydettäviksi.  Vaikka kauppaasi saapuu eri viikkoina eri määrä ihmisiä, konversiosuhdetta voi verrata viikosta toiseen, joten kokeilu on helppoa.

Pysyvyysmittarit

Erittäin tärkeän luokan muodostavat pysyvyysmittarit (retention metrics), joista voi löytää helposti esimerkkejä useilta aloilta: Kuinka moni kaupassasi kävijä tulee uudestaan? Montako kertaa? Mikä on kokonaisrahamäärä (Total Lifetime Value), jonka voit olettaa saavasi yhdeltä käyttäjältä?  Tästä tiedät, kuinka paljon sinulla on varaa käyttää markkinointiin saadaksesi yhden uuden käyttäjän – jos käyttämäsi rahamäärä (CAC – Cost to Acquire Customer) on suurempi kuin odotettavissa oleva kokonaisrahamäärä, firmasi menettää rahaa.

Mittareita on satoja, ja jokainen bisneksen alue mittaa toimintaansa omalla tavallaan.  Sopivien mittareiden valinta voi olla vaikeaa, mutta jokaisen valitun mittarin pitäisi opastaa firmaasi tekemään päätöksiä.

Älä sorru koreilumittareilla brassailuun.  Valitse omat ohjausmittarisi (mutta älä liian monta) ja tee palvelustasi parempi.

Linkkejä

Task Conversion Rate: http://www.kaushik.net/avinash/stop-obsessing-about-conversion-rate/
Vanity vs. actionable https://fizzle.co/sparkline/vanity-vs-actionable-metrics
Startup metrics for pirates http://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version
SaaS funnel metrics http://www.turbineroom.com/2013/metrics-hackers-saas-main-funnel/

Tämän artikkelin on kirjoittanut Janne Jalkanen  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Lean ajattelu ohjelmistoprojektin valmistelussa

Lean ajattelu ohjelmistoprojektin valmistelussa lähtee kahdesta peruskysymyksestä:

  • Miten voimme tuottaa ohjelmistolla asiakkaallemme – välillä myös asiakkaan asiakkaalle – eniten arvoa (ja sitä kautta myös omalle liiketoiminnallemme)?
  • Miten saisimme tehtyä ohjelmiston tehokkaimmin, vähimmällä mahdollisella ylimääräisellä työllä? Entä kun mietimme ohjelmiston käyttöä ja ylläpitoa: onko prosesseja joissa voisi oikaista tai jopa työtä jonka voisi jättää kokonaan tekemättä?

Tietenkin ohjelmistoprojektiin valmistautuminen, myös ketterä projekti, vaatii lisäksi paljon tarkempaa ja syvällisempää suunnittelua. Tässä kirjoituksessa käydään läpi tärkeimmät visiotasolla suunniteltavat asiat.  Voit ladata maksuttoman lean-visiolakanan, jota voit käyttää visiotyöpajassa ohjausryhmän kanssa, ehkä jopa pitää näkyvissä projektihuoneen seinällä projektin ajan. Lakana on ladattavissa täällä.

Lean-visiolakana kiteyttää oleellisimman ohjelmistosta

Suunnittelutyön ongelmana on usein, että yksityiskohtia yritetään kuvitella ja kiinnittää paljon pidemmälle kuin on oikeastaan pakko. Samalla lukitaan ratkaisuja turhan aikaisin, ja kehitystyön aikana syntyvää ymmärrystä voi jäädä hyödyntämättä. Ihannetapauksessa nimittäin voitaisiin projektin aikana käyttäjäpalautteen avulla huomata esimerkiksi, että jotakin ominaisuutta ei tarvitse rakentaa ollenkaan.

Hyvä visioajattelu pitää kysymykset niin yleisellä tasolla, että päätöksentekijätkin jaksavat osallistua keskusteluun, ja toisaalta vaikkapa uusi projektiin tuleva henkilö saa tärkeimmistä asioista kirkkaan yleiskäsityksen ennen kuin hän ryhtyy syventymään projektiin tarkemmin. Hyvässä visioajattelussa päästään tietojärjestelmän ohella kiinni liiketoiminnan perimmäisiin kysymyksiin: Mikä on se epäreilu kilpailuetu, joka saa asiakkaat tulemaan meille eikä menemään naapuriin? Ja mikä toisaalta on meille koko homman tarkoitus, se minkä takia jaksamme aamulla nousta ylös sängystä?

Visio koostuu seuraavista asioista:

Käyttäjien ongelma

Projektin riskitasoa laskee heti kättelyssä, jos ongelma validoidaan eikä se perustu arvaukseen. Esim. käyttäjähaastattelut ovat hyvä keino tähän. Jos sitten huomataan että käyttäjäongelma oli väärä arvaus, suunnittelua voidaan jatkaa toiseen suuntaan ilman kummoisiakaan uponneita henkisiä tai konkreettisia kustannuksia.

Onnistunut järjestelmä ratkaisee käyttäjille jonkin tärkeän ongelman. Kuluttajabisneksessä kyse voi olla vaikka opiskelijoista jotka kaipaavat lukupiiriseuraa ja parempaa kontaktia opiskelutovereihinsa, organisaation sisäisissä järjestelmissä kyse voi olla vaivattomammasta ja varmemmasta kuittien käsittelystä kirjanpitoa varten. Useimmiten ongelmia voi luetella monia, mutta kirkkaan konseptin kannalta on hyvä, jos tärkeimmäksi saadaan nostettua yksi.

Järjestelmän tarjoama ratkaisu

Seuraavaksi on mietittävä, miten järjestelmämme ratkaisee edellä tunnistetun käyttäjän ongelman. Lukupiiriesimerkissä vastaus voi olla Tinder-tyylinen kohtauttamistyökalu, jossa hakija kertoo opintoaiheen johon kaipaa opiskeluseuraa ja työkalu ehdottaa kanssaopiskelijoita sopivalta paikkakunnalta ja oppilaitoksesta. Kuittiesimerkki voi ratketa vaikkapa kännykän appillä jolla voi kuvata kuitit lennossa.

Myös ratkaisu on syytä validoida. Se onnistuu esim. yksinkertaisen prototyypin ja siihen yhdistetyn käyttäjätutkimuksen avulla. Jos käy ilmi, että oletettu ratkaisu ei itse asiassa autakaan käyttäjän ongelmaan, voidaan lähteä hakemaan toista ratkaisua eivätkä tappiot vieläkään ole suuria.

Ainutlaatuinen arvo

Useimmiten järjestelmillä on tavalla tai toisella kilpailijoita, jos ei muita niin se, että käyttäjä jättääkin asian kokonaan tekemättä. Ainutlaatuinen arvo on ohjelmistossa se ominaisuus, joka saa käyttäjän käyttämään juuri meidän järjestelmäämme ja ihastumaan siihen. Lukupiiri-Tinder-esimerkissä tämä voi olla mahtava sosiaalisuuden tuntu, kuittikamerassa taas se että kuva kuitista hoituu yhdellä painalluksella laskujärjestelmään asti.

Ainutlaatuista arvoa voi lisäksi syntyä siitä, että uuden järjestelmän myötä saadaan helpotettua järjestelmää tarjoavan yrityksen omia prosesseja. Viekö jokin asia tiskin takana nykyään paljon aikaa? Onko jotakin minkä voisi jättää tekemättä kokonaan?

Molemmantyyppiset ainutlaatuiset arvot on edelleen tärkeää validoida. Jo prototyypissä voi kokeilla haetun hurmausefektin tehokkuutta, ja uusien työtapojen säästövaikutuksia voi mitata vaikka kokeilemalla ilmaistyökaluilla ennen kuin uusi järjestelmä on edes kehitysvaiheessa.

Avainresurssit toteuttamisessa ja päätöksenteossa

Jokaisessa ohjelmistoprojektissa on resursseja, joiden jääminen löytymättä tai menettäminen on iso riski projektin onnistumiselle. Tällainen voi olla taitava tuoteomistaja, sponsori ylimmässä johdossa tai ohjelmiston tekninen velho, mutta yhtä hyvin korvaamaton lanseerauskanava, datalähde tai lähiprojekti.

Kehitystiimiltä kaivataan yleensä paitsi tiettyä todistettua teknologiaosaamista, myös hyviä yhteistyötaitoja toistensa ja asiakkaan edustajan kanssa. Ja mitä erikoisempi teknologia tai vaatimusyhdistelmä on kyseessä, sitä kriittisempää juuri tiettyjen resurssien saamisesta yleensä tulee. Resursoinnissa kannattaa myös miettiä läpi jatkokehitysvaihe.

Resursointia miettiessä yksi avainkysymys on, onko tärkeimmissä resursoitavissa jotain mikä voitaisiin itse asiassa saada valmiina verkostojen kautta tai ostettuna. Voisiko siitä silloin tulla jopa parempi, ja softantekijät ja tilaaja pääsisivät keskittymään siihen minkä tekevät parhaiten?

Kenelle järjestelmää tehdään

Kohderyhmiä miettiessä mopo usein karkaa käsistä, ja erilaisia käyttäjätyyppejä päädytään luetteloimaan esim. 12 kappaletta. Lean-ajattelun hengessä kuitenkin hyödyllisintä olisi pyrkiä erottamaan yksi tärkein käyttäjäpersoona. Minkä käyttäjäryhmän varassa liiketoiminnan tuleva kasvu on? Kuka viettää järjestelmässä eniten aikaa? Mikä käyttäjäryhmä voisi tuoda muut mukanaan? Olisiko käyttäjäryhmää edustavia ihmisiä saatavilla pilottikäyttäjiksi kehitystyötä varten?

Käyttäjäpalaute ja mitä sitten

Käyttäjäpalautteen keräämisellä ja analysoinnilla varmistetaan, että palvelu kehittyy jatkuvasti paremmaksi. Tämä on edelleen tärkeää, kun järjestelmää kehitetään eteenpäin vaikkapa kymmenettä vuotta.

Tilauskannan kehittyminen on hyvä käyttäjäpalautteen mittari, mutta myös laadullisempaa dataa tarvitaan. Apuun tulee esim. prototyypeistä kerättävä palaute, järjestelmän käyttöanalytiikka, käyttäjille tehtävät kyselyt, muutosten A/B-testaus tai klassinen käytettävyystestaus.

Tärkein asia käyttäjäpalautteessa kuitenkin on, että sitä käytetään päätöksenteon pohjana yhtä hyvin projektin päivittäisessä elämässä kuin isommissakin linjoissa esim. ohjausryhmän kanssa. Muuten kerääminen on jokseenkin hyödytöntä.

Rajoitukset projektille

Jokaisella ohjelmistoprojektilla on rajoituksia. Tyypillisimpiä ovat liiketoiminnan sykli tai aikataulu, johon on osuttava täyden hyödyn saamiseksi investoinnista. Esim. Lukupiiri-Tinderin tapauksessa lukukauden alku on tärkeä, koska opiskelijat järjestelevät elämäänsä ja ovat avoimia uusille vaikutteille.

Myös budjetti on usein rajallinen, ja suunnittelua tarvitaan. Maksavatko lisenssit, tarvitaanko laitteita ja tiloja kehitykseen, hankitaanko ohjelmistokehittäjät rekrytoinneilla vai ostamalla?

Harva järjestelmä tuottaa arvoa ilman, että käyttäjät tietävät siitä. Paljonko lanseeraukseen olisi syytä varata työtä tai rahaa?

Miten palvelun ylläpitovaihe eli hosting ja mahdollinen jatkokehitys aiotaan resursoida? Halutaanko järjestelmä taas uudistaa joidenkin vuosien päästä isosti, vai kehitetäänkö sitä mieluummin jatkuvasti pienellä panoksella?

Tekninen visio

Teknisessä visiossa ohjelmiston ostaja hyötyy eniten toimittajasta, ja suunnittelu onkin syytä tehdä yhdessä. Toisaalta seassa on kysymyksiä, joissa leanit ratkaisut eivät välttämättä kulje käsi kädessä toimittajan maksimikatteen kanssa. Omaakin visiota on siis hyvä hankkia vaikka sitten riippumatonta näkemystä ostamalla.

Millä teknologioilla ohjelmisto aiotaan toteuttaa? Onko vaihtoehtoja? Mikä tekniselle onnistumiselle on ensiarvoista, haetaanko vaikkapa monistettavuutta tulevaisuutta varten vai riittääkö kertatoteutus? Suositaanko avointa lähdekoodia?

Miten projektissa voitaisiin tehdä mahdollisimman vähän ohjelmistokehitystä? Onko olemassa valmiita tuotteita, joilla osa tarpeista voitaisiin kattaa vaikkapa muovaamalla vaatimuksia hiukan? Onko käytettävän teknologian sisällä valmismoduuleita joita voitaisiin käyttää, tai jopa olemassa olevia toteutuksia joihin voitaisiin pohjata? Jos käytetään avointa lähdekoodia, hyödynnetäänhän kehittäjäyhteisön valmiit ratkaisuaihiot?

Yksi järjestelmän lisäarvon ulottuvuuksista syntyy siitä, mitä sillä voidaan korvata. Sitä kautta voidaan esim. saada säästöä lisenssikustannuksissa.

Edelleen on mietittävä, mihin järjestelmä linkittyy – tästä syntyy teknisiä rajoitteita. Pitääkö sen viedä tai tuoda dataa, ja jos niin mihin kaikkiin järjestelmiin? Mitkä ovat turvallisuustarpeiden ja lain tai säännösten aiheuttamat rajoitukset?

Ja viimeisenä: mihin järjestelmän jatkokehitettävyys perustuu? Ollaanko valittu teknologia, jolla on pitkä elinkaari, vai lähdetäänkö suoraan siitä, että homma on menossa uusiksi muutaman vuoden päästä? Tämä vaikuttaa teknologiavision kunnianhimotasoon. Jos ketterä projekti etenee iteratiivisesti mutta aikajänne on pitkä, miten myöhemmin aiotaan kuroa umpeen teknistä velkaa, jota alun nopeissa voitoissa on mahdollisesti syntynyt? Löydetäänkö valituille teknologioille osaajia myös tulevaisuudessa?

Liiketoimintamittarit

Lean ajattelu ohjelmiston visiossa päätyy tuottonäkökulmaan. Kun visio on muodostettu ja validoitu, kehitys etenee suunnitellusti ja asiakkaalle alkaa syntyä uutta arvoa, kehitysinvestointi alkaa näkyä viivan alla. Vaikutuksen toteamiseen tarvitaan kuitenkin mittareita.

Visiossa on hyvä tunnistaa, onko järjestelmän tarkoitus tuoda liiketoimintaan kenties kokonaan uusi alue tai käänne, vai tähdätäänkö laadun parantamiseen esim. asiakaskokemuksessa tai lopputuloksissa? Vai haetaanko ennemminkin toiminnan tehostamista?

Molemmissa tapauksissa tarvitaan sekä välittömiä että epäsuoria mittareita. Lukupiiri-Tinderin tapauksessa välitön mittari voi olla esimerkiksi opiskelijoiden kokema tyytyväisyys ja tenteistä saadut arvosanat, ajan mittaan tulokset näkyvät toivottavasti nopeutuneina valmistumisaikoina ja vähentyneinä mielenterveysongelmina.

Lean-visiolakana käyttöösi

Oman ohjelmistovisiosi vastaukset edellä listattuihin ydinkysymyksiin voit kirjata joko täytettävään PDF:ään tai tilata samalla lomakkeella maksutta työpajaasi A1-kokoisen visiojulisteen.

Visiolakanan lisäksi projekti tietenkin tarvitsee paljon muita ohjausvälineitä, kuten tarkemman konsepti-idean ja mahdollisesti sitä testaavan proton, käyttäjätutkimuksen ja siltä pohjalta muodostetut käyttäjäpersoonat, kehitysjonon ja jonkin välineen sen käsittelyyn, konkreettiset menestysmittarit ja niiden tulosseurannan, resurssi- ja budjettisuunnittelun, taustajärjestelmäselvitykset sekä välineet käyttäjäpalautteen keräämiseen. Visiolakana kiteyttää projektin sielun ja kokoaa edellä mainitut yhteen.

Lataa lean-visiolakana maksutta

Voit ladata visiolakanan täällä.

PyCon Finland 2015

Yksi Pyconin mielenkiintoisimpia oppeja oli se, miten Pythonin avulla voi taistella haittaohjelmia vastaan.

PyCon Finland 2015 on Python-kielestä kiinnostuneille suunnattu konferenssi, jonka järjestää Python Suomi ry. Tässä blogauksessa esittelen mielenkiintoisimmat huomiot ja oivallukset niin puheista kuin tapahtuman toimivuudestakin.

Kuin rasvattu käärme

Pycon lähti osaltani käyntiin hieman kankeasti, kun bussini jumiutui ruuhkaan ja missasin vaihtoratikan. Puhujana minun olisi syytä olla ajoissa. Pamahdinkin paikalle kirjaimellisesti viime hetkellä.

Nimikylttiä ei näkynyt rekisteröinnissä! Sainkin sen suoraan järjestäjältä, minkä jälkeen konferenssi sujui kuin rasvattu salami, tai käärme. Taukoja oli sopivasti ja tekniikkakin toimi paremmin kuin yleensä tällaisissa tapahtumissa. Hektisen aamun jälkeen oli mukavaa viettää päivä kitkattomasti soljuvassa tapahtumassa.

Nähtävissä netissä

Mainitsemisen arvoista on etenkin se, että PyCon kuvattiin ensimmäistä kertaa ammattilaisten voimin, ja kaikki talkit tulevat myöhemmin nähtäväksi YouTubeen. Konferenssissa oli kaksi erillistä trackiä, joten kaikkia puheita ei ehtinyt näkemään livenä, vaikka olisi miten halunnut. Onneksi ne voi nyt tsekata jälkikäteen netistä. Kaikki näkemäni puheet olivat hyviä, mutta tässä kohokohdat.

Kafka – jonojärjestely täydellisellä logituksella

Keynotesta on tietysti pakko sanoa pari sanaa. Spotifyn Jyrki Pulliainen esitteli puheessaan Solid data structures in Python with logs Kafkaa, joka on LinkedInin kehittämä viestijonojärjestelmä täydellisellä logituksella, jota pystyy myös hajauttamaan. Homman juju on siinä, että viestijonon voi palauttaa aiempaan tilaan ja kelata eteenpäin haluamaansa pisteeseen. Ehkä mielenkiintoisin käyttökohde tälle olisi tietokantamuutos, jossa luodaan uusi tietokanta päivitetyllä schemalla ja ajetaan vanhan tietokannan transaktiot Kafkasta sisään. Se ei tosin sovellu hyvin töihin, joissa täytyy yrittää uudelleen epäonnistunutta tehtävää, koska jokainen tehtävä on uusi transaktio.

Hakukone, johon asianajajat rakastuvat

Priidu Kull on entinen asianajaja, nykyinen koodari. Hän kertoi puheessaan Building a Product for Legal Professional projektistaan, jossa hän pyrkii luomaan hakukoneen lakidokumenteille. Hakukoneen päämääränä on olla sellainen, että juristit käyttävät sitä mielellään. Hakukone rakentuu asianajajien workflow’n ympärille. Tästä talkista teki erityisen mielenkiintoisen se, että puheen lopuksi Kull keskusteli yleisönsä kanssa projektinsa sisällöstä ja kysyi heidän näkemystään sen ongelmakohdista. Keskustelua syntyi etenkin siitä, miten haut olisi parasta toteuttaa – tekstien hakeminen kun ei ole ihan helppoa. On hienoa nähdä koodaaja avoimena ja vielä hienompaa, kun hän on harvinaisesti sekä asianajaja että koodaaja. Tämän lisäksi opin, että virolainen oikeusjärjestelmä ei ole aivan samanlainen kuin suomalainen.

Python vs. haittaohjelma

F-Securen Matteo Cafasso kertoi ja näytti livenä talkissaan Hunting malware with Python kuinka haittaohjelmia ajetaan. Puheen aikana pääsi näkemään myös F-Securen vakavaa suhtautumista tietoturvaan. Cafasso kertoi, että läppäriä, jolla ajetaan malwarea millään tavalla, kutsutaan punaiseksi läppäriksi. Tämä tarkoittaa, että jos koneelle on mitenkään saatettu malwarea, edes virtuaalisesti sillä ajettavaan ympäristöön, ei konetta saa kytkeä mihinkään paitsi videotykkiin – eikä etenkään laittaa siihen muistitikkua. Hän näytti kolme erilaista haittaohjelmaa ja kertoi niiden toiminnasta.

Ohjelmistovirheitä voi ennustaa

Tommi Penttisen puheessa Bug forecasting by visualizing code evolution  käsiteltiin sitä, miten ohjelmistovirheitä voi ennustaa visuaalisin menetelmin. Hän viittasi paljon Adam Thornhillin kirjaan Your Code as a Crime Scene sekä käytti samaisen Code Maat -ohjelmistoa versiohallinnan kuvaamiseen. Sillä voi nähdä paitsi koodimoduulien omistajuutta, myös paljonko muutoksia koodi on vaatinut. Tästä voidaan päätellä riskikkäitä alueita ja mahdollisia puutteita testauksessa. Jos tällaiset haasteet havaitaan ajoissa, voi niihin myös puuttua ennen kuin nk. tekninen velka kasaantuu holtittoman suureksi ja korjaaminen tulee kalliimmaksi kuin heti hyvin tekeminen.

Lightning talkit

Lightning talkeja oli vain muutama. Niiden lisäksi PyConin sponsorit pitivät omat puheenvuoronsa. Suurin osa niistä oli odotesti rekry-puheita, paitsi Local Bitcoinsin, joka keskittyi Bitcoin-maailman tapahtumiin ja Bitcoinia muistuttaviin muihin blockchain –teknologioihin. Oli virkistävää, että kerrankin sponsori ei ollut vain rekrytoimassa, vaan esitteli uusia näkemyksiä.

Pluginit Pythonissa

Oma talkkini oli nimeltään Plug in with Python. Kerroin sen aikana, mitä pluginit ovat ja miten niitä voi koodata sovelluksiin. Itseäni kiehtoo ohjelmien eräänlainen väärinkäyttö, eli toiminnallisuuden muokkaaminen. Kävin läpi hieman erilaisten ohjelmistojen plugin-arkkitehtuureja ja omaa aiempaa koodia. Valmisteluksi olin tehnyt yksinkertaisen tekstinmuokkaajan PyQt5-käyttöliittymäkirjastolla. Lopuksi tein myös hieman livekoodausta, joissa näytin yleisölle, miten hommat hoituvat käytännössä.

Mitäs Dockerille kuuluu?

PyConin lopuksi oli perinteinen illallinen, jossa päästiin jatkamaan tauoilla lupaavasti alkanutta verkostoitumista. Yksi konferenssien parhaita puolia on se, kun pääsee näkemään tuttuja, joita ei niiden ulkopuolella juuri kohtaa. Lisäksi tietenkin pääsee tapaamaan aivan uusia ihmisiä. Jatkoilla juttelimme paljon Dockerista ja siitä, kärsiikö se samoista ongelmista kuin vuosi sitten. Vuosi sitten oli paljon keskustelua esimerkiksi virheviestien logituksen vaikeudesta ja parhaiden käytäntöjen puuttumisesta. Parhaat käytännöt ovat ilmeisesti kehittyneet hyvin viime vuoden aikana, ja logitukseen on jonkinlaista ratkaisua. Pienten terävien kulmien takia minusta ei tullut suoraan Docker-fania; se ratkoo kyllä ongelmia, mutta ongelmiin on muitakin päteviä ratkaisuja. Siitä huolimatta heräsi halu päästä perehtymään siihen tarkemmin. Päivä päättyi rennosti oluttuopilla One Pintissa.

 //Kuva: Tambako the Jaguar, Flickr