Ohjelmistokehityksen psykologiaa

Julkaistu 20.9.2017 14:15, kirjoittaja Juha-Pekka Tammela

Miksi projekteissa kestää? Miksi aina tulee lisätöitä ja määrittelyt menevät pieleen? Miksi toimittaja ja asiakas eivät ymmärrä toisiaan?

Olen ollut vuosia kiinnostunut käyttäytymistieteistä ja eritoten asenteista, motivaatiosta ja erilaisista kognitiivista prosesseista. Lähdin pohtimaan ohjelmistoprojektien ikuisia ongelmia ihmisen käyttäytymisen näkökulmasta.

Ohjelmistokehityksessä törmätään aina samoihin asiakkaan ja toimittajan välisiin kommunikointivaikeuksiin, koska ohjelmistot ovat kompleksisia ja niiden toiminnan ymmärtäminen on usein vaikeaa – varsinkin maallikolle. Tästä syystä tulkinnoille ja olettamuksille annetaan tilaa, mikä on erittäin vaarallista ja aiheuttaa ongelmia projektin kulkuun. Näiden ongelmien taustalla on monesti niin sanottuja kognitiivisia vinoumia (cognitive bias).

Kognitiivinen vinouma on psykologinen käsite, jolla viitataan ihmisillä esiintyviin taipumuksiin hahmottaa ja painottaa havaintojaan, tulkintojaan ja informaatiota tietyillä tavoin.  (Lähde: Wikipedia)

Annetaan helppo esimerkki, että meillä on ohjelmistokehitysprojekti, jossa tuotteelle toteutetaan paikkakunta-niminen tietokenttä/attribuutti ja järjestelmään tehdään hakutoiminnallisuus, jolla tuotetta voidaan hakea tämän attribuutin mukaan. Tämän jälkeen tuotteelle toteutetaan tarkennettu osoitekenttä, joka kirjataan kokonaisuudessaan yhteen tuotetietokenttään. Myöhemmin halutaankin lisätä postinumerokenttä osoitekentästä erikseen, jotta postinumero voidaan esittää eri kohdassa tuotesivua kuin muu osoite. Tässä vaiheessa kaikki on vielä ok ja molemmat osapuolet ovat tyytyväisiä projektiin.

Kaikki meistä tekevät asioista oletuksia ja yleistyksiä, vahingossa tai tahallaan. Kyseisessä projektissa asiakas saattaa seuraavaksi olettaa, että alkuperäisen haun pitäisi pystyä tekemään myös ristiinhakuja niin, että haetaan osoitteella ja postinumerolla yhdessä ilman, että tästä ollaan kehittäjälle lainkaan mainittu.

Tietokenttien lisääntyessä ja järjestelmän monimutkaistuessa alkavat jatkokehityksen ikuiset ongelmat. Ei tiedätä, muisteta tai ymmärretä, mitä on jo tehty ja miten yhdessä määriteltyjen ominaisuuksien tulisi toimia keskenään. Tällöin yleensä kysytään toimittajalta, miksi haku ei hae määritellyillä postinumerolla ja osoitteella, ”kun ne kerran sinne lisättiin”. Heittomerkeissä oleva lause kuvaa hyvin tapaa, jolla asiat on alun perinkin esitetty – epätarkasti, tietämättä itsekään mitä kaikkea postinumeron ja osoitekenttien erottamisella voitaisiin saada aikaan.

Tähän kohtaan liittyy ensimmäinen mentaalinen prosessi, jota voidaan kutsua vahvistamisvääristymäksi tai vahvistusharhaksi (confirmation bias).

Vahvistusharha on kognitiivinen vinouma, jossa yksilö on taipuvainen puoltamaan omia ennakkokäsityksiään tai hypoteesejaan tukevaa informaatiota. Tämän seurauksena henkilöt saattavat kerätä todisteita ja muistaa asioita valikoivasti, ja täten tulkinnasta voi tulla vääristynyt tai jopa harhautunut. (Lähde: Wikipedia)

Kyseisessä prosessissa ihminen panee merkille kaikki hänen oletustaan tukevat seikat ja vahvistaa ”oikeaa” mielipidettään näiden avulla, unohtaen samalla seikat, jotka voisivat kumota oletuksen. Toisin sanoen asiakas etsii todistuksia oletukselleen, jonka mukaan kenttien pitäisi asiakkaan mielestä toimia haussa. Tässä vaiheessa toimittjana yleensä kuulee, kuinka monta kertaa asiaa sivuttiin aikaisemmin eri keskusteluissa ja sivulauseissa.

Yleensä toimittaja pystyy ennakoimaan lisäominaisuuksien tai tietokenttien käyttötarkoituksen ja osaa esimerkiksi ottaa huomioon, että toteutettuja tietokenttiä saatettaisiin tarvita tuotesivun lisäksi myös haussa. Tällöin vältytään pahimmilta karikoilta.

Ihminen hakee luonnostaan nykyiseen tietämykseensä perustuvia todisteita ja perusteluita löytämilleen epäkohdille. Seuraavaksi asiakas nimittäin huomaa, että jälkikäteen jatkokehityksenä korjattu haku onkin toteutettu ”väärin”. Haun pitäisikin toimia ”postinumero TAI paikkakunta” eikä ”postinumero JA paikkakunta” – tyyppisesti. Hakua testatessaan asiakkaalla on syttynyt lamppu pään päällä ja hän osaa nyt perustella tietokenttien todellisen tarkoituksen haun kannalta. Asiakas kertoo kirkkain silmin, että tietysti haku määriteltiin alunperinkin niin, että tietokentillä voi hakea ristiin TAI-metodilla, käyttäen jompaankumpaan tietokenttään perustuvaa hakua, eikä niin typerästi kuin haku oli alun perin toteutettu.

Keskusteluissa tulee esiin niin sanotun kognitiivisen dissonanssin (cognitive dissonance) väheneminen, jossa ihminen korjaa omia muistikuviaan kokemuksien pohjalta.

Kognitiivinen dissonanssi on psykologian termi, jolla tarkoitetaan kahden ristiriitaisen kognition kokemista. Ihminen pyrkii vähentämään kognitiivista dissonanssia muuttamalla käyttäytymistään ja keksimällä uusia ajatuksia tai uskomuksia. (Lähde: Wikipedia)

Uuden informaation pohjalta (haku voisi toimia järkevämmin kuin nyt) asiakas muuttaa mielipidettään sovitusta määrittelystä. Negatiiviset tunteet saadaan järjestykseen vähentämällä kognitiivista dissonanssia ja asioiden vääristely näkyy myös valemuistojen (false memory) syntymisenä.

Valemuisto on muisto, joka voi kokemuksellisesti tuntua hyvinkin todelta, mutta joka todellisuudessa on osittain virheellinen tai jopa kokonaan keksitty. (Lähde: Wikipedia)

Tarpeeksi usein keskustelussa mainitut toisiinsa liittymättömät sanat muuttuvat asiakkaan mielessä ”sovituksi kokonaisuudeksi”, joka pitäisi sisällyttää toimitukseen. Sanat ”haku” ja ”postinumero” tarkoittavatkin yhtäkkiä, että haun pitää toimia myös postinumeroilla, vaikka asiasta ei ole keskusteltu aiemmin millään tavalla. Asiakas pitää kuitenkin nyt itsestään selvänä, että ”näinhän asiasta sovittiin”, unohtaen samalla koko prosessin, joka keskusteluun johti. Hän ei muista tai myönnä itselleen, että ajatteli aikaisemmin samasta asiasta eri lailla.

Tässä vaiheessa syytökset alkavat lennellä toimittajan suuntaan ja myös itsepetoksen (self deception) termi voidaan jossain tapauksissa liittää tähän mukaan.

Itsepetos on tilanne, jossa ihminen ei-tietoisesti tulkitsee todellisuutta halujensa ja toiveidensa mukaisesti vääristellen totuutta ja lopulta uskoen unelmaansa. (Lähde: Wikipedia)

Ohjelmistokehitys-casessa asiakas siis muuttaa todellisuutta ja soveltaa attribuutteja lennosta sen hetkiseen käyttötarpeeseen, unohtaen kokonaan niiden aikaisemmat käyttötarkoitukset. Asiakkaalta kysyttäessä jälkikäteen postinumerokenttää ei todellakaan tehty erottamaan postinumero tuotesivulla muusta osoitteesta, vaan nimenomaan hakua varten.

Ollaan kehitysprojektin loppusuoralla ja pitäisi aloittaa uusi testausvaihe. Arvioidaanpas tämän hetken lopputulemia: hausta tuli ihan paska, koska sillä ei voi nyt hakea oikein. Toisin sanoen määrittely meni toimittajalta ihan pieleen eivätkä he kuunnelleet, mitä haluttiin. Tekninen tasokin oli vähän niin ja näin. Kaiken lisäksi toimituksessa kesti liian pitkään.

Tässä sorrutaan niin sanottuun klassiseen lopputulosharhaan (outcome bias, taipumus arvioida prosessin laatua lopputuloksen perusteella, Lähde: Wikipedia).

Kokonaisuus ja toteutuksen toimivuus on kuitenkin aina osiensa ja siihen investoidun rahan summa. Hyvä tai huono lopputulos on ani harvoin suora seuraus yksittäisistä hyvistä tai huonoista valinnoista tai ratkaisuista. Ohjelmistokokonaisuus voi olla niin kompleksinen ja iso kokonaisuus, että jokaisen toiminnon onnistuminen kertalaakista voi olla puhdasta säkää. Syy- ja seuraussuhteet saattavat olla myös niin monimutkaisia, että kaikkia ei yksinkertaisesti osata heti alussa ottaa huomioon. Väärien syy-seuraus vinoumien kanssa ollaan tekemisissä jatkuvasti: mikä vaikutti mihinkin ja mihin suuntaan?

Syy-seuraussuhteisiin liittyy myös paljon uskomuksia ja virhepäätelmiä –  asiakas voi esimerkiksi ajatella, että toimittajan alun perin tekemä ratkaisu postinumerokentän suhteen vaikutti suoraan negatiivisesti hakumoottorin toimivuuteen. Todellisuudessa asiat eivät edes liittyneet toisiinsa. Lopputulosharhan vuoksi lopputulos on kuitenkin asiakkaan mielestä negatiivinen, oli vika missä tahansa, sillä ohjelmistoa pitäisi taas jatkokehittää/korjata ja sehän tietysti maksaa.

Dokumentoinnilla ja ennakoinnilla voidaan välttää selkeät virhetilanteet ja jotkin jatkokehityksen aiheuttamat yllätykset, mutta se vaikuttaa aina kustannuksiin: pienenkin projektin muutoksien täydellinen auki selittäminen, dokumentointi ja tulevaisuuden skenaarioiden tarkastelu voi nostaa projektin kokonaiskustannuksia huomattavasti. Lisäkustannusten osalta onkin yleensä kaksi vaihtoehtoa: tehdään tunnin lisätyö kerralla pois sen enempää kyselemättä tai tehdään kolmen tunnin konsultaatiolisäselvitys mahdollisista jatkokehityssuunnitelmista ja skenaarioista ja vältytään näin yllättäviltä lisäkustannuksilta.

Toinen jatkokehitystä ja lisätöitä aiheuttava tekijä on muutostöiden arvaamattomuus ja ajattelemattomuus. Yksinkertaisen lisäominaisuuden ohjelmointi voi olla tunnin lisätyö, mutta myöhemmässä vaiheessa pienikin tätä toimintoa koskeva ”ajatuskatko” suunnitteluvaiheessa saattaa aiheuttaa kymmenenkertaisen työmäärän. Kun alkuperäisen muutostyön vaikutuksia ei ole ajateltu loppuun asti (esim. haku-toiminto on toteutettu JA-metodilla) voidaan tulevaisuudessa joutua tekemään moninkertainen työ saman asian parissa.

”Kyllä teidän olisi pitänyt tietää” ja ”kyllä tämä olisi pitänyt osata ottaa jo huomioon, ihan puhdas maalaisjärkikin sen sanoo” ovat yleisiä asiakkaalta kuultuja kommentteja, kun jatkokehityksessä tunnin lisätyö muuttuu kahden viikon pakertamiseksi. Asiakas usein olettaa, että tänään tehty lisätyö toimii ikuisesti ja kun kuukauden päästä tehdään uusia muutostöitä, vanhojen ja uusien muutosten pitäisi edelleen rullata saumattomasti yhteen. Toimittajana emme voi kuitenkaan tietää, miten nyt tehty muutostyö, joka tehdään nykyisellä tietämyksellä ja sovittujen speksien mukaisesti, vaikuttaa tulevaisuudessa tehtäviin muutoksiin.

Toimittaja ei valitettavasti ole selvännäkijä eikä ennustaja: emme voi ottaa tulevaisuudessa tehtäviä (nyt ei-tiedossa olevia) muutoksia huomioon, kun teemme muutoksia tänään – varsinkaan jos asiakas ei osaa antaa minkäänlaista vihjettä liiketoiminnan tai järjestelmän teknisen kehityksen suunnasta. Usein ennalta-arvaamattomia lisätyöt ovat valitettavasti väistämätön osa jatkokehitystä.

En usko, että koskaan päästään tilanteeseen, jossa näitä ohjelmistoprojektin aikana esiintyviä ongelmia voitaisiin kokonaan välttää. Olemalla alansa paras asiantuntija ja tuntemalla ihmisen käyttäytymistä päästään tosin jo pitkälle.