接手“烂”项目,怎样避免背锅!

     分类 [产品经理]
2024/5/9 10:14:04 浏览量  1441 喜欢  39
导读:管出于怎样的原因,接手这种项目,一定要慎之又慎,因为“背锅”还是“救火”,是功还是过,真的是一念天堂,一念地狱!

接手“烂”项目,怎样避免背锅!

1
无与伦比的“烂”项目

这个项目,我愿称之为“无与伦比的烂”。

我说一下当时接手该项目时的场景,大家感受一下就知道了:

有一天,我领导喊我到办公室,开门见山地告诉我,后面要交给我一个项目,这个项目,他跟事业部的负责人已经聊过一次了,只知道个大概情况,各种资料文档统统没有。

然后呢,我领导跟我又沟通了大概半个多小时,所有的信息,总结一下的话,大概有这么几条:

1. 这个项目,我们属于丙方,然后需要以乙方的身份,去甲方那边驻场开发;(真的是孙子。。。)

2. 驻场地址xxx,驻场人员目前有ABC,由于公司业务调整,后续我需要带着DEF过去和之前的人交接;(第一次沟通的时候,DEF是谁都还没确定。。。)

3. 按照事业部负责人的说辞:“这个项目的功能已经开发的差不多了,派个PM过去盯着,收收尾就行了。”(功能都有什么,压根都不知道,开发的差不多了,咱也不知道差多少。。。)

4. 我们跟乙方签订的有一份合同,但乙方跟甲方还未签订,后续我们跟乙方的合同,有可能会重签。

意思就是,前期合同签订的有些粗略,不能作为交付验收的依据。。。

按照事业部负责人的说法,目前签订的这份合同,如果哪天跟乙方闹掰的话,打官司的时候会有用。。。

(一个项目,已经开发了两三个月了,合同还没敲定,你们敢信?)

好了,项目的所有信息,基本上就是以上4条了,项目情况看起来比较模糊,其实一点也不清楚。。。

总结一下,这个项目我接手的时候,大概有这么几方面的特征:

1. 没有任何资料;

2. 项目进度不清楚;

3. 何时交付不清楚;

4. 交付标准不清楚;

5. 甚至连资源(主要是人力资源)都不清楚。。。

在此,我想问一下大家,有没有人遇到过,比我这还烂的项目了。。。

接手这个项目,真的就像是开盲盒一样,啥啥都不知道,然后“背锅”与“救火”,真的是就在一念之间啊,一念天堂,一念地狱。。。

遇到这种情况,该怎样避免背锅呢?

项目管理有专业的方法论,正所谓理论指导实践,以下这张图,在整个项目过程中,真的给了我很大的帮助。

接手“烂”项目,怎样避免背锅!

 

然后呢,我从实践的角度,做了几方面的事情,目前来看,基本上能和“背锅”两个字说拜拜了,而且接手了差不多一个月,领导也准备给我这个月的绩效打个A。

好了,今天就把这些“防背锅”小妙招,总结一下,分享给大家,感觉有用的话,赶紧来一波点赞、转发、收藏的一键三连吧~

2
项目正式接手前

项目先别着急接手,正式接手之前,先把这几件事情给搞清楚了,说明白了,再接手也不迟。

且也不要害怕别人会说,你不服从安排什么的,咱又不是不接,接之前,有一些疑问提出来,想确认一下,这个总没毛病吧~

1. 定性

让我接手这个项目,木得问题,但得先把我接手的这个性质,咱们讲清楚,说明白。

这个时候,就得拉着PM领导、事业部领导以及技术部领导,来一个三方会谈了。

(具体拉上哪些人,大家可以根据自己公司的情况决定,反正最好是拉上能够互相制约的几个人,或者是有话语权的第三方公证人)

项目本身就已经这么烂了,让我接手,是来解决问题的,不是背锅的。

而且大概估算了一下,目前项目进展已经几个月了,加上前期的商务成本以及驻场的开发成本,都已经快跟合同额持平了,这个“成本管理”肯定是管不了了,就算是以后项目烂尾了,或者是赔钱了,这个肯定不能算到我头上。

2. 定权责

正所谓,将在外,君命有所不受!

让我接手这个项目,那么驻场的这些个人员,肯定都得听从我的安排。

但只有口头授权,往往是不够的,最直接有效的办法,就是把这些人的考核权,牢牢把握在自己手里。

试想,如果连考核的权利都没有,奖钱罚钱,都不是你说了算,那谁会听你的。

而且,这个事情,也一定要同步到项目所有成员,我当时是这么干的:

第一步:和相关的领导们开了个会议,会上口头确认了一下这个事情;

第二步:我自己整理了一下会议纪要,把这个结论给记录了一下,往所有项目成员都在的群里面给丢了一下;

第三布:群里面@所有人,明确告知,后续现场人员的考核,由PM全权负责!

接手“烂”项目,怎样避免背锅!

这里再多说一点,沟通管理是项目管理里面的一项重要内容,其中沟通里面占比最多的就是会议沟通,有很多人不喜欢记会议纪要,觉得麻烦或者没必要。(有这方面想法的小伙伴,评论区可以告诉我一下~)

这就大错特错了,会议纪要真的是非常有必要:

一方面,会议纪要是大家会议沟通那么长时间,最终达成共识的一个结论性的东西,整理成文字,还可以检验这个结论有没有偏差;

另一方面,后期如果出现不认账的情况,那么会议纪要自然就成了强有力的证据;

最最重要的是,作为一个整理会议纪要的人,在整理的时候,必然会带着一些主观的色彩,说白了,就是将自己认为合理的内容记上去,或者是按照自己认为合理的方式记上去,当然,跟大家的结论不能够有太多的偏差,不然肯定还得修改。

3. 找队友

正所谓,天下没有永远的敌人,也没有永远的朋友,只有永远的利益。

可以从三个不同的视角,来确定不同场景下,队友都是谁:

(1)从公司内部的视角来看:我们PM是一个资源池,服务于不同事业部的不同项目,所以我跟我领导肯定是队友,事业部的人,属于对立面,我们之间肯定是要划清责任的;

(2)从整个项目的视角来看:那么我们公司的人,肯定就是队友了,签合同的乙方以及甲方,那就是对立面了;

(3)从项目交付的视角来看:和我们签订合同的乙方,也有可能是队友,因为有很多时候,甲方会提出很多无理的或者是额外的需求,这个时候乙方也是想尽快交付项目,拿到钱的,所以乙方也会想办法推掉这些乱七八糟的。

分清敌友,能够在不同场景下,让各个角色之间相互制约,更好地推动项目进展~

3
项目正式接手后

项目正式接手后,才是真正的考验。

很多人面对一个项目,不知道该怎么入手,就跟我们做产品设计一样,初级的作图仔仔,很容易一头就扎到细节里面,这样的话,接下里的工作会反反复复,无穷无尽。

所以说,打蛇打七寸,项目的七寸主要在于以下几个方面,把这几个方面给管理好了,那这个项目就成功了一大半了。

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:我是为现场的小伙伴们申请福利了,领导们不批,那是领导们的问题了,可不能说跟着我累死累活,连一点好处都没有啊~

妥妥的阳谋,领导们不批都不行,哈哈哈!

层面二:

中午跟大家伙一起吃饭,时不时给大家整杯蜜雪冰城喝一喝,别看只是一杯几块钱的饮料,这可是我自掏腰包请大家喝的。

而且,这只是一杯饮料吗?这可是我们彼此之间,深厚的革命友谊啊。

4
结语

通过以上这些手段,反正项目现在正在逐步步入正轨,作为管理者,我把工作理顺,安排完之后,就在客户现场天天打酱油就行了,但所有人都说我工作干的不错。。。

最后再说一点,我们之前就总结过,作为一位PM,工作的时间长了,不可能一直是作图仔仔的,职业生涯的发展,有两个方向:

方向一:成为一名产品专家,和业务强绑定,这种方向的性质就是专一型人才,后期如果想换工作的话,只能在某个特定的业务领域内换,可选择性较小。

方向二:成为一名管理专家,这种方向的性质就是通用型人才,后期如果想换工作,选择空间就比较大,而我走的就是这个方向。

 

 

标签

微信扫一扫,分享到朋友圈

微信公众号

相关推荐