工作计划以及总体工作之间的关系是什么呢？

走路与项目管理之间的联系是什么？

因为基本能确定上班花在路上的时间，所以每天几乎都是掐着点儿从家里出发。可是在刚出门走去地铁站的时候，因为觉得还早，所以挺悠哉的像散步一样走过去。可是下了地铁往往都8点10好几，有时是1 1、2分，有时就是1 7、8分了，从地铁站到公司也要10来分钟，就只好紧赶慢赶，甚至跑步前进了。 就算这样也未必就能及时赶到公司，上次的迟到就是一个明证了。 项目管理也会出现同样的情形。通常在项目启动时，大家都知道我们有“大量的”时间，虽然可能这段时间相对于真实进度而言可能还是很紧张甚至是不够的，可是大家看着数量“巨大”的时间资源摆在面前，很容易产生一种“还早呢”的懈怠感。 于是在项目初期产生拖拉、分析...全部

  因为基本能确定上班花在路上的时间，所以每天几乎都是掐着点儿从家里出发。可是在刚出门走去地铁站的时候，因为觉得还早，所以挺悠哉的像散步一样走过去。可是下了地铁往往都8点10好几，有时是1 1、2分，有时就是1 7、8分了，从地铁站到公司也要10来分钟，就只好紧赶慢赶，甚至跑步前进了。
  就算这样也未必就能及时赶到公司，上次的迟到就是一个明证了。 项目管理也会出现同样的情形。通常在项目启动时，大家都知道我们有“大量的”时间，虽然可能这段时间相对于真实进度而言可能还是很紧张甚至是不够的，可是大家看着数量“巨大”的时间资源摆在面前，很容易产生一种“还早呢”的懈怠感。
  于是在项目初期产生拖拉、分析设计不深入等问题也不足为奇。同样，在项目中期虽然会感觉到一定的压力，但仍会感觉有一定的“缓冲时间”在，有时也会产生“唉，这个问题我知道，等我有空了就马上解决”或是“我知道这里应该重新设计，可是我们还有时间，等过一会儿我有空了一定会好好设计的”这种想法/做法。
  然而当进行到项目收尾阶段，大家才会发现时间不够用，前面没解决的问题全都拖到这个阶段，各种各样的毛病、问题和用户反馈像火山一样爆发，大家拼命加班加点，把所有精力都投入到Debug工作中，把那些“修饰性”的设计工作抛到了下一版，所有的团队成员都为了准时提交可用的软件这个唯一目标而努力奋斗。
  最终也许可以准时提交（如果足够幸运的话），但再拖延个三四周甚至几个月也并不是什么罕见的事。 为什么会这样呢？这是因为，在项目的启动阶段（开始走路时），我们拥有全部可调动的资源，同时我们的时间还没有开始浪费在不相关的地方，所以在这个时候我们最容易也最有可能减少我们的浪费。
  就像走路时你完全可以在前半段稍稍提高你的速度，不必奔跑，就可以省下大概10多分钟的时间，而这些时间足够让你悠闲的从地铁站走到公司而不会迟到。同样在项目开始时你可以通过对需求进行详细而深入的分析，对系统进行全面的考虑而给出尽量合理的设计，在发现时间和资源浪费的同时纠正这些错误而提高开发速度，同时减轻资源（包括时间）的浪费。
  在前期的这些投入将使你在项目后期得到10倍甚至100倍的收益，因为你无法收回已浪费的时间和资源，但可以通过努力工作而减少尚未产生的浪费。 而在项目后期，绝大部分的时间和资源都已经被使用，尽管你知道很多被浪费了，你也没有办法再去收回；而同时你可以调动用来进行“补偿”的资源也大大减少，之前由于懒惰、懈怠、草率造成的问题也都开始显现，所以你在这时焦头烂额，疲于奔命，但往往还是不得不面对你无法兑现你当初的承诺的悲惨结局。
  因为无论如何努力，人的能力是有限的，就像如果地铁站与公司的距离是一个人拼命狂奔也需要15分钟的话，你在只剩10分钟的情况下无论如何努力也是要迟到的，因为你不能期望着你能比世界短跑冠军跑得还快。
   所以尽管在项目初期和项目收尾时浪费的10分钟看起来是一样的，但它们带来的影响是完全不同的，而没有认识到这个差别有时会产生非常严重的后果。 顺便说一句，同走路一样，通常不能期望项目相对于估算日期提前很多完成。
  因为当进入到项目后期，每个人都能够肯定项目不会拖延，肯定能够按时交付的时候，不能够指望他们还会拼命的去提前发布日期；相反，他们的通常做法是保持原来的进度甚至稍稍懈怠一些，因为“反正不可能迟到，为何不看着报纸走去公司？”。
   所以如果项目比估算日期提前很多完成，那只有一种情况：估算本身偏离了实际情况太多，就如同早上上班出来的太早，尽管你走得很慢，可还是很早到了公司一样。但要注意的是，尽管比预算提前了很多，但浪费也会更多??因为预算过于宽松，紧迫感会随之降低。
  收起