我之前说过需求管理有几个严格的要求，流程化和审核机制大家其实已经看到了，其实在某种程度上，审核是流程化的一部分，因为审核过程本身就是需求处理过程中一个过程而已，我们只要在流程中设置了这种过程，安排负责人去负责就行了，当需求进入这个过程，就自然有人会去审核了。

　　如果把上面两个要求看成是需求管理的基础的话，那其他几个严格的要求：欢迎变更、版本控制、可跟踪性，就可以看成是确保产品质量成功的关键点了。有了基础才有可能成功，有了关键点才能保证成功！

　　欢迎变更：

　　欢迎变更的重要性大家应该知道了，变更其实也就是需求经常变，从某种程度上也就意味着产品的质量下降，因为这个需求你不断变化，今天刚写好这段代码，明天要改成那样，后天又要大改，谁都知道有潜在风险，而且还有与之有关联的功能呢？你突然改了个接口参数，人家可能还不知道了。靠测试？测试人员也没法很好解决这个问题，因为今天刚测完这个功能，明天却大改了，但是那个测试人员虽然看到这个功能需要测试，但是他却可能认为昨天已经测好了，是不是忘记关闭了，所以就去测其他功能了。

　　那怎么解决呢？也很简单，当有变更的时候，

　　首先，尽量让相关的人知道，让开发知道，让测试知道，让需要我们接口的人知道，这样子大家就都会同步就完成自己要做的事情，不会出现需要做的人却不知道他要去做这个事的情况。在DevSpec中，我们可以采用变更自动通知功能来实现，因为在DevSpec中一个需求总是和它的开发任务和测试任务关联在一起的，所以当需求有了变更以后，只要发送一个通知，开发人员和测试人员就能马上看到变更，就能及时去做他们的工作了。

　　第二点就是，尽量把影响的范围搞得清楚点，让开发知道哪些地方可能会影响到，做的时候小心点；让测试知道这个改动会造成哪些地方有潜在的Bug，需要重点测一下。在DevSpec中，我们会有专门的功能让设计人员和开发人员注明影响到的地方，需要重点测的地方，而且这个功能可以设置成强制，只要有变更，设计人员和开发人员就必须注明，甚至可以要求测试人员也注明测了哪些点，可以让设计与开发人员检查是否有遗漏。

　　第三点就是，针对任何变更（特别对于瀑布模式那种公司），因为关系到了可能会影响质量、进度及成本，风险很大，所以对于变更的内容需要专门的评审流程，评审通过后才能开始开发。在DevSpec中，我们针对这种情况，就会经常启用变更管理视图，在这个视图中，会有特别的流程对变更做评审，在次期间，这个需求是没办法被任何人转到开发环节的，也避免了有些人不清楚情况，直接就把没审核的需求直接让开发去做了。（当然，我们现在很多产品已经是用敏捷开发的模式了，所以这个功能就用得比较少了）

　　这样子做的话，我们还是能把质量掌握在自己的手中，也就是把公司的前途掌握在自己手中。

　　（未完待续）