产品需求文件

产品需求文档阐明了产品或功能应该做什么、面向哪些用户、为什么需要它，以及它必须遵守的约束条件和衡量成功的标准。它早于迭代开发出现，并且经常被认为是顺序交付的产物而被忽视，但它所满足的根本需求并未消失：大量的工作仍然需要一份共享的、书面的意图说明。

对这种格式的反对，实际上是对这种格式使用方式的反对。一份事先详细规定所有细节、签字确认并视为一年内一成不变的文件，不利于学习，其失败之处也已得到充分证实。而一份阐明问题、用户、预期结果和限制条件，并将解决方案细节留待随着理解加深而逐步完善的文件，则发挥着不同的作用，并且仍然具有价值。

最有用的部分是描述问题而非解决方案的部分。哪些人面临这个问题？有哪些证据表明他们确实面临这个问题？他们目前采取了哪些替代方案？什么样的结果才算成功？哪些内容刻意排除在讨论范围之外？一份以功能列表开头的文档忽略了必要的论证，因此任何人都无法评估这些功能是否合适。

约束条件必须明确列出，因为大多数后期意外情况都源于此。监管义务、安全要求、可访问性标准、性能预期、支持的平台、集成依赖关系和操作限制都会影响可构建的内容，而在此过程中发现这些限制代价高昂。在项目初期记录这些限制成本低廉，并且可以避免完全可以避免的返工。

成功标准是最常被忽略的部分，也是决定投资能否得到评估的关键所在。预先明确工作预期在多长时间内产生哪些可衡量的变化，可以将功能转化为可测试的方案，并使组织能够从结果中学习。如果文档只描述要构建的内容，而不说明预期目标，那么实施后的评估将无法进行。

这份文件应被视为动态的，而非一份已签署的协议。在交付过程中，随着证据的积累和限制条件的变化，理解会不断加深，一份未更新的文件最终会沦为与产品相悖的历史记录。将其作为最新的意向声明，并清晰地记录实质性变更，可以确保后续参与项目的人员能够理解决策背后的原因，从而保持其价值。

未决问题应该单独列出，而不是为了显得果断而忽略。记录下未知事项、负责解决者以及解决期限，可以将不确定性从潜在风险转化为可追踪的工作，并避免常见的情况：在实施过程中，有人误以为问题已经解决，却发现问题尚未解决。

超过一定长度后，文档的实用性会成反比。一份长达四十页却无人问津的文档，无论其内容多么完整，都是失败的。而简洁明了地阐述问题、用户、预期结果、限制条件和未决问题，才能真正产生有人查阅的文档。细节应该体现在需要它的其他文档中，例如设计文档、验收标准和技术规范，而不是堆砌在一份无人问津的文档里。

由于该文件的价值在于建立不同职能部门之间的共识，否则这些部门会基于不同的假设开展工作，因此它需要产品管理以外的各方贡献。实际上，它是在一个……内部产生的。 产品工作室 参与解决问题的证据由 产品研究，这些限制条件已得到确认 产品开发并且，成功标准与 数据分析 这样才能在发射后对其进行实际测量。