2013年6月工作小结-- 再论需求与设计，别总去跑马拉松

   理论上来说，在项目终验前，整个开发团队会变得相当轻松，甚至有点无所事事的感觉。然而，总有个别的Team会打破这个规则，来证明软件开发世界里同样存在着多样性与特殊性。比如我们的项目，它就像一场马拉松赛跑，你从头至尾都不能松懈，否则就只能面临淘汰。

   跑一场软件开发世界的马拉松是很多开发人员梦寐以求的事情，我们是幸运的，也是悲催的。幸运的是我们有机会跑一场像样的马拉松，并且跑完了全程。悲催的是我们选择的赛道并不那么平坦。世界上没有十全十美的事情，也就没有十全十美的项目。面对项目，我们必须坦然，也要释然。

   尽管我们已经进入项目验收的末期，但我们却依然不能放缓前进的步伐。因为我们不是在修Bug，我们在处理客户的新需求。这是在项目中经常会出现的情况，也称之为补充合同。这里面包含的内容主要就是需求变更和需求扩展的内容。如果需求一直在动，那么开发人员就要一直忙个不停，这也就是我们长期处于马拉松赛程的原因。

   在处理需求时，经常是需求改动，开发人员行动，这是很正常的事情。但是如果发生了需求小改动，而开发人员有大行动时，这就说明了项目发生了问题，至少是在设计上出现了问题。一个良好的系统设计，应该能应对一定范围内的需求扩展。

   在实际获取系统需求和制定系统设计时，由于客户在IT方面的不专业，导致他们对于系统的描述不精确，需求人员捕获到的需求也就不全面。而设计人员出于时间、范围等因素的考虑，往往做出最简易的设计，以便尽早交付。这就导致了客户在验收过程中，会提出种种问题。为了解决客户的问题，就必须修改设计。

   其实，客户对于系统的挑剔性（简单、易用、响应快）就和我们对于各种工具的挑剔性一样。我们总是满世界里找适合自己的工具，并对这些工具吹毛求疵，因为我们是这些工具的客户。我们才不管这个工具在设计上有多复杂，我们只需知道这个工具能不能满足我们的需要即可。

   作为IT系统的设计人，应该多为客户着想，多为开发人员着想，将系统设计的更灵活一些，别总让大家去跑马拉松。