虽然能写一份好的需求文档并不代表就是一个好的产品经理，也不代表这样就能成为一个好的产品经理。但是一份好的需求文档能够从一定程度上反应出你这个人是否足够专业和细心，考虑是否全面，是否注重细节，是否能够提高整个团队的便捷度和效率。

背景介绍

在产品经理的日常工作中，接收需求或提需求都是最基础最常规的工作内容。

大家都知道，需求来源多种多样，有来源于用户反馈的，有来源于运营、推广、市场、客服等业务部门或者直接来自老板的，也有产品经理通过数据分析、用户调研、问卷调查、竞品分析等获取的需求，当然还有一种常见的需求来源就是产品经理自己yy的。

不管需求来源于哪里，最终需求都是通过产品经理提交给开发或设计的。

那么，如何正确地提需求才不会被喷呢？

这篇文章笔者试着从自己的过往经验出发，对这个问题作一个简单的分享。

由于不同团队的差异性较大，每个人的能力和风格也不同，即使是同一个团队内部不同的产品经理做事方法与风格都会不一样。笔者无法得知大家在工作中都是怎样给开发提需求的。

笔者先后在小公司和大公司都待过，小公司和大公司的开发模式和风格都有接触和了解。就我个人的经验来说，不是每个公司和团队都有规范的产品开发流程。

小公司更加讲究高效机动，没那么多规矩和繁琐流程——怎么方便怎么来；

而大公司一般流程繁琐，有着一套较为完善的开发流程（但要注意，流程虽完善，但不一定合理）。从产品经理接收需求到需求分析与确认，再到需求提交和开发测试需要很长一段时间。

我们平时经常会听到别人问一些关于文档撰写的问题，比如“你们都是用什么写PRD的？用什么工具比较好呀？”“请问PRD要写到什么程度呀？”这样的问题在我刚入行的时候我也喜欢问，而且不厌其烦地去找一些模板来模仿学习。

但结合笔者的两份工作经历，有一个比较深的感受——并不是每个需求都需要产出完整规范的PRD，甚至大部分需求都不需要。因为花大量时间去产出一份几千字甚至上万字的PRD，意义并不是很大，更多情况下我们只需要写一份简化版的需求文档即可。事实上的确也是，什么形式什么工具都不重要，重要的是怎么方便在团队内部沟通和查阅，开发并不喜欢看长篇大论的文档。

因此，本文不针对长篇大论的 PRD 进行探讨与分析，只针对工作中的小需求或小项目用得到的简化版需求文档来作分析。

需求文档必备要素

一份较为完整的简化版需求文档应当包含哪些要素呢？根据笔者的经验，有以下几点供参考：

需求背景或原因

为什么要提这个需求，基于什么样的业务背景提出来的。

比如用户到了商详页，但是加入购物车的人就是很少，一直上不去，运营想要优化商详页，提升用户加车的数量；

或者用户经常将商品加入购物车，但就是迟迟不肯下单，希望加速用户下单时间，提升下单转化率。

问题现状是什么，当前是怎么处理的。确认是否是这个原因导致了需求中提到的问题——即确认问题与原因之间的因果关联性，避免文不对题。

需求详情

这个需求的详细内容包括哪些。注意一下几点：

建议用总——分的表达方式，即总体需求是什么，细分需求点分别是什么（需求点1，需求点2……）；

需求是否需要同时处理前后台、需要在哪些端开发（web、wap or app）；

需求类型是什么，是新增功能，还是修复bug，或者用户体验优化，网站性能优化等等，具体需要处理哪个功能模块或页面；

需求涉及的场景是什么，用户会在什么场景下使用该功能，atv，前置/后置条件是什么；

需求是否涉及到产品规则或者参数，如果有则要列出来；

建议将开发需求和设计需求分开来表达，不要笼统地放在一个文档里。尤其是设计需求，单独用一个文档或表格或页面来表达（设计师会特别开心的）。笔者是用 Axure 写需求文档的，我会单独开一个页面列出设计需求，一遍设计师查阅，节省设计师时间。

是否需要跟其他部门对接合作，期望其他部门什么时候可以配合，什么时候可以交付等等。

这个需求来源于谁，方便有问题不清楚时及时找到相关人进行沟通确认。

需求目标