睿见 | 需求分层模型，让需求传递更加精准！

作者|  睿创咨询顾问 李清

正文字数 | 3839字

预计阅读 | 6分钟

IPD最最最核心的思想就是“基于客户/市场需求的研发”，如果所有的研发工作（产品创新类、技术创新类）都能理清楚和客户与市场需求之间的关系，研发工作将变得既有效率又有效益！

可现实情况是，大部分的研发工作都很难绕出“客户也讲不清楚的各种要求”、“客户提出的解决方案”、“我以为的客户需求”等等怪圈，总会出现，明明按照客户的要求做了，可他却总是不满意或不买单！难免有时也会自我怀疑，客户说的到底要不要听，要如何理解客户说的话？

马斯克说“无论谁给你的需求，肯定都是愚蠢的！”，这话有点绝对，克里斯坦森（颠覆式创新之父）说过类似的话，但更加温柔与准确，他说“客户有时好像在误导我们”！

客户绝对不是故意在误导我们，大部分情况下，客户主动提出来的需求，都是根据自己的认知范围提出的需求或解决方案，认知的局限性就可能导致错误。就像福特曾说“如果我问人们要什么，人们只会告诉我他们要的是跑得更快的马。”

比如，一个做发动机的企业，客户要求他们把一个金属部件的旋转速度提高，结果按照要求设计的发动机，在验证现场因为金属部件旋转速度太快，摩擦产生了火苗，引起了小范围的燃爆，因此产生较大的损失！

再比如，一家做家具的企业，当时因为扫地机器人的普及，收集需求时，出现了很多类似的反馈“希望把床脚和柜脚加高，以方便扫地机器人清洁床底和柜底时，自由进出”。后来这家企业真的按照要求把床脚和柜脚加高后，客户反而不买他们的产品了。他们急忙又跑去调研，得到的反馈是“床脚和柜脚太高，显得头重脚轻，不美观”。

这样的例子屡见不鲜，因为大部分客户不是技术专家也不是研发人员，他们并不总是能想出最佳方案，他们不清楚其所要求的功能特性将会如何影响该产品其他更重要的方面，所以他们可能最终并不喜欢企业按照他们要求生产的产品。

对客户需求理解的另一个障碍来自于“过于抽象和模糊的语言”，比如“更快”、“更好用”、“更美观”、“可靠耐用”、“高端”等等。尽管这些描述确实表明了客户期望，但是他们都存在一个问题-描述不够精确，对于设计和研发人员，他们无法对这些语言进行转化，因为这些输入的不准确，导致了太多的变化空间。

为了尽量避免客户可能的误导，我们介绍一个华为用到的需求分层模型。

图：需求分层模型

需求纳入正式的产品设计之前，是由外而内的，从客户视角到产品视角，是不断细化和层层演进的，上图展现了需求是如何一步步转化为设计的语言。

原始需求指用户或客户的痛点、遇到的问题、客户提出的需要和要求等，通常为用户或客户的原话。原始需求通常具有描述的方式多、描述抽象、误导性强等特点，这就是马斯克为什么认为“需求都是愚蠢的”、乔布斯认为“不要听他们怎么说”的原因。

客户可能会用哪些方式描述需求呢？

问题

客户有意无意会和我们诉说他们遇到的困难、使用过程中的不便和阻碍、遇到的挑战和压力，有时轻描淡写、有时情绪激动、有时抱怨连连。如果客户对我们非常信任又有比较高的要求，他们就会用这种方式向我们传递“需求”。可能这种方式传递的语气听起来有点刺耳，但请放下架子，虚心倾听，这是需求收集的最宝贵的信息！

痛点

问题其实属于痛点的范畴，但痛点还包括客户想表达但没表达出来的焦虑、恐惧和挫折，这类信息的挖掘，要与客户有很强的共情能力，因为客户可能说不出来或不能准确描述。

挫折和恐惧，经常联系在一起，因为有了挫折形成了心理障碍，因此对未来的类似情况产生恐惧。比如在社交中曾经遇到过被拒绝的挫折而产生社交恐惧；再比如，看到了长辈或周围人不幸福的婚姻而产生了对婚姻的恐惧等。

这类信息通常不被轻易获取，因此需要我们提高共情和洞察能力！

需要和要求

很多人说需求最简单的理解方式就是“需要”和“要求”，需要是指因缺乏而产生的渴望，往往较为宽泛和抽象，通常是个体或组织的期望，可能涉及到多个方面和领域，但通常不会过于具体；要求是提出具体的条件和特定的目标，希望能够满足或实现，通常是具体、明确和可量化的。

2B的客户经常通过招标的形式把自己的要求写入标书，但标书的需求大部分是客户能够确定的功能类需求，客户对他们不太清楚的非功能需求往往比较忽视，但如果不满足就会影响整个系统的有效性，例如可靠性、安全性的需求。因此尽管2B客户提出要求相对明确，但需求大概率不全面，要形成完整与精准的需求描述还需要更深入的洞察和挖掘。

2C企业的客户巧合相反，他们通常不会表达的太具体，语言通常较为宽泛和抽象。

无论哪种描述方式，要么可能有误导性、要么抽象模糊，因此需要进一步分析，分析后就形成了“初始需求”。

我们举两个分别来自2B与2C行业的原始需求案例，后续会随着初始需求和系统需求概念的介绍，逐步完成需求的转化：

原始需求A（2B案例），针对在工况中施工的工程机械车，客户提出的原始需求描述为 “行走时设备容易发生下陷，下陷后设备会自动停机，影响施工效率”。

原始需求B（2C案例），有一个做电脑包的企业，他们收到一条客户的抱怨，原始需求描述为 “我的电脑包在恶劣的天气里几乎没用!”。

初始需求是经过需求分析后，站在客户角度，以完整的场景、标准的格式，重新描述后的需求，通常不包含解决方案！

需求分析包括需求过滤、分类、排序和诠释四个步骤，在IPD体系中是由需求分析团队RAT（Requirement Analysis Team）组织开展的活动，如果没有RAT，也可以交由类似“产品管理”、“产品经理”等角色组织。

如果需求状态为初始需求，意味着已经被上述四个步骤轮番轰炸过，是优胜劣汰下来的具备一定市场价值，且需求诠释中所有必填的信息均已准确，包括需求的场景、分类、描述等信息。

上述两个案例中的原始需求经过需求过滤被保留了下来，但描述的都比较抽象，因此接下来，我们需要将原始需求转化为初始需求。

案例A，经过RAT与需求提交人的充分沟通，确定需求发生的

-  场景是“在施工过程中，由于积水导致的土质松软” ；

-  在这种场景下，设备产生下陷的原因是“接地比压过大” ；

-  问题是“当设备接地比压超过一定临界值，设备会下陷，下陷超过Xcm，设备就会发生故障停机；

-  给客户带来的损失是“处理该种故障需要XX小时，如果不停机客户的产值为XX万元”。

案例B，经过同样的分析方式，确定需求发生的

-  场景是“非常恶劣的环境中上下班，比如机场安检、高铁安检、客户的施工现场、暴雨”等环境

-  在这些场景下，电脑包经常被“挤压、磨损、划伤、淋湿”

-  问题是，被挤压的电脑包可能会刮花电脑，被磨损划伤的电脑包会变得老旧、被淋湿的电脑包会让电脑报废…

-  给客户带来的损失是，很有可能损失一台宝贵的电脑，丢失了电脑中宝贵的数据，无法跟客户交流，失去客户的信任…

到此，这两个原始需求才被完整的表达清楚，让我们更清楚的知道客户到底要什么，他为什么有这些需求和抱怨。再加上需求的分类和排序，才算达到了“初始需求”的状态！

初始需求描述时一定要保证需求的完整性，必须充分地挖掘信号微弱的、隐形存在的需求。需求在分析、加工和传递过程中，更不能丢失。基本需求、核心需求等重要程度高的需求如有遗漏，将导致后续不必要、高成本的需求变更！

系统需求是支撑初始需求所需要的具体要求，系统对外呈现的、可测试的全部功能和非功能需求，有时带有初步的解决方案。

从系统需求开始，需求描述的语言开始转化为非常精准的对系统的功能和参数的要求，他是研发用于内部交流的语言。描述时通常带有“通过XX方式，带有XX功能、达到XX状态、达到XX参数要求”等字眼，还要加上需求测试与验证方式等内容。

初始需求和系统需求不完全是一对一的关系，有时一对多，有时多对一，即一条初始需求可对应多条系统需求，多条初始需求可能对应一条系统需求。所以要特别注意当初始需求转化成系统需求时，不要遗落系统需求。

案例A中，为了满足初始需求，系统需要描述为：

1.     接地比压做到≤0.2MPa

2.     在泥岩或砂岩底板条件下，可爬坡18度

3.     在松软土质条件下，行走速度可达12m/min，行走扭矩≥120000Nm

案例B中，为了达到初始需求，电脑包需要具有如下三种能力：

1.     防御各种恶劣天气

2.     防水

3.     防摩擦

很多时候，我们跟客户交流的需求太具体、太明确，一下子就到了系统需求层，如果不去推导系统需求到底支撑了什么初始需求和原始需求，就可能会被客户误导，或丢失其他相关的系统需求。这就是为什么如果我们研究客户的需求，一定要遵从这个需求分层模型的原因。

需求在信息化系统中的层层转化如图所示:

分解分配需求是将系统需求分解到产品架构（逻辑架构/物理架构）中，将转化为产品架构中的部件和子系统的设计要求（子系统/部件需求）以及产品规格。

将系统需求分配到产品架构的操作逻辑，

汽车产品的空车重量是所有模块的重量之和，而汽车产品的空车重量要求，就要分解为各个模块的重量要求。

在可配置产品中，配置需求也是客户需求的一部分，需要在系统需求的分配和分解时，建立起系统需求与分类特性的关联关系，以确保配置需求与分类特性的一致，示例如下：

通过上述讲解，相信你也发现了，整个过程会产生多个文档，每个文档之间又可能有千丝万缕的关系，因此为了让需求不丢失、可回溯、可被跟踪管理，强烈建议企业导入端到端的需求管理信息化工具！

希望今天关于需求分层模型的分享，能给你带来一些启发！

备注：分解分配需求案例来自于公众号：数字化演绎