郑晔老师在《10x程序员工作法》中给了一个例子，程序员小李接到一个单点登录功能的需求，小李经过几天的奋战写完了代码。

在给产品经理小王演示时，小王对整体很满意，就是觉得不支持验证码不太符合常规设计。但是小李觉得这个需求里面没有提，就没做......

小李觉得很辛苦，小王觉得没做完。我平时接一些私活儿时，也会处于这种局面，根据前期讨论的需求，我很快就做完了，然后拿给用户演示，发现这不是结束，而是刚刚开始。因为用户在一开始并不能把自己的实际需求想得很明白。

描述需求的方式

不同需求的描述方式，可能会影响程序员对需求的理解。

信息传递会衰减，如何传递，直接决定了衰减的比例。

基于功能列表的描述方式

我们公司以及在平时私活儿中，开发模式都是基于功能列表的。

公司项目中负责需求的同事，先会跟用户讨论需求，整理出需求文档，项目经理根据需求文档中的功能点拆分开发任务，开发领到任务开始写代码；私活儿中，我自己扮演了需求与开发兼项目经理的三个角色，干的事情都差不多。功能列表其实只是一些简单的描述，并不能看到全局。这种功能列表式的需求描述方式，将一个完整的需求敲成了碎片，只有所有功能完成时，才是破镜重圆的时刻。

开发过程中，大多数人都无法看到完整的图景，项目会在最后遇到很多意料之外的事情，让大家都手忙脚乱。我们现在公司的项目就出现了这种情况。

如果时多个组协同工作时，这种基于列表的需求描述方式的弊端更加明显。每个组都会按照自己的理解排列开发任务。当你所在的组完成了某功能的开发任务时，却上不了线，因为还要依赖别的组。像之前我做过的一个项目里面 n 个子项目，每个子项目之间会互相依赖，如果还按照基于列表的需求拆分，工作安排，兼职要令人抓狂啊。

“用户故事”需求描述

它需要一个完整的场景，将用户的需求将出来。

一个完整的用户故事包含以下几部分：

• 标题

• 概述

一般的描述格式：As a(Role),I want to(Activity),so that(Business Value)

• 详述

• 验收标准

这里会描述系统的正常操作流程，以及各种异常流程系统的响应。大多数情况，我们都是流程跑通，结果发现要么是正常操作流程不完善，要么异常流程处理不到位。就是因为在写代码之前没考虑清楚。在这一环节给出了本次需求最基本的测试用例，保证了开发人员完成需求最进本的质量。

如果在基于列表的描述方式中，加入验收标准的描述，也会提高协作效率。

关于角色

拿到一个需求后，先分析清楚比蒙头就做好太多。分析需求时，你需要学会扮演各个角色，比如假设自己是用户、是产品经理、是测试，这样你才能分析得更透彻。做出来的东西质量会更高。