Jokainen yritys on nykyään ohjelmistoyritys. Digitalisaation menestystarinat osoittavat, että palvelujen sähköistämisessä pitää siirtää ajatukset pois pelkän työkalun hankkimisesta. Teknistä toteutusta ei voi erottaa palvelukonseptin kehittämisestä. Palveluiden kehittäminen on jatkuvaa, ja siten myös teknistä toteutusta on pidempiaikainen kehitys eikä kertahankinta. Jatkuva kehittäminen hämärtää kehitys- ja ylläpitovaiheiden rajoja.
Tämä muutos pitää huomioida tiimiä muodostettaessa. Tehokkaan tiimin ainesosiin sisältyy markkinointia, käytettävyyttä, ohjelmistokehittämistä ja ylläpitoa. DevOps on ohjelmistokehittämisen kulttuuri, jossa painotetaan yhteistyötä yli liiketoiminnallisten lokeroiden ja nopeutetaan palautevirtoja automaation avulla. Nopeus saattaa yllättää palvelun ohjaamisesta vastaavat päättäjät, joiden tulisi huolehtia pysyvänsä kyydissä mukana.
Palautetta? Kyllä, kiitos!
Onnistunut palvelu syntyy siitä, että tehdään ajoissa ne asiat joita loppukäyttäjät haluavat (tai joita loppukäyttäjät saadaan haluamaan) ja jätetään tekemättä ne toiminnot, joita loppukäyttäjät eivät halua. Uutta palvelua kehitettäessä tarvitaan tietoa siitä mikä toimii ja myy. Tieto syntyy oppimalla ja mitä nopeammin palvelusta saadaan palautetta sitä nopeammin voidaan tehdä suuntaa korjaavia liikkeitä.
Palaute on sikäli vaarallinen sana, että suomalaiset mieltävät sen helposti negatiiviseksi. Tässä yhteydessä palautteella on kuitenkin laajempi merkitys. Palautetta on paitsi loppukäyttäjiltä saatu sanallinen palaute, myös käyttäjien käyttäytymiseen perustuva analytiikka sekä järjestelmän teknisen toiminnan monitorointi.
Palautteen kerääminen on turhaa, jos siitä ei ota oppia.
Toimivan palautevirran avulla tietää, mitä seuraavaksi kannattaa tehdä. Palvelun kehitysputki koostuu eripituisista vaiheista, joista jokainen muodostaa systeemiin takaisinkytkennän, palautevirran. Matka ideasta analytiikan keräämiseen on pitkä, koska jokainen vaihe tuo oman viiveensä kokonaisläpimenoaikaan.
Ohjelmistokehittämisen pilvipalvelut ovat vallanneet alaa voitokkaasti, erityisesti kehitysvaiheen nopeuttajana ja riskinlieventäjänä. Kokeiluihin tarvittava infrastruktuuri saadaan nopeasti käyttöön ilman erityistä sitoutumista, jonka ansiosta kokeiluja myös uskalletaan tehdä. Liiketoiminnalle se tarkoittaa nopeaa palvelukehitystä pienin riskein ja investoinnein.
Organisaatiosta ja johdon panostuksesta riippuen ohjelmistokehitys pilvipalveluineen voi olla siinä määrin edellä, että päätöksenteosta ja ohjauksesta muodostuu suhteellisesti suurin pullonkaula. Päättäjät eivät enää odotakaan kehittäjiä, vaan kehittäjät odottavat päättäjiä.
Varmista ettet seiso ohjelmistotiimisi tiellä.
Analytiikkaan ja ohjaukseen on varattava riittävästi resursseja. Tiellä seisominen hidastaa kokonaisläpimenoaikaa, joka helposti johtaa siihen, että palautevirtojen seurannasta ja käyttäjälähtöisyydestä luovutaan. Sokkona tekemisen seuraukset paljastuvat vasta pidemmän ajan kuluttua.
Varhainen Ops se palvelua pyörittää
Kun tuotantoliukuhihna rullaa sulavasti, on helpompi julkaista kerrallaan entistä pienempiä toiminnallisuusjoukkoja. Kehittämisestä tulee jatkuvaa ja se sulautuu ylläpidon kanssa yhteen. Käytännössä tämä tarkoittaa, että loppukäyttäjä käyttää palvelua heti, kun jo ensimmäiset päätoiminnallisuudet ovat toteutettu. Projektitiimistä pitäisikin tällöin löytyä ylläpito- eli Ops-osaamista alusta lähtien, eikä vasta kahden vuoden kehitystyön jälkeen.
Varmista riittävä Ops-panostus ajoissa.
Palvelinvirtualisointi ja automaatiotyökalut ovat helpottaneet jonkin verran ylläpitotyötä, ja osa perustehtävistä luonnistuu sovelluskehittäjältä muun koodaamisen ohessa ylläpidon pienellä avustuksella. Ja koska pilvipalvelut mahdollistavat infrastruktuurin muokkaamisen lennosta, voi sovellus itse ohjata omaa alustaansa esimerkiksi loppukäyttäjien mukaan.
Myös Ops-roolissa koodataan, kun ylläpidosta tuleekin toimivan automaation ohjelmointia. Dev- ja Ops-roolit sulautuvat yhteen ja ohjelmistokehitystiimeistä löytyy molempaa osaamista. Samankaltaisempien taitojen kautta kyseessä voi olla sama henkilö.
Palvelu uunista ulos
Jatkuvaan julkaisemiseen (Continuous Deployment) suhtaudutaan ohjelmistoalalla joskus fanaattisesti ja kilpaillaan sillä, kuinka monta kertaa päivässä päivityksiä viedään tuotantoon. Julkaisutahdin maksimointi ei kuitenkaan ole itseisarvo, vaan oikea tavoite on pystyä julkaisemaan aina tarvittaessa. Jatkuvan julkaisemisen tarkoitus on saada palaute varhain, vähentää turhan työn määrää ja saada palvelun ominaisuudet nopeammin markkinoille.
DevOpsin arvo on siinä, että julkaiseminen ei ole enää pelottava ja massiivinen projekti. Palvelun kehittämisestä voidaan tehdä entistä enemmän käyttäjälähtöistä. Vaikka suomalaisia kehittäjiä onkin kehuttu oma-aloitteisiksi, jatkuva kehittäminen vaatii silti jatkuvaa ohjaamista. Prosessia kannattaa viilata sieltä, missä se eniten tökkii. Kuka odottaa ketä, se selviää palautevirtojen pituuksista.
