软件开发难,恐怕大家都觉得最难的是搞清楚需求;但是其实更难的是管理需求。今天在北京.NET俱乐部上又有人提出了这样的问题,主要的难点是他的开发团队是为了自己的领导们服务的,几个领导都有自己的想法,而且不停的在开发过程中提各种个样的问题;开发进度无法保证,开发的结果总是满足不了要求……
其实这样的问题大家都遇到过,而对于普通的开发人员来说我们往往不去关心,认为这是项目经理的事情,但是其实不然,这样的问题涉及软件开发的各个环节,就算你是出于最底层的开发人员,一样需要控制项目经理交给你的任务。其实这里最重需要把握的一点就是:把任务控制在你能控制的范围之内。总结一下,我的经验如下:
第一:无论你的客户是谁,我们永远需要一个中介来接受需求;你首先需要和客户有个协议,需要他们制定某一个人来提所有的需求,这个人不需要是很高职位的人,而且往往最好的选择是中层的技术管理人员;用户的所有需求必须通过这个人的认可,就算是对方老总提出的要求,如果没有这个人的认可我们也不执行。这点非常重要,可是替我们减少许多麻烦。
第二:无论是什么样的软件开发过程理论现在都承认一个问题,那就是软件开发需要迭代。而且我们一定要面对一个现实,就是软件开发的过程是在不断的变化中寻找平衡的过程,我们的需求永远不会结束,我们的软件永远都在被修改;修改不是坏事,但是我们必须要保证在一定的时候可以拿出成果。
所以,控制迭代的增量就是非常重要的。一般我们公司的做法是,以两周为一个周期最为一个Release,一旦这个Release开始以后,任何用户的新需求就都需要放到后面的Release;我们不会决绝客户的需求,但是我们必须管理我们可以承受的进度。这样做的最大好处在于,在两周的时间内,我们一定可以为客户提供一个更好的版本,这可能不是客户现在心目中的最终结果(因为很多新需求都在后面的Release中),但是我们至少完成了我们在两周前所承诺的结果,客户得到他们想要的东西(当然不是全部),我们也可以很明确的告诉客户,我们完成什么样的需求。
而且在这样一个迭代的过程中,我们会发现很多需求中的不完善之处,每两周的时间我们都可以针对开发方向作相应调整。最终的结果是保证了客户的满意度,同时也保证了产品的按期交付。
在这里,我们需要明确的区分修改bug的需求和新功能的需求,bug应该是那些对软件主要功能造成决定性影响的缺陷,这些东西无论是我们开发人员自己发现的还是客户反馈的,都必须在当前的Release处理完;而新需求则必须放到后面的Release中去。明确区分这两种不同需求对软件项目的成功起到决定性作用。
第三:我们需要学会管理客户。可能有人觉得我在胡扯,客户怎么可能被管理,他们是上帝啊??!!其实上帝也是人,而且是通事理的人。我们对客户永远不应该是100%的服从,正确的方式是控制用户对开发进度的期望值,尽量使他们一致。当然有些时候我们需要更强硬一点点,比如我就经常很直接的告诉我的老板,这个需求属于新功能,必须放到后面的Release中去。
------------------------------------------