如何正确地提需求才不会被喷？

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

背景介绍

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

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

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

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

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

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

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

• 小公司更加讲究高效机动，没那么多规矩和繁琐流程——怎么方便怎么来；
• 而大公司一般流程繁琐，有着一套较为完善的开发流程（但要注意，流程虽完善，但不一定合理）。从产品经理接收需求到需求分析与确认，再到需求提交和开发测试需要很长一段时间。

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

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

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

需求文档必备要素

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

需求背景或原因

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

• 比如用户到了商详页，但是加入购物车的人就是很少，一直上不去，运营想要优化商详页，提升用户加车的数量；
• 或者用户经常将商品加入购物车，但就是迟迟不肯下单，希望加速用户下单时间，提升下单转化率。

目前现状

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

需求详情

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

• 建议用总——分的表达方式，即总体需求是什么，细分需求点分别是什么（需求点1，需求点2……）；
• 需求是否需要同时处理前后台、需要在哪些端开发（web、wap or app）；
• 需求类型是什么，是新增功能，还是修复bug，或者用户体验优化，网站性能优化等等，具体需要处理哪个功能模块或页面；
• 需求涉及的场景是什么，用户会在什么场景下使用该功能，前置/后置条件是什么；
• 需求是否涉及到产品规则或者参数，如果有则要列出来；
• 建议将开发需求和设计需求分开来表达，不要笼统地放在一个文档里。尤其是设计需求，单独用一个文档或表格或页面来表达（设计师会特别开心的）。笔者是用 Axure 写需求文档的，我会单独开一个页面列出设计需求，一遍设计师查阅，节省设计师时间。
• 是否需要跟其他部门对接合作，期望其他部门什么时候可以配合，什么时候可以交付等等。

需求来源

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

需求目标

需求方提出需求，产品经理提出解决方案，开发按照需求方案进行处理后，期望达到什么样的目标，要用数据「量化」。诸如提高用户付费转化、降低用户退货率、提高用户注册率…..等诸如此类无法用数据量化的笼统目标，都是废话。要知道，我们做的所有工作，都是为了不断优化用户体验，提升用户数据，提高下单转化率，提升销量。

无法用数据衡量的目标，都是耍流氓。一定要「数据化」和「可视化」，这也是 SMART 原则中可量化衡量原则的体现。

预定效果

增加的这个功能最终想要实现什么样的效果？这个一般是交互和视觉层面的效果。

• 比如一个按钮，鼠标 hover 时、移开时、点击时和点击后分别是什么样的效果和前后状态变化。
• 比如用户未付款状态显示「付款」和「取消」按钮，用户付款成功收到货后付款和取消按钮隐藏，显示「评价」按钮。而不应当描述成，增加一个评价按钮，跟付款和取消按钮放在一起。

技术可行性分析

这个问题一般要产品、技术、设计一起进行分析。有些时候想法是美好的，但是以公司目前的技术实力，可能还难以做到，或者技术上投入产出比太低，开发必要性不大，或者是当前技术无法实现等各方面的原因，都有可能导致我们的想法落空。这个时候一般就只有“等待”——等待时机或技术成熟时再考虑开发。

需求优先级

产品经理的需求池里往往有大量需求，那么如何定义每个需求的优先级呢，这里有几个需求优先级的判定方法供参考：

• KANO模型法：基本型需求>期望型需求>兴奋型需求
• 矩阵分析法：重要且紧急>重要不紧急>紧急不重要>不重要也不紧急
• 经济收益法：经济收益高且紧迫的功能需求  ＞ 经济收益高但不紧迫的功能需求  ＞ 紧迫但经济收益不高的功能需求  ＞ 不紧迫且经济收益不高的功能需求
• 前/后置需求分析法：前置需求的优先级  ＞ 后置需求的优先级；前置需求的重要性和紧迫性  ＞ 后置需求的重要性和紧迫性
• 满足核心用户需求的优先（二八原则）
• 满足核心业务的需求优先（资源最大化利用）
• 满足核心业务的投入产出比最大的需求优先（ROI最大化）
• 当然，有些需求可能难以按照以上方法清晰地排出优先顺序，那也可以采用另一种方法：P0、P1、P2（优先级依次递减）

需求排期

这个需求期望在什么时间开发完成，什么时间提测，以及什么时间安排上线。如果没有按时上线，下次什么时间可以上线，或者上线后出现问题，补救时间是什么时候。

人员分配

前端由谁负责，后端由谁负责，设计由谁负责，每个人多少工时（在有工时的公司），这些都要尽量明确到个人。

下面是我平时提需求的模板，放在这里供参考。

注意：该模板中提到的数据都是虚假数据，只作举例说明之用。

下面这张图是分开的设计需求表：

总结

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

文档写好一点，提需求的姿势正确一点，专业度提高一点，你在团队里也就显得更靠谱，不至于每次都被其他人喷。

作者：卿宗伟，产品经理。专注探索电商与移动社交领域的产品设计与用户体验，分享一个产品人的野蛮成长历程。同名公众号：@卿宗伟（ID：HaloThanksBye）

本文由 @卿宗伟 原创发布于人人都是产品经理。未经许可，禁止转载。