关于项目时间的评估

话说上一篇博文是2011年的文章，这个博客已经遍布蜘蛛网了，其实我有常过来看看，却无心书写下一篇博文。2011，2012年可是多事之年，我疲于奔波这个那个，结果啥也没有得到，回过头来，想想，要是当初有一份计划那该有多好，精确指导未来该何去何从。每次写博文必须先吐槽一番，不吐不快。

自从2010年加入了汇丰软件，一直安安分分的做一个J2EE的软件工程师（SE），光学习公司内部的BT框架就学了个一年半载。刚开始学习框架，一些开发任务完成得很吃力，总认为自己技术不够，自己主动加班，时间持续了一年多，等到自己开始熟练的时候，新的技术又来，即便做自己熟悉的技术，还是需要加班。这个时候我就开始思考自己为啥需要加班去赶这个死人的工期，即便很拼命的赶上这个项目的里程碑，下个里程开始的时候又松松垮垮，直到下个里程碑日期将至，又拼命的加班，反反复复。无法终结这个循环。

这个将目光指向了项目计划的制定和人员安排的那份plan了，我质疑那份plan的可靠性，和严密性。 据我所知，这份plan是从一个项目抄过来的，再由之前写plan的人分享一些经验过来，和项目经理的过往管理经验，估算出来的一份plan，即便把每一个详细item写的很清楚，可这份东西终究是没有数据支持的，只有经验支持。所以这份项目计划书和实际上是有很大的差距的，但为什么这样的一份计划书每次都能够成功的完成任务？

以鄙人的拙见：

1）项目计划书在实施过程中依据情况做时间的微调，在里程碑时间不变的情况下作修改。(本身plan够宽松)

2）用户大发慈悲放松的周期和注入了新资金，有钱加多些高手进来(这种情况并不多见)

3) 项目中的开发人员没日没夜的加班工作(最为常见)

 

对比一下建筑行业的工期计划表，这个软件开发的项目时间表一样，可他们不同的是，建筑行业项目的每项工期都是可知，比如每十米的砌墙时间，都是确定的，楼层水泥沉降时间是确定的，不同比例的混泥土凝固时间也是确定的，有多少这方面的资料，而且都是通用的。精确到每个细项，给多少钱做多少事，建筑行业中的明细项通用性高，可重用资源多。 建一层楼需要多长人工和时间很多时候是确定的，只要不出意外。

可软件行业却不同，软件行业中，异常境况多如牛毛，不同人对一个分配到的相同task完成时间差距相当大，高手有可能1天，新手有可能1个星期甚至2个星期才能完成，或是方向错了，做了一个星期，再花多两个星期将之前的错误修复，然后再重新开工，一个月就过去了。以前也听过大牛在网上吐槽过，建筑行业和软件行业的不同点，虽然同是做工程的。建筑行业里面，比如说这个楼层建个3.5米，或这面墙离厕所1.5米距离，这些由用户和工程师设计好后就不会改，特别是开始施工的时候，已经建了3.5米，不会有人来吵说改成3.51米，一旦施工，就无法修改，不同建筑的是，软件是可以修改的，包括里面的钢筋5条加到6条，都是没有问题的，有必要的话，我们架构师把这个设计优化一下，等下程序员们会把它搞定的。老板们说完狂笑一番，下面的程序员们已经喷血了。。。

回到正题，关于项目时间的精确评估,以上吐槽那么多，主要是要表达一个观点，就是建筑行业中的明细项有过往的经验和数据支持，而且基本变动不大，而且需求不会再开工后做巨大变动。 如果软件行业中也可以有这个所有开发项目中明细项的经验和数据支持，比如开发一个登陆界面花多少时间，一个检索功能的按钮时间的多长，每个具体的任务都一个份checklist可以根据。

这些经验都没有给记录下来，都给每一个工程师或项目经理独自带走了。 要是，我又说了whatif之类的话了。

如果每一个项目的所有细节都靠文档记录下来，把这个项目的开发时间记录下来，交由项目组存档，新开的项目组就可以从中吸收经验。将同类型的项目经验归类存档，让相同类型项目去参照，制定项目计划，然后再一个循环记录下所有项目细节，然后再由下一个项目迭代优化。这样对新开项目是一个福音，而且在与用户沟通的时候，可以用以往数据做根据，跟用户争取更加准确的工期和工钱。比如下面一个场景，

BA(业务分析员)+SA(系统分析师)+PM(项目经理)， 3人去跟用户谈项目的价钱和时间的时候，

PM: 这个项目必须需要60hcm(人月，一个人做一个月的时间)。

用户:需要这么多时间吗？ 隔壁项目组做类似的项目只需要40个hcm，也是几个页面啊，同样是几个数据检索页面。

PM:....

通常来说这个情景，不同项目经理淡出来的结果相差很多，有的把周期定成了70个hcm，有的变成40hcm，有的变成45hcm，实际情况，大家还未知道。所以加班的原因不言而喻.

 

列下一个不同人员在一个项目中的定位，大家觉得有问题或不合理的可以提

情景一：项目进行一半，新增人员加速项目周期(常见)

初级软件工程师(TSE):

1）只具备开发基础，学习新item周期长，需要前辈指引

2）做重复性文档工作

3）辅助性测试

4）简单需求更改。

软件工程师(SE)：

1）独立开发一个新item，实现SSE提出的设计。

2）制定item的单元测试，

3）实施SA/SSE提供的技术解决方案并及时回复结果

4）对小型item有管理能力能任何时候汇报当前item完成的实际情况。

5）能在测试阶段对系统缺陷进行修复

高级软件工程师(SSE)：

1）分解大item成独立task，交由SE实施。

2）与SA沟通提出对关键技术解决方案

3）与第三方部门沟通协作，促进task的完成

4）能在测试阶段对系统缺陷进行修复，提供解决方案

5）汇报大模块的完成情况

6）与需求分析师沟通了解更准确的需求

系统分析师(SA)：

1）关键技术解决方案提供.

2）与第三方部门沟通协作，促进task的完成。

3）制定文档标准，关键技术文档编写，对项目相关技术有高层次的理解

4）与需求分析师沟通了解更准确的需求

项目经理(PM)：

1) 应付上级压力

2）解决项目中的出现的影响项目周期的瓶颈

项目经理助理(PMA)：

1）辅助PM收集项目周期的相关信息。

2）管理文档。

3）传送各层开发人员需要的信息。