20 | 项目管理中的三个技巧
下载APP
关闭
渠道合作
推荐作者
20 | 项目管理中的三个技巧
2017-12-27 朱赟 来自北京
《朱赟的技术管理课》
课程介绍
讲述:丁婵
时长07:56大小3.63M
我在“管理者不用亲力亲为:关键是什么”一文中,介绍了授权和任务分配的重要性。那篇文章的重点有两点:第一我们要有效地把任务分配出去,第二我们要保证分配出去的任务能够被圆满完成。
作为管理者,我们平时在项目管理的过程中,更侧重的是要保证团队成员能够按照你的期望值完成任务。今天的这篇文章里,我会进一步展开讲一些项目管理的技巧。这些技巧一部分来自我个人的思考和实践,另一部分得益于我的老板的悉心指导和启发,真实可行并且有效,希望对你的日常管理工作也有帮助。
第一个技巧,我们在做项目计划的时候,要对多个项目进行细分重组
怎么理解呢?我们从做这件事的目的说起。在给组里多个人分配项目的时候,我们往往需要考虑的因素包括以下的内容。
先评估能力,再分配任务,每个人的能力要和任务的难度匹配。
每个人任务完成所需时间要尽量平等,也就是要达到一种负载平衡。
每个人得到的任务里,挑战有意思的工作和脏活累活的比例要大致相等。
每个人任务里有足够的挑战,能够帮助其成长,又不至于太难而让其望而生畏并产生挫败感。
不同人的任务之间如果有依赖性,在分配任务时要安排合理的顺序,确保不会有人被别的人或事阻塞(Block)。
每个人的任务里都应该有一个主题,就好像故事有一条主线。这样,成员会觉得自己参与了一个比较完整的任务,进而产生成就感,而不是感觉做了一堆杂活。
达到这些目的的手段,我们姑且就称其为“细分重组”。这个过程又包括两个阶段。
第一个阶段。你需要把所有要做的事,细分成一个个的小任务,每个任务的大小、完成需要的时间都大致差不多。如果有比较大的任务块,就尽可能地切分成几个小块。这需要管理者对项目本身的重点和任务细节有很好的把握。
第二个阶段。把这些大小均匀的任务块,按照上面提到的因素,分装到几个虚构的 “箱子” 里,然后分配给团队成员。这就像个打包装箱的过程,尤其需要注意的是,每个箱子一定都有一个主题,也就是说,如果你想给这个箱子起个名字,你一定能找到那个名字,并很好地概括其中的内容。最后,保证每个箱子在内容、重量等各方面都比较均衡。
完成了这个工作之后,后续项目的每一步,作为管理者的你都能做到心中有数。同时还能避免后期执行中一些可能的弊端,例如,有的人工作繁重疲累不堪,有的人则早早完成了自己任务,缺乏挑战。这种任务划分的方式还会让每个人更有成就感和责任感,因为他们完成的是一整个故事。
第二个技巧,工期估算
一般情况下,技术管理者都会对每个任务的完成时间有自己的判断,但最终还是要和接受任务的员工沟通清楚,并尊重对方的意见,确保双方能就任务时间线达成一致。有了承诺,工作的目标性也会更强一些,毕竟,截止日期才是最好的效率工具。
这一点非常重要。如果不是双方达成一致的协议,或者不是双方都认可合理的时间估算,一旦后期出现不能按期完成任务的时刻,就很容易出现一些令人不愉快的交流。
同时需要注意的是,很多工程师在做时间预算的时候,会过于乐观。我见过的大部分工程师都乐观、积极、自信,他们沉浸在代码的世界里,试图把软件做到最好,往往却会忽略时间因素。当核对工期的时候,他们会根据自己的经验给出一个非常乐观的期限。
和普通人一样,工程师们也会高估自己编程能力和对复杂逻辑的处理能力。甚至,有时候工程师给出的工期是自己负责的那部分程序编写完成的时间;然而,一个功能的完成,包含编译、单元测试、提交代码、集成测试、功能测试、性能测试和上线。如果不是特别留意,这些细节往往会泯灭在项目进度的时间表里,无法体现。
即使是一个很有估算经验的工程师,在新项目中也可能会遇到各种各样新的问题,你会惊奇地发现,上一个项目中的方法在新产品中失灵了。另外,开发中遇到的技术瓶颈或难以解决的 Bug,也会耗费程序员大量的精力和时间,这时候我们能做的事情只有等待,给他们时间去披荆斩棘,直到问题解决。
所以,在这个阶段,往往需要技术领导给出参考性的意见和建议;除此之外,你最好留出一些缓冲的时间,因为实际工作中总会有一些不可预见的情况发生。
第三个技巧,也是很重要的一点,实时跟踪,并准备好 B 计划
技术领导者要做好两手准备,比如,团队中有一部分人突然表现失常了怎么办?项目由于其他原因被阻塞了怎么办?
这时候我们需要做好以下两点。
我们在 “细分重组” 中把工作分成了小块,在完成过程中,我们还需要设立各种里程碑。其中,有一些长期的大里程碑,也有一些为期一周到两周的小里程碑。这些里程碑就像你上高速行驶之前给自己定的目标:几点前要到某个服务区,几点前要到某个城市等等。有了这些里程碑,管理者就可以通过它们进行实时跟踪,了解项目的进度,看看项目这辆汽车是不是还正常地行驶在高速路上,是不是抛锚了,是不是没油了,等等。
一旦出现延迟,管理者要和任务的负责人一起分析原因,询问对方能否追上进度,会不会对整个项目的进程有重大影响。如果问题不严重,可以暂时不做调整,继续跟进。如果影响比较大,就需要启动 B 计划了,比如调整执行的人员、提供额外的资源、分析执行的方法、调动其他组支援,甚至你需要重新考虑项目进度。
今天,我和你讨论了平时在项目管理过程中的一些实践技巧,总结一下:管理者首先要对大的项目进行细分重组,“打包装箱”之后再分配下去;其次,在工期估算方面,管理者要和任务的负责人达成一致,并且要注意到,工程师们在进行时间预算的时候都是比较乐观的,最好为项目预留缓冲的时间;最后,要为项目设置大大小小的里程碑,并实时跟进,一旦项目出问题,就要启动 B 计划。
通常情况下,如果这三点做得比较好,我们的 B 计划就不会用上,这也是我们期待的最好结果。
你在项目执行过程中还有那些经验和技巧呢?可以在留言中告诉我,我们一起进步。
感谢您的收听,我们下期再见。
分享给需要的人,Ta购买本课程,你将得18元
生成海报并分享
赞 7
提建议
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
上一篇
19 | 硅谷面试:那些你应该知道的事儿
下一篇
21 | 每个工程师都应该了解的:中美在支付技术和大环境下的差异
精选留言(17)
- nanquanmama2017-12-29分配项目的做法很像是map/reduce
池建强回复: 这个比喻很形象啊,赞
24 - 刘剑2018-01-05我谈下我的项目管理感受: 1.在项目管理中很多时候在前期需求分析阶段就出现问题(伪需求、需求不明确就已经设计出方案),所以即使项目顺利完成效果也不好,而且前期需求不清晰会导致开发中需求变更,频繁的变更会成为项目失败的主因。我见过和亲身经历太多需求问题导致项目失败的案例 所以项目进程中首先需要从这个源头开始严之又慎,从因果关系来说没有好的因不会得好的果,需求分析阶段在项目中真是太重要了。 2.一个磨合很好的团队,由于时间预估不足导致延期可能性较小。这种延期多出现在刚组建的团队阶段,大家彼此陌生,流程不规范,配合不默契,沟通成本也很高。在这种情况下我通常第一次让开发人员自己估计时间,我再在这个时间上加20%的项目缓冲期时间以应对突发事件。由于我们用的MVP模式,所以每次迭代周期短,当第二次迭代期,我会帮助开发人员梳理开发流程中的问题,帮助他们开发流程更顺畅、更高效,比如:需要列出功能开发优先级顺序,对于关联功能或需要联调功能优先完成,独立开发的功能放在后面完成等等技巧可极大提高他们开发效率。再有了第一次开发作为纵向评估标准,第二次开发效率会高很多(同等难度效率提高40%以上)第三次会再梳理。基本三次迭代后团队基本可定型,后续开发在没有外界因素变化的情况下开发进度很稳定。 3.对于需要技术攻关的时候,在项目需求和设计阶段就要让开发人员尽早做技术调研出有核心功能的Demo,到真的开发阶段Demo代码就可以复用到项目开发中,省时又省力。展开21
- 走小調的凡世林2019-08-25一般用什么工具进行项目管理呢
作者回复: 每个公司有自己的工具规范吧,我们目前用 Trello 多一些,也有用 Excel 来管理的。
3 - mikejiang2019-11-14一般一周可以完成的需求,基本估计都是比较准的,加一天缓冲即可;两周的事情,可能就要加30%的缓冲,三周以上的项目,可能性要加40%的缓冲。1
- yoummg2018-12-11需求的按时完成最好两点。 1.技术需求的评审 2.需求迭代时的把控。(即里程碑的设定)共 1 条评论1
- 冰糕不冰2018-07-10需求评审真的太重要!最近一个需求就是产品出的需求不明确,导致开发时不断重新商讨修改需求,致使项目严重延期!这也是自己的不足。1
- Donghe2018-04-28我发现项目时间预估和跟进挺tricky。预估了太乐观,到时候因为无法预测的原因delay了被block了,这时候求助援助吧,心理上显得自己没能力没办法树立组里形象,不求助吧,对项目进展不负责。这个心理特别经常出现在新组员身上。所以您对此有什么看法和见解么?1
- liupan2022-08-14 来自广东我觉得要多补充一些实际案例
- 怀揣梦想的学渣2022-03-20在预留缓冲时间上,有相关的思想指导吗,比如标准的预留30%的时间作为缓冲和应急。
- rOMEo罗密欧2021-07-17请教一下安姐,关于项目计划里程碑等,现在硅谷或者互联网大厂都用什么工具来管理?是用像Microsoft Project那种甘特图工具吗?
- 范2021-02-04管理者不能是简单的任务转述,而应该有拆分打包装箱的能力。
- 何慧成2020-08-24需求不明确是最大的风险,一份伪明确的需求可能会导致后面得计划和投入都打水漂。 另外对于拆细重组是个好方法,之前没做到位。
- Ric2020-06-10有時候如果任務與任務之間有很強關聯性,實在比較不容易細方拆碎分配給多人做,這樣也只能夠偏重某一成員完成。
- 紫豪2019-11-21通篇读下来,发现自己在管理这块还是有很大的欠缺,没有注重对细节的掌握,太过随心所欲,没有规范的管理流程,在小的创业公司可能体现不出来弊端,但总的来说,弊大于利。
- 彪(kingbox)2018-04-18都是比较常规的方法,就没有比较好的吗?
- 李锦2018-01-04非常好的心得,总结很多时候自己带新人要么就是太放松了要么就是太紧,没分配好任务,主题不明确,感觉很多时候就是在做杂活。
- 老赵2018-01-01看到“打包装箱”,就想起写程序的时候,把一个个功能封装到不同函数里,函数之间传递简单参数,最后实现完整功能。一旦出错,debug方便。