需求池管理

需求池要分为用户需求池和产品需求池。

用户需求池记录所有用户端提报的用户需求记录。产品需求池是对用户需求经过初步分析和拆解后形成的功能需求清单。二者应该有明确关联，可以互相追溯。

用户需求一旦记录在案，更多作用是存档保留。产品需求则可能被更新和调整。一旦产品需求形成产品方案，并产生研发投入之后，就会进入明确的项目管理周期。

维护两个需求池非常有利于后续工作的开展。一方面，可以方便用户从需求提出人的角度了解相关工作进展；另一方面，可以帮助产品经理找到产品设计背后对应的用户需求轨迹。

为了避免用户互相思考、随意提出需求，造成没必要的资源损耗，可以考虑让用户通过填写需求提报模板提交需求，促使用户在提需求前把一些关键事项想明白，提高需求质量。这个办法尤其适合甲方公司。乙方公司面临的现实情况是，需要更好地主动服务客户；如果让客户通过模板提需求，估计老板也不同意。

用户的需求提报模板通常有如下字段：

需求编号：由业务人员填写。如果是需求变更，需要写明原需求编号。
需求名称。
提交人。
业务负责人。
提交时间。
期望上线时间。
优先级：采用公司统一的项目管理优先级定义。
问题描述：说明业务中遇到的问题，需要尽可能清晰详尽。

提出任何需求之前，都应该想清楚需求的价值，以及上线后如何衡量价值的实现，并依据结果做持续的闭环优化跟踪。不论是谁发起需求，都应该提前想清楚需求的预期收益和度量方式。所以，还应该增加以下字段：

期望目标：说明期望解决哪些问题或改善哪些指标。
预期收益：尽量用客观数字描述预期获得的收益。
期望解决方案和期望上线时间。
存在风险：说明预计需求背后可能存在的各类风险，包括业务风险、商业风险。
相关部门：具体而言，是会从此需求中得到收益或受到影响的部门。

产品需求池通常需要包含以下字段：

产品需求 ID：作为需求唯一性主键。
用户需求 ID：对应的用户需求编号，可以关联多个用户需求。
产品线：描述需求所在产品线或业务线。
需求类型：需要谨慎设计分类，便于分析资源在不同业务方向上的投入情况。可能的类型包括业务需求、用户需求、技术需求，或者按业务价值分类。
是否插队：专门记录需求在项目执行中是否具有插队执行属性。
主题：需求的一句话概述。
内容：需求的具体描述。
来源：需求的提出人或提出部门，通常可以直接沿用用户需求中对应的字段。
需求提出日期。
优先级。
迭代版本：如果采用敏捷开发模式，需要标记需求排期开发时的迭代版本。
业务负责人：该需求业务口的唯一负责人。
产品经理：该需求对应的产品经理。
研发负责人：研发负责人一定是研发的整体负责人，不应该拆分为前端负责人和后端负责人。因为这样可能导致两者各自负责自己的工作，但对技术实现的整体方案和进度没有把控，相当于没有技术负责人。
测试负责人：如果研发负责人全权管理研发和测试工作，就不需要单独指定测试负责人；否则要明确安排测试负责人对质量结果和进度负责。
状态：用于描述需求的生命周期，可以包含以下选项：待跟进、需求调研中、产品需求文档编写中、待产品需求文档评审、待技术评审、待排期、待开发、开发中、待测试、测试中、待验收、待上线、已上线、暂停、终止。总之，状态应该能够持续一段时间，而不应该很快就结束。
状态变更说明：对某些状态字段的补充解释。
计划上线日期：在技术评审之后，由研发负责人基于工时和资源投入给出的目标上线日期。这里使用的是工时，而不是工期。工期是指开发时长，工时是指工作量，二者是两个完全不同的概念。
实际上线日期：系统真正上线的时间。
前后端开始日期、结束日期以及研发工作量：按人日计算。
发版计划：在移动端产品里，需求上线可能涉及发版，也就是需要发布新的客户端，所以要在表格中记录发版的版本号。

如果某个需求涉及跨端或者跨团需要开发，就需要按照子项目把上述模板进一步细化。