Konsultointi - Kuinka pitää asiakas kartalla ohjelmistoprojektin etenemisestä?





Erika Bergström

17.11.2020 · 6 min

Demot ja työn visualisointi. Kaksi äärimmäisen tärkeää aihetta – tai toinen on oikeastaan aihe ja toinen työkalu hyvään lopputulokseen pääsemiseksi. Idention ohjelmistokehittäjät Sami Suo-Heikki ja Julius Rajala käsittelivät aihetta Prochat-podcastin Konsultointi-sarjassa.

Puhummeko työn visualisoinnista siinä mielessä, että jos joku palkkaa konsultin tekemään tuotetta x, niin asiakas näkee, että konsultti myös tekee tuotetta x?

– Se on aika hyvä kuvaus tälle aiheelle. Taustalla on kuitenkin myös syvempi ajatus. Tästä puhuu myös lukemamme kirja Trusted advisor. Kyseisessä kirjassa puhutaan paljon luottamuksen rakentamisesta konsultin ja asiakkaan välille.

Luottamuksen rakentaminen on päämäärä, johon haluamme päästä visualisoimalla tekemäämme työtä.

Minkälaisia työkaluja löytyy konsultin työkalupakista? Miten työn visualisointi onnistuu parhaiten?

– On paljon kokemuksia projekteista, jossa merkitään Jiraan tunteja ja katsotaan, että mikä on ollut arvio ja kuinka paljon on tehty. Silloin jotkut tekevät johtopäätöksiä niin, että nyt on tehty vaikkapa 70%. Joillekin se voi toimia, mutta minulle se ei toimi.

"Täytyy nähdä vähän pintaa syvemmälle ja ohi työkalujen, joissa katsellaan etenemistä."

Jira-tiketeillä ja tuntimerkkauksilla 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 se, että taistellaanko vaikeiden vai helppojen ongelmien kanssa. Mikäli tämä homma olisi niin yksinkertaista, niin voisimme vain katsoa GitHubista, montako riviä koodia Sami on kirjoittanut tämän päivän aikana.

– Työkalupakista löytyy siis ainakin demoaminen. Käymme läpi asiakkaalle ja tuotteesta kiinnostuneille henkilöille, että mitä olemme tehneet. Jos olen tehyt vaikkapa kaksi viikkoa uutta ominaisuutta vanhaan tuotteeseen, niin laitan ruudunjaon päälle ja näytän, miten kyseinen ominaisuus toimii tuotteessa ja miten sitä käytetään.

Kun on monta ihmistä katsomassa demoamista, niin palautetilaisuudessa voi helposti vahvistaa, ollaanko tehty oikeita vai vääriä asioita. Vaikka teknisesti jokin ominaisuus toimii, niin se ei aina tarkoita, että se tekee sitä mitä halutaan.

"Tekninen puoli ei välttämättä ole se pääasia tietyllä tavalla demonkaan tekemisessä. Jos on työskennellyt muiden koodareiden kanssa, niin demoat koodiasi kun laitat pull requestin. Heitä kiinnostaa se osuus. Kun demoat tuotetta, niin enää ei puhuta koodiriveistä."

Jos tehdään backendiä ja ominaisuus ei omaa fronttikomponentteja eli mitään visuaalista, niin miten tällaisia järjestelmiä kannattaa lähteä demoamaan niin, että siitä ei tule kiusallista komentorivisessiota?

– Hah, liian hyvä kysymys! Ajatus olisi ehkä, että jos siinä ei ole fronttia, niin bäkkijärjestelmäkin on kuitenkin tehty jotain tarkoitusta varten. Demon alussa mietitään juuri se yleisin käyttötapa kyseiselle järjestelmälle. Sen voisi esitellä niin, että miten se lähtee toimimaan tässä järjestelmässä ja mitä tapahtuu eri järjestelmissä sen aikana.

Työskentelimme aiemmin eräässä projektissa, jossa demoiltiin viikottain osaa järjestelmästä, jossa meillä ei vielä ollut mitään fronttikomponenttia. Mietimme, että miten sitä kannattaisi demota. Rakensimme siihen ympärille pientä demosysteemiä, jonka kanssa pystyttiin mokkailemaan sitä hommaa. Esimerkiksi Postman on aina hyvä työkalu.

Minkälaisia juttuja sitten kannattaa demota ja mitä ei?

– Silloin kannattaa demota, kun tulee uusi ominaisuus tai vanha ominaisuus muuttuu vahvasti. Tottakai voidaan parin viikon ajan korjata bugeja ja vähentää teknistä velkaa. Nuo ovat asioita, joita ei tarvitsisi demota. Demoaminen toimii parhaiten, kun rakennetaan uusia ominaisuuksia tai sellaista, missä meillä saattaa olla epävarmuuttakin mukana. Ei tiedetä, ollaanko samalla kartalla homman suhteen.

Olemme hyödyntäneet usein Scrumia ohjelmistoprojekteissa. Siinä sprintit ovat yleisimmin parin viikon mittaisia. On aika hyvä tapa, että sprintti päättyy sprint demoon. Sprint demossa esitellään kahden viikon välein, mitä ohjelmistoprojektissa on tehty. Kahdessa viikossa saadaan usein jo jotain näkyvää esiteltävää. Jos viikon välein tehdään demoja ja taas vähän valmistellaan demoihin, niin kehitysprosessi on äkkiä pelkkää demoamista.

Eri ihmisille voi myös pitää eri demoja. Esimerkiksi ison yrityksen toimitusjohtaja voi olla mukana kerran kuukaudessa ja muuten esitellään tiimille.

Kummasta saa enemmän tietoa siitä, kuinka paljon projektista on jäljellä: Jiran aika-arvioista vai demon järjestämisen kautta?

– Burn down chartit ovat sellaisia, joihin suhtaudun pienellä skeptisyydellä. Se saattaa johtua myös siitä, että projekteissa joiden parissa olemme työskennelleet, ei ole ollut kovin selkeää valmiin tuotteen määritelmää. Ideana ei ole ollut missään vaiheessa tuottaa mitään lopullista asiaa, joka jää sellaisekseen.

Jos tekee perus Scrumia, niin siinä tulee yleensä tuotettua tiketit jokaisessa sprint planningissa juuri kyseisen sprintin ajaksi. Niistä pystyy käytännössä seuraamaan sitä, missä vaiheessa sprinttiä mennään. Parhaimmillaan se toimii – ei niin, että seuraamme käyrää joka laskee vähitellen kohti nollaa ja valmista on – vaan niin, että meillä on Kanban-laudan tyylinen ratkaisu, josta pystymme seuraamaan sitä, mitkä asiat ovat minäkin hetkenä työn alla. Tämä vaihtelee aika paljon sen mukaan, minkälainen projekti on kyseessä.

Tuleeko demojen ja tikettien lisäksi mieleen muita tapoja, joilla voidaan pitää asiakas perillä etenemisestä?

– Sivusimme aikasemmin sitä, että kuinka usein demoja kannattaa järjestää. Meillä on ollut viikottaiset weeklyt varsinkin niissä projekteissa, joissa ei ole suoranaisesti käytetty Scrumia vaan on tehty sellaista jatkuvaa prosessia Kanban-tyylisesti. Tällaiset weekly-sessiot tuntuvat toimivan tosi hyvin siihen. Silloin on 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.

Tällaisesta ei välttämättä saa täydellistä pitkän ajan kuvaa, mutta ainakin sellaisen kohtuullisen ennustettavan parin viikon aikataulun. Näin pystytään viikottain fiksailemaan ja priorisoimaan – etenkin hyvin muuttuvassa asiakasympäristössä, jossa on paljon vaikeasti arvattavia tekijöitä.

Vielä olisi loppukevennys. Klassinen demoihin liittyvä asia on demo effect. Onko sinulla kokemusta niistä?

– Voisin väittää, että en ole elämäni aikana tehnyt yhtään demoa, jossa ei ole ollut jonkinlaista demo effectiä. Se on asia, jota ei aivan täysin voi koskaan välttää. Demo effect tarkoittaa siis sitä, että olet katsonut koneellasi, että nyt demottava asia toimii ja puolen tunnin päästä on demo. Sitten kun demoat, niin se asia ei toimikaan niin kuin sen piti.

Yleensä nämä demot tehdään lokaalissa kehitysympäristössä ja suunnilleen pari tuntia ennen demoa aletaan rakentamaan jonkinlaista demoa, joka esitellään. Siinä saattaa tulla tehtyä naiiveja oletuksia, koska demottava asia harvemmin on ihan täydellisesti loppuun asti hiottu. Kun pidetäään sprint demoja, voisi olla parempi, jos hommat olisivat tuotantokunnossa asti.

Välillä demottavassa asiassa on pientä validaatiovirhettä tai siinä vaiheessa kun kirjoitat input-kenttään jonkin asian, niin yhtäkkiä selain välähtää valkoiseksi ja errorit huutavat konsolissa. Kaikenlaisia yllätyksiä tulee vastaan ja niitä on aina hauskaa selitellä, kun asiakkaan johtoryhmä on paikalla.

"Olimme kerran tehneet fronttia ja meillä oli videopuhelu. Jaoin linkin, josta asiakas pääsee kokeilemaan sitä. Joku toinen henkilö sanoi, että ei tämä aukea ollenkaan ja on vaan valkoinen screeni. Se olikin eri selain – heillä ei ollutkaan chrome käytössä. Nämä ovat asioita, jotka pitäisi tsekata aina ennen demoa, että kai tämä toimii kaikilla selaimilla. Se vaan meinaa unohtua helposti."

"Yksi hienoimpia demoja, jonka olen tehnyt oli sellainen, jossa rakensimme soittointegraatiota yhteen järjestelmään. Olimme juuri saaneet soittojen ohjauksen järjestelmään toteutettua ja asiakasdemossa pyysimme tätä henkilöä soittamaan puhelinnumeroon. Siinä oli tällainen hauska interaktiivinen elementti, josta itse nautin kovasti. Se toi herkullista laatuvaikutelmaa."

Onko sinulla hauskoja kokemuksia demojen parissa? Kerro niistä meille! Tavoitat meidät somessa ja osoitteessa [email protected]