90%的时间学技术，10%的时间学管人，但80%的项目问题，都出在“人”身上。
大家好，我是一名程序员。
上周，我被拉去参加一个听起来很“不程序员”的培训——《IT项目干系人管理实战》。说实话，一开始我是抗拒的：2.5小时？我能写多少行代码、修多少个bug啊！
但开场第一个问题，就把我问住了：“假设你刚被任命为‘电子会计档案系统’的项目经理。在你脑中闪现的第一个念头是什么？”
各个小组开始讨论，我心想：当然是技术选型啊！微服务还是单体？数据库用什么？但我错了。
培训里讲了一个真实案例，让我后背发凉：
某公司启动“会计电子档案系统”，财务总监亲自推动——20年纸质凭证堆积如山，审计越来越难，数字化迫在眉睫。
项目组很专业：
需求调研做了3个月
技术选型很先进（微服务 + 分布式存储）
开发过程也很顺利
6个月后，系统上线了。
但是——上线第一天，问题就炸了：
老会计王师傅拒绝使用：“我眼睛花了，看屏幕头疼。”
审计部张经理说：“电子档案的法律效力有问题，我们不认可。”
IT运维团队抱怨：“这系统架构我们没参与，不会维护。”
最致命的是：财务总监发现，税务凭证扫描清晰度不够，税务局不认！
投资100万、耗时半年的项目，上线一周就被迫暂停。
他们解决了“事”的问题（如何数字化），却完全忽略了“人”的问题（谁会用、谁在乎、谁会反对）。
我们都在重复这个错误，培训中展示了一组数据，让我彻底清醒：
近80%的项目失败，根源不在技术，而在“人”。
但讽刺的是——我们花90%的时间学算法、框架、架构，只花10%的时间学怎么和人打交道。
一张图，看懂该“抱谁的大腿”
培训里最实用的工具，是这张“权力-利益矩阵”：
小思考：为什么CEO属于“令其满意”而非“重点管理”？
因为对你来说这是生死大事，对他来说只是几十个项目之一。但他若不满意，随时能叫停你。
听懂他们的“潜台词”
干系人说的话，往往只是冰山一角。
培训给了三个“魔法问题”，帮你挖出真实需求：
“如果这个功能实现了，您最大的感受是什么？”→探求情感价值
“现在这个过程里，最让您头疼的是什么？”→发现真实痛点
“如果不做这个项目，会有什么后果？”→了解底线需求
那个被我们忽略的“地雷”
培训有个互动投票：
“哪个干系人最容易被忽略但影响最大？”
选项：IT运维、审计部、老员工、外部监管机构。
正确答案：审计部。
他们不参与建设，但有一票否决权。
等验收时说一句“电子档案法律效力不足”，项目就完了。
现在回到开头的问题
讲师最后让我们重新回答：
“如果你是项目经理，第一步做什么？”
参考答案是：
先找到所有会影响这个项目，以及会被这个项目影响的人。
不要急着跳进解决方案，
先搞清楚——你到底在为谁解决问题？
写在最后
作为程序员，我们总相信技术能解决一切
但现实是：
技术决定系统下限（能不能跑起来），
干系人管理决定系统上限（能不能用起来）。
培训结束时，讲师说了一句话让我印象深刻：
“成功的干系人管理往往看不见——当项目顺利推进时，你感觉不到它的存在。就像船的‘压舱石’，平时看不见，但确保船在风浪中不翻。”
从今天起，在写下一行代码之前，请先问自己两个问题：
我为谁而写？
他们真的需要吗？
别让你的技术，败给了人性。
后记
培训结束后，我更新了自己的待办事项。第一条不再是“优化数据库查询”，
而是——“约财务部老会计喝杯咖啡。”毕竟，代码最终是为人服务的。
