Teetkö DevOpsia oikein?

Yksi yleisimmistä virheistä DevOps-transformaatiossa on nähdä se pelkästään teknologisena harjoituksena. Kun fokus on näin kapea, seurauksena voi olla kyvykkyyksien kehittäminen vain deploymentien tuottamiseksi mahdollisimman nopeasti. Valitettavasti suuri deploymentien määrä ei automaattisesti tarkoita, että viet strategiaa eteenpäin tai tuot arvoa sidosryhmille. Joskus etenet vain nopeammin ja tehokkaammin kohti ei mitään.

Mitä laadukkaan ohjelmiston tekeminen vaatii?

Mistä tiedämme, tuottaako julkaisemamme ohjelmisto todella arvoa asiakkaille? Design thinkingin Desirability, Feasibility & Viability -malli tarjoaa hyvän pohjan sen arvioimiseen, syntyykö arvoa todennäköisesti. Parasta mallissa on sen yksinkertaisuus.

Kolme tyypillistä epäonnistumispistettä ovat:

Palvelu ei ratkaise käyttäjän ongelmia tai sen käyttö on liian hankalaa, mikä johtaa vähäiseen loppukäyttäjien käyttöönottoon – epäonnistunut desirability
Palvelu vastaisi kaikkiin tarpeisiin, mutta sen toteuttaminen ei ole mahdollista, koska tarvittava kehitystyö on epärealistinen tai prosessimuutoksia ei voida toteuttaa – epäonnistunut feasibility
Palvelu vastaa käyttäjien tarpeisiin ja on toteutettavissa, mutta se ei tuottaisi organisaatiolle riittävästi liiketoiminta-arvoa – epäonnistunut viability

Eteenpäin kiirehtiminen ei ole riittävän leania

Viime vuosikymmen teki lean-tuotekehityksestä suositun jatkuvana ”rakenna – mittaa – opi” -syklinä. Tämä lähestymistapa voi johtaa kulttuuriin, jossa konsepteja ei validoida ennen niiden viemistä kehitykseen. Tällöin kehitystyötä saatetaan käyttää työhön, josta ainoa validoitu oppi on se, ettei konsepti toiminut. Pahimmillaan suurin osa kehitystyöstä kuluu hukkaan, mikä on lean-ajattelun vastakohta.

Ohjelmistokehitys on usein pullonkaula, joka määrittää, kuinka nopeasti organisaatio pystyy kehittämään palveluitaan. On tärkeää kehittää kyvykkyyksiä julkaista usein, mutta yhtä tärkeää on kehittää tapoja, joilla palvelut konseptoidaan ja vaatimukset määritellään. Hyvä uutinen on, ettei alkuun pääseminen vaadi koko organisaation kattavan Agile-kehyksen käyttöönottoa. Näillä kolmella käytännöllä voit saada aikaan suuren muutoksen.

Jatkuva validointi tuottaa merkittäviä hyötyjä

Ensinnäkin, validoi ennen kehitystä. Siinä kaikki. Validointiin tarvittavat työpäivät voi yleensä laskea yhden käden sormilla. Säästetyn työn potentiaali on ominaisuustasolla kuukausia, mutta konseptien kohdalla vuosia.

Säästät paljon hukkatyötä ja vaivaa, kun kulttuurissasi palvelukonseptien validointi ennen etenemistä on itsestään selvä ensimmäinen vaihe. Ominaisuuksia kannattaa myös validoida jatkuvasti ennen kuin ne päätyvät kehityssprinteihin.

Yksinkertaisimmillaan jatkuva validointi voi tarkoittaa:

Viability: Näkevätkö keskeiset sidosryhmät, mukaan lukien kumppanit ja kanavat, ominaisuuden tuottavan arvoa, ja onko tarvittava muutos hallittavissa?
Desirability: Mitä prototyypin käyttäjätestaus kertoo? Onko se käyttäjille miellyttävä, toimiva ja merkityksellinen? Toisin sanoen: saimmeko aikaan ”vau”- vai ”häh”-reaktion?
Feasibility: Läpäisevätkö arkkitehtuurisuunnitelman kriittiset kohdat teknisen proof of conceptin, ja onko palvelu toteutettavissa kohtuullisella työmäärällä?

Ominaisuuksien validoinnin perusteellisuus vaatii tasapainoa ja hieman harjoittelua. Kuinka perusteellisesti esimerkiksi pienten ominaisuuksien eri käyttäjäpolkujen variaatioita pitää validoida? Tämä vaatii kokeilua, sillä toiselle toimivat validointiperiaatteet eivät aina sovellu sinulle.

Monialaiset työskentelytavat

Helpoin tapa varmistaa desirability, viability ja feasibility on saada suunnittelu, liiketoiminta ja kehitys työskentelemään yhdessä. Esimerkiksi ominaisuuden suunnittelu kannattaa aloittaa kokoamalla tuoteomistaja, suunnittelija ja kehittäjä valkotaulun ääreen tai etätyöpajaan.

Jokaisen palvelun parissa työskentelevän tulisi ymmärtää, miten oma työ liittyy muiden tekemiseen. Yhteistyötä tehostavia menetelmiä ja työkaluja, kuten design sprintiä, kannattaa käyttää tarpeen mukaan. Yhteistyö ei vain vähennä hukkaa, vaan myös parantaa ideoiden laatua, sillä saat välitöntä palautetta desirabilitystä, viabilitystä ja feasibilitystä.

Kun muistat ottaa suunnittelun, liiketoiminnan ja kehityksen mukaan projektin jokaiseen vaiheeseen, onnistumisen mahdollisuutesi ovat parhaat. Myös prosessin ja työskentelytapojen kehittämisen aloittaminen on helppoa (lue lisää Digital Product Building Toolkitistamme).

IT:n on siirryttävä vasemmalle

Shift left tarkoittaa käytäntöä, jossa ongelmia ehkäistään ja laatua parannetaan tekemällä enemmän tehtäviä arvoketjun alkuvaiheessa. DevOpsissa tämä on perinteisesti tarkoittanut hyväksymistestien laatuun keskittymistä tai Continuous Deploymentin mahdollistamista. Ne ovat erittäin tärkeitä, mutta IT:n on mentävä vielä pidemmälle vasemmalle.

On olennaista, että suunnittelijat, liiketoiminta ja kehittäjät työskentelevät tehokkaasti yhdessä koko arvoketjun ja vaatimuksen elinkaaren ajan. Ei riitä, että IT keskittyy vain ”vaatimusten hallintaan”, vaan sen on osallistuttava ominaisuuksien konseptien tutkimiseen ja suunnitteluun.

Kun alat validoida jatkuvasti ja kehittää konseptien tutkimiseen, suunnitteluun ja kehitykseen liittyviä poikkitoiminnallisia toimintatapoja, olet hyvällä matkalla kohti suurempaa arvoa sekä pienempää hukkaa ja vähemmän haasteita. Pystyt myös kohdentamaan suunnittelu- ja kehitystyösi uudelleen tai jopa muuttamaan koko roadmapin suuntaa.