程序员要知道的项目规划技巧：再也不怕项目delay了

任务总是做不完、项目不小心又 delay，是很多工程师和互联网人在项目规划经验不足时会掉入的一个常见误区。

项目规划的过程的确很复杂，从程序员角度出发，也未必与项目经理的观点一致。但项目管理技巧，绝不是只有项目经理才有必要掌握的技能点。如果你在动手写代码之前能够做一些简单规划，不仅不会耽误工夫，还能事半功倍。

近期，100offer 联合 Momenta 做了一场知乎Live《程序员要知道的项目规划技巧》，这里我们将 Live 的精华实录部分分享给大家。

如何描述一个任务是否重要？

首先，如何判断一个任务是否重要？一般可以把重要性分为 Critical，Major，Normal，Minor 等不同级别。我们先看重要和不重要这两个级别。

举个栗子：你手头现在有 4 个任务：安排来访客户日程、重构代码、把咖啡机换个位置以及买一张即将开奖的彩票。

前两个是明显重要的，后两个就没那么重要，这就把任务按照重要度分成了不同的级别。但这并不是唯一的分级方法。

「紧急性」就是「重要度」以外的一个维度。用紧急来评价这几个任务的话，可能得到的结果就非常不一样了。

一个事情紧急或者不紧急往往会随着时间推移而变化，比如说「我要吃午饭」 ，这件事情是非常重要的，但是如果在晚上，就不紧急，如果刚刚错过了午饭时间，就显得很紧急了。

重要和紧急是两个正交的维度，我们可以以此把任务分配到图中的四个象限。

从直觉上肯定会先做「重要-紧急」的事情，最后才做「不重要-不紧急」的事情，但对于「紧急-不重要」和「重要-不紧急」的事情就没这么好决定了。我们的建议是，如果还有时间就专心去做重要的事情，不重要的事情做不做都可以。

再来看「重要-紧急」和「重要-不紧急」：是不是应该先把「重要而且紧急」的事全做完了，才开始做「重要-不紧急」的事呢？

千万不要，千万不要，千万不要。

因为如果你这么做，可能又会陷入一个怪圈：越来越多紧急的事情不断地打扰你，你就像救火队员一样到处去填坑，没有时间处理别的事了。

遇到这样的问题，除了人力不足或者效率不高的原因以外，还要想一想，是不是因为你一直在专心做「重要-紧急」的事情，而忽视了那些「重要-不紧急」的事情。很简单，随着时间推移，「重要-不紧急」的事情会变得越来越紧急。如果不分配时间给不紧急的事情，摆在你面前紧急的事情就会越来越多。这一方面会影响你的心情，另一方面也会严重打乱你的计划。

所以，建议在分配时间时遵从80-20法则，花80%的时间做「重要-紧急」的事情，20%的时间做「重要-不紧急」的事情。比如像重构代码、写文档这些事，可能属于重要不紧急，但如果不去做的话，随时间推移，你为之付出的代价也会越来越多。

「重要和紧急」两个维度是最简单有效的，但我们很难用一个二维的评价体系做任务的排序，所以还需要引入一些能够排序的评价体系。比如有两种常见方法：

一种叫「分数」。给每一个任务赋予 0 到正无穷的整数分数，分数越大代表这件事越优先。这种方法的优点是：当你给所有任务打好分之后，就很容易排序，排前的先做，排后的后做；缺点是分数很零散、种类很多，打分标准随着不同人甚至同一个人的不同时间而变化，对统一标准会带来负担。

另一种方法叫「优先级priority」。把任务分为 P0 到 P3 四种级别，P0 最优先，P3 最不优先。这个方法解决了统一尺度的问题，缺点是排序很困难，比如同是 P1 的任务，哪一个更重要，是体现不出来的。但从易用度来讲，优先级略胜一筹。

如何进行项目规划？

简单来说就是把任务划分出优先级，并制定合理的完成顺序，但过程并没有那么简单。

上图是一个规划的大体流程，它至少包含以下几步：

第一步，确定目标。

目标是团队共识的基础，必须明确且具体。

比如，上图左边 「开发车辆识别模块」这个目标其实是很模糊的，但如果换成右边的表述就明确了。

一个好的目标至少要包括：时间、任务、验收标准，目标往往会配合一个简单易记的口号，像左边的「开发车辆识别模块」更像是一个口号，可以喊口号的同时在文档上记录目标，将两者关联起来，达到互补的效果。这样既容易强调，又能形成共识。

第二步，分解目标。

有时候目标可能会很大，需要多个功能搭配完成。因此对目标的分解，一方面有利于项目人员了解到底需要做些什么，另一方面可以通过讨论把想要支持的场景讲清楚。比如我们可以把上图左边的目标分解成右边的样子。

第三步，划分优先级。

分解目标后可对功能划分优先级，用 P1 到 P3 定义。

P1 是 Must Have，这个功能如果不做目标就无法完成；

P2 是 Should Have，应该做，不做的话对目标有一些影响，但也可以达成；

P3 是 Nice to Have，最好做，不做的话也不会怎么样。

偶尔在非常紧急的情况下可能会用到 P0，正常规划时建议尽量不要使用。

划分优先级之后一定要和团队讨论下。如果有分歧最好在这个阶段就把它找出来并且消除。

第四步，拆解任务且预估时间。

功能还是一个比较大的概念，要把它拆解成一个个细小的可执行的任务。任务拆得越细，估计的时间越准。

原则上，单一任务尽可能不要超过一天，最好按小时来计，超过一天可考虑进一步细分。还可以把一个功能分解成不同任务，由不同的人合作完成。

功能拆好之后，建议用管理工具来记录任务，比如 Jira、Trello 都是不错的选择。

第五步，设置检查点。

在项目截止前设定几个检查点，具体数量可根据情况来定，如果项目整体的风险大一些可以多设几个，风险小就可以设得松一些。再把所有任务填到不同的 Checkpoint 周期里去。

每个 Checkpoint 中，应优先完成优先级高的任务。在分配任务的过程中，应尽可能把有相互依赖关系的任务分给同一个人来做，这样就不会因为一个人的延误影响到其他人。

还要尽可能考虑不同成员任务量的平衡，如果任务分配不均，有的人过于空闲而其他人做不完，对项目也有风险。

任务分配好之后，可进行进度跟踪。一起来认识下上图的几个常见的进度跟踪工具。

第一个是看板。看板是个轻量级工具，从左到右共有四列：Backlog，To Do，In Progress 和 Done。把每个任务用便签表示，放在黑板上，在开始时把所有要做的任务放在最左列，每进入一个新的 Checkpoint，就把便签放在相应的 Checkpoint 上。

看板最大的好处是对项目进度一目了然。

举个栗子，项目有 10 人，In Progress 只有两个任务，意味着很有可能有些人没活可干，或者这些任务需要多人同时完成。如果是后者，就代表任务分得不够细。

反过来如果 In Progress 有超过 10 个项目，很可能项目里有人同时在做多件事。虽然老板可能会觉得自己赚到了，但这其实并不是什么好事——事情之间互相干扰，可能会影响员工效率。另一种可能是有人在做完一件事后没有把它从 In Progress 挪到 Done 里，这就需要项目经理定期更新看板。

另一个工具是燃尽图。

这是一个被动型工具，展示的是根据项目管理统计出的数据。横轴表示时间，纵轴表示剩余的任务时间总量，如果把所有任务预估好时间，就会得到一张剩余任务量的趋势图。

理想情况下应该像这条红色虚线一样从左上角连到右下角，但这未免也想得太美了——现实世界当然是不会这么来的。

实际的线可能在虚线之上或之下，虚线之下意味着比预期进度快，之上意味着有些 delay。

在这张图里可以看到第四周有一个非常大的上升，这可能表示加入了新需求，或者引入了新bug，导致需要花更多时间解决。

所以一个项目如果所有趋势都是在虚线之上，就代表有很大的 delay 风险；但是反过来，如果所有节点都在虚线下也未必是好事，虽然总算是能按时完成了，但很可能代表你预估时间的能力有问题。

还有一个工具叫甘特图。这个工具有点小复杂，我们用不同的颜色代表不同的人。比如第一个人会在第一周开始做任务一，一直做到第二周，以此类推。

比如从上图的甘特图可以看出不少问题：第二周很有风险，因为第一个人和第三个人在同时做多件事，影响效率。

另外第二个人的任务五在第二周很晚才开始，why？在图上我们可以推测到，或许他依赖任务七的结果，也就是第三个人影响到了第二个人的工作。这时你就得考虑，是不是要把任务七提前完成，任务八稍晚完成，这样第二个人就可以更早开始工作。

甘特图是项目经理的常用工具，需要一定的规划能力。如果规划做得好，可以在项目中发现很多问题。

      

这3个项目规划的常见误区，

你肯定有同感

误区 1：「为什么任务总是做不完，项目总是会 delay？」

如果你经常产生这种抱怨或困惑，八成是因为时间预估不准，造成恶性循环。

建议在你的项目预估的时间里加一些buffer（缓冲）。如果预估一件事情两天可以做完，那可加一天或半天的 buffer，用来规避一些未知因素和潜在风险。

另外，你最好考虑下是否对有效工作时间认识不足。有效工作时间和工作时间是不同的，虽然每天上班是 8 个小时，但因为开会、讨论等影响，实际工作时间并不到 8 个小时。如果按照 8 个小时规划任务，基本是做不完的。有效工作时间因人而异，一般而言是 6 个小时，但如果比较忙可能是 5 个甚至 4 个小时。

误区 2：当任务存在较大的不确定因素，常常就有人把「不知道这个事需要做多久」挂在嘴边。

这个说法显然也是不对的，如果大家都这么说，项目就不用做了。虽然有些事情的确无法精确预估，但只要你给出乐观的估计时间，再加上一些风险时间就好了，之后再随着项目发展，不断修正风险时间。

同时，真正的未知因素其实只是很小的一部分，可以把这个复杂任务再次细分，把真正不可估计的部分独立出来。这样，整体时间的预估就更准了。即使剩下的部分花了 2 倍的时间，对整体预估也不会造成太大影响。

误区3：「不要管我做事的顺序，我保证在 deadline 前做完」

在没有发现更行之有效的做事方法前，还是请老老实实按照优先级顺序来完成。

首先，任何预估都不可能 100% 准确，总是存在风险的，如果先做了低优先级的任务，就可能延误高优先级的。其次，即使预估 100% 准确，你也不能保证在项目进行中，不会出现更高优先级的事情，或者说遇到断网断电这样的天灾。如果没有遵守优先级，这也会成为隐患。

所以，多掌握一些项目规划技巧，能让开发者和技术管理者更游刃有余地进行团队分工合作，也能帮你掌握更多主动权，不至于每次都被时间节点给玩坏了。

公众号：javafirst