产品包需求定义及分层

产品包需求是指产品交付给客户的显性需求和隐性需求的统称。当前，产品包需求定义以从传统的只关注客户现场静态交付的产品包需求转变为面向关注产品概念、开发、生产、销售、工程交付、维护服务、运营管理全流程的动态产品包需求，全面提升产品包需求质量。产品包需求主要包括7个场景和18个小类需求：

产品包需求按照产品生命周期分为原始需求、初始需求、客户问题、系统特性、设计需求等几个层次：

 如上图所示，需求从最初的原始需求到分配给开发人员设计需要一个需求传递的过程。

• RR

• • 客户的原始需求，全公司都可以提，只要是代表客户的原始诉求
  • 关键是要把客户面临的困难讲出来
• IR
  • 问题+解决方案，相当于原来的OR
  • 问题是针对RR通过根因分析等方法得到的
  • 解决方案不是研发的设计实现方案，是MKT从需求满足度方面提出的方案，比如：蜡烛VS手电筒？
• SR
  • 系统需求，相当于原来的DR
  • 每版本新增VS全量维护，是采用迭代开发还是瀑布开发？
• AR
  • 分配需求，MST的依据
  • 维护的单位：是根据特性来维护V模块来维护？

产品需求为什么需要进行映射？

产品需求在实际传递的过程中，经常出现失真的情况，前端人员的一句话需求、一个电话或一个邮件传递客户需求的情况屡见不鲜，根据共创力咨询的经验，一般的公司均存在以下的问题：

1）输入混乱，没有聚焦客户价值

不同的产品包需求描述差别很大。从特性、内部增强、Bug-fix都有，粒度从几十行到数万行不等，部分产品一个版本甚至有50%以上都是增加一个小特性或修改几个客户端Bug；

2）需求分析输出不能很好的支撑设计、开发、测试、资料

《需求分析说明书》变成参考资料，而不是设计开发必须严格遵守的规约，SE根据DR直接分解设计，开发根据AR直接开发，测试根据对业务和设计的理解，自己设计测试场景和要评估的客户界面需求分析多站在系统的角度描述内部功能、需求片段，甚至不考虑客户如何使用，资料人员无法根据设计文档进行开发，需要SE另外输出素材。很多资料问题，需要SE补充针对性的方案设计才能解决；

3）需求分析漏洞百出，版本设计变更多

据统计每个版本至少有30%的IR/CR是因为上个版本考虑遗漏部分的优化；据统计每个版本因为需求分析导致的设计缺陷占50%以上，有的甚至超过75%，多为场景遗漏，方案错误，客户界面不可预期的变更；

4）需求澄清困难

与客户澄清需求非常困难，一方面渠道不畅，同时我们也缺少能与客户进行需求有效交流的东西，各环节对需求的认知不一致。

需求映射能解决什么问题？

由于产品包需求在传递过程先后经过了市场人员、PDT经理、SE、软（硬）件开发人员、测试人员等不同的角色，因此如果没有一条线索把需求传递的过程串起来，是很容易造成最终交付的产品不能满足用户需求的情况：

因此，共创力咨询认为，需求映射能解决这个问题，将最原始的客户需求与设计需求、测试需求对应起来，才能保证需求的质量，如下图所示：

最后，需求映射的实现可以通过IT平台去实现，如果公司没有现成的IT平台，只能采用手工的需求跟踪矩阵进行管理。共创力咨询在需求映射咨询活动中，积累了丰富的经验。如某客户的案例：

通过需求映射，建立需求与产品版本、产品版本与开发项目、开发项目与需求之间的关联，让需求在传递过程中永远保持与客户需求一致。