需求变更的成本为啥着这么高？

Posted 2021-03-17 senline

软件开发过程中，需求变更是不可避免的。

需求发生变化的原因有很多种

1，前期需求调研不充分，导致错误理解需求

2，客户对需求的描述，认识不准确

3，需求分析人员能力差，输出错误的需求

4，随着时间推移，需求确实发生变化

 其中，1和2是比较常见的原因。也是主要的原因。

 需求发生了变化，那开发是不是要进行调整呢？

答案是肯定的，软件的目的就是为了满足客户的需求，不符合客户需求的软件是没有价值的。

前期需求调研后，客户对需求的确认，并不意味着后期需求不能发生变化，需求评审和确认只不过是一种仪式，他可以促使客户相关方重视需求确认工作，而不是把它当成可有可无，形式化的东西。确认后的需求可以变更，但是需要走变更手续。代表需求的严肃性。

 需求的变更发生的成本到底有多大。对同一个变更，有人说很小，有人说很大，到底谁对谁错，如何评估。尤其是直接客户，会很不理解：我就提了一个简单的需求，怎么开发的周期这么长？

在实际开发中，客户提了需求变化，有的项目人员，甚至是开发人员就直接拍脑袋说了，小case，分分钟的事情，但往往事与愿违，实际交付时耗费的工作量成倍增长。

 我们以一个例子来讲解为何需求变化的成本高，为何需求变化的成本难以测量。这个例子中的大部分都是我N年前做的一个项目发生的真事。

一天客户过来说，希望能在组织表中增加一个组织简称。

为什么？是因为老大年纪比较大，眼神不好，电脑设置的字体比较大，组织表的字段有比较多，光组织全称这一栏就占了小半个屏幕。因为组织的全称是带了集团名字的，比如"▓▓▓▓▓集团股份有限公司人力资源部"，18个汉字。老大希望只显示"集团人资部" 5个汉字就行。

 这个需求合理吗，非常合理！在项目前期需求确认时，确认组织字段时给漏掉了，或者说没有人注意到这个事情。

 开发人员和客户简单沟通后，说不复杂，半天就加上（后来问时，开发人员说还有所保留，加个字段也就是10几分钟的事）。客户嘟囔了语句说，不就加个字段，还要这么长时间，好吧，我给领导说下。就走了。

 不大一会，开发人员说做好了，也测试了。

他做的工作就是：

1、在数据库中增加了组织简称这个字段：ZZJC，长度为10个汉字，

2、配置到系统元数据中

3、修改组织查看和变更界面，将组织简称放在全称后面，显示宽度为 10 。

4、测试无误

5、中午发布到生产系统

 然后，下午告诉客户改好了。客户看了看，说没问题，就是这样。

事情到此就为止了吗？

….那就好了。

 

第二天客户有跑过来了：“查询里为啥不能按简称查啊？”

开发人员：好好好，我马上修改“。这个系统，并不是表格里有什么列就可以按照什么列查询是需要配置的。打开快捷查询配置界面，需要配置查询配置id，增加上 简称的快捷查询。

下午，用户在qq上发来一个截图，说在组织人员表这个查询上，部门名称换成简称，否则查出来的报表A4纸打不开，太宽了。然后打开帆软报表设计器，找这个报表，没找到，因为在将报表注册到系统的时候，修改了报表名称，实际的报表名称与用户看到的不同，又打开报表注册功能，找到这个报表的实际名称，在设计器修改，修改数据源sql语句，在报表上增加列，保存，发布。完活。但是在系统中打开报表的时候，发现设置的宽度，不正确了，它按照页面自适应了。:(。原来报表设计器有个bug，一旦增加或者减少了列，他的自适应属性就变了。需要手工在修改过来。30分钟过去了。一张报表就为了增加一列，差不多1个小时。

其他报表呢，暂时不该了吧。（这个有为后边挖了个坑）。

 

下面列出了以后断断续续做的其他修改。

1、视图报错了。有一个视图用到了组织表，因为组织表的表结构变化了，导致整个视图状态为invalid，不可用，所以这个视图需要重新构建。为了保险起见，将所有的视图就检查了一遍。

2、日志没有记录对简称的修改日志，需要修改触发器。系统的修改日志时通过触发器来实现的，新增了部门简称，但是触发器没有同步修改，导致修改简称没有记录日志。

3、在人员编辑界面，也希望显示简称，而不是全称，没必要。

4、选择组织的所有窗口都要修改。因为要根据简称查找过滤。

5，接口。因为简称设置为不能为空，因此提供给身份系统的接口要修改，避免下发组织机构数据是出错。

6，说明书修改。

 

最后算下来，增加个简称，耗费了至少10个人天的工作量。按照￥2000/人天费用计算，一个看似很小的修改，带来的成本是 20000！

成本包括5部分：

1，沟通成本。需要和客户频繁沟通，以便充分理解需求，达成一致。不仅仅是直接需求，还包括间接需求（连锁反应）

2，开发成本（编码，测试，相关变更）

3、发布成本

4、文档变更成本（开发文档，手册）

5、变更管理不善带来的间接成本（频繁修改开发计划，频繁与客户沟通）

这还不考虑修改程序可能会带来的潜在的bug、修复bug的成本，以及带来的不良影响。

  

这个事情给我们的启示：

1、不要小看任何一个需求变更。

2、需要有经验的人员一起对需求变更进行的评估，评估的内容：需求的合理性，需求带来的连锁修改，所有修改的工作量。

3、需求评估完成后，要把评估结果与客户进行沟通，让客户理解需求变更具体内容，尤其是连锁反应，得到用户的认可与理解

4、小case，没问题这种话要谨慎。任何一个变更，在认真评估前，都不是小case。

5、开发人员不建议直接面对客户。尤其是一些菜鸟。