下面的内容是我在作为一名程序员入职之前阅读的由Gergely Orosz写的The Software Engineer’s Guidebook。我将将阅读时得到的重要的信息总结成中文以供大家分享。
利益相关者是对项目结果有兴趣的人和团体。内部的利益相关者可能包括产品团队、法律团队、工程团队或任何其他业务单位。利益相关者也可能是公司外部的，包括用户、客户、供应商、监管机构等。
找出项目中关键利益相关者的最佳时机是在尽可能早的时候。最糟糕的时机是在你准备发布时，因为此时可能会出现一个重要的人物，第一次真正审视你的项目，并要求进行重大更改。在这种情况下，提前咨询这个关键利益相关者会更为妥当。
作为技术负责人，为什么需要管理利益相关者？为何要识别他们，并定期提供详细更新？是为了与他们保持良好关系吗？这种关系确实很重要，但这并不是主要目标。
利益相关者管理的重点在于项目成功，通过确保每个人都在同一页面上进行协作。许多项目失败的原因在于参与者对项目的目标和执行方式有不同的看法。这意味着，当工程团队宣布项目完成时，商业利益相关者往往会表示所开发的内容并不符合业务需求。
利益相关者管理涉及各种方法，以确保对项目有重要发言权的人都知道项目的进展情况、了解新的风险和变更，并且意识到对项目变更的关键应对措施且不持异议。这只是一个帮助项目成功的工具，确保每个人对成功的定义达成共识。
我参与的一个项目涉及多个团队，项目负责人与所有团队成员每周发送长篇状态更新，并在聊天中发布更新。然而，似乎每个人的方向都不同，真正的重点除了完成分配的工程任务外并不明确。最终，这个项目看起来像个失败，让每个人都感到不快。
在另一个类似复杂的项目中，目标更为明确，更新内容较少，但项目感觉更为团结。在我们交付时，商业利益相关者送给工程团队一瓶香槟以示感谢。这个项目与之前项目的不同之处在于，项目负责人与产品团队和商业利益相关者进行了更多的沟通。
良好的利益相关者管理高度依赖协作。在成功的项目中，技术负责人在电子邮件和书面更新方面进行了较少的“正式”利益相关者管理。他们所做的是与业务利益相关者进行面对面和视频交流。而且，技术负责人对业务领域足够熟悉，以至于在工程风险可能意味着需要改变工作范围时，能够明智地寻求业务的意见。”
对于大多数工程项目，利益相关者通常可分为以下几类：
将利益相关者分入以下类别可以成为一个有用的思维模型。可以将其想象成一条流动的河流，各个团队在上下游不同位置构建坝。
上游依赖是您所依赖的团队，他们必须完成特定任务，以便您的团队可以开展工作，从而推动项目的完成。
下游依赖是依赖您工作的团队。下游团队是在您的团队之后，他们的工作必须在您的工作完成之后才能继续进行。
战略利益相关者是您希望保持沟通的人或团队，他们通常可以帮助打通上游依赖。
这种分类有助于明确在特定情况下与哪些利益相关者沟通。例如：
作为一名技术负责人，了解你的主要利益相关者是至关重要的，因为不知情可能会在项目中引发浪费和延误。我有过这样的亲身经历。在一个项目中，我的团队忘记与一个“我们需要修改其服务的工程团队”分享工程计划——请求反馈（RFC）。当我们开始进行这一修改时，该工程团队因我们的做法和他们的系统不相符而阻止了此项工作。最终我们找到了解决方案，但由于不知道该团队是利益相关者，项目因此延误了两周。
在另一个案例中，我看到一个工程团队为了一个项目工作了一个月，结果法律部门出乎意料地介入并阻止了项目。尽管法律部门本应参与，但他们并没有被告知。他们审查了提议的变更，认为该项目风险过高，不愿意改变这一判断，因此项目被取消。如果工程团队能早些让法律团队参与，他们本可以避免很多不必要的工作。
那么，如何找出你的利益相关者呢？这个问题在拥有数十个甚至数百个工程团队以及大量产品/设计/数据和业务人员的大型公司中尤其重要。有两种方法可以找到利益相关者：一种是艰难的方式，如上所述，另一种是简单的方式：
直接询问！ 咨询确定的是利益相关者的人，了解还有谁可能是利益相关者。例如：
查看架构变更和代码。通过了解哪些代码部分和服务将在你的项目中被修改，通常可以找到工程利益相关者。联系负责这些代码和服务的团队。
在修改服务时，上游和下游利益相关者的概念非常有用。因为常见的冲突是某个工程团队修改服务，导致下游用户受到影响。通过及早识别下游用户作为关键利益相关者，可以避免这种情况。这样工程团队可以更早地获得反馈，并修改计划，以免破坏该团队的工作。
识别“常见利益相关者”。 有一些团队可以安全地假设对你的项目感兴趣。在中型和大型公司中，这些团队通常包括：
“利益相关者管理”是一个华丽的术语，指的是确保所有需要了解您团队正在进行的事情的人都了解这些信息。糟糕的利益相关者管理会让关键人物和团队错失沟通，导致挫折、投诉以及项目延误。一旦您识别了您的利益相关者，确保他们不会对您的团队所做的决策感到意外是非常重要的。 由于通常有多个利益相关者，逐一沟通实际上并不有效，以小组形式更新利益相关者会更高效。
我观察到有三种常见方式来保持利益相关者的更新：
了解您组织的文化是非常重要的；技术负责人和产品团队是如何向利益相关者更新信息的？利益相关者是否偏好某种格式的更新？如果是这样，那么在您负责的前几个项目中使用熟悉的格式可能会更为合理。
关于项目进展的主动书面沟通总是很有用。我见过的一种有效方法是定期发送更新电子邮件，内容包括进展、风险及其缓解措施、时间表变更以及对截止日期的信心。以下是一个更新电子邮件的示例：
电子邮件的一大优点是它充当了“主”状态更新，并在与利益相关者的会议及其他沟通中作为有用的参考。对于那些要求多或对项目发表很多意见的利益相关者，会议可能是必要的。然而，作为技术负责人，尽量让利益相关者将定期状态更新电子邮件视为‘真实来源’，将使确保所有利益相关者在同一页面上变得更加容易。
作为项目负责人，您将遇到问题利益相关者。那么，“问题”到底指的是什么呢？这取决于他们是下游、上游还是战略利益相关者：
在每种情况下，最大的问题往往是沟通和信任。以下是一些适用于上述所有群体的改进方法。
面对面沟通
与其通过聊天或电子邮件沟通，不如考虑与问题利益相关者面对面交谈。可以进行视频通话，或在工作场所见面，阐明您的观察结果。讨论可以改变什么以改善情况。例如，如果一个上游利益相关者不断询问您的团队是否可以更早交付一个里程碑，请向他们说明目前的进展和剩余的工作，反馈被催促并没有帮助，并达成更好的合作协议。
保持透明，进行教育
对于上游利益相关者和战略利益相关者——这两者通常都很不耐烦——解释需要做什么、原因，以及您目前的进展。面对面的会议是最容易做到这一点的方式。更新电子邮件是另一个保持透明和提供教育的方式。定期、诚实的进展更新有助于缓解紧张情绪，这也是我钟爱这种做法的原因之一。如果您撰写这些更新，有很大可能性只需将问题利益相关者添加到邮件列表中即可解决问题。
请求支持
有时，直接沟通和更透明的做法并不能奏效。如果您觉得无计可施，请寻求管理链或项目领导链的帮助。向拥有比您更高权限的人请求帮助和建议。
如果你能够妥善管理利益相关者，就能减少因某个未被告知的利益相关者而产生的意外延误风险。然而，如果你只专注于管理利益相关者，你将错过与项目相关的人的一个重要环节：向他们学习！
作为技术负责人，你可能会与不同团队和各种学科的利益相关者进行互动。这是一个绝佳的学习机会。探讨他们的专业领域、学科以及他们在业务中的角色。如我们在第五部分中所述，了解业务是高级员工的基本要求。技术负责人有机会通过日常与利益相关者的合作，在工作中学习。
以下是一些与利益相关者合作并向他们学习的有效方法：
向利益相关者学习的好处在于，这能让你在工作中更好地处理与他们的关系。当你理解他们的工作、领域和挑战时，更容易产生共鸣，并以他们能理解的方式表达你的项目的细节。
在面对面交流中，向利益相关者学习要比在远程环境中容易得多。在远程工作的情况下，说清楚你的意图并安排更集中的会议是非常重要的。以下是一位软件工程师和工程经理约翰·克里凯特的有效做法：
如果你在远程工作，可以给他们发送邀请。我发的内容是这样的：
‘嗨，X——我是约翰，我最近加入了[机构]，很希望能见到你，了解更多关于你所在业务领域的情况。如果你有空，我非常感谢你抽出15分钟的时间。 我已经在你的日历上找了一个空档，但如果不方便，请提出其他建议。非常感谢，——约翰’
可以适当添加业务领域或项目名称等细节。到目前为止，没有人拒绝过我！大多数人也乐于接受这个小聚会的延时或提供更长的时间。
我在通话时确保按时到达，并准备好一些问题来帮助推进谈话。通常这些问题是：