Parhaat ja huonoimmat tavat laatia tuotespesifikaatio

Yksi suurimmista haasteista tuotekehitystiimille on yksinkertaisesti se, miten päättää, minkä tuotteen rakentaa. Niissä tiimeissä, jotka työskentelevät tuotespesifikaation pohjalta, erityisesti laitteistokehityksessä, insinöörit eivät yleensä saa aloittaa työskentelyä ennen kuin spesifikaatio on valmis ja hyväksytty. Ja koska useimmat kehitysaikataulut ovat uskomattoman lyhyitä, ei useinkaan ole riittävästi aikaa harkita vaihtoehtoisia ratkaisuja, kun uutta tietoa tulee näkyviin.

Yksi tapa tarkastella tätä haastetta on esitetty tässä. Voit kuvitella, että ympyrässä on kaikki mahdolliset tavat, joilla tiimi voisi rakentaa tuotteen. Ja tuo pieni sininen piste on yhden tietyn tuotteen spesifikaatio. Tämä tuotespesifikaatio määrittelee tarkalleen, mihin tuotteeseen kehittäjien tulisi keskittyä ja mikä tuote heidän tulisi rakentaa.

Tässä postauksessa kuvaan ensin joitakin yleisiä menetelmiä, joita käytetään tuotespesifikaatiosta sopimiseen. Sitten tarkastelen näiden menetelmien ongelmia ja sitä, miten ne voivat johtaa siihen, että rakennetaan tuotteita spesifikaation pohjalta, joka ei todellisuudessa ratkaise asiakkaan ongelmia.

Mainittakoon, että näkökulmani perustuu 10 vuoden kokemukseen analogisen ja sekasignaalisen puolijohdeteollisuuden parissa työskentelystä, ensin sovellusinsinöörinä ja myöhemmin tuotemäärittelijänä. Nyt toimin konsulttina täällä Jama-yrityksessä.

Pahimmat tavat laatia tuotespesifikaatio:

Kysy asiakkaaltasi, mitä he haluavat sinun rakentavan

Yksi tapa aloittaa on kysyä asiakkaaltasi, mitä he tarvitsevat. Tämä voidaan tehdä odottamalla asiakkaan tekemää tarjouspyyntöä (RFQ) tai vähemmän muodollisesti tapaamisten ja keskustelujen kautta. Tyypillisesti saat tällä lähestymistavalla selville, mitä ratkaisua tai tuotetta he käyttävät tällä hetkellä ja mitä he haluaisivat muuttaa lähitulevaisuudessa. Toimit tavallaan urakoitsijana, ja asiakas vastaa kaikista määrittelyn yksityiskohdista.

Koska tässä skenaariossa on kyse olemassa olevan tuotteen iteroinnista, on hyvin todennäköistä, että päädyt hyvin tarkkaan määriteltyyn ideaan, jonka voit varmasti toteuttaa.

Tässä lähestymistavassa on kuitenkin useita ongelmia:

• Mitä asiakkaasi kertoo sinulle tuotestrategiastaan, kertovat he todennäköisesti myös kilpailullesi, ja projektin keskeisenä tavoitteena on todennäköisesti tehdä jotakin nykyistä ratkaisua halvempaa. Löydät itsesi hintasodasta.
• Asiakkaasi on jo asettunut tietynlaiseen ratkaisuun, joka perustuu siihen, mitä hän on ostanut aiemmin, minkä vuoksi on vaikea ehdottaa mitään sellaista, joka voisi vastata paremmin hänen tarpeitaan.
• Aikataulu on todennäköisesti erittäin aggressiivinen, mikä jättää vain vähän mahdollisuuksia rakentaa jotain uutta tai mahdollistaa todellisen innovaation.
• Asiakkaasi ei ehkä ole tietoinen uusista teknologioista tai hän ei vain tiedä, mitä hän tarvitsee.

Tässä tapauksessa luotat siihen, että asiakkaasi kääntää sisäiset vaatimuksensa spesifikaatioksi sinulle, sen sijaan että sinä kirjoittaisit vaatimukset tuotteelle, jota laajemmat markkinat tarvitsevat ja ostavat.

Tuotetta kehittäessäsi tiimisi joutuu väistämättä tekemään kompromisseja eri syistä. Ainoa tapa varmistua siitä, että tehdään paras valinta, on tarkastella tuloksena olevaan tuotespesifikaatioon tehtäviä muutoksia yhdessä asiakkaasi kanssa. Jos et tee niin, vaarana on, että rakennat tuotteen, jota asiakas ei hyväksy. Koska suunnittelutiimillä on kuitenkin kova paine toteuttaa aggressiivinen aikataulu, on hyvin todennäköistä, että he tekevät tuotekompromisseja ilman kaikkia parhaita tietoja. Tämä lisää entisestään riskiä väärän tuotteen rakentamisesta.

Tämä lähestymistapa toimii siten, että tuote toimitetaan. Jos toimitat hyödykekomponentteja, tämä on hyvä ratkaisu. Jos etsit ainutlaatuista ratkaisua, joka puolustaa bruttomarginaalia, tämä ei ole paras lähestymistapa.

RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships

2. Anna insinöörin kirjoittaa koko spesifikaatio

Toinen yleinen skenaario on sellainen, jossa insinööri tai jokin muu asiakaskohtainen tiimin jäsen visioi ratkaisun yhden tai muutaman asiakkaan kanssa käymiensä keskustelujen perusteella. Tiimi kokoontuu tämän idean ympärille, ja sisäisen vauhdin ansiosta vaatimukset dokumentoidaan nopeasti, ja tiimin ponnistelut siirtyvät nopeasti tuotespesifikaatioiden kirjoittamiseen ja ratkaisun kehittämiseen.

Kun ratkaisu on valmis ja valmis menemään markkinoille, jotkin tiimit validoivat ideansa asiakkaiden kanssa, mutta koska tiimi esittää ratkaisun eikä tutki tarvetta, keskustelu keskittyy yleensä tuotespesifikaatioiden yksityiskohtiin. Näillä tiimeillä ei ole tilaisuutta selvittää, ratkaiseeko ratkaisu ongelman.

Tyypillisesti tässä skenaariossa tuotevaatimukset tulevat suoraan yhden henkilön päähän ja kirjataan sen jälkeen pitkälle spesifikaatiolomakkeelle, ja muu tiimi toimii dokumentoidun spesifikaation pohjalta. Aina kun tiimi törmää konfliktiin, jossa on tehtävä kompromisseja, vaatimusten laatija joutuu päättämään oikeista kompromisseista itsenäisesti, eikä hänellä ole juurikaan tai lainkaan uutta tietoa. Lisäksi jos kyseinen henkilö ei ole tutkinut eikä validoinut vaatimuksia, tiimi rakentaa väärän tuotteen.

Miksi nämä lähestymistavat eivät johda menestykseen

Yhteistä molemmille edellisille lähestymistavoille on se, että pääpaino on valmiin tuotespesifikaation saamisessa mahdollisimman nopeasti. Tiimeillä on niin kiire aloittaa jonkin rakentaminen ja noudattaa asiakkaan asettamaa määräaikaa, etteivät ne ensin varmista, että se jokin on se oikea jokin.

Lisäksi vaatimusten tuntemus on vain yhdellä tiimin jäsenellä. Tämä henkilö on joko henkilö, joka on yhteydessä sponsoriasiakkaaseen, tai se henkilö, joka keksi tuoteidean. Kummassakaan tapauksessa muulta tiimiltä puuttuu konteksti ratkaisusta ja siitä, miksi tuotetta ollaan rakentamassa, eivätkä he näin ollen voi antaa suosituksia.

Tuloksena on usein se, että tuotteet lopetetaan myöhemmin kuin olisi pitänyt, kun paljon aikaa ja rahaa on tuhlattu, tai tiimit luovat tuotteita, jotka eivät ole menestyksekkäitä, tai me-too-tuotteita, jotka kilpailevat pitkälti hinnalla. Mikään näistä ei ole hyväksi liiketoiminnalle.

RELATED POST: 8 Do’s and Don’ts for Writing Requirements

The Best Ways to Create a Product Specification:

Paras tapa rakentaa tuotteita, joita asiakkaasi ostavat, on mennä ulos ja puhua kohdemarkkinoillesi kauan ennen kuin alat kirjoittaa spesifikaatiota. Ensin sinun on muotoiltava ongelmanasettelu.

Tuotteen ongelmanasettelu on muutama lause tai kappale, jotka kuvaavat markkinoiden tarvetta. Ne kirjoitetaan ongelmasta kärsivän henkilön näkökulmasta, ja – tämä on ratkaisevaa – niissä ei sanota mitään siitä, miten ongelma itse asiassa ratkaistaan. Tutkimuksen tämän vaiheen tavoitteena on välittää ymmärrys ongelmasta ja tunne sen ratkaisemiseen liittyvästä arvosta.

Ongelmalausunto koostuu yleensä kolmesta osasta:

1. Ensimmäinen on persoona eli kuvaus siitä, kenellä ongelma on. On hyödyllistä kuvata persoona hyvin yksityiskohtaisesti erikseen ja sitten viitata tiettyyn persoonaan ongelmanasettelussa, jotta ei tarvitse toistaa samaa persoonan kuvausta.
2. Seuraavana on ongelman kuvaus. Mitä yksityiskohtaisempi tässä on, sitä parempi. Haluat varmistaa, että tarve on kristallinkirkas. Anna myös ongelmalle nimi. Näin tiimien on helpompi viitata siihen projektin aikana.
3. Kirjoita lopuksi kuvaus siitä, kuinka usein ongelmaa esiintyy. Jos ongelmaa esiintyy harvoin ja sen vaikutus on vähäinen, sen ratkaiseminen on arvoltaan vähäistä. Jos ongelmaa esiintyy usein ja sillä on suuri vaikutus, sen ratkaisemisen arvo on suuri.

Voit aloittaa kysymällä asiakkailta, mitä ongelmia heillä on, jotka heidän mielestään voit ratkaista, mutta sinun on kaivettava syvemmältä päästäksesi todella arvokkaisiin ongelmalausuntoihin tai kultaisiin nugetteihin. Nämä kultaiset nugetit syntyvät yleensä, kun kehität syvällistä ymmärrystä markkinoista ja kokoat yhteen tietoa monista eri lähteistä.

Jos teet tämän onnistuneesti, päädyt tunnistamaan ongelman, jonka voit ratkaista ja josta asiakkaasi maksaa.

Ole prosessin aikana varovainen, ettet törmää vääriin positiivisiin tai negatiivisiin tuloksiin. Kuuntelemalla liikaa yrityksesi sisällä olevia ihmisiä tai vain pientä määrää asiakkaita voi johtaa siihen, että validoit tai hylkäät ongelman virheellisesti. Puhu mahdollisimman monelle asiakkaalle ja kerää mahdollisimman paljon tietoa.

Palaamme takaisin kaavioomme kaikista mahdollisista tuotteista, joita voimme rakentaa.

Tällä kertaa olemme lisänneet leikkaavat viivat, jotka edustavat rajoitteita. Jos ajattelemme ongelmanasetteluja ympyrän leikkaavina viivoina, niin hyvä, markkinoiden ymmärtämiseen perustuva ongelmanasettelu rajaa ympyrään alueen, joka edustaa kaikkia hyväksyttäviä ratkaisuja. Kaikki tällä alueella olevat ratkaisut ratkaisevat ongelman ja olisivat asiakkaan kannalta hyväksyttäviä.

Huomaa, että tämän alueen koko on paljon suurempi kuin edellisten tarjouspyyntö- ja tuoteideaympyröiden. Tämä johtuu siitä, että nämä ongelmanasettelut ja asiayhteys sitovat ratkaisun tarkoituksellisesti mahdollisimman löyhästi, jotta uudet ideat voivat tulla esiin.

Ajatuksena on antaa suunnittelutiimille maksimaalinen joustavuus mahdollisimman innovatiivisen ratkaisun luomiseksi rajoitusten puitteissa.

RELATED POST: Checklist: Selecting a Requirements Management Tool

How Do You Get to a Final Problem Statement?

Tässä ovat suositukseni:

1. Aloita antamalla jokaisessa projektissa jollekin henkilölle vastuu asiakkaan äänenä toimimisesta.
2. Seuraavaksi anna tälle henkilölle tehtäväksi tunnistaa markkinaongelmat pelkästään markkinoilta kerättyjen tietojen perusteella.
3. Varmista, että nämä markkinaongelmat dokumentoidaan ja jaetaan paikassa, johon koko tiimillä on pääsy.
4. Kirjoita kullekin markkinaongelman toteamukselle perustelut, joissa selitetään, miksi se on ongelma ja kuinka tärkeää sen ratkaiseminen on
5. Lisää projektisuunnitelmaan virstanpylväs, jossa tiimin on tarkasteltava ja hyväksyttävä ongelman toteamukset yhdessä liiketoimintasuunnitelman kanssa.
6. Kun tiimi alkaa kehittää ratkaisua, palaa määräajoin ongelmalausuntojen luetteloon muistuttaaksesi kaikkia siitä, mikä on tavoite.
7. Kaappaa jokaisesta ongelmasta luettelo tuotteen ominaisuuksista, joilla ongelma ratkaistaan.
8. Jos jotakin ongelmaa ei voida täysin ratkaista, tarkastele uudelleen liiketoiminta-asiakirjaa varmistaaksesi, että tuote on edelleen elinkelpoinen.

Ongelmalausunnosta spesifikaatioon

Nyt kun sinulla on ongelmalausunnot ja tiimi on tutustunut niihin, aloita tuotespesifikaation kehittäminen yhteistyössä. Koska kaikki tiimin jäsenet ymmärtävät ratkaistavan ongelman, jokainen voi antaa panoksensa spesifikaatioon.

Koska olet tehnyt etukäteistyön ratkaistavan ongelman yksilöimiseksi tunnistettujen rajoitusten puitteissa ja tiimisi on harkinnut useita tapoja toimittaa ratkaisu, sinulla on riittävästi tietoa tuotespesifikaation kirjoittamiseen.

Julkaise tuotespesifikaatio pienissä erissä

Paras lähestymistapa tässä tapauksessa on julkaista pieniä paloja spesifikaatiosta tiimille mahdollisimman aikaisin, jotta saat nopeasti palautetta. Näin vältytään tuhlaamasta aikaa väärään suuntaan ja tiimin on paljon helpompi antaa laadukasta palautetta.

Etkö ole vakuuttunut? Mieti tätä: Mitä tapahtuu, jos saat 200-sivuisen spesifikaatiolomakkeen tarkastettavaksi? Luultavasti katsot muutaman ensimmäisen sivun ja sivuutat loput.

Entä jos saat yhden sivun mittaisen asiakirjan? Luultavasti luet koko asiakirjan. Kaksisataa yksisivuista asiakirjaa johtaa paljon parempaan palautteeseen kuin yksi 200-sivuinen asiakirja.

Viittaat ongelmanasetteluun varmistaaksesi, että olet oikeilla jäljillä

Tarkista myös määrittelyä kehittäessäsi, että tuote on edelleen pätevä ratkaisu ongelmaan. On helppoa jäädä kiinni tuotteen kehittämiseen liittyvästä kompromissista ja unohtaa tarkistaa, oletko edelleen tavoitteessa.

Tällä lähestymistavalla hallitaan myös sidosryhmien odotuksia. Koska prosessi on hallittu, on olemassa puitteet ja avoimuus, jotka estävät ketään ohittamasta päätöksiä. Pystyt missä tahansa projektin vaiheessa selittämään tarkalleen, mitä arvoa tuotteesi tarjoaa ja miksi siinä on oltava tiimin määrittelemät ominaisuudet.

Tuotteiden suunnittelu markkinoiden tarpeiden mukaan on kriittistä menestyksen kannalta

Tunnustan, että joillakin teollisuudenaloilla tämä on suuri muutos siihen, miten tuotteita on aiemmin suunniteltu ja rakennettu. Mutta markkinoiden kiristyessä ja tuotteiden kasvaessa yhä monimutkaisemmiksi, pelkkä uuden iteraation toimittaminen jostain, jonka olet rakentanut jo aiemmin, ei tule pitämään sinua liiketoiminnassa pitkään.

Lataamalla e-kirjamme Best Practices for Writing Requirements (Parhaat käytännöt vaatimusten kirjoittamiseen) saat lisätietoa siitä, miten vaatimukset kirjoitetaan niin, että kaikki sidosryhmät ymmärtävät kehitystarpeet selkeästi.

LUE e-kirjaa

.