问:老师,我们现在功能点、里程碑、优先级、功能点详细描述、界面原型、数据库结构、数据操作描述都做好了,那么我们是否下一步就开始编码了?
答:不。你们还需要工具。
你的软件质量不行,销售部一演示就报错,实施部让客户用不起来,客服部整天接到客户的电话,那么公司的成本必须很高,当然老板就很生气。所以质量高了以后的运营成本就低了。
你的进度无法保证,老板问你现在干到了什么阶段,现在每个人正在做什么,每个人的工作量多大,谁的工作质量不高,你是否能顺畅的说出来?
所以,你需要一个需求与BUG管理工具。
BUG,是需要修复的任务。而没有做完的功能,也是需要完成的任务。所以BUG和需求都是任务。而程序员要做的,就是完成这个任务。
谁做什么功能?任务要求的时间是多长?他实际做了多长?他超出计划时间或缩短了计划时间,还剩多少任务,这些任务还需要多少天,余下的任务该如何做,是改裁减还是干脆不做?因为一个系统的功能往往是关联的,独立互不干扰的功能不太多,那么他超出计划时间或缩短了计划时间,其他业务小组该怎么办?如果在开发过程中需求有变动,程序员该怎么办?
很多很多的问题需要解决。所以我在讲《业务开发小组》的时候就讲到,不要让业务组长开发程序。因为有许多问题需要他来解决来协调来思考很细的细节。
有了需求与BUG管理工具,谁这个星期要干什么?他还有多少任务在身上?每个任务现在进展到什么程度了?现在还有多少个BUG需要他解决?他写出的功能的BUG比率是多少?他在一个月内完成的功能有多少?写了多少行代码?他有多少任务超期了?有多少任务中途变化需求了?
关于种种管理上要求量化的数据,我们都能很容易的统计到。对于我们控制质量、控制进度有非常好的帮助。
当然,有些团队过去很不正规,现在应用了这种方法,每一个环节都是新的,所以感觉很陌生很茫然,还不如过去那样省劲爽快。现在再让学习一种新的工具,更是繁琐。
所以,我们管理变革,一点点变革,觉得自己团队什么能首先做到,那么就去做这一点。如果工具大家抵触,我们可以先用EXCEL,也用WORD。直到大家都顺畅了,都觉得用EXCEL和WORD麻烦了,再用工具。如果EXCEL和WORD就能适合本团队,那么干嘛要换呢?我们是为了拿工具达到我们的目标,用工具是我们的手段,不是必需。