Entinen käyttöliittymäsuunnittelun opettajani on ollut yhdistämässä ihmiskeskeisen suunnittelun ja ketterän ohjelmistokehityksen menetelmiä Reaktorissa vuodesta 2005, jolloin tämä työ alkoi siellä. Myös tuoteomistaja aiemmasta projektistani työskentelee nyt samassa yrityksessä liiketoiminnan pääkonsulttina. Ehdotin heille keskustelua aiheesta, miten asiakkaiden vaatimukset huomioidaan Reaktorin prosesseissa, ja tapaamista lounaan merkeissä. Koen asian tärkeäksi muun muassa, koska asiakasvaatimusten hallinta tuntuu työläältä tämänhetkisessä, scrumia soveltavassa projektissamme. Tapasimme lounaalla, ja osallistuin myös kuukautta myöhemmin Reaktorin toiminnallisuusarkkitehtien vetämään, NordiCHI’14-konferenssin yhteydessä järjestettyyn koulutustyöpajaan.

Reaktorissa on neljä kiinnostavaa, tuotehallintaa parantavaa toimintamallia:

1. Asiakas tuoteomistajana
2. Yksi kokonaisuus kerrallaan
3. Fasilitoiva coach
4. Asiakas kertoo organisaation tavoitteet

Kolme ensimmäistä näistä toimintamalleista perustuu keskusteluumme lounaalla, neljäs entisen opettajani NordiCHI’14-työpajassa antamiin vastauksiin kysymyksiini.

Asiakas tuoteomistajana. Reaktorin ohjelmistotiimeissä ei ole sisäistä tuoteomistajan roolia, vaan asiakkaan edustaja hoitaa tuoteomistajan tehtävät. Näistä tehtävistä tärkein on priorisoida toteutettavia kokonaisuuksia, eli järjestää ne tärkeysjärjestyksen mukaan prioriteettijonoksi. Next-sarakkeen vihreät laput havainnollistavat ohjelmistokehityksen prioriteettijonon kuvassa alla. Tärkein kokonaisuus, joka on suunnittelun puolesta valmis toteutettavaksi, on ylimpänä. Jotkut kokonaisuudet edellyttävät vuorovaikutussuunnittelua, ennen kuin ne voidaan siirtää kehityksen työjonoon. Tällaiset kokonaisuudet esitetään punaisina lappuina next-sarakkeessa. Jos projektissa on asiakkaana monta eri organisaatiota, tuoteomistajana voi toimia johtoryhmä, joka koostuu eri asiakasorganisaatioiden edustajista. Asiakkaan, tai asiakkaiden, tärkeimpänä pitämä kokonaisuus otetaan kulloinkin seuraavaksi työn alle.

Yksi kokonaisuus kerrallaan. Koko ohjelmistotiimi kehittää yhdessä yhtä ja samaa kokonaisuutta (engl. epic). Tämä ajatus on peräisin kanbanista. In progress -sarakkeen vihreät laput ovat työn alla olevia kokonaisuuksia. Pienemmät, keltaiset laput ovat kokonaisuuteen sisältyviä tehtäviä. Kerralla toteutettava kokonaisuus on laajuudeltaan tyypillisesti noin neljä päivää kalenteriaikaa toteutusta koko tiimiltä, joskus ehkä vain päivän, joskus kaksi viikkoa. Kokonaisuuksia ei pakoteta vakioituun ”sprintin” mittaan, koska sprinttimitoitus edellyttäisi tarkkoja työmääräarvioita, joiden laatimista ei ole koettu tuottavaksi työmäärän ja saadut hyödyt huomioiden.

Fasilitoiva coach. Reaktorissa kehitystiimi vastaa monista ohjelmistoprojektissa tarvittavista päätöksistä yhdessä. Organisaatiopsykologian mukaan tällaisille vähän johdetuille tiimeille on tyypillistä, että päätöksenteon ristiriitatilanteissa asiantuntijoiden välille muodostuu näkemyseroja, jotka kasautuvat jännitteiksi henkilösuhteisiin, koska päätöksenteon roolit ovat epäselviä. Reaktorissa tiimiin pyritään aina saamaan mukaan ”fasilitoiva coach”, jonka tehtävänä on auttaa tahoja, joilla on keskenään ristiriitaiset käsitykset jostakin asiasta, löytämään yhteinen näkemys (”make it happen”). Fasilitoiva coach johtaa keskustelua ja valmentaa muita, mutta ei osallistu työhön ohjelmistokehittäjänä eikä suunnittelijana, eikä myöskään ole johtaja, joka itse tekisi päätökset. Reaktorissa työskennellään yleensä kanbanissa eikä scrumissa, ja fasilitoiva coach tavallaan korvaa scrum masterin.

Asiakas kertoo organisaation tavoitteet. Entisen opettajani ”unelmien tuoteomistajalla” olisi selvä näkemys, mitkä kokonaisuudet ovat tärkeitä organisaation taloudellisten ja muiden tavoitteiden kannalta, eli palvelun ansaintalogiikasta. Tuoteomistajana toimivan asiakkaan edustajan ei tarvitsisi kilpailla Reaktorin tiimin kanssa käyttäjien arjen tuntemuksessa, koska käyttäjäymmärrystä kertyy perinteisissä asiakasorganisaatioissa yleensä vähemmän perusteellisilla menetelmillä kuin Reaktorissa tehtävä ihmiskeskeinen suunnittelu.

Kokonaisuuksien priorisointi oli kiinnostavassa asemassa, kun palvelu oli siirtynyt tuotantoon esimerkkiprojektissa, jota entinen opettajani esitteli NordiCHI’14-koulutustyöpajassa. Koska käyttäjien ja asiakkaiden toimintaympäristö muuttuu uuden palvelun käyttöönoton myötä, myös heidän toiminnalliset, palveluun kohdistuvat tarpeensa muuttuvat. Nämä tarpeiden muutokset kyetään huomioimaan syklisessä palvelukehityksessä (kuva yllä). Kun esimerkkipalvelu oli viety tuotantoon, nostettiin ohi muun prioriteettijonon kolme kokonaisuutta, jotka edistivät organisaatiotavoitteen ”uuden ohjelmiston laajamittainen käyttöönotto” toteutumista. Kenttätutkimuksissa oli seurattu käyttöönoton etenemistä ja haastateltu tahoja, jotka eivät olleet vielä ottaneet palvelua käyttöönsä. Kun tämän organisaatiotavoitteen kannalta tärkeät kokonaisuudet oli saatu tehtyä, tehtiin kokonaisuuksia, jotka edistivät käyttäjien tavoitteiden saavuttamista.

Käyn seuraavaksi läpi artikkelin alussa listaamani toimintamallit arvioiden, mitkä niistä olisivat hyödyksi omassa, tämänhetkisessä toimintaympäristössäni. Henkilökohtainen kiinnostukseni tuotehallintaanhan lähtee siitä, että olen päätynyt suunnittelijana ketterän kehityksen projekteissa olemaan ”prosessin joka vaiheessa” samanaikaisesti, mikä lisää työn kuormittavuutta ja pitkään jatkuessaan vähentää työssä jaksamista sekä tuottavuutta. Esimerkiksi kahden päivän aikana olen ollut mukana suunnittelemassa töitä pidemmällä aikavälillä, kuuntelemassa käytettävyystutkimuksen palautetta toteutustehtäviä poimien, toteuttanut prototyyppiä javascriptillä, suunnitellut parannuksia tuotantoversion käyttäjäkyselyyn ja kirjoittanut tarjouspyyntöä käyttäjätutkimukselle. Työtehtäviä oli eri puolilta suunnittelun ympäriltä, mutta varsinaista suunnittelua ei oikeastaan juurikaan.

Malli ”asiakas tuoteomistajana” näyttäisi ehkäisevän tehokkaasti ”rikkinäistä puhelinta” prioriteettien viestinnässä, eivätkä tilanteet, joissa jokin asiakkaan toive jää jostain syystä toteutumatta, aiheuta siinä kielteistä mielikuvaa palvelun tarjoajalle. Asiakkaiden erisuuntaiset pyynnöt vähenisivät, timiltä kuluisi vähemmän aikaa asiakasvaatimusten pähkäilyyn ja jäisi enemmän aikaa toteutukselle, mitä kautta myös suunnittelijan rooli voisi yksinkertaistua. Tuoteomistajan tarvitsisi kuitenkin nähdäkseni osallistua vaatimustenhallinnan arkeen viikkotasolla, jotta suunnittelijan työnkuva selkiytyisi, eikä näin aktiivista osallistumista liene realistista odottaa nykyisen projektimme asiakkailta. Erityyppisistä asiakkaista koostuva ohjausryhmä vaikuttaisi kyllä hyvältä ratkaisulta meidänkin projektissamme, mutta meillä on jo useampikin vastaava elin, jotka ovat käytännössä liian raskaita ollakseen viikkotasolla mukana projektin tuotehallinnassa.

Mallit ”yksi kokonaisuus kerrallaan” ja ”fasilitoiva coach” helpottanevat suunnittelijan työtä ketterissä ohjelmistokehitysprojekteissa suoraan. Kun koko projektissa on ”vähemmän palloja ilmassa”, myös suunnittelijoille kasaantuu vähemmän rinnakkaisia työtehtäviä. Ihmiskeskeistä suunnittelua tuntevasta ”fasilitoivasta coachista” olisi apua laajojen ja pienempienkin kokonaisuuksien suunnittelussa, koska tämä työ on risteävien vaatimusten ja tarpeiden yhteensovittamista.

Kokonaisuuksien tasolla tapahtuva priorisointi on yhtenä lähtökohtana malleissa ”kokonaisuus kerrallaan”, ”asiakas kertoo organisaation tavoitteet” ja ”asiakas tuoteomistajana”. Kehittämäämme palveluun on kuitenkin tarvetta toteuttaa nopeasti myös yksittäisiä palvelupyyntöjä, jotka koskevat jo tuotannossa olevia kokonaisuuksia. Tällaisilta irrallisilta tehtäviltä lienee vaikea välttyä, kun kehitetään alustaa, joka on jo tuotannossa. Tuotannossa oleviin kokonaisuuksiin liittyvät tehtävät voitaisiin vaikkapa esittää pieninä, oransseina lappuina, joiden käsittelyyn olisi omat käytäntönsä.

Toimintamalli ”asiakas kertoo organisaation tavoitteet” yhdistää tehokkaasti elinkelpoisuuden (engl. viability), haluttavuuden (engl. desirability) ja toteutettavuuden (engl. feasibility) näkökulmat, ja helpottaisi ihmiskeskeisen suunnittelun arkea omassa ympäristössäni. Asiakkaan edustaja ilmaisee organisaatiotavoitteet vapaamuotoisesti. Kun asiakas ehdottaa ratkaisumallia, ei kuitenkaan keskitytä hänen sanoihinsa, vaan pyritään kuuntelemaan toiminnallisia tarpeita, joita ehdotettu ratkaisu voisi palvella, ”sanojen takana”. Tässä kohtaa ihmiskeskeisen suunnittelun, palveluajattelun ja käyttäjätutkimuksen lähestymistavat soveltuvat mielestäni paitsi käyttäjien myös asiakkaiden ymmärtämiseen. Kun eri puolilla ehdotetut, samaa tai samankaltaista tarvetta palvelevat ratkaisumallit saadaan redusoitua yhdeksi toiminnalliseksi kokonaisuudeksi, helpottuu paitsi ihmiskeskeinen suunnittelu, myös ohjelmistokehitys. Tarvittavat kokonaisuudet saadaan toteutettua vähemmillä resursseilla, mutta valmiit toteutukset ovat silti asiakkaille elinkelpoisia ja käyttäjille haluttavia.