【五千字总结】项目对外推进乏力，有何“破局之策”

【五千字总结】项目对外推进乏力，有何“破局之策”

在“对外”推动项目时，如果客户方或合作方不配合，我们应该如何处理呢？本文作者从三个方面，对产品推进需求落地外部受阻该如何破局进行了分析，希望能给你带来一些帮助。

前段时间整理了“如果自己提的需求，技术同学不愿意做怎么办”（【七千字总结】如果你提的需求，技术同学“百般推诿”怎么办？）

这篇文章更多是在“对内”层面，即公司内部范围下的应对策略。相比而言，还有一类产品经理/项目经理在“对外”推动时受阻，即客户方或者合作方配合不足时，我们要如何处理。

两个问题结合起来，可以概括为一个问题：产品推进需求落地受阻时怎么办？

从面试的角度来看，我们首先便要区分内部受阻和外部受阻两类，再分别进行应对。

今天便来总结一下“外部受阻”时，我们如何破局。

同样，以下内容均来自实践经验，可能存在场景考虑不足的情况，欢迎各位以小见大、举一反三、不吝赐教。

按照习惯，本文将从三个方面进行分析：

1. 归类外部受阻的常见原因
2. 寻找这些阻力的应对措施
3. 试着深度挖掘表象背后的深层原因

一、他们为什么不想配合你？

在对外推进受阻时，原因大体归结为这几点：产品价值、利益分配、关联难度、以及优先级排期。当然，优先级排期也是基于多种原因导致。

我们还需要针对不同的合作方来区分不同的原因，其中主要在于主办部门与协办部门之间的目标与价值。

1. 产品价值与利益的不匹配

无论是主办部门还是协办部门，此项目推进成功之后，能够为其带来哪些效果？下面我列举几个常见的例子来说明：

• 主办部门通过前期的调研、立项、招标，进入实施过程之后，部门领导突然被调走，新来的领导对现有产品的合作模式、预期效果不认可，但是合作关系已经形成，那么很容易在后期推进的过程中不重视。
• 主办部门和协办部门本身对于此产品上线后的应用场景、预期用户存在一定的重合，即便主办部门在极力推进，但协办部门配合的意愿度并不高。
• 前期调研时的结果，与落地交付时的结果存在偏差，可能是因为市场发生了快速变化，也可能在入场之后客户发现此产品并不能完全匹配业务目标，因此要求实施方对方案进行大规模改造。而实施方因为交付成本、项目周期等因素无法做到快速响应，导致双方在合作过程中出现了目标偏差。

以上三个例子，都是在实际工作中经常遇到的问题，而每一类问题又不是单方面因素导致，也可能不是由具体的执行人、负责人能够决策，因此在推进过程中屡屡受阻

2. 交付难度比预期大很多

虽说双方合作可能是基于标准化产品，但在产品落地过程中需要结合客户的实际情况进行适配。包含了业务功能的适配以及关联系统的适配。

业务功能的适配可能存在某个业务改造会对原有核心场景造成较大的影响，需要产品经理、项目经理进行更加全面的改造分析；

而关联系统的适配，则受限于更加多变、更加特色化的现状，导致现有系统无法满足场景，修改起来又增加了协办部门的配合力度，同时也为自身系统的联调加大困难。

对于一些重点项目，有时也面临政策的调整，用户受市场环境的影响等原因，让原本的标准化产品需要更具有业务拓展性和适应性。

而这些因素，都为产品的落地增加了层层困难，一方面反映出来便是客户方内部的协调受阻，优先级排序延后，最终影响到我们自身项目的推进。

3. 从角色角度拆分

无论形成问题的原因是什么，最终表现出来的情况，大体可以分为四种组合（主办部门、协办部门；业务负责人、高层领导）：

1. 主办部门业务负责人推进受阻
2. 协办部门业务负责人推进受阻
3. 主办部门高层领导推进受阻
4. 协办部门高层领导推进受阻

而且，很多时候当风险已然转变成问题出现时，原因错综复杂，表现情况也是多方受阻。因此，对外的困难，比对内的困难更加难以解决，也更考验我们的心态和能力。

二、不试试，怎么知道行不行？

1. 首先，要保证内部的工作没有大的偏差

对外反馈时，更应该注意在反馈之前保证本身（个人、团队）的工作在正常进行，否则很容易被“反客为主”。即便有些自以为已完成的工作，真正摆到会议上，也容易被对方系统甩锅。

即便有些工作我们还没有完成，或者因为某些原因导致延后，也要做到心中有数、有理有据有规划、汇报。在此基础上，再去推进外部进度则会更加主动。

这一点，我在刚入职的时候就被前辈多次提醒过。当遇到一些问题我想要找客户方对接人反馈时，老领导都会先问我一句：如果XX系统说，你们的XX功能还没有确定，所以他们才没有启动，你怎么办？

2. 试着和对接人做好“私人关系”

和上一篇文章一样，无论是对内、对外，协调这类问题时，“人情世故”依然是基础。试想如果你们之间关系不好，没有信任基础，即便我们的要求有理有据，对方也很难积极配合。

所以，即便代表不同的公司，即便是甲乙双方的合作关系，我们依然可以通过自身的正气、自身的能力、自身的专业性来赢得对方的认可。还可以通过私下的交流来增进革命感情。

这一点，其实非常重要。

当我们和对接人存在较好的关系之后，对方也会主动帮我们想办法，或者介绍一些靠自己很难了解的背后原因。而知道这些背后原因，对自己真正解决问题会有极大的帮助。

3. 帮助对方向上反馈

有时，对接人碍于上下级关系、或者同事关系，不太好向领导、向协作部门提出过多的要求。而这时，我们则需要在会议上，或者邮件里主动提出风险和方案，做好对接人的“高级嘴替”。

很多话，可能大家心知肚明，但就是没人来捅破这层窗户纸。如果不捅破，自己的团队将长期位于高风险之下。

不过，真正在做“嘴替”时，也要讲究语言的艺术，不要太直接，毕竟“枪打出头鸟”。我们可以采用委婉，主动担一小部分责任，或者带着合理的解决方案等方式，在正式/非正式场合对外反馈。

4. 一起分析现状和问题

无论是协办部门配合受阻，还是关联系统改造难度大，从态度方面我们都要积极面对，毕竟，自己所处的团队是这个项目的第一负责人。我们可以和对接人一起分析现有的问题，讨论可行性方案，方案可以有多个，有时也会陷入两难的境地。具体如何决策可以由对接人结合现状来决策。

涉及到较为复杂的问题，可以由对接人“攒局”，自己详细和关联方沟通，本着解决问题的态度，寻找多样化的解决方案。当方案制定完成之后，再由对接人按照客户方的流程进行推进。

于情、于理、于流程、于方法，努力做到“尽人事”。

5. 饼不要画得太大、太满

前期很多对接人不愿意配合，是因为觉得这个系统不重要。或者像上文提到的，可能主系统会把现有的某个辅助系统的客户“抢”走，所以协办部门也不愿意主动配合。

针对这类问题，其实更多的是执行人的困惑，对于上层的领导，在制定主系统建设规划时，已经对此有过相应的权衡分析。因此，我们可以在私下，或者工作时间的非正式会议上，和对方阐述系统的价值，并结合客户方现有业务现状、痛点，以及系统的解决方案等方面进行表达。

毕竟，从客户高层视角分析，是A产品价值高还是B产品价值高，对于整体而言都有益处。所以A与B之间的竞争、协作，只是达到整体目标的途径之一。

不过，在这种情况下，切忌“冠冕堂皇”，要把语言润色成简洁、容易理解和记忆的口语。更像是一个30秒的电梯演讲，或者几分钟的产品介绍。

提前准备好这些话术，在真正遇到问题，或者需要临时表达的场合时，才能从容应对。这一点，无论是对内、对外，作为产品人都需要对自己各个产品的价值、意义理解清楚，形成不同的表达方式：

• 一句话介绍自己的产品
• 30秒的电梯演讲
• 会议上的开场白
• 客户营销时的快速介绍

以上这些场景，都应该有理解、内化、随用随取。

6. 借助公司的资源

对于个人无法推进的问题，还要善于借助公司的资源。尤其是在客户方高层领导方面，无论是从职位的匹配度，或者沟通经验上，自己会很欠缺。

因此，我们需要自下而上进行反馈，主动推进，协调公司高层、商务团队的力量，寻找契机和客户方进行沟通，再通过自上而下的方式来推进。

但是，在借助公司资源之前，我们要做好定期的工作汇报，免得大家临时“抓瞎”。

7. 做好每个节点的工作汇报

其实无论工作是否存在问题和风险，定期向上汇报、向客户汇报，都是必不可少的。不同的团队汇报方式不同、频次也不同。我认为抛开形式，汇报的周期和内容要简洁、全面。

• 首先是现阶段的进度，以及重要的里程碑节点，整体的规划安排；
• 其次是进度与规划的偏离程度，偏离原因，以及自己正在采取、计划采取的方案；
• 另外则是现在预估的风险，风险形成的原因，以及现在面临的问题。今天所述的内容，大多都属于风险和问题的范围。

定期的文字汇报，再加上适时的会议、电话沟通，把现阶段的情况如实反馈出来，当真正需要协调公司资源出面解决时，各个环节都有心理预期，自己也能够更宏观的审视现状。

最终，大多数客户还是会秉持契约精神，最终把项目推进下去，问题解决之后，我们更要注意的则是内部推进过程的速度和质量。如果后期经常被客户催促、抱怨，那新一轮的风险又会潜移默化的积累起来。

三、困境的形成，更多在于前期的风险积累

这一节，我们试着跳脱出问题的表象，从更宏观的角度来审视外部推进受阻形成的深层原因。（不一定最深，但比遇到问题解决问题，要更主动些）

1. 产品标准化程度不足

最近几年，即便是定制的交付项目，也越来越看重标准化产品。“产品+定制”俨然成为大客户采购的基础。

而标准化，并不代表一成不变，更应是适配能力强、场景覆盖全面、拓展能力强的一套综合性产品。当然，这样的产品市场上并不多见，除非是一些从行业政策上非常规范的业务。

所以，很多标准化产品更多在PaaS层、低代码层、或者配置化程度上进行升级。而对于一个逐渐演进的产品进行这样的架构升级，难度几乎超过了重构。

很多定制化场景，因为产品的拓展性不足（业务拓展性+技术拓展性），产品交付手册缺失（业务说明书、开发手册等），在交付现场面对客户的实际场景，犹如“盲人摸象”。

基于这些现状，最终的产出物势必会和客户预期存在偏差，进而导致客户的不满以及在推进过程中的困境。

不过，这类问题如果想解决，那可太难了……

2. 售前阶段，以及售前和交付对接过程的缺失

很多时候，无论是项目经理入场，还是产品经理接手，仅是针对本次项目的现状进行临时性方案讨论。而一次定制化项目的合作，势必涉及到从销售阶段，到售前阶段，经历多轮沟通和博弈，最终达成的合作。而前期的过程、以及预知的问题，真正的执行人了解吗？

前两年，我也做过售前，也和售前团队一起整理过从售前到交付的交接清单，发现在正式开始实施之前，大多数团队对于客户的了解、背景的了解、合作方人员的了解、甚至建设范围以及口头承诺功能的了解，都非常欠缺。

而这些事项的欠缺，便为后期的风险和问题埋下了一个大大的隐患。

去年，我便想把售前和交付之间的交接流程形成文字，可惜至今也没有开始，希望今年上半年能够整理完成吧。

3. 对风险的重视程度不足

很多同行对于风险的重视程度严重不足，有的是自上而下，有的是即便上级反复强调，真正的执行人也不在意。而这些风险即便不会全部转化为问题，但只要有几个真正变成问题之后，都会让自己的工作陷入艰难困境。

从时间管理的理论上，大体可以把事情分成四个维度：重要且紧急、重要不紧急、紧急不重要、不紧急不重要。

越来越多的团队会把工作重点铺在“重要且紧急”的任务中，反而忽略了“重要不紧急”的事项，等到这些不紧急的问题变成紧急的，才会纳入排期，从而形成恶性循环。

从时间管理层面，我们更应该把时间投入到重要不紧急的任务中，从而形成一个良性的机制。但做到这一点，不仅困难，也得不到大家的重视。

说回工作，风险事件即可划分到“重要不紧急”的范围，因为我们对于风险的认知不足，重视程度不足，无法将其“扼杀在萌芽阶段”，进而在后期形成一个又一个难解决的问题，让自己疲于应对。

4. 团队本身的拓展模式就是这样

对于很多创业型团队，产品本身的标准化程度不足，生存压力也很大，因此只能通过一场又一场的硬仗，让自己扛过去。都说扛过去之后，能够拨云见日，但如果仍然采用传统的拓展模式，越来越多的定制化之后，更会暴露越来越多的问题。何况还有很多团队没有扛过去。

定制化和标准化，本就是一场无休止的悖论，任何一种模式都有团队成功，也有团队失败。原因有很多，包含了行业、客户、团队、市场方方面面。但如果定制化的摊子铺的越来越大，从流程和策略上，势必又将面临一轮新的改革。

而一旦涉及到改革，其中的危机又会此起彼伏。

任何一次困境的形成，都不是一朝一夕、一人一事，笔者能力有限，无法把这些问题看透彻，讲明白。所以点到为止，希望各位领悟精神，一起探讨。

四、写在最后

本文以项目推进难为切入点，涉及项目经理、产品经理在工作中的一些常见问题。若想解决问题，都要先找到关键的矛盾点。

这就像我们做一款产品一样，要先找到真正的痛点，才能想出更合理的方案。同时要保持平和的心态，否则按照自己的角度，代入自己的情绪，一通输出，最终也只能让事情变得更尴尬、更为难。

换位看待、深入思考、有理有据、心平气和、善用资源、主动解决。祝大家都能把自己面临的问题推进下去。