摘要：当我们要考虑如何让项目不延期时，我们是否做到让每个员工都满负荷了？我们追求的是不延期，还是追求更卓越的产品？
这一两个星期和同事讨论如何使用看板进行项目管理时，总的来说，我遇到最频繁的问题有：
- 如何能看出项目是否延期？
- 如何拆任务？
其实，我遇到的问题是：如何能看出项目是否延期？然后经我将问题深挖，才发现他们更本质的问题是：拿到需求，如何拆任务，拆到什么粒度。
讨论这类问题，最好举个例子，否则整个讨论过程会很虚。
比如我们的项目经理从产品经理那里拿到一个需求：改版APP。这款APP有12个界面，所有的界面都需要改。而你手下有6个人。
这时，可以以两种粒度来拆分：
- 以界面为粒度
- 拆分成更可以量化的粒度。
关于什么是可以量化的粒度，下文会阐述。
按界面粒度来拆分
可以看出，以界面粒度来拆分，简单粗暴：24人天的任务，我们有6个人，所以，理论上我们只需要4天完成“改版APP”。我们可以很容易看出这个项目是否延期，只要每个界面都没有延期。
放到看板上，理所当然，每个界面一张卡。
现实中，我们的项目经理可能还会这样分到人头上：
为什么一定要分到人头上？除了方便KPI（表面上），背后还有一定的文化因素：因为当项目延期时，我们就可以找出那个相应的人进行问责。这种问责的机制导致的后果：人们更愿意推卸责任，而不是共同协作。
放大一些这个问题，公司内部多个技术部门也会因为这种问责的文化，导致部门之间更趋向责怪对方不按期，而不是共同协作完成一件事情。
再再放大一些这个问题：在人们的意识里往往认为，问责后，坏的事情就可以避免问题再发生。放到我们本篇文章讨论的上下文里，也就是问责可以避免延期。但是，可能吗？因为延期已经发生，我们应该在延期发生前进行协调资源来解决延期。
我们举个例子：在项目进行的过程中，人员B在做界面3，4时，在第3天时被一个问题卡住了。而人员C其实在第3天时就已经完成了，第4天开始优化。其他人准时完成了自己的任务。最后人员B的延期导致项目延期了2天。这时，如果你问责人员B，那么，这次的延期能倒退吗？也许你会说，问责后，这个人下次就不会延期了。
我想说：
- 延期不延期和你问责没有任何关系。如果有关系，你在项目开始时，就每个人问责一下，这样项目就不会延期了？
- 我们应该追求的是每个项目都不延期，而不是下一个项目不延期
- 我们追求的是不延期，还是追求更卓越的产品？
回头看这次延期，也许我们是可以避免的，比如在第3天的站会上，人员C说出自己被某个问题卡住了。这时，可能其他人员一句话就点通人员C的问题了。还有可能是人员C遇到的问题是需要其它部门来协助才能根本解决，这时项目经理就需要与其它部门沟通了。
回到问题“按界面粒度来拆分任务”这个问题本身。
将界面再拆分成可量化的粒度
这种方式要我们的项目经理拿到需求后，让最熟悉这个APP的人或团队对需求再进行拆分成一系列工作单元，然后再分别估算这些工作单元在现有的人员基础上需要多少天。最后估算出一个总的交付时间点。我们假设完成这个需求，我们同样需要4天完成。
至于拆分到什么程度，就是我们上文提到的可量化的程度。
什么叫可量化？
上面我们看到将需求拆分成一系列工作单元后，我们可以更灵活的安排优先级。同时，这样也帮助我们发现界面1和界面2有一个工作单元3是有交集的。有交集的工作单元，我们应该让同一个人来完成以避免其中的沟通成本。总的来说，拆分成一系列可量化的工作单元后，我们可以：
- 更灵活的优先级调控
- 发现有交集的工作单元，也就能发现可减少沟通成本的空间。
但是，什么样的工作单元叫可量化？
代码行数是最简单的，估计完成APP改版需要写10万行代码。一个工作单元，我们定1万行？这种工作单元是可以量化，但是写完那么多行代码，你就是完成APP改版这个任务了？
我们举个例子来说明什么样的工作单元叫可量化，比如对于界面1，我们需要：
- 把“完成”按钮的颜色从绿色改成蓝色
- 当完成值为100时，不显示100，显示成“恭喜，已完成”
- 缓存从服务器获得的任务完成值，对于多次操作，只向服务器请求一次，以提升用户操作的流畅感
从这个例子，我们可以看出，每个工作单元都应该是：
- 准确的：将绿色改成蓝色，而不是红色
- 不可分割的：不显示100，显示成“恭喜，已完成”，这个工作单元，你不能再分割了
- 体现了业务含义：代码行数并不能体现业务含义，但是提升用户操作的流畅感有业务含义的。
可量化的工作单元、站会与看板
有了可量化的工作单元后，再结合站会和看板，这样，我们每天都可以知道（可视化）团队的工作状态了。延不延期，大家都可以看得到，大家都是成年人了：
- 谁做得快，谁捡更多的卡来做的。而且可以捡优先更高的卡先做，也降低延期的风险。我们可以从这个过程中识别人才。
- 站会的第3天，人员B还在做_#3_卡，我们其他成员可以加快速度做其它卡以弥补人员B的慢速度，同时项目经理也可以更早的介入这个可能延期的卡中帮助人员B
- 当出现质量问题时，人员D的卡会被打回Todo多次，因为有站会，我们所有人都很感觉到_#5_这张卡可能存在一定难度或者人员D在协作方式存在问题，这时，我们其他人就会主动帮助人员D解决问题，而不是责怪他。
慢慢地，团队的协作方式变得以解决问题为导向，而不是以问责为导向。
拆分成可量化的工作单元，一样会延期
但是，我个人的经验看来即使我们将需求拆分成可量化的工作单元，项目一样可能会延期。
看板只能帮助我们更可视化，更容易地了解到项目当前的状态，对于这个状态，我们的项目经理要如何反应，完成是个人问题了。
同时，看板也能帮助我们找到延期的根本原因，比如是某个人的卡在In Progress上拖了很长时间、某个人请假了、其它部门中间改需求了、项目人员在某项技术的能力问题……
所以，要延期的项目一定会延期，我们应该正确面对，找到原因并根本解决。我们要做的只是保证每个人每个工作日都是满负荷的。
这里，留给大家一个思考题：如果其它外部条件不变，每个人每个工作日都是满负荷了？如何不延期？
拆成可量化的工作单元会增加项目经理的工作量？
然而，又会有人说了，这么多项目，我每个项目都要拆分成可量化的，我们项目经理会增加很多工作量。
其实，如果真的有作用了，这些工作量是值得的，只要你真的理解可量化工作单元的作用。同时，当出现多个项目时，你忙不过来时，说明现在是你培养另一个项目经理的时机了。你可以尝试将一些项目管理的工作交给团队成员来完成。但前提是项目经理本身也是超负荷工作，影响正常工作了。
小结
想让项目不延期，我们首先关注的是如何将需求拆分成可量化的工作单元，然后想办法保证这些工作单元真正被有效的执行。办法通常可以有：
- 使用看板可视化所有的工作单元
- 通过站会了解工作单元执行过程可能的风险
- 通过协作来取长补短
- 通过优先级来降低延期时的风险
- 通过打包有交集的工作单元减少沟通成本
通过以上方法可以将团队“调”到可能的最优状态。但是如果还是延期，原因可能就不在团队了。