那么按照这个逻辑，软件研发的管理，也应该越来越厉害才对啊~ 然鹅……很多初级的软件项目管理问题，仍然困扰着我们。细想想，为啥大家嘴上一直说“管理很重要”，行动上却又不愿意为此投入呢？一张图告诉你！
我一直在想，在项目管理的众多领域里，到底哪一个，可以快速反应出管理改进的好处呢？项目经理帮我找到了答案。
这挺让我欣喜的，这正好论证了我们建立的PM核心能力架构的双支柱——过程能力和领导能力。
软件的需求哪有不变的，为啥需求变更让人如此“害怕”呢？控制变更的“变更过程”从概念上讲是比较简单的，但执行起来却复杂的很——因为需求变更驱动设计变更，设计变更影响代码，后面，测试可能发现进一步变更的问题，导致原始需求的变更……即使小规模的项目，参与变更的人员和工作量都大的惊人，如果不进行有效的管控，将引发不计其数的各种问题。
既然变是恒常，除了佛系一点，还能咋办？
变更是引入配置管理最为重要的原因。不能停止变更，就只能管好变更。变更的发生通常很“任性”，这就基本上明确了配置管理的跨度，将伴随整个软件生命周期。
由于配置管理，覆盖到了整个软件生命周期的全部重要产出，因此，它还能解决很多其他常见问题，比如：
- 需求、设计、编码、测试等工作产品的不一致性
- 无法找到软件的前一版本
- 产品升级和维护的时候，找不到软件的相关资料
- 编码未经测试，就集成到软件中，导致整个系统崩溃
- 谁都可以获取项目资料
- ……
列举的这些小问题，看起来都很“低级”，但小问题，一样要命。就是不久前，一个做大数据平台的同鞋跟我抱怨。项目组刚花了大量的精力修复了一个高难度的bug，测试也通过了，上线后，居然原来的bug又出现了。活见鬼！项目经理的电话都快被客户打爆了。大家又搞了三天才明白，原来是版本弄错了……
实操层面，我们应该参考能力成熟度模型集成CMMI里，对配置管理的实践要求。毕竟CMMI来源于全球顶级软件企业的优秀实践集成。
综合以上，对配置管理做一个系统梳理：
目的：在软件项目生命周期中，维持工作产品的完整性和一致性，减少由配置问题引起的混乱，提高软件开发生产率，降低成本。
核心：管理变更
关键实践：
- 最简易的配置管理——版本控制
- 配置管理策划
- 软件项目中到底什么应该受控？——配置项
- 符合项目需求的配置管理系统
- 建立和发布Baseline
- 配置管理真正的核心过程——跟踪和控制变更
- 软件开发过程的“库存盘点”——配置项状态报告
- 配置和QA的深度合作——配置审计
配置管理既然能够完整覆盖整个软件生命周期，以及所有重要的工作产出，可见配置管理并不是配置管理员一个人的事，而是与所有项目成员息息相关。它通过工作产出，将过程管理与人员管理关联起来。真的不能小看它哦~ 不然……
