第1章干系人识别

第一章：干系人识别——谁是嵌入式项目的真正决策者？如何绘制干系人地图

做嵌入式项目这么多年，我见过太多技术方案被推翻、项目延期、甚至直接夭折的案例。原因往往不是技术不行，而是——你根本没找对拍板的人。

说白了，嵌入式项目里，谁说了算？这个问题不搞清楚，你画再好的电路图、写再优雅的代码，都可能白费。我个人习惯，在项目启动的第一周，先花时间把干系人地图画出来。这步走对了，后面至少省一半的沟通成本。

很多人觉得，项目经理就是决策者。其实不一定。我遇到过好几次，项目经理在会上点头说“行”，结果回去被技术总监一票否决。为什么？因为项目经理管的是进度和资源，但技术路线、芯片选型、架构设计这些，最终拍板的往往是技术负责人。

嵌入式项目的决策者，通常分这么几类：

技术决策者：一般是系统架构师或技术总监。他们决定用什么MCU、选什么RTOS、通信协议怎么定。我在一个智能家居项目里，项目经理坚持用某款国产芯片，但技术总监评估后认为生态不成熟，直接换掉了。嗯，这就是技术决策者的权力。
业务决策者：产品经理或市场负责人。他们关心的是功能、成本、上市时间。比如，一个功能要不要砍？他们说了算。我记得有个车载项目，产品经理坚持要加OTA升级，技术团队觉得风险大，但最后还是按业务需求走了。
资源决策者：通常是部门总监或老板。他们管预算、人员调配。你想想看，项目要加人、要买昂贵的开发工具，谁点头？就是他们。
隐性决策者：这个容易被忽略。比如客户方的质量工程师、认证工程师。他们不直接说“行”，但能说“不行”。我曾经有个项目，因为没提前跟客户的EMC工程师沟通，最后认证阶段被卡了两个月。

核心观点：决策者不一定是头衔最大的人，而是那个能说“不”且不被推翻的人。

干系人地图，说白了就是一张“谁在项目里扮演什么角色”的图。我习惯用四步来画，简单实用。

别漏了。从项目发起人、客户代表、技术团队、测试团队、生产部门、采购、甚至法务。我有个习惯，把项目可能涉及的所有角色先写下来，哪怕暂时觉得不重要。比如，一个医疗器械项目，连注册法规人员都得算上。

这是最关键的。我一般用两个维度：权力（能不能拍板）和利益（项目成败对他影响大不大）。画个四象限：

权力/利益	利益高	利益低
权力高	关键干系人（重点管理）	保持满意（定期汇报）
权力低	保持知情（及时沟通）	最小关注（偶尔更新）

举个例子。技术总监通常权力高、利益也高，属于关键干系人。你得主动找他确认方案。而采购经理权力中等、利益中等，保持定期沟通就行。

谁和谁关系好？谁和谁有矛盾？这很重要。我见过一个项目，硬件负责人和软件负责人互相看不顺眼，结果每次联调都吵架。如果你提前知道这个关系，沟通时就能避开雷区。

不同的人，沟通方式不一样。关键干系人，我建议每周一次面对面汇报。保持满意的那类，发邮件摘要就够了。我曾经犯过一个错，对一位权力高但利益低的领导，频繁发详细报告，结果人家嫌烦。后来改成每月一次简报，反而效果更好。

我的小技巧：干系人地图不是画一次就完。项目中期、关键节点，记得更新。因为人的角色和态度会变。

这些年，我在干系人识别上栽过跟头。分享出来，你们别重蹈覆辙。

坑一：只盯着一个人。我曾经以为客户方的项目经理就是唯一决策者，结果方案被他们技术负责人直接否了。后来我才明白，嵌入式项目里，决策往往是多人博弈的结果。
坑二：忽略“反对者”。有个项目，生产部门的负责人一直对方案有意见，但我没当回事。结果量产时，他卡着工艺文件不放，项目延期两周。嗯，现在我会主动找“反对者”聊，提前化解矛盾。
坑三：信息不共享。干系人地图画好了，只自己看。其实应该让核心团队也知道。有一次，我忘了告诉软件负责人，客户方的测试经理是个关键人物，结果他沟通时态度随意，差点搞僵关系。

警告：干系人地图是活的。项目进入新阶段（比如从开发到测试），决策者可能会变。别偷懒，定期复盘。

去年我做的一个智能门锁项目，刚开始干系人地图画得很粗糙。只列了产品经理、技术总监、客户代表。结果做到一半，客户方的安全审计工程师突然介入，要求改加密方案。我们措手不及，加班两周才搞定。

后来我重新画了地图，把安全审计、认证机构、甚至最终用户（物业公司）都加进去了。每个角色标注了权力和利益，还画了关系线。你猜怎么着？后续沟通顺畅多了。安全审计工程师提前介入，方案一次过。

说白了，干系人识别不是走形式。它是你项目沟通的“导航地图”。地图画得准，你才知道该往哪走、该跟谁聊。

我建议你，下次项目启动时，花两小时做这件事：

别嫌麻烦。我做了15年，每次项目都先干这事。你会发现，很多沟通问题，其实在画地图时就已经解决了大半。

好了，这一章就到这里。下一章我们聊聊“如何跟技术决策者高效沟通”——那可是个技术活。