如何控制需求变更?

需求变更是软件项目推进中非常常见的一种现象,变更来自于需求方、管理、技术各个方面,且原因也不尽相同。对于这些变更来说,如果不控制或者控制不好,就会导致项目陷入混乱,甚至出现严重延期或者质量下降的问题。对于需求变更,既不能一律拒绝所有变更,也不能一味迁就变更,所以“需求变更控制”就显得非常关键且艺术。

通常来说,在软件项目管理中,对于需求变更管理主要有以下几个方面要求

  1. 建立变更控制委员会:变更控制委员会应该由项目的相关人员组成,由他们确定哪些需求需要变更,这些变更是否在项目范围之内,并对这些变更进行评估来作为需求变更选择或放弃的标准。
  2. 确定变更控制的流程:需求变更控制流程就是对需求变更进行控制的过程,所有的需求变更控制都需遵循此过程来进行处理。
  3. 进行变更影响分析:影响分析可以提供对所建议的变更进行准确理解,帮助做出充分的变更批准决策,因此,它是处理需求变更申请的一个重要环节。通过对变更内容的检验,确定对系统做出修改、抛弃或者创建新系统的决定以及评估每个任务的工作量,这项工作结果的好坏往往依赖于跟踪能力数据的质量和完整性。
  4. 进行变更波及效应分析,确定受变更波及的元素:当进行需求变更时,往往会波及其他的元素,这样就可以根据需求跟踪表找到相关受波及的要素,并对其进行变更或修改。及时的波及效应处理可以减少由于这些影响而导致的不利因素。
  5. 跟踪每个需求的状态:需求的状态包括已建议、已批准、已完成、已验证、已删除、已否决等几类,在需求变更控制中需要建立一个数据库来记录和保存每一项需求的状态和重要属性,从而有利于对需求状态的管理和追踪。
  6. 建立需求基准版本和需求控制版本文档:确定一个需求基准,并遵循确定的变更控制过程来进行需求变更。当然,对需求控制的版本也应该进行管理,以避免新旧版本的混淆,每个版本的规约说明都应有独立的说明。
  7. 记录并维护需求变更的历史:在进行需求变更时,需要记录和维护需求变更的历史,包括版本的日期、所做的变更、变更原因、由谁负责更新以及更新后的新版本号等。

但实际情况很少有公司和项目能够完全遵守这方面的管理,所以我结合了PMP项目管理思路,总结了几个对于需求变更控制最为关键的因素,在这方面做一些要求和规范,能很好约束频繁需求变更的问题

  1. 建立基准意识 对于大型项目的迭代和开发来说,一般都会有一个版本基线,通常达到这个基线的时候就意味着迭代定版,不允许任何变更。如果需要变更,则需要重新进行需求澄清开发测试的流程。那么对于这个基线的概念,我们可以将其抽离为两方面的基准:

    • 时间基准:项目推进的时间节点,如果已经接近最终阶段,那么禁止变更;
    • 成本基准:项目推进的成本要求,通常是时间、人力,这里可以用一个简单的评估办法,就是上线时间的延期范围,如果变更增加的工作时间超出了一个阈值,那么禁止变更。 这个基准意识应当是项目所有参与者的共识和原则,超出基准范围的变更则必须等待下一轮迭代,这种要求也是项目风险控制中很关键的一环。
  2. 赋予项目负责人一定的变更管理权限 对于不影响基准的变更,项目负责人有权限自行决定是否进行变更,但对于变更的内容仍需要重新澄清、开发和测试。 而涉及基准的变更,则必须通过变更控制委员会的审核。因为这类变更会影响整个项目的进度
  3. 成立变更控制委员会

    • 委员会的组成有高层领导、项目经理(负责的产品经理)、设计负责人、研发负责人、需求方代表等涉及到的利益方组成
    • 变更控制委员会的职责就是对涉及基准并在基准控制范围内的变更进行审核,确保相关方知情,同时对变更内容的价值也进行了一次确认
  4. 建立变更控制流程,保留变更记录 变更控制的流程,主要围绕变更发起、评估、审核、落地这四个方面进行约束,同基准意识一样,也必须成为所有项目参与者的共识和原则,否则变更控制的制度就形同虚设 找到的一个关于变更控制的流程,非常完善 保留变更记录是流程中非常关键的一点,不管变更请求有没有最终执行,都需要记录到变更日志。这对日后的复盘和溯源工作都有非常大的意义。
Published 12 Nov 2020

在网络连接的世界中,做一个特立独行的节点。大熊Bear on Twitter