如何高效传递需求？

做一个产品时有多个角色参与到各个环节，每个角色对需求的理解可能都有偏差，这样就会导致做出来的产品南辕北辙，不符合客户的真实需求，导致产品失败。

产品经理获取需求后，对需求进行分析，并把需求传递给其他角色，包括但不限于：项目经理、开发、测试、QA、运维......

如何高效传递需求，是产品经理的一项重要技能。

注意，这里说的不是“写需求文档”，而是“传递需求”。

“传递需求”意味着不仅仅是写需求文档，还要应用多种手段帮助他人理解需求，减少信息损耗。

本文将分享高效传递需求的几个实践方法：

• 一图抵千言：用产品原型、可视化需求模型传递需求

• 写需求文档的原则与要点

1. 一图抵千言

传递需求有很多形式，不同的形式效果也不同。

有个公式“文 ”，说的是：文字的呈现效果不如表格，表格不如图片，图片不如动画、演示。

俗话说的“一图抵千言”也是这个意思。所以我们在需求传递的时候要尽量多用产品原型、可视化需求模型、图片、演示。

1.1 产品原型

通过产品原型可以帮助他人理解你的产品要做成什么样子，以及产品设计概念。

常见的产品原型有如下几种形式：

• 纸上原型（用纸、笔画出草图、线框图）

• 界面交互原型（用Axure、墨刀等制作）

• 故事板（用漫画的形式展示产品的使用场景）

• 实物原型（可以用3D打印机制作硬件产品的原型）

• 视频原型（用视频、动画的形式展示产品的外观、特性、使用场景）

• 表演（用小品、角色扮演的形式展示产品的特性、使用场景）

对于软件产品来说，纸上原型、界面交互原型是很经常使用的原型。

一般是先用纸上原型画出低保真原型做初步的沟通确认，然后再用Axure、墨刀等原型工具画出高保真的界面交互原型。

当我们使用Axure、墨刀做界面交互原型时，通常要包括以下内容：

• 界面原型

• 页面交互效果（包括页面之间的跳转）

• 页面的标注

• 业务流程图

• 页面结构图

界面原型：

页面交互效果（墨刀可以直接生成页面之间的跳转关系，如下图）

对页面上的重要元素、注意事项、提示信息等要标注出来：

对复杂的业务处理流程，可以画出业务流程图：

在页面很多的情况下，用页面结构图画出页面的层次结构关系：

关于制作原型的几点建议：

• 尽量应用现有模板与素材，可以提高效率

• 不要创造价值不大的新交互方式，不要增加用户的学习成本

• 当你在画原型缺乏思路时，竞品是最好的老师（竞品分析）

• 不要在原型上花太多的时间做出特别炫酷的交互效果，原型最大的价值是用来沟通并获得反馈，不是炫技！

• 够用就好，不求精细，胜在快速

• 投入的精力越多，越舍不得放弃，越怕别人提出不同意见

• 做好原型随时被推翻的思想准备

• 推荐的需求传递形式：图（以原型图为主）+文（文字补充描述）+当面沟通

1.2 可视化需求模型

除了产品原型，还有其他几种可视化需求模型有助于传递需求。

• 范围图

• 业务流程图

• 用例图

• 状态图

• 数据流图

• 决策树与决策表

• 实体关系图

下面对几种可视化需求模型做个简单介绍，有需要的话可以百度一下进一步学习。

• 范围图

范围图(context diagram，也称为上下文关系图)通过描述待开发的系统以及与它有交互关系的外部实体（人或系统），来明确系统的边界和范围。

下图是某选课系统的范围图。

• 业务流程图

业务流程图用来描述业务处理的流程，可以用UML中的时序图或活动图来体现。

• 用例图

用例图从用户视角展示系统外部角色与系统之间的关系。

状态图

状态图描述产品所有可能的状态以及事件发生时状态的转移条件。

数据流图

数据流图（Data Flow Diagram）从数据传递和加工角度，以图形方式来表达系统的数据在系统内部的流向和加工处理过程。

决策树与决策表

软件系统中经常要处理复杂的逻辑，不同的条件组合使系统产生不同的行为。

复杂的条件组合逻辑可以用决策树或决策表来描述。

决策树：

决策表：

实体关系图

实体关系图（也称E-R图）用于对数据关系进行建模，是一种提供了实体，属性和联系的方法，用来描述现实世界的数据模型。

以上介绍的几种可视化需求模型，都有各自的适用场景，可以根据你的需要选择合适的表达方法，在传递需求、编写需求文档时使用。

写需求文档的原则与要点

2.1 用产品思维写需求文档

可以把需求文档当做一个产品，用产品思维来写需求文档，从产品的角度思考如下几个问题：

为什么要写？【价值】

用户（读者）是谁？【用户】

什么时候写？【场景】

用户（读者）关心什么内容？【需求】

如何写？【解决方案】

需求文档的读者可能有下面这些，他们的关注点各不相同：

• 高管、投资人：关心为什么做这个产品、有什么价值，项目的范围、做这个产品的成本与收益。

• 客户、市场部、销售人员：需要知道要交付给他们什么产品。

• 项目经理：根据需求文档估算这些需求的日程安排、工作量和资源。

• 软件开发团队：需要知道要开发什么东西。

• 设计师：基于需求文档来做界面设计、交互设计。

• 测试人员：基于需求文档来制定测试计划、设计测试用例、执行测试。

• 维护和支持人员：通过需求文档了解产品各个部分的用途。

• 培训师：使用软件需求规范说明和用户文档来制作用户培训材料。

• 法务人员：确保需求合法合规。

• 分包商：根据需求文档展开外包范围内的工作。

针对不同的读者，需求文档有不同的类型，不同的需求文档的侧重点也不一样，如下表所示。

2.2 避免一句话需求

很多需求是用一句话描述的。

有个真实案例：

甲方：“给我们做一个自动化控制的灯”

开发团队费了九牛二虎之力，设计了一个智能灯，加了多种传感器，能够基于时间、声控、体感、光感的多维度控制，还考虑了子空间继承逻辑、设备控制权限、跟其他智能家居设备联动等等。

甲方：“这些都不是我要的，我就需要能用 APP 远程控制、能设定时间开关灯等就可以了。”

很多团队都接到过一句话需求，一句话描述的需求是不完整的，缺少了很多关键信息。按照一句话需求做出来的东西往往得不到甲方的认可。

一切用一句话描述的需求都是伪需求！

需要有四个关键要素：

我们再看一个一句话需求的案例：

PM：“界面的字体大一些，按钮大一些”（一句话需求）

开发：“哦”（你们就会指点江山，提一些鸡毛蒜皮的小需求）

可以换一种方式来传递需求，把需求的四个要素说清楚，开发人员对需求就会理解得更全面，基于他对技术的理解可能会想出更好的解决方案。

PM：滴滴打车司机端APP的用户是滴滴司机（人物角色），他们在开车时使用手机，而且把手机放在支架上（场景），看不清，而且容易误操作（痛点），所以需要设计成原型里的样子：字体大，按钮大（解决方案）

开发：“懂了！建议再增加语音提示，滴滴司机在开车时会更方便”

PM：“好主意！”

2.3 结构化描述

在编写需求文档的时候，按照金字塔原理，要遵循“先整体后局部、先概要后细节”的原则。

下图是一个典型的SRS（软件需求规格说明书，相当于PRD）目录结构，就是按照“先整体后局部、先概要后细节”的原则来组织的。

2.4 清晰具体，避免歧义

需求文档就像是说明书，严谨比有趣更重要。

清晰具体比简洁抽象跟重要。尽量避免使用无法衡量的形容词、副词等，如：方便、更快、非常、大概、可能、经常、也许、若干、少许......

在需求文档中统一术语，用术语表、词汇表来解释术语的含义，避免歧义。

请你评审下面这些需求描述，你知道问题出在哪里吗？知道怎么改进吗？

• “全面提升客户服务质量”

• “金额较大时需要上级审核”

• “系统要支持高并发“

• “面对恶意的用户，系统要......”

• “系统要防住羊毛党”

• “支付超时要取消订单”

• “设备的振动幅度要在可接受的范围内”

• “5天内的休假申请不需要总监审批。”

• “商品重量在3kg与5kg之间按10元快递费结算。”

• “在接收到外部信号后，系统必须快速地发送反馈信号。”

• “当主机出现故障时，系统必须能够无缝切换到备用机。”

• “通常情况下只有一辆列车在该区间运行。”

• “后台任务管理器必须以不少于60秒的固定间隔来提供状态消息”

• “设备测试器必须允许用户轻松连接上外部设备，包括心电图机、脑电图机、血压测量仪等。”

• “设备在振动/冲击中必须能够正常运作。”

• “系统要有足够的易用性。”

2.5 充分考虑异常

在需求文档中描述业务处理流程时，不能只描述正常处理流程，还要描述异常处理流程。

例如，去ATM机取款时，正常处理流程是：

插卡->输入密码->进入系统->输入金额->提取现金->取卡

还要描述各种异常情况的处理，如下图所示：

为什么要在需求文档中描述各种异常情况的处理呢？

因为开发人员在写程序时要充分考虑异常，否则写出来的程序就有bug；

测试人员在做测试时也要针对各种异常情况编写测试用例、执行测试任务，否则就会漏测导致bug逃逸。

例如，在上述ATM机取款的案例中，测试人员要针对各种异常情况设计测试用例：

然后测试人员针对测试用例设计测试数据并执行测试。

在上述测试案例中，如果需求文档没有写清楚异常处理流程，测试人员的工作将无从下手，需要花时间跟需求文档编写者逐一详细确认，一来二去反而要花双方更多的时间。

2.6 不求完美，够用就好

需求文档要细化到什么程度？是不是写得越详细越好？

这要看情况。

下列情景中，包含的细节要多一些：

• 开发和测试工作要发外包

• 项目团队成员分散在不同的地区

• 新组建的团队、做全新的项目

• 基于需求进行系统测试

• 需要有需求的可追溯性

下列情景中，包含的细节可以少一些：

• 企业内部自用系统的需求文档

• 客户广泛参与

• 开发人员有相关领域的经验

• 有前例可循，优化现有的项目

另外，文档的详细程度与团队采用的开发方法论也有关系。

瀑布式开发方法论倾向于在前期尽量定义清楚需求的细节。

而敏捷开发项目倾向于逐步细化，对即将要进入迭代的需求会描述得详细一些，而其他需求先用用户故事简要描述，待到要开发时再细化。

总而言之，需求文档不是写得越细越好。

不求完美，够用就好。