2021-04-22需求范式的实践——如何避免需求传导过程中的耗散和扭曲
要尽可能避免这种需求信息的消散和扭曲，我大致有两种方式总结。一是尽量减少传输链的长度，二是尽量让信息被双方理解。
本文记录了我们在项目中尝试的“需求反谈”的实践，以帮助项目团队对需求达成一致的理解。如果能启发和帮助同事，那就非常欣慰了。
需求方的负责人a打电话给我，说已经把需求和需求工程师P说了，但是担心P可能什么都不懂。他又向我描述了需求，说了三件事，balabala，几分钟。他觉得比较简单，让我注意P是否理解需求。因为不熟悉自己的业务背景，在A的演讲过程中，我开始走神。
我找到P，问了一下，发现是A口头告诉他的。他对工作量做了一个估算，在描述的时候他也提到了一些疑惑，但是他已经做好了动手的准备。我让他把要求整理成文件，然后让A组织开会讨论确认。
a约了两个营业部的负责人，然后下午从1: 40开始，讨论到5: 00结束。在讨论中，我们发现了很多之前没有提到的地方，也确认了很多具体的业务场景和功能操作。
经过几个小时的激烈讨论，大家都认为要讨论的要点都讲完了，但是对于P是否理解到位还是不太放心，于是让P倒着讲需求，把使用的角色带入到各个环节的具体场景中，从业务运营的角度讲述完整的业务流程。然后P一开始有点迷茫。简单调整后，他流畅地讲了业务流程和功能操作，发现中间有几处不一致。经过与业务人员的讨论和确认，大家最终达成一致。
这个需求讨论过程费时费力，却避免了后期的一系列返工。
有一天站会上，测试说关于这次迭代的一个测试点需要评审。我提出来，评判的时候，他会先讲需求。
需求分析师和开发人员参加了评审会议，测试工程师根据业务场景将需求串起来。从整体上可以看出，测试人员理解的业务逻辑和需求分析人员理解的业务逻辑是一致的。
需求分析师在发言的过程中，获得了一个旁观者思考需求的视角，发现了以前没有描述清楚的东西，也发现了测试人员没有注意到，但在需求沟通过程中确实提到的东西。
因为每次迭代不会有太多的功能点，所以这次评审的会议时间会在20分钟左右，是一次简单但有效的会议。
需求反转会增加单次会议的时间，但可以避免后期由于理解不一致而导致的重复。
但是如果讨论的内容太多，谈论需求就变得不现实了。所以把需求分成小的迭代进行沟通和确认是非常重要的。
当然，在一次沟通内容较多的情况下，也可以选择个别重点和重要的进行反谈确认。
还有，在向开发解释需求的时候，可以从多个开发工程师中抽签决定谁来反过来讲一个模块，也可以保持参与者的注意力。