我在“管理者不用亲力亲为：关键是什么”一文中，介绍了授权和任务分配的重要性。那篇文章的重点有两点：第一我们要有效地把任务分配出去，第二我们要保证分配出去的任务能够被圆满完成。
作为管理者，我们平时在项目管理的过程中，更侧重的是要保证团队成员能够按照你的期望值完成任务。今天的这篇文章里，我会进一步展开讲一些项目管理的技巧。这些技巧一部分来自我个人的思考和实践，另一部分得益于我的老板的悉心指导和启发，真实可行并且有效，希望对你的日常管理工作也有帮助。
怎么理解呢？我们从做这件事的目的说起。在给组里多个人分配项目的时候，我们往往需要考虑的因素包括以下的内容。
达到这些目的的手段，我们姑且就称其为“细分重组”。这个过程又包括两个阶段。
第一个阶段。你需要把所有要做的事，细分成一个个的小任务，每个任务的大小、完成需要的时间都大致差不多。如果有比较大的任务块，就尽可能地切分成几个小块。这需要管理者对项目本身的重点和任务细节有很好的把握。
第二个阶段。把这些大小均匀的任务块，按照上面提到的因素，分装到几个虚构的 “箱子” 里，然后分配给团队成员。这就像个打包装箱的过程，尤其需要注意的是，每个箱子一定都有一个主题，也就是说，如果你想给这个箱子起个名字，你一定能找到那个名字，并很好地概括其中的内容。最后，保证每个箱子在内容、重量等各方面都比较均衡。
完成了这个工作之后，后续项目的每一步，作为管理者的你都能做到心中有数。同时还能避免后期执行中一些可能的弊端，例如，有的人工作繁重疲累不堪，有的人则早早完成了自己任务，缺乏挑战。这种任务划分的方式还会让每个人更有成就感和责任感，因为他们完成的是一整个故事。
一般情况下，技术管理者都会对每个任务的完成时间有自己的判断，但最终还是要和接受任务的员工沟通清楚，并尊重对方的意见，确保双方能就任务时间线达成一致。有了承诺，工作的目标性也会更强一些，毕竟，截止日期才是最好的效率工具。
这一点非常重要。如果不是双方达成一致的协议，或者不是双方都认可合理的时间估算，一旦后期出现不能按期完成任务的时刻，就很容易出现一些令人不愉快的交流。
同时需要注意的是，很多工程师在做时间预算的时候，会过于乐观。我见过的大部分工程师都乐观、积极、自信，他们沉浸在代码的世界里，试图把软件做到最好，往往却会忽略时间因素。当核对工期的时候，他们会根据自己的经验给出一个非常乐观的期限。
和普通人一样，工程师们也会高估自己编程能力和对复杂逻辑的处理能力。甚至，有时候工程师给出的工期是自己负责的那部分程序编写完成的时间；然而，一个功能的完成，包含编译、单元测试、提交代码、集成测试、功能测试、性能测试和上线。如果不是特别留意，这些细节往往会泯灭在项目进度的时间表里，无法体现。
即使是一个很有估算经验的工程师，在新项目中也可能会遇到各种各样新的问题，你会惊奇地发现，上一个项目中的方法在新产品中失灵了。另外，开发中遇到的技术瓶颈或难以解决的 Bug，也会耗费程序员大量的精力和时间，这时候我们能做的事情只有等待，给他们时间去披荆斩棘，直到问题解决。
所以，在这个阶段，往往需要技术领导给出参考性的意见和建议；除此之外，你最好留出一些缓冲的时间，因为实际工作中总会有一些不可预见的情况发生。
技术领导者要做好两手准备，比如，团队中有一部分人突然表现失常了怎么办？项目由于其他原因被阻塞了怎么办？
这时候我们需要做好以下两点。
我们在 “细分重组” 中把工作分成了小块，在完成过程中，我们还需要设立各种里程碑。其中，有一些长期的大里程碑，也有一些为期一周到两周的小里程碑。这些里程碑就像你上高速行驶之前给自己定的目标：几点前要到某个服务区，几点前要到某个城市等等。有了这些里程碑，管理者就可以通过它们进行实时跟踪，了解项目的进度，看看项目这辆汽车是不是还正常地行驶在高速路上，是不是抛锚了，是不是没油了，等等。
一旦出现延迟，管理者要和任务的负责人一起分析原因，询问对方能否追上进度，会不会对整个项目的进程有重大影响。如果问题不严重，可以暂时不做调整，继续跟进。如果影响比较大，就需要启动 B 计划了，比如调整执行的人员、提供额外的资源、分析执行的方法、调动其他组支援，甚至你需要重新考虑项目进度。
今天，我和你讨论了平时在项目管理过程中的一些实践技巧，总结一下：管理者首先要对大的项目进行细分重组，“打包装箱”之后再分配下去；其次，在工期估算方面，管理者要和任务的负责人达成一致，并且要注意到，工程师们在进行时间预算的时候都是比较乐观的，最好为项目预留缓冲的时间；最后，要为项目设置大大小小的里程碑，并实时跟进，一旦项目出问题，就要启动 B 计划。
通常情况下，如果这三点做得比较好，我们的 B 计划就不会用上，这也是我们期待的最好结果。
你在项目执行过程中还有那些经验和技巧呢？可以在留言中告诉我，我们一起进步。
感谢您的收听，我们下期再见。
评论