Tässä energiatehokkuuden blogisarjan kirjoituksessa valotamme kokemuksiamme siitä, miten käytettävyyteen (UX) ja prosesseihin liittyvät ongelmat voivat tuoda kustannuksia ja tehottomuutta.
Softa tehdään käyttäjiä varten
Auditoinneissa tutkimme ohjelmistoa monelta eri näkökulmalta, sekä koodia lukemalla että eri sidosryhmiä haastattelemalla. Teknisen perehtymisen lisäksi on tärkeää ymmärtää miten järjestelmän tehokkuus tai tehottomuus vaikuttaa käyttäjiin ja myös ohjelmistokehittäjien sekä testaajien työhön. Heikosti suunniteltu käytettävyys voi ohjata käyttäjää tekemään esimerkiksi ylimääräisiä hakuja tai kutsuja taustajärjestelmään, mikä olisi paremmalla suunnittelulla ollut vältettävissä. Jos palvelu on työläs ja hankala käyttää, niin se todennäköisesti on työläs myös tuotekehitykselle ja testauksellekin, eli ongelmat kertautuvat. Tämä tarkoittaa tarpeettomia kuluja ja arvokkaan työajan hukkaamista.
Esimerkki: tarpeettomat haut
Käyttäjä haluaa hakea huomiselle iltapäivälle linja-autoaikataulun. Hän avaa selaimella pääsivun, jolloin tapahtuu automaattisesti ensimmäinen haku. Käyttäjä vaihtaa päiväksi huomisen, jolloin tapahtuu toinen haku. Käyttäjä asettaa tavoiteajan, jolloin vasta tapahtuu se haku jonka käyttäjä oikeasti halusi. Kaksi edellistä hakua olivat siis käyttäjän kannalta tarpeettomia.
Esimerkki: piilotettu tieto
Käyttäjä joutuu klikkailemaan sivustoa läpi pitkän aikaa löytääkseen haluamansa toiminnallisuuden, aiheuttaen turhaa kuormaa palvelimelle sekä käyttäjälle ajanhukkaa. Paremmalla käytettävyydellä haluttu toiminta voisi olla nopeammin ja vähemmällä työllä tarjolla. Tuotteen monimutkaisuus heijastuu myös esimerkiksi automaatiotesteihin, koska jokainen käyttäjältä vaadittu toimenpide joudutaan ohjelmoimaan niihin erikseen.
Voiko ohjelmistokehitysprosessikin olla energiatehoton?
Kyllä voi, ja usein onkin, jos esimerkiksi CI/CD-putket, arkkitehtuuri tai vaikka asennuksien automatisointi ei ole kunnossa. Käytännössä tämä tarkoittaa sitä, että muutosten tekeminen järjestelmään on paljon työläämpää ja hitaampaa ja siksi myös kalliimpaa kuin se voisi olla. Tämäkin on resurssien ja energian tuhlaamista.
Ohjelmistokehittäjän arjessa on valitettavan tyypillistä se, että vaikka varsinaiseen muutaman rivin koodimuutokseen kuluisi aikaa varsin vähän, niin kaikki sitä edeltävä selvitystyö ja suunnittelu, muutosten jälkeen tuleva pipelinen odottelu, testaaminen, asentaminen, korjailu ja tuotantoon vieminen vievät pahimmillaan päivätolkulla aikaa. Tämäkin on tehotonta, jos prosessia voisi nopeuttaa fiksummalla automatisoinnilla. Toisaalta on myös järjestelmiä, joissa muutoksia viedään tuotantoon asti kymmeniä kertoja päivässä, mikä tietysti vaatii järeää automatisointia testauksen, asentamisen ja palautumisenkin suhteen vikatilanteessa.
Esimerkkejä takkuavasta kehitysprosessista
- Kehittäjä saa testituloksen eli palautteen tekemästään muutoksesta tuntien viiveellä versionhallintaan viemisestä.
- Kehittäjät eivät katselmoi tai edes kommentoi toistensa tekemiä koodimuutoksia.
- CI/CD-putki ei hyödynnä välimuistia, joten paketteja haetaan toistuvasti internetistä.
- Ohjelmiston build- tai kääntämisvaihe kestää tuntikaupalla.
- …ja paljon muuta.
Auditoinnin hyödyt
Energiatehokkuusauditoinnilla saat tietoa sekä järjestelmäsi että ohjelmistokehitysprosessisi toiminnasta. Optimointi- ja parannussuositustemme tavoitteena on toki pienentää juoksevia palvelinkuluja ja CO2-päästöjä, mutta myös suoraviivaistaa ja tehostaa ohjelmistokehitystä. Taloudellisesti voi olla niinkin, että asiakkaan kannalta kaikista suurin säästö tulee juuri siitä, että hankalien prosessien ja turhien monimutkaisuuksien kanssa kamppailuun ei enää kulu niin paljoa kehittäjien arvokasta työaikaa.
Annamme parannussuositusten yhteydessä arviomme toimenpiteisiin tarvittavista työmääristä, jolloin on helpompaa arvioida että mitkä ovat ne matalimmalla roikkuvat hedelmät joihin ensimmäisenä kannattaa tarttua. Loppuraportti käydään läpi yhdessä asiakkaan ja ohjelmistokehittäjien kanssa, jolloin voimme keskustella löydöksistä ja erilaisista vaihtoehdoista. Annamme lopuksi tarjouksemme optimointityön toteuttamisesta, mutta optimointia voi lähteä tekemään vähitellen ja vaiheittain myös osana muuta ohjelmistonkehitystä.
