前两天咱们在做我的项目复盘的时候，发现其实在整个过程中还是遇到了不少需要变更的问题，不过还好咱们算是比拟圆满地解决了这些从天而降的问题。置信也会有很多敌人和咱们团队一样，常常遇到客户这边的需要变更，的确这是一个十分辣手的问题。不过在麻利项目管理过程中，咱们还是有一些办法能够解决需要变更这个问题的。
只管咱们对需要变更“疾恶如仇”，但毕竟，该面对的还是要面对的。
在 麻利项目管理中，咱们要如何应答需要变更的问题呢？
一、设置 Product Backlog 与 Sprint Backlog
Scrum 框架针对需要变更，设置了 Product Backlog（产品待办列表）和 Sprint Backlog（迭代待办列表）。在每个迭代开始时，产品负责人须要在 Product Backlog 中，通过优先级排序来筛选、整顿出这一迭代的 Sprint Backlog，也就是这一迭代须要实现的产品需要。也就是说，Product Backlog 是一直变动的，而 Sprint Backlog 是以后迭代中曾经确定的产品需要，是不变的。这样就会保障需要的变更不会影响到以后迭代的产出。
二、做好需要排序
设置 Sprint Backlog 就意味着咱们要做好需要排序，那需要的优先级由哪些维度来决定呢？一个维度是需要的重要紧急水平，比拟重要且紧急的需要要往前排，绝对不重要不紧急的需要往后排。如果咱们要交付一个电商平台的 MVP 版本，那下单领取的需要会比珍藏某一商品的需要重要的多，所以咱们天然须要优先解决下单领取的性能。
那 另一个维度其实是 需要的明确性，因为在我的项目的后期阶段，客户需要其实也不是那么清晰明确。所以咱们要考虑一下优先做曾经明确了的需要，同时和客户一直地沟通确认，将那些绝对含糊、可能会产生变动的需要确定下来，而后再排进相应的 Sprint Backlog 中。
客户在形容需要的时候，咱们能够用极限编程中的用户故事实际，将需要以“作为一个 < 用户角色 >，我想要 < 实现流动 >，以便于 < 实现价值 >”的模式进行表白，这样更有利于单方沟通、廓清需要。
三、对需要变更进行限度
确认好 Sprint Backlog 后，原则上不容许再变更需要。所以这就要求产品负责人须要对 Sprint Backlog 进行负责，提前与客户进行需要的沟通、确认。
- 如果遇到必须变更、优先级比拟高且对迭代影响较小的需要，咱们能够将这个需要放入迭代中，而后将本来迭代中优先级较低的需要替换进去；
- 如果遇到必须变更、优先级比拟高且对迭代影响较大的需要，则须要和客户同步并确认后，将以后进行中的迭代暂停，产品负责人从新布局新一期的 Sprint Backlog。
在这种状况下，我的项目团队和产品负责人要做好足够的应急预案，例如产品负责人要提前布局出接下来的几期 Sprint Backlog，以便呈现需要变更时，更疾速地响应。
“怅然面对需要变动，即便在开发前期也一样。为了客户的竞争劣势，麻利过程掌控变动。”麻利 项目管理的过程是一个动静过程，在这一过程中，波及客户、我的项目团队、利益相关者等多方因素，而且这些因素的变动会影响其余因素的流动。所以在变动不可预知的状况下，咱们就须要化被动为被动，踊跃应答我的项目过程中的各种需要变动。以进步客户的竞争劣势为目标，在变动中寻找解决的办法，寻求单方对立意见的达成，将需要变更的老本降至最低，实现提高效率与保证质量的对立。
往期文章举荐：
如何无效进行回顾会议（上）？
如何无效进行回顾会议（中）？
如何无效改良回顾会议（下）？