在整个研发过程中，需求方（通常是产品经理）与研发团队之间的需求沟通是非常重要的一环，沟通效率的高低和沟通质量的好坏对交付结果有很大的影响。需求沟通的最重要目标是让各方对需求形成一致的认识，然而这一目标并不容易达到。
据个人在所接触的团队中进行的非正式统计，由于需求沟通问题导致的线上缺陷占比从5% ~ 30%不等，由此造成的损失还是非常可观的。而且低效的需求沟通对团队士气也有不小的影响。团队非常容易陷入一些需求沟通的误区，这直接导致了种种问题的发生。
常见误区
●追求大而全的文档
很多团队需求沟通过程主要是基于需求文档。如果产品、开发和测试各方对需求理解出现不一致，原因常常被归结于文档写的不够好，进而花更多的时间试图让文档内容更详尽，尽可能包含所有的细节，准备需求文档的时间因而大大增加了。
然而据笔者观察，这样做通常并没有产生明显改观。需求沟通的主要目标是各方对需求形成明确共识，虽然我们希望能够有完美的文档来解决沟通中的问题，但是仅仅靠文档很难达到。完美的文档对沟通来说并不“完美”，充分的面对面沟通是必须的。
另外，大而全的文档很容易让大家觉得既然文档很全面照着做就好了，不再需要面对面的沟通，这样会让大家更加依赖文档而轻视直接的沟通。往往让情况变得更糟。
●不重视说清楚“为什么做”以及“为谁做”
在需求沟通过程中，需求背后的目的常常没有传达给开发和测试人员。需求方常常觉得只要告诉团队做什么就够了，至于为什么做大家知道了也没有什么用。
但实际上，了解了“为什么做”对团队的帮助是非常大的，只有真正理解了需求背后的目的才能准确把握需求。而且，只有真正清楚要往哪里去，团队才能主动思考达到目的的最佳方式并付诸于行动。这在不清楚“为什么做”的团队里是不会发生的。
另外，只有真正理解了目标用户。也就是“为谁做”，才能做出用户真正需要的产品。
●为减少时间浪费，尽可能减少参与沟通人数
在很多团队眼里需求沟通是不产生价值的活动，参与的人数太多会浪费大家时间，所以通常在需求沟通活动中开发和测试只派代表参加，会后再由参加会议的人将需求转述给真正做开发的人。
这个过程看似节省了部分人的时间，但是拉长了沟通链条，使得沟通过程中更容易产生各种信息丢失和扭曲，从而加剧了需求沟通的各种问题。
重新理解需求沟通
●文档不代表共识
需求沟通的核心目标是各方形成一致的理解。然而文档本身无论写的多么的完善都不代表各方已经对需求形成了共识。并且主要依靠文档来沟通也并不容易做到让各方形成一致的理解。因为人类语言的复杂性，这个过程中有不少“坑”在等着我们：
●文字容易产生歧义
文字并非我们想象的那样精确，请看下面两个例子：
例一：新汽车牌照
可以解释成“新汽车的牌照”，也可以解释成“新的汽车牌照”
例二：他走了一个小时
可以解释成“他离开了一个小时”，也可以解释成“他走路走了一个小时”
●文字丢失了部分信息
下面这句话读着没什么特别：
我没说过他写了这段代码
但如果说出来时，重音放在不同的部分则会表达出不同的信息。
我没说过他写了这段代码
我没说过他写了这段代码
我没说过他写了这段代码
我没说过他写了这段代码
我没说过他写了这段代码
但是以文字的形式输出这些文字时，这样的信息就丢失了。
●“知识的诅咒”让事情变得更糟
“知识的诅咒”，简单说就是人们在沟通一件事时，会不自觉的假设别人对这件事和自己有一样的了解，进而在解释给别人的时候，因为信息不对等，很可能会无意识的遗漏一些重要信息，从而造成沟通的困难。当在陌生的地方问路时，就很容易体会到“知识的诅咒”。
●对“常识”理解的不一致也会带来困扰
说到“小”瓶的可乐时你的脑海里浮现出的是哪一种？350毫升还是500毫升？对于“小瓶”这个常识，不同的人可能有不同的认识。
所以文档其实很难做到对需求精确、全面、完整的描述，如果读文档的人理解出现偏差，那么各方对需求的理解就会出现不一致。也就是说文档是无法保证各方理解一致，形成共识的。
如果追求大而全的文档，花了大量时间却达不到期望的沟通效果，而且容易使得需求文档中充满细节的堆砌，难以快速理解和分割。所以停止对完美文档的追求是明智的做法。
需求沟通过程中主要靠文档是不现实的，面对面密切的沟通在需求沟通中扮演的角色可能更加重要。
●文档不能代替面对面沟通
前面讲了这么多文档在需求沟通过程中的局限性该如何解决呢？密切的对话沟通（最好是面对面）其实是应对这些问题的最有效手段。有效的对话可以不断的让需求涌现出来，确保尽可能的不遗漏。
下面模拟了团队在电商书籍类促销活动需求讨论的对话过程：
对话过程可以让参与者有机会通过复述和追问的方式反复从不同角度验证自己的理解并不断修正，大多数的需求理解差异在这一过程中可以得到消除。
另外，可视化的方式呈现需求也对需求理解和沟通有很大帮助。
●要有明确达成一致的验收条件
在需求沟通过程中，要对需求理解达成一致需要有具体的可验证的验收条件，需求沟通完成的标志是各方对验收条件达成一致。如果使用实例化需求这一实践方法，形成验收条件就比较容易了。
●需求要包含明确的目标和愿景
不了解需求背后目标的团队相当于不知道前进的方向，只有了解了做一件事背后的目的，才能真正知道怎样才算做好了。即使开始发生了偏差，也可以基于原本的目的，做出正确的判断并进行修正，否则只能被动地按照需求本身的描述来实现，很难自主的、具有创造性的完成任务，这样的团队工作积极性通常也不会太高。
●知道为谁做很重要
需求到底是针对什么样的用户的？有时候这个问题的答案并不是那么显而易见。不同的用户需求很可能会有很大不同，这就需要需求方考虑清楚并清晰的传达给团队。
●沟通环节越多，失真越大
在需求沟通环节比较多的团队中，通常沟通效率都不会太高，而且因为信息传递环节太多，有相当比例的问题源自于沟通过程中的信息丢失或扭曲。缩短沟通链条肯定是努力的方向。
一些有效实践
●用户故事
采用用户故事来描述需求并以此为基础进行需求沟通是敏捷开发中的一种做法。它的核心理念可以通过3C来描述：
卡片（Card）： 一般在小卡片上写着故事的简短描述，工作量估算等。
交谈（Conversation）：背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）：通过验收测试确认用户故事被正确完成。
其意在于通过简化需求描述来鼓励面对面直接交流，并对验收条件达成一致的方式来实现更有效地需求沟通。
用户故事的形式“作为……，我可以……，以便……”包含了我们刚才提到的需求的两个重要方面：用户和目的。
●追求快速反馈
即使需求沟通过程非常有效，还是会存在个别漏网之鱼，这时“实现快速反馈”就成了补救的下一道重要防线，我们可以通过尽早实现可运行的功能，在进入测试和验收环节中及时地反馈并修正错误。反馈越早，修正的代价越小。
●需求实例化
顾名思义就是用实例来说明需求。也就是从用户场景出发，用操作实例来澄清需求。基于具体的实例非常有助于保证各方对需求理解的一致性。其基本形式是“在什么情形下什么操作会得到什么结果”。我们还是以电商书籍类促销活动为例，下面用实例来描述“清华出版社购书免邮费优惠活动”这一需求：
可以看到，通过实例化让需求的描述更加具体明确，更容易理解。再结合Cucumber、RobotFramework等工具就可以实现验收测试的自动化了。
结语
需求沟通需要紧紧围绕目标，即让所有人对需求形成一致的认识。我们有各类沟通的手段：文档、邮件、即时消息工具、电话或面对面交谈等。这些手段各有各的优点，但要想达到需求沟通的目的，我们应该使用电话或面对面交谈作为核心的沟通方式，其它方式也需要，但应该作为辅助手段。再结合本文提到的其它一些实践方法，需求沟通便不再是一件痛苦的事！
本文作者
