授课视频2/3在线视频

说到需求呢，其实我们最痛心的地方就是

需求的变化

是我们心中永远的痛

首先呢，我们来看

需求是隐藏在用户和客户内心最深处的无形东西

就是说你看不见

而捕获呢

就是巧妇难为无米之炊

做开发，我们必须要捕获到用户的需求

这是跑不掉的

作为开发人员

我们对客户的需求

对他个人的了解程度会影响到我们对需求的把握

我们来看一看

在整个软件开发过程当中

有一个数据，25%

也就是说，用户有100个需求

其中25个需求可能会发生变化

这是一个典型的数字

我们再进一步看另外一个数字

因需求变更导致的返工的工作量

占总返工量的75%到85%

这个数字是相当高的

我们前面做完了

用户说要变更

发现前面白做了

这时候程序员和设计人员往往就比较崩溃

累死累活的

加班加点的

干出来的东西一下子就全废了，没用了

这个东西呢

有的时候我们说客户变需求太不人道了

你这么频繁的变需求

但实际上我们来看看啊

客户变需求

他为什么会变需求

其中一个最主要的原因

开始的时候

客户头脑当中只有一个基本的想法

随着他参与项目的时间越来越长

就是我们开发人员开始拿来个项目

我们也是一脸懵啊

我们也不知道怎么弄

一周两周三周

一个月两个月之后

我们对这个系统的理解非常的清楚了

客户也是这样

他开始刚有想法的时候

他也考虑的不全

随着一周两周三周

一个月两个月之后

客户对这个软件的理解也是越来越深了

那么这时候呢

他要改变更

这是很自然的

很正常的

也是应该的

不然的话我们软件开发出来之后

就达不到用户的需求

那么对需求这块呢

我们有一个很好的比方

叫做司机和汽车

我们认为客户是司机

开着一辆车，我是客户

我要确定目的地

我要去天安门

那么开发团队是什么

是汽车

现在我要去天安门

我走二环，二环堵啊

我得绕道，绕道的时候

没有方向盘，我怎么绕啊

车速你也不告诉我

温度也不告诉我

转速表也不告诉我

你想象一下，一辆没有方向盘

没有温度表

没有车速表的一辆汽车是多么的可怕

所以我们要强调，就是说

很多情况下，客户签了合同

打了首付款

然后他就去打高尔夫了

周游世界了

说我信得着你们

你们公司做软件开发很厉害

我出去玩去了

相当于说司机把自己的命交给汽车了

说你自动驾驶吧

我睡一觉

应该怎么做？

比较典型的就是有一个特派员

就是客户公司应该派一个人

比较熟悉业务的人

参与到开发公司和开发人员当中去

时刻盯着我们汽车的各种表

一旦发现偏了

跟客户心目当中理想的路线不一样

那么他能及时的制止，及时的沟通

所以说一个典型的情况是

我们做开发的客户公司派一个人来

和我们一起上班，参与进来

特派员

但现在呢

很多公司也不愿意这么做

第一呢，我开发的时候你老有人盯着我

我觉得很不爽

另外一个呢，客户说了

我派个人，我一个月给几千块钱工资

让他不干我自己的活

去帮你们盯着你这个仪表盘

他也觉得不合适

所以说这方面的思路是好的

但实际上呢很难做到

这一点呢，不同的公司

与公司规模，公司文化等等各方面有关

来灵活应对

经常变更，我们怎么办来应对这变更

我们不能被动的让变更毁了我们

这里面第一点，用户热衷于变更

因为变更能让他的产品变得更完美

这是没问题的，这是我们都支持的，都认可的

但是呢，如果客户没完没了的变更

最终这个产品会失败

所有说我们要告诉客户

你可以提变更

但你这个变更会引起进度和金钱成本

原来你说要10月份交工，OK

你要变更，我说你这一变

我们分析之后发现

在11月才能交工

你觉得怎么样

并且因为你这次变更

预算需要再增加10万块钱

也就是告诉他，你的成本是什么

然后他就会考虑了

如果我把10月交工变成11月交工

那么我竞争对手就提前上市

那么我损失的市场不可估量

那就算了

那他可能就会放弃这次需求的变更

这一点是非常重要的

就是作为开发人员

我们要评估用户的每一次变更带来什么样的成本

在我们的内部应该进行变更控制

变更控制属于配置管理方面的

配置管理实际上是一个保护伞

这个保护伞，让我们的开发团队

我们的开发活动更有序，减少混乱

所以说，配置管理

或者说配置管理里面的变更控制

是让我们的需求变更变得更有序

下面我们讨论一下

下面我们讨论一下

在我们的内部，往往会需要一个组织

叫变更控制组

叫变更控制组

简称CCB

这个CCB呢是一个权力很大的机构

这个机构呢可以是兼职的，不一定是全职的

但任务是对建议的这种需求变更做监管

就是说这个变更行不行

成本是什么，怎么做

要做一个审批和监督

下面是一个变更请求流程的伪代码表示

开始的时候

客户提起或者我们开发内部提起说

我要有一个变更

你可以填一张表，请求表

这个表呢我们要对它进行分析

如果变更成立

就是我们认为时间和金钱的增加

客户是认可的

如果变更成立

我们要找技术人员来估计这个变更怎么实现

技术上有没有问题

然后估算它的成本

然后将这个表送到CCB，就是我们的配置管理

如果CCB这个权力机构说

变更不错，跟客户沟通了

客户愿意承担这个成本和时间的负担

OK，那我们就实施

让开发人员去做

我们把它记下来

变更之后的软件呢

我们送到质量保证

专门有个机构负责质量保证

看质量能不能满足公司的要求

如果不满足要求呢，重复重复

最后质量达到要求之后呢

我进行入库，代码入库

这是一个基本的流程

这个表呢我们来看一看

项目名称，那个项目需要变更

有个ID，这个可以由管理员来做

变更请求，谁来请求的

什么时间，你为什么要变更

变更的描述

这个变更影响到哪些

优先级的问题，我必须，着急，马上

还是可以等下一个版本

评估的工作量

估计需要多少个人月或人日

就是3个人需要几天

这是分析的人员签字，一般是CTO

就是技术主管来做这个分析

分析完之后说，没问题，同意

然后审批，CCB负责人签字

审批同意

变更实施情况呢

技术组，就是技术组

开发组有负责人说我安排技术人员做完了

已完成，送到了质量保证

质量保证负责人签字

说质量达到了要求

所有的事情完成之后

送给配置管理员

配置管理员检查所有的资料

源文件啦，代码呀，文档啊

所有的配置项都完毕

然后入库，OK

这样的一个变更结束了

通过这种方式，让这个变更变得有序的和可控的

好，这部分就讨论到这里