Millä perusteella teknologia tulisi valita?

Gartnerin malleissa ja menetelmäkäsikirjoissa kaikki menee ihanasti, kun taas käytännön elämässä kehitystiimit ja IT-yksiköt joutuvat tekemään teknologiavalintoja usein puutteellisilla tiedoilla. Erityyppiset hankinnat tulevat eteen niin harvoin, että edellisen kierroksen jälkeen markkina ja sen pelurit ovat ehtineet muuttua täysin. Ostaja on helposti toimittajien mainospuheiden varassa. Vai onko? Ei välttämättä, kun pitää muutaman perusasian valintoja tehdessään mielessä.

 

1 Panosta liiketoimintakriittisyyden mukaan

Ihan ensin hankintaa miettiessä on syytä tunnistaa, minkä verran järjestelmään on perusteltua panostaa. Jos kyseessä on aivan liiketoiminnan keskiössä oleva järjestelmä, jolla etsitään kilpailuetua ja kirkkaampaa tulevaisuutta, sen kehittämiseen voidaan panostaa aivan eri tavalla kuin jos kysymys on toiminnan rutiineista.

Jos tarve kuuluu jälkimmäiseen kategoriaan, hankintaa suunniteltaessa kannattaa saman tien kääntää päälle vaihde, jolla ratkaisut tarpeisiin mietitään vaikka millä ilveellä olemassa olevien valmisratkaisujen ympärille ja kustomointia tehdään minimaalinen määrä.

Seuraavat alaluvut koskevat erityisesti ensimmäisen kategorian teknologioiden valitsemista, niihin kun on todella aihetta keskittyä.

 

2 Varmista käyttäjätarve

Seuraavaksi on ymmärrettävä käyttäjän tarve. Mikä on käyttäjän perusongelma, joka teknologian on syytä ratkaista? Millainen palvelu sen voisi ratkaista, ja miten pystymme varmistamaan että potentiaalisen toimittajan tai meidän itse kehittämämme teknologia oikeasti tekee näin?

Jos mahdollista, ennen investointia on hyvä käyttää viikko-pari sen varmistamiseen, että käyttäjätarve on oikeasti kuultu käyttäjiltä itseltään eikä mielikuviteltu kulmahuoneessa. Ja samalla on hyvä yksinkertaisimmalla mahdollisella prototyypillä myös varmistaa, että löyhästi kaavailemamme ratkaisu oikeasti täyttää tuon käyttäjätarpeen – ennen kuin olemme upottaneet siihen merkittäviä määriä aikaa ja rahaa.

 

3 Analysoi liiketoiminnan tarve

Lähdettäessä toimittamaan käyttäjille sitä mille löytyi toivottavasti huutava tarve, on seuraavaksi selvitettävä liiketoiminnan teknologialle asettamat reunaehdot. Miten asiakkaan toivoma asia aiotaan toimittaa? Onko valintoja, joita on syytä tehdä vaikkapa hinnoittelun tai järjestelmän toimintasyklien suhteen?

 

4 Tutki uudet fiksut työtavat

Käyttäjän ja liiketoiminnan tarpeen lisäksi teknologiaan useimmiten liittyy organisaation työn arkea: teknologialla tehtävää asiakaspalvelutyötä, ylläpitoa tai taustaprosessia. Teknologiaa valitessasi haluat luultavasti varmistaa, että organisaatiosi on hahmottanut työtavan jolla sitä tullaan käyttämään.

Yleensä tässä kohtaa ei haluta menettää sitä mahdollisuutta, että uuden teknologiavalinnan siivin voidaan uudistaa myös työtapa. Kun käytetään hetken aikaa työtavan analysointiin, huomataan, mikä osa tekemisestä oikeastaan tuottaa arvoa asiakkaalle. Arvovirtakartta on tähän hyvä väline. Analyysin jälkeen teknologiavalinnalla voidaan linjata, että työssä saadaan oikeasti keskityttyä asiakkaan saamaan arvoon ja pakolliset rutiinit pystytään hoitamaan mahdollisimman tehokkaasti.

 

5 Kartoita tietojärjestelmäympäristö

Harvoin teknologiaa päästään valitsemaan puhtaalle pöydälle. Yleensä ympärillä on elinkaaren eri vaiheissa olevia tietojärjestelmiä joihin uuden teknologian pitää liittyä, ja palapeli rajoittaa valintoja. Näiden mallintamisen tapaa tärkeämpää on, että ne ja niiden integrointitarpeet tunnistetaan ennen teknologian valintaa. Esimerkiksi: millaisia rajapintatarpeita teknologian pitäisi täyttää?

 

6 Huomaa muut rajoitukset

Edellä mainittujen lisäksi on olemassa yleensä vielä muitakin ulottuvuuksia, jotka rajoittavat teknologiavalintaa. Joskus teknologian käyttöönotolla on aikataulu, joka rajoittaa ratkaisuvaihtoehtoja – kehitykseen panostamiseen ei yksinkertaisesti ole aikaa, vaan pitää rakentaa olemassa olevien ratkaisujen päälle. Joskus toimintaan liittyy lainsäädäntöä, joka asettaa teknologialle rajoituksia, esimerkiksi tietojen sijainnin tai muiden tietoturvatekijöiden muodossa.

 

7 Mieti elinkaaritarpeet

Useimmiten tässä pohdinnan tässä kohtaa vaatimusten yhdistelmä ajaa jo kohti melko harvalukuista joukkoa teknologia- ja toteutustapavaihtoehtoja. Yksi pohdinta on kuitenkin vielä jäljellä: teknologian elinkaari. Useimmiten halutaan välttää joutumista tuoreen teknologian ensimmäisten kokeilijoiden joukkoon.

Kun teknologia on ollut jo jonkin aikaa olemassa, tarjolla on ilmaista etua muiden tekemistä virheistä ja kehittämistä perusasioista eli hienosti sanoen ekosysteemin kypsymisestä. Toisaalta jos kysymys on kriittisestä teknologiasta ja haetaan kilpailuetua, joskus kannattaa myös maksaa oppirahat ja olla eturintamassa.

Joka tapauksessa on hankittava markkinaymmärrystä ja joskus myös meediopalveluita hahmottaakseen myös elinkaaren loppupää: Miten pitkälle tulevaisuuteen teknologialle voi olettaa jatkuvuutta vs. käyttötarpeen mitta? Miltä ekosysteemin kehitys näyttää, vaikuttaako siltä että teknologialle on tarvittaessa löydettävissä ylläpitäjiä myös tulevaisuudessa? Olemmeko investoimassa kisojen voittajahevoseen vai näyttäkö uhkaavasti siltä että kyseessä on häviäjätallin kaakki?

 

Työkaluja:

Tarpeen pikadokumentointiin voit käyttää ohjelmiston visiolakanaa, ks. https://www.codento.fi/lataa-lean-visiolakana-ohjelmistoprojektiisi/

Lisää prosessien analysoinnista ks. https://www.codento.fi/2017/08/hyvaa-halvalla-nopeasti/

 

Lataa opas: Uuden verkkopalvelun teknologiavalinnat

Onko blockchain yrityksellesi pelkkä troijan hevonen?

Harvat uudet teknologiat ovat yhtä kiinnostavia ja samalla yhtä vaikeita hyödyntää olemassaoleviin liiketoimintamalleihin kuin lohkoketju, eli blockchain. Lohkoketjun kansikuvajutut bitcoin-kurssikäyrän kera ovat helposti kirjoitettavia, teknologiaan on sijoitettu valtava määrä rahaa ja näyttää siltä, kuin lohkoketjulla olisi todella helppo tienata miljoonia tai miljardeja. Lohkoketju on vieläpä todella hienoa teknologiaa!

Väitän silti voimakkaasti, että useimmille yrityksille lohkoketju on tässä vaiheessa pelkkä kangastus tai troijan hevonen, vaikeasti kaupallistettava superkiinnostava teknologia, joka häiritsee aivan yhtä kiinnostavien mutta nopeasti kaupallistettavien teknologioiden kehitystä.

Blockchain-hypestä tulee Itselle mieleen Ford-autovalmistajan Nucleon -konsepti, kuvankaunis amerikanrauta, jonka moottorina piti olla ydinreaktori. Kun ydinreaktorit olivat kuuminta hottia, niitä ajateltiin asennettavan autoihin, lentokoneisiin, juniin ja jokaiselle asuinalueelle. Todellisuus olikin sitten jotain muuta.

Vähän sama tilanne on lohkoketjun kanssa. Valtavan hienoa teknologiaa, jolla voidaan tehdä uusia palveluita, joita ennen ei olisi voinut kuvitellakaan. Valitettavasti suurin osa nykyisen liiketoimintamallin ja lohkoketjun yhdistelmistä on yhtä banaaleja kuin Fordin ydinreaktorilla käyvä henkilöauto – teoriassa mahdollisia, mutta härveleitä, joiden haitat eivät koskaan vastaa niistä saatua hyötyä.

Mistä sitten kannattaisi aloittaa? Itse ehdotan, että nyt on oikea aika jakaa uusien teknologioiden kehitys kolmelle eri tiimille tai striimille, jos tilanne on samanlainen kuin monilla asiakkaillamme.

  • Tiimi I

Useimmat organisaatiot ovat yllättävän käsityövaltaisia, kun niihin kunnolla tutustuu. Arkisia työvaiheita varten tulostetaan A4:ia, tieto siirretään järjestelmästä toiseen käsin tai eri järjestelmissä olevaa tietoa ei saada yhdistettyä fiksumpaa toimintaa varten.

Yritys, jonka tiedot ovat tällä tavalla hujan hajan ei voi onnistua uudistumisessa, mutta onneksi nykyään yhteisen näkymän luominen on halvempaa ja nopeampaa kuin koskaan aiemmin, eikä tätä varten ole pakko ostaa SAP:pia tai mitään muutakaan monoliittista sovellusta.

  • Tiimi II

Toisena striiminä etsisin kaikki ne kohdat, joissa arkisia päätöksiä tehdään täysin prosessin mukaisesti. Jokainen käsityönä tehty, tarkkaa byrokraattista prosessia noudattava päätös kannattaa automatisoida. Tiedon käsittelyn nopeuttaminen tuo yllättäviä hyötyjä, useimmiten sekä asiakkaalle että myynnille ja markkinoinnille.

  • Tiimi III

On vaikea saada rahoitusta tiimeille I ja II ilman vanhoista malleista poikkeavia liiketoimintasuunnitelmia. Asiat ovat rempallaan, koska loppujen lopuksi vanhassa maailmassa on ollut halvempaa teettää enemmän käsityötä kuin automatisoida prosessit loppuun saakka. Tämä on muuttunut viime vuosina. Automatisointi on jatkossa onnistumisen edellytys, eikä siitä voi tinkiä. Uudet tekoälyyn perustuvat liiketoimintamallit vaativat perustuksekseen hyvää tietoa ja organisaation, joka ei tuhlaa aikaa ja rahaa turhaan käsipelillä tunkkaamiseen.

Tekoäly, tai oikeastaan sen koneoppimiseksi kutsutut toteutustavat, ovat jo arkipäiväisiä. Kaikkien suurten internetyritysten, Googlesta Spotifyhyn, onnistumisen salaisuus on fiksussa koneoppimisen käytössä. Useimmilla toimialoilla tekoälyä fiksusti hyväksikäyttävä yritys tulee seuraavina vuosina pieksemään ne, joiden tekoälytiimi ei ole päässyt vauhtiin.

Kolmostiimi toimii myös loistavana kirittäjänä kahdelle muulle tiimille. Tieto, jonka yhdistäminen on vaikeaa tai johon liittyvät päätökset tehdään vielä käsipelillä, tulee yhdistetyksi ja automatisoiduksi, kun kolmostiimi lupaa sellaista, jota kilpailijalla ei ole – automaattisen asuntolainapäätöksen, juuri sinulle halvalla räätälöidyn puvun valmistuksen tai juuri sinun makuusi viritetyn illallisreseptin.

Me Codentossa autamme teknologiavalinnoissa ja olemme ammattilaisia Tiimien I, II ja III työssä. Etsimme jatkuvasti uusia arkkitehtejä teknologiatiimiimme ja teemme niin suuria kuin pieniä teknologiavalinta toimeksiantoja yksityisellä ja julkisella puolella.

 

Banneri Uuden verkkopalvelun teknologiavalinnat 2018

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.

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ä.