需求相关：“请拿起你的奥卡姆剃刀”

需求相关：“请拿起你的奥卡姆剃刀”

----王珏原创

   这些年的项目经验，使我常常能够看到一些奇怪的“需求”，这些需求最后有导致了一系列奇怪的“设计”，这些奇怪的设计竟然还要进行“测试”，并且还要定期维护这些奇怪的功能。

   举两个例子作为开始。

   第一个例子是我遇到的一个“网络协议分析”项目，简单点说，就是通过分析网络上的各种协议（如：P2P，VoIP等等）来做进一步的工作（比如：阻断、干扰等等），具体这个项目有什么用，在此无需多说，其实很多路由器也在干同样的事情。由于此设备需要远程管理，因此竟然提出了“支持telnet远程控制”，“支持FTP”，“无人值守安装”等这样滑稽的需求来。我不反对这些需求，但这是操作系统的需求，而不是网络协议分析这个项目的需求；尤其在项目的前期，投入大量的精力来开展这样的工作，只能让我无语（当然这个项目的最后的结果是什么，也不是我们现在需要关心的）。

   第二个例子是“网管采集数据的历史数据删除（涉及到比较多的表）”这么个需求：就是定期删除Oracle数据库中保存的那些历史的网管采集数据。研发人员根据这个需求开发出一系列脚本，找出数据库中哪些表存在历史数据，哪些需要定时删除。为了支持这一系列脚本，又在Oracle里面建立了一系列的“表”用以保存相关数据。我很纳闷，删除历史数据本来是一个“维护工作”，为了让这个维护工作能够自动化，不仅仅搞出一堆需求和研发工作量，使得本来就已经晦涩难懂的Oracle结构又多出一堆的“表”来；最关键的是这些“自动化脚本”还需要另外的维护工作。作为“需求”，这个需求是不恰当的。作为研发人员，完全可以设计一个单独的脚本来完成“删除历史数据”工作，把这个脚本作为一个crontab任务，或者是Oracle的job来执行；这样可以有效的保持“项目核心结构”的简洁性。

   事实上，当我们善于运用“奥卡姆剃刀定律”我们就不会犯上诉错误了。

   奥卡姆剃刀定律，是由14世纪逻辑学家、圣方济各会修士奥卡姆的威廉（William ofOccam，约1285年至1349年）提出。奥卡姆（Ockham）在英格兰的萨里郡，那是他出生的地方。他在《箴言书注》2卷15题说“切勿浪费较多东西去做用较少的东西同样可以做好的事情。” 这个原理称为“如无必要，勿增实体”

   “为什么要将复杂变简单呢？因为复杂容易使人迷失，只有简单化后才利于人们理解和操作。随着社会、经济的发展，时间和精力成为人们的稀缺资源，管理者的时间更加有限，许多终日忙忙碌碌的管理者却鲜有成效，究其原因正是缺乏简单管理的思维和能力，分不清“重要的事”与“紧迫的事”，结果成为了低绩效或失败的管理者。从这个意义上讲，管理之道就是简化之道，简化才意味着对事务真正的掌控。”（参考：奥卡姆剃刀定律-MBA智库百科）

   上诉定律告诉我们：

   1、从需求角度来说:必须保持项目需求的简单明了，不要添加不必要的需求来增加项目复杂度。我的观点是：用一句话说不清楚的项目，都存在极大的潜在风险。

   2、从系统架构的角度来说：要保持系统架构的清晰明了。我的观点是：如果你不能用一页纸清晰的描绘你的系统架构，这差不多就是一个失败的架构。