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

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

预定效果

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

比如一个按钮，鼠标 hover 时、移开时、点击时和点击后分别是什么样的效果和前后状态变化。

比如用户未付款状态显示「付款」和「取消」按钮，用户付款成功收到货后付款和取消按钮隐藏，显示「评价」按钮。而不应当描述成，增加一个评价按钮，跟付款和取消按钮放在一起。

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

需求优先级

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

KANO模型法：基本型需求>期望型需求>兴奋型需求

矩阵分析法：重要且紧急>重要不紧急>紧急不重要>不重要也不紧急

经济收益法：经济收益高且紧迫的功能需求 ＞ 经济收益高但不紧迫的功能需求 ＞ 紧迫但经济收益不高的功能需求 ＞ 不紧迫且经济收益不高的功能需求

前/后置需求分析法：前置需求的优先级 ＞ 后置需求的优先级；前置需求的重要性和紧迫性 ＞ 后置需求的重要性和紧迫性

满足核心用户需求的优先（二八原则）

满足核心业务的需求优先（资源最大化利用）

满足核心业务的投入产出比最大的需求优先（ROI最大化）

当然，有些需求可能难以按照以上方法清晰地排出优先顺序，那也可以采用另一种方法：P0、P1、P2（优先级依次递减）

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

人员分配

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

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

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

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

总结

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

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

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