如何提需求和记录需求

由于不同团队的差异性较大，每个人的能力和风格也不同，即使是同一个团队内部不同的产品经理做事方法与风格都会不一样。
所以此文档书写一些在提需求的必要条件，供给参考

需求文档必备要素

需求背景

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

目前现状

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

需求详情

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

需求来源

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

需求目标

• 需求方提出需求，产品 (项目) 经理提出解决方案，开发按照需求方案进行处理后，期望达到什么样的目标，要用数据「量化」。
• 根据 SMART 原则中可量化衡量原则，一定要「数据化」和「可视化」

预定效果

• 增加的这个功能最终想要实现什么样的效果，这个一般是交互和视觉层面的效果。
  • 比如一个按钮，鼠标 hover 时、移开时、点击时和点击后分别是什么样的效果和前后状态变化。

技术可行性分析

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

需求优先级

• 产品 (项目) 经理的需求池里往往有大量需求，那么如何定义每个需求的优先级呢，这里有几个需求优先级的判定方法供参考：
  • KANO 模型法：基本型需求 > 期望型需求 > 兴奋型需求
  • 矩阵分析法：重要且紧急 > 重要不紧急 > 紧急不重要 > 不重要也不紧急
  • 经济收益法：经济收益高且紧迫的功能需求 > 经济收益高但不紧迫的功能需求 > 紧迫但经济收益不高的功能需求 > 不紧迫且经济收益不高的功能需求
  • 前 / 后置需求分析法：前置需求的优先级 > 后置需求的优先级；前置需求的重要性和紧迫性 > 后置需求的重要性和紧迫性
  • 满足核心用户需求的优先 (二八原则)
  • 满足核心业务的需求优先 (资源最大化利用)
  • 满足核心业务的投入产出比最大的需求优先 (ROI 最大化)
  • 当然，有些需求可能难以按照以上方法清晰地排出优先顺序，那也可以采用另一种方法：P0、P1、P2 (优先级依次递减)

需求排期

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

人员分配

尽量明确到个人

• 设计由谁负责，多少工时
• 前端由谁负责，多少工时
• 后端由谁负责，多少工时