Auditointi ilman tekijöiden haastattelua on ohuella jäällä

Auditointeja tarvitaan monesti järjestelmien tilan selvittämiseen ja tiekartan määrittämiseen. Muiden tekemän koodin arvosteleminen on usein seniorikehittäjille kutkuttavaa, mutta inhimillinen analyysi – mm. kehittäjien haastattelu – jää helposti tekemättä. Yli 200 järjestelmän auditoinnin kokemuksella väitän, että auditointi ilman haastattelua ontuu pahasti.

Kun asiakas toivoo järjestelmää auditoitavaksi, asiat ovat harvoin kunnossa. Tietoturvan tarkastaminen voi vielä olla rutiininomaista toimintaa, mutta silloin kun paikalle tarvitaan ”kilpaileva tekijä” arvioimaan laatua, taustalla on yleensä tietty selkeä huoli. Vuosien varrella selvityshommiin on päädytty mm. projektikatastrofien, toimittajanvaihdosten, yrityskauppojen, oikeudenkäyntien ja jopa kuolemien seurauksena.

Teknisellä asiantuntijalla on houkutus arvioida järjestelmiä katsomalla sovellusta, dokumentaatiota ja lähdekoodia. Nämä ovat yleensä tarkastelijan ominta asiantuntemusta – selkeitä konkreettisia tuotoksia, joiden arviointi onnistuu omassa rauhassa objektiivisesti. Harmi vain, että monesti näennäisobjektiivinen arvio ei ole asiakkaalle ollenkaan niin hyödyllinen kuin mitä kuvittelisi.

Kehittäjä tietää paljon, vaikkei ole aina oikeassa

Järjestelmät syntyvät aina poliittisten, liiketoiminnallisten ja teknologisten tekijöiden yhteisvaikutuksessa. Kertovatko huonot yksikkötestit tiimin osaamattomuudesta, koodin liian nopeasta muutosvauhdista vai epäonnistuneesta resursoinnista? Onko ontuva datamalli seurausta kriittisellä hetkellä tapahtuneesta henkilövaihdoksesta, vai onko speksi muuttunut matkan varrella? Testiympäristö on kelvoton, mutta johtuuko se aikataulupaineesta, DevOps-kompetenssin puutteesta vai projektille liian tiukasta pilvihallintamallista?

Kaikki edellä kuvatut kysymykset ovat todellisia, käytännön auditoinneissa vastaan tulleita ongelmatilanteita – ja mm. kaikki nämä vastaukset ovat olleet vuoroin oikeita, välillä myös useampi yhtä aikaa. Lähdekoodia ja sovellusta katsomalla on vaikea nähdä vastauksia, mutta kehittäjät kyllä kertovat. Kun heitä haastaa näillä kysymyksillä, puhe suorastaan pulppuaa: ”No eihän me olisi haluttu sitä noin tehdä, mutta kun…”

Kehittäjien haastattelu ei kuitenkaan kaikkia auditoijia houkuta. Omien ja toisten laatukäsitysten vertaileminen voi tuntua vaikealta. ”Korkeammaksi asiantuntijaksi” asettautuminen saattaa ahdistaa suurestikin. Kokemus on kuitenkin osoittanut, että uteliaaseen ja ystävälliseen auditoijaan suhtaudutaan lähes aina rakentavasti ja avoimesti. Näin saatu lisätieto antaa perspektiiviä, joka parantaa auditointilausuntoa huomattavasti.

Menneellä on tapana toistua

Kun auditoitava koodi tuntuu eeppisen töhnäiseltä tunkilta, on helppo lausua jotain ”sovelluksen riittämättömästä laadusta” ja suositella uudelleenkirjoitusta. Uudelleen tekeminen on kuitenkin helposti samojen virheiden toistamista, sillä ympäristötekijät istuvat syvässä. Oliko kyse varmasti tekijöiden osaamattomuudesta, vai oliko tavoite realistinen alun perinkään? Olivatko liiketoiminnan tahtotila ja tekniset reunaehdot selkeät riittävän aikaisin, vai oliko vesiputoukseksi kuviteltu projekti yhtä ainoaa muutostyötä? Jos kyse todella oli tekijöiden huonoudesta, miksi se huomattiin vasta niin myöhään?

Kaikkiin näihin kysymyksiin saa parhaiten lisävaloa, kun kuuntelee ihmisiä, jotka ovat projektia oikeasti tehneet. Asiakkaan hyväksyntätestaaja paljastaa täydentäneensä speksiä vielä julkaisuviikolla, turhautunut devaaja kertoo miten verkkoyhteyksien auki saamiseen kului puolet projektista, ja designer manaa saavutettavuusvaatimusten lisäämistä scopeen siinä suunnilleen kahdeksannen sprintin kohdalla. Yhtäkkiä sietämätön sotku alkaakin näyttää taidokkaasti tehdyltä hätäpelastukselta, ja karmea kura hahmottuukin kelvollisena MVP-saviveistoksena.

Hyvä auditoija ei arvioi pelkkää koodia, koska asiakas ei tarvitse pelkkää koodia. Asiakas tarvitsee toimivan järjestelmän, joka yleensä sisältää teknisen ratkaisun lisäksi vähintään jaettua osaamista, ylläpitomallia, ihmissuhteita ja työtapoja. Vaikka auditoijan tehtävänä ei välttämättä olekaan ihmissuhteiden evaluointi, käytännössä auditoijan näkökulma näistäkin asioista tuo keskusteluun aina jotain uutta – usein sellaista, joka auttaa tulevien projektien onnistumisessa selvästi enemmän kuin tekniset havainnot koodista.

Miksi tasapainoisella esityksellä on väliä?

Auditoijan valta on pehmeää, mutta monesti yllättävän sitkeää. Vanhoihin auditointiraportteihin saatetaan viitata vuosien päästä, ja niillä voidaan perustella varsin monenlaisia ratkaisuja. Eri lukijat näkevät raportissa myös hyvin erilaisia puolia: yksi kiinnittää huomiota teknisiin laatutekijöihin, toinen taas hahmottaa raportista ostamisen prosessien ongelmia. Auditoijalla on suuri vastuu asetella sanansa niin, että oikeat asiat ja näkökulmat tulevat esiin tasapainoisesti.

Asetelma ulottuu myös asiakkaan vastuuseen tilaajana. Auditoinnin voi tilata tarkoitushakuisesti, esimerkiksi toimeksiannolla ”Voisitko luetteloida järjestelmän virheet reklamaatiota varten”. Tämäkin voi olla hyvin tärkeä ja merkityksellinen toimeksianto. Viisas auditoija kirjaa kuitenkin raporttiinsa selkeästi, millä toimeksiannolla ja lähdeaineistolla arviot on tehty, jotta jälkitulkintojen pahimmilta virheiltä vältytään. Ihmisten kuunteleminen on yksi parhaita tapoja ymmärtää se, mitä kaikkea pitäisi ylipäätään auditoinnissa selvittää!

Pahimmillaan huonosti kirjoitettu auditointiraportti johtaa järjettömiin päätöksiin. Kaikista suosituksista helpoin on aina ”korvatkaa järjestelmä uudella”, koska sen kanssa voi esittää – mahdollisesti myös oman yrityksen tarjoamaan sopivan – ihanan modernin teknologiasuunnitelman, joka luonnollisesti ratkaisee kaikki ongelmat.

Viisas asiakas haluaa laajojen roadmap-päätösten perusteeksi sellaisen auditoinnin, jossa järjestelmästä on nähty nykytilan lisäksi myös ne syyt, miksi nykytilaan on päädytty. Jos uudelleenkirjoitusta on pakko suositella, pitäisi myös osata kertoa, miten edelliset virheet vältetään.

Lisää aiheesta