A termékleírás készítésének legjobb és legrosszabb módjai

A termékfejlesztési csapatok egyik legnagyobb kihívása, hogy egyszerűen hogyan döntsék el, milyen terméket készítsenek. A termékspecifikáció alapján dolgozó csapatok esetében – különösen a hardverfejlesztésben – a mérnökök általában nem kezdhetnek el dolgozni, amíg a specifikáció el nem készül és jóvá nem hagyják. És mivel a legtöbb fejlesztési ütemterv hihetetlenül rövid, gyakran nincs elég idő alternatív megoldások mérlegelésére, amint új információk kerülnek napvilágra.

A kihívás egyik megközelítése itt látható. Elképzelhető, hogy a kör minden lehetséges mód, ahogyan a csapat megépítheti a terméket. Az a pici kék pont pedig egy adott termék specifikációja. Ez a termékspecifikáció pontosan meghatározza, hogy a fejlesztőknek melyik termékre kell összpontosítaniuk és megépíteniük.

Ebben a bejegyzésben először is ismertetek néhány, a termékspecifikációban való megegyezéshez használt általános módszert. Ezután feltárom az ezekkel a módszerekkel kapcsolatos problémákat, és azt, hogy hogyan vezethetnek ahhoz, hogy olyan termékeket építünk egy olyan specifikáció alapján, amelyek valójában nem oldják meg az ügyfél problémáit.

El kell mondanom, hogy az én nézőpontom 10 évnyi, az analóg és vegyes jelű félvezetőiparban szerzett tapasztalatból származik, először mint alkalmazásmérnök, majd mint termékmeghatározó. Most tanácsadóként dolgozom itt a Jama-nál.

A termékleírás készítésének legrosszabb módjai:

Kérdezze meg az ügyfelét, hogy mit szeretne, hogy megépítse

Az egyik módja a kezdésnek az, hogy megkérdezi az ügyfeleit, hogy mire van szükségük. Ezt megteheti úgy, hogy megvárja az ügyfél által kiadott árajánlatkérést (RFQ), vagy kevésbé formálisan, találkozók és megbeszélések útján. Jellemzően azt fogja megtudni ezzel a megközelítéssel, hogy milyen megoldást vagy terméket használnak ma, és mit szeretnének megváltoztatni a közeljövőben. Bizonyos értelemben Ön vállalkozóként jár el, az ügyfél pedig felelős a specifikáció minden részletéért.

Mivel ez a forgatókönyv egy meglévő termék iterálását igényli, nagy a valószínűsége, hogy a végén egy nagyon konkrét ötletet kap, amelyet biztosan meg tud valósítani.

Ezzel a megközelítéssel azonban több probléma is van:

• Amit az ügyfél elmond Önnek a termékstratégiájáról, azt valószínűleg a konkurenciának is elmondja, és a projekt egyik fő célja valószínűleg az, hogy a meglévő megoldásnál olcsóbbat készítsen. Árháborúban fogod magad találni.
• Az ügyfele már beállt egyfajta megoldásra, annak alapján, amit korábban vásárolt, ami megnehezíti, hogy bármi olyat javasoljon, ami jobban megfelelhet az igényeinek.
• Az ütemterv valószínűleg rendkívül agresszív, ami kevés lehetőséget hagy arra, hogy bármi újat építsen, vagy valódi innovációt tegyen lehetővé.
• Az ügyfele valószínűleg nincs tisztában az új technológiákkal, vagy egyszerűen nem tudja, mire van szüksége.

Ebben az esetben Ön az ügyfelére támaszkodik, hogy a belső követelményeit specifikációvá alakítsa át az Ön számára, ahelyett, hogy Ön írna követelményeket egy olyan termékhez, amelyre a szélesebb piacnak szüksége van, és amelyet meg is fog vásárolni.

A termék fejlesztése során a csapatának különböző okokból elkerülhetetlenül kompromisszumokat kell kötnie. Az egyetlen módja annak, hogy megbizonyosodjon arról, hogy a legjobb döntést hozta meg, az, hogy az ügyféllel közösen felülvizsgálja a kapott termékleírás módosításait. Ha ezt nem teszi meg, akkor fennáll annak a veszélye, hogy olyan terméket készít, amelyet nem fogadnak el. Mivel azonban a tervezőcsapat rendkívüli nyomás alatt áll, hogy agresszív ütemterv szerint végezze el a munkát, nagy az esélye annak, hogy a legjobb információk nélkül kötnek kompromisszumokat a termékkel kapcsolatban. Ez tovább növeli a rossz termék megépítésének kockázatát.

Ez a megközelítés annyiban működik, hogy a terméket leszállítják. Ha az Ön üzletága az árucikkek szállítása, akkor ez rendben van. Ha olyan egyedi megoldást keres, amely megvédi a bruttó árrést, akkor nem ez a legjobb megközelítés.

HEZ KAPCSOLÓDÓ POST: Hogyan végezzen jobb hatáselemzést az upstream és downstream kapcsolatokon

2. Egy mérnök írja meg a teljes specifikációt

Egy másik gyakori forgatókönyv az, amikor egy mérnök vagy a csapat más, az ügyfelekkel foglalkozó tagja egy vagy néhány ügyféllel folytatott beszélgetés alapján képzeli el a megoldást. A csapat összefog az ötlet körül, és a belső lendület hatására a követelmények gyorsan dokumentálásra kerülnek, és a csapat erőfeszítései gyorsan a termékleírás megírására és a megoldás kifejlesztésére irányulnak.

Mihelyt a megoldás elkészült és készen áll a piacra lépésre, egyes csapatok validálják az ötletüket az ügyfelekkel, de mivel a csapat egy megoldást mutat be – nem pedig egy igényt vizsgál -, a vita általában a termékleírás részleteiről folyik. Ezeknek a csapatoknak nem lesz lehetőségük arra, hogy kiderítsék, hogy a megoldás megold-e egy problémát.

Tipikusan ebben a forgatókönyvben a termékkövetelmények egyenesen egy egyén fejéből származnak, majd egy hosszú specifikációs lapban rögzítik őket, és a csapat többi tagja a dokumentált specifikáció alapján bonyolítja le az ügyleteket. Bármikor, amikor a csapat olyan konfliktusba ütközik, ahol kompromisszumot kell kötni, a követelményeket író egyénnek önállóan kell döntenie a helyes kompromisszumokról, kevés új információ birtokában vagy anélkül. Ráadásul, ha ez a személy nem kutatta és nem validálta a követelményeket, akkor a csapat rossz terméket fog építeni.

Miért nem vezetnek sikerre ezek a megközelítések

Az előző két megközelítésben az a közös, hogy a hangsúly a kész termékleírás minél gyorsabb elérésén van. A csapatok annyira sietnek, hogy elkezdjenek valamit építeni, és teljesítsék az ügyfél által megadott határidőt, hogy előbb nem győződnek meg arról, hogy a valami a megfelelő valami.

A követelmények ismerete ráadásul a csapatban csak egy embernél van meg. Ez az egyén vagy az a személy, aki a szponzor ügyféllel kapcsolatot tart, vagy az, aki a termékötlettel előállt. Mindkét esetben a csapat többi tagja nem ismeri a megoldás kontextusát, azt, hogy miért építik meg ezt a terméket, és ezért nem tudnak ajánlásokat tenni.

Az eredmény gyakran az, hogy a termékek később halnak meg, mint kellett volna, miután sok időt és pénzt elvesztegettek, vagy a csapatok olyan termékeket hoznak létre, amelyek sikertelenek, vagy olyan me-too termékeket, amelyek nagyrészt az árral versenyeznek. Ezek egyike sem tesz jót az üzletnek.

Kapcsolódó hozzászólás:

A termékleírás készítésének legjobb módjai:

A legjobb módja annak, hogy olyan termékeket hozzon létre, amelyeket az ügyfelei megvesznek, az, hogy kimegy és beszélget a célpiacával, jóval azelőtt, hogy elkezdené megírni a specifikációt. Először is meg kell fogalmaznia a problémafelvetését.

A termék problémafelvetése néhány mondat vagy bekezdés, amely leírja a piaci igényt. A problémával rendelkező személy szemszögéből íródnak, és – ez a kritikus – semmit sem mondanak arról, hogyan lehet ténylegesen megoldani a problémát. A feltárás ezen szakaszának célja, hogy a probléma megértését és a megoldásával kapcsolatos értékérzetet közvetítse.

A problémakifejtés általában három részből áll:

1. Az első a személyiség, vagyis annak leírása, hogy kinek a problémája van. Hasznos, ha a személyiséget külön-külön nagyon részletesen leírjuk, majd a probléma-megállapításban hivatkozunk egy adott személyiségre, hogy ne ismétlődjön ugyanaz a személyiségleírás.
2. A következő a probléma leírása. Itt minél részletesebb, annál jobb. Biztosra akarsz menni, hogy a szükséglet kristálytiszta legyen. Adjon a problémának egy nevet is. Ez megkönnyíti a csapatok számára, hogy a projekt során visszautaljanak rá.
3. Végül írja le, milyen gyakran fordul elő a probléma. Ha a probléma ritkán fordul elő, és hatása csekély, akkor megoldása alacsony értékű. Ha a probléma gyakran fordul elő és nagy hatása van, akkor a megoldásának értéke magas.

Azzal kezdheti, hogy megkérdezi az ügyfeleket, milyen problémáik vannak, amelyeket szerintük meg tud oldani, de mélyebbre kell ásnia, hogy eljusson az igazán értékes problémamegállapításokhoz vagy aranyrögökhöz. Ezek az aranyrögök általában a piac mély megértésének kifejlesztéséből és a legkülönbözőbb forrásokból származó információk összerakásából származnak.

Ha ezt sikeresen végzi, akkor a végén olyan problémát fog azonosítani, amelyet meg tud oldani, és amelyért az ügyfél fizetni fog.

A folyamat során ügyeljen arra, hogy ne fusson bele hamis pozitív vagy negatív eredményekbe. Ha túl sokat hallgatja a vállalaton belüli embereket vagy csak egy kis számú ügyfelet, az ahhoz vezethet, hogy tévesen érvényesít vagy elhagy egy problémát. Beszéljen annyi ügyféllel, amennyivel csak tud, és gyűjtsön minél több adatot.

Visszatérjünk vissza az összes lehetséges termékről készített ábránkhoz.

Ezúttal a korlátokat jelképező, egymást metsző vonalakat adtunk hozzá. Ha a problémamegállapításokra úgy gondolunk, mint a kört metsző vonalakra, akkor egy jó, a piac megértésén alapuló problémamegállapítás behatárol egy olyan területet a körben, amely az összes elfogadható megoldást képviseli. Bármi, ami ezen a területen belül van, megoldja a problémát, és elfogadható lenne az ügyfél számára.

Megfigyelheti, hogy ennek a területnek a mérete jóval nagyobb, mint az előző RFQ és termékötlet köröké. Ennek az az oka, hogy ezek a problémafelvetések és a kontextus szándékosan a lehető leglazábban határolják le a megoldást, hogy lehetővé tegyék az új ötletek megjelenését.

Az ötlet lényege, hogy a tervezőcsapatnak maximális rugalmasságot adjunk a korlátok között a lehető leginnovatívabb megoldás megalkotásához.

KÖZLEMÉNYEK: Checklist: Követelménykezelő eszköz kiválasztása

Hogyan jutunk el a végső problémameghatározásig?

Itt vannak a javaslataim:

1. Kezdje azzal, hogy minden projektben kijelöl valakit, akinek az a feladata, hogy az ügyfél hangja legyen.
2. Ezután bízza meg ezt a személyt a piaci problémák azonosításával, kizárólag a piacról gyűjtött információk alapján.
3. Gondoskodjon arról, hogy ezeket a piaci problémákat dokumentálják és olyan helyen osszák meg, amelyhez az egész csapat hozzáfér.
4. Írjon le egy indoklást minden egyes piaci problémamegállapításhoz, amely elmagyarázza, hogy miért probléma, és mennyire fontos a megoldása
5. Adjon hozzá egy mérföldkövet a projekttervhez, ahol a problémamegállapításokat a csapatnak az üzleti érvvel együtt át kell néznie és jóvá kell hagynia.
6. Amint a csapat elkezdi a megoldás kidolgozását, rendszeresen térjen vissza a problémamegállapítások listájához, hogy mindenkit emlékeztessen arra, mi a cél.
7. Minden egyes problémára rögzítse a probléma megoldását szolgáló termékjellemzők listáját.
8. Ha valamelyik probléma nem oldható meg teljes mértékben, vizsgálja felül újra az üzleti tervet, hogy megbizonyosodjon arról, hogy a termék még mindig életképes.

A problémamegállapítástól a specifikációig

Most, amikor már megvannak a problémamegállapítások, és a csapat megismerkedett velük, kezdje el közösen kidolgozni a termék specifikációját. Mivel a csapatban mindenki érti a megoldandó problémát, mindenki hozzá tud járulni a specifikációhoz.

Mivel már elvégezte az előzetes munkát a megoldandó probléma azonosításával, az azonosított korlátok között, és a csapata többféle megoldást is mérlegelt, elegendő információval rendelkezik a termékleírás megírásához.

A termékleírás kis tételekben történő kiadása

A legjobb megközelítés itt az, ha a specifikáció kis darabjait a lehető leghamarabb kiadja a csapatnak, hogy gyors visszajelzést kapjon. Ez segít elkerülni a rossz útra való időveszteséget, és sokkal könnyebbé teszi a csapat számára, hogy minőségi visszajelzést adjon.

Nem győzte meg? Gondoljon erre: Mi történik, ha egy 200 oldalas specifikációs lapot kap felülvizsgálatra? Valószínűleg átnézi az első néhány oldalt, majd átfutja a többit.

Most mi történik, ha egy egyoldalas dokumentumot kap? Valószínűleg átnézi az egészet. Kétszáz egyoldalas dokumentum sokkal jobb visszajelzést fog eredményezni, mint egyetlen 200 oldalas dokumentum.

Hivatkozzon a problémaleírásra, hogy biztos legyen benne, hogy a helyes úton jár

A specifikáció kidolgozása közben is ellenőrizze, hogy a termék továbbra is érvényes megoldást jelent-e a problémára. Könnyen belefeledkezhetünk a termékfejlesztésben rejlő kompromisszumokba, és elfelejtjük ellenőrizni, hogy még mindig a célon vagyunk-e.

Ez a megközelítés az érdekelt felek elvárásait is kezeli. Mivel a folyamat irányított, van egy olyan keret és átláthatóság, amely megakadályozza, hogy bárki felülbírálja a döntéseket. A projekt bármely pontján képes leszel pontosan elmagyarázni, hogy milyen értéket kínál a terméked, és miért kell rendelkeznie a csapat által meghatározott funkciókkal.

A termékek piaci igényekhez való tervezése kritikus a sikerhez

Megértem, hogy egyes iparágakban ez nagy változást jelent ahhoz képest, ahogyan a termékeket eddig tervezték és építették. De ahogy a piacok egyre versenyképesebbé válnak, és a termékek egyre összetettebbé válnak, az, hogy csak egy újabb iterációt szállítunk valamiből, amit már korábban megépítettünk, nem fogja sokáig fenntartani az üzletben.

Ha többet szeretne megtudni arról, hogyan kell úgy írni a követelményeket, hogy minden érdekelt fél világosan megértse a fejlesztési igényeket, töltse le a Best Practices for Writing Requirements című e-könyvünket.

READ THE EBOOK