不定时炸弹

　　　　　　　　窖藏问题的威力

产品和开发讨论需求的时候，没有通知测试，也没有落实到文档中，测试不知道需求变化。开发提交版本测试最后的测试版本时才突然发现还有几个功能点没有测试。

Symbian开发组和服务器组讨论确定了一些计划外的变更，没有通知J2ME和WinCE，也没有落实到文档上。J2ME组和WinCE组按照最初商定的产品需求开发完成了，也连服务器测试了，提交测试版本后，测试有问题了，一问SUPER改了，多耽误事！

产品和Symbian开发组讨论商定的需求，Symbian开发组按照产品的要求改了，由于现在是一套产品需求对应Symbian、J2ME、WINCE等多个客户端产品，某些功能只对应了一个客户端，又没有落实到文档上，这样的功能点就很容易丢失。

现在这样的问题屡见不鲜,已经成为影响工作进度、延误发版时间的一个重要原因。只要能够在确定下来这些问题的时候，及时通知到相关人，或者及时详细地记录到相关文档上，这样的问题就可以很简单地避免掉，提高工作效率。

问题在产品中停留的时间越长修改的代价也越大，有调查表明其代价是呈指数增长。这个不难理解，软件开发只能根据现有的需求设计，在早期，比如需求分析和结构设计时，有可能只是在需求文档中添加几句说明，或者是修改一下设计结构，这是非常简单的。如果是详细设计或者编码阶段发生变更，变更的代价就相对较大了，有时需要调整程序的整体结构，重新编码，之前做地工作要重新再做一遍，工期延误了，工作白费了。

虽然有时也考虑一些将来可能的变更，为将来的变更预留接口，但这些并不是开发中主要方面，并且预想的变更和之后遇到的变更相差较大。并且只是留了个接口，省去了设计，功能的详细设计、与其他模块的交互，编码、测试等工作也是要做地。那些与其他功能模块有交互较多的功能代价越大。

有了变更及时通知相关的工作组调整是代价最小的做法，这些问题有应该尽早改掉，把这些问题都窖藏起来，就相当自己设定一个不定时炸弹，爆炸时间越长威力越大，但最终都要爆炸的。

这类问题纯粹是人为的，只要有那么一点全局意识可以避免，做的这个决定和公司的哪些部门有关系，对他们有什么样的影响？有能力做这些决定的人，应该有这样的全局意识！