Minulla on ystävä, joka työskentelee DevOps-konsulttina IT-alan yrityksessä. Keskusteluissamme aihe kääntyy luonnollisesti usein töihin ja hänen tyypillinen työpurkautumisensa kuulostaa suurin piirtein tältä:
“Pidettiin palaveri asiakkaan kanssa, selvitettiin tarpeet ja teimme ehdotuksen pilvipohjaisesta ratkaisusta. Se ja se palvelu, managed-tietokanta ja tehdään koko homma serverless-arkkitehtuurina. Asiakas kysyy ratkaisun kuukausiveloituksista ja kauhistuu: Ei nyt noin kallista ratkaisua voi ottaa! Tietokantakin maksaa satasen kuussa! Eikö voida tehdä jotenkin halvemmalla? “
En tee henkilökohtaisesti DevOpsia, mutta tämä on eri muodoissaan tuttu tarina. Asiakas tai muu päättävä elin näkee ulkoisen palvelun kustannukset ylikorostettuina, mutta ei ota tasapuolisesti huomioon itse tuotetun palvelun riskejä ja kustannuksia, joihin kuuluvat työaika- ja resurssikustannukset, sekä epävarmuus liittyen ohjelmistokehittäjiin ja ohjelmiston tuottamiseen.
Tee se itse -ajatusmalli voi olla vaarallinen harha
Kun aloittelin uraani, olin mukana projektissa, jossa ajateltiin samalla tavalla. Säästetään palvelin- ja palveluntarjoajan kustannuksissa, kun tehdään itse. Ajatusmallissa työaikaa saa käyttää miltei rajattomasti, mutta kuukausittaiset lisäkustannukset eivät saa nousta liian korkeiksi.
Tämä kuulosti korviini järkevältä. Emmehän me halua lukittautua tiettyyn palveluntarjoajaan ja olla suuren pilvialustan laskujen ja muutosten armoilla. On parempi tehdä itse toiminnallisuudet, koska pakettienhallinnan paketit voivat olla vaarallisia. Mehän pystymme itse tekemään tarvitsemamme rajapinnan. Kolleganikin oli sitä mieltä, että hän saa tehtyä ominaisuuden muutamassa viikossa.
Tällainen työ on kivaa, opettavaista ja mielenkiintoista koodarin kannalta, mutta liiketoimintasi kannalta tee-se-itse -toteuttaminen voi olla taloudellinen katastrofi.
Käytä tiimin aika viisaasti
En osannut ottaa asiaa huomioon silloin, mutta myöhemmin ymmärsin, että merkittävä osa tiimin työajasta kului ylläpitoon ja tarpeettomaan bugijahtiin, jolta olisimme voineet välttyä ostamalla enemmän ja koodaamalla vähemmän. Kehityksen aikana ongelmia ilmestyi liittyen itsepidettyjen palvelinten käyttöjärjestelmään ja muistiin. Skaalaaminen ylös ja alas. Ongelmiin varautumista omatekoisilla boteilla. Jopa rakastettu Kuberneteskin vaatii päivittelyä itse ylläpidettynä.
Jos olisimme vain ostaneet tarvittavat palvelut, olisimme saaneet korkealla todennäköisyydellä toiminnallisuuksia, jotka toimivat niinkuin niiden pitääkin, koska tuhannet muut olisivat jo testanneet palvelun ennen meitä. Olisimme hyötyneet suurtuotannon ekonomiasta ja säästäneet ohjelmistotiimimme kallisarvoista aikaa keskittymään arvonluontiin asiakkaillemme teknisen näpertelyn sijaan.
Vaikka ulkoisten palveluiden valinnat olisivat menneet täysin pieleen tai eivät olisi vastanneet lopulta tarpeita, integraation purkaminen ja irtisanominen on kuitenkin pientä sen rinnalla, mitä itse toteutettu tulee maksamaan. Harva palvelu maksaa tuhansia euroja kuukaudessa, kuten ohjelmistokehittäjän työaika.
Teknologiavalinnoissa turvallisuus ennen hypeä
Koodareissa on sellainen juttu, että he ovat uteliaita otuksia. Jos minulta kysyttäisiin, mitä todella haluan tehdä seuraavaksi, haluaisin upota Haskelliin ja kirjoittaa älykkäitä sopimuksia lohkoketjuun. Kollegani taas intoilevat tällä hetkellä Rustista. Tämä innostus on arvokasta oppimisen kannalta, mutta kaupallisen ohjelmistoprojektin tulisi pitäytyä mahdollisimman turvallisissa valinnoissa hallitakseen riskejä ja saadakseen projekti ajallaan maaliin.
Jokainen ylimääräinen koodirivi tuo lisää vastuuta ja riskiä. Kasvaneen työmäärän vuoksi palkattu ylimääräinen koodari on vielä kalliimpi riski. Hyviä koodareita on vaikea löytää, tunnistaa ja pitää. Vielä vaikeampi on luoda kokonaisuutena toimivaa, kyvykästä koodiorganisaatiota. Uusia tekijöitä kannattakin tämän vuoksi rekrytoida hitaasti ja harkiten.
Ylläoleviin riskeihin ja ongelmiin ei ole oikoteitä. Periaatteessa, parasta riskienhallintaa onkin välttää koodaamista.
Ota kaikki irti MVP:stäsi
Kun suunnittelet uutta toiminnallisuutta tai ohjelmistoa liiketoimintaasi, käännä jokainen kivi ennen kuin aloitat ohjelmistokehityksen. Purista kaikki ulos MVP:stäsi ja harkitse vielä kerran seuraavat kysymykset läpi.
- Oletko todella jutellut tuleville asiakkaillesi antamatta omien ennakkokäsitystesi vaikuttaa palautteeseen?
- Olethan tehnyt käyttäjätutkimuksesi?
- Oletko prototyypannut ideaasi design-työkaluilla, myös tuleville asiakkaillesi?
- Onko tuoteideasi niin uniikki ja vaativa, ettet saisi luotua sitä no-code -työkaluilla?
- Saisitko tehtyä koko palvelun tai sen osan ostettavana palveluna?
Kun kaikki kivet on käännetty ja markkinahypoteesit näyttävät vihreää, kutsu ohjelmistokehittäjät paikalle.
