Vauhtia fronttiin Vuella

Aloitin tammikuussa Codentolla uutena työntekijänä, ja ensimmäisten viikkojen aikana pääsin mukaan mielenkiintoiseen sisäiseen projektiin, jossa tarkoituksena oli tuottaa nopeasti prototyyppi avoimia rajapintoja hyödyntävästä business casesta. Vaikka tällä alalla uuden oppiminen ja uusiin teknologioihin tutustuminen on jatkuvaa, ensivilkaisulla projektin palvelinpuoli näytti silti mukavan tutulta: käytetyt backend-teknologiat olivat Node.js ja Express. Suorastaan ydinmukavuusaluetta!

Käyttöliittymässä tulikin sitten vastaan Javascript-framework, josta en ennalta tiennyt mitään muuta kuin nimen: Vue.js. Se lupaa olevansa progressiivinen, asteittain käyttöönotettava framework reaktiivisten käyttöliittymien rakentamiseen. Tämä tarkoittaa, että Vue integroituu helposti olemassaolevaan web-sovellukseen pala kerrallaan. Esimerkiksi Gitlab on kirjoittanut paljon omista hyvistä kokemuksistaan Vuen käyttöönotossa.

On tosin huomattava, että tämä siirtymä tapahtui melko vanhanaikaisesta, puhtaasti JQueryllä toteutetusta sovelluksesta nykyaikaiseen frameworkiin, ja tässä kohtaa mikä tahansa ratkaisu olisi tarjonnut merkittäviä parannuksia. Heidän tapauksessaan valinta osui silti Vueen – paljolti niistä syistä, jotka ovat olleet sen suosion takana laajemminkin: yksinkertaisuus ja helppokäyttöisyys. Viimeisimmän State of Javascript -raportin mukaan Vuen suosio vaikuttaisikin olevan selkeässä kasvussa.

Usein kehittäjien keskusteluissa Vue vertautuu ennen kaikkea Facebookin tukemaan Reactiin. Vue ja React ovat osapuilleen saman ikäisiä, ja niissä molemmissa tieto liikkuu sovelluksen sisällä esimerkiksi AngularJS:ää kurinalaisemmin. Reactin tapaan Vue käyttää virtuaalista dokumenttipuuta, joka mahdollistaa paljon sujuvamman käyttökokemuksen laajoissa webbisovelluksissa. Vue onkin ominaisuuksiltaan riittävän samankaltainen suhteessa Reactiin, että teknologiavertailu menisi tämän tekstin laajuudessa liian pikkutarkaksi, joten vertaillaan mielummin sitä miltä työkalu tuntuu käteen ja millainen tuntuma sen käytöstä on jäänyt – eli toisin sanoen keskittykäämme kiistelemään makuasioista.

Templatointi tuntuu olevan mielipiteitä jakava kysymys. Vuen tapa käyttää templatointia on hyvin selkeä ja johdonmukainen: .vue-komponentti rakentuu templatesta, ohjelmakoodista ja valinnaisista muotoilumäärittelyistä, jotka ovat kaikki samassa tiedostossa, ja jotka hyvin rakennettuina pystyy hahmottamaan yhdellä vilkaisulla. Vuen templatointikieli tuskin on kenellekään kehittäjälle vaikeaa opetella, koska Vue kehittää eteenpäin monia aiempien ratkaisujen hyviä puolia.

Vue on tällä hetkellä Reactiin verrattuna pitkälti yhden ihmisen projekti. Tästä huolimatta kirjastotuki alkaa olla tuotantokäyttöön riittävä, ja projekti tarjoaa omasta puolestaan useita oleellisimpia peruskirjastoja, kuten esimerkiksi monista muista kirjastoista ja frameworkeista tutut router- ja store-kirjastot. Vuessa vetoaa ennen kaikkea se, miten nopeasti prototyyppejä saa luotua, ja miten helppoa prototyypistä on kasvattaa toimivia webappeja. Sisäisessä projektissamme sekä uuden teknologian haltuunotto että prototyypin tekeminen sujui tuskin paljon viikkoa pidemmässä ajassa, ja kokemukset maailmalta kertovat, että prototyypin jalostaminen tuotantokypsäksi tuotteeksi onnistuu Vuella myös varsin ketterästi.

Tiivistetysti sanottuna Vue tuntuu ennen kaikkea kustannustehokkaalta vaihtoehdolta. Näkymistä ja komponenteista on helppo rakentaa selkeitä ja yksinkertaisia hahmottaa. Projektiin ei välttämättä tarvitse etsiä spesifisti Vue-kehittäjiä, kun oppimiskynnys on kenelle tahansa matala. React jatkaa varmasti ansaitusti menestyksekästä taivaltaan käyttöliittymäteknologiana Vuen suosion kasvusta huolimatta, eli “Reactin tappajaa” Vuesta ei tule löytymään. On silti aina eduksi, että hyviä ja keskenään erilaisia vaihtoehtoja on useita. Siili järjestää 21.3. tietääkseni Suomen ensimmäisen Vue.js -tapaamisen – kuhinaa Vuen ympärillä on siis jo meillä Suomessakin.

 

PS Jos olet kiinnostunut Vuesta, on meillä tilaa osaajille! Täältä pääset hakemaan.

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

 

 

Mitä Hackathonista voi oppia? Case StreetReboot  

StreetReboot: mikä, miksi, mitä ja miten?

Osallistuimme IndustryHackin järjestämään StreetReboot Hackathoniin. Hackathon on muutaman viikon ja loppurutistuspäivien kuumeinen ohjelmointisessio, jonka järjestäjä tai sen rahoittaja on laittanut aluille, ja jonka toiveena ratkaista jokin iso ongelma tuomalla pöytään monenlaisia näkökulmia.

Tyypillisesti järjestämisvaiheessa tuohon ongelmaan ei vielä ole pienintäkään ratkaisuideaa, kun perimmäinen syykin on erittäin suuri kysymysmerkki. Hackathonissa on siis tarkoitus saada iso joukko kehittäjiä eri ryhmissä toimien ja ratkaisten eri näkökulmia annettuun haasteeseen liittyen. IndustryHack on Hackathon tapahtumien järjestämiseen erikoistunut Startup. Heidän tehtävänsä on toimia kokeneena fasilitaattorina hackathonin aikana.

StreetReboot järjestettiin digitalisoimaan Staran toimintaa. Stara lienee monelle tuttu Helsingin kaupungin katujen ja viheralueiden ylläpidosta vastaava yritys. Heidän vastuullaan on lähes 70% Helsingin katu- ja viheralueista.

Miten homma eteni?

Codenton Team Cityketut – eli devaajat Turo Mikkonen, Miili Halkka ja Jukka Purma – osallistui Staran haasteiden ratkomiseen. Alla Turon yhteenveto projektin etenemisestä ja  tiimin kokemuksista.  

Hakemus ja hyväksyntä

Staran haaste innosti heti ja kaihot äänet kehittäjien keskuudessa antoivat ymmärtää kiinnostuksensa. Ideoita heräsi tiimin kesken ja puhetta riitti muun muassa muurahaisalgoritmeista, machine learning -tekniikasta sekä datan visualisoinnista. Tiimin kesken tehtiin omat profiilit, sekä tietysti itse hakemus järjestäjälle eli IndustryHackille.

Pian saimme tietää, että pääsimme valittuun timanttiseen kahdeksan tiimin joukkoon. Itselläni oli loistava fiilis ja erittäin positiivinen asenne eteenpäin mentäessä.

StreetReboot Kickoff 22.9.2017

Ensimmäinen virallinen työpäivä StreetReboot -hankkeessa. Suuntasimme Staran varikolle, jossa meille tarjottiin kahvia, leipää ja aimo annos tietoa käytettävistä API-pisteistä, lisätietoa Staran pääasiallisesta työstä, sekä hiukan lisää tietoa koko tapahtumasta ja sen järjestäjistä.

Jokaiselle tiimille osoitettiin Staralta mentori, jolla siis on kokemusta itse työstä ja sen tarpeista. Meidän tiimimme mentoriksi tuli Staran hoitopäällikkö Juha-Pekka Tissari.

Juha-Pekka kertoi meille monista hankalista työtehtävistä, mitä voisi korjata tai muuttaa heidän tarpeisiinsa sopivimmiksi. Lisäksi kaikille tiimeille demonstroitiin Staran hoitokalustoa. Kävimme katsomassa tarkemmin koneiden sisältöä, työkaluja, sekä työtehtävien raportointiapplikaatiota. Aikataulut venyivät iltaan, mutta paljon informaatiota sulattaneena ideoimme vielä vähän samana päivänä työtapoja sekä lopullista demoa.

StreetReboot Hackathon 6.-7.10.2017

Ennen itse Hackathon tapahtumaa olimme sopineet työmme aiheen, data-pisteet, työkalut sekä vastuualueet. Testiympäristönä käytimme Lego Technic -sarjan aura-autoa, jonka auraa tarkkailemme Arduinolla. Datan käsittely, tutkimus ja esittely taas hoidettiin Pythonilla ja JavaScriptillä.

Hackathon järjestettiin Elisa HQ:ssa, eli Pasilan pääkonttorilla. Saavuimme paikalle, ja meille ojennettiin vihreät StreetReboot -hupparit sekä nimikyltit. Päivä alkoi käytännön asioilla, jonka jälkeen ryhdyttiin hommiin.

Aluksi sovimme tarkemmin mitä kukakin tekee, sillä osa datasta kerrottiin vasta äskettäin. Teimme Kanban-boardin ja tiketit, sekä ryhdyimme hommiin. Tapahtuma oli erittäin hyvin järjestetty, saimme ruokaa ja välipaloja työn äärellä ja tiimin omat työhuoneet auttoivat keskittymisessä erittäin paljon.

Ensimmäinen päivä menikin vauhdikkaasti ja saimme paljon aikaan. Oli kunnon tekemisen meininki! Toisena päivänä tavoitteena oli saada demoesitys kuntoon. Rajoitetun ajan takia kuitenkin emme päässeet haluttuun lopputulokseen, mutta meillä oli back-up -suunnitelmana auran statuksen muuttavaa dataa. Saimme kuitenkin itse Demo Fair -osuuden aikana asiat toimimaan halutulla tavalla. Vaikka haluttuun lopputulokseen ei ihan päästy, en usko sen vaikuttaneen tuomarien päätöksiin.

Emme yltäneet voittoon, mutta kokemus oli mainio! Pidin erityisesti tiimini yhteistyöstä, toimimme erittäin hyvin yhteen ja vastuut jakautuivat oman osaamisen mukaisesti. Emme ole Miilin ja Jukan kanssa samoissa projekteissa olleet, mutta tämä kokemus antoi minulle erittäin positiivisen kuvan heidän kanssaan työskentelystä.

Jos jotain olisin tehnyt vielä paremmin, niin omaan tiimiin olisin ottanut vielä yhden henkilön lisää, jolloin joko minä tai tuo kuvitteellinen neljäs tiimiläinen olisi keskittynyt enemmän idean esitelmöintiin, dokumentointiin sekä myymiseen. Näillä eväillä olisi hackathon voitettu vuoren varmasti!

Turon vinkit Hackathon-tapahtumiin osallistuville

Olen jo muutamaan ‘hackathonmaiseen’ tapahtumaan osallistunut, ja näistä kokemuksista oppineena haluan suositella Hackathoniin osallistujille muutamaa hyväksi todettua tapaa.

  1. Ensiksikin teknologioista ja tekniikoista. Suosittelen, että käytätte teille tuttuja tekniikoita suurimmassa osassa työtänne, tämä mahdollistaa nopean ja toimivan tuotoksen, joka valmistuu ainakin suurimmaksi osaksi jo tapahtuman aikana. Tiimille tuntemattomia teknologioita kannattaa ottaa vain muutama, joita sitten tutkitaan ja testataan jo ennen tapahtumaa.
  2. Toiseksi markkinointi ja dokumentointi. Tärkein osuus, niin hyvässä asiakas projektissa, kuin voittavassa Hackathon tiimissä on dokumentointi ja asiakkaalle idean kommunikointi. Hackathon tapahtumissa usein vain aika määrittelee sen miten paljon voidaan pistää tykkejä kunnon markkinointiin ja viestin edustamiseen, siksi olisi erittäin tärkeää yhden tiimin jäsenen keskittyä viestin suunnitteluun ja toteutukseen.
  3. Kolmas, mutta ehdottomasti tärkein pointti, on pitää hauskaa ja oppia jokaisesta pienestäkin virheestä tai odottamattomasta käänteestä projektin osalta. Hyvin usein tämän kaltaisiin tapahtumiin tulee ns. “Suorittaja-tiimi”, jonka pääasiallinen tavoite on saada voitto ja murehtia muista asioista, sitten tapahtuman jälkeen. Harvoin nämä tiimit voittavat, sillä ajatukset hyvin usein pyörivät vanhojen “hyväksi”-todettujen ratkaisujen ympärillä, eikä asiakas välttämättä ole etsimässä niitä vanhoja ratkaisuja vaan pussillisen uusia.

Projektimme tuotos ja käytetyt teknologiat

Teknologia ja tekniikat, osuuden sanoisin meidän tiimissämme onnistuneen erittäin hyvin. Meille Python ja JavaScript ovat erittäin tuttuja kieliä, sekä niiden avulla datan käsittely ja esittely olivat helppoja nakkeja, mutta tietysti suurin osa työstä tehtiin näiden teknologioiden päälle, joten niiden pyörittelyyn varattiin aikaa.

Meille tuntemattomampi osuus oli Arduino- ja C++ -ohjelmointi, mutta niistä taas minulla oli jo jonkin verran kokemusta, joten hoidin sen puolen työstämme. Markkinointi ja dokumentointi osuus, oli meidän tiimimme heikkous. Ei niinkään ettemme olisi niitä tehneet, mutta tiimin koko ja aikataulut, eivät antaneet periksi sen vertaa, että kunnon esitelmää olisi saatu luonnehdittua tuomariston esitystä varten. Tämä harmittaa itseäni erityisesti, sillä aikaisemmissa samankaltaisissa tapahtumissa olen korostanut esitelmöinnin tärkeyttä, mutta Hackathon tapahtumien luonne ei anna tarpeeksi aikaa, jotta jokainen aspekti työstä olisi varmasti valmis tulosten esitelmöinti vaiheessa.

Jatkossa otan itse opiksi, sekä varaan aikaa omasta työstäni esityksen hiomiseen. Kolmas aspekti ainakin omasta mielestäni onnistui tiimiltä erinomaisesti! Olimme sopivasti uusien aspektien kanssa tekemisissä. Omasta mielestäni koko tapahtuman ajan oli kunnon tekemisen meininki. Pidin myös erityisesti Miilin ja Jukan kanssa työskentelystä, osaamisemme sivusivat sopivasti toistemme osaamisia, joten keskustelu projektista, etenemiseen tarvittavista asioista ja työn kulusta oli helppoa ja mukavaa. Päällekkäinen, toisiaan täydentävä osaaminen oli vahvuutemme!

Vielä pari sanaa tuotoksestamme. Codenton – ja CityKettujen – it-arkkitehti Jukka Purma luonnehti projektiamme seuraavanlaisesti:

“Kalliita työkoneita käyttävissä yrityksissä sensoreiden mahdollistamaa digitalisaatiota (mennee IoT:n alle) ei kannata tehdä projekteissa tai isoissa harppauksissa: täytyy kehittää toimintamenetelmät, joilla varikot, IT, hallinto, työntekijät ja ‘älykkäät järjestelmät’ kaikki *sietävät* sen, että sensorit muuttuvat, katoavat, vaihdetaan toisenlaiseksi, lisätään ad hoc -tarpeeseen ym. Nopean muutoksen kausi tällä saralla tulee jatkumaan vielä seuraavat kymmenen vuotta, mutta työkoneita ei kannata uusia sen ehdoilla: pitää olla tottumus ja käytännöt kuinka ‘lisätä älyä’ vanhoihin koneisiin.

Menetelmien suunnittelu, koodaaminen tai kiveen hakkaaminen olisi kuin DevOps, mutta työalue on isompi: pitää voida sanoa johdolle että vain käyttämällä näitä menetelmiä, voitte hyötyä näistä uusista tietokanavista, IT-porukalle että on päästettävä tällaista tietoa sisään ja ulos, ja juteltava työntekijöiden kanssa missä on pullonkauloja joissa IoT voisi auttaa. Käytännössä tämä olisi vaativa työrooli monipuoliselle osaajalle, mutta niin kauan kuin sellaista tehtävää ei ole eikä täyttä ymmärrystä miten sen roolin täyttäjään pitäisi suhtautua, se on parempi toteuttaa konsulttien avulla: monta henkilöä yhdistää osaamisensa ja keskittyy joksikin aikaa ratkomaan tuota ongelmaketjua, tavoitteena luoda alustavat (turvalliset) käytännöt joita sitten joku asiakasyrityksestä nousee jatkamaan.”

 

IndustryHackin järjestämään Street Reboot -tapahtumaan osallistuneet CityKetut ovat:

Turo Mikkonen: “Tiimini kanssa tekeminen oli erityisen palkitsevaa näiden ihmisten kanssa ja pidin tästä kunnon tekemisen meiningistä”

Jukka Purma: “Tekeminen oli hauskaa ja jännää, enemmän alamäkijuoksua kuin maratonia: koska tahansa saattoi askelvalinta osoittautua vääräksi ja homma mennä turvalleen, mutta selvittiin ehjänä maaliin suunnilleen sitä reittiä mitä lähdettiin yrittämään.“

Miili Halkka: “Kokonaisuutena hackahton oli hieno kokemus, oman tiimin mutkaton toiminta, muiden tiimien tuotoksien näkeminen ja verkostoituminen monenlaisten osaajien kanssa antoi elämyksen, jonka kaltaista normaalissa työprojektissa on mahdoton saavuttaa muutamassa päivässä. Nopea palaute tehdystä työstä palkitsee aina.”

Codenton CityKettujen tuotokseen voi tutustua Githubissa: https://github.com/codento/snowplow_sense

Lisätietoja hankkeesta myös täällä:
https://6aika.fi/in-english/
http://rebootthecity.fi/

Hankintalaki on tekosyy – 7 neuvoa päättäjälle

Kun ostaa sian säkissä, se ei ole hankintalain vika – vaikka julkishallinnon puolella sen taakse helposti piiloudutaan. Turhan harva tietää, ettei hankintalaki estä tekemästä hyvää ostosta. Julkishallinnossa hankitaan jatkuvasti laajoja järjestelmiä kohtuukustannuksilla ja loistavalla laadulla.

Se mikä ei julkisella puolella onnistu, on jättihankkeen nopea läpivienti. Jonkun on pitänyt käynnistää hankinta jopa vuosia ennen kuin uutta järjestelmää tarvitaan, jottei projekti menisi mönkään.

Hankintalaki, huolellinen tarveanalyysi, kilpailutus ja hankkeen läpivienti vaativat julkisella sektorilla jokainen enemmän aikaa ja taitoa kuin vastaavan hankkeen läpivienti yksityisellä puolella.

Alla 7 neuvoani päättäjälle


1. Eriytä valmisteluvaihe.
Kaikkein vaikeinta tuntuu olevan se, että hankinnan ja määrittelyn pitää olla täysin erillään toisistaan. Ei riitä, että valitsee parhaan tuotteen tai palvelun tarjotuista, vaan valinnan kriteerit on pitänyt asettaa jo ennen hankinnan läpivientiä. Tilanne on joskus yhtä koominen, kuin aviopuolison lähettäminen hänelle vieraaseen kauppaan. Tarkimmatkaan ohjeet eivät riitä ja oivariinin ja ruokakerman sijaan kassista löytyy helposti pari senttiä halvempaa tarjousvoita ja kahvikermaa.

2. Kehitä osto-osaamista. Käytännössä hankintoja pitää tehdä jatkuvasti ja tarkasti, jotta hankintataidot kehittyvät ja säilyvät. Isojen hankintojen ammattilainen on kuin kirurgi, joka tarvitsee kokonaisen yliopistollisen sairaalan potilasmassan, jotta käsi pysyy vakaana. Monessa organisaatiossa ei yksinkertaisesti ole riittävästi isoja hankintoja ammattitaidon kehittämiseksi ja säilyttämiseksi.

3. Resursoi riittävällä tasolla. Jatkuvien hankintojen parhaille ammattilaisille on tarjolla töitä kosolti sekä julkisella että yksityisellä puolella. Haasteena on se, että vain harva julkisen puolen organisaatio on perustanut virkoja, joiden palkkaus vastaa työn vaativuutta. Vielä harvempi aloittaa työt riittävän aikaisin, jotta välttyisi paniikilta ja ‘veren maku suussa’ -vaiheilta.

4. Maalaa visio ja polku ymmärrettävästi. Hankinnasta on vaikeaa saada poliittinen päätös tilanteessa, jossa nykyinen ratkaisu tuntuu olevan vielä ihan käyttökelpoinen. Poliittinen päättäjä on harvoin toimialan ammattilainen ja sellaisten päätösten teko, joista ei ole näkyvää hyötyä nykyisellä vaalikaudella vaatii lujaa poliittista selkärankaa.

5. Aloita ajoissa. Kiusallisen vaikeaksi ajoissa hankinnan aloittamisen tekee valmistelevan työn näennäinen helppous…jonkun on tutustuttava toimittajiin, alalla tyypillisiin ratkaisuihin, sopimusmalleihin, käyttöönottojen vaikeuksiin ja sudenkuoppiin. Etäisen johtajan voi olla vaikea erottaa toisistaan lahjakasta markkinan ja omien tarpeiden selvittäjää messuilla käyvästä laiskottelijasta.

6. Valaise päätöksentekoa. Monessa virastossa on helpompi saada miljoonabudjetti hankkeelle, jonka luullaan olevan helppo, sillä sitä ei ole riittävästi tutkittu, kuin sellaiselle, jonka tunnetut vaikeudet ja sudenkuopat on selvitetty, dokumentoitu ja selätetty hyvällä hankintatavalla. Jälkimmäisessä joudutaan dokumentoimaan riskit, edellisessä päätös voidaan tehdä kuin riskejä ei olisikaan.

Tätä projektien fiksun hankinnan teemaa sanoittaa myös mainio Helsingin Sanomien juttu, lue ex-nokialaisen psykologin Ari-Pekka Skarpin haastattelu.

7. Suosi ketterää. Ari-Pekka Skarp ehdottaa pilkkomaan hankkeen ketterän metodologian mukaisesti ja niin ehdotamme mekin Codentossa. Kaupunki rakennetaan talo kerrallaan ja laaja systeemi niin, että jokaisen laajennuksen jälkeen on toimiva, entistä parempi systeemi. Lähes kaikki suuret tietojärjestelmien kertahankinnat voidaan palastella sarjaksi pienempiä ja samalla riskittömämpiä hankintoja.

Eikä tässä vielä kaikki, alla muutama nämä seitsemän neuvoa koostavaa vinkkiä, eräänlainen hankinnan litmustesti:

+1. Bonusneuvo “vendor-lock-in”. Monimutkaisten palvelujen hankinta on aina vaikeaa. Tee kaikkesi, että voit vaihtaa toimittajaa kesken hankkeen ilman suurempia kustannuksia tai myöhästymisiä. Tämä “jos et käyttäydy kunnolla, en leiki kanssasi” on parasta mitä julkisessa hankinnassa voi omalle toteutustiimille hankinnan aikana antaa.

+2. Bonusneuvo “nuukailu”. Jos pisteytyskriteerit jättävät hankintahinnalle suurimman painoarvon, et todennäköisesti ole ymmärtänyt, mitä kollegasi järjestelmällä aikovat tehdä. Jos painotat hankintahintaa samalla itseasiassa väheksyt hyötyjä ja tulet helposti valinneeksi järjestelmän, josta on vähiten hyötyä. Sekä hinnalla että laadulla on hankinnassa merkitystä, kallein ei välttämättä ole paras. Hankintahinnan painotus johtaa helposti siihen, että todellinen hankintakustannus on moninkertainen hankintahintaan nähden, koska minimisetti ei sittenkään riittänyt työnne tekemiseen.

Petri Aukia
Twitter @aukia

#hankintalaki #julkishallinto #osto-osaaminen #ketteryys #lean #johtaminen #länsimetro 

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.