Ohjelmistoprojekteissa on tärkeää, että asiakkaan ja konsultin välinen kommunikaatio ja yhteistyö on sujuvaa. Siihen kuuluu oleellisesti yhteinen käsitys siitä, missä mennään.
Miten asiakas kannattaa pitää mukana projektin edetessä? Entä miten visualisoida omaa työtään?
Työn visualisointi rakentaa luottamusta
Työtä voidaan visualisoida eri tavoin ja se on usein työkalu hyvään lopputulokseen pääsemiseksi. Yksi yleinen visualisointiin käytetty tapa on Kanban, jonka avulla työtä voidaan pilkkoa pienempiin osiin ja tehdä siten projektin eri vaiheet näkyviksi. Näin työn etenemistä on myös helpompaa seurata.
Visualisoinnin taustalla on usein myös syvempi ajatus, kun kyse on ohjelmistokehitysprojektista, johon asiakas ostaa konsultointia. Aiheesta puhuu myös monien konsulttien lukema kirja The Trusted Advisor. Kirjassa korostetaan luottamuksen rakentamista konsultin ja asiakkaan välille.
Luottamus on siis päämäärä, johon haluamme päästä visualisoimalla tekemäämme työtä.
Työn visualisointi ei kerro kaikkea
Monissa ohjelmistoprojekteissa hyödynnetään Jiraa tehtävien hallintaan ja seurantaan. Jira tarjoaa monenlaisia työkaluja, kuten roadmappeja ja erilaisia raportteja, joiden avulla projektin etenemistä voidaan tarkastella. Näistä on helppo nähdä esimerkiksi se, kuinka monta prosenttia projektista on tehty.
Jira-tiketeillä ja kaavioilla on paikkansa, mutta ne eivät välttämättä anna itsessään täydellistä kuvaa työn etenemisestä. Niistä ei välttämättä välity, taistellaanko vaikeiden vai helppojen ongelmien kanssa. Mikäli seuranta olisi niin yksinkertaista, voisimme vain katsoa GitHubista päivän aikana kirjoitettujen koodirivien määrän.
Joskus projekteissa, joiden parissa olemme työskennelleet, ei ole myöskään ollut kovin selkeää valmiin tuotteen määritelmää. Ideana ei ole ollut missään vaiheessa tuottaa mitään lopullista asiaa, joka jää sellaisekseen. Tyypillisessä scrumissa tiketit tuotetaan sprint planningissa kyseisen sprintin ajaksi. Niiden avulla seurataan käytännössä sitä, missä vaiheessa sprinttiä mennään. Parhaimmillaan se toimii – ei niin, että seuraamme käyrää joka laskee vähitellen kohti nollaa, jonka jälkeen on valmista – vaan niin, että meillä on kanban-taulun tyylinen ratkaisu, josta pystymme seuraamaan mitkä asiat ovat minäkin hetkenä työn alla.
Näissä tilanteissa täytyy nähdä pintaa syvemmälle – ohi työkalujen, joissa tarkastellaan etenemistä.
Demo on yksi visualisoinnin työkalu
Konsultin työkalupakista löytyy visualisoinnin ja tehdyn työn esittelyyn myös demoaminen. Konsultti käy demossa läpi asiakkaalle ja tuotteesta kiinnostuneille henkilöille, että mitä hän on tehnyt. Jos konsultti on tehnyt esimerkiksi kaksi viikkoa uutta ominaisuutta vanhaan tuotteeseen, niin on helppoa näyttää ruudunjaon kautta, miten kyseinen ominaisuus toimii tuotteessa ja miten sitä käytetään. Tekninen puoli ei välttämättä ole pääasia demon tekemisessä. Muiden koodareiden kanssa työskennellessä pull request on keino demota koodia heille. Kun demoaa itse tuotetta, niin enää ei puhuta koodiriveistä.
Kun demoa on katsomassa monta ihmistä, niin palautetilaisuudessa voidaan helposti vahvistaa, onko tehty oikeita vai vääriä asioita. Vaikka teknisesti jokin ominaisuus toimii, niin se ei aina tarkoita, että se tekee sitä mitä halutaan.
Jos frontendiä tai visuaalista näytettävää ei ole, niin pitää muistaa, että backend on myös tehty jotain tarkoitusta varten. Backend työtä voidaan demota esimerkiksi esittelemällä testituloksia tai työllä aikaansaatua muutosta loppukäyttäjän näkökulmasta.
Minkälaisia asioita kannattaa demota ja mitä ei?
Demota kannattaa, kun tulee uusi ominaisuus tai vanha ominaisuus muuttuu vahvasti. Joskus parikin viikkoa voi hyvin vierähtää bugien korjailussa tai teknisen velan vähentämisessä. Ne ovat asioita, joita ei tarvitse demota. Demoaminen toimii parhaiten kun rakennetaan uusia ominaisuuksia tai jotain sellaista, jossa saattaa olla mukana epävarmuutta – kun ei välttämättä tiedetä, ovatko kaikki samalla kartalla asioiden suhteen.
Identiolaiset ovat hyödyntäneet usein scrumia ohjelmistoprojekteissa. Siinä sprintit ovat yleisimmin parin viikon mittaisia. On hyvä tapa, että sprintti päättyy sprint demoon. Sprint demossa esitellään kahden viikon välein, mitä projektissa on tehty. Kahdessa viikossa saadaan usein jo jotain näkyvää esiteltävää. Jos viikon välein tehdään demoja, ja väleissä valmistellaan demoja, niin kehitysprosessi on hyvin nopeasti pelkkää demoamista.
Eri ihmisille voi myös pitää eri demoja. Esimerkiksi ison yrityksen toimitusjohtaja voi olla mukana kerran kuukaudessa, mutta muuten demo esitellään tiimille.
Onko muita tapoja, joilla voidaan pitää asiakas perillä etenemisestä?
Sivusimme aikasemmin sitä, kuinka usein demoja kannattaa järjestää. Monissa projekteissa pidetään viikottaiset kokoukset, eli weekly-sessiot varsinkin silloin, jos ei käytetä scrumia vaan on tehty jatkuvaa prosessia kanbanin avulla. Tällaiset weeklyt saattavat toimivaa siihen hyvin. Pidetään aina pieni demo, jossa käydään läpi sitä, minkä parissa ollaan työskennelty viime viikko. Samalla pystytään päivittämään asiakasta siitä missä mennään, tarkistamaan suunta sekä tekemään pientä uudelleenpriorisointia.
Weeklyt ei välttämättä anna täydellistä pitkän ajan kuvaa, mutta ainakin kohtuullisen ennustettavan parin viikon aikataulun. Näin pystytään viikottain korjaamaan suuntaa ja priorisoimaan. Se on arvokasta etenkin hyvin muuttuvassa asiakasympäristössä, jossa on paljon vaikeasti arvattavia tekijöitä.
”Voisin väittää, että en ole elämäni aikana tehnyt yhtään demoa, jossa ei ole ollut jonkinlaista demoefektiä. Se on asia, jota ei aivan täysin voi koskaan välttää. Demoefekti tarkoittaa siis sitä, että olet katsonut koneellasi, että demottava asia toimii, mutta sitten kun demon aika on, niin se asia ei toimikaan niin kuin sen piti.”
– Ohjelmistoinsinööri, Identio
Lue myös miten ohjelmistoprojekti aloitetaan.
