软件工程之美学习笔记二十一 20 | 如何应对让人头疼的需求变更问题？

《软件工程之美》材料地址：https://time.geekbang.org/column/article/89848

需求变更是个麻烦事

程序员：“杀一个程序员不需要用枪，改三次需求就可以了！”
产品经理也觉得很委屈：“客户要改，我有什么办法？”

两个常见的解决方案

方案一：增强需求变更流程，让需求变更规范起来。
方案二：快速迭代，缩短版本周期。

为什么建筑工程中少有需求变更？

• 原因一：需求的确定性
  建筑需求是很具象的，而软件工程的需求是抽象的，导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更。
• 原因二：需求变更的成本
  建筑项目里面的需求变更，我们都很容易和成本挂钩，因为这些东西已经是生活常识了。而与此相对的是，很多人，包括很多老板都对软件项目需求变更导致的成本增加缺少系统认识。
  为什么美国的产品经理不敢随意更改需求？因为在美国很多 IT公司都是工程师文化，工程师相对比较有话语权，正常情况下是不会加班加点的，所以产品经理变更需求的成本很高，在确定需求时，必须慎之又慎。

如何解决需求变更问题？

一定要意识到需求变更是不可避免的。
1，提升需求确定性，把需求分析做好，减少需求变更；
这种方案的优势就是对需求理解透彻，后期返工少，缺点是对产品经理的需求分析能力要求很高。
2，提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求变更的目的。
这种方案的优势就是可以马上起到效果，缺点就是过于繁琐的流程不利于项目协作。
3，降低响应需求变更的成本，可以方便快捷地响应需求变更
这种方案的优势在于可以快速响应需求变更，能快速试错尽快调整，缺点在于对软件架构和项目管理要求比较高。

外包公司示例

第一步：规范变更流程，提升客户变更成本。
第二步：用原型设计低成本响应需求变更；做好需求分析和确认，减少需求变更。通过原型设计的方式，不仅可以方便地与客户沟通需求，还可以灵活响应需求变更。
第三步：通过灵活的架构和强大的配置，低成本响应客户需求变更。

我的留言

老师今天讲的现象，实际上是软件开发部门最头痛的事情。通过三个手段来解决需求变更问题，总结得太到位了。按照软件质量的金三角理论，需求变更，就相当于范围变大，必然导致成本上升或者时间增加，否则，就是质量下降。
比如说成本问题，由于业务领导对于软件开发没有成本意识，而且不考核他们的成本，所以他们可以随意变更需求，IT部门有苦难言。为了减少这个问题，我们尝试让业务部门在业务蓝图（需求）文档上签字，但对于强势的业务部门，依旧见效甚微。后来，又在发布频次上进行考核，减少发布频次。但结果又带来了用户真实的需求变更不能及时获得满足，直接影响业务。

业务变更是必然的，IT部门必须快速响应用户需求，这是摆在IT面前的必然挑战，无法回避。
真正掌握在IT部门的办法，只能是第三种选择：
“降低响应需求变更的成本”。
因此，我们开始建立统一应用框架(比如单体应用的java框架，微服务框架等）、建立CICD环境、推进云的建设，加快环境搭建速度，引入自动化质量工具，加快系统缺陷的检出速度，减少技术债务，甚至建立一些业务中台，加大业务的下沉力度和技术的上浮力度，加大技术和业务的复用，建立更高效的项目管理体系和工具平台，减少技术和业务的沟通成本。
但是这样的基础建设长路漫漫，见效很慢。不知老师有没有这方面的经验分享，比如采取哪些措施，优先级是什么，来达到降低响应需求变更的成本的目的，这里又有哪些困难，如何克服。等等。
老师回复: 基础建设方面我的一点建议：

基础建设困难在于短期内会减慢开发速度，是和业务冲突的，如果业务部门不支持，会很难推进，压力很大。所以可以考虑分成短期、中期、长期三类，逐步做。

首先，在不影响业务的前提下，优先做一些跟业务相关能短期取得正面效果的事，比如工具的使用，管理平台的搭建。这样取得效果后相当于为你自己积累了声望，以后推进其他事情会更容易。

然后推进流程规范的建设，比如CICD、代码审查，这类事中期可以取得效果，但也需要投入大量精力保障制度的执行。

跟开发相关的事是短期看不到效果长期的事，低调的做，一点点做，最好有专门的小团队做，比如你说的统一框架的事。这类事情阻力很大，因为既要兼顾新业务的推进，又要还大量精力对现有业务的改造。做成了绝对大功一件，没做成是要背锅的。所以低调一点，做成后再高调表表功，万一没做好或没达到预期就总结经验，下次再战，也不会导致太大影响。

供参考！