什么我大费周折地给你们介绍这个小例子，其实我想告诉大家的是：我们不需要将软件过程改进中关于变更管理和需求管理的过程看得过于复杂化，我们现在待改进的开发过程看似杂乱无章，其实它们是由于我们在开发活动中每个角色获取利益并规避责任后的本能反应，这些本能的反应活动构成了无序的结果，只要细心梳理这些活动，就可以形成为各自公司所用的变更管理和需求管理过程。
下面看看我们如何在软件开发背景中分析这个生活中的场景。
软件开发背景中的场景分析
首先在客户的电话来之前，我要满足的需求如表 1 所示：
需求点：
李明中午 2：00 到上海漕宝路 99 号拜访客户，进行 IBM Rational RequisitePro 产品的介绍。
当客户的电话打来要求调整会议时间时，意味着开发中的需求变更登场了，那么再来看看我在上一章中每句话的含义：
“不知道您会如何处理这件事情呢？” 如何处理变更？
“也许您会说客户是上帝，客户是甲方，只能同意。” 无条件接受变更。
“也许您会说没关系我可以等您，您先开会吧。” 无条件妥协。
“也许您会想：“我还不知道我在哪里呢，怎么回答客户呀” 既 不想接受，也不知道如何妥协。
“看到这里，也许您会想现在什么时间？离那里多远？我需要先知道这些才能回答呀。” 已经萌芽了一些分析需求变更的想法，准备分析并处理需求变更请求，很好。
那么我的每个步骤的含义又是什么：
步骤 1:首先让客户挂机稍等。然后直接给我们的销售人员小鲍，告知情况，征询如何处理。小鲍此时有另外的事情正在忙碌，让我自己看着办。 我提交客户需求变更请求，小鲍分配我去审核变更。（责任划分明确，避免不必要的责任纠纷）
拿到授权并规避完责任后，我需要判断是应该接受还是拒绝这个需求变更请求呢？下面分析步骤 2 和 3：
步骤 2:判断我现在在哪里。从车窗可以看到我现在正在漕宝路 139 号和 137 号之间。 从距离上分析，结论不远。
步骤 3:看表。现在 1：10，距离客户要求的 1：30 还有 20 分钟。 从时间上分析，时间充裕。
看似我们应该接受这个需求变更请求，但是从步骤 4 至 7 分析，我们又可以得出：
步骤 4:继续观察路况，发现堵车。怎么办？要是开飞经就好了，肯定没问题；要是想警车那样管路人借摩托车就好了；实在不成走路过去吧。 从实际进度分析，进展缓慢。希望通过引入新技术提高保障，但是新技术的引入风险大。
步骤 5:继续观察路况，当前正中午，夏天天气炎热，而且漕宝路两边树木非常少。如果步行，不仅自己被暴晒而且由于行路匆匆，大汗淋淋导致仪表不庄，最终还有可能被客户投诉。 从舒适度角度分析，舒适度差，并且很有可能舍弃舒适度拼命为了满足客户的变更还最终受到埋怨。
步骤 6:继续观察路况，需要穿过至少 2 个路口才有可能到达客户公司。步行不仅天气炎热，而且车来车往非常危险。 从安全性上分析，安全性差。
步骤 7:继续观察，发现堵车严重，出租车计价器不停计价。步行虽然省钱，但是因公坐车公司负责报销车费，成本不是大问题。 从成本角度分析，成本低。
于是现在脑海中形成了这样一个分析现象：
表格形式描述的需求点
| 需求点 |
新技术 |
安全性 |
成本 |
时间 |
距离 |
舒适度 |
| 李明中午 2：00 到上海漕宝路 99 号拜访客户，进行 IBM Rational RequisitePro 产品的介绍。 |
从时间和距离的角度看，我们会接受这个变更请求；
从安全性和舒适度的角度看，我们肯定会拒绝这个请求；
那我们到底优先关注的是哪个角度呢？我首要关心的是安全性，然后是舒适度，所以我选择了拒绝这个变更请求。当然您也许还有别的角度更关心，这就是仁者见仁，智者见智的事情了。对于门牌号这个小例子写了这
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
