【实用长文】需求定义不清？看这一篇就够了（另赠需求分析工具箱）

---

你们现在的团队都有什么痛点？

当我问一个团队这样的问题的时候，经常会得到各种不同的回答，这些回答中，出现频率居高不下的就是：

需求定义不清楚

这种情况下，我通常都会去看一看他们最近的需求文档，然后去找研发团队聊一聊，请他们对每个需求文档说说他们的看法。

先来说说我看到的需求定义的常见问题。要说明这个问题，要从什么样的需求定义是好的定义说起。

1如何判断一个需求文档写的怎么样？

以我的经验，判断一个需求文档写得怎么样，大概可以看三个维度，完整性，清晰度，和效率。

1. 完整性

完整性指的是软件解决方案是否定义完整。

完整性没做好的例子有：

• 只定义了正常业务流程软件的行为，没有定义分支流程的软件行为；

• 缺少交互的定义；

• 接口缺乏定义；

• 缺乏异常处理定义，等等。
  

2. 清晰度

清晰度指的是软件解决方案的描述是否清楚。

3. 效率

效率指的是软件解决方案的描述是否简洁明了。

以上这三个类别是有排序的，

完整性最重要，其次是清晰度，再次是效率。

这就引出了：

2需求定义的常见问题是什么？

大部分需求定义不清楚的问题，其实是定义不完整。

我看到的需求文档存在的首当其冲的问题，就是把上面的这个优先级顺序给弄颠倒了。

这些文档通常都是“效率”优先。

我见过的最“高效”的一个文档，打开来看只贴了一张UI设计图。研发团队用“一脸懵逼“来描述他们看到这个文档的感受。

还有一种观点更加夸张，认为敏捷就是不写文档，或者写一个故事卡片就可以了。

这种情况我通常会给对方看一个简单的需求模型：

这个需求模型，不论你是采用传统的瀑布开发方法，还是采用敏捷，都能用到的。

这个模型的本质，就是PMP倡导的“渐进式规划”。

在初始阶段，我们的定义可以概括一些，但是当要进入开发的时候，需求应该是定义清晰的。

清晰的标准是：团队沟通顺畅，和团队对交付件有一致共识。

如果产品和研发团队有长期的顺畅合作的关系，需求文档才会考虑到效率维度。

而在很多的团队当中，以当前产品和研发团队之间的合作顺畅程度，需求文档根本谈不上拼效率。

所以对于这类团队，我的建议是：先把解决方案定义完整，写清楚，再来说是否花太多时间写文档了。

毕竟写需求文档的本质，不是写文档，而是产品定义。产品定义是一份严肃的全职工作。

你不能说一个开发人员是否花太多时间开发了，同样的，你也不能说一个产品人员，是否花太多时间定义产品了。

在我们开始正式介绍如何写好需求文档（定义需求）之前，我们先来看看：

3需求分析的目的是什么？

有人说需求分析的目的，就是把用户的需求分析一下，拆解一下。

不对。

还记得我在需求总变怎么办？一文中讲的故事吗？

用户提的需求“要做一个手机订餐系统”其实并不是用户的需求，用户的真正需求是“外出办公，中午回到公司还有午饭吃”。

所以，

需求分析的目的是把握用户的真正需求。

要做到这一点，就要把用户的真正需求，和用户为了满足他的需求而提出的解决方案区分开来。

4需求文档包含什么内容？

包含两部分的内容：需求分析和软件设计。

需求分析是弄清楚用户需求是什么，软件设计是设计一个解决方案，来满足用户需求。

举个例子，大热天，用户既不想不出门，也不想动手，但是想要吃饭。这个是用户的需求。

为了满足用户的这个需求，可以有百度外卖，也可以有美团外卖，后面两个就是为了满足同一个需求做出的两个不同的解决方案。

5需求文档的撰写角度

有一种常见的撰写角度就是以产品经理或者开发团队的角度来写。

这样的角度也不是一定不可以，但是这个角度有一个问题，就是很容易把方案写成一个自嗨（自我感觉良好）的方案。

我的建议是：

从用户的角度来写需求文档，这样可以确保不会丢失用户角度。

具体怎么从用户角度来写，请往下看，这个角度会影响到需求文档的各个方面。