项目最本质的一个特性是不确定性，所以实际的执行与预估有些偏差很正常。预估较实际所花费的工作量时大时小，有人快，有人慢。单独从个人能力来解释进度并不客观，因为本来项目排程时就应当考虑到人的能力的不同。
既然一切都在项目进度规划中定义，所有工作都能按步就搬的完成自然最好，但项目的不确定性告诉我们这是难以确定的。总有些任务会提前，也总有些任务会滞后。如果我们只关注滞后的任务，那可以想像项目总会延期的，最好的结果也只能是按时完成。但如果我们能利用到提前完成的时间呢？
项目中识别关键路径并严加监控是常用的做法。项目在进行过程中关键路径实际上会发生改变的，因为有些非关键路径会因为资源的问题导致整体进度延后。可是你怎么知道哪个非关键路径上的任务会出问题？
将TOC运用在项目管理上，我们要找出项目中的约束条件在哪里? 是什么资源会限制项目进度? 也就是找出关键链。项目进度的规划重点就在关键资源的规划，因为它的产出将决定整体的产出，它的进度将决定整体的进度。
比如程序员A为核心程序员，一些项目的主要模块为确保质量，都需要由他进行分析设计。这时他就可能是项目的关键资源，其他任务都应当要配合程序员A的进度。如果任务过重，可以细分他的工作由别人承担一部分，或者再培养新的核心程序员，也就是建立资源缓冲。无论他的工作在不在关键路径上，都需要特别加以关注。
当确保关键资源可以有效使用后，再要做得就是挤掉项目中的安全时间。我们在预估工作量的时候要么过于乐观，要么过于悲观。一般工作时间越长，悲观的成分会越大一些。这和我们在项目中体会到不确定性有关系。所以我们会在一个可能的时间后加上一点缓冲，对应于TOC这个就是局部上优化，但对于全局并不是最佳的。
于是这部分时间应当以使用乐观估计的时间去除，也就是没有了安全时间。然后将挤掉的时间，视项目的风险，安排一定比例做为项目缓冲，放置在关键路径之后。为了减少非关键路径的延后影响到关键路径上的任务，在非关键任务与关键路径交会的位置增加一部分接驳缓冲。
最后就是这些缓冲时间不要告诉工程师，虽然大部分人都知道有，但毕竟具体是多少是自己可以管控的。如果大家都知道了各个缓冲的时间，安全时间仍然会普遍存在，整体的进度并不会有真正的改进。
我刚出来工作时，遇到了产线的一位有经验的班长故意将前一天多出来的产出隐瞒不报的情况，我能理解他可以用来填补第二天可能出现的产出不足的情况。这也是一种缓冲，但却是一种局部上的优化，实际上会导致整体产能的低效和不必要的线边库存。
写得肤浅，有兴趣可以再搜些资料看看。
其中<<关键链>>是本很值得读一读。
转载请注明出处: http://blog.csdn.net/horkychen
