放弃完美的需求管理

我当然晓得需求管理是怎么回事，我当然知道需求管理要做什么，我当然知道Telelogic的Doors比IBM的requisitepro的功能要强大，我当然知道在IBM和Telelogic的pk中，cc/cq的扩展功能要synergy/CM 和synergy / change的功能要强。

作为一个软件开发企业，需要的是什么样的开发平台呢？兴山总列举出：KMS 知识管理系统 、RMS 需求管理系统 、PMS 项目管理系统、CCM 配置和变更管理、DM 缺陷管理系统。不错，从各种角色的角度去看，它可能只需要一两个系统就够了，但是，别忘了现实生活中那些隐含的数据关系链，我更喜欢把这些系统看成是软件开发过程中的一个个的纬度。

我无意于去贬低或者抬高任何一家厂商，我相信他们也都明白，我说的基于一个核心数据库的多个纬度的展现是最好的实现方式，但是这样它们就挣不到几个产品(组合)的钱，所以，它们称它为理想状态。

没有搞错吧，既然这是理想状态，那我为什么还要因为你描绘的一点点的功能增强而放弃现有的开发规范和工具呢？因为在很长时间内，我们需要管理的是变更（流程）。IBM的售前问他的技术专家：他们这样用对吗？我很明确的告诉他：多年的工作模式已经形成了这样的工作习惯，而且现在市场的状况不会有任何的改变，所以也不会有太多的动力来指引决策层转变。只有适用不适用之说，没有对不对之分别。

其实说这样的话出来是很别扭的，如果我出去给我的客户做咨询，得到了这样的回答，我心里是不会好受的。但是，中国IT企业的现状就是这样，不要期望有太多的（传统型）IT企业会因为理想而去冒进。

我当然知道从理论上应该是先做需求的条目化和跟踪，然后再管理变更流程，我当然知道需求条目化后的属性会给我们的开发工作更大的帮助，我当然知道需求矩阵的手工维护量是比较大的。我只能说，那对做项目的软件企业来说，也是理想状态。

我是一个完美主义者，至少曾经是过，至少曾经有很多人说我是过，但现在我不是。

成熟，就是放弃完美，然后用比实际稍微超前一点的心态去工作。