一个项目经理能不能扛事，先看他会不会这“三板斧”

项目顺的时候，其实很难看出一个项目经理到底行不行。

计划正常推进，大家各做各的，客户也没突然改需求，这时候项目经理每天开开会、跟跟进度，项目基本都能往前走。

真正拉开差距的，是项目开始出问题以后。

• 客户突然要求提前上线，
• 研发说时间不够，
• 供应商交期又不确定，
• 两个部门互相等资料，
• 领导还在问月底到底能不能交。

有的项目经理一遇到这种情况，立刻陷入救火。一天十几个电话，微信群里不断催人，哪个问题声音大就先处理哪个，自己忙得脚不沾地，项目却越来越乱。

但真正能扛事的项目经理，处理方式往往很像。

先把事情拆清楚，再把关键点抓出来，最后把问题一路推到结果。

这三件事看起来不复杂，却基本决定了一个项目经理是在跟项目，还是在真正控项目。

一、第一板斧：事情越乱，越要先把任务和责任拆清楚

很多项目经理一发现进度不对，第一反应就是催。

“这个什么时候能好？”
“那个能不能快一点？”
“客户等着呢，大家抓紧。”

催当然有用，但如果事情本身都没有拆清楚，催得越多，项目往往越乱。

比如一个系统项目原计划本月底上线，现在测试进度明显落后。

项目经理去问测试：“为什么还没测完？”测试说接口不稳定。

再去找研发，研发说接口已经做完了，是业务数据没准备好。

去问业务，业务又说数据规则还在等客户确认。

绕了一圈以后才发现，真正卡住项目的根本不是测试慢，而是客户的一项关键规则迟迟没有确认。

如果一开始只盯着“测试延期”，项目经理可能已经催了三天测试团队，真正的问题却一直没人处理。

所以我一直觉得，项目经理遇到复杂问题时，第一个动作不是马上协调，而是先把事情拆回来。

至少要搞清楚五件事：

• 问题到底发生在哪个任务，
• 前面依赖什么，
• 谁负责解决，
• 什么时候必须解决，
• 如果解决不了会影响哪个节点。

这也是为什么项目一开始就不能只留一张粗糙的计划表。

如果计划里只有“需求分析、开发、测试、上线”几个大节点，真正出问题的时候几乎没法判断。

实际做项目时，我更习惯一开始就在简道云里把项目拆成阶段和具体任务，把负责人、计划开始时间、计划完成时间、当前状态、重要紧急程度这些基础信息一起放进去。

比如“完成接口开发”还可以继续往下拆：

接口字段确认、客户数据提供、接口开发、联调测试、异常修复。

这样一旦联调卡住，不需要项目经理重新在群里把整个过程问一遍。打开对应任务，就能先看它前面依赖什么、负责人是谁、现在做到哪里。

这种管理方式最大的价值，不是让项目计划显得更专业，而是项目一乱，你还有地方可以迅速找到问题。

很多项目最后为什么失控？

不是没人努力，而是事情一多以后，所有问题都混在一起。

客户说的是需求问题，研发说的是开发问题，采购说的是交期问题，项目经理每天接收几十条信息，却没有办法快速判断这些问题到底和哪个任务、哪个节点有关。

等事情都混在微信群、邮件和口头沟通里，项目经理最后就只能靠记忆控项目。

项目小的时候还能撑。项目一多、参与部门一多，靠人脑肯定会漏。

真正能扛事的项目经理，第一项能力其实就是：

把复杂的问题重新变成一件件可以处理的事情。

二、第二板斧：别平均用力，先抓最可能影响交付的那几件事

新人项目经理特别容易出现一种状态：

每天都很忙。

• 十几个任务同时跟，
• 谁找过来就先处理谁，
• 哪个任务变红了就马上催，
• 群里有人@就立刻回复。

看起来响应特别快，但做久以后会发现，这种管理方式其实很危险。

因为项目里的任务，并不是每一件都同样重要。

举个很常见的例子。某个项目还有两周上线，现在有两个问题。

第一个，项目周报晚了一天，还没提交。

第二个，核心设备要求下周五到货，目前系统状态还是“进行中”，没有延期，但供应商到今天还没确认具体发货时间。

如果只看系统里的红色任务，周报已经延期，设备采购还正常。

很多项目经理会先催周报。但真正有经验的人，注意力一定会先放到设备采购。

因为周报晚一天，大概率不影响最终交付；设备晚一天，却可能直接导致后面的安装、调试全部往后推。

这就是项目经理第二个很重要的能力：

不要平均用力。

一个成熟项目经理每天真正需要盯的，通常只有少数几件事。

• 关键任务有没有正常往前走？
• 临近节点的任务有没有异常？
• 重要且紧急的事情有没有明确负责人？
• 已经延期的任务会不会继续影响后面？

在项目管理系统里，我通常不会单独只看延期任务，而是把任务的重要紧急程度、计划完成时间、当前状态和是否延期放在一起判断。

比如一项任务距离截止时间还有两天，状态却还是未开始，同时它又属于重要且紧急，那即使现在还没红，也应该提前介入。

再比如一项任务虽然延期半天，但只是内部资料整理，而且不影响任何关键节点，那项目经理完全没必要亲自冲进去处理。

这一步真正想解决的，是项目经理的注意力分配问题。

很多项目不是没人管，而是项目经理把大量时间耗在低价值的事情上。

所以我现在看项目，不太喜欢只问一句：

“现在完成率多少？”

完成率80%，不代表项目就安全。如果剩下的20%刚好是核心接口、客户验收和关键采购，那风险可能比完成率50%的时候还高。

反过来也是一样。一个项目有两个普通任务晚了一天，不代表整体项目已经失控。

项目经理真正需要形成的，是一种判断习惯：

什么事情晚了没关系，什么事情现在看起来没问题，其实已经必须介入。

这也是“扛事”和“勤快”最大的区别。勤快的人什么都管。能扛事的人知道现在最该管什么。

三、第三板斧：遇到重大问题，别只往上汇报，要把选择一起带过去

项目经理做到后面，经常会遇到一些自己决定不了的事情。

• 比如预算不够了。
• 客户突然增加范围。
• 关键资源同时被另一个项目占用。
• 原来的节点确定守不住。

这些问题该升级就必须升级，项目经理没必要什么都自己扛。

但问题在于，很多人的升级，其实只是转发问题。

跑去找领导说：“现在研发时间可能不够。”

领导问：“那怎么办？”

项目经理说：“我先来汇报一下，看领导怎么定。”

这种汇报方式，本质上还是把问题原封不动地交给了领导。

真正成熟一点的项目经理，会在升级之前先把账算清楚。

比如项目月底必须上线，现在研发确认至少还差10天工作量。

这时候项目经理去找领导，不应该只有一句：

“可能赶不上。”

至少应该整理出几个现实选择。

• 方案A，增加两个人临时支援，范围不变，节点尽量守住。
• 方案B，不增加资源，保留当前范围，上线时间顺延两周。
• 方案C，砍掉三个非核心功能，核心范围按原计划上线，剩余内容放到第二阶段。

然后把每个方案背后的影响说清楚：

• 需要多少资源，
• 会增加多少成本，
• 对客户有什么影响，
• 风险分别是什么。

领导真正需要做的是决策，不是重新替项目经理做分析。

这一点特别考验项目经理平时有没有把项目数据管起来。

如果日常任务一直散在Excel、群聊和个人笔记里，真正遇到重大问题时，项目经理通常要临时去问：

• 研发还剩多少工作？
• 哪些功能没做？
• 谁这周有时间？
• 后面测试需要几天？

等这些数据收齐，可能最佳决策时间已经过去了。

如果项目平时就在项目管理系统里持续更新任务状态、负责人、计划时间和关键节点，到了需要升级的时候，很多基础事实其实已经在系统里。

• 哪些任务卡住了，
• 哪些任务已经延期，
• 哪些任务还没开始，
• 哪个负责人同时挂着多个关键任务。

项目经理可以先把事实整理清楚，再带着方案去沟通。

但这里还有一个细节。

有方案，不等于开完会就结束了。

比如最后领导决定采用方案C，先砍掉三个非核心功能。

接下来还要继续落回项目执行：

• 哪些任务取消，
• 哪些任务调整截止时间，
• 测试范围怎么变，
• 客户由谁通知，
• 新的上线版本由谁确认。

这些动作如果没有重新落到任务和负责人上，会议上做出的决定很容易过两天又变成一句：

“上次不是说要调整吗？”

所以我更建议决策完成以后，直接回到项目里更新对应任务和节点。

该停的任务停掉，该调整时间的重新排期，该新增的动作补进去，并明确负责人。

问题真正结束的标准，不是领导知道了，也不是会上讨论过，而是新的方案已经进入执行。

这才叫闭环。

四、真正能扛事的人，会把这三板斧连起来用

单独看，这三件事都不复杂。但项目现场真正难的，是连续做对。

比如客户在项目中途突然增加一个需求。

差一点的项目经理第一反应可能是问研发：

“这个能不能顺便做一下？”

研发说可以，于是直接加进去。

过两周发现开发时间不够，开始加班；再过一周测试被压缩，最后上线延期。

成熟项目经理会先走第一步：

拆清楚。

这个需求到底增加哪些任务，需要谁参与，预计增加多少工作量，影响哪些已有任务。

然后第二步：抓关键。

新增需求会不会影响关键路径？原来的上线节点还能不能守？如果要做，最可能被挤压的是哪一部分？

最后第三步：推决策。

如果确实会影响上线，那就把选择摆出来。

增加资源、调整范围，还是调整时间。

决策确定以后，再把结果重新落到项目任务里。

这就是三板斧真正的价值。

它不是三套独立的方法，而是一套很稳定的处理顺序：

先把事情弄明白，再判断哪里最重要，最后把问题推到结果。

我现在越来越觉得，项目管理系统真正好用的地方也在这里。

不是为了多做一张表，也不是为了把所有人每天干了什么都记录下来。

而是项目一旦发生变化，项目经理能够很快回答几个问题：

• 现在到底哪里出了问题？
• 谁在负责？
• 会影响什么？
• 最晚什么时候必须处理？
• 决定做完以后，下一步谁来执行？

如果这些问题每天都要重新靠开会、问人和翻聊天记录才能回答，项目经理再能干，也迟早会变成项目里的信息瓶颈。

反过来，如果任务、节点、负责人和执行状态平时就在项目管理系统里持续更新，项目经理才能慢慢从到处问发生了什么，转向判断接下来应该做什么。

这一步，才是真正从跟项目走向控项目。

说在最后

所以一个项目经理到底能不能扛事，我觉得不需要看太复杂。

项目正常的时候，大家都能推进。

真正出问题时，看他能不能迅速做三件事：

• 把事情拆清楚，
• 把注意力放到真正影响结果的地方，
• 再把问题一直推到有结果。

• 不会拆，项目一乱就抓不到重点。
• 不会判断，每天忙得要死却总在处理小事。
• 不会闭环，问题汇报了一堆，最后还是没人真正解决。

项目经理所谓“扛事”，从来不是所有事情都自己冲上去解决。

真正让团队和领导放心的，是项目越复杂、问题越多，你反而越知道下一步应该抓什么。