工作中，我们都有概率会碰到烂项目，有可能是别人甩锅，故意坑你；也有可能是项目确实失控了，需要外部援助，紧急救火。
但不管出于怎样的原因，接手这种项目，一定要慎之又慎。
一、无与伦比的“烂”项目
这个项目，我愿称之为“无与伦比的烂”。
我说一下当时接手该项目时的场景，大家感受一下就知道了：
有一天，我领导喊我到办公室，开门见山地告诉我，后面要交给我一个项目，这个项目，他跟事业部的负责人已经聊过一次了，只知道个大概情况，各种资料文档统统没有。
然后呢，我领导跟我又沟通了大概半个多小时，所有的信息，总结一下的话，大概有这么几条：
1. 这个项目，我们属于丙方，然后需要以乙方的身份，去甲方那边驻场开发；
2. 驻场地址xxx，驻场人员目前有ABC，由于公司业务调整，后续我需要带着DEF过去和之前的人交接；（第一次沟通的时候，DEF是谁都还没确定…）
3. 按照事业部负责人的说辞：“这个项目的功能已经开发得差不多了，派个PM过去盯着，收收尾就行了。”（功能都有什么，压根都不知道，开发得差不多了，咱也不知道差多少……）
4. 我们跟乙方签订了一份合同，但乙方跟甲方还未签订，后续我们跟乙方的合同，有可能会重签。意思就是，前期合同签订得有些粗略，不能作为交付验收的依据…
按照事业部负责人的说法，目前签订的这份合同，如果哪天跟乙方闹掰的话，打官司的时候会有用。（一个项目，已经开发了两三个月，合同还没敲定，你们敢信？）
好了，项目的所有信息，基本上就是以上4条了，项目情况看起来比较模糊，其实一点也不清楚。
总结一下，这个项目在我接手的时候，大概有这么几方面的特征：
1. 没有任何资料；
2. 项目进度不清楚；
3. 何时交付不清楚；
4. 交付标准不清楚；
5. 甚至连资源（主要是人力资源）都不清楚。
在此，我想问一下大家，有没有人遇到过比我这还烂的项目…
接手这个项目，真的就像是开盲盒一样，啥啥都不知道，然后“背锅”与“救火”，真的是就在一念之间啊，一念天堂，一念地狱。
遇到这种情况，该怎样避免背锅呢？
项目管理有专业的方法论，正所谓理论指导实践，以下这张图，在整个项目过程中，真的给了我很大的帮助。
然后呢，我从实践的角度，做了几方面的事情，目前来看，基本上能和“背锅”两个字说拜拜了，而且接手了差不多一个月，领导也准备给我这个月的绩效打个A。
好了，今天就把这些“防背锅”小妙招，总结一下，分享给大家。
二、项目正式接手前
项目先别着急接手，正式接手之前，先把这几件事情给搞清楚、说明白了，然后再接手。
而且，也不要害怕别人会说你不服从安排什么的，咱又不是不接，接之前，有一些疑问提出来，想确认一下，这个总没毛病吧。
1. 定性
让我接手这个项目，没有问题，但得先把我接手的这个性质，咱们讲清楚、说明白。
这个时候，就得拉着PM领导、事业部领导以及技术部领导，来一个三方会谈了。（具体拉上哪些人，大家可以根据自己公司的情况决定，反正最好是拉上能够互相制约的几个人，或者是有话语权的第三方公证人）
项目本身就已经这么烂了，让我接手，是来解决问题的，不是背锅的。
而且大概估算一下，目前项目进展已经几个月了，加上前期的商务成本以及驻场的开发成本，都已经快跟合同额持平了，这个“成本管理”肯定是管不了，就算是以后项目烂尾，或者是赔钱，这个肯定不能算到我头上。
2. 定权责
正所谓，将在外，君命有所不受！
让我接手这个项目，那么驻场的这些人员，肯定都得听从我的安排。
但只有口头授权，往往是不够的。最直接有效的办法，就是把这些人的考核权，牢牢把握在自己手里。
试想，如果连考核的权利都没有，奖钱罚钱都不是你说了算，那谁会听你的。
而且，这个事情，也一定要同步到项目所有成员，我当时是这么干的：
第一步：和相关的领导们开了个会议，会上口头确认了一下这个事情；
第二步：我自己整理了一下会议纪要，把这个结论给记录了一下，往所有项目成员都在的群里面给丢了一下；
第三步：在群里@所有人，明确告知，后续现场人员的考核，由PM全权负责！
这里再多说一点，沟通管理是项目管理里的一项重要内容，其中沟通里占比最多的就是会议沟通，有很多人不喜欢记会议纪要，觉得麻烦或者没必要。但这就大错特错了，会议纪要真的是非常有必要：
-
一方面，会议纪要是大家会议沟通那么长时间，最终达成共识的一个结论性的东西，整理成文字，还可以检验这个结论有没有偏差；
-
另一方面，后期如果出现不认账的情况，那么会议纪要自然就成了强有力的证据；
-
最最重要的是，作为一个整理会议纪要的人，在整理的时候，必然会带着一些主观的色彩，说白了，就是将自己认为合理的内容记上去，或者是按照自己认为合理的方式记上去。当然，跟大家的结论不能够有太多的偏差，不然肯定还得修改。
3. 找队友
正所谓，天下没有永远的敌人，也没有永远的朋友，只有永远的利益。
可以从三个不同的视角来确定，不同场景下，队友都是谁：
-
从公司内部的视角来看：我们PM是一个资源池，服务于不同事业部的不同项目，所以我跟我领导肯定是队友；事业部的人属于对立面，我们之间肯定是要划清责任的；
-
从整个项目的视角来看：那么我们公司的人肯定就是队友了，签合同的乙方以及甲方就是对立面；
-
从项目交付的视角来看：和我们签订合同的乙方也有可能是队友，因为有很多时候，甲方会提出很多无理的或者是额外的需求，这个时候乙方也是想尽快交付项目，拿到钱的，所以乙方也会想办法推掉这些乱七八糟的事。
分清敌友，能够在不同场景下让各个角色之间相互制约，更好地推动项目进展。
三、项目正式接手后
项目正式接手后，才是真正的考验。
很多人面对一个项目，不知道该怎么入手，就跟我们做产品设计一样，初级的做图仔仔，很容易一头就扎到细节里面，这样的话，接下来的工作会反反复复，无穷无尽。
所以说，打蛇打七寸，项目的七寸主要在以下几个方面，把这几个方面给管理好了，那这个项目就成功一大半了。
1. 范围边界管理
我们要干哪些事情，以什么为验收标准，这个是项目开始之前，就必须要搞清楚的事情。
也不知道这个项目是咋搞的，都已经几个月了，连验收标准都不知道，现场甲方爸爸让干啥就干啥。
而且这个问题，一定不能含糊，对方如果和稀泥，那就一定要有打破砂锅问到底的精神。
就比如，我向乙方这个负责人发出的夺命5连问，我感觉都已经给他问的快怀疑人生了：
2. 干系人管理
想要顺利地推动项目进展，一定要知道各个角色都有哪些权责。
举个简单的例子：一款考勤产品，肯定是公司的老板买单，你如果一直满足员工的需求，比如搞了个方圆100公里都能够打卡的功能，那这个项目肯定会烂尾。
拿我接手的这个“烂”项目举例，最起码能够列举出这么几类干系人：
（1）公司内部干系人
决策者：事业部领导、PM领导、技术部领导。
也就是说如果后期项目烂尾了，或者是赔钱不想干了，有这三个领导拍板就行了。
当然，日常汇报，不管是有什么进展，或者有什么困难，比如资源协调什么的，干系人也是这三位。
执行者：驻场的开发，这些就不一一介绍了，全是砖，哪里需要哪里搬的那种。
（2）公司外部干系人
乙方对接人：和我们签合同的乙方的对接人，反正乙方的其他人我也从来没见过，跟乙方沟通，或者是需要乙方跟甲方出面沟通的话，找这一个就行；
甲方对接人：现场直接对接的甲方人员，说白了，就是现场找了俩人，盯着我们干活的，有啥小事，找这俩人就行，但大事，比如项目验收什么的，这俩人肯定没这个权利；
甲方决策者：项目想要验收，还得把这个人搞定。
但现实往往是，这种决策者总会提一些乱七八糟的需求，比如我在这个烂项目中遇到的，甲方决策者提的：“产品界面能不能做得简约一点，但界面展示的内容能不能丰富一点”，我当时一口老血，差点就吐在他脸上了。
最后再多说一点，毕竟我是中途接手的这个烂项目，就简单列了一下这些干系人，如果是一个新项目，或者大家想做一个专业点的干系人管理，可以参考以下这个表格：
3. 问题与风险管理
之前这个项目是一个开发人员负责的，完全没有问题与风险意识。
我还和我们PM领导讨论了一下，开发人员的思维应该是这样的：
“客户提出问题，我得想办法解决啊。如果把问题反馈给领导，领导肯定会觉得我水平不行，前期自己先想想办法，后期如果实在兜不住了，到时候再说吧……”
但实际情况很有可能是问题与风险越积越多，项目最终就失控了。
有问题不可怕，可怕的是，领导们连有问题都不知道，还以为项目都进展得很顺利呢。就比如事业部领导刚开始跟我说的：项目都快收尾了，大概率就是听这个开发负责人汇报的片面之词。
有问题及时反馈，领导们及时了解项目现状，也会想方设法帮忙解决问题的，因为领导们也是需要向老板汇报情况的，也是希望项目早点结束，拿到款项的。
再来普及两个概念，有谁知道，“风险”跟“问题”都是什么意思么？
我来直接说答案吧：
风险：是指还未发生的，但我们可以预测到的，对应的是预案，需要避免风险的发生。
就比如这个项目的交付标准不明确，等到后期验收的时候，肯定会扯不清，这就是风险，而预案肯定就是前期想方设法跟乙方以及甲方明确交付标准。
问题：是指已经发生的，对应的是解决方案。
在这个项目当中，我遇到了一个特别“搞笑”的问题，当时笑得我都差点哭了。
我接手的时候不是说项目的功能都已经快做完了么，但实际了解了一下，他喵的，里面的核心功能还存在技术难点，也就是OCR这部分内容，现场的开发人员搞不了。
其他的增删改查的功能，做得再完美，有个毛用啊。核心功能不能用，这个项目交付个毛线。
于是，我紧急跟公司的技术领导沟通了一下，找了其他的技术资源，赶紧支撑了一波。
4. 进度管理
进度跟第一项范围边界是息息相关的，搞清楚了范围边界，才能谈进度。
对于进度管理，我是分了两个层面，一个是项目的整体进度，另一项是每周现场每位人员的进度，从宏观到微观，也就是这两张表。
第一张表：可以看到整个项目的进展情况。
第二张表：可以看到每周各个任务，以及每个人员的工作情况。
两张表结合，即可实现对于项目的管控（有兴趣的同学，可以查看这篇文章，已经讲得很清楚了）。
5. 沟通管理
及时汇报，及时汇报，及时汇报，重要的事情说三遍！
汇报工作这件小事，我敢打赌，80%的PM，甚至是80%的职场人，可能都不会。
沟通管理的意义，在前面“问题与风险管理”当中，已经说过了，这里重点说一下，我在这个项目中，是怎样做好沟通管理的。
因为该项目的干系人稍微有点复杂，于是我一口气建了5个群。
（1）项目群：里面包含我们公司项目的所有成员，用于同步项目信息，以及日常的沟通交流。
（2）管理群：只有领导的群，包括前面说的，事业部领导、PM领导、以及技术部领导，有些话不方便对所有人说，这个群也是很有必要的。
（3）只有项目成员的群：同样，有些话，也不方便对领导说，所以建一个只有项目成员所在的群，说一些悄悄话，也是挺有必要的。而且这么整的话，也能让现场干活的人感觉到，你们都是一条贼船上的。
（4）所有项目成员以及乙方的群：乙方那个对接人，老是微信单独给我发信息，还经常下班给我打微信电话。然后呢，我先是正常沟通，让他在群里发信息，这样直接同步所有人，省得我再次传达了。
后来发现，并没有什么卵用，还是各种单独给我发信息，于是乎，他单独给我发，我就在群里给他回。
建这个群的目的是如果乙方如果提出什么奇形怪状的要求，也能让我们领导知道，共同想办法对付他。
（5）有所有项目成员以及甲方的群：现场也是需要同步信息的，比如我们制定一个计划，或者确认的需求，反正就是各种结论性的东西，都往群里丢一下，省得后期不认账。
6. 要想马儿跑，就得给马儿喂草
项目进展过程中，避免不了各种突发情况，比如甲方爸爸提了一些脑残需求，导致反复更改，或者是为了赶进度免不了加班的情况。
除了权利层面的约束之外，想让大家好好干活，小恩小惠自然也是少不了的。
我从两个不同的层面，给马儿们整来了草，其中第一层面，还用了阳谋！
层面一：当然是向公司申请费用了。
把一个烂项目丢给我，我申请顿饭钱，一点都不过分吧。
其实我刚开始想的是，等项目有一定成绩了，再申请个“庆功宴”，后来想想，项目后面咋样还不好说呢，先带大家吃顿好的再说。
而且我申请的方式，让领导无法拒绝！
还记得我们建的第一个群，项目群么，我当时在群里是这样申请的：
这么一段话，往群里一发，如果领导们不批这顿饭钱的话，隐藏的后果有三个：
-
后果1：我都拉着甲方一起加班了，如果不请他们吃顿饭，后面甲方不配合了，可不能赖我啊；
-
后果2：现场的小伙伴们最近也都得加班，如果不请他们吃顿饭，后面这群人不配合加班了，这也不能赖我啊；
-
后果3：我是为现场的小伙伴们申请福利了，领导们不批，那是领导们的问题了，可不能说跟着我累死累活，连一点好处都没有啊。
妥妥的阳谋，领导们不批都不行，哈哈哈！
层面二：展现自己的心意。
中午跟大家伙一起吃饭，时不时给大家整杯蜜雪冰城喝一喝，别看只是一杯几块钱的饮料，这可是我自掏腰包请大家喝的。
而且，这只是一杯饮料吗？这可是我们彼此之间，深厚的革命友谊啊。
四、结语
通过以上这些手段，反正项目现在正在逐步步入正轨，作为管理者，我把工作理顺，安排完之后，就在客户现场天天打酱油就行了，但所有人都说我工作干得不错。
最后再说一点，我们之前就总结过，作为一位PM，工作的时间长了，不可能一直是做图仔仔的，职业生涯的发展，有两个方向：
方向一：成为一名产品专家，和业务强绑定，这种方向的性质就是专一型人才，后期如果想换工作的话，只能在某个特定的业务领域内换，可选择性较小。
方向二：成为一名管理专家，这种方向的性质就是通用型人才，后期如果想换工作，选择空间就比较大，而我走的就是这个方向。
本文来自微信公众号：晓庄同学产品笔记（ID：PM-xiaozhuang），作者：晓庄