PMP职场实战108问 · 第70问

什么时候应该正面解决核心问题？

“能忍就忍，别撕破脸。”

这句话你听过多少次了？尤其在项目里，当冲突冒头时，周围人会劝你“以和为贵”“大局为重”。但我做项目管理十五年，最深的体感是：有些问题，你越绕路，它越会在你交项目的那天给你致命一击。

那到底什么时候该正面刚？什么时候该绕道走？今天咱们把这层窗户纸捅破。

为什么我们总选择“不解决”？

先别急着自责。不愿意正面解决核心问题，背后有三个很现实的原因：

1. 害怕关系破裂。尤其在中国职场，人情和项目进度常常纠缠在一起。你一拍桌子，对方可能记恨半年。
2. 担心暴露自己没掌控住。项目经理想展示“一切尽在掌控”，主动挑冲突等于承认“我hold不住了”。
3. 被“先干活再说”的思维绑架。很多项目经理把“解决问题”等同于“推进任务”，觉得只要活干了，矛盾自然就淡了。

结果呢？问题像地雷，你不扫，它就在那儿，等着你在最关键时刻爆炸。

三把尺子，帮你判断该不该正面解决

我总结了一个 “冲突分级决策模型” ，非常简单，你在脑子里过一遍就知道答案。

只要同时满足第一列的两个条件——不解决项目要完蛋 + 没别的路可走——你就必须正面解决。这时候不解决，就是失职。

一个真实的例子：技术选型拉锯战

去年我辅导的一个互联网中台项目，就踩了这个坑。

项目初期，技术负责人坚持要用自研框架，理由是“可控”。但团队里两个资深架构师评估后，发现该框架在并发处理上有个致命bug，修复至少需要三周。项目经理小L选择了“先做再说”，想着等bug爆了自然有人改。

结果呢？第三周集成测试时，系统崩了三次。客户CTO直接打给VP：“你们的技术方案到底谁把关的？”

此时再开复盘会，技术负责人和架构师已经相互指责了三轮，项目延期两周，信任成本损失惨重。

这个案例里，项目经理犯了两个错误：

• 第一周发现bug时，应该立即拉技术负责人、架构师和产品经理三方对齐，用数据说话：修复三周 vs 换成熟框架一周。这是正面解决核心冲突的最佳时机。
• 但他绕路了，导致小矛盾累积成团队信任危机。

如果当时他果断说：“我们必须现在决定，要么我让产品把工期从6周压到4周，你们用成熟框架；要么承担延期风险，但需要发邮件给所有干系人确认。”——这就是正面解决。

正面解决核心问题的四个实操步骤

当你判断必须正面解决时，别情绪化砸场子，按这个流程走：

第一步：锁定“核心问题”本身，而不是指责人

• ❌ 错误开场：“你们技术部总是拖延，这次必须换框架。”
• ✅ 正确开场：“目前两个方案，自研框架修复需3周，成熟框架集成需1周。我们来评估这两种选择对项目成本和风险的直接影响。”

第二步：用数据把“冲突”转化为“选择题”
把对方可能的“面子情绪”抽掉，变成理性选择。我常用的句式是：“如果我们选A，结果是X；选B，结果是Y。你建议选哪个？”

第三步：提前预设“输得起的结果”
正面解决不等于你要赢。有些时候，你的目标是“让决策更早发生”，而不是“按我的方案来”。只要核心风险被暴露了，你就赢了。

第四步：结束后马上做“关系修复动作”
冲突结束后，当天或第二天找个无关话题破冰：“刚才拍桌子的方式我知道不好，但我是真着急项目。”——真诚比圆滑更让人尊重。

一个反例：什么时候不该正面解决？

假设客户提出的需求改动很小（3人天），但你一正面解决，客户觉得你“较真”“情商低”，反而影响后续合作。这种场景，绕路或暂搁更明智。

关键判断标准永远只有一条：如果这个问题不解决，项目还能不能交付？

如果不能，你再怕冲突，也必须站出来。

📌 今日动作：打开你现有的项目，找出一个你回避了超过两周的冲突点。用上面的“三把尺子”打分：如果三个维度都指向“正面解决”，那么今天下班前，约相关方做一次15分钟的“核心问题对齐会”。

📚 返回 PMP职场实战108问 目录 →