朱赟的技术管理课
朱赟
计算机博士,前Airbnb技术经理
立即订阅
11176 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 从工程师到管理者,我的思考与实践
免费
01 | 职场分身术:从给答案到做引导
02 | Bug引发事故,该不该追究责任?
03 | 每个工程师都应该了解的:A/B测试
04 | 如何帮助团队成员成长
05 | 当我们给别人提意见时,要注意些什么?
06 | 每个工程师都应该了解的:聊聊幂等
07 | 当别人给我们提意见时,该如何应对?
08 | 说说硅谷公司中的一对一沟通
09 | 每个工程师都应该了解的:大数据时代的算法
10 | 项目延期了,作为负责人该怎么办?
11 | 管理和被管理:期望值差异
12 | 每个工程师都应该了解的:数据库知识
13 | 管理者在进行工作分配时,会考虑哪些问题?
14 | 硅谷人到底忙不忙?
15 | 每个工程师都应该了解的:系统拆分
16 | 技术人如何建立个人影响力?
17 | 管理者不用亲力亲为:关键是什么?
18 | 每个工程师都应该了解的:API 的设计和实现
19 | 硅谷面试:那些你应该知道的事儿
20 | 项目管理中的三个技巧
21 | 每个工程师都应该了解的:中美在支付技术和大环境下的差异
22 | 不要做微观的管理者
23 | 如何处理工作中的人际关系?
24 | 编程语言漫谈
25 | 兼容并包的领导方式
26 | 如何做自己的职场规划?
27 | 小议Java语言
28 | 如何激发团队人员的责任心
29 | 说说硅谷互联网公司的开发流程
30 | 编程马拉松
31 | 工程师、产品经理、数据工程师是如何一起工作的?
32 | 硅谷人如何做 Code Review
33 | 技术人的犯错成本
34 | 如何从错误中成长?
35 | 理解并建立自己的工作弹性
36 | 如何对更多的工作说“不”
尾声:成长不是顿悟,而是练习
新书 |《跃迁:从技术到管理的硅谷路径》
朱赟的技术管理课
登录|注册

20 | 项目管理中的三个技巧

朱赟 2017-12-27
我在“管理者不用亲力亲为:关键是什么”一文中,介绍了授权和任务分配的重要性。那篇文章的重点有两点:第一我们要有效地把任务分配出去,第二我们要保证分配出去的任务能够被圆满完成。
作为管理者,我们平时在项目管理的过程中,更侧重的是要保证团队成员能够按照你的期望值完成任务。今天的这篇文章里,我会进一步展开讲一些项目管理的技巧。这些技巧一部分来自我个人的思考和实践,另一部分得益于我的老板的悉心指导和启发,真实可行并且有效,希望对你的日常管理工作也有帮助。

第一个技巧,我们在做项目计划的时候,要对多个项目进行细分重组

怎么理解呢?我们从做这件事的目的说起。在给组里多个人分配项目的时候,我们往往需要考虑的因素包括以下的内容。
先评估能力,再分配任务,每个人的能力要和任务的难度匹配。
每个人任务完成所需时间要尽量平等,也就是要达到一种负载平衡。
每个人得到的任务里,挑战有意思的工作和脏活累活的比例要大致相等。
每个人任务里有足够的挑战,能够帮助其成长,又不至于太难而让其望而生畏并产生挫败感。
不同人的任务之间如果有依赖性,在分配任务时要安排合理的顺序,确保不会有人被别的人或事阻塞(Block)。
每个人的任务里都应该有一个主题,就好像故事有一条主线。这样,成员会觉得自己参与了一个比较完整的任务,进而产生成就感,而不是感觉做了一堆杂活。
达到这些目的的手段,我们姑且就称其为“细分重组”。这个过程又包括两个阶段。
第一个阶段。你需要把所有要做的事,细分成一个个的小任务,每个任务的大小、完成需要的时间都大致差不多。如果有比较大的任务块,就尽可能地切分成几个小块。这需要管理者对项目本身的重点和任务细节有很好的把握。
第二个阶段。把这些大小均匀的任务块,按照上面提到的因素,分装到几个虚构的 “箱子” 里,然后分配给团队成员。这就像个打包装箱的过程,尤其需要注意的是,每个箱子一定都有一个主题,也就是说,如果你想给这个箱子起个名字,你一定能找到那个名字,并很好地概括其中的内容。最后,保证每个箱子在内容、重量等各方面都比较均衡。
完成了这个工作之后,后续项目的每一步,作为管理者的你都能做到心中有数。同时还能避免后期执行中一些可能的弊端,例如,有的人工作繁重疲累不堪,有的人则早早完成了自己任务,缺乏挑战。这种任务划分的方式还会让每个人更有成就感和责任感,因为他们完成的是一整个故事。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《朱赟的技术管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • nanquanmama
    分配项目的做法很像是map/reduce

    池建强回复: 这个比喻很形象啊,赞

    2017-12-29
    18
  • 刘剑
    我谈下我的项目管理感受:

    1.在项目管理中很多时候在前期需求分析阶段就出现问题(伪需求、需求不明确就已经设计出方案),所以即使项目顺利完成效果也不好,而且前期需求不清晰会导致开发中需求变更,频繁的变更会成为项目失败的主因。我见过和亲身经历太多需求问题导致项目失败的案例
    所以项目进程中首先需要从这个源头开始严之又慎,从因果关系来说没有好的因不会得好的果,需求分析阶段在项目中真是太重要了。

    2.一个磨合很好的团队,由于时间预估不足导致延期可能性较小。这种延期多出现在刚组建的团队阶段,大家彼此陌生,流程不规范,配合不默契,沟通成本也很高。在这种情况下我通常第一次让开发人员自己估计时间,我再在这个时间上加20%的项目缓冲期时间以应对突发事件。由于我们用的MVP模式,所以每次迭代周期短,当第二次迭代期,我会帮助开发人员梳理开发流程中的问题,帮助他们开发流程更顺畅、更高效,比如:需要列出功能开发优先级顺序,对于关联功能或需要联调功能优先完成,独立开发的功能放在后面完成等等技巧可极大提高他们开发效率。再有了第一次开发作为纵向评估标准,第二次开发效率会高很多(同等难度效率提高40%以上)第三次会再梳理。基本三次迭代后团队基本可定型,后续开发在没有外界因素变化的情况下开发进度很稳定。

    3.对于需要技术攻关的时候,在项目需求和设计阶段就要让开发人员尽早做技术调研出有核心功能的Demo,到真的开发阶段Demo代码就可以复用到项目开发中,省时又省力。
    2018-01-05
    10
  • 走小調的凡世林
    一般用什么工具进行项目管理呢

    作者回复: 每个公司有自己的工具规范吧,我们目前用 Trello 多一些,也有用 Excel 来管理的。

    2019-08-25
    1
  • yoummg
    需求的按时完成最好两点。
    1.技术需求的评审
    2.需求迭代时的把控。(即里程碑的设定)
    2018-12-11
    1
  • MarksGui
    需求评审真的太重要!最近一个需求就是产品出的需求不明确,导致开发时不断重新商讨修改需求,致使项目严重延期!这也是自己的不足。
    2018-07-10
    1
  • Donghe
    我发现项目时间预估和跟进挺tricky。预估了太乐观,到时候因为无法预测的原因delay了被block了,这时候求助援助吧,心理上显得自己没能力没办法树立组里形象,不求助吧,对项目进展不负责。这个心理特别经常出现在新组员身上。所以您对此有什么看法和见解么?
    2018-04-28
    1
  • 紫豪
    通篇读下来,发现自己在管理这块还是有很大的欠缺,没有注重对细节的掌握,太过随心所欲,没有规范的管理流程,在小的创业公司可能体现不出来弊端,但总的来说,弊大于利。
    2019-11-21
  • mikejiang
    一般一周可以完成的需求,基本估计都是比较准的,加一天缓冲即可;两周的事情,可能就要加30%的缓冲,三周以上的项目,可能性要加40%的缓冲。
    2019-11-14
  • 彪(kingbox)
    都是比较常规的方法,就没有比较好的吗?
    2018-04-18
  • 李锦
    非常好的心得,总结很多时候自己带新人要么就是太放松了要么就是太紧,没分配好任务,主题不明确,感觉很多时候就是在做杂活。
    2018-01-04
  • 老赵
    看到“打包装箱”,就想起写程序的时候,把一个个功能封装到不同函数里,函数之间传递简单参数,最后实现完整功能。一旦出错,debug方便。
    2018-01-01
收起评论
11
返回
顶部