本节书摘来异步社区《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》一书中的第2章，第2.5节，作者：邱毅凌，更多章节内容可以访问云栖社区“异步社区”公众号查看
02-05项目进度（Time/Schedule）管理
嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜
接下来我们要讲项目管理9大知识体系中的时间管理。衡量一个项目是否成功的最简单方法就是是否在约定时间内，按照规格完成所有工作。而工程人员也常被问到：‘某某模块能不能on time完成？’、‘你预估要delay多久？’等与时间有关的问题。
时间是一种特殊的资源，也是项目计划中灵活度最小的因子。当项目缺人、缺钱、缺器材、缺技术时，都还有办法可想，但时间一旦过了就要不回来了！因此，实际上都是采用‘用金钱换取时间’、‘用RD肝功能换取时间’等策略，但若为企业长远发展着想，这都不该视为常事，不如在计划阶段就把时间规划好。
PMI强调项目成功的三要素为：计划、计划、计划。项目计划是通往项目成功的路线图，而进度计划则是项目计划中最重要的部分，是项目计划的核心。进度计划是基于WBS分解出来的所有Task（任务，即WBS树状结构的最末端—Leaf），确认Task之间的关系，然后估算出每项Task需要的资源与时间，进而编制出项目的进度计划。
同一件事由不同人执行，可能需要不同的时间，所以最好先确定资源，再估算时间，但实际上常有资源不足的状况，有时顺序必须颠倒过来—先预估每件工作的时间，等进度计划完成后再来分配资源。
拟定进度计划之前，必须先理清工作之间的关系。一般来说，工作间的关系有4种（请参考幻灯片中的图）。
FS（Finish to Start）：任务A结束后，才可启动任务B。
FF（Finish to Finish）：任务A结束后，任务B才可结束。
SF（Start to Finish）：任务A启动后，任务B才可结束。
SS（Start to Start）：任务A启动后，任务B才可以启动。
实际上用到最多的是FS，例如：设计完才能开始Implement，Implement完才能开始测试等，这都是FS的概念。工作间的关系相当重要，会直接影响整个项目的执行时间与关键路径的计算。举例来说，完成任务A要5天，完成任务B要10天，若它们的关系是FS，则完成任务A、B最短也需要15天；若它们的关系是SS，则可能需要10天就可以完成任务A与B（因为任务A、B可以同时启动）。
当WBS里任务较多时，人工排序并非是件容易的事，幸好有工具可以帮我们做这件事，我们只要输入每个任务所需的工时，以及任务间的关系即可。
在此我们看到Microsoft Project这个专门用于项目管理的工具，只要输入任务信息，就会自动产生甘特图（Gantt）。在甘特图里，每项任务会有一根时间bar，代表其起讫时间。除了时间外，甘特图也能包含里程碑（执行时间为0的任务）与人力资源的信息。更重要的，我们还可以拿甘特图来执行进度追踪。因为甘特图具有简单易用与容易理解的特性，所以被广泛地应用在项目管理中。
一般来说，所谓的项目计划至少要包含以下信息，使用Microsoft Project这种轻量级的项目管理软件已经绰绰有余。
工作内容描述
工作起讫时间
工作间的关系
工作所需的资源（或负责执行工作的员工）
工作所需的费用或人力成本
当进度计划制定出来后，我们必须找出关键路径（下一张投影片会讲到），此时仅使用甘特图是不够的，还必须导入‘网络图’的概念。网络图描述了项目中所有工作的特性，以及工作之间的关系。投影片中就是一个简单的网络图范例。
以嵌入式系统项目的复杂程度而言，用人工去画网络图是不切实际的，而项目管理工具可以协助我们画出网络图，并找出关键路径。
网络图有好几种形式，幻灯片中的网络图是最简单普遍的一种，节点代表工作，连接节点间的箭头指示线则代表完成工作所需的时间。所谓的关键路径，就是网络图里从‘开始（S）’到‘结束（E）’之间最长的路径，表示想要完成此项目，最快也需要这些时间。
以投影片中的网络图为例，关键路径是：S→Task3→Task4→E，路径长度为10。从这个项目计划来看，就算缩短Task1的执行时间，甚至让Task2不需执行，都无法缩短完成此项目的时间。
许多项目经理完全不知道项目的关键路径与关键工作是什么，导致项目团队可能花太多精力在整体Schedule缺乏帮助的工作上，却任由关键的工作延迟，导致整个项目一同延迟。若能从项目的进度计划中找出关键路径，可使项目主管更有效率地调配资源，让所有项目相关人员都能知道不同工作项目间的重要性等级。更重要的，所有人都会特别关注关键路径上的工作，因为不管任何关键工作delay一天，项目的Schedule就必须跟着延迟一天！
知道了关键路径，项目经理会倾向尽可能提早每项关键工作的启动时间，或设法缩短其执行时间。必须注意的是，当我们加派资源在关键路径上，可能会导致项目路径改变，此时，项目经理就必须检验查看并设法缩短新的关键路径。项目经理通过不断改善关键路径上工作的执行计划，从而完成项目计划的最优化。
我们说过，没有人能够一次就做出完美、零误差的计划，要估计准确每一项任务的工作时间绝非易事，且任务的执行时间显然与负责执行的工程人员有绝对的关系。当项目里的任务为数众多时，每项任务预估时间的累积误差将非常大。
PMI应该观察到一个普遍性的状况。无论何种领域的项目，估计工时的误差总是很难做到准确。所以PMI建议进度计划拟定好后，项目经理最好再多灌一点水，把整个项目的预定执行时间拉长一些。至于要拉长多久，应视项目计划中还有多少未知的事情，以及风险评估的结果。如果要拉长50%，则表示项目计划准确度相当低。个人认为，与其拉长项目执行时间，不如利用这个时间把规划与分析做得更扎实些。
要注意的是，我们是为整个项目预留时间，这个时间是放在项目经理的口袋里，非到必要时不会轻易拿出来用。这意味着项目经理仍必须强烈要求各项目成员把预计工作时间估计准确，如果员工反应有太多未知，实在不知如何估起，这通常表示WBS切割得还不够细，必须把规划工作退回项目范围分析，或者采用滚动式规划（Rolling Wave Planning）这项方法。
举例来说，面对一个团队完全没做过的项目，同事们普遍反应未知的东西太多，无法在初期就identify出明确的工作项目与时间，但我们至少知道项目的目的与预定的deadline。假设6个月内要完成这个项目，那么，我们至少可以精确做出前一、两个月的计划，其中的工作项目可能是评估、分析、研究、买入solution等，而后面几个月的计划则保持模糊。例如：工作项目：implementation；执行时间：3个月。待分析工作完成后，对后期的工作性质应该就比较有把握了，此时，再来更新并细化计划的后半部。
至于幻灯片中的Parkinson’s Law（帕金森定律）就不用提了，我本身也由工程师起家，深知大家是如何利用时间的。但我现在是项目经理，得把项目里时间的buffer收回我的口袋。
这张幻灯片将对项目进度管理做个总结。
虽然我们会为项目进度留些buffer，但对于项目进度的安排应该要有适度的压力，让项目成员有适度的紧迫感。但这不表示项目主管必须不断地在进度上压迫工程人员，只会问‘还要多久可以搞定？’、‘会不会delay？’这些话，严格来说，都不能算是合格的项目主管，过度强调进度，很容易会伤害项目人员的士气。
当进度计划已经公布，同事们也知道关键路径与关键工作是什么，工程人员只要按章行事即可。此时，项目主管应该专注在任务的完成质量上。也就是说，基于任务的schedule，通过不定时对任务成果的review，自然能够得知该任务的进度，也能实时挽救即将delay的任务。