极客时间已完结课程限时免费阅读

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

01|角色转变:新手项目管理的三大误区-极客时间

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

讲述:雷蓓蓓

时长14:49大小13.57M

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

畅所欲言

如果你已经走上了项目管理之路,在开始系统学习之前,你最好整体梳理一下自己所在项目组的背景情况,这将会为你之后的学习和实践找到方向。
现在,请你对照自己的日常行为,结合以上三个误区完成一个自检。了解自己的行为倾向,并结合你的项目情境,回答误区三中的五个问题。
你可以在留言区写下你的回答,我们一起讨论。同时,我也会在后续的课程中,尽可能结合你的项目情境来组织讲解,期望能为你带来最大的帮助。
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 100

提建议

上一篇
迭代说明|如何学习项目管理这门课?
下一篇
02|十大领域五大过程组(上):你必须了解的项目管理常识
unpreview
 写留言

精选留言(128)

  • 穷查理
    2019-10-29
    从15年毕业后,前两年主要做移动开发,后两年做开发和项目管理工作,公司基本采用瀑布开发模式。针对本节课中的三个误区的自检如下: 公司项目开发按照课题组为单位进行,一个课题组包括Android开发、IOS开发、web端开发以及后台开发。基本上每个人独立负责一个端的开发工作,所以不存在事必躬亲、替别人做事情的情况。在集成开发的时候,就会涉及到三个或更多课题组协同开发,这时就有一个部门总监来协调(我目前即将升任总监)。 根据目前公司的工作场景,我觉得“在影响他人做事情”方面,做的很不好。 首先,课题组长兼任开发、产品以及日常管理工作。 其次,课题组长负责完成需求设计,以及划分好各个工作阶段的时间段(时间段只是为了立项参考),下发到各个端开发负责人开始开发,基本没有启动会,项目背景介绍及愿景分析;即使大领导要求,下面也是流于形式,开发也觉得浪费时间。 最后,开发分别按照自己的理解,独立完成开发。导致在项目验收阶段存在很多的问题,延期严重。 这时课题组为了能早日通过验收,无限制地修改需求,项目组负责人,也只能追在各个开发屁股后面要求修改。最终项目能不通过验收,是在没有闪退的情况下验收人员心情是主要原因之一。 基于以上项目管理背景和我的理解: 1、如果要问在项目中,时间、成本、质量及范围哪个更重要,我只能说质量吧。因为时间可以延期,而且除了近一年多,我带的两个项目在规定期限内完成之外,我接触到的项目基本没有不延期的;成本主要是人力成本和时间成本;而范围可以根据验收部门的提议,无限制修改,所以我觉得也不重要。 2、痛点还不少,项目组需求不明确、愿景不清晰、目标及任务很模糊,有几次我建议把这些工作做仔细,我的直属领导觉得没有必要,而且下面的小伙伴也觉得浪费时间。 3、团队如果能解决痛点问题,肯定是非常迫切的。我亲自带的两个项目,都是严格按照需求研讨、设计研讨、技术选型分析、目标及愿景分析来做,并且团队一起完成目标分解和计划制定,效果很好。而且创造了首个一次性通过验收的记录。 4、我本人的定位走管理路线了,而且公司对管理也不太看重,总觉公司上层有很多想法很好,但是执行下去就变了。使用,目前是自己一边学习一边实践锻炼。 5、目前在我的两个直属课题组,在公司瀑布开发模式下,我引入了站会、周分析会,帮助项目组开发小伙伴梳理工作计划和事情的轻重缓急,在工具方面引入禅道。目前在公司整体环境下,推广很难,而且大领导多是口头支持,很多公司老员工也习惯了他们原有的开发方式。 目前通过书籍、网上的课程学习项目管理,并逐步项目组锻炼。 以上就是简单自检。
    展开
    共 5 条评论
    99
  • 2019-11-14
    项目经理和产品经理是同一个职业吗

    作者回复: 一个正确的做事,一个做正确的事

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

    作者回复: 你讲的很好!我发现评论区大家的讨论,会是专栏很重要的一部分学习延伸,每个人向每个人学习。

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

    作者回复: 你总结的很到位,要把自己的角色转变过来,把团队的力量发挥出来,项目才能顺畅起来!

    共 4 条评论
    32
  • 田利超
    2019-10-28
    转行项目经理需要具备哪些条件?

    作者回复: 事实上并没有太多硬的约束,我身边各种类型的PM都有,意愿是第一位的,其次是持续不断的学习和刻意训练。我团队中就有一位打定主意要做项目管理的同学,不顾家人反对,从呆了六年的国企中跳出来,全脱岗先去学编程,做了3年研发后转到项目经理。

    18
  • crossbell
    2019-10-28
    声音好听呀
    共 3 条评论
    17
  • P0074887_曾凡
    2020-02-20
    其次就是沟通技巧 1.对客户的沟通技巧: 不要讲太多的专业术语,主要讲目标和目前的进度,以及需要得到什么资源协助。 如果涉及到跨部门的协作更要注重的是说话的慎重,知道哪些话该说哪些话要慎重的说。 2.面对上级沟通 主要是沟通项目的目前的进展,还有就是剩余目标。以及项目目前团队进展情况。 3.面对资历老技术强的沟通方式主要是采用沟通和咨询的方式协调,因为他们技术方面是够硬的资历可能比你还老在某个领域绝对是专家级别的,这样可以和他采用协商的方式。你给足对方面子,对方会在工作上全力支持你。 其次就是有技术 有主见的团队成员,应该明确的是项目规章制度,在项目之处就需要明确项目规章奖惩制度。
    展开
    12
  • 亚祥
    2019-11-05
    始终在第一和第二个误区徘徊,相当的难受呀。

    作者回复: 你如何看待这种不舒服? 贝壳中进了一粒沙,就是因为不舒服,所以刺激它不断分泌,才结出美丽的珍珠。 到现在,我还是会有很多难受的事情,今天突然想到,换个角度去看,我也正在酝酿自己新的珍珠呢!

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

    作者回复: 好认真的作业!仔细读完了,我在文中说,你意识到的痛点也好,迫切需要去做的改进也好,要跟你的重要干系人达成共识。 听上去开发规范的确是个问题,但是否是当前已有共识需要迫切改变的呢?如果现阶段有很多需要改进的,从共识的痛点去改进,选择合适的切入口,就会事倍功半。

    9
  • Fighting
    2019-10-28
    讲的太好啦,作为项目经理的我看到这些,真是感同身受啊,句句讲到我心里

    作者回复: 握爪

    共 3 条评论
    9
  • 刘圣伟
    2019-10-28
    我在想,如果建立了职责明确的okr,项目是不是可以自驱呢

    作者回复: 很棒的思路!小团队自驱没问题,大团队需要很多配套的极致、工具和能力建设

    共 4 条评论
    9
  • 漫迷
    2020-07-06
    做了10年程序员,现在又做了4年多项目经理,最大感悟就是,程序员是背锅的,项目经理是甩锅的,最优秀的项目经理,是甩锅专家,一招足以。
    共 1 条评论
    6
  • 程序员人生
    2019-10-28
    变更的背后是对客户需求管理的失控,那么怎么样才能更好地管理需求呢?

    作者回复: 很认真在学习哦!需求管理的问题有收到,后面第九讲会详细介绍。

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

    作者回复: 项目开发规则和流程,倒未一定只能是领导发起,自上而下和自下而上相结合,效果更好

    5
  • Jialeigd
    2019-10-29
    现在也面临研发转项目管理的困惑,不知道哪个方向。感觉项目管理成长空间更大,但是很疑惑目前互联网似乎很好有项目管理岗,大家都能把自己的事情做好,项目管理变得很虚了
    共 4 条评论
    5
  • You Jun
    2019-10-30
    保目标、助决策、提效能、促协作。落实到每日的工作中要怎么做?产出怎么衡量呢?感觉是找不到具体的事情,才更容易走进这三大误区。

    作者回复: 你说的很对!这里有个认定,什么是具体的事情,程序员会认为研发工作是具体的事情,而项目管理不是,但其实不然,需要学习的是,各个阶段项目管理需要去做的具体的事情。 PS:这十二字总结,我还没发表,你是怎么找到的呀?

    4
  • 谭方敏
    2021-05-15
    1)项目管理其实有个隐藏的属性就是可以复制下属的能力,在亲力亲为之前,不然先盘点下这个事情需要什么技能,然后谁具备这个技能,如果有合适的人,那么就是他了,否则才需要自己临时躬身入局,在这之后还得需要更新下自己的招聘计划, 2)如果你把下属看成是农民工,那么你只能算个工头,如果你把下属都看成一个有独立思考的精英,那么你是个精英中的精英。尽量通过契约和约定去约束,而不是强行控制。 3)永远解决最重要的问题和最疼的痛点,往往这里面隐藏巨大的价值。抓大放小。 一直关注项目管理,但是却没法形成一个闭环,不过却不断更新自己的项目管理知识,总觉得某天能用得上。。。。
    展开
    3
  • P0074887_曾凡
    2020-02-20
    技术经理转项目经理的最大的瓶颈就是思维的转变,技术经理往往只会抓技术层面的问题,不会对项目整体进度的把控和客户的沟通方面做更多工作,而项目经理是主要是全局的把控,不同的项目类型侧重点也不同,比如说政治目的强项目,这种项目对时间的要求非常明确,规定什么时间必须上线。但是这种项目的需求目的非常明确,如果采用传统软件开发工程的方法可能时间上是不允许的,可以采用敏捷式开发,项目经理需要在项目的需求目标中抓住需求重点,重点对项目的重要需求做为工作量的重点,对时间和人员的使用必须明确,每个阶段的里程碑和目的都需要非常清楚 ,不重要的优化都可以放在后面。其次就是有种需求连客户都不是很明确的项目,这种需要就是项目经理带理团队认真做好需求分析,并在项目实施和开发过程中每个环节都做好对应的变更明确记录,每天和每周都做好工作纪要,掌控好项目每个阶段的进度
    展开
    3
  • 褚晓娜
    2020-02-03
    第一个误区相对来说比较容易克服,虽然会在项目过程当中出现手痒的情况,我一般情况都是协助程序员寻找网上的解决办法,让他们自己去尝试完成,并跟踪完成的结果。对于第二个误区通过今年一年的项目管理经历来看对于项目的整体把握能力还是弱了好多。项目开工前之前的计划并不能很顺利的完成,中间总是会出现各种问题,有时候甚至会对伙伴的积极性产生各种各样的怀疑,有段时间甚至觉得大家的积极性非常的低,总是感觉控制不住,那段时间情绪非常的失控,大家都不敢跟我说话,虽然我有时会有意识的控制自己的情绪,但是效果并不是很好。其实出现这种情况我有时候甚至很自责,我感觉是沟通协调的问题,但是极力的去做,可能是方法不对,效果不是太好。我认位程序员在沟通上存在这很大的问题,比如我们在沟通项目需求的时候,技术人员总感觉没有必要,总是说有项目需求就好,开发过程中肯定会有问题,进而对需求的并没有非常深入的理解,导致项目经理并不能对项目有一个很准备的把控,在开发过程中总会出现考虑不到的问题。我希望能通过本次课程的学习增强自己项目管理的能力,同时也能够有效的提高与技术人员的沟通能力。
    展开

    作者回复: 其实很多人都会这样,看到问题很容易焦虑,一焦虑就会用力过猛,反而适得其反。管理好自己,永远是第一位,嗯。

    3
  • 辰昊楠-(Yami的土豆...
    2019-10-29
    蓓蓓的儿化音好萌哦:)

    作者回复: 哈哈

    3