”Se vie vain hetken”
Jokainen, joka työskentelee verkkosivujen, sovellusten tai järjestelmien kehityksen tai ylläpidon parissa, tuntee tämän lauseen.
”Voisitteko vain vaihtaa tuon napin?”
”Tämä on todella pieni korjaus.”
”Voisitko vain siirtää tämän elementin?”
”Voidaanko tämä tehdä nopeasti?”
”Luultavasti viisi minuuttia työtä?”
Ja joskus se todellakin on niin.
Joskus napin värin vaihtaminen vie muutaman minuutin. Joskus kirjoitusvirheen korjaaminen vaatii yhden klikkauksen. Joskus kehittäjä avaa koodin, katsoo, muuttaa yhden rivin ja homma on sillä selvä.
Ongelma on siinä, että ei jokainen muutos, joka näyttää käyttäjän näkökulmasta pieneltä, ole pieni järjestelmän näkökulmasta.
Ja vielä suurempi ongelma syntyy, kun tällaisia ”pieniä muutoksia” on kymmenittäin, kymmeniä tai satoja kuukaudessa. Silloin alkaa tapahtua jotain mielenkiintoista.
Yritys saattaa kokea, ettei se tilaa mitään suurta. Samaan aikaan IT-tiimi käyttää merkittävän osan ajastaan juuri näiden pienten tehtävien toteuttamiseen.
Ja tässä syntyy kysymys: Paljonko yhden ”Korjatkaa tämä nopeasti” -napin todellinen hinta oikeasti on?
Aloitetaan yksinkertaisella esimerkillä
Kuvitellaan, että markkinointiosasto lähettää software houselle viestin:
”Hei, meidän täytyy vain vaihtaa napin tekstiä. Sen pitäisi olla ’Tutustu tarjoukseen’ eikä ’Tarkista tarjous’. Se on pieni juttu, tehkää nopeasti, kiitos.”
Kuulostaa banaalilta. Mutta tekniseltä tiimiltä se voi näyttää täysin erilaiselta.
Kehittäjän täytyy:
1. Analysoida pyyntö
Missä nappi sijaitsee?
Onko se vain yhdessä paikassa?
Onko se useammassa sivun versiossa?
Onko teksti kovakoodattu?
Onko se CMS:n hallinnoima?
Koskeeko muutos sekä työpöytä- että mobiiliversiota?
Onko nappi osa komponenttia, jota käytetään muissa paikoissa?
2. Toteuttaa muutos
Vaihda teksti.
Rakentaa komponentti uudelleen.
Päivittää sisältö CMS:ssä.
Tai muokata koodia.
3. Tarkistaa vaikutus
Näkyykö nappi edelleen oikein?
Eikö teksti ylitä nappialuetta?
Toimiiko kaikki puhelimella?
Eikö muutos vaikuta muihin paikkoihin?
4. Testata
Voiko napin klikata?
Ohjaako linkki oikeaan paikkaan?
Eikö ilmennyt virheitä?
5. Julkaista muutos
Jos muutos vaatii deployn, se pitää laittaa tuotantoympäristöön.
Ja yhtäkkiä käy ilmi, että: ”vain tekstin muutos”
ei välttämättä tarkoita: ”vain viisi minuuttia työtä”.
Paljonko yksi pieni muutos voi maksaa?
Oletetaan hyvin konservatiivinen skenaario.
Kehittäjä käyttää:
- 15 minuuttia analyysiin,
- 20 minuuttia toteutukseen,
- 15 minuuttia testeihin,
- 10 minuuttia valmisteluun ja julkaisuun.
Yhteensä: 60 minuuttia työtä.
Ja tässä tulee tärkeä kohta. Jos tiimin tuntihinta on esimerkiksi 200 euroa nettoa, yksi näennäisen pieni muutos maksaa noin: 200 euroa nettoa.
Mutta se ei ole kaikki. Käytännön prosessissa voi ilmetä myös:
- tehtävän siirtoa,
- laajuuden täsmentämistä,
- kysymyksiä asiakkaalle,
- odottelua vastauksia,
- muutoksen tarkistusta pyytäjältä,
- korjauksia palautteen jälkeen,
- uudelleenjulkaisua.
Yksi tunti voi siis hyvinkin muuttua kahdeksi. Ja yksi pieni muutos voi muuttua useiden tuntien työksi koko tiimille.
Kalleinta ei useinkaan ole muutoksen tekeminen
Tämä saattaa kuulostaa paradoksaaliselta. Joskus itse tehtävän suorittaminen vie 10 minuuttia. Mutta valmistautuminen vie toiset 20. Sitten tulee testit, julkaisu, viestintä ja kontekstin vaihtamisen kustannus.
Juuri viimeinen osa aliarvioidaan usein eniten.
Context switching – pienten tehtävien piilotettu kustannus
Kehittäjä työskentelee suuren ominaisuuden parissa. Koodi on auki. Hän analysoi ongelmaa. On keskittynyt.
Sitten tulee viesti: ”Hei, pieni juttu. Voisitko korjata napin?”
Kehittäjä keskeyttää työn. Avataankaan tiketti. Tarkistaa sivun. Etsii paikkaa koodista. Tekee muutoksen. Testaa. Julkaisee. Palaa edelliseen tehtävään...
Ja sitten hänen täytyy muistaa: ”Mihin sitä jäinkään?”
Tätä kutsutaan context switchingiksi, eli kontekstin vaihtamiseksi. Ja se voi olla hyvin kallista. Ei siksi, että jokainen yksittäinen muutos vaatisi paljon työtä, vaan siksi, että jokainen muutos keskeyttää ajatusprosessin.
Mitä monimutkaisempi tehtävä on, sitä suurempi on paluun kustannus. Siksi 10 mikrotehtävää ei aina tarkoita 10 × 10 minuuttia. Käytännössä se voi tarkoittaa huomattavasti enemmän.
Yksi nappi ei ole mitään. Sata nappia on prosessi.
Oletetaan, että yritys lähettää tekniselle tiimille:
- 20 pientä muutosta kuukaudessa,
- jokainen vie keskimäärin 45 minuuttia.
Se tekee: 15 tuntia työtä kuukaudessa.
200 euron tuntihinnalla: 3000 euroa nettoa kuukaudessa.
Vuositasolla: 36 000 euroa nettoa.
Ja puhumme vain 20 pienestä tehtävästä kuukaudessa. Ilman suuria ominaisuuksia. Ilman tuotteen kehitystä. Ilman uusia moduuleja. Ilman integraatioita. Ilman suunnittelua.
Vain: ”vaihtakaa”, ”korjatkaa”, ”siirtäkää”, ”lisätkää”, ”poistakaa”.
Kuvitellaan nyt organisaatio, jossa tällaisia tehtäviä on 50 kuukaudessa. Tai 100.
Skaala näyttää aivan erilaiselta...
Mikrotehtävillä on vielä yksi hinta – ne estävät kehitystä
Tämä on yksi tärkeimmistä kokonaisuuden osista.
Jos kehitystiimi käyttää 20 % ajastaan pieniin korjauksiin, se ei voi käyttää näitä 20 % tuotteen kehittämiseen. Se kuulostaa itsestään selvältä. Mutta käytännössä se ei aina näy.
Yritys kysyy: ”Miksi uusi ominaisuus ei ole vielä valmis?”
Kehittäjä vastaa: ”Meillä oli paljon juoksevia asioita.”
”Minkälaisia?”
”Korjauksia, pieniä muutoksia, päivityksiä, pieniä tehtäviä.”
Jokainen oli pieni. Mutta yhdessä ne muodostivat suuren työn esteen. Se on vähän kuin puhelimen ilmoitukset. Yksi ilmoitus ei haittaa. Kymmenen jo vähän. Sata? Yhtäkkiä huomaamme kuluttaneemme koko päivän reagoimiseen.
Mikrotehtävät ovat samanlaisia.
”Pieni tehtävä” ei aina ole pieni tehtävä
On myös hyvä ymmärtää, että kaikki muutokset eivät ole samanlaisia. Tekstin muuttaminen CMS:ssä voi todellakin viedä muutaman minuutin.
Mutta tekstin muuttaminen sovelluksessa voi vaatia:
- komponentin löytämistä,
- koodin muuttamista,
- käännösten päivittämistä,
- testausta,
- sovelluksen uudelleenrakentamista,
- julkaisua.
Yhden kentän muuttaminen voi vaatia muutoksia:
- frontendiin,
- backendiiin,
- tietokantaan,
- API:iin.
Yhden elementin muutos järjestelmässä voi vaikuttaa muihin elementteihin.
Siksi kysymykseen: ”Kuinka kauan tämän napin muuttaminen kestää?”
ilman järjestelmän arkkitehtuurin tuntemusta usein ei voi antaa järkevää vastausta.
Ensin pitää tarkistaa. Vasta sitten voi arvioida.
Miksi kehittäjä joskus sanoo: ”Minun täytyy tarkistaa”?
Se ei ole välttelevä vastaus. Se on usein ammattitaidon merkki.
Hyvän kehittäjän ei pitäisi luvata: ”Joo, selvä, viisi minuuttia.”
jos hän ei tiedä, mitä alla on.
Hänen pitäisi sanoa: ”Tarkistan, missä tätä elementtiä käytetään, ja ilmoitan.”
Se voi viedä 10 minuuttia. Mutta nuo 10 minuuttia voivat säästää useita tunteja ongelmilta. Siksi kallein muutos ei ole usein se, joka vie tunnin.
Kallein on usein se, joka:
- rikkoo toisen toiminnon,
- aiheuttaa tuotantovirheen,
- vaatii kiireellisen rollbackin,
- generoi lisää tikettejä,
- tarvitsee useiden henkilöiden väliintuloa.
Siksi analyysi ennen muutosta on osa työtä, ei ajan hukkaa.
Miten asiakas voi vähentää mikrotehtävien kustannuksia?
Kyse ei ole siitä, että pitäisi lopettaa pienten muutosten pyytäminen. Pienet muutokset ovat normaali osa tuotteen kehitystä. Kyse on niiden hallinnasta.
1. Ryhmittele pienet tehtävät
Sen sijaan, että lähetät:
”Vaihda nappi.”
”Korjatkaa otsikko.”
”Lisätkää tämä linkki samalla kertaa.”
”Ja siirtäkää tämä elementti.”
On parempi kerätä ne yhteen pakettiin.
Tiimi voi tehdä useita muutoksia yhden työskentelyjakson aikana.
Vähemmän kontekstin vaihtoa.
Vähemmän viestintää.
Vähemmän julkaisuja.
Pienemmät kustannukset.
2. Aseta prioriteetit
Kaikki eivät ole kiireellisiä.
Jos kaikella on tila:
URGENT
ei mikään ole todella kiireellinen.
Kannattaa jakaa tehtävät:
- kriittisiin,
- tärkeisiin,
- suunniteltuihin,
- kosmeettisiin.
Näin tiimi voi työskennellä tehokkaammin.
3. Mieti, tarvitaanko muutosta koodiin
Jos yritys jatkuvasti muuttaa:
- tekstejä,
- kuvia,
- mainoksia,
- linkkejä,
- viestejä,
ongelma ei välttämättä ole kehittäjän nopeudessa.
Ongelma voi olla arkkitehtuurissa.
Jos jokainen sisällön muutos vaatii ohjelmoijan, kannattaa harkita CMS:ää tai hallintapaneelia.
Hyvin suunniteltu järjestelmä antaa liiketoiminnan ihmisille mahdollisuuden hallita itsenäisesti asioita, jotka eivät todellisuudessa vaadi ohjelmoijan puuttumista.
Hyvän järjestelmän tulisi vastata kysymykseen: kuka tekee tämän muutoksen?
Tämä on erittäin tärkeä suunnitteluperiaate. Kaikki muutokset eivät kuulu kehittäjälle.
Jos markkinointi voi itse:
- vaihtaa tekstiä,
- korvata kuvan,
- lisätä artikkelin,
- muuttaa osioiden järjestystä,
ei ole järkevää sitoa ohjelmoijaa tähän työhön.
Kehittäjän tulisi tehdä sitä, mikä vaatii hänen osaamistaan.
Eli esimerkiksi:
- uuden toiminnallisuuden rakentaminen,
- järjestelmän kehittäminen,
- integraatiot,
- optimointi,
- tietoturva,
- arkkitehtuuri,
- teknisten ongelmien ratkaiseminen.
Muuten yritys alkaa maksaa kehittäjälle tehtävistä, jotka järjestelmän käyttäjä olisi voinut tehdä itse.
Se on vähän kuin palkkaisi automekaanikon tankkaamaan auton. Hän osaa sen kyllä. Mutta tarvitsemmeko todella sitä?
Milloin kannattaa sanoa: ”Tehdään tämä eri tavalla”?
Jos sama pyyntö toistuu säännöllisesti, kannattaa pysähtyä ja kysyä:
Miksi meidän täytyy tehdä tämä joka kerta käsin?
Jos joka viikko pyydämme muuttamaan samaa elementtiä, ehkä meidän pitäisi rakentaa:
- Asetus CMS:ään,
- Konfiguraatio,
- Hallintapaneeli,
- Automaatio,
- Self-service-mekanismi.
Kertaluonteinen kustannus tällaisen ratkaisun rakentamisesta voi olla suurempi. Mutta myöhemmin jokainen muutos voi viedä sekunteja tunneiksi kuluttavan työn sijaan.
Tämä on juuri ero: maksaa jokaisesta muutoksesta versus sijoittaa järjestelmään, joka mahdollistaa muutokset itsepalveluna.
Mikrotehtävät ja yhteistyömalli software housen kanssa
Tämä on myös tärkeä aihe asiakkaille.
Jos yhteistyö software housen kanssa perustuu pelkästään malliin: ”me ilmoitamme – te hinnoittelette – hyväksymme – toteutatte”, jokainen pieni muutos voi aiheuttaa ylimääräistä organisatorista kuormaa.
Siksi jatkuvassa yhteistyössä toimivat usein paremmin:
- tuntipaketit,
- ylläpitoabonementit,
- vakio tiimi,
- tehtäväjono (backlog),
- säännölliset sprintit,
- sovitut julkaisuikkunat.
Ei tarkoita, että jokaisen asiakkaan pitäisi valita sama malli. Kyse on yhteistyötavan sovittamisesta projektin luonteeseen.
Jos yritys tarvitsee yhden muutoksen kuukaudessa, monimutkainen prosessi voi olla tarpeeton. Jos yritys lähettää 50 tehtävää kuukaudessa, prosessin puute voi olla hyvin kallis.
Kannattaako jokaista muutosta laskuttaa erikseen?
Se riippuu.
Joissakin projekteissa tarkka minuuttitasoinen laskutus on järkevää. Toisissa se voi tuottaa enemmän hallinnollista työtä kuin säästöä.
Siksi kannattaa katsoa yhteistyötä laajemmin.
Tärkein kysymys ei ole: ”Paljonko tämä yksi muutos maksoi?”
Parempi kysymys on: ”Paljonko meiltä maksaa tapa, jolla hallitsemme kaikkia muutoksia?”
Jos yritys maksaa 200 euroa yhdestä muutoksesta, mutta siten välttää virheitä ja saa varmuuden, että kaikki toimii oikein, se voi olla järkevä kustannus.
Jos taas joka kuukausi maksetaan useita tuhansia kymmeniä samanlaisia mikrotehtäviä varten, kannattaa miettiä, voitaisiinko ongelma ratkaista systemaattisesti.
IT:n kalleimmat sanat?
Ehkä ne ovat: ”Se on vain pieni muutos.”
Ei siksi, että pienet muutokset olisivat huonoja. Ne ovat tarpeellisia.
Digitaalinen tuote elää. Asiakkaiden tarpeet muuttuvat. Markkinointi vaihtuu. Teknologia kehittyy. Muutokset ovat luonnollisia.
Ongelma syntyy, kun organisaatio ei näe muutosten kumuloituvaa kustannusta.
Yksi pieni muutos? – Ei iso juttu.
Kymmenen? – Vielä ei paljoa.
Sata? – Se on jo prosessi.
Ja jos näitä prosesseja on kymmeniä? Yhtäkkiä yritys ei käytä rahaa tuotteen kehittämiseen. Se käyttää sitä pienten korjausten jatkuvaan tekemiseen.
Lasketaanko napit vai aika?
Hyvin johdettu digitaalisen tuotteen kehitys ei ole sitä, että estetään asiakasta tekemästä pieniä muutoksia.
Se on sitä, että tiedetään:
- mitkä muutokset todella vaativat kehittäjää,
- mitkä voidaan tehdä itse,
- mitkä kannattaa automatisoida,
- mitkä pitää ryhmitellä,
- mitkä ovat todella kiireellisiä,
- mitkä voi suunnitella,
- mitkä kannattaa ratkaista systemaattisesti.
Koska joskus paras vastaus: ”Korjatkaa tämä nopeasti.”
ei ole: ”Selvä, teemme sen.”
vaan: ”Katsotaanpa, miksi meidän täytyy korjata tämä uudestaan kuukauden päästä.”
Tässä software house ei enää ole pelkkä tehtävien toteuttaja. Se alkaa olla teknologinen kumppani. Hyvä kumppani ei vain toteuta seuraavaa tikettiä.
Se auttaa myös näkemään, että joskus halvin muutos ei ole se, jonka teemme nopeasti. Halvin on se muutos, jota emme joudu tekemään sadas kertaa.
Ja juuri siksi yksi ”Korjatkaa tämä nopeasti” -nappi voi maksaa tunnin.
Mutta hyvin suunniteltu järjestelmä voi tehdä seuraavat sata tällaista muutosta itsepalveluna muutamassa minuutissa.
Se ei ole säästö ohjelmoijista. Se on sijoitus parempaan prosessiin, parempaan arkkitehtuuriin ja tiimin ajan fiksumpaan käyttöön.
