Scrum 项目如何获得管理层的支持和合作

Scrum 项目在公司的组织结构中无法单独生存，必然需要公司其他部门的合作和约束。Andrew Pham 和 Phuong-Van Pham 在“ Scrum in Action ”中分享了和管理层沟通的技巧和经验。

除非你独立工作或者就职于小型的创业公司，否则项目经理总是需要和组织内的许多人沟通来推进项目。虽然 Scrum 本身没有项目经理的概念，但是这并不意味着项目管理被抛弃了。对于实践 Scrum 的人来说，我们知道 Scrum 中的项目管理责任被转化并分配给了产品负责人、团队和 ScrumMaster。

企业高层管理者

在与企业高层管理者（如 CEO、总裁、首席财务官或者业务部门的高级副总裁）沟通时，Andrew 和 Phuong 建议避免谈论 Scrum 会如何帮助你更快地构建更好的软件：

作为企业高层，他们会对你彬彬有礼，但是最终拒绝你，同时还会奇怪到底是谁把你招进了公司——浪费他们的时间泛泛而谈，而不是通过他们更加容易理解的财务术语来提出想法。​虽然构建更好的软件或者改进开发人员的效率对高管来说重要，但是他们更感兴趣的是公司整体市场份额、大规模的成本降低和整体的利润率。因此，尽管你对 Scrum 怀有好感，但是不要得意忘形地和高管谈论如果你被允许使用 Scrum 之后你的软件会如何出色或者你的构建会如何迅速。

​​相反，通过数字或者至少是整体的业务战略来把你的技术实力和热情与高管的财务思想关联起来。不论和你组织里的哪个人交流，都必须考虑倾听者的观点和角度，并就此沟通。​了解 IT 项目如何适应高管的整体构想和战略将帮助你更加有效地告诉他们，你的项目将如何对公司的整体战略做出贡献。请谨记，通过财务数据（也就是业务语言）将你的项目贡献​与公司联系起来是很重要的。你的老板会感谢你。

关于项目管理办公室，Andrew 和 Phuong 建议：作为负责 IT 绩效并与公司业务需求和战略保持一致的机构，项目管理办公室（PMO）应该是你第一个需要面对的机构。如果你了解 PMO 的关注点，你应该很容易把 PMO 变成盟友，因为它的使命是确保 IT 项目为业务带来最大价值。毕竟，我们对产品负责人的使命的所有了解应该来自于 Scrum 项目，不是吗？​​

中层管理者

在我们深入讨论中层管理者或者执行团队的职责之前，我们应该搞清楚在日常职责中，这些人​的工作受你的项目影响最大。Andrew 和 Phuong 建议：

因此，你有必要取得他们的支持来成功地完成项目。请记住，中层管理者的作用不是来捣乱的，而是提供支持和帮助。他们关注的是把问题降到最小，看起来像是一个成功的团队，并在正确的时间做事情。变化总是困难的，需要合理的管理。你作为给团队带来变化的人，应该了解大家通常是如何处理变化的。你必须知道如何与中层沟通并给与他们足够的理由使之相信这些变化让他们受益。当大家听到变化来临时，你可以期待的最好反馈是他们尝试理解这些变化会带给他们的后果。希望，反馈不是恐惧和反感。​接下来，根据沟通和收到信息的质量和数量​，他们可能直接或间接地抵制，或者如果他们认为对自己的工作和职业生涯有好处，他们会接受变化。因此，在沟通时，时刻记住对方的利益，确保你的沟通产生了所期望的结果，并且为你提供了你所需要的帮助。你应该计划的联系，保持接触，与您的项目将带来的变化将影响人们的沟通，你应沟通，在这样一种方式，他们可以清楚地看到，这是对他们有好处。你应该与会被项目引入的变化所影响的人保持沟通，并采用上述的方式使他们清楚地认识到这些变化对他们有好处。

质量保证管理层

考虑到 Scrum 中测试的重要性和变化本质，你应该想要与质量保证团队建立良好的关系。​根据你的公司是否已经为常用的 Scrum 实践做好准备，主要是测试基础设施方面，你可能需要为此或多或少的做些工作。如果 Scrum 是企业文化的一部分了，那么你只需要了解流程并试着利用。如果 Scrum 还没有成为企业文化的一部分，你可能需要向质量保证管理层解释 Scrum，特别是主管测试的人，并获取他们的支持。你可能要求他们派出某个人全程参与你的项目，并且 / 或者为项目搭建合适的测试环境，这样，你可以快速准备好自动化测试、回归测试和持续集成测试。

运维管理层

不论你喜欢与否，都无法避开运维管理层。他们负责控制所有的预生产和 / 或生产活动。确保和他们沟通并解释你所需要的东西，以便在每个 Sprint 结束时交付的代码符合他们的预期标准。首先，请记住，开发团队和运维团队具有不同的，有时是相反的目标。​作为开发团队的一员，你的目标是持续地交付对业务的实际价值​。但是，在此过程中，你引入了变化，而运维团队的目标是在确保一切稳定的状态下持续交付价值。因为 Scrum 开发的本质，会有更多的软件发布，通常存在许多更小的更新，而不是几个较大的更新，这些都需要运维团队来处理。运维团队不会也不能仅仅因为你的更新较小，而放弃他们的控制过程。这样做会导致在运行业务系统时增加中断。运维团队仍一如既往地严格实施预生产验证测试。整个变更过程保持不变，即使针对较小的更新。

因此，除非你的公司已经准备好了某种自服务的部分，或者更确切地说，自服务部署过程的自动化，否则请努力与运维团队做好日程安排，因为这会帮会组他们处理持续的更新。作为回报，他们会帮助并感激你。随着时间推移，运维团队会发现有更多时间处理其他工作，从而很高兴为开发团队提供变更支持，同时，也会保留对生产环境的所有控制。​

​​把你的直接管理者变成盟友

正如行业众所周知的，中层管理者的目标是确保项目前进，避免翻船，因此除非你直接向 CIO 或者 CEO 汇报，否则请花时间与你的中层管理者沟通，确保她完全理解了 Scrum 和它需要什么。如果你的经理不知道 Scrum 如何运行，而且你的项目进展不顺或者进度落后，那么存在这样的风险：你的经理希望很快地转化到传统的命令控制式过程。​​你必须尽可能地在项目启动之前向管理层解释清楚：Scrum 是什么、在项目日常执行时它的运行机制、在进展顺利时如何运转、在不顺利时如何运转。