危机公关随着近些年来信息科技和互联网技术的迅猛发展，越来越多的“危机公关”事件被公之于众并被广大民众所关注。这些“危机”大到国家层面的重大事故处理，也可以小至某某明星的“八卦丑闻”，还有诸如“神钢”造假、汽车断轴召回，某某餐饮公司食品卫生等等涵盖了生活中的方方面面，而如何进行“危机公关”已然成为了一个成功的企业（个人）所必修的课程。在项目管理中，也需要对时时出现的“危机”问题进行“公关”，作为项目经理若处置不当往往会造成团队在突发情况下产生混乱、延误解决问题的时机、蔓延问题的影响范围、造成客户的不满甚至导致整个项目的失败。正所谓不怕有问题，怕的是没有应对的解决方法。本文旨在针对技术研发类的项目，结合笔者的项目管理经验，对如何进行项目中的“危机公关”进行探讨。

网络危机公关发展

危机公关如何将买错卖商品在技术开发类的项目中，遇到的问题大致可分为研发中发生的技术错误、供应商物料的品质问题、制造生成过程中的工艺流程、质量管控问题、客户端发现的使用问题以及产品投入市场后的突发状况等。这些危机涵盖了项目中的各个环节，但处理这些问题都有着共通的思路可循，总体来说可以分为四个方面：

怎样给明星做危机公关1. 根因分析（Root Cause Analysis）

旅游业危机公关处理2. 风险评估（Risk Assessment）

网络危机公关发展3. 围堵（缓解）机制（Containment/Mitigation）

4. 纠正措施（Corrective Action）

常见的误区是遇到问题只关注于1根因分析和4纠正措施，而忽略了其他两点，这么做或许能够得到一定程度的处理方案，但从项目的层面来说其实并没有把整个问题解决了。作为项目经理除了技术上的措施，还需要关注客户层面的需求以及产品的成功交付。只有把这4个方面都做到位了，才能称得上真正度过了危机。下面就这4个方面进行一一介绍：

1. 根因分析（Root Cause Analysis）

根因即根本原因，发生了问题首当其冲就是要找出原因，这是解决问题的第一步。根本原因也是其他所有分析和相关措施的起点，就好比是船舵，只有方向找对了才会达到目标。根因分析的重要性不言而喻，但在实际分析根因的过程中，作为项目经理有以下几个注意事项：a) 根因分析只是起点，而不是最终目标

危机公关的目的是解决问题，换句话说就是要有方案。根因的确定只是制定相关方案的基础，最终客户和相关干系人所关心的往往不在于根因的细节，而是如何解决问题的细节。

在项目执行过程中，笔者有时会遇到这样一些供应商，他们在出了质量问题后会相当认真且细致地分析原因，和你每天开一次会汇报所进行的实验、测试的进展，报告也写得相当详细，能够把根因梳理归纳到极致。但问其怎么解决，却拿不出一份有目标、有时间点、落实到具体负责人的计划。作为甲方来说，这样折腾下来，除了了解乙方的技术细节和工作态度之外，对于解决实际问题没有丝毫的帮助。

同样在执行自己项目的时候，需要项目经理自身对根因分析有一个正确的定位，并引导项目团队合理地有限度地进行根因分析。b) 要把握住大方向

问题往往是突发的，时常需要项目经理能够在一个极短的时间内给出答复。有限的时间决定了一时半会不可能遍历所有可能的根因进行一一排查，只有把握住大方向，从大到小进行分析。

举个例子，有一款产品在客户使用时发生故障，需要找出根因。分析时可以遵循如下顺序：

危机公关文章

i. 客户操作错误or产品自身问题

ii. 若是产品自身问题，那么是批次缺陷or设计错误

iii. 若是设计错误，那么是软件问题or硬件问题

iv. 若是硬件问题，那么是用料不当or设计考虑不足

……依此类推

这样做的好处是每一步有了结论之后都可以说是对客户有了一定的交代。同时在定位了大方向后，一方面可以让团队着手于该范围内的分析，更重要的另一方面是项目经理可以根据已经划分出的范围开始考虑相应的对策，进行风险评估和制定围堵措施，这些和根因分析可以并行进行。c) 汇报根因要谨慎

发生突发问题的时候，上至高级领导、客户，下至团队成员往往都是处于神经紧绷的状态，用“风声鹤唳草木皆兵”来形容也不为过。在这种氛围中，项目经理切忌发布未经确定或落实的消息，尤其是反反覆覆变来变去的“结论”。否则，会给干系人留下对于项目团队“不成熟”、“没有经验”、“水平不高不专业” 的看法，同时也对解决问题无益。干系人对于根因的迫切知晓的需求是客观存在的，在多方面的压力下，项目经理与其发布不确定的结果，还不如实事求是汇报分析的进展、已经掌握的大方向以及接下来具体的分析计划（要有时间点）。只有项目经理自己稳住了，才能抓住危机处理的主动权。

2. 风险评估（Risk Assessment）

如果说根因分析是项目危机公关的基点，那么对于风险的评估就是决定事件影响范围的依据。作为项目经理，不仅要知晓发生问题的根因，还需要清楚地了解其波及的范围，而只有知道了影响的范围，才能采取相应的对策。风险评估的结果往往决定了项目、自身企业乃至客户的政策走向，同样的问题在不同的风险定义下会有着截然不同甚至完全相反的对策，因此对于风险的评估也是危机公关的一个重要方面，而这点往往被很多项目经理所忽视。

对于技术开发类的项目，有以下几个要点可循：a) 定义好风险的严重等级

一般来讲，问题的严重程度从轻到重按如下顺序：

尚处于研发阶段时发生 < 小规模试生产（NPI）时发生 < 投产时发生 < 客户端发现 < 客户投入市场后发生

同样的问题，越在项目后段发现，意味着其影响越是严重，项目经理也必须花更多的时间和精力来处理除了技术解决方案之外的沟通、决策等问题。b) 定义清楚波及范围

在项目的执行过程中需要养成记录变更的良好习惯，实体产品的BOM和相关配置都要有记录，可以通过序列号（SN）追溯相关信息，软件也要有版本号（ver）以及对应的发布说明（Release Note）。这样一旦出了问题就可以清楚地知道哪些批次的产品存在风险，对于已经发货的产品也能通过查询记录来告知客户影响范围以便于进一步的决策。

这里笔者有一个经验——风险的评估不一定非要等到根因分析完全结束之后才开始。危机的出现是突发的，解决问题速度越快越能避免影响范围的扩大，也能减少相应的损失。而根因的分析很多时候是需要相当长的时间才能有一个明确的答案，在此情况下只要有了根因大方向的判断就可以开始风险的评估。

例如，某产品在生产过程中发现有缺陷，经初步分析发现所有缺陷都发生在使用第二供应商的元器件的产品中。那么在确定“第二供应商”这个大方向后就可以进行风险评估了，若已经向客户发货100个该产品，可以通过生产记录和SN排查得出这100个中有多少使用了第二供应商的元器件从而存在失效风险（如40个），这时就可以告知客户建议暂时隔离这批次40个产品等待进一步的措施而其余的60个可以正常使用，并要求产线在根因清楚并有解决方案以前全部切换至第一供应商（围堵机制）。与此同时项目团队进行进一步的根因分析再确定第二供应商的问题到底在哪里，而这40个中又到底有多少个真正有问题。

这样分步来处理其实也是止损的一个过程，问题既然发生了项目经理就有义务去减少额外的损失，在这个例子中定义好波及范围至少能保证第一供应商的产品能正常发货，不至于影响生产，而若等到最终根因完全分析出来在做评估，可能已经停产好几天了。c) 向客户公布风险评估的结果前需得到各方面认可

由于风险评估的结果直接影响客户的处理政策，其中牵扯到各方的利益，在向客户公布具体数字前需和相关干系人进行讨论并达成统一意见。换句话说，最终风险评估的结果不单单是一个技术上的统计，而要结合方方面面的因素，是一个权衡多方意见的结果，最少也需要得到市场、销售、售后的首肯并统一口径。这也是项目经理的一种自我保护的方式。

3. 围堵（缓解）机制（Containment/Mitigation）

在项目管理的危机公关中，围堵机制和纠正措施是解决方案的两个不同的方面，也是“公关”是否成功的最直接呈现。它们的区别在于，纠正措施是最终根除问题的解决方法，而围堵机制是为了防止影响范围扩大而采取的行动。

例如在汽车断轴事件中，召回市面上所有受影响的汽车——这是围堵机制，而在新的产品中采用新的结构或材料进行改进来消除断轴的隐患——这是纠正措施。

被很多项目经理所忽略的是，围堵机制和纠正措施有着同等的重要性，问题越晚被发现围堵机制的重要性越高，尤其在客户端发现的问题往往需要投入绝大多数的资源来制定围堵机制。而和纠正措施不同的是，围堵机制通常会受到多方面的限制，因为产品一旦出货后主动权便不在自己的手中。在限制条件下想办法满足客户的需求并防止问题扩散，这相当考验项目团队的综合能力。

笔者曾经接手过一个项目研发一款产品，在该产品正式投产并广泛投放网络后发现了一个缺陷，此缺陷有一定的风险会导致网络中断。经过根因分析发现是由于产品中某一元器件短路造成，纠正措施不难，在以后产品中采用绝缘材料并改进电路板焊接工艺即可完全规避短路的风险。但在和客户的讨论中主要的关注点却在于如何制定围堵措施——即已经投放网络的产品怎么处理。客户的特殊要求是第一不接受退换货，即无法返修，第二必须有措施保证即便发生问题网络仍旧要保持最低限度运行不能中断，第三，任何对于该产品的措施（操作）必须是线上进行，即不能断网。客户的意图其实很明显——不想惊动他的客户，要保证网络正常运行，不想让此产品的缺陷演变成断网事故并暴露出来。最后，项目组花了很多的精力才制定了一个可行的围堵机制，那些有问题的产品先靠此围堵机制保证低效率运行，等网络定期维护的时候再进行撤换。

从这个例子笔者得到了两条宝贵的经验：

1.围堵机制往往比纠正措施更复杂更关键，

2.有问题一定要尽早发现。

在制定围堵机制的时候有以下几点经验可供参考：a) 机制的制定不要只关注于己方项目组内部

尤其对于已经量产并发货的产品（包括软件），围堵机制就不单单是一个技术层面的方案，是一个需要结合项目成本、时间以及客户需求的综合考量。说白了，就是技术方案必须在成本和时间上行得通，也必须满足客户的各种限制条件。b) 项目经理需要给予相关干系人简单明确的指示

围堵机制说到底就是止损措施，也就是抢时间抢金钱。项目经理在危机情况下必须把握住主动权，建立威信，敢于承担责任。简单明确、思路清晰的指示是最直接的手段，背后的动机可以回头再探讨，但当下首先要做的不是进行技术上的解释和讨论，而是要采取紧急措施防止危机蔓延、控制影响。c) 尽量避免采取召回措施（recall）

召回在各行各业都是相当严重的事故，不管最后能否解决问题，召回本身的成本很多项目都负担不起，重则还会影响企业的资金链。在和客户的谈判中要有自我保护的意识，也要懂得客户也不想得罪客户的客户的心理，召回是万不得已的最后一步。

4. 纠正措施（Corrective Action）

纠正措施即是规避问题的方案，和围堵机制的不同点在于纠正措施着眼于长期的更正计划，而不是处理当下已经产生的损失。一般来讲优先级和紧急程度没有围堵机制那么高，但严格来说围堵机制只是止损并不解决问题，最终能不能摆平危机还是要看纠正措施，也是“危机公关”的最后一个步骤。

具体如何计划和实施纠正措施笔者这里不详细叙述了，每个行业和企业都有自己的文化和套路，项目中具体越到的问题也千差万别。这里还是站在项目经理的角度总结一下几条经验：a) 要学会思路转换

解决问题并不是说只有消除根因这一条路可走，有时候控制诱因，不让根因发展成表象的问题也是一个可选的方法。

这里笔者也举一个案例，有一款产品有电磁辐射的要求，在做相关测试的时候发现有一些频率超过标准，需要解决方案。这时有两条路和选，第一是排查产品所有的电路，找出辐射源，重新设计产品，报废现有库存，停止生产直到用新的设计替换；第二条路是设计屏蔽罩，虽然辐射源还在，但可以屏蔽到产品内部不至于泄漏，这样做不用重新设计，不影响生产，屏蔽罩设计好后加在现有产品内即可。显而易见笔者团队最后选了第二种解决方案。

项目都是在有限的时间，有限的资源下进行，项目的目的是交付满足客户需求的产品，而非设计一款十全十美毫无瑕疵的艺术品。b) 纠正措施实施的同时要管控好变更

变更在PMP中是一个重要知识点，在危机公关中也不可忽视。纠正措施的进行必然会带来产品的变更，无论是硬件还是软件，都要做好记录，尤其注意区分好批次。对于生产中的产品，还要注意定义切换时间点（cut-off time）。c) 要站在项目的角度去解决问题而非纯技术角度

技术的方案当然是解决问题的首选，但同时也不要忘了存在其他的途径。技术上难以解决或许在商务上并不是大问题，商务上的让步或战略的调整都可以是“解决”问题的方法。多和相关干系人探讨，多去了解客户的心理，对于项目经理解决问题都会有所启发和帮助。

以上就是项目管理中“危机公关”的4个方面。除此以外，项目经理在同相关干系人，尤其是和客户的沟通中要注意措辞以及对待整个危机的态度。出了问题要实事求是，不能一概否定己方的错误逃避责任，也不能学日本东电那样两手一摊表示无能为力任由事态发展。当然日本企业的“躬”匠精神还是要借鉴的，而项目经理就是那个有义务出来鞠躬道歉安抚人心并安排后事的负责人，要敢于承认错误承担责任，这样才能凝结团队把事情摆平了。成功的“危机公关”也会是项目经理展现自己能力的舞台。最后笔者用一个比喻来作为此篇的结语。

项目就像是行驶在大海中的轮船，项目经理就是船长，项目团队成员是船上的水手而客户则是船上的游客。这艘船在途中发现漏水了产生了危机。通过调查发现船底破了个洞导致漏水——这是根因分析；船长和水手们根据经验和理论计算判断漏水只波及了某几个船舱并不会导致整艘船沉没——这是风险评估；船长下令隔离漏水的船舱，安抚游客并继续航行——这是围堵机制；安全回来后对船身进行维修并加固——这是纠正措施。

也祝大家在各自项目经理的岗位上都能够扬帆远航！