Mikä siinä skooppauksessa voi olla niin vaikeaa?

Keskustelut skooppauksesta eli toteutuksen kokonaislaajudesta voivat olla haastavia. Ne ovat myös jotakuinkin jatkuva osa tuotekehitystä, sillä skooppausta tapahtuu niin suurissa kuin pienissä muutoksissa. Usein yhdestä näkökulmasta yksinkertainen asia voi paljastua yllättävän monimutkaiseksi toisesta näkökulmasta. Yhden ominaisuuden toteutuva vaikutus ja sen todellinen monimutkaisuus ovat kuin sipuli, jonka eri kerroksilla toteutetut valinnat ratkaisevat, onnistuuko toivotun vaikutuksen saavuttaminen ja kuinka suuri kokonaistyömäärä systeemissä muodostuu. Pelkästään tekniseen toteutukseen liittyy paljon valintoja ja pohdintaa, jotka voivat lisätä tai vähentää toteutettavan ominaisuuden tai tuotteen monimutkaisuutta. Kun yhtälöön lisätään vielä liiketoimintanäkökulma tulee sipuliin vielä lisäkerroksia.

Erään tiukan skooppikeskustelun innoittamana piirsin taannoin "mutkikkuuden sipulin", josta yleiseen muotoon muokattu versio alla. Hahmotuksen tavoite oli auttaa meitä yhdessä pohtimaan muutoksen kokonaistyömäärää systeemissä ja siten muutoksen "todellista mutkikkuutta".

Ominaisuuden mutkikkuus ja liiketoimintavaikutus

Tuossa taannoisessa keskustelussa nousi korostetusti esille tavoite saada kehitysputkesta ulos mahdollisimman pieniä palasia mahdollisimman nopeasti. Tämä onkin monessa tapauksessa todella fiksua. Skooppauksessa on tosiaan tärkeää varmistaa, ettei kokonaisuutta kasvateta liian suureksi ja jäädä askartelemaan asioita hyllylle vanhentumaan. Jos ympäristö on yksinkertainen ja muutosviestinnän tarve on pieni, on todennäköisesti hyvinkin fiksua viedä paljon pieniä muutoksia ulos tiuhalla tahdilla.

Ongelmia kuitenkin syntyy, jos keskitytään liikaa yksittäisten palasten tuottamiseen ja unohdetaan palasten merkitys asiakkaalle ja niiden vaikutus systeemiin. Tuotantoon viedystä palasesta on iloa vasta kun se auttaa ratkomaan asiakkaalle merkityksellistä ongelmaa. Jos huomioidaan asiakasnäkökulma ja tavoiteltu liiketoimintavaikutus, voi olla viisasta lisätä hetkellisesti työmäärää viemällä pienempiä palasia tuotantoon piilotetusti ja tehdä lanseeraus useamman palasen suuremmalla skoopilla. Skooppi kannattaa kuitenkin yhä pitää tiukkana, jotta saadaan mahdollisimman nopeasti palautetta tehdyistä ratkaisuista.

Fiksut skooppausäätökset ovat siis tilannesidonnaisia, ne huomioivat koko systeemin ja pitemmän aikajänteen vaikutukset. No mitkä asiat sitten vaikuttavat siihen onko jokin palanen ylipäätään pieni vai suuri? Entä kannattaako asiakkaalle asti vielä yksittäinen palanen vai useamman palan setti kerrallaan? Käydään läpi sipulin kerroksia pintaraapaisuna:

Tekninen ydin: eri tuotteet voivat olla aivan eri tasolla teknisessä monimutkaisuudessa yksin kokonsa, luonteensa ja toimintaympäristönsä vuoksi. Teknisen ytimen monimutkaisuuteen vaikuttaa tietysti tuotteen ominaisuudet ja asiakasryhmien kirjo, mutta myös tuotteen historia ja aikaisemmin tehdyt valinnat. Pahimmillaan vuosien varrella tehdyt valinnat ovat aiheuttaneet tuotteeseen turhaa monimutkaisuutta siinä määrin, että kaikki muutokset ovat alkaneet muuttua hankaliksi. Tähän liittyy yksi klassisista skooppikeskusteluista, eli pohdintaan siitä kuinka paljon korjailua ja uudistusta otetaan mukaan skooppiin vai otetaanko ollenkaan. Oikeaa vastausta tähän kysymykseen ei ole, vaan kaikki riippuu kontekstista. Aiheen syvällisempi avaaminen vaatisikin ihan oman kirjoituksensa.

Läpileikkaavuus: yksittäinen ominaisuus tai suunniteltu muutos voi olla hyvinkin paikallinen tai vaikuttaa laajasti komponentteihin, käyttöliittymiin tai rajapintoihin. Aina tämä mutkikkuus ei ole missään suhteessa asiakkaalle näkyvän muutoksen koon kanssa. Joskus "pikku fiksi" tai muutos voi todella olla pieni, mutta erityisesti, jos vaikutukset ulottuvat ulkoisiin rajapintoihin voi pienikin asia olla koko systeemin tasolla yllättävän suuri.

Prosessivaikutus: mitä monimutkaisemmassa ympäristössä toimitaan ja mitä enemmän tuotteella on erilaisia käyttäjäryhmiä, sitä työläämpiä ja hitaampia voivat prosessimuutokset olla. Prosessivaikutuksia voi olla niin yrityksen sisäisiä kuin sidosryhmien tai asiakkaiden prosessivaikutuksia. Sisäiset prosessivaikutukset voivat jo yksin olla suuria, mutta niiden toteuttaminen on kuitenkin yrityksen omissa käsissä ja siten helpompaa. Jos taas muutos vaikuttaa asiakkaiden tai sidosryhmien prosesseihin, vaaditaan yleensä runsas määrä muutosviestintää. Jos prosessimuutoksia on runsaasti on tuskin järkevää pilkkoa muutoksia kovin pieniin palasiin ja pommittaa asiakasta jatkuvalla muutosviestinnnällä.

Valittu toteutus: tällä kerroksella sisemmät sipulin kerrokset kohtaavat ulommat. Ymmärrys tavoitellusta liiketoimintavaikutuksesta ja muutosviestinnän tarpeesta auttaa tekemään hyviä päätöksiä skoopista ja viemään valittua toteutusta oikeaan suuntaan. Valittu toteutus on täynnä eritason skooppauspäätöksiä. Huolimatta siitä kuinka tietoista pohdintaa näistä asioista tehdään ratkaisevat valitut tekniset-, prosessi-, ja käyttöliittymädesignratkaisut yhdessä sen kuinka suuri kokonaismuutos on ja onko halutun liiketoimintavaikutuksen saavuttamiselle olemassa onnistumisen mahdollisuudet.

Muutosviestintä: Mitä enemmän skoopissa on muutoksia, jotka vaikuttavat asiakkaiden ja sidosryhmien prosesseihin, sitä suurempi on muutosviestinnän tarve. Muutosviestintällä tarkoitetaan tässä mm. mahdollista sisäistä koulutusta, asiakaspalvelulle syntyvää kuormaa, käyttäjien-, asiakkaiden ja sidosryhmien koulutusta sekä markkinoinnin ja viestinnän tarpeita ja materiaalien muutoksia. Hyvät ratkaisut valitussa toteutuksessa pyrkivät minimoimaan synnytettävää “selityskuormaa”. Mutkikkaassa ympäristössä hyvätkään ratkaisut eivät poista tarvetta viestiä muutoksesta.

Liiketoimintavaikutus: fiksut päätökset aiemmilla kerroksilla ja onnistunut muutosviestintä mahdollistavat positiivisen liiketoimintavaikutuksen. Käytännössä sen millaiseksi liiketoimintavaikutus muodostuu, ratkaisee asiakkaiden kokemus hyödystä, helppoudesta, laadusta ja lupauksen toteutumisesta. Lopulliseen liiketoimintavaikutukseen vaikuttaa myös tehtyjen valintojen vaikutus tiimin tulevaan kehitysnopeuteen. Jos valinnoissa ollaan menty metsään, voi liiketoimintavaikutus olla negatiivinen. Pahimmillaan joudutaan seuraavaksi korjailemaan uuden rakentamisen sijaan. Harvoin on mahdollista saada ennen varsinaista tuotantoonvientiä aukotonta dataa todellisesta liiketoimintavaikutuksesta. Tästä näkökulmasta onkin hyvä pyrkiä pitämään skooppi mahdollisimman pienenä, jotta saadaan palautetta asiakkailta mahdollisimman pian.

Yhteenvetona voidaan yltä poimia skooppaukselle seuraavat ohjenuorat: älä kasvata skooppia liian suureksi, älä myöskään karsi skooppia liikaa ja tee liian pieniä muutoksia liian tiuhaan. Ja se mikä on liian suuri ja mikä on liian pieni, riippuu täysin kontekstista. Näin avattuna on varsin helppo nähdä miksi se skooppaus voi olla välillä vähän hankalaa :D

korvat hörölle - soraääniä kuuluvissa

Tuotekehityksessä koko tiimi tekee arjessa jatkuvasti pieniä päätöksiä, joiden tuloksena syntyy ajan saatossa suuria suuntia. Tästä syystä sekä oma että koko tiimin fokus, eli käsitys siitä mikä on juuri nyt olennaista ja mikä ei, olisi koko ajan pidettävä kirkkaana.

Fokuksen kirkkaana pitäminen on helpommin sanottu kuin tehty, sillä päätöksiin liittyy yleensä aina tasapainottelua eri näkökulmien välillä. Mitä mutkikkaammassa ympäristössä toimitaan, sitä enemmän kilpailevia näkökulmia on tarjolla. Haastetta lisää vielä se, että näkökulmat ovat harvemmin kaikki yhteismitallisia. Jokin huomioon otettava asia voi olla validi, mutta kuitenkin sellainen, ettei sen tärkeyttä tai arvoa pysty järkevästi mittaamaan. Toinen lähestyminen puolestaan haastaa fokuksen ja sen todesta ottaminen vaatisi suunnan vaihtoa. Tämä jatkuva tasapainottelu näkökulmien, fokuksen pitämisen ja suunnan muokkaamisen sekä eri tavalla mitattavien asioiden välillä synnyttää väistämättä jännitteitä ja konflikteja.

Harva meistä suhtautuu konflikteihin kovin innokkaasti vaan pyrkii pikemminkin luontaisesti välttämään niitä. Mutta tuotekehityksessä jännitteet näkökulmien välillä ovat väistämätön ja jopa tarpeellinen osa hyvää päätöksentekoa. Siksi koko tuotetta tai palvelua yhdessä rakentavan tiimin olisi opittava käsittelemään konflikteja rakentavasti ja jopa arvostamaan niitä.

Tuotepäällikkönä käytän omaa aikaani paljon asiakasymmärryksen kartuttamiseen, erilaisten tietolähteiden analysointiin sekä kokonaiskuvan rakentamiseen. Piirrän kokonaiskuvasta ja asioiden suhteista usein kuvia ja kaavioita, joiden avulla selkeytän omaa ajatteluani siitä, mikä on tuotteen ja liiketoiminnan kannalta juuri nyt olennaista ja mikä voi odottaa. Tämä voi myös aiheuttaa joskus kärsimättömyyttä konfliktin edessä. Juuri kun oman ajatuksensa on saanut kirkastettua ja haluaisi jo liikkua eteenpäin voivat soraäänet ja ristiriitaiset näkemykset tuntua turhalta hidastukselta ja aiheuttaa turhautumisen tunteita. Mutta tällöin on hyvä muistaa, että rakentava konflikti on hyvä asia! Konfliktin välttäminen ja soraäänten sivuuttaminen voi puolestaan johtaa siihen, että oman pohdiskelun sokea piste jää huomioimatta ja tulee priorisoineeksi väärän asian.

Miten siis mahdollistaa rakentava konflikti? Ensimmäinen vaatimus on, että dialogille on tilaa ja toimintatavoissa on keskustelun mahdollistavia rakenteita. Lisäksi tarvitaan uteliaisuutta ja halua pohdiskella tosissaan myös vastakkaisten näkemysten hyviä puolia. Tarvitaan asiakkaiden, tiimikaverien ja sidosryhmien kuuntelua, kykyä asettua toisen asemaan, hyvien kysymysten esittämistä ja tietoista omista poikkeavien näkemysten etsimistä. Ennen kaikkea pitää jatkuvasti pyrkiä ymmärtämään näkemyksen esittäjän taustat, arkitodellisuus ja oletukset esitettyjen näkemysten takana. Ja loppuun tarvitaan tietysti kykyä tunnistaa milloin on aika tehdä päätös, avata päätöksen logiikka erityisesti niille, jotka olisivat päättäneet toisin ja jatkaa sitten eteenpäin.

Joten muistetaan soraäänen kuuluessa höristää korvat, sillä tämä ei ole välttämättä huono asia vaan tilaisuus oppia jotain, auttaa tekemään parempia päätöksiä ja terävoittää fokusta.

Jaatko kokemuksen konflktista tarpeellisena osana tuotekehitystä? Laita viestiä, niin jutellaan lisää käytännön tavoista luoda tilaa dialogille ja rakentavalla konfiktille!