需求也是进化的
做产品需求分析时，最怕就是需求不清，场景不明，出现遗漏。用户角色遗漏，用户活动遗漏，或使用场景遗漏，任何遗漏都会造成做出来的东西不是用户想要的。虽然我们经常说”人人都是产品经理“，但是想要人人都做好产品经理却是不现实的。
用户也许在业务领域非常强憾，但在输出需求时却常常让产品经理抓狂，比如说他们会更关注于最终的界面是什么样子，或实现方式是怎么样的。并且由于对于需求目的探究的不够深入，常常在产品开发中后期产生很多逻辑悖论，或规则冲突。
产品经理经验或许足够了，但一个人的脑力毕竟有限，并且如果在业务目标澄清阶段不够深入，也会出现遗漏。
开发和测试就更不用提了，如果按照传统做法，在需求评审时再介入需求，同于大部分需求已经定型了，也错过了深入了解需求和针对需求提出完善意见的最佳时机。
那么影响需求输出的重要因素，除了上面我们明眼可以看出的沟通协作问题外，还有一个隐藏于水面之下的问题 -- 即任何需求都是进化的，是不断拨开云山雾海，不断完善健全的一个演化过程。我们可以通过下面的图例来展现一下这个过程。
73349.png
我们可以看到，从原始需求到可实现的标准大致经历了这样几个阶段：原始需求 ->澄清的业务目标 -> 举例说明 -> 用户操作及操作流程。并且最后基于用例生成的”需求活文档“以支持未来的产品重构等工作。这样就形成了一个需求闭环，并且随着产品的不断完善，不管其角色，角色活动，业务规则如何变更，只要按照这个统一且系统方法来维护和更新需求，我们就可以通过自动化工具从自动化测试用例中生成简单易懂，永不过时的需求活动文档，这对于保存项目知识，支持未来的项目改造及重构意义重大。这即是所谓的实例化需求。另外 Scrum 中的迭代也是推动需求进化的一个重要方式。迭代交付及反馈改进也是确保最终产品交付质量的重要手段。
与这三个步骤并行，团队还应该在需求分析和澄清过程中，持续梳理和澄清所分析领域的概念，建立统一的认知，形成需求沟通的统一语言。而基于 ULM 的领域建模可以很好地实现这一目的。
在关于需求的这两篇文字中，我尝试通从需求协作和需求进化两个角度来说明如何保证需求质量，避免需求不清造成开发风险。综合起来，可以将需求实例化实践进行如下归纳：
- 需求是在所有产品干系人及开发团队的协作中不断进化的。
- 所有产品干系人基于统一的系统，统一的语言建立需求模型。
- 需求的组织和沟通要符合 MECE（无重叠，不遗漏）原则。
- 采用实例说明需求，并通过实例生成自动化用例来验证需求。
- 迭代是推动需求进化的重要手段。
- ”需求活文档“是支持项目改造及重构不可或缺的内容。
