原文参见本人博客：技术管理 之 干系人管理

回想最初作为 Tech Lead 的情景，如果说到 干系人 这个词，总感觉是很遥远的，Tech Lead 管的都是技术上的事，干系人管理与我何干。然而，如果观察你身边出色的Tech Lead，就会发现TA和干系人之间的信任关系非同一般，对干系人也有很强的影响力。

为什么要做干系人管理

为了说明干系人管理的必要性，先看几个干系人管理做得不好可能带来的问题：

1. 被动响应干系人的需求，缺少必要沟通，结果总是驴唇不对马嘴

Tech Lead讨论起技术来头头是道，甚至发现一个新的技术框架，恨不得晚上加班也要尝个鲜。然而，面对一些和项目干系人的沟通，就没有这么多的热情了，通常比较被动，对方要什么，就给什么，甚至不过问为什么。

项目的关键干系人往往掌握着资源，他们对项目的各种约束非常清楚，会决定什么是项目的成功。当缺少需求背后的这些信息时，开发团队给到干系人的响应往往都是不理想的，在得到一些负面反馈后会持续产生反抗情绪：

他/她怎么总是找事，不把事情一次说清楚，这么折腾人有意思吗？

2. 干系人“吝啬”共享信息，一旦有信息都是紧急任务

一些干系人掌握着项目的核心信息，他们并不会将所有信息都共享给开发团队。一方面有很多信息只是在讨论阶段，还没有形成决策，传递给团队会影响团队，另一方面有些信息某种程度上比较敏感，并不适合让太多的人知道，因此干系人在共享信息方面会显得非常“吝啬”。

作为团队的Tech Lead，在没有任何上下文的时候，直接接收到一个决策信息，而且通常都是非常紧急的任务，如：

“明天一早要出一版方案，和XXX团队讨论可行性。”

“需求有些调整，本周内要完成开发工作量评估，看看是否能够在规定时间内完成项目开发。”

3. 多个干系人意见不统一，夹在中间，左右为难

在一个项目中，通常不会只有一个干系人，多个干系人因部门不同，角色不同，专业背景不同，对项目的期望和目标不同，不同的干系人会引导项目朝着不同的方向发展。

这些方向有些可能是相互冲突的，这通常都是因为干系人之间缺少必要地沟通，不了解对方的目标。作为开发团队，从不同干系人侧接收到有冲突的需求，不可能也无法给出一个满足各方需求的方案，左右为难。

4. 优先级突然变化，措手不及

很多情况下，干系人的决策是受各种因素限制的，如整体目标，战略方向，预算，时间等等，已经确定的决策被推翻或降低优先级是经常发生的事情，也有时候个别决策并不成熟，或只是临时方案，已经开发到一半的功能要回退，或者需要采取某些手段规避对当前业务功能的影响。

对于有强迫症的Tech Lead，这无疑像是在一幅构图精妙，笔法精湛的绘画作品上填上几笔打破设计的线条，让人看着那么难受，简直不能再叫做作品。加上项目时间紧迫，突变的优先级给开发团队带来工作量的增加，各种随意的更改，没有章法，没有规则，令人沮丧。

5. 与干系人沟通经常起冲突

这种情况并不少见，上面几种情况处理不好，沟通走到情绪化的极端，往往会直接导向每次沟通的气氛非常紧张，甚至剑拔弩张，针锋相对，不欢而散。非但问题没有解决，双方都会开始抵触和对方合作，导致很多事情无法推进。

上面几个问题都非常典型，相信大家在日常工作中还遇到过更多奇葩的问题。但这些难道都是项目的干系人在故意找茬刁难开发团队吗？当然不是，如果他/她不是竞争对手派来的卧底，怎么会希望自己的项目失败呢。虽然大家上下文不同，站在不同的视角，但都是为了项目的成功，只是在不同的信息面前的反应不同，因此在某些事情上大家的意见看上去是有冲突的。作为Tech Lead，掌握着软件开发过程中最核心的技术和方案，需要找到一些方法和这些干系人合作，共同把项目引导到正确的方向上。

如何管理干系人

回顾在项目上跟干系人的冲突，都是因为在同一件事情上大家的意见和想法不一致。因此，要管理干系人就要搞清楚哪些人对项目有着至关重要的影响，理解他们的目标和想法，并想办法让大家站在统一战线上，并肩作战。

识别干系人

项目上通常有很多的参与者，任何直接或间接参与到项目中并可能影响到项目的人都是干系人。

在开发团队看来，其他的人要么是需求方，要么是监督方，或是发号施令，或是在某个时间站出来“找茬”的。由于冲突的存在，很难让开发团队将所有参与者都放在同盟者的行列。而作为团队的Tech Lead，要意识到项目的成功一定是经过权衡找到满足所有干系人需求的方案，按时保质保量成功交付才算成功。

因此，首先要做的就是识别参与到项目中的所有干系人，并进行分类和排序：

• 关键干系人，对项目有巨大影响力和决策权，通常是公司高管或投资者。

• 主要干系人，直接受项目影响，并通过项目的成功受益。

• 次要干系人，间接受项目影响，比如项目的支持团队。

理解干系人

并非所有干系人都对项目有同等的兴趣，因此需要跟干系人建立良好的沟通渠道，理解不同干系人对项目的期望，特别是关键干系人和主要干系人。

虽然干系人在主动分享信息时会比较“吝啬”，但如果我们尝试主动建立沟通（最好是能够面对面地直接沟通），理解干系人真实的诉求和目标，对方也会因为被理解和被关注而更愿意分享他们的见解和意图。

特别是在某些事情上持反对意见的干系人，更要深入理解他们的动机，为什么会提出反对意见，有哪些限制因素，是否有些额外的诉求之前没有考虑到。只有解决了这些干系人反对背后的问题，才能找到双赢的解决方案。

当然，并不是干系人背后所有的诉求都能解决，比如上文提到的“沟通走到情绪化的极端”，见面就起冲突的干系人。在这种情况下，要尝试去寻找能够影响这个干系人的其他关键干系人或主要干系人，往往可能是这个干系人的直属领导，通过加强这些关键干系人或主要干系人的沟通来找到解决方案。

构建专业影响力

作为Tech Lead，影响干系人的另一个武器就是技术。依靠对项目技术架构的深入理解以及业务发展方向的把握，Tech Lead可以在项目的技术演进方向、解决方案设计、交付风险等方面给出非常有价值的建议，帮助干系人把项目引往更加合理的方向，帮助干系人获得成功，这非常有利于构建和干系人之间的信任关系。

Tech Lead可以通过技术分享，建立和干系人的定期技术沟通，定制项目技术规范，构建风险管理机制等方式，加强和干系人之间的信息同步，一方面更好的理解干系人的诉求，另一方面也能有更多的机会进行技术输出，打造技术氛围，构建在干系人一侧的技术专业影响力。

保持专业客观，解决真正的问题

理解干系人并不意味着要附和所有干系人的想法，将所有人的需求汇聚起来实现一个四不像，这无疑是饮鸩止渴。

在软件产品开发上，并不是所有人都是专家，在和干系人沟通过程中，也要客观地通过一些事实证据来说明实际情况，提供更专业的解决方案建议，对于一些有悖于设计原则或演进方向的内容，和干系人共同讨论，找出一个合理的解决方案，从根本上解决问题。这非常有助于在关键干系人面前建立专业影响力。

持续构建开放合作的氛围

与干系人的沟通应该是持续的，有效的沟通渠道可以帮助开发团队及时反馈目前遇到的问题，也给干系人一个分享想法的渠道，促进信息的流动，积极构建开放合作的氛围。

像上文中的比喻一样，软件产品开发就像很多人共同完成一幅绘画作品，需要各方彼此理解，相互信任，统一目标，这是一门艺术。作为Tech Lead，要发挥自己的专业优势，努力构建和干系人之间的信任关系，推动项目成功。