产品包与产品包需求.ppt

产品需求管理培训-全流程的产品包需求（OR）工程主办单位：上海普瑞思管理咨询有限公司上海创卓商务咨询有限公司时间：2013年12月20-21日北京；2014年01月03-04日深圳；06月27-28日深圳；11月14-15日深圳价格：￥4800/人(包括授课费、资料费、会务费、午餐等)课程背景：客户的需求不断变化，如何快速高效地推出满足客户需求、具有差异化优势和竞争优势的产品，并最终获得市场的成功，是企业的核心问题！我们发现国内许多科技型企业在产品需求管理方面存在如下问题：1.产品开发没有实现市场驱动，是“闭门造车”，关注技术而不关心客户；产品开发出来后才找客户、找卖点；2.缺乏完备的需求收集、汇总、整理和分析机制，导致研发和市场脱节，需求无法有效传递和落实，相关环节和部门（如：客户、市场部、开发部、测试部等）对需求的理解也不一致，经常针对需求“吵成一锅粥”；3.对客户/市场需求分析不充分、不透彻、不完整，导致产品需求变化频繁，产品开发大量返工，“计划不如变化快”，开发过程“失控”；4.需求管理各个阶段的职责不清晰，也缺乏组织支撑；往往了解市场的不懂技术，懂技术的不了解市场，不知道需求应该由谁负责；5.需求没有有效地分级分层，没有明确不同阶段需求的范围，如何进行需求转换，以及需求分析的目的和方法，更不清楚业界众多需求分析方法和工具如何在不同需求阶段进行恰当运用；6.没有明确规定不同阶段需求应详细到什么程度，需求的表达不规范，需求质量不高，直接影响了不同团队对需求理解的一致性；7.对需求分析工作不重视，认为“不画图/不编码就等于没有干活”，产品需求分析工作持续时间短，需求分析不充分；8.需求在产品开发流程中的分解分配和产品的设计过程不规范，也缺乏对需求的跟踪，导致需求没有得到有效的实现；9.由于需求分析的不充分，使得需求无法成为产品测试的有效输入，导致测试方案和测试用例设计无法保证产品测试的完备性，影响产品质量。

产品包需求如何转化为设计需求来源：汉捷咨询浏览次数： 1509基于市场的创新是IPD的核心思想之一,集中体现为客户需求驱动产品开发.具体实现方式是划分出一个个产品包（Offering）,并根据客户需求（包括外部客户和内部客户）定义产品包需求（OR，Offering Requirements),再将产品包需求转化为设计需求（DR，Design Requirements）,然而通过产品开发实现需求。

那么，产品包需求（OR)与设计需求(DR)有何区别呢？下表列出了两者的定义和主要不同：产品包需求的例子：•扬声器需要110dB低频声音输出•提供简易方便的查看和打印分公司经营数据的功能•减轻臂架自重，载荷能力提高20％•每站平均升级时间30分钟设计需求的例子:•将广播的输出在20～50HZ的范围内放大到115W•在查询功能模块中，设置查看分公司经营数据的功能，可以选择按分公司名称、区域、月份、年份查询，查询结果按表格和图形方式显示，并能即时打印•臂架采用三角型支撑结构，支撑臂从圆形改为工字型,采用高韧性轻型钢材•每次可以同时升级10个机站,加载准备时间60分钟完成,同步升级20分钟内完成,40分钟完成测试确认汉捷咨询发现很多企业在产品开发过程中往往把产品包需求和设计需求混为一谈，获得客户需求(通常客户需求还不充分,也不明确）后就一古脑编制产品需求说明书和规格书,然后匆匆忙忙进入开发阶段。

这是一种典型的欲速则不达的开发方式,往往造成以下突出的问题：•没有理解真正的需求。

缺乏从客户角度对需求进行研究和分析,没有了解客户真正的需求，尤其是潜在的需求。

很多新产品推向市场后虽然也能使用，但无法让客户满意甚至惊喜，就与此问题直接相关。

如过去每款新手机都有短信功能,都能使用,但直到iPhone推出对话式短信格式才使消费者有了很好的用户体验。

•需求出现偏差。

由于前面的客户需求不充分、不清晰,开发人员在进度的压力下,从开发者的角度去定义需求，与实际的客户需求相距甚远。

手机功检自动化项目产品包需求说明书文件编号：版本号：V1.0拟制人：日期：审核人：日期：批准人：日期：湖北众友科技实业股份有限公司目录1 目的 (4)2 适用范围 (4)3 定义 (4)4 概述 (4)4.1产品背景 (4)4.2产品功能和特性 (4)4.3产品应用环境 (4)5 具体需求 (5)5.1功能需求 (5)5.1.1 功能需求1 (5)5.1.2 功能需求2 (5)5.1.3 功能需求N (5)5.2性能需求 (6)5.3属性需求 (7)5.3.1 需要遵循的标准 (7)5.3.2 成本限制需求 (7)5.3.3 可靠性需求 (7)5.3.4 可获得性需求（智力财产、智力资产需求） (7)5.3.5 可服务性需求 (8)5.3.6 可测试性需求 (9)5.3.7 可制造性/可测试性需求 (11)5.3.8 兼容性需求 (12)5.3.9 保密性需求 (12)5.3.10 安全性需求 (12)5.3.11 包装需求 (12)6 参考资料 (13)1 目的对市场规格说明书、财务代表的成本分析、可测试性需求、可服务性需求、可制造性需求进行综合分析，形成一个比较完整的产品包需求，对后续产品开发设计工作提供依据和指导。

2 适用范围手机自动功检系统PDT（Product Development Team，集成产品开发团队）所有成员。

3 定义PDT：Product Development Team，集成产品开发团队，由与产品开发相关的各个功能部门的人员组成。

4 概述4.1 产品背景目前多数手机生产厂商在手机出厂之前，都会从手机消费者的角度出发对手机功能进行检验。

这些功能的验证，绝大多数是由人手工操作并进行人工判断，鉴于手机功能繁多，厂家需要为此投入相当的人力成本、费用成本、管理成本，手机终端厂家需要一套自动化设备能够替代人的手工操作，实现对手机功能的自动化检测，从而降低相应的人力成本、费用成本及管理成本，同时提高检验的效率与质量。

套用《端到端产品包需求模板》模板：设计需求开发指导书（正式模板见上面嵌入文件）Project Manager 项目经理: ___________ Project项目: _________________ Project Phase / Decision Checkpoint:项目阶段/决策评审点√Concept概念 __ Develop开发 __ Launch发布 __ Interim临时__ Plan计划 __ Qualify验证 __ Life Cycle生命周期1将产品包需求分解为设计需求 Decompose offering requirements into Design requirements:1.1.确定操作方式对于每一个产品包需求，根据下面内容对操作方式进行概括，写入表1中：• 操作环境及顾客/用户眼中の操作• 顾客/用户期望の操作• 在成本、尺寸、重量、电源、冷却、环境、制造、服务等方面の操作限制。

• 限制范围内の实际操作• 以下方面所带来影响：成本、质量、上市时间、顾客满意度、兼容性等等• 客户/用户对操作表示出来の任何吃惊（包括正面の和负面の）For each offering requirement, summarize the Operational Scenario by notingin the Table below:• the operational environment and the operation from the customer/user view• the customer/user expectations for the operation• the constraints on the operation in terms of cost, size, weight, power, cooling,environment, manufacturing, servicing, etc.• the actual operation within the constraints• the consequences in terms of cost, quality, time to market, customer satisfaction,compatibility, etc.• any surprises for the customer/user (both positive and negative) for the operation.对操作方式进行概括の一个例子：Another example: Operation产品包需求：从中国偏远地区进行紧急呼叫。