第十四天 工具

问：老师，我们现在功能点、里程碑、优先级、功能点详细描述、界面原型、数据库结构、数据操作描述都做好了，那么我们是否下一步就开始编码了？

 

答：不。你们还需要工具。

 

你的软件质量不行，销售部一演示就报错，实施部让客户用不起来，客服部整天接到客户的电话，那么公司的成本必须很高，当然老板就很生气。所以质量高了以后的运营成本就低了。

 

你的进度无法保证，老板问你现在干到了什么阶段，现在每个人正在做什么，每个人的工作量多大，谁的工作质量不高，你是否能顺畅的说出来？

 

所以，你需要一个需求与BUG管理工具。

 

BUG，是需要修复的任务。而没有做完的功能，也是需要完成的任务。所以BUG和需求都是任务。而程序员要做的，就是完成这个任务。

 

谁做什么功能？任务要求的时间是多长？他实际做了多长？他超出计划时间或缩短了计划时间，还剩多少任务，这些任务还需要多少天，余下的任务该如何做，是改裁减还是干脆不做？因为一个系统的功能往往是关联的，独立互不干扰的功能不太多，那么他超出计划时间或缩短了计划时间，其他业务小组该怎么办？如果在开发过程中需求有变动，程序员该怎么办？

 

很多很多的问题需要解决。所以我在讲《业务开发小组》的时候就讲到，不要让业务组长开发程序。因为有许多问题需要他来解决来协调来思考很细的细节。

 

有了需求与BUG管理工具，谁这个星期要干什么？他还有多少任务在身上？每个任务现在进展到什么程度了？现在还有多少个BUG需要他解决？他写出的功能的BUG比率是多少？他在一个月内完成的功能有多少？写了多少行代码？他有多少任务超期了？有多少任务中途变化需求了？

 

关于种种管理上要求量化的数据，我们都能很容易的统计到。对于我们控制质量、控制进度有非常好的帮助。

 

当然，有些团队过去很不正规，现在应用了这种方法，每一个环节都是新的，所以感觉很陌生很茫然，还不如过去那样省劲爽快。现在再让学习一种新的工具，更是繁琐。

 

所以，我们管理变革，一点点变革，觉得自己团队什么能首先做到，那么就去做这一点。如果工具大家抵触，我们可以先用EXCEL，也用WORD。直到大家都顺畅了，都觉得用EXCEL和WORD麻烦了，再用工具。如果EXCEL和WORD就能适合本团队，那么干嘛要换呢？我们是为了拿工具达到我们的目标，用工具是我们的手段，不是必需。