项目管理实践常见困境（五）

1. 当遇到需求变更的业务场景，我们应该怎样正确的应对？

01

—

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

项目场景：

提起需求变更，我们并不会陌生，它基本在我们日常的需求迭代中都可能会出现，控制的好，项目正常上线，项目组成员皆大欢喜。控制的不好，各方都有可能不满。

问题：

当遇到需求变更的业务场景，我们应该怎样正确的应对？

反馈：

首先先关注BUS（商业、用户、交付）三个不同视角综合来看场景，对变更需求进行分析，再选择合适的方式应对，这个过程实际上也是解决某种程度上的冲突。想要做到这一点，又可以向上看一层，通过前期建立适当的项目组织架构来支撑良好的需求变更机制。

1、综合BUS三方视角看场景，对变更需求进行分析。

基于商业视角。

关注变更的投入产出、预期收益、风险等。

基于用户视角。

首先，对需求要有个基本的分类。例如基于KANO模型：是基本型需求、兴奋型需求、还是期望型需求。这对于需求的强度和优先级审视很有帮助。

更深一层，是要区分需求与诉求。表达出来的需求和背后的诉求并不是一回事儿。例如一个人需要你帮忙打开房间的窗子，这是说出来的需求，而背后的诉求可能是希望给房间通风透气、也可能是希望快速调整房间温湿度，这些诉求可能并没有清楚地在需求中表达出来。更关注需求背后的诉求，有时需要共情的能力，这对于变更的决定在整体项目中的影响有着重要意义。

基于交付视角。

关注变更对时间、范围、质量等的影响。

2、前期建立适当的项目组织架构。

不同的项目组织架构可以针对不同项目环境中的变更处理机制提供支撑。例如：偏瀑布式交付型的组织架构，其中的变更控制委员会（CCB），在实际中就需要格外关注如上的商业和用户视角；而基于PRINCE2的项目组织，因为核心的项目委员会由BUS三方代表构成，这就天然地关注到了以上三个方面的视角；而敏捷团队组织标榜的即是拥抱变化，而PO这类角色本身的职责也就带有商业和用户属性，如果充分履责理论上也就能够照顾到如上的三个方面视角。

3、额外要提的是敏控的平衡。

变化是常态，控制并不是拒绝改变，敏捷并不是失控。（即使传统的瀑布式流程仍然可以通过CCB充分关注各关键相关方的视角，在变更控制过程中尽力减少各方的不满。）

有时为了兼顾平衡，除了在分层上有敏控的偏重，比如组织受控、交付敏捷；也要考虑在不同阶段针对风险和问题的特点有不同处理。这就涉及到结合分阶段管理的思路，在不同的管理阶段，基于该阶段的场景或根据变更带来的影响调整敏控的平衡。例如可能倾向早期偏敏捷后期偏控制，敏捷方法一些实践倾向一贯地对需求和开发交付敏捷但对版本发布可能会相对控制。

综上，关注场景还是最首要和最核心的，根据场景选择敏控之间的平衡，选择合适的方法应对。方法和工具也总是在适用的场景中才能发挥其优势。