最近做外包有很多感悟，比较之前做产品的开发，外包显得更紧张一些，在时间上卡的紧。
有时候想好好的做一个具有高性能、高可维护性、高可扩展性的优雅的设计，可是到最后，发现总是在时间紧迫中草草的收尾，或者偏离初衷。
上司是个不爱技术的程序员~他的开发格言是用最普通的办法（最好不用设计不用思考抬手能做的办法），最快的时间干完活，交活之后啥都不用管，然后做下一个项目。
可以理解这是标准的向钱看的做法。
而我呢，总是对项目有一堆的想法要尝试，这种情况下时间观念上的冲突显得尤为突出，且不讨论谁目光长远吧，回归正题。
接下来想讨论的是，如何管理好需求变更，如何在我们紧张的项目时间上有条不紊的拥抱变化，在有限的时间内做更有意义的事。
项目变更的起因有很多种，比如：
- 新的业务或市场条件导致产品需求变更
- 新的客户需求，要求更改系统产生的数据、和系统提供的服务
- 企业改组扩大/缩小规模，导致项目优先级或团队成员变更
- 预算或进度安排限制，导致产品重新定义。
面对这样多的变化，首先我们应当摆正心态，坦然的接受变化，而不是抵触变化。需求变更存在整个软件开发周期之中，无论是前期设计开发，还是后期的测试验收，无处不在，如果你一见到需求变更就心烦，哈哈，那么，可以确切的告诉你一定是个天天不开心程序员。
那样的生活太黑暗了……
怎么样来改变呢，行之有效的处理各种变化是彰显我们设计能力的时候。什么的设计能力？设计高可为维护性软件的能力!
当变更发生，首先确认参与者职责。
职责：
在需求变更发生时项目经理的职责是：
- 通知变更：保证通知到每一个利益成员。
- 组织变更评估：评估必须所有共同利益者参与
- 做好记录: 防止日后没有查询依据，无法追溯。
- 跟踪变更进度
开发人员的职责
- 实现维护代码变更控制的技术
- 收集变更影响范围。
- 评估变更时间。
基线：在需求变更中一个重要的概念。
随着时间流逝，所有参与者得到丰富的知识，这些知识成为了变更的推动力，并且造成了很多软件工程师难以接受的事实：
大多数变更是合理的！
在这样的情况下，我们就要制定基线。它能帮助我们在不阻碍合理变更的条件下控制变更。
有变的就要有不变的，所谓不变就称为架构。在成为基线之前我们可以随意的地变更。然后一旦成为基线，就像单向的门要经过全体参与者的评审。
优良的版本控制:
此处略，可通过使用版本控制工具解决。
最后送句名言同大家共勉：改进的艺术是在变更中保持有序，同时在有序中保持变更。
