三、避免这种情况发生的三个前置动作

好好学习，我们先说“怎么避免”。虽然你的项目已经发生了，但你以后还要做项目，你身边的朋友可能也会遇到同样的问题。所以这三个前置动作，你记住，以后用得上。

前置动作一：在项目启动时，把“问题处理机制”写进章程，而不是等出了问题再吵

绝大多数项目的问题处理机制是：“有问题？找PM。”“PM解决不了？找产研。”“产研也解决不了？互相甩锅。”

这是错的。

正确的做法是，在项目启动的第一天，你们就要签一个“问题升级与裁决机制”。这个机制里要写清楚：

什么问题属于现场PM决策范围

什么问题属于产研决策范围

什么问题需要双方协商

什么问题需要升级到公司高层裁决

升级的时限是什么（比如：24小时内无法达成一致，自动升级）

你可能会说：“老邱，我们项目都烂成这样了，现在说这个有什么用？”

有用。因为你现在依然可以补签这个机制。只是补签的时候，大家的心情不一样了。但如果你不补签，后面会更乱。

前置动作二：明确“现场工程师的双重汇报关系”，但区分“行政汇报”和“任务汇报”

好好学习，你发现没有，你们现场工程师风中凌乱的根本原因是什么？是因为他们同时被PM和产研指挥，而且这两个指挥系统没有优先级。

解决这个问题的方法很简单：明确谁管“做什么”，谁管“怎么做”。

现场PM管“做什么”：优先级、客户需求、交付节奏、资源调配。PM说“今天先把登录模块的Bug修完，客户下午要演示”。

产研管“怎么做”：技术方案、代码规范、问题根因分析、修复方案。产研说“登录模块的Bug集中在session超时处理，你们按这个方案修”。

现场工程师同时收到两个指令，怎么办？以PM的“做什么”为优先级，以产研的“怎么做”为执行标准。

如果PM说“今天修登录模块”，产研说“今天先测支付模块”，那听PM的。如果PM说“随便修修能演示就行”，产研说“必须按规范修，否则会有安全隐患”，那听产研的。

这个规则，必须在项目启动时就讲清楚，并且写进项目章程。所有人都签字。

前置动作三：建立“问题银行”，而不是“问题垃圾桶”

好好学习，你们现在的问题处理方式是：谁发现了问题，问题就是谁的。所以大家都不愿意发现问题，发现了也不愿意说，说了也不愿意负责解决。

这是人性。

解决这个问题的方法，是建立一个“问题银行”。

什么叫问题银行？就是任何人发现的问题，都记录到一个共享的问题清单里。但这个清单不是为了追责，而是为了悬赏。

谁解决了这个问题，谁就获得“问题积分”。积分可以兑换奖金、调休、荣誉、晋升加分。

你看，这样一搞，大家的心态就变了。从“我发现问题＝我惹麻烦”变成“我发现问题＝我发现了赚钱的机会”。

你们这个项目，产品问题太多，如果有一个问题银行，现场工程师会是最高兴的人。因为他们天天在现场，最清楚哪里有问题。

他们不是不想解决问题，他们是解决了问题也没有好处，不解决问题也没有惩罚，那凭什么要多干活？

好好学习，这三个前置动作，你现在做也不晚。只是现在做，阻力会大一些。但大一些也得做，不做就是等死。

四、已经发生了，现场PM该怎么做？

好好学习，你现在如果是那个想撂挑子的PM，我告诉你，你现在最不该做的就是撂挑子。

为什么？因为你一撂挑子，你就坐实了“这个PM不行”的评价。公司不会因为项目烂就不追责，公司只会因为项目烂了找一个人背锅。你不干，你就是那个锅。

那你不撂挑子，你该怎么办？

PM第一步：停止甩锅，开始“接锅”

你没有听错。你现在要做的不是甩锅，是接锅。

但接锅不是认罪，接锅是掌握主动权。

你去找你的领导，或者去找产研的领导，你说：“这个项目现在问题很多，交付日期快到了，我作为PM有不可推卸的责任。我前期对产品风险评估不足，对客户期望管理不到位，这是我的问题。现在我需要大家帮我一起解决问题，而不是互相指责。”

你这样说，不是认怂，是破局。

因为你说完这段话，对方就没法再甩锅给你了。你已经认了自己的那部分责任，对方如果再甩锅，就显得他格局小了。

PM第二步：重新定义“成功标准”

好好学习，你们现在的目标是“按期验收”。我告诉你，这个目标已经不可能了。你们现在还在为一个不可能的目标努力，所以所有人都在焦虑、都在甩锅。

你要做的是：重新定义成功标准。

去找客户，跟客户说：“王总，我们现在的系统还有一些问题需要优化，为了不影响您的业务使用，我们建议分两阶段交付。第一阶段我们先交付核心功能，保证您的业务能跑起来；第二阶段我们在一个月内完成所有优化和遗留问题的修复。您看这样可以吗？”

你看，这不是认输，这是管理期望。

客户也是人，客户也知道你们产品有问题。客户怕的不是延期，客户怕的是“你说能交付，结果一堆Bug，上线就出事故”。

如果你主动提出分阶段交付，客户会觉得你靠谱、你诚实、你在为客户着想。

PM第三步：夺回“指挥权”，但不是靠权力，是靠“信息”

好好学习，产研现在想夺权，想远程安排现场工程师工作让你打下手。你不能硬刚，因为硬刚你刚不过。产研有技术话语权，你没有。

你怎么夺回指挥权？靠信息。

你现在要做的，是成为整个项目信息最全的人。

客户要什么，你最清楚

现场有什么问题，你最清楚

哪些Bug影响了哪些功能，你最清楚

客户的验收标准是什么，你最清楚

当你是信息中心的时候，产研再牛，也得问你：“客户到底想要什么？”“这个Bug优先级多高？”“今天先修哪个？”

你不需要跟产研争“谁说了算”，你只需要让所有人意识到：没有你，他们寸步难行。

这就是PM的生存之道——不靠权力，靠信息。

PM第四步：建立“战时指挥部”

好好学习，你们现在的问题是各自为战。PM干PM的，产研干产研的，现场工程师不知道该听谁的。

你要建立一个“战时指挥部”。这个指挥部每天上午9点开15分钟站会，每天下午5点开15分钟复盘会。

站会只回答三个问题：

1.昨天干了什么

2.今天要干什么

3.遇到了什么阻碍

复盘会只回答两个问题：

1.今天解决了什么问题

2.明天还需要解决什么问题

所有决策必须在会上做出，所有决策必须有记录。谁不参会，谁就失去发言权。谁在会上不说，会后就别再说。

你看，这不是一个复杂的流程，这是一个让混乱变得有序的最小闭环。

五、已经发生了，产研该怎么做？

好好学习，你现在如果是那个想夺权的产研负责人，我告诉你，你现在最不该做的就是夺权。

为什么？因为你一夺权，你就成了“不懂现场的傲慢产研”。客户不会觉得你牛，客户只会觉得你们公司内部都在打架，不靠谱。

那你不夺权，你该怎么办？

产研第一步：承认“产品有问题”

好好学习，你们产研现在最大的问题，是不肯承认产品有问题。

你们说“产品在别的项目跑得好好的”，那是别的项目。这个项目就是有问题，你承不承认，问题都在那里。

你现在要做的，是大大方方承认：“我们产品在这个项目确实暴露了一些之前没发现的问题，我们需要现场团队帮我们一起定位和修复。”

你这样说，不是认输，是建立信任。

因为现场PM和工程师最烦的就是产研死不认错。你认了，大家反而会帮你。

产研第二步：派一个“技术接口人”去现场，而不是远程指挥

好好学习，你们想远程安排现场工程师工作，这是最蠢的做法。为什么？因为你远程，你看不到现场的真实情况，你不知道客户的真实环境，你不知道现场工程师的真实能力。

你要做的，是派一个“技术接口人”去现场，驻场一周。

这个人不是去指挥的，是去协同的。他负责：

帮助现场工程师分析问题根因

把现场的问题翻译成产研能理解的技术语言

把产研的修复方案翻译成现场能执行的操作指令

这个人到了现场，现场PM就不用夹在中间了。现场工程师也知道该听谁的了——听这个技术接口人的技术建议，听PM的任务优先级。

产研第三步：建立“问题分级响应机制”

好好学习，你们现在的问题是：所有问题都一样处理，所有问题都很紧急，所有问题都要立刻修。

这不对。

你们要建立一个问题分级响应机制：

P0级问题：系统崩溃、数据丢失、核心功能不可用。这些问题，产研要24小时在线，2小时内出方案，4小时内修复。

P1级问题：非核心功能不可用、严重性能问题。这些问题，产研要48小时内出方案，一周内修复。

P2级问题：体验问题、非关键Bug。这些问题，记录在案，一个月内修复。

P3级问题：建议性优化。这些问题，下个版本再说。

你看，有了这个分级机制，现场PM就知道哪些问题要立刻报，哪些问题可以缓缓。产研也知道哪些问题要优先投入资源。现场工程师也知道今天先修什么。