需求变更管理你？还是你管理需求变更？

　　最近做外包有很多感悟，比较之前做产品的开发，外包显得更紧张一些，在时间上卡的紧。

有时候想好好的做一个具有高性能、高可维护性、高可扩展性的优雅的设计，可是到最后，发现总是在时间紧迫中草草的收尾，或者偏离初衷。

　　上司是个不爱技术的程序员~他的开发格言是用最普通的办法（最好不用设计不用思考抬手能做的办法），最快的时间干完活，交活之后啥都不用管，然后做下一个项目。

可以理解这是标准的向钱看的做法。

而我呢，总是对项目有一堆的想法要尝试，这种情况下时间观念上的冲突显得尤为突出，且不讨论谁目光长远吧，回归正题。

接下来想讨论的是，如何管理好需求变更，如何在我们紧张的项目时间上有条不紊的拥抱变化，在有限的时间内做更有意义的事。

项目变更的起因有很多种，比如：

• 新的业务或市场条件导致产品需求变更
• 新的客户需求，要求更改系统产生的数据、和系统提供的服务
• 企业改组扩大/缩小规模，导致项目优先级或团队成员变更
• 预算或进度安排限制，导致产品重新定义。

面对这样多的变化，首先我们应当摆正心态，坦然的接受变化，而不是抵触变化。需求变更存在整个软件开发周期之中，无论是前期设计开发，还是后期的测试验收，无处不在，如果你一见到需求变更就心烦，哈哈，那么，可以确切的告诉你一定是个天天不开心程序员。

那样的生活太黑暗了……

怎么样来改变呢，行之有效的处理各种变化是彰显我们设计能力的时候。什么的设计能力？设计高可为维护性软件的能力!

当变更发生，首先确认参与者职责。

职责：

在需求变更发生时项目经理的职责是：

• 通知变更：保证通知到每一个利益成员。
• 组织变更评估：评估必须所有共同利益者参与
• 做好记录: 防止日后没有查询依据，无法追溯。
• 跟踪变更进度

开发人员的职责

•  实现维护代码变更控制的技术
• 收集变更影响范围。
• 评估变更时间。

基线：在需求变更中一个重要的概念。

 　　随着时间流逝，所有参与者得到丰富的知识，这些知识成为了变更的推动力，并且造成了很多软件工程师难以接受的事实：

　　大多数变更是合理的！

在这样的情况下，我们就要制定基线。它能帮助我们在不阻碍合理变更的条件下控制变更。

有变的就要有不变的，所谓不变就称为架构。在成为基线之前我们可以随意的地变更。然后一旦成为基线，就像单向的门要经过全体参与者的评审。

优良的版本控制:

　　此处略，可通过使用版本控制工具解决。

最后送句名言同大家共勉：改进的艺术是在变更中保持有序，同时在有序中保持变更。