文章目录
常规需求流程
项目需求管理问题分析案例
1.概述
需求，是一切产品价值的源头，只有管理好这一部分的过程，才能尽量从源头减少实际项目中的各种意外成本（eg：返工带来的人力、时间、质量成本）及风险
2.项目&产品介绍
- 产品层面：笔者的项目是一个C端产品，需求主要来源于产品策划和用户反馈，处于发展期，以占领市场为主
- 项目层面：前期主要功能较为清晰，可切割空间不大，但关联依赖方较多，协作周期长，迭代周期在15～30天左右
3.问题分析（找到问题）
一开始项目上对需求的产生、定义、变更等流程和规范没有做清晰明确的限定，导致实际推进过程中出现诸多问题，下面结合实际情况做逐一说明和分析：
3.1 需求定义不清晰
项目初期，当有需求意向出现时，一般由产品经理进行分析和定义，绘制出原型图和对功能点进行注释说明，
但是这种方式，因为缺乏正规、通用的需求定义文档模板和需求说明标准，导致需求定义的过程中，出现主观、模糊的描述，增加了后续的沟通成本。
3.2 需求不健壮
大多数产品需求出现的初期，都无法非常完整的描述和考虑到所有场景，会有许多细节和关联依赖覆盖不全，导致需求变更频繁，需要不断返工和完善
3.3 需求变更不规范，没有存档
为了适应快速变化的市场需求和优化线上功能，需求的变更在所难免。在项目初期，当需求需要变更时，往往由项目主要负责人共同协商拍板后实施，没有进行详细的流程规范和记录，导致了如下问题的信息在各角色之间不同步：
- 这么多需求变更，每个变更对项目的影响是什么？带来了什么风险？
- 每个变更的优先级如何？时间上如何协调？是否做得完？
- 这些变更什么时候做？谁做？做得怎样了
4.解决方案（解决问题，择其优）
4.1 建立需求规范及需求文档模板
- 逐步建立《需求规范说明书》，形成需求规范模板
- 保持语句和段落的简短
- 采用主动语态的表达方式
- 需求陈述应该具有一致的样式
- 避免模糊的、主观的术语。如：容易、迅速
- 避免使用比较性的词语。如：提高、最大化、最佳。尽量定量的说明要提高的程度
- 对需求进行分类，增加需求标识
<需求类型><需求 编号>
F=功能需求；D=数据需求；B=行为需求；I = 接口需求；O=输出需求
4.2 拆分需求 & 需求评审
- 缩小需求粒度：建立需求的拆分层次：意向（PM）-- 特性（PO）-- 用户故事（DEV）
- 需求评审：建立评审团队 – 按需求层次/阶段评审 – 评审达成一致输出需求文档 – 项目成员对需求文档进行确认
4.3 增加变更控制流程
-
梳理完善后的需求主干流程：
需求提出 – 需求分析 – 需求定义 – 需求评审 – （需求变更） – 编码实现 – 测试 – 验收完成 -
梳理变更控制流程：
（相关方）提出需求变更请求 -->CCB（变更控制委员会）进行评估 -是-> 指派需求负责人进行分析确认 -ok-> PM更新计划、范围、风险等文档 --> 实施变更 – 对变更进行记录和跟踪 -
建立需求变更跟踪机制：
引入需求管理工具：神兵，记录每个需求的属性和状态-
属性 ：eg ：创建时间、需求的版本号、确认者、需求状态、优先级、涉及的子系统、需求原因
-
状态：eg：已建议、已批准、已实现、已删除
-
5.难点
5.1 如何引入变化
当问题分析完成并制定好解决方案之后，如何把方案在实际项目中落地是最难的一步，往往需要天时、地利、人和几个因素。
如何让大家都配合和认可你的方案和做法，认可你即将引入的变化？
- 天时：阶段性复盘时，将问题和大家的痛点结合起来，罗列以往几次需求不清晰或不健壮带来的影响，摆数据，挖痛点，和成员达成共情
- 地利：将方案在项目中因地制宜的落地，如寻找合适的，或内部已有的工具
- 人和：注意沟通技巧，不同立场、不同角色采取不同的沟通方式，找出更多的积极因素。在引入变化之前，与关键角色进行一对一的沟通，逐个击破后，再进行面向全员的正式沟通
5.2 如何做好监控
引入变化之后，如何确保整个机制正常的运作起来，是否形式正向的闭环？
- 及时跟踪反馈：每日站会上，确认需求是否新增，需求状态是否及时更新，建立需求跟踪矩阵
- 数据汇报：每个迭代中的需求变化情况，绘制成甘特图；每月汇总需求变更情况
6.总结
项目经理在日常的工作中，除了及时发现项目问题并制定相应的流程规范外，还要选取合适的时机去引入变化，并且不断的引导团队进行复盘和持续改进。在实施的过程中还要增加监控手段，让项目形成反馈机制。
注意点：
- 要让大家达成共识，变更是有代价的
- 再小的变更也要经过正规的控制流程，否则会积少成多
加油吧，越挫越勇～