需求控制组的构成

在软件项目中常见如下现象：

①用户提出了需求变更，市场人员答应了，开发人员认为工作量太大，不好实现；

②软件项目签订了合同，规定了价格，在后期的开发过程中，需求变更很多，变更的成本都是乙方承担，项目结束后发现项目做亏了；

③用户提出了需求的变更，开发人员直接修改软件，没有通知相关人员；

④用户张三提出了需求变更，开发人员修改了软件后，张三又认为不妥当，需要修改回去；

⑤用户张三提出了需求的变更，开发人员修改了软件，用户李四看到了，认为需求不妥，需要修改回去，张三与李四的意见没有统一；

⑥用户提出了需求变更后，软件开发人员只是做了局部的修改，有的功能漏改了；

等等，上述现象可以罗列出很多。

这些现象出现的原因都是因为缺少一个决策的机构对需求进行管理。

在敏捷方法中，可以通过现场客户或product owner实现需求的控制，但该角色需要满足如下的要求：

Collaborative：易于协作

Representative：具有代表性

Authorized：得到了充分授权

Committed：尽职尽责

Knowledgeable：熟悉需求

这种CRACK型客户是可遇不可求的，通常情况下，需要一个团队来实现上述的要求，这个团队一般称为需求控制组。

需求控制组是需求决策的机构，他负责对需求进行拍板，确定需求做还是不做，做到什么程度，开发的顺序等。需求控制组可以有哪些人构成呢？可以参见下图：

成立需求控制组，再定义需求变更的管理流程，则可以实现对需求变更管理的制度化建设。

需求变更管理的目的不是为了不让需求变更，而是希望需求能够有序地、一致地变更。

本文作者：任甲林 CMMI高成熟度主任评估师 麦哲思科技