17.11.2020

Kuinka pitää asiakas ajan tasalla ohjelmistoprojektin etenemisestä?

Teksti perustuu Prochat-podcastin jaksoon, jossa Idention ohjelmistokehittäjät Sami Suo-Heikki ja Julius Rajala käyvät läpi sitä, miten asiakas on hyvä pitää mukana projektin edetessä.


Demot ja työn visualisointi

Toinen on oikeastaan aihe ja toinen työkalu hyvään lopputulokseen pääsemiseksi. Työn visualisoinnista puhutaan myös siinä mielessä. että jos konsultti on palkattu tekemään asiaa x, niin asiakas näkee, että konsultti tosiaan tekee asiaa x. Taustalla on kuitenkin myös syvempi ajatus. Tästä puhuu myös monien konsulttien lukema 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ä.

Miten työn visualisointi onnistuu parhaiten?

On paljon projekteja, joissa tunteja merkitään Jiraan ja katsotaan, mikä on ollut arvio ja kuinka paljon on tehty. Silloin jotkut tekevät johtopäätöksiä niin, että nyt on tehty vaikkapa 70 prosenttia projektista. Joillekin se voi toimia, mutta kaikille ei.

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ä olisi yksinkertaista, niin voisimme vain katsoa GitHubista, montako riviä koodia joku on kirjoittanut tämän päivän aikana.

Konsultin työkalupakista löytyy siis ainakin demoaminen. Konsultti käy läpi asiakkaalle ja tuotteesta kiinnostuneille henkilöille, että mitä hän on tehnyt. Jos joku on tehnyt vaikkapa kaksi viikkoa uutta ominaisuutta vanhaan tuotteeseen, niin on helppoa laittaa ruudunjako päälle ja näyttää, miten kyseinen ominaisuus toimii tuotteessa ja miten sitä käytetään.

Kun demoa on katsomassa monta ihmistä, niin palautetilaisuudessa voi 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.

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. Kun demoat tuotetta, niin enää ei puhuta koodiriveistä.

Miten backendiä kannattaa demota?

Jos fronttia tai visuaalista näytettävää ei ole, niin pitää muistaa, että backend on myös tehty jotain tarkoitusta varten. Demon alussa voidaan miettiä yleisin käyttötapa kyseiselle järjestelmälle. Konsultti voi esitellä, miten se lähtee toimimaan tässä järjestelmässä ja mitä tapahtuu eri järjestelmissä sen aikana.

Työskentelin aiemmin projektissa, jossa demottiin viikottain osaa järjestelmästä, jossa ei vielä ollut fronttikomponentteja. Rakensimme siihen ympärille demosysteemin, joka kanssa pystyttiin mallintamaan haluttua asiaa. Esimerkiksi Postman on hyvä työkalu.

Minkälaisia asioita kannattaa demota ja mitä ei?

Demota kannattaa, kun tulee uusi ominaisuus tai vanha ominaisuus muuttuu vahvasti. Parin viikonkin ajan voidaan korjailla bugeja ja vähentää teknistä velkaa. Ne ovat asioita, joita ei tarvitsisi demota. Demoaminen toimii parhaiten, kun rakennetaan uusia ominaisuuksia tai sellaista, missä saattaa olla epävarmuutta mukana – ei välttämättä tiedetä, ollaanko samalla kartalla asioiden suhteen.

Identiolaiset ovat 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 chartteihin kannattaa suhtautua pienellä skeptisyydellä. Joskus 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.

Perus scrumissa tiketit tulee yleensä tuotettua sprint planningissa juuri kyseisen sprintin ajaksi. Niiden avulla 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 jonka jälkeen on valmista – vaan niin, että meillä on kanban-laudan tyylinen ratkaisu, josta pystymme seuraamaan mitkä asiat ovat minäkin hetkenä työn alla. Tämä vaihtelee aika paljon sen mukaan, minkälainen projekti on kyseessä.

Onko muita tapoja, joilla voidaan pitää asiakas perillä etenemisestä?

Sivusimme aikasemmin sitä, että kuinka usein demoja kannattaa järjestää. Monissa projekteissa on pidetty viikottaiset weeklyt varsinkin, jos ei ole suoranaisesti käytetty Scrumia vaan on tehty jatkuvaa prosessia kanban-tyylisesti. Tällaiset weekly-sessiot tuntuvat toimivan siihen hyvin. Silloin 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.

Tällaisesta ei välttämättä saa täydellistä pitkän ajan kuvaa, mutta ainakin 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ä.

Loppukevennys: klassinen demoihin liittyvä asia on demo effect. Onko konsulteillamme 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ä demot tehdään lokaalissa kehitysympäristössä ja suunnilleen pari tuntia ennen demoa aletaan rakentaa 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.”

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

Kirjoittaja

Erika Bergström

Copywriter

Kategoria

Konsultointi

Jaa Artikkeli

Share on facebook
Share on twitter
Share on linkedin


+358 40 568 4617


+358 40 568 4617

Ura meillä

Identio Prochat

Ajankohtaista