我做产品管理已经很多年了。我很清楚地记得写产品需求文档（或者所谓的PRD，市场需求，业务需求，功能规格说明书等等）的感觉。但是，我最后一次编写这类文档已经是2005年的事情了：这并不是因为我觉得写这些东西的工作量很大（虽然，工作量确实很大），而是因为它们根本没用。
除非你是在制造一个核反应堆或类似的高风险、资本密集型产品，否则在弥合客户需求和试图构建解决方案的团队之间的隔阂方面，使用需求文档是最糟糕的办法。
为什么？让我们一一道来……
为什么产品需求文档如此糟糕
1. 浪费。一个产品中只有很少的功能是被真正需要的，把所有的东西都设定为需求，我们就忽视了优先级，忽视了去实现客户真正需要的、能解决他们的问题的东西，这就为功能的蔓延埋下了隐患。这种功能蔓延是对精力和资源的巨大浪费。早在2006年，Standish Group的报告就显示，即使在成功交付的项目中，也有45%的功能从未被使用过！
图片说明：
在一个 "成功 "的IT项目中，如果采用串行方式进行需求收集和文档化，交付功能实际使用情况的平均百分比。
从未用过：45%
很少使用：19%
偶尔会用：16%
经常使用：13%
一直在用：7%
（来源：Chaos Report v3, Standish Group）
"软件开发一直被'需求'这个词所误导。'需求'在字典中被定义为强制性的或必须的东西。这个词带有绝对和永久的含义——这是对拥抱变化的抑制。'需求'这个词是完全错误的"。
—— Kent Beck，《解析极限编程——拥抱变化》
2. 需求文档关注的是解决方案，而不是问题。我相信产品管理者的工作是专注于定义和优先考虑客户的问题，而不是解决方案。这意味着，一旦你把问题摆在设计和工程团队面前，你们就可以一起在项目的范围或预算内，为这个问题找出最佳的解决方案了。然而，产品需求“文档”就像它的定义一样，迫使你必须先开始为功能和需求（解决方案）写文档。
3. 需求文档是在某个时间点编写的——而且和那个时间点一样，它们在现在都已经成为了过去式。我们都知道技术领域的变化有多快，但市场、我们的客户、甚至我们公司的战略也是如此！当我们写完PRD时，它就已经过时了。这导致我们在翻来覆去不停地更新需求，而不是构建产品。
4. 只有好的输入才有好的产出。如果一开始的点子就很糟糕，结果也不可能好。问题是，这么多年来，我们的每一代利益相关方们都学过用头脑风暴来提出他们认为有一天可能需要的需求，然而，在现实情境中，他们列出的很大一部分功能都没有用。但是，由于它们都被设定为“需求”，所以最后都会被实现。
5. 需求文档会被曲解。阅读需求并真正干活的人通常不是写这篇文档的人，所以你基本上就是在和你的产品管理人员玩传话游戏。对需求的错误解释将会从文档编写者到实施人员再到测试人员一层层的累积起来，最后的结局一定是灾难。
6. 需求文档会成为推卸责任的工具。任何软件项目最难的部分是弄清楚要做什么——因此工程团队要求提供规格说明，产品团队需要编写需求描述，每个人都认为他们已经完成了自己的工作，唯一的问题是客户最终没有使用产品。
"建立一个软件系统最困难的部分是准确地决定构建什么"。
—— Fred Brooks, 《没有银弹》 (1987)
7. 需求文档限制了你的产品。这听起来有些匪夷所思，虽然通过需求文档，你可以有效地限制需求产出的结果，但是，当你的资源或时间即将耗尽时，你会被迫把产品实现的范围缩小。这意味着所有那些旨在取悦客户的东西会被扔掉，从而为实现功能让路。
有什么其他选择吗？
像往常一样，我认为重要的是回归敏捷原则，与调研、设计和工程部门一起，作为一个团队协同工作，为你的客户设计出正确的产品。既然我们要做的是尽可能有效地弥合客户和产品开发团队之间的隔阂，不要浪费时间写产品需求文档，下面的几点才是你应该做的（借用敏捷宣言中的第一原则）。
1. 个体和互动。没有什么方法能取代大量沟通。产品设计应该是一个利用团队中每个人的洞察力和创造力，大家合作完成的迭代过程，而不是依赖于写规格说明然后隔着墙把它们扔给工程人员。无论是做用户故事地图，设计冲刺，还是使用其他技术，合作都会产生更快、更清晰的结果，因为它们是在彼此的对话沟通中被成就出来的。
2. 工作的软件或硬件。重要的事情说三遍：原型，原型，原型！无论是用便利贴写的用户流程，还是在纸上勾画的线框图，或者是一个可运行的交互式原型，你要有一些东西展示实际的体验并能够引起内部的讨论，这些讨论的内容能够让你打磨构成产品体验的无数个微小的决定，包括从支持产品所需的后端基础设施，到精确的用户流程。
3. 客户协作。走出办公室! 与你的客户交谈，了解他们的问题到底是什么，并把问题带回团队。然后，一旦有了产品原型，就对它们反复进行测试，不仅要优化用户流和可用性（Usability），还要设法让产品包含触及品味与美学的可取性（Desirability），从而证明其在市场上的可行性（Feasibility）。
作者：Martin Eriksson
译者：捷行译社
致谢
本篇译文来自ShineScrum捷行译社的两位学友共同翻译，译者介绍：
刘康Kang Liu
专业认证：CSP-SM, SAFe5(R) Professional Consultant (SPC), PMP和CAL-II认证。从事企业级敏捷教练工作12年，现旅居德国，致力于企业流程改进，工具优化和敏捷转型。
齐欢Hendry Qi
生命科学领域研发工程师/大学讲师
专业认证：CSP-SM, A-CSM, CSM, PMP, PMI-PBA, PMI-ACP, CxCE和CAL E+T+O认证。
原文链接：https://www.mindtheproduct.com/product-requirement-documents-must-die/
