PMO应该消失吗?

当我进行大规模的转换时，我总是被问到这样的问题，“PMO应该消失吗?”其理由是，实现敏捷应该摆脱所有的监督、甘特图(Gantt Charts)、每周状态会议和发布日程安排。这样的例子不胜枚举。

在我回答这个问题之前，我想先给你们一些背景知识，从教练的角度来看，当我们落地时通常会看到什么。该公司处于临时状态。他们可能会按时交货，但并不总是准时。在这种环境下，范围蔓延是不可避免的，因为他们计划3个月、6个月，甚至12个月发布。当团队试图变得敏捷时，会有许多过程来确保产品能够真正推出。预先有一些发布计划，设定了期望。开发可能发生在sprint中，但是集成测试和验收测试滞后。有时做集成测试是如此复杂，以至于不得不在一个大的时间框中进行测试。当开发处亚博vip9通道于停滞状态时，业务就会变得无所事事。这个过程并不敏捷，如果你用甘特图来描述它，它就会像瀑布一样。

现在想想你组织中所有的关卡。发布计划结束。每周变更控制。发布调度。释放签字。部署计划。部署变更控制。我曾见过一些组织在通宵部署期间有20个人在打电话。为什么会这样呢?答案很简单。 Over time the organization has created an environment of mistrust. Promises have been broken. Buggy software has been delivered to customers. Fingers pointed; “Requirements were bad”, “Development is slow”, “Too many last minute changes.” A number of reasons have caused the need for the stage gates. Once a stage gate exists it’s difficult to remove.

为了让组织回到正轨，我们需要重新关注构成敏捷过程的3件事;待办事项、团队和工作测试软件。从本质上讲，就是清晰、问责和可衡量的进展。为了做到这一点，我们需要治理、结构和度量。这些东西会让我们进入一个可预测的状态。一旦我们得到了可预测的，我们就可以开始重建对组织的信任。

为了让一个组织回到正轨，我们需要关注构成敏捷过程的3件事;待办事项、团队和工作测试软件。

治理模型必须从上到下对组织进行分割。在许多组织中，这将以至少3层的形式出现;项目组合、计划和团队。Portfolio层将处理主题和史诗的创建、定义和优先级。程序层将创建定义和功能优先级。团队级别负责实现来自特性的用户描述。此治理模型将进一步定义从初始到部署的流程流。

我在这里简要描述的是走向逻辑规划的转换策略的第一步。正如您所看到的，在这第一步中，我们清楚地定义了导致可预测过程的结构和治理模型。我们不能只是教授敏捷实践，然后希望每个人都能看到光明。组织中有许多手动编排活动来保持一切进展。随着组织朝着一个更加分离的交付系统的规模进一步前进，手工编配将会减少。我将这种手动编排和稳定流程称为搭建。随着手工编排的减少，脚手架可以开始下降。在您的转换中，确定脚手架并计划作为您未来转换工作的一部分来删除它是很重要的。

一旦我们得到了可预测的，我们就可以开始重建对组织的信任。

所以，“PMO应该消失吗?”不是在这种情况下。组织的某些部分需要在转换的这个阶段促进手工编排。如果您的组织已经有一个项目管理办公室，那么这些就是您需要帮助的人员类型。

PMO有一天会消失吗?我能给出的唯一负责任的回答是:“当贵公司准备好了的时候。”

最后一个警告。我已经看到一些组织被分离了，一些部分由于组织和技术债务需要PMO，而其他部分已经被构建为解耦的，并且在一个持续的交付周期中消除了手工编排的需要。