大多数工程管理内容将利益相关者视为需要管理的敌对资源：转移他们的请求，管理他们的期望，保护团队免受他们的影响。这种框架是错误的，也是许多新兴市场与利益相关者关系最终恶化的原因。
利益相关者不是障碍。他们是 原因 团队还有工作要做。我们的工作不是管理他们，而是管理他们。它是在两种语言之间进行翻译：工程现实和商业现实。大多数新兴市场在这方面做得很糟糕，因为没有人教他们如何做。
这是剧本。翻译人员的工作、五个经常出现的利益相关者个性以及每个人如何打破团队的冲刺、处理 90% 的一对一利益相关者沟通的每周更新模板，以及在不破坏关系的情况下保护团队的规则。
翻译问题
工程师和利益相关者使用相同的词语来表示不同的事物。
- “这需要一周时间。” 工程师的意思是“在一个没有中断的完美世界中，这是一周的专注工作。”利益相关者听到“7 天后我们会将其放在我的办公桌上。”
- “完成了。” 工程师的意思是“代码通过测试并且位于 main 中”。利益相关者的意思是“用户可以使用它，我们已经衡量了影响。”
- “简单。” 工程师的意思是“没有新颖的概念”。利益相关者的意思是“我们今天下午应该可以做到。”
- “我们需要重构 X。” 工程师的意思是“代码正在造成真正的问题，如果我们不解决，我们将付出代价。”利益相关者听到“工程界想要摆弄代码而不是发布功能。”
翻译不是可选的。要么是 EM 故意这样做，要么是意外且严重地发生。第一个习惯：
每当一个句子对团队和利益相关者来说可能意味着两种不同的事物时，请在就任何事情达成一致之前用两种语言明确地重申它。
五种利益相关者性格以及每种性格如何打破冲刺
模式重复。大多数新兴市场最终都会遇到这五种情况。行为和修复：
1. 热切的总理
行为：不断提出新想法。每个 Slack DM 都是“我们也可以……吗？”治疗 待办列表 作为头脑风暴的表面。没有意识到每个新的要求都会消耗冲刺能力。
出了什么问题：该团队累积了 30 张部分指定的工单。冲刺计划变成了分类而不是承诺。每次优先级发生变化时，工程师都会失去背景信息。
修复：两个通道；一种用于想法，一种用于承诺。想法会进入共享文档或具有“概念”状态的待办列表工作。承诺通过冲刺计划。这不是官僚主义，而是官僚主义。它将“我们可以”和“我们愿意吗”分开，这样团队就可以集中精力。
脚本：“添加到想法文档中；让我们在下一个冲刺计划中讨论是否优先考虑它。当前的冲刺已提交。”
2. 焦虑的创始人/首席执行官
行为：每天对单个功能进行 ping 操作。询问状态，有时一天多次。读茶叶。担心工程进展“太慢”。
出了什么问题：工程师被迫进行临时状态更新，而这些更新不会增加价值。团队感觉受到监视，而不是被信任。创始人收到了他们不应该收到的信号（一个错误就变成了“工程无法交付”）。
修复：可预测的更新通道。每周书面更新（模板如下）。对于更大的计划，创始人可以通过单个仪表板或文档进行自助服务。大多数焦虑的创始人一找到地方就会停止ping。
脚本：“我会每周五发送一份书面更新。对于[重大倡议]，这里是仪表板；我会保持最新状态。如果您在周五之间需要什么，请直接联系我，我会在当天回复。”
3. 持怀疑态度的财务主管
行为：询问“本季度工程交付了什么？”隐含的框架是“为了我们花的钱”。想要将工程输出转换为可数单位。将工程视为成本中心。
出了什么问题：团队感觉工单数量减少了。内部工作（重构、基础设施、待命）是不可见的。战略项目因进展缓慢而受到惩罚。
修复：以结果而非产出为主导。不要说“我们交付了 47 张票”。假设“我们将结账错误率从 4.2% 降低到 0.8%，每月损失的订单预计可收回 X 英镑。”每次季度审查将工程工作转化为业务影响。
脚本：“季度总结；成果以及每个成果背后的工作。三大成果，两项正在进行的投资，我们正在管理的一项风险。”
4. 领域专家利益相关者
行为：深入了解自己的业务领域。对于功能应该如何工作有强烈的意见，通常基于长期的经验。当工程实施不同的东西时感到沮丧。
出了什么问题：工程团队交付了成果，利益相关者却不满意，于是需要返工。或者工程团队提出异议，利益相关者觉得被忽视，关系随之恶化。
修复：将它们拉入需求 之前 工程开始。与利益相关者一起对用户故事和验收标准进行 30 分钟的审查值得一周的返工。不要将其作为“最后的演示”；使其“在开始时审查规范”。
脚本：“在我们开始之前，与您一起浏览一下规范；30 分钟。现在就抓住错过的细微差别比我们构建了错误的东西更好。”
5. 不参与的利益相关者
行为：说“你决定”。不出现在演示中。不回答澄清问题。当结果不是他们想要的时候就会抱怨。
出了什么问题：工程团队基于假设完成交付，随后因这些假设受到责备。或者工程团队停下来等待输入， 冲刺目标 滑倒了。
修复：强制在计时器上做出决定。 “我们需要在周三之前就 X 做出决定；如果我们没有做出决定，我们将采用[默认]。默认值是合理的，但不是您权衡后会选择的。”
脚本：“需要做出决定：A 或 B。如果您不参与讨论，我们将在周三默认选择 A。A 没问题；如果您因为我们看不到的原因更喜欢 B，请到那时告诉我们。”
每周利益相关者更新模板
90% 的利益相关者沟通可以通过每周书面更新来处理。三段：
本周交付了什么：用户可见的结果，以其业务影响命名。不是“合并身份验证重构”； “登录用户的页面加载速度提高了 30%。”
飞行中的内容：积极的冲刺工作，表示为冲刺的目标结果。如果存在风险（有人外出、依赖性下降），请在此处简单地列出风险。
接下来是什么：关于下一个冲刺重点的一句话，作为结果。
下面还有两行：
- 去哪里看：链接到他们可以自助服务的仪表板/冲刺板/指标图表。
- 我需要你做什么: 明确询问，如果有的话。 “我需要在周二之前就定价等级做出决定，以便我们可以将其纳入下一个冲刺中。”
这种格式之所以有效，是因为它回答了利益相关者实际提出的三个问题：发生了什么变化、现在正在发生什么、即将发生什么。没有更新，他们就会发明答案。
升级规则：保护团队而不破坏关系
工程师倾向于：
- 默默承受利益相关者压力，达不到目标，怨恨利益相关者。或者
- 直接抵制利益相关者，损害关系，并失去对工程的政治支持。
两者都不起作用。中间的路径是 可见的 权衡对话：
“是的，我们可以做 X。为了在这个冲刺中做到这一点，我们会削减 A 或 B。如果 A 和 B 的优先级更高，我们将推迟 X。你的决定。”
这是有效的，因为：
- 它没有说不；它说“这是权衡”。
- 它将决定权交给了利益相关者。
- 它记录了权衡，因此 回顾性的 对话有数据。
- 它并不假装团队拥有无限的能力。
团队最终得到相同的结果； 受保护的冲刺能力，推迟新工作;但利益相关者感到自己的意见被倾听，而不是被转移。大多数利益相关者在看到权衡后都会选择默认值（“好吧，推迟到下一个冲刺”）。
少做三件事
损害关系的常见利益相关者管理错误：
-
不要将工程复杂性转化为努力英雄主义。 “这真的很难”意味着应该感谢工程师。利益相关者并不关心这有多困难；他们关心的是。他们关心自己得到的东西。谈论结果，而不是汗水。
-
不要成为团队唯一的利益相关者界面。如果只有 EM 与利益相关者交谈，工程师就无法发展这些技能，EM 就会成为瓶颈，利益相关者会感到与团队隔绝。选择几位高级工程师来共享界面，即使只是针对特定项目。
-
不要让利益相关者得到模糊的保证。没有具体细节的“我们正在取得进展”不如“周五我们已完成 60% 并步入正轨”更令人放心。含糊其辞意味着“他们不知道”，即使你知道。
多做三件事
-
展示你的推理，而不仅仅是你的结论。 “我们选择 B 是因为 A 意味着需要 3 周时间依赖平台团队；计算如下。”利益相关者信任新兴市场，即使他们不同意，他们也可以遵循他们的推理。
-
预防他们可预见的担忧。财务总是询问成本。销售人员总是询问时间表。创始人总是询问竞争风险。在他们提出询问之前先解决他们的问题。
-
让团队了解利益相关者的反馈。当利益相关者对交付成果满意时，把反馈分享给实现它的工程师。不满意时，也应以建设性的方式传达。工程师如果从未听到利益相关者的反馈，就会逐渐失去与业务的联系。
总结
利益相关者不是敌人。他们是工作的源头，他们需要一位称职的翻译人员在他们的语言和团队的语言之间进行翻译。译员的工作就是 EM 的工作。刻意去做：
- 在达成一致之前，用两种语言重申不明确的陈述。
- 认识五种性格并针对每种性格使用结构修复方法。
- 每周发送一次书面更新，这样焦虑就不会变成临时的通知。
- 让权衡显而易见；通过揭露必须削减的内容（而不是拒绝）来保护团队的能力。
如果做得好，利益相关者管理就不会增加新兴市场的时间负担。这是他们整周所做的杠杆率最高的事情，因为所有其他工程输出都流经它。
冲刺目标、范围变更和利益相关者更新都集中在一处？ SprintFlint 跟踪目标，捕获针对目标的每个范围变更，并在最后自动生成书面的冲刺摘要。 免费试用：每月50张免费工单，无需刷卡。