Edellisessä blogissa käytiin läpi tuotekehitysprojektin vaiheet kokonaisuutena. Tässä osassa keskitytään työn alkuun ja puretaan se auki hieman tarkemmin – siihen kohtaan, jossa moni hanke joko saa hyvän suunnan tai alkaa huomaamatta ajautua sivuraiteelle.
Tuotekehitysprojekti alkaa harvoin valmiilla spekseillä ja aikatauluilla. Usein pöydällä on selkeä ajatus, tarve tai ongelma, jonka ympärillä on kuitenkin enemmän kysymyksiä kuin vastauksia. Tämä on aivan normaalia. Kaiken ei tarvitse olla valmista – tärkeintä on edetä ja tehdä oikeita asioita oikeassa järjestyksessä.
Projektin aloitus – mitä ollaan oikeasti tekemässä?
Alkuvaiheessa keskustelu lähtee usein liikkeelle tavoitteesta:
”Pitäisi tehdä laite, joka mittaa tämän tarkemmin.”
”Tarvitaan uusi versio nykyisestä tuotteesta.”
”Haluamme kehittää tuotteen tämän ongelman ratkaisemiseksi.”
Lähtökohta on oikea, mutta ennen kuin mennään pidemmälle, pysähdytään yleensä kysymään muutama yksinkertainen asia:
- Mikä nykyisessä ratkaisussa ei riitä?
- Kuka käyttää tuotetta?
- Milloin ja missä?
- Onko kyse suorituskyvystä, luotettavuudesta, hinnasta, käytettävyydestä vai jostain muusta?
Yllättävän usein käy ilmi, että varsinainen ongelma tai tavoite on selkeä. Keskustelun myötä käy kuitenkin selväksi, että kehitystyöhön liittyy monia ’piilossa olevia’ ongelmia, joiden ratkaiseminen on edellytys tuotteen menestymiselle markkinoilla.
Esimerkiksi mittaustarkkuus ei välttämättä ole rajoittava tekijä – vaan se, että laitteen käyttö- tai ympäristöolosuhteet estävät riittävän tarkan mittauksen. Tai että nykyisessä tuotteessa ei ole teknistä puutetta, vaan sen käyttö on hankalaa ja asentaminen ja huolto vievät liikaa aikaa.
Kun tavoite kuvataan konkreettisina käyttötilanteina eikä abstraktina toiveena, projekti saa selkeämmän suunnan. Tässä vaiheessa ei tarvitse vielä tietää, millaisella rakenteella, komponenteilla tai teknologioilla asia tullaan ratkaisemaan. Riittää, että ymmärretään ongelma riittävän tarkasti.
Alkuvaiheessa on hyödyllistä myös rajata asioita: mitä tämä tuote ei ole, kenelle sitä ei ole tarkoitettu, mihin sitä ei saa käyttää, mitä ominaisuuksia siihen ei sisällytetä…? Kaikkea ei kannata yrittää ratkaista yhdellä kertaa. Rajaaminen auttaa fokusoimaan työn oikeisiin asioihin ja välttämään loputonta tuoteominaisuuksien ’shoppailua’.
Usein järkevin tapa edetä on määritellä ensimmäinen versio niin, että se ratkaisee keskeisen tarpeen – ei kaikkia mahdollisia tulevia tarpeita. Tuotteen myynnin ja tuotekehitysinvestoinnin takaisinmaksun kannalta olennaista on, että kehitetty tuote soveltuu juuri olennaisimpaan ja siten arvoltaan suurimpaan markkinaan. Pienempien markkina-alueiden kattaminen onnistuu sitten, kun tuotteen myynti saadaan liikkeelle.
Yhteistyön määrittely – miten tätä tehdään yhdessä?
Kun suunta alkaa hahmottua, seuraava käytännön kysymys kuuluu: miten työ organisoidaan niin, että se pysyy hallinnassa?
Tuotekehityshankkeissa yhdellä henkilöllä voi olla monta roolia. Tuotteen omistajan puolella päätöksenteko, tekninen näkemys ja liiketoiminnallinen vastuu voivat olla samoissa käsissä. Tuotekehityspalvelun tarjoajan projektipäällikkö ja pääsuunnittelija voivat olla yksi ja sama henkilö. Tämä on vahvuus, kunhan roolit tunnistetaan.
Jotta työ etenisi mallikkaasti, alkuvaiheessa on aiheellista sopia ainakin:
- kuka hyväksyy tekniset ratkaisut
- kuka konkreettisesti päättää budjetista ja mahdollisista muutoksista
- miten muutospyynnöt käsitellään
- miten dokumentointi hoidetaan
- kuinka usein katselmoidaan etenemistä
Jos näitä ei sovita, syntyy helposti tilanne, jossa tekninen työn eteneminen pysähtyy puuttuvaan päätöksentekoon – tai sitten mielikuvat vievät työtä eri suuntaan kuin oli tarkoitus.
Keskeinen asia on myös muutosten käsittely. Tuotekehitystyölle on ominaista se, että kaikkea ei saada kerralla osumaan kohdalleen. On hyvä todeta ääneen, että muutoksia varmasti tulee työn edetessä. Kysymys ei näin ole siitä, tuleeko muutostarpeita – vaan siitä, miten niihin reagoidaan. Kun muutosten hallinnalle on selkeä toimintatapa (vaikutusten arviointi, aikataulu- ja kustannusvaikutus, hyväksyntä), ne eivät tunnu ylitsepääsemättömiltä ongelmilta.
Yhteistyön määrittely ei ole byrokratiaa. Se on keino varmistaa, että suunnittelutyö ja päätöksenteko kulkevat samaan suuntaan ja johtavat oikeaan lopputulokseen.
Skitsaus – oletusten paljastaminen
Skitsaus on vaihe, jossa moni hanke alkaa muuttua konkreettiseksi. Se voi tarkoittaa käsin piirrettyä lohkokaaviota, 3D-luonnosta, alustavaa kytkentäperiaatetta tai yksinkertaista käyttöliittymämallia.
Tässä vaiheessa esiin nousevat usein ensimmäiset ristiriidat:
- laitteen koko vaikuttaa olevan liian pieni tarvittavien osien määrään verrattuna
- valmistuskustannus nousee tavoitetta korkeammaksi
- käyttöympäristö asettaa käytölle rajoitteita, joita ei aiemmin huomioitu
Skitsaus tekee oletukset näkyviksi. Ajatuksissa kaikki mahtuu hienosti ajateltuun konseptiin – oikeilla osilla tehdyssä luonnoksessa tila näyttääkin käyvän yhtäkkiä liian pieneksi.
Tässä kohtaa on hyödyllistä tehdä vaihtoehtoja, ei yhtä ratkaisua. Esimerkiksi kolme erilaista periaateratkaisua, joista jokaisella on omat vahvuutensa ja heikkoutensa. Kun vaihtoehtoja vertaillaan rinnakkain, päätökset tehdään tietoisemmin eikä vain ensimmäisen idean pohjalta. Valittu ratkaisu kannattaa valita ajatuksella – se kuitenkin ohjaa vahvasti varsinaista suunnittelua.
Skitsausvaiheessa ei ole tarpeen optimoida yksityiskohtia. Tavoitteena on varmistaa, että kokonaisuus on looginen ja toteutuskelpoinen. Liian varhainen yksityiskohtien hiominen vie tarpeettomasti aikaa, ja yksityiskohdat täsmentyvät joka tapauksessa suunnittelun edetessä.
Demo – riskit esiin varhain
Demo on usein ensimmäinen hetki, jolloin teoria kohtaa käytännön. Demo on tavallaan skitsin toteutus.
Jos kyse on elektroniikasta, demo voi olla pelkistetty toteutus tuotteen kannalta keskeisimmästä ja kriittisimmästä piiristä. Jos kyse on ohjelmistosta, se voi olla rajattu toiminnallisuus ilman viimeisteltyä käyttöliittymää. Mekaanisessa tuotteessa demo voi tarkoittaa yksinkertaista testirakennetta, jolla varmistetaan toimintaperiaate.
Demon tärkein tehtävä on paljastaa ja tuoda esiin teknisiä riskejä mahdollisimman aikaisin. Esimerkiksi:
- toimiiko valittu mittausperiaate todellisessa ympäristössä?
- syntyykö häiriöitä, joita ei simulaatiossa näkynyt?
- riittääkö suorituskyky vai törmätäänkö fyysisiin rajoihin?
Jos nämä asiat selviävät vasta oikeaa tuotetta vastaavassa prototyypissä, korjaaminen on huomattavasti työläämpää.
Hyvä demo on rajattu. Siinä testataan yksi tai muutama kriittinen asia – ei koko järjestelmää. Tavoitteena ei ole vaikuttava esitys, vaan rehellinen vastaus siihen, onko valittu suunta teknisesti perusteltu.
Proof-of-Concept – kokonaisuus ensimmäistä kertaa kasassa
Proof-of-Concept (PoC) yhdistää tarvittavat osuudet toimivaksi kokonaisuudeksi. PoC-versionssa elektroniikka, mekaniikka, ohjelmisto ja käyttöliittymä toimivat yhdessä. PoC:n tavoitteena on osoittaa, että kaupallinen tuote on oikeasti toteutettavissa valitulla konseptilla. Tähän vaiheeseen ei tarvita kuitenkaan kaikkia lopullisen tuotteen toimintoja – selkeät ja itsestään selvät osuudet voidaan jättää pois.
Tässä vaiheessa nousevat usein esiin käytännön realiteetit:
- lämpökuorma ei jakaudu kuten oletettiin
- tehonkulutus on odotettua suurempi
- langattoman yhteyden kantama ei riitäkään
- mittauksen kohina vaikuttaa liian suurelta
PoC on versio, jossa nämä asiat halutaankin kohdata. Mitä aikaisemmin mahdolliset ongelmat tulevat esiin, sitä helpompi niihin on reagoida hallitusti. Kukaan ei varmasti halua törmätä tuotteen toimintaongelmiin sen jälkeen, kun tuote on jo toimitettu käyttöön.
PoC vastaa keskeisiin teknisiin kysymyksiin ja kertoo kokonaisuudesta. Voi olla järkevää jättää tästä versiosta osa toiminnoista ajan säästämiseksi vielä pois. Myöhemmin tehtävässä prototyypissä laitteen rakenne, valmistettavuus ja luotettavuus tulevat sitten esiin paremmin.
Tässä kohtaa dokumentoinnin merkitys korostuu. Havainto siitä, että jokin ratkaisu ei toiminut, on arvokasta tietoa – mutta vain, jos se kirjataan ylös ja otetaan hallitusti huomioon seuraavassa muutoskierroksessa.
Miksi alku ratkaisee niin paljon?
Tuotekehitysprojektin alku ei näytä ulospäin dramaattiselta. Eihän alussa vielä valmisteta sarjaa eikä julkaista tuotetta. Silti juuri tässä vaiheessa määritellään pitkälti:
- mihin tarpeeseen tai ongelmaan tuote vastaa
- kuinka hallittavasti projekti etenee
- miten tuotteeseen ja kehitystyöhön kohdistuvat riskit hallitaan tai havaitaan
- miten tarvittavat muutokset hoidetaan kaikkien hyväksymällä tavalla
Kun tarve on ymmärretty konkreettisesti, yhteistyömalli on selkeä ja kriittiset riskit paljastetaan ajoissa skitsauksen, demon ja PoC:n avulla, tuotteen kehitys etenee hallitusti kohti maalia.
Hyväkään aloitus ei tarkoita sitä, että kaikki tiedettäisiin tai pystyttäisiin ennustamaan. Se tarkoittaa, että oikeita kysymyksiä on esitetty riittävän aikaisin – ja että niihin on onnistuttu löytämään myös vastaukset aikanaan. Seuraavassa osassa siirrytään siihen, mitä tapahtuu, kun suunta on valittu: suunnittelun syventämiseen, materiaalihankintaan ja alustaviin testeihin.