理论上来说,在项目终验前,整个开发团队会变得相当轻松,甚至有点无所事事的感觉。然而,总有个别的Team会打破这个规则,来证明软件开发世界里同样存在着多样性与特殊性。比如我们的项目,它就像一场马拉松赛跑,你从头至尾都不能松懈,否则就只能面临淘汰。
跑一场软件开发世界的马拉松是很多开发人员梦寐以求的事情,我们是幸运的,也是悲催的。幸运的是我们有机会跑一场像样的马拉松,并且跑完了全程。悲催的是我们选择的赛道并不那么平坦。世界上没有十全十美的事情,也就没有十全十美的项目。面对项目,我们必须坦然,也要释然。
尽管我们已经进入项目验收的末期,但我们却依然不能放缓前进的步伐。因为我们不是在修Bug,我们在处理客户的新需求。这是在项目中经常会出现的情况,也称之为补充合同。这里面包含的内容主要就是需求变更和需求扩展的内容。
如果需求一直在动,那么开发人员就要一直忙个不停,这也就是我们长期处于马拉松赛程的原因。
在处理需求时,经常是需求改动,开发人员行动,这是很正常的事情。但是如果发生了需求小改动,而开发人员有大行动时,这就说明了项目发生了问题,至少是在设计上出现了问题。一个良好的系统设计,应该能应对一定范围内的需求扩展。
在实际获取系统需求和制定系统设计时,由于客户在IT方面的不专业,导致他们对于系统的描述不精确,需求人员捕获到的需求也就不全面。而设计人员出于时间、范围等因素的考虑,往往做出最简易的设计,以便尽早交付。这就导致了客户在验收过程中,会提出种种问题。为了解决客户的问题,就必须修改设计。
其实,客户对于系统的挑剔性(简单、易用、响应快)就和我们对于各种工具的挑剔性一样。我们总是满世界里找适合自己的工具,并对这些工具吹毛求疵,因为我们是这些工具的客户。我们才不管这个工具在设计上有多复杂,我们只需知道这个工具能不能满足我们的需要即可。
作为IT系统的设计人,应该多为客户着想,多为开发人员着想,将系统设计的更灵活一些,别总让大家去跑马拉松。