软件需求从用户头脑中的构想到最终变成为可工作的软件，会经历一个较长的传递链条。这种传递不同于信息世界里的数据拷贝，更依赖于人们的表达和理解，难以避免过程中信息的耗散和失真。
要尽量避免这种需求信息的耗散与失真，我粗浅的总结下，大概有两种办法，一种是尽量减少传递的链条长度，另一种是尽量让信息在传递时做到双方理解一致。
本篇小文专们记录我们在项目中尝试的“需求反讲”实践，以帮助项目团队对需求达成一致的理解，如果能够对同行有所启发和帮助，即甚欣慰。
场景1：需求反讲在需求开发人员与用户沟通时的实践
需求方负责人A跟我打电话，说他已经将需求和需求工程师P说了，但他担心P不一定都明白了，将需求又跟我描述了下，说就三件事情，balabala，说了几分钟，他认为比较简单，让我可以关注下P是否明白了需求。我由于对业务背景不熟悉，在A说的过程中就开始走神。
我找到了P，大概问了下，发现A是口头上跟他说的，他做了个工作量估计，而且他在描述的过程中还提到了有几个疑惑的地方，但准备开工了。我让他把需求整理成一个文档，然后约A组织个会议讨论确认下。
A约了两个业务部门的负责人，然后从下午1：40开始，直讨论到5：00结束。讨论过程中，发现了好多原来没说到的地方，确认了好多具体的业务场景、功能操作。
经过几个小时的激烈讨论，大家认为要讨论的点都说完了，但对于P理解得是否到位仍然不太放心，于是让P将需求反讲一遍，一定将使用的角色带入各环节的具体场景，从业务操作的角度讲述完整的业务流程。然后P一开始有点懵，经过简单的调整后，比较流畅的将业务流程、功能操作串讲了一遍，中间发现了几个理解不一致的地方，经过与业务人员的讨论和确认，最终大家达成了一致。
这次需求讨论过程较耗时和费神，但避免了后面一系列的返工。
场景2：需求反讲在测试用例评审时的实践
某天的站会上，测试说写了一个有关这次迭代的测试要点，需要评审下。我提出来，评审的时候由他先反讲下需求。
评审会议有需求分析人员、开发人员参与，测试工程师按照业务场景将需求串了一遍，整体上能看出来测试人员理解的业务逻辑和需求分析人员理解的是一致的。
在他讲的过程中，需求分析人员多了一个从旁观者思考需求的视角，发现了自己之前不曾描述清楚的地方，也发现了一些测试人员没有注意到、但在需求沟通过程中确实提到过的内容。
因为每次迭代的功能点不会太多，所以这次评审的会议时间也就20来分钟，简单但有效果的一个会议。
总结一下：
需求反讲会增加单次会议的时间，但能避免后期因理解不一致的反复。
但如果一次讨论的内容太多，需求反讲就会变得不现实。因此将需求拆分成一个一个的小迭代进行沟通和确认，就变得很重要。
当然也可以在一次沟通内容较多的时候，挑选个别关键、重要的进行反讲确认。
还有，在需求向开发讲解的时候，可以从多个开发工程师中抽签，决定谁来反讲一个模块，这样还能够促使参会人员保持注意力。
