需求,是一切产品价值的源头,只有管理好这一部分的过程,才能尽量从源头减少实际项目中的各种意外成本(eg:返工带来的人力、时间、质量成本)及风险
一开始项目上对需求的产生、定义、变更等流程和规范没有做清晰明确的限定,导致实际推进过程中出现诸多问题,下面结合实际情况做逐一说明和分析:
项目初期,当有需求意向出现时,一般由产品经理进行分析和定义,绘制出原型图和对功能点进行注释说明,
但是这种方式,因为缺乏正规、通用的需求定义文档模板和需求说明标准,导致需求定义的过程中,出现主观、模糊的描述,增加了后续的沟通成本。
大多数产品需求出现的初期,都无法非常完整的描述和考虑到所有场景,会有许多细节和关联依赖覆盖不全,导致需求变更频繁,需要不断返工和完善
为了适应快速变化的市场需求和优化线上功能,需求的变更在所难免。在项目初期,当需求需要变更时,往往由项目主要负责人共同协商拍板后实施,没有进行详细的流程规范和记录,导致了如下问题的信息在各角色之间不同步:
梳理完善后的需求主干流程:
需求提出 – 需求分析 – 需求定义 – 需求评审 – (需求变更) – 编码实现 – 测试 – 验收完成
梳理变更控制流程:
(相关方)提出需求变更请求 -->CCB(变更控制委员会)进行评估 -是-> 指派需求负责人进行分析确认 -ok-> PM更新计划、范围、风险等文档 --> 实施变更 – 对变更进行记录和跟踪
建立需求变更跟踪机制:
引入需求管理工具:神兵,记录每个需求的属性和状态
属性 :eg :创建时间、需求的版本号、确认者、需求状态、优先级、涉及的子系统、需求原因
状态:eg:已建议、已批准、已实现、已删除
当问题分析完成并制定好解决方案之后,如何把方案在实际项目中落地是最难的一步,往往需要天时、地利、人和几个因素。
如何让大家都配合和认可你的方案和做法,认可你即将引入的变化?
引入变化之后,如何确保整个机制正常的运作起来,是否形式正向的闭环?
项目经理在日常的工作中,除了及时发现项目问题并制定相应的流程规范外,还要选取合适的时机去引入变化,并且不断的引导团队进行复盘和持续改进。在实施的过程中还要增加监控手段,让项目形成反馈机制。
注意点:
加油吧,越挫越勇~