在我们公司，获取了一个需求以后，

首先，相关人员会先在DevSpec建立一个条目，添加相应的一些属性信息，比如标题，内容描述，状态，对应文档，优先级，紧急程度，负责人，对应版本，对应浏览器，对应数据库等等。。。

提交完了条目以后，由于这个条目设置了一个负责人，所以那个负责人登录系统可以马上看到自己名下有这个条目，他会马上去处理这个需求。（可能有些人没登录系统去看，我们也可以设置Email或者手机短信的自动提醒功能）

这里提到的“负责人”，在不同的过程里，负责人都是不同的，比如“评审”阶段有专门的评审负责人，普通人无法成为评审负责人，哪些人在哪些过程里能成为负责人是可以在流程中设置的。而上面提到的提交完条目后，一般情况第一个过程是要审核刚获取的需求，负责人审核通过后可以把这个需求从“审核”状态改到“需求分析”阶段了，当然负责人也会改变，“需求分析”过程的负责人会马上知道自己有事情干了。

这样，经过一个一个的过程，经手了一个一个的负责人，这个需求逐渐从一个只有一个思想，到有了轮廓，再设计出里面的框架，然后后被实现。

其实，大家都是这么来处理需求的，不同的是，我们通过一个工具来管理这个过程，而有些公司只是人工来做一下。我们这么做，好处和坏处其实都有，正如之前有个客户问，你们这么做的话，是不是每一个需求的处理效率会降低？对，的确会降低，我们承认，因为这些都是严格的流程，而且是在一个系统中管理，肯定没有他们口头直接说一下快。但是，我们考虑的是我们是在卖产品，牺牲一部分的效率来确保产品的质量，我们觉得划得来，毕竟质量才是重要。人家虽然速度快，但是问题也来得多，需求多的时候，这个忘做了，那个做错了，或者相互责任推来推去的事情多着了，终导致产品质量出问题的事情比比皆是。但是我们用了系统以后，避免了这些事情，实践也证明了我们这么做以后，产品质量是得到保证了的。

当然，产品的质量也不是简简单单像我说上面说的“经过一个一个的过程，经手了一个一个的负责人”能马上实现了，这里还会涉及到很多细节注意点了，待我一一道来。

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

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

欢迎变更：

现在已经不是从前了，对于需求的变更而言，想必大家都能理解了，特别是采用敏捷开发模式的公司，大家都在比快速变化，变得慢可能被淘汰。

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

不过，我们也知道产品的Bug是任何人、任何公司都没法避免的，连微软这种大公司，Windows都有这么多大Bug，所以我们要坦然面对Bug，对于需求的变更，也需要坦然面对。不过坦然面对不意味着撒手不管，起码我们要把Bug控制一定范围内，起码客户用了不会有很严重的问题，起码用着能流畅着做完普通的事情。

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

首先尽量让相关的人知道，让开发知道，让测试知道，让需要我们接口的人知道，这样子大家都会同步完成自己要做的事情，不会出现需要做的人却不知道他要去做这个事的情况。

第二点是，尽量把影响的范围搞得清楚点，让开发知道哪些地方可能会影响到，做的时候小心点；让测试知道这个改动会造成哪些地方有潜在的Bug，需要重点测一下。

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

而这个措施实际在DevSpec中，我们是用变更自动通知功能来完成的，效果很好，开发、测试、设计人员都能看到自己任务在其他部门中的情况，一有变更立马知道。