Nejlepší a nejhorší způsoby tvorby specifikace produktu

Jednou z největších výzev, s nimiž se potýkají týmy zabývající se vývojem produktů, je prosté rozhodnutí, jaký produkt vytvořit. V případě týmů, které pracují na základě specifikace produktu, zejména při vývoji hardwaru, inženýři obvykle nesmějí začít pracovat, dokud není dokončena a schválena. A vzhledem k tomu, že většina časových plánů vývoje je neuvěřitelně krátká, často není dostatek času na zvážení alternativních řešení, jakmile se objeví nové informace.

Jeden ze způsobů, jak se na tento problém dívat, je uveden zde. Můžete si představit, že v kruhu jsou všechny možné způsoby, jak by tým mohl produkt vytvořit. A ta malá modrá tečka je specifikace jednoho konkrétního výrobku. Tato specifikace produktu přesně definuje, na který produkt by se měli vývojáři zaměřit a který by měli vytvořit.

V tomto příspěvku nejprve popíšu některé z běžných metod používaných k odsouhlasení specifikace produktu. Poté se budu věnovat problémům s těmito metodami a tomu, jak mohou vést k sestavování produktů podle specifikace, která ve skutečnosti neřeší problémy zákazníka.

Měl bych říci, že můj pohled vychází z desetileté praxe v oboru analogových a smíšených polovodičů, nejprve jako aplikační inženýr a později jako definátor produktů. Nyní jsem konzultantem zde ve společnosti Jama.

Nejhorší způsoby, jak vytvořit specifikaci produktu:

Poptejte se zákazníka, co chce, abyste vytvořili

Jedním ze způsobů, jak začít, je zeptat se zákazníka, co potřebuje. To můžete udělat tak, že počkáte na žádost o cenovou nabídku (RFQ) vystavenou zákazníkem, nebo méně formálně, prostřednictvím schůzek a diskusí. Obvykle se tímto přístupem dozvíte, jaké řešení nebo produkt dnes používají a co by chtěli ve velmi blízké budoucnosti změnit. Svým způsobem vystupujete jako dodavatel a zákazník je zodpovědný za všechny detaily specifikace.

Vzhledem k tomu, že tento scénář vyžaduje iteraci stávajícího produktu, je vysoce pravděpodobné, že skončíte s velmi konkrétním nápadem, který rozhodně můžete realizovat.

Tento přístup má však několik problémů:

To, co vám zákazník říká o své produktové strategii, pravděpodobně říká i vaší konkurenci a klíčovým cílem projektu je pravděpodobně vytvořit něco levnějšího než stávající řešení. Ocitnete se tak v cenové válce.
Váš zákazník je již nastaven na určitý typ řešení na základě toho, co si koupil dříve, a proto je obtížné navrhnout něco, co by mohlo lépe vyhovovat jeho potřebám.
Harmonogram je pravděpodobně extrémně agresivní, což ponechává málo příležitostí k vytvoření něčeho nového nebo umožňuje skutečné inovace.
Váš zákazník nemusí mít povědomí o nových technologiích nebo prostě neví, co potřebuje.

V tomto případě se spoléháte na to, že vám zákazník přeloží své interní požadavky do specifikace, místo abyste vy psali požadavky na produkt, který širší trh potřebuje a bude kupovat.

Při vývoji produktu bude váš tým nevyhnutelně muset z různých důvodů dělat kompromisy. Jediný způsob, jak se ujistit, že byla provedena nejlepší volba, je zkontrolovat změny výsledné specifikace produktu s vaším zákazníkem. Pokud tak neučiníte, vystavujete se riziku, že vytvoříte produkt, který nebude akceptovat. Protože však bude tým konstruktérů pod extrémním tlakem na realizaci v agresivním časovém plánu, existuje velká pravděpodobnost, že učiní kompromisní rozhodnutí o produktu bez všech nejlepších informací. To dále zvyšuje riziko, že postavíte špatný produkt.

Tento přístup funguje v tom smyslu, že produkt je dodán. Pokud se zabýváte dodáváním komoditních komponent, pak je to v pořádku. Pokud hledáte jedinečné řešení, které obhájí hrubou marži, pak to není nejlepší přístup.

RELEVANTNÍ POSTUP: Jak lépe provést analýzu dopadů na vztahy mezi předcházejícími a následujícími zákazníky

2. Nechte inženýra napsat celou specifikaci

Dalším častým scénářem je situace, kdy si inženýr nebo jiný člen týmu, který se obrací na zákazníka, představuje řešení na základě rozhovorů, které vedl s jedním nebo několika zákazníky. Tým se kolem této myšlenky shromáždí a s přívalem vnitřní dynamiky jsou požadavky rychle zdokumentovány a úsilí týmu se rychle obrátí k sepsání specifikace produktu a vývoji řešení.

Když je řešení dokončeno a připraveno k uvedení na trh, některé týmy ověří svou myšlenku u zákazníků, ale protože tým představuje řešení – nikoliv zkoumá potřebu – diskuse se obvykle vede kolem detailů ve specifikaci produktu. Tyto týmy nebudou mít příležitost zjistit, zda řešení řeší nějaký problém.

Typicky v tomto scénáři pocházejí požadavky na produkt přímo z hlavy jednoho člověka a poté jsou zachyceny v dlouhém listu specifikace a zbytek týmu jedná s využitím zdokumentované specifikace. Kdykoli tým narazí na konflikt, kdy je třeba učinit kompromis, musí jednotlivec, který byl autorem požadavků, rozhodnout o správném kompromisu samostatně, s malým množstvím nových informací nebo bez nich. Pokud navíc tato osoba požadavky neprozkoumala ani neověřila, pak tým vytvoří špatný produkt.

Proč tyto přístupy nevedou k úspěchu

Oběma předchozím přístupům je společné to, že se zaměřují na co nejrychlejší dosažení hotové specifikace produktu. Týmy tak spěchají, aby začaly něco stavět a stihly termín od zákazníka, že se nejprve neujistí, že to něco je to správné něco.

Znalost požadavků má navíc jen jeden člověk v týmu. Tato osoba je buď osobou, která komunikuje se zákazníkem sponzora, nebo je to osoba, která přišla s nápadem na produkt. V obou případech zbytek týmu postrádá jakýkoli kontext řešení, důvod, proč tento produkt vytváří, a proto nemůže dávat doporučení.

Výsledkem je, že produkty často zaniknou později, než by měly, poté, co bylo promarněno mnoho času a peněz, nebo týmy vytvářejí produkty, které jsou neúspěšné, nebo me-too produkty, které konkurují převážně cenou. Nic z toho není pro podnikání dobré.

SOUvisející příspěvek: 8 rad a doporučení pro psaní požadavků

Nejlepší způsoby, jak vytvořit specifikaci produktu:

Nejlepším způsobem, jak vytvořit produkty, které budou vaši zákazníci kupovat, je vyjít ven a mluvit s cílovým trhem dlouho předtím, než začnete psát specifikaci. Nejprve musíte formulovat svůj problémový výrok.

Problémový výrok produktu je několik vět nebo odstavců, které popisují potřebu trhu. Jsou napsány z pohledu osoby, která má problém, a – to je rozhodující – neříkají nic o tom, jak problém skutečně vyřešit. Cílem této fáze průzkumu je zprostředkovat pochopení problému a pocit hodnoty spojené s jeho řešením.

Vyjádření problému se obecně skládá ze tří částí:

První je persona neboli popis toho, kdo má problém. Je užitečné popsat personu velmi podrobně samostatně a pak se na konkrétní osobu odkázat ve vyjádření problému, aby se neopakoval stejný popis persony.
Další částí je popis problému. Čím více podrobností, tím lépe zde. Chcete se ujistit, že potřeba je naprosto jasná. Problém také pojmenujte. Díky tomu se k němu budou týmy v průběhu projektu snáze vracet.
Nakonec napište popis toho, jak často se problém vyskytuje. Pokud se problém vyskytuje zřídka a má malý dopad, pak má jeho řešení nízkou hodnotu. Pokud se problém vyskytuje často a má vysoký dopad, pak bude hodnota jeho řešení vysoká.

Můžete začít tím, že se zeptáte zákazníků, jaké mají problémy, o kterých si myslí, že je můžete vyřešit, ale musíte se dostat hlouběji, abyste se dostali ke skutečně hodnotným vyjádřením problémů nebo zlatým nugetům. Tyto zlaté nuggety obvykle vycházejí z hlubokého porozumění trhu a skládání informací z nejrůznějších zdrojů.

Pokud se vám to podaří, nakonec identifikujete problém, který můžete vyřešit a za který zákazník zaplatí.

Během tohoto procesu si dejte pozor, abyste nenarazili na falešně pozitivní nebo negativní výsledky. Přílišné naslouchání lidem uvnitř vaší společnosti nebo pouze malému počtu zákazníků může vést k falešnému potvrzení nebo opuštění problému. Promluvte si s co největším počtem zákazníků a shromážděte co nejvíce údajů.

Vraťme se k našemu diagramu všech možných produktů, které můžeme vytvořit.

Tentokrát jsme přidali protínající se čáry, které představují omezení. Pokud si představíme zadání problému jako čáry protínající kruh, pak dobré zadání problému podložené porozuměním trhu ohraničí oblast v kruhu, která představuje všechna přijatelná řešení. Cokoli v této oblasti řeší problém a bylo by pro zákazníka přijatelné.

Všimněte si, že velikost této oblasti je mnohem větší než u předchozích kruhů RFQ a nápadu na produkt. Je to proto, že tato zadání problému a kontext záměrně ohraničují řešení co nejvolněji, aby umožnily vznik nových nápadů.

Jde o to, aby návrhový tým získal maximální flexibilitu při vytváření co nejinovativnějšího řešení v rámci daných omezení.

RELEVANTNÍ POSTUP: Kontrolní seznam: Výběr nástroje pro správu požadavků

Jak se dostanete ke konečnému zadání problému?

Tady jsou má doporučení:

Začněte tím, že někomu pro každý projekt přidělíte zodpovědnost být hlasem zákazníka.
Poté pověřte tuto osobu identifikací problémů trhu výhradně na základě informací získaných z trhu.
Zajistěte, aby tyto problémy trhu byly zdokumentovány a sdíleny na místě, ke kterému má přístup celý tým.
Pro každý výrok o tržním problému sepište zdůvodnění, které vysvětlí, proč se jedná o problém a jak důležité je jeho řešení
Do plánu projektu přidejte milník, ve kterém musí být výroky o problémech přezkoumány a schváleny týmem spolu s obchodním zdůvodněním.
Jakmile tým začne vyvíjet řešení, pravidelně se vraťte k seznamu problémových tvrzení, abyste všem připomněli, co je cílem
Pro každý problém zachyťte seznam funkcí produktu, které problém vyřeší.
Pokud některý problém nelze plně vyřešit, znovu přezkoumejte obchodní případ, abyste se ujistili, že je produkt stále životaschopný.

Od problémového tvrzení ke specifikaci

Když máte problémové tvrzení a tým se s ním seznámil, začněte společně vytvářet specifikaci produktu. Protože každý člen týmu rozumí řešenému problému, může každý přispět k tvorbě specifikace.

Protože jste v rámci stanovených omezení vykonali předběžnou práci při identifikaci řešeného problému a váš tým zvážil více způsobů, jak řešení dodat, máte dostatek informací k sepsání specifikace produktu.

Vydávejte specifikaci produktu po malých dávkách

Nejlepším přístupem v tomto případě je vydávat týmu malé části specifikace co nejdříve, abyste získali rychlou zpětnou vazbu. Tím se vyhnete plýtvání časem na špatné cestě a pro tým bude mnohem snazší poskytnout kvalitní zpětnou vazbu.

Nejste přesvědčeni? Zvažte toto: Co se stane, když dostanete k posouzení 200stránkový specifikační list? Pravděpodobně se podíváte na prvních pár stránek a zbytek přelouskáte.

A co se stane, když dostanete jednostránkový dokument? Pravděpodobně si ho prohlédnete celý. Dvě stovky jednostránkových dokumentů přinesou mnohem lepší zpětnou vazbu než jeden dvousetstránkový dokument.

Přečtěte si zadání problému, abyste se ujistili, že jste na správné cestě

Při vývoji specifikace se také znovu ujistěte, že produkt je stále platným řešením problému. Je snadné nechat se unést kompromisem, který je s vývojem produktu neodmyslitelně spjat, a zapomenout zkontrolovat, zda jste stále na správné cestě.

Tento přístup také řídí očekávání zainteresovaných stran. Vzhledem k tomu, že proces je řízený, existuje rámec a transparentnost, které zabraňují tomu, aby někdo přehlasoval rozhodnutí. V každém okamžiku projektu budete schopni přesně vysvětlit, jakou hodnotu váš produkt nabízí a proč musí mít funkce, které tým určil.

Navržení produktů podle potřeb trhu je rozhodující pro úspěch

Uznávám, že v některých odvětvích je to velká změna oproti tomu, jak byly produkty navrhovány a vytvářeny. Ale jak se na trzích zvyšuje konkurence a produkty jsou stále složitější, pouhé dodání další iterace něčeho, co jste již dříve vytvořili, vás na trhu dlouho neudrží.

Chcete-li se dozvědět více o tom, jak psát požadavky tak, aby všechny zúčastněné strany měly jasnou představu o potřebách vývoje, stáhněte si naši elektronickou knihu Best Practices for Writing Requirements.

READ THE EBOOK