项目进度，你汇报清楚了么？

     背景：   

     这段时间休假，今年试用期员工成立工作学习互助小组的组长很是困惑，不知道怎么评估项目进度。和他在邮件中沟通过几次，大致整理如下：

    很多时候，单一的数据评估会有欺骗性。作为一个项目负责人，评估、掌控并汇报出项目进度，是核心中的核心。那么项目进度，有那些维度呢？

一、工作单位量

    工作单位量有可能是子模块、需求数量、硬件批次等等。用工作单位量作为项目进度评估，只是很小的适用范围。

    比如传统的生产制造部门行业，固定的流水线生产冰箱，电脑。举例：10W的生产量，每天计算生产数目，就可以很精准的反馈这笔单子的项目进度。

    但是很多项目不一定是按照单位量直接衡量。
    比如测试6款软件。你们测试完成1个软件，项目进度就是1/6，测试2个，就是1/3……因为可能每款软件的测试周期不一样。
    或者需求单位量，有可能小需求，一天就能实现十个八个，同样，一个需求，可能一个团队做两个礼拜都不一定搞的定。再特殊点，乔布斯“只要一个按键”的需求，折腾了整个苹果多久？

二、时间

    时间直接等同工作进度，是很多老板的理想，更是很多老板大而化之管理的一种方式。但是作为项目负责人，绝不可以按照已用时间/总时间 = 项目进度 的方式来掌控项目，否则会挂的很难看——如果老板对项目运作比较懂行，也不要如此汇报。

    既定的时间结束，项目完成。这是唯一的交集，在过程中，时间轴和项目进度轴可能完全不搭界。作为新手的项目负责人，一定要注意，不能用时间作为项目评估的标准。

    比如一个新项目是三个月的周期，但是为了了解新业务，可能最初两个星期就是单纯的学习、摸索，也就是传统的磨刀不误砍柴工。两个星期过去了，项目进度是零——如果project上把预研、探索时间也作为项目内容，就可以正大光明的汇报：单项任务进度：100%，项目进度：XX%。

    同样，一个维护项目是三个月的周期，可能一个半月时，所有的需求都已经实现，后面的一个半月是性能、压力、升级测试，以及bug的修复期。所以可能一个半月时，项目进度就是90%，然后慢慢爬向100%。

三、人月

    呃，关于人月，《人月神话》的作者最有发言权。
    新人需要旪间学习才能上手
    新人一开始参与时，会需要对这个系统有经验的老手来加以指导，这会减少老手投入开发的时间。
    人数增加后，沟通的成本会呈几何级数地增加。
    生一个孩子要花十个月，即使找来十个人，也不可能一个月就把小孩子生出来。
    人数多了，可是现在可以让他们做的工作一下子没有这么多，项目经理得要想办法生工作让这些人都有事做。这样子反倒会让项目经理没有心力与注在真正该做的事情上。
    如果有人没事做，就会很害怕自己被裁员，就会做一些看起来像是工作的事情。于是做一些抵销人工作的事情。

    成功的项目，依赖于时间和思考，依赖于一步步的积累。成功是积累出来的。原来我第一次带项目，比你们更不堪，硬着头皮做，现在不是熬出来了么。当你感到迷茫不知如何下手的时候，先硬着头皮做。做一段时间，思路自然就有了——反而依赖于空想，不去行动，会达不成目标。

    那么，你作为一个新鲜出炉的项目负责人，会认为自己需要了解多少，才是对项目的掌握得力呢？你认为自己应该回报多少，才能让你的领导清晰直观的做到可视化管理项目？