需求，是一切产品价值的源头，只有管理好这一部分的过程，才能尽量从源头减少实际项目中的各种意外成本（eg：返工带来的人力、时间、质量成本）及风险

• 产品层面：笔者的项目是一个C端产品，需求主要来源于产品策划和用户反馈，处于发展期，以占领市场为主
• 项目层面：前期主要功能较为清晰，可切割空间不大，但关联依赖方较多，协作周期长，迭代周期在15～30天左右

一开始项目上对需求的产生、定义、变更等流程和规范没有做清晰明确的限定，导致实际推进过程中出现诸多问题，下面结合实际情况做逐一说明和分析：

项目初期，当有需求意向出现时，一般由产品经理进行分析和定义，绘制出原型图和对功能点进行注释说明，
但是这种方式，因为缺乏正规、通用的需求定义文档模板和需求说明标准，导致需求定义的过程中，出现主观、模糊的描述，增加了后续的沟通成本。

大多数产品需求出现的初期，都无法非常完整的描述和考虑到所有场景，会有许多细节和关联依赖覆盖不全，导致需求变更频繁，需要不断返工和完善

为了适应快速变化的市场需求和优化线上功能，需求的变更在所难免。在项目初期，当需求需要变更时，往往由项目主要负责人共同协商拍板后实施，没有进行详细的流程规范和记录，导致了如下问题的信息在各角色之间不同步：

• 这么多需求变更，每个变更对项目的影响是什么？带来了什么风险？
• 每个变更的优先级如何？时间上如何协调？是否做得完？
• 这些变更什么时候做？谁做？做得怎样了

• 逐步建立《需求规范说明书》，形成需求规范模板

• 保持语句和段落的简短
• 采用主动语态的表达方式
• 需求陈述应该具有一致的样式
• 避免模糊的、主观的术语。如：容易、迅速
• 避免使用比较性的词语。如：提高、最大化、最佳。尽量定量的说明要提高的程度

• 对需求进行分类，增加需求标识
  <需求类型><需求 编号>
  F=功能需求；D=数据需求；B=行为需求；I = 接口需求；O=输出需求

• 缩小需求粒度：建立需求的拆分层次：意向（PM）-- 特性（PO）-- 用户故事（DEV）
• 需求评审：建立评审团队 – 按需求层次/阶段评审 – 评审达成一致输出需求文档 – 项目成员对需求文档进行确认

• 梳理完善后的需求主干流程：
  需求提出 – 需求分析 – 需求定义 – 需求评审 – （需求变更） – 编码实现 – 测试 – 验收完成

• 梳理变更控制流程：
  （相关方）提出需求变更请求 -->CCB（变更控制委员会）进行评估 -是-> 指派需求负责人进行分析确认 -ok-> PM更新计划、范围、风险等文档 --> 实施变更 – 对变更进行记录和跟踪

• 建立需求变更跟踪机制：
  引入需求管理工具：神兵，记录每个需求的属性和状态

  • 属性 ：eg ：创建时间、需求的版本号、确认者、需求状态、优先级、涉及的子系统、需求原因

  • 状态：eg：已建议、已批准、已实现、已删除

当问题分析完成并制定好解决方案之后，如何把方案在实际项目中落地是最难的一步，往往需要天时、地利、人和几个因素。
如何让大家都配合和认可你的方案和做法，认可你即将引入的变化？

• 天时：阶段性复盘时，将问题和大家的痛点结合起来，罗列以往几次需求不清晰或不健壮带来的影响，摆数据，挖痛点，和成员达成共情
• 地利：将方案在项目中因地制宜的落地，如寻找合适的，或内部已有的工具
• 人和：注意沟通技巧，不同立场、不同角色采取不同的沟通方式，找出更多的积极因素。在引入变化之前，与关键角色进行一对一的沟通，逐个击破后，再进行面向全员的正式沟通

引入变化之后，如何确保整个机制正常的运作起来，是否形式正向的闭环？

• 及时跟踪反馈：每日站会上，确认需求是否新增，需求状态是否及时更新，建立需求跟踪矩阵
• 数据汇报：每个迭代中的需求变化情况，绘制成甘特图；每月汇总需求变更情况

项目经理在日常的工作中，除了及时发现项目问题并制定相应的流程规范外，还要选取合适的时机去引入变化，并且不断的引导团队进行复盘和持续改进。在实施的过程中还要增加监控手段，让项目形成反馈机制。
注意点：

• 要让大家达成共识，变更是有代价的
• 再小的变更也要经过正规的控制流程，否则会积少成多

加油吧，越挫越勇～