To gain experience, science has to go into industry and adopt their methods and collect impressions what are the demand of methods in industry
[Birkhofer et. al. 2005]
Tuotekehityksen kirjallisuutta on vaikka millä mitalla. Kukin käsittelee samoja asioita hieman omasta kulmastaan. Tuotekehitystä on ajateltava siinä kontekstissa, että yleispätevää totuutta tuotekehityksen läpivientiin ei ole. Kaikilla teoksilla yhteistä on kuitenkin, että toiminta:
- Nähdään prosessina
- Aletaan asiakastarpeiden määrittelyllä
- Päättyy kilpailukykyisen tuotteen ollessa markkinoilla
Lisäksi tiedetään, että mitä kehitys on joka tapauksessa enemmän ja vähemmän iteratiivinen prosessi. (Huom. Aiemmat kirjoitukset, jotka viittaavat Darwiniin, ja soveltuvimman ratkaisun hakemiseen)
Jos perusta on siis sama, niin onko työkalujen kehittymisellä väliä prosessin kannalta? No – on sillä huomattavasti väliä. Se on alun lainauksen ydin. Koitan parhaani mukaan esittää, että miksi tietotekniikan kehitys vaikuttaa siihen, miten tuotekehitystä prosessina kannattaa ajatella uusiksi.
Simulointi muuttaa prosessin läpimenon
Simulointi on yhtä kuin todellisuuden jäljittely. Nykyisillä mallinnus- ja laskentaohjelmistoilla siinä ollaan jo erittäin tehokkaita. Miten tämä tehokas todellisuuden jäljittely sitten vaikuttaa tuotekehitysprojektin prosessiin? Siten, että iteraatioita on mahdollista tehdä moninkertainen määrä verrattuna perinteisiin menetelmiin.
Haasteena simuloinnin tehokkaalle hyödyntämiselle ovat yritysten perinteisesti käyttämät tuotekehitysprosessit, jotka eivät erityisen hyvin tue simulointimallien hyödyntämistä.
Käytännössä muutos prosessissa on se, että simuloimalla saadaan suunniteltua moninkertaisesti nopeammin ’riittävän todellinen tuote’, että virtuaalituotetta voidaan arvioida asiakkaan tai käyttäjän toimesta. Eihän asiakasta kiinnosta piirustukset tai mallit, vaan tuotteen luoma lisäarvo.
Simuloimalla voidaan siis nopeasti mennä suoraan perinteisen tuotekehitysprosessin alusta loppuun ja takaisin. Tällöin projektin perinteiset etapit hämärtyvät ja toisaalta iteraatioiden määrä kasvaa. Enemmän yrityksiä ja erehdyksiä ja sitä kautta parempi lopputulos – kuten evoluutiossa.
Kommunikaatioalustat hämärtävät projektin etappeja
Jos simuloinnin helppous ja edullisuus mahdollistaa lisää ja tarkempia iterointikierroksia, on kommunikaatioalustojen parantumisen merkitys saman tyyppinen. Sekin hämärtää ennen niin suoraviivaisen prosessin rajoja.
Perinteiset metodit ovat enemmän ja vähemmän ylhäältä johdettuja. On palavereja, jossa käydään läpi miten on tehty, miten tullaan tekemään, miten päästään seuraavasta etapista läpi jotta projekti voi edetä,yms.,yms. Hieman kärjistäen projektit usein vedetään projekti läpi manuaalin mukaan ja katsotaan maalissa mikä on asiakkaan ilme lopputuloksen nähtyään. Välissä on palavereja joissa makustellaan vaihtoehtoja ja suuri osa ajasta on jonkin tason päätöksen odottelua ja raportointia.
Tämä on loogista, koska kaikkien asianomistajien pitää olla kartalla siitä mitä tapahtuu ja mihin ollaan menossa. Ongelmat on tietenkin tiedettävä ja niihin on varauduttava, koska deadlinet on kuitenkin pidettävä.
Tässä onkin se murros mitkä ’ketterän kehityksen työkalut’ kuten Jira ja muut vastaavan tyyppiset ohjelmat ovat tuotekehityksen prosesseihin synnyttäneet. Tai ainakin – nämä alustat voivat vaikuttaa prosessiin mikäli niiden käyttö suunnitellaan hyvin. IT-alalla ketteryys, eli Agile, on arkipäiväisempää, mutta konservatiivisemmilla aloilla menetelmiä ja työkaluja ei olla otettu niin herkästi käyttöön.
Tuotekehityksen projektimaisuus on ennustettavuuden ja hallinnan kannalta tärkeää, mutta sen osia voi automatisoida ja projektin palasia voi kasata sieltä täältä hallitusti valmiiksi. Päätökset eivät ole enää vastaavasti jonoon kytkettyjä, vaan ongelmiin tartutaan matkan varrella pala palalta, mutta silti hallitusti.
Yhteenveto
Tiivistettynä – usein sitoudutaan vanhoihin oppikirjamalleihin siitä, miten tuotekehitystä johdetaan prosessina. Vanhat suoraviivaiset prosessit eivät enää päde, ellei onnistu ajattelemaan prosessia työkalujen sallimien mahdollisuuksien kannalta.
Jos yritykset suhtautuisivat tuotekehitykseen vapaammin ja hyödyntäisivät näitä itselleen parhaita työkaluja, voisi se tänä päivänä toteutettu tuotekehityksen best practice toteutua tulevaisuuden tuotekehityskirjallisuudessa. Niin ne vanhatkin prosessit on tehty.
Lisää aiheesta linkkien takana:
V-malli
https://en.wikipedia.org/wiki/V-Model
VDI2221
Agile