跳转至

01 角色转变:新手项目管理的三大误区

你好,我是雷蓓蓓,今天是专栏的第1讲,主题是新手项目经理的角色转换。我会结合自己的经历,跟你聊一聊在这条赛道切换的路上,容易进入的三个误区。

在成为一名专业的项目经理之前,我曾做过四年的“程序媛”。在那时的我看来,程序员是个很有意思的职业,现在回想起来,一个人敲代码的日子依然觉得有很多乐趣。我喜欢用代码尝试各种效果,折腾新的技术和语言,从图书馆背回来厚厚的《设计模式》,一边学一边在我的项目上应用实践。

那时的我,不怎么需要跟人交流,一天到晚对着屏幕,只要跟我的代码在一起,就觉得自己可以上天入地,玩得不亦乐乎,真当是“代码在我手,天地任我游”!

尽管当一个很牛的程序员是一件很酷的事情,但是我却很早就意识到,做技术大概不是我一生的饭碗和追求。当我开始成为这个岗位上的熟练工之后,我发现自己开始有了更多的渴望。

直到有一天,摆在我面前的路出现了新的转折。那时,组织中成立了新的项目管理部,于是我通过内部转岗,顺利地成为了第一名全职的项目经理。从此,项目管理的世界向我敞开,带领我走上了一条完全不同的人生轨道。

美国电影中经常有句话说:Great power means great responsibility(能力越强,责任就越大)。项目管理这个岗位,让我从管好自己的事,到开始操心别人的事,责任一下子扩展开来。这种责任范围的扩大,极大地锻炼了我的全局分析能力、统筹规划能力和沟通协调能力。

但由于我并非天生就擅长跟人打交道,所以刚开始时,我丝毫体会不到什么power,反倒经常感觉有劲儿使不出来,被新的责任压得喘不过气。不过也正是这段经历,让我对想要半路出家转行项目经理的同学,有了更多的同理和体谅。

那么今天这节课,我就结合我的经历,把这个转换过程中常见的问题,归纳为以下三大误区:

误区一:凡事恨不得事必躬亲

“跟TA说了几次,到现在还没做好,好不容易做完了,又总是出问题,早知道这么费劲,还不如我替TA做来得快。”

当我做程序员时,我的工作是高度可控的,我可以把每天的工作安排得井井有条。但在做项目管理之后,我发现自己的产出全部依赖别人的工作,于是我会经常性地陷入一种抓狂的状态。有时候着急起来,甚至会忍不住冲上去,替别人做好人家本该做好的事情。但是,后来我慢慢地意识到,对于团队长期的发展而言,这种行为的效率是最低的。可对当时的我来说,想办法影响他人去把事情做好,简直难于上青天

那么,如何影响他人去做好一件事呢?在不断地反思之后,我总结出了成功施加影响的三个层次,分别是让人知道要做(Awareness)、有动力做(Desire)和有能力做(Ability)

我曾经跟一位产品总监合作,他交待工作非常言简意赅,所以团队只知道最终输出的指令和结论,但完全不清楚背景,更不用说明白他的思考过程是什么,以及为什么要这样做了。他的下属有一次跟我说,“老大昨天晚上突然给我打电话,让我马上把就要上线的活动停掉,不要再做了”。他非常困惑,因为团队已经投入了一个月的精力,马上就要见到成果了,但没等他追问为什么,老大就直接把电话挂了。

这样的团队,听上去应该执行力不错,老大的指令都会被立马执行,可事实却并非如此。我发现他们完全谈不上有做事的动力,很多时候都只是照章办事,出了问题也不敢去问,往往导致执行效果与预期相差甚远。

对照刚刚我们所讲的三个层次,这应该只是第一个层次。单方面的工作交待和告知,停留在浅层次的信息传达上,知道要做(Awareness),但并不足以让人产生动力(Desire),去促成有效的行动。

事后我了解到,这位总监之所以着急叫停,是为了规避短期的政策风险。在我和他沟通之后,他主动找来这位下属,讲明了自己的意图。随后,他们一起找到了一种合理的策略,经过调整这个活动还是如期上线了。

这个例子告诉我,在把工作授权给别人时,对于动力(Desire)的关注尤为重要。讲清楚为什么要做,为什么要现在做,获取理解及认同,激发团队的动力,是项目经理成功授权工作的关键。

当然,在动力(Desire)的基础上,你还要确保你所选择的人,有相应的能力(Ability)来做到这件事情。如果现阶段的团队都没有对应的能力,该怎么办呢?项目成功关键路径上的核心能力缺失,是你作为项目管理人员,要当作最高优先级的风险管理的事项。

从外部引入相应的人才显然是最直接有效的方式。不过除此之外,你还可以去积极争取短期借调、内部转岗等。从长期来看,你还需要有意识地发现和投资那些团队中最有潜力的人,给他们安排相应的工作辅导,开展有针对性的培训等,帮助项目组成员发展相应能力,让事情真正落地。

以上,就是授权工作时,成功施加影响的三个层次,从让人知道要做(Awareness)、到有动力做(Desire),再到有能力做(Ability)

误区二:追在别人屁股后面做监工

“好,我不亲历亲为,我把活全都分出去,但我总要督促大家把事情做好吧!我跑去问A,做好没有,A反馈说这事得找B和C,于是我又跑去问B和C……一天下来,我把各处都跑遍了,事情还是没有个进展,反倒讨了一身没趣。我该怎么办?”

在我做项目管理的第一年,经常会有种赶鸭子上架的无奈。通常情况下,我会在心里设定一个目标,然后费尽心力地把大家往一处赶。但往往我赶得越是卖力,“鸭子们”就越是跑得到处都是。

其实,项目经理最该做的,并不是每天监督逐个人、逐条事项,而是要明确目标,建立机制,并让这个机制运转起来,最终在项目组形成一种良性的秩序。

比如,项目经理要带大家一起开启动会,清晰愿景目标,定义阶段里程碑和完成标准,接着制定分段执行的计划,把事情的所有环节从头到尾捋顺了;项目经理要建立上下游协同的流程规则,明确各个角色在整个过程中的职责,获得大家的认同和共识;项目经理还要建立站会、周会等制度和模版,让进展和风险通过这些良好设计的信息渠道汇聚,借助规则和工具来达到监控的目的。

我会在接下来的内容中,把我的经验系统化、分步骤地传递给你。这里你需要记住的是,项目管理并非要让你成为监工,而是要始终依靠流程和规则来约束大家的行为。当成熟的秩序在团队中形成之后,从日常琐事中解放出来的项目经理,就可以集中精力到愿景驱动、激励团队等更高层面的工作,真正做到变“赶”为“引”。

误区三:拿着锤子,看哪里都是钉子

“我们应该每天都开个站会沟通下进展,我们应该定期开个复盘会回顾下……对了,我们应该换个工具,电子看板比这个好用多了。”

我曾经见过一位新官上任的项目经理,可能是因为终于得到施展的空间了,一上来就左突右攻,恨不得把十八般武艺全都套上去,结果激起了许多不必要的麻烦。开站会也好,电子看板也罢,本来都是好工具,但是如果引入不当或时机不对,会让团队产生抵触心理,起不到什么好的效果。

看到项目中的问题,哪里都很想修理一下,这种心情我非常能理解。但是,你要知道的是,每个项目的现有执行方式,都有它本身的背景和成因,不管现有方法是否先进,都是更加适应本土环境的。

在这个课程中,我会跟你分享很多新的方法和工具。但我担心的是,越是好学生,越有马上上手实践的冲动:“看到好的东西,我就想马上在自己的实践中尝试一下。”

如果你也是这样,那么我要提醒你,先不要急,你需要与项目中的重要干系人加强沟通,理清前因后果,多想想自己的项目现阶段到底最需要什么,这对项目管理方法的成功推进至关重要。每个项目都有它独特的情境,你可以试着问自己几个问题:

  • 在你的项目组中,时间、成本、质量、范围这几个因素,到底哪个更重要?哪些是允许有一定调整空间的?
  • 各个角色目前的痛点在哪儿?哪些是最先需要解决的?这些问题背后潜在的原因是什么?
  • 团队对于这个痛点的改进是否有真实需要?需求的迫切程度如何?
  • 你的老板或项目发起人对于项目管理及你本人的定位是怎样的?关于这些问题与可能的改进,你是否与其沟通过并达成了一致?
  • 如果你打算引入新方法或工具,更适合用怎样的路径进行,自上而下地全面推广?自下而上一步一步优化?最有可能从哪个问题切入?

这些问题能够帮助你理清思路,从项目和团队当前的真实痛点出发,找到真正解决问题的方法和步骤。

回到刚刚说到的那位新官上任的项目经理,在我和他对照着以上这五个问题分析完之后,他终于明白了问题到底在哪儿。在他的项目中,时间绝对是第一要素,拖延一天交付都是直接损失。在这样的情景下,团队对变更的容忍度很低,最头疼的就是客户的需求变更又很频繁……实际上,变更的背后是对客户需求管理的失控,大家对这个痛点的改进要求非常迫切,项目发起人也很是头疼。

之前他看哪儿都是问题,眉毛胡子一把抓,现在经过梳理之后,他意识到自己应该找准变更这个切入口,让大家看到切实的效果,其他的改进一步一步来。说干就干!他和发起人沟通了自己改善变更的思路和方法,很快得到了认可,而通过这些有效的改进,团队对他的信任也与日俱增了。

总结

最后,我们来小结一下。从专业人士走向项目管理,是从“左手习惯”到“右手习惯”的转变。其中,思维模式和行为习惯的转变,远比学会使用那些工具方法要有挑战得多。从管好自己的事,到管好别人的事,你需要有意识地避免3个误区。

第1个误区是,凡事都要亲力亲为。遇到事情时,你不要自己直接去做,而是要想办法驱动他人去做好事情。在授权工作时,有三个层次,从让人知道要做,到有动力做,再到有能力做。你需要讲清楚为什么要做,为什么要现在做,获取理解及认同,激发团队的动力,同时为每个任务选择能力匹配的授权对象。

第2个误区是追着别人做监工。做项目管理,不是要你变成监工,而是要你带领团队明确目标,建立机制,并让这个机制运转起来,要始终依靠流程和规则来约束大家的行为。

第3个误区是拿着锤子看哪里都是钉子。每个项目的现有执行方式,都有它本身的背景和成因,你要与项目中的重要干系人加强沟通,理解前因后果,从项目和团队当前的真实痛点出发,找到真正解决问题的方法和步骤。

畅所欲言

如果你已经走上了项目管理之路,在开始系统学习之前,你最好整体梳理一下自己所在项目组的背景情况,这将会为你之后的学习和实践找到方向。

现在,请你对照自己的日常行为,结合以上三个误区完成一个自检。了解自己的行为倾向,并结合你的项目情境,回答误区三中的五个问题。

你可以在留言区写下你的回答,我们一起讨论。同时,我也会在后续的课程中,尽可能结合你的项目情境来组织讲解,期望能为你带来最大的帮助。

精选留言(15)
  • 👍(75) 💬(13)

    项目经理和产品经理是同一个职业吗

    2019-11-14

  • 吴建中 👍(42) 💬(5)

    最近一个项目,业务复杂度,项目重要程度都非常高,同时要求使用新技术新平台(相当于团队研发),团队肩负着甲方的进度压力和质量压力,中间几个核心成员离队,同时信息中心又想通过这个项目打插边球,要求团队偷偷摸摸做一些范围外的工作,项目经过两次延期,好在是现在上线了,回想这路走过来... 最大的心里体会是: 1.如果项目经理忙于琐碎的细节,自己成为瓶颈,无法有效管理团队,那么团队必然失控。很多时候项目出了问题,自己一个熬通宵解决,感觉没有一个人帮得上忙。项目组成员都有一种事不关己高高挂起的状态。 2.信息中心要求使用微服务技术来做系统,受限于项目组技术储备和业务压力,第一阶段我坚持使用SpringBoot技术+传统技术实现,而没有使用SpringCloud组件,千方百计确保项目关键模块先上线,让业务部门看到希望,给团队看到希望。这样做的后果是,业务保住了,但是系统立马面临改造,相当于技术上做无用功,好在这些技术工作慢慢都消化在项目推进中。最后的结果是业务和技术都保住了,现在回显起来,自己的决策应该是对的,那时我一个人基本站在了信息中心对立面,甲方项目经理都要绝交了。事后项目上线了,运行稳定,业务部门满意,信息中心才慢慢改变态度,并对我的决定表示理解,说“不管是乙方项目团队还是信息中心都是为业务部门服务,他们满意了,项目就成功了”。 3.在项目管理中,我通过引入日报机制(必须发送日报)、周报(通过钉钉发布,里面包括关键用户、甲方项目经理)、每周四发布代码(开发轮着部署代码)、建立项目组成员工作特点清单(记录他们的工作特点,在进度控制中采取不同策略,执行力强的人不用天天催,执行弱的人半天催一次),每周五过周计划,然后周日晚上整理下周的计划,并当天晚上发布到工作群,每月阶段性汇报,等机制慢慢让项目步入正轨。 4.我总结的是:要做好一件事情:事前规划(计划管理)+把事情做好(质量管理)+执行力(过程管理)+有效的沟通汇报。

    2020-04-18

  • iMARS 👍(40) 💬(3)

    第一点(凡事恨不得事必躬亲)很有感触,应该做到: (What)目标明确:知道要做到什么程度,达成什么效果 (Why)背景/环境清晰,形成核心动力和凝聚力 (How)如何做:赋能团队和个人,找对人 做不到上述几点,会把项目经理陷入到繁琐的日常事务的泥潭。

    2019-10-29

  • 田利超 👍(19) 💬(1)

    转行项目经理需要具备哪些条件?

    2019-10-28

  • Geek_nyr4dj 👍(14) 💬(1)

    始终在第一和第二个误区徘徊,相当的难受呀。

    2019-11-05

  • Geek_d22b74 👍(11) 💬(1)

    1、在我的项目中我觉得质量是更重要的,时间是允许有一定调整空间的,因为在所接触的项目中,除了要驻场开发的,几乎每个项目都会延期,具体原因总是归结于需求改动,需求没有确定完全,都是边开发边更新新的需求,但是其主要原因还是要归结于内部,至于成本,公司的项目都是承接的,不自主研发,成本高也是时间延期,人员工资增加,成本在一定范围内是可以延期的; 2、其角色痛点是开发没规范,没有固定的开发流程,就算前期定好,后期也没落实,其主要原因是公司原来是两、三人的团队,人少,不需要管理,每个人都会自觉有自己的计划,但是突然增加到十多人的开发团队,就不知道怎么管理了; 3、这些痛点是迫切需要改进的,要不然一直这样下去,根本没办法让公司更上一步,人多了,延期成本会更高; 4、目前的定位是项目经理,也与老板沟通过,也开会说过要根据什么样的流程来,但是老板忙于跑市场,在项目扔给我后总是感觉不知怎么如实按着流程来; 5、我认为基于我的情况,应该自上而下地全面推广,首先要从确定开发流程,制定工作计划切入,且要实施起来;

    2019-10-30

  • Fighting 👍(9) 💬(3)

    讲的太好啦,作为项目经理的我看到这些,真是感同身受啊,句句讲到我心里

    2019-10-28

  • 刘圣伟 👍(9) 💬(4)

    我在想,如果建立了职责明确的okr,项目是不是可以自驱呢

    2019-10-28

  • 程序员人生 👍(7) 💬(1)

    变更的背后是对客户需求管理的失控,那么怎么样才能更好地管理需求呢?

    2019-10-28

  • 雅麻桑 👍(5) 💬(1)

    1、我们公司依然处于发展期,要想留住或者吸引更多的客户,个人认为项目质量是关键,只有东西做好了,才有继续合作的可能性;其次是范围,我们公司的客户经常会提出需求变动,让大家都很头疼,做好前期的需求沟通,明确项目范围,也是我公司要考虑的重点问题;相比之下,时间和成本可以有一定的调整空间; 2、目前,公司研发人员的技术水平参差不齐、且缺乏基本的编码规范意识,做出来的东西经常bug很多;另外项目管理流程比较简单,更多的是看项目经理自己的发挥;再一个,需求变更管理不到位,我无论是学PMP还是软考时,给我的感觉就是,无论项目大小,需求变更管理很重要,然而在公司实际工作中,变更都是口头传达,没有经过更多的评审就直接做了,变更管理无从谈起。领导其实都很清楚这些问题,每次开会也都强调大家要重视这些问题,想办法解决掉,然后就没有然后了。。。其实总的看来,还是缺少一个符合公司状况的项目开发规则和流程,这个规则需要领导发起,相关人员共同商讨制定,而且更重要的是,如何在人手有限的情况下,把这套规则真正的实施下去! 3、规则的完善,是我公司重点需要考虑的问题,而规则又细分为很多部分,比如需求设计规则、代码开发规则、测试规则、项目管理规则等等,我作为一个程序员出身的项目经理,比较关注研发人员的的代码开发状况,目前问题其实不少,代码设计冗余、不合理,代码注释缺失严重,没人愿意接手其他人的代码,理由基本都是看不懂,接手后改起来也很痛苦,这样的状况开发出来的系统,问题能少才怪了。然而这些问题并非技术难题,还是缺少编码规范,以及有效的审查和监督。因此新的一年里,会和领导反映,一定要解决这个最基本的问题。

    2020-01-30

  • 褚晓娜 👍(4) 💬(1)

    第一个误区相对来说比较容易克服,虽然会在项目过程当中出现手痒的情况,我一般情况都是协助程序员寻找网上的解决办法,让他们自己去尝试完成,并跟踪完成的结果。对于第二个误区通过今年一年的项目管理经历来看对于项目的整体把握能力还是弱了好多。项目开工前之前的计划并不能很顺利的完成,中间总是会出现各种问题,有时候甚至会对伙伴的积极性产生各种各样的怀疑,有段时间甚至觉得大家的积极性非常的低,总是感觉控制不住,那段时间情绪非常的失控,大家都不敢跟我说话,虽然我有时会有意识的控制自己的情绪,但是效果并不是很好。其实出现这种情况我有时候甚至很自责,我感觉是沟通协调的问题,但是极力的去做,可能是方法不对,效果不是太好。我认位程序员在沟通上存在这很大的问题,比如我们在沟通项目需求的时候,技术人员总感觉没有必要,总是说有项目需求就好,开发过程中肯定会有问题,进而对需求的并没有非常深入的理解,导致项目经理并不能对项目有一个很准备的把控,在开发过程中总会出现考虑不到的问题。我希望能通过本次课程的学习增强自己项目管理的能力,同时也能够有效的提高与技术人员的沟通能力。

    2020-02-03

  • 张有俊 👍(4) 💬(1)

    保目标、助决策、提效能、促协作。落实到每日的工作中要怎么做?产出怎么衡量呢?感觉是找不到具体的事情,才更容易走进这三大误区。

    2019-10-30

  • 辰昊楠-(Yami的土豆宽粉) 👍(3) 💬(1)

    蓓蓓的儿化音好萌哦:)

    2019-10-29

  • eric-xin 👍(3) 💬(1)

    怎么在大家都没有项目管理意识的团队中,快速建立起一套敏捷的项目管理工作模式?激发大家的好奇心,让团队工作有序升级?在研发团队大多数情况不是大家不配合项目管理,而是不会配合。

    2019-10-29

  • 富润家 👍(3) 💬(1)

    你讲得很接地气,我听了很多管理学理论,但是功夫没到那个层次,总感觉有些空洞,就喜欢这种实战分析的课,实际指导性和可操作性很强! 谢谢你的分享!

    2019-10-29