Et ikinä usko mitkä kolme asiaa menevät pieleen Vincitin asiakasprojekteissa!


Kohta kaksi saa purkan pysähtymään suussasi!

Säännölliset retrospektiivit kuuluvat käytänteisiimme asiakasprojekteissa. Niissä pohditaan yhdessä asiakkaan kanssa tapoja parantaa työskentelyämme projektin ulkopuolisen fasilitaattorin vetämänä. Pidimme hiljattain fasilitointitiimin voimin session, jossa kävimme läpi yleisimpiä ongelmia, joita retroissa nousee esille.

1. Visio puuttuu

Kalleimmat ominaisuudet ovat ne, joita on intohimolla nysvätty, mutta joita kukaan ei käytä. Riski tällaisten määrittelylle ja toteutukselle kasvaa huomattavasti jos työn visio ei ole selkeä. Puuttuva visio aiheuttaa sen, että koko tiimi ei tiedä tarkalleen minne ollaan menossa ja miksi tuotetta tehdään.

Hyvä visio kertoo miten haluamme muuttaa käyttäjiemme maailmaa ja miten haluamme muokata liiketoimintaamme. Hyvään visioon on helppo palata kun tehdään päätöksiä työn sisältöön liittyen. Kun tiedetään mihin ollaan menossa, on matkan varrella huomattavasti helpompaa miettiä mitä pitää tehdä jotta sinne päästään. Kuitenkin liian usein projektien alussa tämä laiminlyödään ja siirrytään puhumaan ominaisuuksista ja siitä miltä tuotteen tulee näyttää.

Vision puuttumisen oireita ovat esimerkiksi

  1. Priorisointi on vaikeaa, koska jokaisella on oma näkemyksensä suunnasta.
  2. Työssä tärkeimmäksi muodostuvat käytetyt teknologiat ja tekninen laatu, koska syvempää motivaatiota on vaikea löytää kun ei ymmärretä miten työ auttaa liiketoimintaa ja käyttäjiä.
  3. Roadmapin ja askelmerkkien suunnittelu on vaikeaa. Työssä ollaan enemmänkin reagoimassa ja tekemässä pieniä viilauksia

Onneksi vision puuttuminen on helppoa korjata. Projektin kickoff on luonnollisesti paras paikka varmistaa, että koko tiimi ymmärtää miksi työhön ryhdytään. Jos Kickoff on jo pidetty, ei vaiheessa olevassakaan projektissa ole kuitenkaan myöhäistä palata pohtimaan visiota. Vision luomisessa ja hienosäätämisessä voit käyttää apuna kysymyksiä:

  • Kuinka maailma, liiketoimintamme ja käyttäjiemme/asiakkaidemme maailma muuttuu paremmaksi tämän tuotteen/palvelun myötä?
  • Kuinka tämä tuote/palvelu vaikuttaa liiketoimintaamme kun se on valmistunut?
  • Mihin osiin markkinoitamme ja ympäristöämme tämä tuote/palvelu vaikuttaa ja miten?
  • Mitä muutoksia työn voi aiheuttaa asiakasprosesseihimme tai sisäisiin prosesseihimme?
  • Mihin osiin yritystämme tuote/palvelu vaikuttaa?
  • Kuinka tunnistamme yllä mainitut vaikutukset ja muutokset?

Projektien aloittamiseen on muuten loistavaa luettavaa Diana Larsenin kirja Liftoff: Launching Agile Teams & Projects, josta yllä olevat kysymyksetkin on referoitu.

2. Paskat speksit

Paskat speksit, eli määrittelyt aiheuttavat väärinkäsityksiä ja turhaa työtä sekä keskeytyksiä työntekoon kun epäselvyyksiä pitää selvitellä kesken sen parhaan koodausflown. Pahimmillaan väärinkäsitysten vuoksi tehdään kokonaan vääriä asioita, joita pitää paikkailla jälkikäteen.

Tyypillisesti määrittelyssä menee pieleen se, että sitä tehdään kerroksittain. Eli speksataan työtä esimerkiksi näkymä kerrallaan. Näkymän tai käyttöliittymäkuvan perusteella pohditaan taustalle tekninen toteutus ja vaadittu logiikka. Tällä tavoin työ saadaan kyllä tehtyä, mutta ymmärrys siitä miksi se tehdään jää monesti vajavaiseksi. Hyvä speksi kertoo

  • Kenelle tätä tehdään?
  • Mitä käyttäjä haluaa tehdä käyttäessään toimintoa?
  • Mitä arvoa toiminnon suorittaminen käyttäjälle tuottaa?

Ketterässä ohjelmistokehityksessä on tähän ihan valmiiksi keksitty ratkaisu: käyttäjätarinat. Käyttäjätarina kirjoitetaan muotoon:
[käyttäjärooli] :ssa haluan [mitä haluan tehdä?], jotta voin [mitä haluan saavuttaa tekemiselläni].

Esimerkki:
"Vincit blogin adminina haluan saada Slackiin notifikaation uusista ennakkokatseltavista blogiteksteistä ja sallia niiden julkaisut vasta hyväksyntäni jälkeen, jotta kuka tahansa apina ei voi tahrata firman mainetta typerillä listoilla ohjelmistoprojektien ongelmista."

Hyvä käyttäjätarina ohjaa suunnittelemaan työtä toiminnoittain, ei teknisinä palasina kuten tietomallina, käyttöliittymänä tai rajapintoina. Näin varmistetaan, että valmis käyttäjätarina tuottaa jonkin käytettävän ja kokonaisen lisäyksen ohjelmiston toimintoihin.

Mikäli yksittäinen käyttäjätarina vaikuttaa isolta, se kannattaa pilkkoa pienempiin. Jos jokin raja pitää vetää, niin jos perstuntumalla käyttäjätarinan tekeminen kestää yli viikon on syytä pohtia pilkkomista. Yksi hyvä tapa etsiä pilkottavia kohteita on liitossanojen kuten "ja" sekä "tai" etsiminen käyttäjätarinoista. Yllä olevasta esimerkistäkin yksi sellainen löytyy ja sen perusteella voisi harkita pilkkomista:

  • "Vincit blogin adminina haluan saada Slackiin notifikaation uusista ennakkokatseltavista blogiteksteistä, jotta minulta ei jää huomaamatta uusien tekstien syntyminen ja voin nopeammin reagoida palautteeseen."
  • "Vincit blogin adminina haluan sallia uusien blogitekstien julkaisut vasta hyväksyntäni jälkeen, jotta kuka tahansa apina ei voi tahrata firman mainetta typerillä listoilla ohjelmistoprojektien ongelmista."

3. Käyttäjäpalaute puuttuu

Jos tiimiltä puuttuu kontaktit asiakkaisiin, on heidän toiveidensa täyttäminen vaikeaa. Julkaisun jälkeen tiimi ei tiedä mistä toiminnoista käyttäjät pitävät, mitä he käyttävät ja mikä softassa toimii. Priorisointi pohjautuu arvailuun, intuitioon sekä siihen mikä on nopeaa ja helppoa tehdä.

Heti alkuun on hyvä ymmärtää, että vaikka tiimi pitää ideoitaan hyvinä, eivät käyttäjät välttämättä ole samaa mieltä. Kaikki ideat ovat hypoteeseja siihen saakka, että niiden toimivuudesta on saatu vahvistus käyttäjiltä. Työkaluina käyttäjäpalautteen saamiseksi mahdollisimman aikaisin voi käyttää vaikka:

  • Tee prototyyppejä, joita testautat käyttäjillä.
  • Haastattele käyttäjiä.
  • Suunnittele analytiikka, joka mittaa miten käyttäjät tuotettasi käyttävät. Mieti mitä haluat käyttäjien tekevän ja mittaa konversiota siihen.
  • Jos toteutettava toiminto on suuri, mieti voidaanko sitä ensin testata esim. kovakoodaamalla kaikki mahdollinen taustajärjestelmään. Jos homma toimii, kuten hypoteesissa oletit, tee vasta sitten toiminto "oikein".
  • Mieti priorisoinnissa etupäässä sitä mitkä toiminnot tuottavat eniten arvoa, ei sitä mitkä ovat helpoimpia toteuttaa.

Jos luet yhden kirjan tuotteiden validointiin ja käyttäjäpalautteen hankkimiseen, Eric Riesin klassikko The Lean Startup on mainio. Herran muukin tuotanto on kyllä tutustumisen arvoista.

Fasilitoijien sessiossa nousi esiin toki muitakin aiheita, mutta top-3 olivat yllämainitut. Jos lista olisi top-10, sijoilta 4. - 10. löytyvät

  • Roolitukset
  • Jatkuva parantaminen
  • Laadusta tinkiminen kiireessä
  • Kommunikaatio
  • Liiketoiminnalliset tavoitteet
  • Päätökset ja priorisointi
  • Toimintatavat

Softan tekeminen vaatii siis toki kovaa asiantuntijuutta suunnittelussa ja ohjelmoinnissa, mutta isoimmat onnistumiset - ja myös epäonnistumiset - saadaan ihmisten keskinäisellä yhteistyöllä.

Juha Riippi

Juha Riippi

Liity keskusteluun