我听过很多支持“不写产品需求文档”的理由：“某产品用户那么多，他们整个团队没有一份完整的（产品）需求文档”；“我们追求效率，不用文档”； “文档写了也没人看”……

首先要搞清楚的问题是：“什么是产品需求文档？”

就公司内部而言，可能存在各种各样的文档：产品需求文档（Product Requirements Document, PRD）、市场需求文档（Market Requirements Document, MRD）、产品策略文档（Product Strategy Document）、产品路线图（Product Roadmap）、产品更新文档（Product Release Note）、客服产品文档……有的公司可能每种都有（甚至一种文档有好几个互相冲突的版本^^），有的公司可能一种文档都没有。

上面这些文档，每种文档都跟“产品”有一定关系，但是每个文档有各自的侧重点：

“产品需求文档”描述产品应该是什么样子。产品文档的目的是准确无误地描述产品的功能、特性、行为。在某些公司，产品需求文档还包括产品的界面要求和用户体验要求，有的公司则将这些内容分布在不同的文档中。

“市场需求文档”描述产品的机会（opportuinity）和市场需求。产品需求文档描述能够满足市场需求的产品。

“产品策略文档”描述一段时间后，产品该走向什么方向。“产品路线图”描述实现“产品策略”的路径、步骤。“产品需求文档”描述每一步骤过程中某一具体版本的产品应当是什么样子。“产品更新文档”是产品更新时，用来说明本次更新内容的文档。“客服产品文档”则侧重客服如何解答用户提出的产品相关的问题。

搞清楚了这些文档的关系后，“要不要写产品需求文档”这个问题的答案已经很清楚了。不难看出：“产品需求文档”是“市场需求文档”的延伸，是产品策略文档和产品路线图的具体落实，同时，产品需求文档是产品更新文档、客服产品文档和测试文档的来源、标准。

从产品设计团队、研发团队、测试团队的工作协作方式而言，撰写“产品需求文档”也是有必要的。

如前所述，产品文档的目的是准确无误地描述产品的功能、特性、行为。在某些公司，产品需求文档还包括产品的界面要求和用户体验要求。产品经理撰写产品需求文档的过程相当于将整个产品的每一个功能、每一种行为进行梳理的过程。通常而言，设计产品的过程中，人们是按照完整、按完美次序完成一系列操作的流程进行思考的。而撰写文档的过程中，则需要考虑到如果用户进行某个“意料之外的操作怎么办”（相信我，用户肯定会这样的）。“撰写需求文档”这个过程本身就能发现产品设计中的问题。

对产品开发团队而言，产品需求文档是开发团队的“蓝图”，产品开发团队严格依照这份“蓝图”完成产品的每一个功能、行为。口头传达这些需求当然可以，但是你可以想象这样一个场景：一个工程师在施工现场，对每一个施工者口头传授“你在这儿安一个水龙头”、“沿着这堵墙走线”、“这堵墙水泥标号再高一点”……整栋楼也能建成，可能建完第二层，就没人记得第一层是怎么回事儿了。以“追求效率”作为不写“产品需求文档”的理由基本上是出于想象，接下来面临的是无数类似于“当时是怎么设计的来着”（“这间房的电线是怎么走线的？”）这种灾难。

对测试团队而言，“产品需求文档”是测试用例的来源、产品能否通过测试的标准。测试团队拿到产品后测什么、怎么才算通过，这两个问题的答案都在产品需求文档中：按照需求文档的描述的功能和行为测，符合需求文档要求算通过。测试工作我参与的不多，理解不深，但大致是这样的。

就团队协作而言，在团队规模小时，“产品需求文档”的重要性可能还不那么明显——毕竟，沟通成本还不高甚至沟通还不算成本。但是当团队到了一定规模，且具有人员流动性之后（这几乎是必然的），“产品需求文档”的作用就明显了。设想一个场景，产品设计人员不在时（睡觉、休假、离职，或者死了），又没有产品需求文档，除了让研发人员一行行查代码，还有什么方式能够获知某个开关的默认值、某个数值的初始值、某个排序操作的具体规则？

有产品需求文档，不一定能开发出好的产品，但是没有产品需求文档……只能说，做出好产品也不是不可能吧。

至于“文档写了也没人看”的问题，我还在考虑，等我考虑好了再说吧。不排除长时间考虑不好的可能性。