Browse Tag: tuotehallinta

photo-1457427062431-fbf106908649

Vauhtia tuotekehitykseen: näin muutat monimutkaiset toiveet yksinkertaisiksi tuoteominaisuuksiksi

Tekniset ja digitaaliset tuotteet ovat usein monimutkaisia vekottimia. Mitä fiksummat insinöörit niitä suunnittelevat, sitä monimutkaisempia ratkaisut ovat.

Monimutkaisuus johtaa tuotteeseen, joka on kallis rakentaa ja vaikea käyttää. Kumpikaan ei ole hyvä asia, sillä kalliit tuotteet jäävät helposti rakentamatta ja vaikeat tuotteet käyttämättä.

Jokainen tuotteiden kanssa työskennellyt on törmännyt monimutkaisuuden kiroon. Toivelista uusista ominaisuuksista on nälkävuoden mittainen, mutta mitään ei saada toteutettua, koska jokainen toive vaatisi niin järkyttävästi työtä. Niitä ei yksinkertaisesti kannata tai ehdi tekemään.

Tiedon kirous yhdistettynä perfektionismiin on lamauttava yhdistelmä

Tuotekehittäjän saappaissa ongelmana on tiedon kirous. Tiedämme tuotteesta ja asiakkaan ongelmasta liikaa. Fiksut ja kunnianhimoiset ihmiset haluavat tehdä parhaan mahdollisen ratkaisun. Siksi suunnitellaan kuinka homma voisi toimia optimaalisella tavalla myös poikkeuksellisissa oloissa.

Olenko nyt ehdottamassa, että meidän pitäisi tehdä huonoja ratkaisuja? En suinkaan.

Olen ehdottamassa, että meidän pitäisi tehdä sellaisia ratkaisuja, joilla tuotamme asiakkaillemme enemmän hyötyä kuin mitä he saavat nyt. Se onnistuu yleensä paremmin, jos teemme jotakin yksinkertaista (eli halpaa) sen sijaan, että teemme jotakin monimutkaista (eli kallista).

Kirjoitin aikaisemmin kuinka koodari mahdollisti myyntimiehelle hyvän kaupan mitoittamalla ratkaisunsa asiakkaan kokeman arvon mukaan. Tämä on yksi esimerkki kuinka saman ongelman voi ratkaista joko yksinkertaisesti (eli halvalla) tai monimutkaisesti (eli kalliilla).

Monimutkaisuus hiipii tuotteeseen vaivihkaa

Monimutkaisuuden pirullisuus piilee sen kyvyssä hivuttautua osaksi tuotteita vaivihkaa. Asiakas haluaa saada ohjelmistolla piirrettyä hieman erilaisen pallon, joten siihen lisätään uusi valinta pallonpiirtämistoimintoon. Sama toistuu vuosien varrella kahdeksan kertaa, jonka jälkeen nämä pienet tuunaukset ovat tuottaneet markkinoiden monimutkaisimman tavan piirtää palloja.

Monimutkaisuutta lisäävät ratkaisut ovat yleensä helppoja ja nopeita toteuttaa. Laitetaan tähän jotakin lisää ja ongelma ratkeaa sillä.

Yksinkertaiset ratkaisut ovat puolestaan vaikeita. Meidän pitää miettiä miten pallon piirtämiseen toimivaa ominaisuutta voi lähtökohtaisesti käyttää eriväristen, erimuotoisten ja eri logiikalla toimivien pallojen piirtämiseen ilman, että niitä joutuu erikseen ruksimaan käyttöön tai pois. Tällainen ajatustyö on raskasta ja turhauttavaa.

”Entä jos” auttaa löytämään yksinkertaisen ratkaisun

Yksi suosikkimenetelmistäni yksinkertaisempien ratkaisujen löytämiseen on ”entä jos” -ajattelu. Tarkastellaan sitä muutaman yksinkertaisen esimerkin avulla.

Koko arkkitehtuuri pitää uudistaa.
Entä jos meillä on vain kuukausi aikaa korjata kaikista isoin ongelma?

Nosturin pitää yltää metriä korkeammalle.
Entä jos emme saa koskea nosturiin, mutta voimme muokata ympäristöä?

Asiakkaan bisnekset ovat aivan sekaisin, mikäli tavaroiden lähetystä ei saada automatisoitua.
Entä jos automaatio koskee pelkkää verkkokauppaa?

Tämä vekotin pitää voida ladata nopeammin.
Entä jos ratkaisussa ei muuttaa laturia lainkaan?

Sait varmasti kiinni ajatuksesta.

Tämän keinon tarkoituksena on saada ihmiset tuottamaan vaihtoehtoisia ratkaisuja tilanteeseen keksimällä erilaisia teennäisiä rajoituksia. Rajoituksen pitää olla sellainen, että se estää alkuperäisen, monimutkaisen ratkaisutavan.

Toimivia rajoituksia ovat mm.

  • Käytössä oleva aika
  • Käytössä oleva porukka (tai raha)
  • Käyttötilanne
  • Ratkaistavan ongelman rajaaminen
  • Tietyn tuotteen osan eristäminen pois ratkaisun piiristä

Rajoitukset luovat turvallisen ympäristön käydä ajatusleikkiä vaihtoehtoisista ratkaisuista. Niiden vuoksi ratkaisun ei tarvitse olla täydellinen. Kaikki tietävät, että rajoitusten vallitsessa haetaan parasta mahdollista ratkaisua poislukien se kaikista hienostunein versio. Lopputuloksena saa yleensä helposti ja edukkaasti toteutettavan vaihtoehtoisversion

Koodari kysyi yhden kysymyksen ja myynti sai kaupat

Erään espoolaisen ohjelmistoyrityksen pahaa-aavistamaton ohjelmoija istuu työpisteellään melusuojatut humppaluurit päässään optimoimassa resurssirohmuja tietokantakyselyitä, kun Taavi koputtaa häntä olalle ja vaatii koodikonkarin huomiota. Taavi toimii yrityksen tuotepäällikkönä ja edustaa kehittäjän näkökulmasta myyntiä.

Kuule Milla, käytiin Hilkan kanssa asiakkaalla ja he ostavat tilaustenhallintaohjelmistomme, jos he voivat tuoda sinne omat omat toimittajalistansa. Nyt sinun pitäisi ratkaista ongelma, eli kuinka paljon aikaa sinulta menee rakentaa sellainen automatiikka, jonka avulla toimittajalista kosahtaa suoraan tietokantaan ilman ikävää nypläystä?

Kuva: www.freeimages.com, kuvaaja: nimim. royalshot.
Kuva: www.freeimages.com, kuvaaja: nimim. royalshot.

Laatutietoisena ja ylpeänä koodarina Milla käy pohtimaan kuinka toimittajaominaisuus kannattaisi rakentaa. Hän toteaa, että toimittajat kannattaa tietysti hakea suoraan taloushallinnon järjestelmästä, jossa ne jo ovat. Sitä varten pitää rakentaa integraatio, jonkinlainen työkalu integraation hallintaan ja niin poispäin.

Pitkän hiljaisuuden, Taavin kahdeksan äänekkään huokaisun ja kahdenkymmenenkolmen asennonkorjauksen jälkeen Milla vastaa.

Jos tuon haluaa tehdä kutakuinkin hyvin, niin kyllä siihen ainakin kaksi kuukautta menee. Luultavasti kolme.

Taavi hämmästyy ja tekee nopean päässälaskun.

Jos Milla koodaa 150 tuntia kuussa ja tekee töitä kolme kuukautta, se tekee 450 työtuntia. Jos laskutamme asiakkaalta vaikka 100€ jokaisesta kehitystunnista, niin toimittajien tuominen järjestelmään maksaa asiakkaalle 45 000€. Eli aivan kohtuuttomasti asiakkaan budjettiin nähden pienestä lisäkilkkeestä!

Hetken hiljaisuuden jälkeen Taavi poistuu katse varpaissa ja päätään pudistellen. Kunnes äkkää Matildan, joka tekee töitä saman ohjelmiston parissa. Taavi selittää tarpeensa Matildalle, joka ei jää suunnittelemaan ratkaisua, vaan kysyy kuinka paljon Taavi oli ajatellut, että tällainen lisäominaisuus saisi maksaa.

”Varmaan jonkun tonnin tai pari”, Taavi toteaa hämmästyneenä. Vasta tämän jälkeen Matildan nuppi käy raksuttamaan.

Se tarkoittaisi alle viikon duunia. Tiukkaa tekee. Voisin lisätä järjestelmään lomakkeen, johon copy-pasteamalla läjän Y-tunnuksia asiakas saisi koko toimittajarekkarinsa tuotua järkkään yhdellä klikkauksella. Toimisiko sellainen?

Taavi paiskaa Matildalle yläfemman ja lähtee viemään ilosanomaa myyntiin: ”voimme tehdä kaupat”!

Mitä eroa Millan ja Matildan toimintatavoilla oli? Milla teki itse päätökset toivotun ominaisuuden laajuudesta ja Matilda kysyi ensin yhden avainkysymyksen, jonka avulla hän osasi ehdottaa Taaville sopivaa ratkaisua. Huomaa toki, ettei Matilda ryhtynyt tenttaamaan Taavilta sopivaa toteutustapaa, vaan kysyi liiketoiminnan edustajalle luontevan kysymyksen: mitä tämä saa maksaa. Sen pohjalta hän osasi suunnitella budjettiin sopivan ratkaisun.

Tarina pohjautuu työkaverini Kallen linkkivinkkiin: Drive development with budgets not estimates.