应该很多人都遇到过这种场景吧：某天同事突然微信发来一句话：你写过产品需求文档吧，给我发一个模版。他们突然提出这种需求的时候，多半是在客户现场，出于客户要求，要完成一项叫做“写一个产品需求文档”的工作，虽然这种场景下的产品需求文档最终使命是存档或者是汇报，但是既然花了时间，就不如直接写一份实用一点的，不拘泥于固定模版可能写起来更轻松哦。 那下面我就聊一下怎么写一篇实用的产品需求文档。首先，要明确产品需求文档的作用是什么：一、留存。文字较语言或其他传播途径，是最容易无偏差流转及保存的一种形式。举个例子，某产品经理要离职，如果他是一个有良好输出产品需求文档习惯的人，那么恭喜你，接手前任分分钟，反之，产品梳理和设计的工作基本上得重新开始了。二、说明。产品需求文档，是流转于产品、运营、设计、技术以及客户、BOSS等不同岗位相关人员之间的文档，用来统一和标准化产品的某个原始需求到最终实现的说明性文档，一定程度代表了不同人相同的意志。基于这两个主要的功能，那么产品需求文档应该包含以下四类内容：一、文档标识关于文档标识，其实不仅适用于写产品需求文档，可以作为一个文章输出习惯。因为它可以更好的做文档版本控制。具体形式的话，可以在文档的最前面用一个单独页，注明文档名称，版本号，修订人，修订时间，修订内容概述等，每次修改也做好维护。单独页的原因是，最后往外输出的时候可以视情况判断是否留存，如果要删除，也不会影响内部格式结构。 二、定义需求即说明要做什么定义需求就是用通俗易懂的语言，描述这个需求到底是要做什么，是新增功能还是优化现有功能，不用写的很炫技，能让不同岗位的同事都看能看懂就可以了。其次要指出这个功能的使用场景是什么，比如面向所有用户还是特定的用户群体，有没有什么使用前提，如果功能有地域属性也要说明一下。第三部分要说明一下衡量这个需求的成功指标是什么，可以是达到的实现效果，也可以是所谓的运营数据指标的估算。最后要大致估算并说明一下需求落地的截止日期，以及重要性指标即优先级。 三、要解决什么问题即为什么做需求的来源渠道很多，比如用户反馈、市场调研、运营需求、公司战略等等。因为不同角色的人站的位置不同，看问题的角度是不同的，对需求的“真实程度”的感知也不一样，所以不是每一个需求落到产品这里都有响应的必要。那么产品需求文档里就一定要写明，这个需求为什么要做，要解决用户的什么痛点，以此来引起不同角色的共鸣。其次一定要论证，这个所谓痛点是否真实存在，论证的过程很重要，也很容易被忽视。论证可以通过数据分析或是用户调研等方式实现。尽量避免费很多精力在想当然的需求上，你以为你以为的就是用户以为的？没有论证就“先开发试一下“的需求不配拥有产品需求文档。 四、功能需求即具体怎么做前面写了很多铺垫性内容，最后就要进入描绘如何落地的部分了。首先要在文档里呈现由初始需求形成的功能架构，功能架构是用来更直观的表述最终要实现的功能及其组合，配合功能架构，有能力的同学也可以输出信息架构，到这一部分需求就变得立体了。其次是业务逻辑，业务逻辑包括主流程、分支流程、异常流程。在这个过程中可以同步考虑，当然为了思路清晰，我建议可以先按主流程逻辑顺下来之后，再着手分支流程，最后再考虑异常流程的处理，例如，默认值、上下限、误操作提醒、网络异常等。这里特别提一下，关于功能架构和业务逻辑的梳理时，一定要尽可能多的去考虑全面一些，前期功课尽量做足，静下心来多考虑，规划过程中不妨就拉着技术或其他业务相关人员交流，多吸收别人的建议。尽可能避免投入研发之后，再去大规模改需求，不仅耽误上线时间，对大部分人来说也是极度不友好的。基于前面的功能架构和业务逻辑的梳理，再将已经设计好的原型图，或是设计师设计好的效果图贴到产品需求文档里，备注上相关的交互说明就可以了。 完成上述工作基本上就可以形成一份实用且完整的产品需求文档了。其实大家在实际工作中，可以视需求和工作要求的不同，进行内容的随意插拔和组合，不必完全局限于上述四点。写在最后：

在写产品需求文档的时候，有两个原则希望大家能够注意：

一、千万不要自己闭门造车的做需求分析，要多拉相关人员讨论；

二、不要妄想开发的过程中遇到的问题在产品需求文档里都能预判，这个是不可能的，只能尽可能的去多考虑，要记住需求与实现效果只能无限趋同。(写在这里实在想说一句：请研发哥哥姐姐们对产品经理多一些些体谅吧，或许他们真的已经尽力了呢)

最后祝福看到这篇文章的同学，以后写文档的时候都能文思如泉涌，下笔如有神，仿佛吃了炫迈一样，根本停不下来～～下附本文的内容提要，读者时间宝贵，帮大家省一省。

1

END

1

感谢大家的关注

请多多指正，多多交流

给思维一个出口

和诸位一起

把生活经营成一款产品

As the untamed !