代码进度统计（二）

 

代码进度统计（二）

 

 

 

本次统计以HMIS为蓝本。

生产力

8个月，160个模块，每个月20个模块：

5人：每周4个模块；
6人：每周3.33个模块；
5.5人：每周3.64个模块。

 

生产率

人员流动性大，稳定人员是5人。

这是在经常加班的情况下完成的。14天扣除周末，只有12天，但每天的加班量算上，其实也是14天。

最好的情况下是5个人每周4个模块，每个人每周（7天）0.8个模块。

评价

总体说来效率有点低，每个人5天（一周、不加班）一个模块才是合格的速度。 

原因

什么原因引起的？

项目周期这么长，产生的低效率我相信不是一个原因引起的，而是多种原因并发产生的。

 

沟通不顺畅？

团队是坐在一起的，客户也在现场，不存在沟通条件不足的情况。事实证明，现场开发是一种有效的手段。我相信如果没有现场开发，项目周期会更长。

 

项目周期长、封闭式开发？

这是一个原因，项目周期太长了，又是半封闭式开发，团队中后期普遍士气低落，开发效率高不起来。

如果现场开发不可避免，建议每隔一段时间（不超过三个月），团队撤回深圳休整一次，每次休整一个月。休整期间仍然做项目开发，但严禁加班。

 

项目太复杂？

总体来说项目的业务逻辑并不复杂，有少数（不超过10个）的模块算得上复杂，但复杂性处于可控范围之内。

MIS项目的复杂度永远有限，但模块一多，bug自然翻倍，维护起来也更困难（bug之间是有关联的）。建议PM不再编码，专门抓项目的代码质量和系统测试。

 

天天加班导致效率下降？

这也是有的。至少我在后期表现得很明显。

建议尽量少加班，最好是不加班。如果项目时间很紧张，确实要加班，那么也不要天天加，最好一个星期不超过三次。周六可以适当加班，但周日严禁加班。

 

没有有效的团队管理？

团队基本上没有管理制度，PM分配任务之后就不再过问，没有测试、没有review，大家各自为战。

晨会、任务日志、Code Review、成品测试（模块单元测试、自动化测试）都要搞起来。