Etätöissä Japanissa

Kun syys–lokakuussa huomasimme parin kaverini kanssa, että lennot Japaniin olivat pienessä alennuksessa, päätimme tutkia olisiko mahdollista lähteä sinne porukalla. Olen melko uusi työntekijä Codentolla ja erityisesti tuolloin olin vielä upouusi työntekijä. Tiesin että mahdollisuus lähteä Japaniin olisi joko palkaton reissu tai etätyö.

Codentolla kerrottiin jo hakuprosessin alkuaskeleilla, että mahdollisuuksien mukaan etätyöt myös muualla kuin Suomessa onnistuvat. Päätinkin ottaa Japanin-reissun osalta selvää, kuinka sellainen onnistuisi omalla kohdallani. Codenton etähommissa ei tehdä lainkaan firman omia asioita edistäviä töitä, vaan konsultti keskittyy pelkästään asiakasprojektin edistämiseen. Näin tuetaan asiakkaan tavoitteita sekä edesautetaan asiakkaan mahdollisuutta antaa konsultille lupa lähteä pidemmällekin reissulle etätöihin. Lisäksi yrityksenä ja yksittäisinä konsultteina pyrimme siihen, että hommat tulee tehtyä parhaalla mahdollisella tavalla, olipa konsultti sitten tekemässä töitä missä suunnalla palloa tahansa.

Alkuvalmisteluja ennen matkaa

Keskustelin aluksi toimarimme Petrin kanssa, josko voisin tehdä etähommia matkan aikana. Sain Petriltä siunauksen sillä ehdolla, että myös asiakkaalta tulee vihreää valoa. Meillä Codentolla tehdään pääasiassa asiakasprojekteja, siksi hommia tehdään aina asiakkaan aikataulun mukaan. Seuraavaksi juttelin asiakasprojektin vetäjän kanssa mahdollisesta etätyöstä, kerroin myös että saatan tehdä vajaita päiviä etänä. Projektin vetäjä ei edes epäröinyt vaan lupa tuli saman tien kuin apteekin hyllyltä osaksi varmasti siitä syystä, että luottoa minuun löytyy, mutta myös siksi että luottoa Codentoon löytyy.

Etätyöt matkan suunnittelussa keskiössä

Aloimme suunnittelemaan matkaa hyvissä mielin sekä varasimme lennot. Matkasuunnitelmaa muodosteltiin ja hiottiin, korjailtiin ja muutettiin aikataulujen ja muiden asioiden mukaan. Suunnitteluun kuului oleellisena osana myös etätyöt. Hommat ulkomailla saa varmemmin tehtyä, jos se ei estä näkemästä asioita, joita haluan nähdä. Keskustelin myös muiden codentolaisten kanssa etätöistä ulkomailla, ja parhaaksi vaihtoehdoksi muodostui tehdä osa-aikaisia työpäiviä. Lähempänä lähtöpäivää muistuttelin asiakasta sekä projektityökavereitani lähdöstäni ja osa-aikaisesta työpanoksestani. Muistuttelin ihmisiä myös Codentolla, jotta kukaan ei ihmettelisi missä olen. Sovin meidän markkinointivastaavan Eevan kanssa, että kirjoittelisin blogin kokemuksestani, sekä etätyöstä. Lupasin myös hienoja matkakuvia. Juttelin asiakkaan kanssa vielä tarkemmin työtavoista ja olin valmis lähtemään matkoille.

Ja täällä ollaan!

Olen nyt Japanissa, ja teen noin 2–5 tuntia töitä per päivä. Joka päivä olen ollut yhteyksissä asiakasprojektin tiimiin tavalla tai toisella. Töitä on tullut tehtyä junassa, lentokoneessa, rannalla, hotellissa sekä kahvilassa – sopiva paikka on aina löytynyt tosi hyvin. On ollut mukavaa tehdä välillä omissa oloissa töitä. Vaikka yhteydet internettiin ovat välillä olleet mitä ovat, ja joskus projektin tekeminen on ollut hankalaa, niin haasteista huolimatta on projektissa päästy eteenpäin sovitussa aikataulussa.

Kaiken kaikkiaan kokemus on ollut mahtava ja siitä suurin kiitos Japanille. Mahdollisuudesta tehdä matka ja etätöitä iso kiitos niin asiakkaalle kuin Codentollekin!

Katso Codenton avoimet työpaikat

Arvoketjukartta hahmottelee toimintaympäristösi – ja visioi herkullisemman tulevaisuuden

Teimme budjetoinnin ja projektien arvioinnin tueksi lean-projektikartan. Olemme nyt käyneet usean asiakkaan kanssa keskusteluja siitä, miten lean-projektikartta auttaa heitä ja miten sitä voi hyödyntää tekemisen suunnittelussa. Vaikka lean-projektikartta on yksinkertainen täyttää, tarvittavat päätökset eivät aina ole itsestään selviä. Useamman kerran olemme päätyneet keskustelemaan siitä, millä perusteilla pitäisi painottaa toiminnan ylläpitoa tai milloin pitäisi tehdä mullistavaa kokeilua asiakkaan kanssa. Kysymyksiin vastaamiseen tarvitaan kaksi asiaa: 1) Missä tilanteessa ollaan nyt ja 2) Mihin tilanteeseen toivotaan päästävän.

Vastaukset eivät selviä täyttämällä lean-projektikarttaa. Tarvitaan näkemystä toimintaympäristöstä yli ajan – tarvitaan visio.
– Toimiva visio johdattaa organisaatiota kohti haluttua tilaa ja auttaa linjaamaan päivittäiset ratkaisut pitkän ajan tavoitteeseen
– Päivittäisessä työssä auttavan vision pitää olla ymmärrettävä, sitä kohti pitää voida edetä ja sen pitää olla motivoiva

Toimintaympäristön kokonaisvaltaisen ymmärtämisen kautta muodostettu tahtotila organisaation paikasta toimintaympäristössä on tukeva pohja visiolle. Kun vielä ymmärretään organisaation kyvykkyys vaikuttaa omaan positioonsa toimintaympäristössä, ollaan jo hyvän vision jäljillä.

Me Codentolla olemme käyttäneet muun muassa Simon Wardleyn arvoketjukarttaa, kun fasilitoimme toimintaympäristön kuvaamista. Tämä malli on tehokas väline kiinnittämään keskustelu yhteiseen viitekehykseen ja luomaan yli keskustelutilanteiden kantava ja asteittain yhä tarkentuva malli toimintaympäristöstä. Wardley map eli arvoketjukartta esittää asiakkaan keskiössä. Asiakas näkee käyttämänsä palvelun muodostavasta arvoketjusta lähinnä itseään olevat osat. Asiakasta ei yleensä suuremmin kiinnosta, millä alustalla palvelu pyörii tai miten palvelu on varmistanut internet-yhteytensä tai sähkönsaantinsa – palveluntarjoajalle tämä on kriittistä tietoa.

Jos liiketoimintasi on tuottaa asiakkaillesi välitöntä nautintoa vaikkapa ketterällä macaron-keksien toimituspalvelulla, sinun kannattaa miettiä hyvin tarkkaan miten palvelua tuotat nyt ja jatkossa. Siinä missä teknologian hype-sykli kuvaa yksittäisten teknologioiden kypsymistä yli ajan, Wardley map auttaa ymmärtämään sitä toimintaympäristöä, jossa organisaatio toimii nyt ja yli ajan. Siksipä arvoketjukartassa organisaation arvontuottoketjun kannalta olennaiset toimijat kuten esimerkiksi kilpailijat, toimittajat ja jakelijat kuvataan yhteen kuvaan. Samalla arvioidaan, millä tahdilla ne ovat kypsymässä uutuudesta massahyödykkeeksi. Lisäksi mietitään, mihin omaa organisaatiota kannattaisi toimintaympäristössä luotsata. Mikä olisi sen visio.

Saattaa olla että ketterä macaron-keksien toimituspalvelu menestyy juuri nyt hyvin – mutta jatkoa suunniteltaessa on vaarallista katsoa sitä mitä tapahtuu juuri nyt. Asiakkaasi sanovat, että haluavat makuja mielialansa mukaan. Lähdetkö toteuttamaan toivetta upouutta tilausdrone-konseptia kehittämällä vai pelaatko korttisi niin, että olet ensimmäisten joukossa käyttämässä Amazonin tarjoamaa “välittömästi mitä vain” -alustaa? Molemmat voivat olla voittava käsi, mutta onko organisaatiollasi varaa tehdä molemmat? Ja jos ei, millä kriteerillä valitset? Arvoketjukartta auttaa hahmottamaan tulevaisuuden menestysvisiot.

Jos haluat sparrausta, ota yhteyttä! miika.kuha@codento.com

 

 

DevOps tuo yrityksellesi strategista kilpailuetua

DevOps on siitä upea termi, että harvoin löytää sanaa, jolla on eri merkitys käytännössä kaikille. Yhdelle se tarkoittaa tiettyä valikoimaa työkaluista, joilla toimintaa tehdään. Toiselle taas sitä, että koodille ajetaan välittömästi muutosten jälkeen testit, joiden onnistuttua uusi versio softasta otetaan automaattisesti käyttöön yhdessä tai useammassa ympäristössä. Nämä näkemykset eivät ole vääriä, mutta mielestämme DevOps voi kuvata laajemminkin organisaatioiden toimintaa ja tuoda strategista kilpailuetua, jonka avulla yritys voi toimia vikkelämmin ja huomioida asiakkaidensa tarpeita nopeammalla syklillä.

CALMS – DevOps viidellä kirjaimella

The DevOps Handbookin kirjoittajanakin toiminut Jez Humble loi CALMS-käsitteen kirjan muiden kirjoittajien aiemmin luoman CALMS-akronyymin pohjalta. CALMS muodostuu sanoista Culture, Automation, Lean, Measurement ja Sharing. Mallissa ei mainita ensimmäistäkään palvelua, ohjelmistoa tai työkalua, vaan nämä ovat toteutuskysymyksiä. Vaikka esimerkiksi ohjelmistokehityksen ja tuotantoonviennin automatisointi tapahtuu usein muutamalla yleisesti käytetyllä työkalulla ja järjestelmällä (Ansible, Jenkins, Docker, Kubernetes jne.) on tärkeää, ettei toimintaa suunniteltaessa takerruta liiaksi tiettyyn ratkaisuun.

“Kuka haluaa antaa devaajille rootit?”

Kulttuuri, CALMSin C eli culture, tarkoittaa DevOpsissa jaetun vastuun kulttuuria, jonka myötä perinteiset raja-aidat ohjelmistokehityksen ja järjestelmien pyörityksen väliltä kaadetaan. Itselleni tämä osa DevOps-käsitettä tuntui aikanaan erityisen vastenmieliseltä. Sysadminina olin usein tilanteessa, jossa devaajat rikkoivat muutoksilla tuotantojärjestelmiä ja omana työnäni oli ongelmien korjauksen lisäksi vastaavien tapausten ennaltaehkäisy, käytännössä käyttöoikeuksien rajaaminen. Stabiiliutta korostettiin siis merkittävästi yli muutosten.

Vastuurajojen kaatuminen on kuitenkin muuttanut pelikenttää merkittävästi. Kun aiemmin kiisteltiin, pitäisikö kehittäjillä olla pääsy tuotantoon, puhutaan nyt siitä miksi ylläpitäjänkään pitäisi kirjautua sinne. Automatisointi on kääntänyt asian päälaelleen, jolloin tuotannon testauksesta ja pystyssä pysymisestä on tullut prosessiasia, ei yksittäisten ihmisten vastuualue.

“Mä teen tän aina uuden version tullessa.”

Automatisoinnista, joka on CALMSin A eli automation, puhutaan DevOpsissa usein turhaan vain tuotantoautomaationa (Continuous Integration & Deployment), vaikka se kuuluu olennaisena kaikkeen tekemiseen. Organisaatioista löytyy usein käsin tehtäviä rutiinihommia, jotka ovat jääneet jonkun vastuulle. Yleinen perustelu on, että hommassa ei mene kuin pari minuuttia, mutta päivittäin tehtävänä tähän alkaa kulua melkoisesti aikaa. Kiireessä voi myös sattua virheitä, joista seuraa huomattavasti lisää työtä.

Hyvä alku manuaalisen työn poistamiselle on kirjoittaa asia skriptiksi, jolloin samat asiat tapahtuvat riippumatta kuka sen ajaa. Paremmaksi tilanne menee, kun skriptin ajaminen kytketään suoraan siihen toimintoon, joka sitä edellyttää. Näin asia tapahtuu aina oikea-aikaisesti ja sovitun määrän kertoja.

“En mä osaa sanoa, milloin tää on valmis.”

Lean eli CALMSin L tuo tiimin tekemää työtä näkyväksi niin tiimille kuin sen ulkopuolellekin. Työn palastelu järkeviksi kokonaisuuksiksi ja siitä vielä yksittäisiksi kehitystehtäviksi tekee suuremmankin ominaisuuden kehityksen paremmin nähtäväksi – ja tilanne aukeaa nopealla vilkaisulla myös tiimin ulkopuolisille.

Leaniin voi liittyä myös asioiden tekeminen näkyväksi esimerkiksi palvelun omalla kojelaudalla, josta löytyy yhdellä vilkaisulla sekä metriikat että ongelmatilanteet. ChatOps-käsitteellä tarkoitetaan palvelussa tapahtuvien asioiden näyttämistä ja hallintaa erilaisten integraatioiden avulla. Mikäli firma toimii muutenkin Slackissä tai Flowdockissa on luonnollista, että myös järjestelmät raportoivat tekemisistään sinne.

“Valvomme, että palvelu vastaa.”

Monitorointi, CALMSin M eli measurement, on usein palvelun saavutettavuuden tarkkailua. Kun sivuston latauksessa kestää useampi sekunti tai se ei lataudu ollenkaan, lähetetään asiasta sähköposti tai tekstiviesti. Infrapuolella valvontaan kuuluu usein myös palvelinten saavutettavuus ja kuormitus, mutta useimmiten valvonta tapahtuu noin minuutin välein ja muutaman minuutin alhaallaolon jälkeen aiheutuu hälytys. Valvonta on tällöin pakostakin reaktiivista, ja ennakointi jää usein tekemättä.

DevOps tuo monitoroinnin seuraksi mittaamisen (instrumentation), joista voi yhdistettynä puhua havaittavuutena (observability). Havaittavuus korostaa nimenomaan järjestelmien toiminnan ymmärtämistä ja sen hallintaa erilaisilla mittaristoilla. Esim. API-rajapinnan virhemäärien tarkkailu on tärkeää, mutta virheen taustalta on hyvä nähdä myös syy, mistä virheet aiheutuvat. Palvelu voi olla täysin kunnossa, vaikka APIn pyynnöistä 50 % tyssäisi virheeseen, mikäli kyse on häirintäyrityksestä. Häirintä on syytä havaita, mutta siihen on osattava reagoida eri tavoin kuin palvelun rikkinäisyyteen.

“Eihän me voida kaikille kertoa, miten nää tehdään!”

CALMSin viimeinen kirjain S eli sharing sisältää tiedon jakamisen kehityksen ja ylläpidon välillä. Vaikka työtehtävät ja vastuut sekoittuvatkin, voi tietyn tiimin pääasiallinen työ edelleen liittyä ylläpitoon. Tässä kontekstissa on äärimmäisen tärkeää, että eri asioita tekevien tiimien välillä on avoin ja toimiva keskusteluyhteys, tapahtui tämä sitten toimistolla tai jotain viestintä käyttäen. Yllättävän moni asia lakkaa hajoamasta, kun kehittäjä pääsee näkemään oman koodinsa toimintaa tuotannossa.

Jakamisen käsitettä voidaan haluttaessa laajentaa myös oman firman ulkopuolelle. Esimerkiksi Suomen OpenStack -operaattorit juttelevat kuukausittain OpenStack Finland -ryhmän myötä erilaisista ongelmista ympäristöissään. Salaisuuksien varjelun ja verisen kilpailun sijaan ratkaisuja jakamalla voidaan saavuttaa etua kaikille.

CALMS on mainio lähtökohta yritykselle, joka hakee DevOpsista parannusta ja ketteryyttä toimintaansa. Vaikka DevOpsista puhuttaessa kannattaakin sivuuttaa teknologia hetkeksi, ei tätä toki voida käytännön sovellutuksissa unohtaa. Jakamisen opit pätevät myös teknologiavalintoihin eli työkaluista ja järjestelmistä kannattaa keskustella ja kysellä. Mikäli et oikein tiedä mistä aloittaisit, kannattaa kysyä asiasta vaikka meiltä!

 

Ketterän hankinnan trendit

Ketterä hankinta on teema, josta käydään innokkaasti keskustelua – mutta mitä se oikeastaan tarkoittaa? Suomessa ketterällä hankinnalla viitataan tällä hetkellä yleisimmin kolmeen asiaan: 1. Kokeilujen tai protojen hankinta, 2. Määritellyn pienimmän julkaistavan tuotteen (MVP) hankinta + iteratiivinen jatkokehitys ja 3. Resurssien ostaminen itse johdettavaksi. Suomessa vaihtoehdoista suosituin on tällä hetkellä numero 3 eli resurssien ostaminen itse johdettavaksi. 

Trendinä resurssien ostaminen

Kun resurssit ostetaan itse johdettavaksi, ei siis osteta ohjelmistoa tai lopputulosta, vaan hankitaan ohjelmistokehityksen ammattilaiset omaan ohjaukseen työskentelemään kohti parasta mahdollista lopputulosta. Tähän houkuttelee ohjelmistoalan ympärillä kuhiseva tekemisen into ja halu saada aikaan jotakin omaa.

Resurssiprojektit päättyvät vaihtelevin lopputuloksin. Onnellisimmissa tapauksissa tuloksena on intoa piukassa oleva kehitystiimi ja asiakkaat ennennäkemättömän tyytyväiseksi tekevä palvelu. Masentavammissa tapauksissa juututaan vuosiksi ankeaan junnaukseen: tekemistä tuntuu olevan aivan liikaa ja lopputuotteesta tuntuu tulevan vaikeasti hallittava jouluhimmeli.

Miten ketterässä hankinnassa onnistuu?

Millä sitten voi huolehtia siitä, että pääsee onnelliseen onnistujien joukkoon ja ehkä pokkaamaan palkintopokaalinkin softa-alan gaalassa? Varmistettavia asioita on viisi.

1. Läpinäkyvyys. Läpinäkyvyys on ketterän hankinnan tärkein riskienhallintakeino. Huolehdi, että se otetaan vakavasti kaikilla tasoilla. Sisällytä sopimukseen koodin tallentaminen säännöllisesti versionhallintaan. Etsi mittarit, joiden pohjalta projektissa syntyvää (asiakas)arvoa pystytään seuraamaan jatkuvasti. Ja kun olet löytänyt tiimiisi ohjelmistokehityksen kirkkaimmat tähdet, huolehdi läpinäkyvyydellä ja aktiivisella kommunikoinnilla, että heillä on käytössään tieto, jota projektin tavoitteiden saavuttamiseksi tarvitaan.

2. Visionhallinta. Ketterässä projektissa visionhallinta on muutokseen reagoimista, sillä ketteryyden etu tulee kyvystä hyödyntää projektin varrella löydetyt oivallukset. Huolehdi siis, että on olemassa hyvä tapa hankkia käyttäjäpalautetta ja reagoida siihen. Vie priorisoinnin ajatus äärimmilleen: millaisia ovat ne 20 %:n ratkaisut, jotka täyttävät 80 % tarpeesta? Kun niitä löytyy, jää maksimaalisen paljon aikaa palvelun jalostamiseen käyttäjäpalautteen perusteella ja ketteryydestä saadaan irti oikeaa hyötyä.

3. Vastuun ottaminen teknologiavisiosta. Teknologiapäätösten jättäminen kokonaan tiimille johtaa pahimmillaan ylläpito-ongelmiin. Kehittäjät ymmärrettävästi haluavat työskennellä kiinnostavimmilla uusimmilla teknologioilla – ongelmana vain on, että niille ei välttämättä vielä löydy erityisen paljon tukea tai ne voivat jäädä tähdenlennoiksi. Viisaalla ketterällä ostajalla on tukenaan teknologiaa valittaessa joko selvitys markkinatilanteesta tai toinen mielipide, jolla ei ole omaa lehmää projektin ojassa. Niiden avulla kehittäjien mielipiteet loksahtavat osaksi isompaa kuvaa.

4. MVP-budjetointi. Julkaisemalla startup-termein pienimmän julkaistavissa olevan tuotteen (minimum viable product) mahdollisimman aikaisin varmistat, että ketteryydelle eli toiveisiin vastaamiselle jää oikeasti projektissa aikaa. Jos 90 % budjetista käytetään projektin ensimmäisenä päivänä listattuun toiminnallisuuteen, olisit yhtä hyvin voinut ostaa tuotteen toimittajan riskillä ja säästää hermojasi ja resurssejasi. Jos taas pienin julkaistava tuote saadaan julkaistua jo 50 %:n kohdalla budjetista, loppuaika saadaan käytettyä jalostamiseen palautteen pohjalta, ja käyttäjistäsi tulee paljon tyytyväisempiä kuin he olisivat ikinä olleet perinteisellä tavalla tuotetun tuotteen kanssa.

5. Vastuu yhteistyön johtamisesta. Vaikka tiimisi ohjelmistokehittäjät olisivat kuinka lahjakkaita, huono vuorovaikutus pilaa työtehon projektissa kuin projektissa. Testaa siis yhteistyötaidot hankinnan aikana vaikkapa päivän mittaisella koodausleirillä. Varmista, että projektiasi päivittäin johtava tuoteomistaja on vähintään yhtä kokenut kuin kehittäjäsi. Huolehdi, että jatkuvan oppimisen ideaa noudatetaan projektin arjessa ihan käytännössä, vaikkapa retrospektiivien muodossa. Se on ketterä kilpailuetu, josta ei kannata vapaaehtoisesti luopua.

Oletko valmis ketterään hankintaan?

Loppuun ketteryyskonsultin antimainos: Ketterien resurssien ostaminen itse johdettavaksi pitäisi olla aina viimeinen vaihtoehto. Siihen pitäisi päätyä vasta, kun on huolellisen pohdinnan jälkeen todettu, että projektin tuotevisio on niin eksoottinen tai edistyksellinen, ettei sen vaatimuksia mitenkään pystytä muokkaamaan vastaamaan markkinoilla olevaa SaaS-ratkaisua tai valmistuotetta.

Resurssipohjaisen kehityksen ohjaaminen menestykseen vaatii ostavalta organisaatiolta paljon visiota ja energiaa. Molemmat ovat kallisarvoisia voimavaroja, joita ei kannata tuhlata toissijaisiin projekteihin.

Kun tämä varmistus on tehty, ohjelmiston visiolakana on hyvä mittari siitä, oletko valmis ketterään ostokseen. Jos lakanan tiedot on helppo täyttää, kotiläksyt on tehty.

Onnea projektiin (muista myös valmistella se gaalapuhe)!

Voimmeko auttaa?

Ota ketterän hankinnan kysymyksissä yhteyttä joko allekirjoittaneeseen karoliina.luoto@codento.com tai toimitusjohtajaamme petri.aukia@codento.com

Lisää SlideSharessa

Yksityiskohtaisemmin ketterän hankinnan teemoja käsittelee Slideshare-esitys Projektipäiviltä.

 

Asiakas – välttämätön paha?

Helsingin kaupunki on pyrkimässä digitaalisen koulutuksen eturintamaan. Kaupungin opetuslautakunta on suunnittelemassa digitaalisen verkkotyökalun, ePorfolion, käyttöönottoa. Ylen uutisen mukaan

käytännössä on kysymys oppilaan omasta kansiosta verkossa, jonne hän voi tallettaa tiedostoja opiskelun varrelta. Kansio toimii portfoliona, jonka avulla sekä oppilas että opettaja voivat arvioida miten oppilaan osaaminen on vuosien aikana kehittynyt.

Äkkiseltään tämä kuulostaa Google Driveltä tai Microsoftin Sharepointilta tai jo kauan sitten kuopaltulta Lotus Notesilta. Ne olivat ja ovat kaikki omaan tarkoitukseensa ihan kelpo järjestelmiä.

Hyvä tarkoitus

Ajatus on varmasti hyvä. Tietojen tallettaminen digitaalisesti on yleensä kätevämpää kuin analogisesti papereille ja kansioihin. Digitaalisesti talletettujen tietojen käyttäminen on helpompaa kuin mappien selaaminen. Portfolio ei kuitenkaan Ylen uutisen mukaan täytä käyttäjien odotuksia. Uutisen mukaan opettajat ja oppilaat pitävät järjestelmää huonona ja keskeneräisenä. Äidinkielen ja kirjallisuuden lehtori Maarit Nopsanen sanoo:

Me olimme aluksi ihan innostuneita siitä. Koulutus sen käyttöön oli kuitenkin riittämätöntä ja itse koko alusta oli täysin keskeneräinen. Suurin ongelma on kuitenkin siinä, etteivät opiskelijat halua käyttää alkeellisen näköistä työkalua, koska netti on pullollaan vastaavia paljon parempia ohjelmia.

Huono toteutus

Toteutus ei ole yhtä hyvä kuin ajatus. Toteutuksessa on ilmeisesti kaksi ongelmaa.

Ensinnäkin järjestelmä ollaan ottamassa käyttöön hallinnollisella päätöksellä, vaikka se on keskeneräinen. Keskeneräisen järjestelmän ottaminen käyttöön laajasti ja hallinnollisella päätöksellä ei ole koskaan hyvä ajatus. Keskeneräisen järjestelmän käyttöönotolla yleensä ajetaan tiehensä järjestelmän käytöstä eniten hyötyä saavat tahot, koska järjestelmä ei keskeneräisenä kykene vastaamaan käyttäjien tarpeisiin ja tuottamaan täyttä hyötyä. Menetettyä mainetta on myöhemmin vaikea paikata, vaikka järjestelmä myöhemmin kykenisikin tuottamaan palvelua täydellä teholla.

Toiseksi järjestelmä ei miellytä sen pääasiallisia käyttäjiä eli koulujen oppilaita. Oppilaat ovat tottuneet käyttämään viimeistelyjä järjestelmiä eikä keskeneräisen järjestelmän käyttö innosta. Tämä on yleinen ongelma nykyisin järjestelmäkehityksessä: mikään Facebookia, Twitteriä, Basecampia ja Google Drivea huonommin käytettävä järjestelmä ei menesty markkinoilla.

Asiakas kadoksissa

Miksi tässä kävi näin? Ajatus ja tarkoitus ovat olleet hyviä. Järjestelmän kehittämiseen on uutisen mukaan käytetty 150 000 euroa eli vajaat 200 työpäivää. Ongelmat eivät siis johdu liian halvalla tekemisestä.

Toteuttajat ovat varmasti tehneet parhaansa. Helsingin kaupungin edustajat ovat myös varmasti tehneet parhaansa ja noudattaneet kaupungin vakiintuneita käytäntöjä. Vakiintuneista käytännöistä puuttuu näet jotain projektin onnistumiselle olennaista: asiakkaan ymmärtäminen.

Tähän viittaa Helsingin kaupungin opetustoimen johtajan Liisa Pohjalaisen lausunto:

Pohjolaisen mukaan nyt kouluilta on kerätty palautetta, jonka pohjalta ePortfolio kehittelyä jatketaan yhdessä opettajien kanssa.

Järjestelmällä on näet muitakin asiakkaita kuin opettajat.

Keitä ovat asiakkaat?

Järjestelmän asiakkaita ovat he, jotka saavat järjestelmästä hyötyä. Kullakin järjestelmällä on yleensä useita asiakkaita. Jotta järjestelmä olisi menestyksekäs, on sen tuotettava hyötyä kaikille asiakkailleen. Järjestelmän kehittäjien on ymmärrettävä kaikki asiakkaat ja heidän tarpeensa, ominaisuutensa, odotuksensa ja kykynsä.

Keitä sitten ovat ePortfolion asiakkaat järjestelmän kehittäjän näkökulmasta? Asiakkaita on monia.

  1. Helsingin kaupungin opetusvirasto ja sen johto,  joka kustantaa kehitystyön ja joka edistää omia tavoitteitaan uuden järjestelmän käyttöönotolla
  2. Koulujen opettajat, jotka käyttävät ePortfoliota päivittäisessä opetustyössään ja joiden työtä ePortfolio helpottaa
  3. Oppilaiden vanhemmat, jotka seuraavat lastensa koulunkäyntiä
  4. Oppilaat, jotka käyttävät ePortfoliota oppimisen tukena ja jotka oppivat paremmin ja nopeammin ePortfoliota käyttäen

Jotta ePortfolio voisi olla menestys, on sen täytettävä ainakin näiden neljän ryhmän tarpeet ja tuotettava arvoa heille kaikille. Ylen uutisesta voi päätellä, että ePortfolion kehityksessä on keskitytty liian vähän arvon tuottamiseen opettajilla ja oppilaille. Koska oppilaat ja opettajat eivät koe saavansa arvoa järjestelmästä, he eivät halua käyttää järjestelmää. Jos järjestelmä tuottaisi opiskelijoille arvoa, he eivät valittaisi järjestelmän huonosta käyttöliittymästä. Huonokin käyttöliittymä on siedettävissä, jos järjestelmästä on ilmiselvää hyötyä.

Miten ymmärtää asiakkaan tarve?

Tietojärjestelmien kehittämisessä on valitettavan helppoa sekoittaa maksajan ja asiakkaan roolit. Usein tämä johtuu projektimallista, jossa kehitysprojektia johtaa ohjausryhmä, jonka puheenjohtajana on joku hyvin korkeassa asemassa oleva johtaja ja jäseninä muita johtajia. Johtajilla ei välttämättä ole kovin hyvää ymmärrystä kaikkien asiakkaiden tarpeista. Johtajilla saattaa myös olla omaan asemaansa liittyviä tavoitteita ja kunnianhimoja, jotka menevät joidenkin asiakkaiden etujen edelle. Joskus johtajien kunnia saattaa myös estää virheiden myöntämisen.

Onneksi on kuitenkin olemassa yksinkertainen keino asiakkaan tarpeiden ja kaipaamaan arvon selvittämiseen: asiakkaan kanssa ajan viettäminen, asiakkaan toiminnan tarkka havainnointi ja asiakkaan elämän eläminen.

Hyvä keino oppia ymmärtämään asiakkaita ja heidän tarpeitaan on perehtyä muiden kuin tietojärjestelmäteollisuuden käyttämiin menetelmiin. Toyota on kuuluisa tavastaan lähettää uuden automallin pääsuunnittelija elämään kuukaudeksi pariksi automallin kohderyhmään kuuluvien kanssa. Yhdessä elämällä pääsuunnittelija ymmärtää myös tarpeet, joita asiakas ei osaa sanoa ääneen.

ePortfolion tilanteessa parasta olisi etsiä ryhmä, jolle jo tuotetut ominaisuudet ovat tärkeämmät kuin ne puutteet, joita järjestelmässä on. Koekäyttö on luonteva tapa silloin, kun järjestelmä on joillekin käyttäjille keskeneräisenäkin käytön arvoinen. Näin on tapana toimia yksityisellä puolella. Facebook oli aluksi tarkoitettu vain Harvardin yliopiston fukseille ja hiljalleen se tuotiin muidenkin käyttäjien käyttöön.

Oppia nosturiteollisuudesta

Toinen hyvä keino on tutustua muiden teollisuuden alojen tuotteisiin ja miettiä, miten niiden kehityksessä on otettu asiakas huomioon ja miten asiakkaan tarpeet näkyvät innovatiivisuutena ja arvontuottona tuotteissa. Yksi parhaista viime aikoina näkemistäni esimerkeistä on saksalaisen nosturivalmistajan Liebherrin mobiilinosturikonsepti.

Mobiilinosturista on netissä nähtävissä selkeä video  ja esite. Erityisesti videon katsominen kannattaa. Videosta käyvät selville olennaiset mobiilinosturille asetetut vaatimukset:

  • Pieni kääntösäde, jotta nosturilla pääsee mille tahansa rakennustyömaalle aivan kuten millä tahansa rakennustyömaalla vierailevalla ajoneuvolla.
  • Matala korkeus, jotta nosturilla voi ajaa kaupungissa ilman tarvetta erikoiskuljetukselle
  • Nopea pystytys alle 20 minuutissa, jotta nosturi voi siirtyä työmaalla paikasta toiseen
  • Nosturin operointi vaatii vain yhden henkilön eli saman, joka kuljettaa nosturia, mikä vähentää henkilöstökuluja
  • Riittävä nostokapasiteetti ja pitkä ulottuvuus
.

Näiden vaatimusten keksiminen on ollut mahdollista vain seuraamalla eri asiakasryhmien toimintaa ja ymmärtämällä miten nosturi voi tuottaa heille arvoa.

  • Uuden talon asukas saa arvoa, kun talo valmistuu nopeasti ja halvalla. Liebherrin mobiilinosturi auttaa tässä.
  • Uuden talon rakentaja säästää rahaa, kun hän voi tilata nosturin tarpeen mukaan ja vain lyhyeksi aikaa. Rakentajan ei tarvitse suunnitella rakennustyömaata ja rakennusjärjestystä nostureiden ehdoilla.
  • Nosturin omistaja – eli Liebherrin maksava asiakas – saa sitä enemmän arvoa, mitä useammassa paikassa hän päivän aikana ehtii käydä nostamassa ja mitä moninaisempiin paikkoihin hän nosturillaan pääsee.

Vastaavasti ePortfolion kehittäjien on syytä jatkossa viettää merkittävästi aikaa kouluissa opettajien ja oppilaiden kanssa. Pelkät työpajat ja kyselyt ja palautteen kerääminen eivät riitä. On pystyttävä elämään yhdessä arvoa saavien asiakkaiden kanssa. Vain siten voi ymmärtää mitä uuden järjestelmän pitäisi tehdä ja miten se pitäisi tehdä. Luonnollisesti tämä maksaa, mutta turhan järjestelmän tekeminen ja hallinnollinen käyttöönotto vasta kallista onkin.

Codento on mukana kehittämässä Helsingin kaupungille uutta kehittämisohjeistoa. Uusi malli ottaa huomioon asiakkaan ja hänen tarpeensa, jotta jatkossa tällaisilta ongelmilta vältyttäisiin.

Kuva: Flickr Creative Commons, Stefan Eldeby.

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