Kuka keksi jakaa designin osiin?
Kehitysprojektien etenemisen kannalta tehokkainta olisi, jos samat, monitaitoiset ihmiset olisivat mukana koko kehityksen ajan, eikä heidän tekemisilleen olisi asetettu ulkoisia esteitä. Mikäli tiimin tuotos on yksinkertainen osaamispaletin ei tarvitse olla niin laaja. Yksi ihminenkin voi tuottaa ja myydä palveluaan, mikäli osaa tuottaa sellaista mitä muut haluavat ja osaa siitä periä maksua.
Tuotteiden ja palveluiden monimutkaistuessa kehittämiseen ja myymiseen tarvittava osaamispalettikin kasvaa. Tiimin osaamispaletin pitäisi olla laaja, jotta kaikki palvelun tai tuotteen synnyttämisen tarvittavat tehtävät ja vaiheet saadaan riittävissä määrin täytettyä
Työnjako tehostaa toimintaa tiimin tasolla, koska erikoistumaan päässeet yksilöt ovat tehtävissään tehokkaampia kuin aihepiiriin perehtymättömät. Kukin voi keskittyä optimoimaan tehtäviään ja muutaman henkilön toimiessa yhdessä, päivittäin toisilleen keskustellen, kommunikaatiokaan yhteisistä kaikkia koskevista asioista ei vielä kärsi.
Kuulemani mukaan kaverini startupissa homma meni alkuvaiheessa jotenkin näin: Jokaisella alkuperäisestä perustajatiimistä oli jokin oma erikoistumisensa. Yksi otti vastuuta fronttikoodauksesta, toinen bäkkäristä. Kolmas, toimitusjohtaja, täytti tarpeen mukaan tehtäviä, mutta oli ensisijaisesti vastuussa myynnistä ja sen oikean toimivan konseptin löytämisestä. Kukaan ei ollut täysi ekspertti roolissaan, mutta oppia tuli lisää tehdessä. Aiemmat kokeilut olivat antaneet jotain osviittaa asiakkaiden tarpeista ja markkinoilta löytyi tarve, joka validoitiin kevyellä Proof-of-Conceptilla, jonka tiimi teki nopeasti kasaan. Kun todellinen tarve oli tällöin löydetty tiimi päätti itse alkaa investoimaan aikaansa tähän mahdollisuuteen. Koko perustajatiimi tunsi toimintatavat joilla houkuttelevia digitaalisia tuotteita synnytetään. Toiminnassaan he sovelsivat mm. Lean Service Creation -toimintamalleja.
Myynnin kasvaessa ja ulkoisten investointien kautta lisääntyneillä resursseilla tehtiin rekryjä ja tiimissä oleva erikoistuminen lisääntyi. Palkattiin lisää kehittäjiä ja asiakassuhteita tekeviä, joiden tehtävänkuvakin oli rajatumpi kuin alussa oli. Kasvavat yritykset kamppailevat sen kanssa kuinka paljon erikoistumista vaativia tehtäviä on, eli missä vaiheessa jotain asiaa tekemään kannattaa palkata erillinen ihminen.
Koska yrityksellä on vain yksi palvelu ja jokainen työskentelee sen parissa, ei yritykseen tulemisen lisäksi erillisiä perehdytyksiä tarvita. Palvelukehitys jatkaa siitä mikä on jo olemassa.
Isommissa yrityksissä ihmisten ja osaamisen organisoituminen on kuitenkin hyvin erilaista.
Organisaatiot, joilla on pidempi historia ovat kokeneet palveluidensa muuttuneen, vanhojen kuolleen ja uusien syntyneen tilalle. Palveluiden kehittäminen on saatettu irrottaa niiden ylläpidosta ja tuotannosta tehtävistä suoritutymisen ja johtamisen tehokkuuteen perustuen. Uusien palveluiden löytäminen vaatii uteliaisuutta ja kokeilunhalua, joita kaikissa rooleissa, joita organisaatioon on syntynyt, ei tarvita. Uusien palveluiden synnyttäminen on kuitenkin organisaation pitkän tähtäimen selviytymisen kannalta kriittistä, koska lähtökohtaisesti marginaalihyöty vanhan asian tekemisestä laskee ajan myötä kilpailun ja markkinoiden muuttumisen myötä. Ihmiset kyllästyvät vanhaan ja löytävät jonkin uuden tavan täyttää tarpeitaan.
Näistä syistä organisaatioon on voinut syntyä erikoistuneita osastoja ja rooleja palvelukehityksen eri vaiheisiin. Osa organisaatioista on myös saattanut palvelukehityksen tehtäviä ja keskittyä ylläpitämiseen. Erityisesti näissä tapauksissa palvelukehityksen alkuvaiheiden integroituminen muun organisaation kanssa, joka lopulta tulisi palvelutuotannosta vastaamaan on kriittistä.
Seuraavaksi hahmottelen isoissa organisaatioissa sisällä ja ulkoisena konsulttina Suomessa toimiessa havaitsemiani palvelukehityksen vaiheita ja tehtävien organisoitumista roolien kautta.
Tutkimusvaihe
Alkuvaiheessa, kun organisaatiolla ei ole vielä muodostunut kunnollista käsitystä siitä mitä sen pitäisi tulevaisuudessa tehdä, se alkaa uusien kohteiden etsiskelyn. Käyttäjälähtöisessä kehityksessä se lähtee käyttäjien tarpeita ja kontekstia ymmärtämällä. Kuluttajatutkimuksen erikoistunut rooli voi olla esimerkiksi User Researcher. Etsiskelyä ohjaamaan voidaan valita jo Business Owner, tai tehtävän voi antaa Service Designerille. Palvelumuotoilija toimii yleisosaajana eri toimijoiden välillä, pyrkien synnyttämään fasilitoinnillaan uutta tietoa. Business Designer roolille annettavissa tehtävissä korostuu liiketoiminnan kannalta tulevien tarvittavien prosessien tarkastelu. Tutkimusvaiheen jälkeen on saatettu löytää jokin konkretisoitu ehdotus suunnasta ja tehtävistä palveluista.
Investointipäätös
Isommissa keskusjohtoisissa organisaatiossa päätöksenteko tapahtuu tutkimusvaiheeseen osallistumattomien toimesta siten, että ideaa tarkastellaan osana muuta käynnissä olevaa toimintaa ja jo portfoliossa hallussa olevia innovaatioiden alkuja. Ihmisiä, joille tämä erikoistuminen on muodostunut kutsutaan mm. Business Director ja Portfolio Manager nimityksillä. Ensimmäinen tiimien välinen kommunikaatioyritys tapahtuu tässä, kun tutkimus- ja palvelumuotoiluvaiheeseen osallistuneet muotoilevat ideansa asiaan perehtymättömille. Usein päädytään käyttämään liiketoiminnan mittareita yritykselle idean houkuttelevuuden perustelemiseen. Jos synnytettävää liiketoimintaa pystytään testaamaan pienemmässä koossa aluksi, niin investointipäätöksiä voi tulla useita, panostusten aina kasvaessa.
Kehittämisvaihe
Kehitysvaiheessa, investointipäätöksen tultua ryhdytään alkuperäistä palveluideaa viemään toteen. Siihen liittynyttä hypoteesia asiakkaille syntyvästä arvosta testataan todellisessa maailmassa. Digitaalisten palveluiden tapauksessa palvelukehityksen osaaminen koostuu ohjelmistotuotannosta (esimerkiksi Architect, Developer, Backend Developer). Yleensä Business Owner jatkaa palvelunkehittämisen johtajana, saaden digitaalisista tuotteista ja komponenteista vastaavia Product Ownereita avukseen. Tiimien välinen toinen kommunikaatioyritys tapahtuu siinä vaiheessa kun mukaan tulee uusia ihmisiä, jotka eivät ole olleet mukana aiemmassa tutkimusvaiheessa. Palvelumuotoilijan ohjastamana syntynyt konsepti ja sen taustalla vaikuttavat liiketoiminnan, sidosryhmien ja asiakkaiden maailmasta opitut asiat täytyy saada välitettyä ihmisille, jotka tulevat vastaamaan aihepiiriin liittyvän ratkaisun kehittämisestä. Mikäli palveluidea ei ole selkeä, eikä sen perusteena olleet tiedot mitenkään välity, on kehitysvaiheella vähintään vaikea alku.
Ylläpivovaihe
Digitaaliset palvelut siirtyvät ylläpitoon, kun aktiivinen uusiin toiminallisuuksiin pyrkivä kehitystyö loppuu. Yleensä palveluiden annetaan olla toiminnassa markkinoilla vuoden tai pari, ennen kuin niiden kehitys nähdään taas tärkeänä. Kuluttajien omaksuminen kestää myös tovin, ja tätä varten markkinoinnin ja myynnin tarpeisiin palvelutarjooman lukitseminen hetkeksi sopii hyvin. Lisäksi mikäli digitaalinen palvelu aiheuttaa muutoksia manuaalisiin ihmistyöllä tuotettuihin palveluosiin, on myös näihin komponentteihin syntyvät dynaamiset vaikutukset huomioitava. Kun markkinoilta on tullut asiakaspalautteen ja liiketoimintamittarien muodossa lisää tietoa, on helpompi tehdä yrityksen toiminnan kannalta parempia päätöksiä tulevien kehityspanosten asettamisesta. Yritys voi esimerkiksi ennustaa, missä vaiheessa nykyiselleen jätetty palvelu tavoittaa lakipisteensä ja mitä asian muuttamiseksi täytyisi tehdä.
Ylläpitovaiheessa syntyvää tietämystä käytetään yleensä seuraavien tutkimusvaiheiden lähtökohtana. Tilastollisella tiedolla nähdään esimerkiksi joitain kiinnostavia poikkeuksia, joihin laadullisella perehtymisellä pystytään synnyttämään tarkempi kuva.
Miten designia pitäisi organisoida?
Käyttäjäkeskeisten suunnitteluroolien eriytyminen palvelumuotoilijoihin, käyttäjätutkijoihin, käyttökokemuksensuunnittelijoihin ja muihin kehittäjiin on ollut havaittavissa. Väitän että osittain tämä johtuu siitä, että käyttäjäkeskeinen suunnittelu on läpäisemässä suuria organisaatioita, joiden organisoitumistapa on perua aikaisempien palveluiden kehittämisestä ja työn organisoinnista keskusjohtoisesti. Vasta perustettavien tai pienten yritysten tapauksessa käyttäjäkeskeisen suunnittelijan tontille tippuu useampia asioita palvelukehityksen eri vaiheista. Suurissa yrityksissä yksittäiselle tehtävälle nähdään jatkuvampi tarve, joten siihen palkataan erikoistuva ihminen. Tittelit siten seuraavat suurien organisaatioiden tarvetta asettaa erikoisosaajille tarkkoja nimikkeitä. Riippuu täysin organisaatiosta ja sen kulttuurista missä määrin designerit nähdään yleisosaajina taidoiltaan, ja missä määrin pelkkään liiketoimintaan perehtyneet säilyttävät johtoasemansa.
Erillisten palvelumuotoilijoiden tarpeeseen vaikuttaa myös se mihin organisaatio on keskittynyt ja mitä toimintoja se pitää sisäisinä kyvykkyyksinään. Mikäli yrityksellä ei ole merkittävää tutkimusta ja tuotekehitystä, vaan se laajenee ostoilla ja menestyy vain pyörittämällä olemassa olevia liiketoimiaan, se saattaa tarvita ulkoisena toimintona palvelumuotoilua ja digitaalista kehitystä pysyäkseen kilpailullisena.
Ulkopuolelta ostettu palvelumuotoilu- tai kehitystiimi ei saa luotua niin tehokkaasti organisaatioon sopivia palveluita kuin sisäiset toimijat saisivat, koska tuotantoon siirtäminen ei ole täysin kontekstiriippumatonta ja vaatii pidempiaikaista tiedon diffuusiota, eli jakautumista tasaisemmin ihmisiltä toisilleen.
Tutkimusvaiheessa tarvitaan eri taitoja ja osaamista kuin mitä kehittämisen vaiheessa. Työnjaon kannalta tehostuu johonkin pisteeseen saakka jos on erikoistuneita yksilöitä tekemässä, koska kaikki ihmiset eivät pysty omaksumaan koko kavalkadia metodeita, joita kaikkiin vaiheisiin tarvitaan. Ihmisillä on rajallinen aika opetella töissään tarvitsemia taitoja. Tästä syystä erityisesti isojen organisaatioiden tapauksessa palvelumuotoilijan ja käyttökokemussuunnittelijan työtehtävät ovat eriytyneet.
Kiinnostavaksi akateemiseksi tutkimuskohteeksi muodostuu se, miten palvelumuotoilijat ja kokemuksen suunnittelijat tekevät vaihdon syntyneestä tiedosta (toinen kommunikaatioyritys).
Investointipäätöksen eriyttämisen, koko organisaation näkökulmasta, lisäämä tehokkuushyöty asettuu tarkasteluun sen palvelukehitysprosessin keskeytyksen aiheuttaman haitan kanssa. Mikäli löydöksistä siirrytään toimintaan liian myöhään, voi mahdollisuus olla markkinoiden muutoksen myötä mennyt. Lisäksi jos tutkimusvaiheen tietämys jää vain kirjallisen dokumentaation varaan, on vaarana tiedon hukkuminen.
Uskon tässä vaiheessa, että
- Tiimin jäsenten samana pysyminen tukee kokonaisnäkemyksen säilymistä
- Liiketoimintaomistajat tasoittaavat tiedon siirtymistä
- Laaja-alaiset osaajat kykenevät parempaan tiedonvälitykseen keskenään, eli täysi erikoistuminen palvelukehityksen kaltaisessa toimessa ei aina kannata
- Jos liiketoiminta on tietämätön todellisista kehitystyön kautta syntyvistä mikrotason arvonluontimekanismeista asiakkaille, se ei voi tehdä parhaimpia päätöksiä siihen liittyen
Vastaus otsikkoon:
Uskon että työnjaon hyödyt ja isojen organisaatioiden kontekstissa tehokkuuspyrkimys ajavat designiin liittyvien tehtävien eritytymistä.
Tuleva akateeminen tutkimukseni tullee käsittelemään palvelumuotoilutiimin ja liiketoimintaverkoston välistä kommunikaatioyritystä, jossa yhteiskehittämisellä muodostettu konsepti ja sen taustalla vaikuttavat liiketoiminnan, sidosryhmien ja asiakkaiden maailman opit pyritään välittämään seuraavaan palvelukehitysvaiheeseen erinäisten ihmisten, tuotosten ja sattumien kautta.
Päivitys 2020–01–13: Caballero, Moreno & Seffah (2016) kirjallisuuskatsaus tarkasteli pääosin 00-luvulla kirjoitettuja artikkeleita ketterän kehityksen ja käyttäjälähtöisen suunnittelun yhdistämisestä. Heidän löydöksenään oli, että useammin käytössä ovat erilliset tiimit, jotka sitten ovat yhteydessä toisiinsa, kuin että sama tiimi olisi vastuussa ohjelmistokehityksestä sekä käyttäjiin, käyttöliittymäsuunnitteluun ja vaatimusmäärittelyyn liittyvistä asioista.
Caballero, Leydi, Ana M. Monero, and Ahmed Seffah. “How Agile Developers Integrate User-Centered Design Into Their Processes: A Literature Review.” International Journal of Software Engineering and Knowledge Engineering 26 (2016): 1175–1201. https://doi.org/10.1142/S0218194016500418.
