需求又改了

张传波老师说：“人是会死的，需求是会变的”
作为程序员的你，是不是每个月总会有那么几天，感到莫名的烦躁？你找到真正的原因了吗？会不会是需求又变了呢？

客户需要的是一把梯子，系统分析员了解到的是一个凳子，开发人员做出来的是一张桌子，测试人员以为是一把椅子

很简短、粗暴，却很透彻的回答了“需求为什么会变”：“很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解不太一样”

需求是不断进化的

13年到15年奖金2年的时间，我的工作是负责开发和维护测试平台，公司有多个产品，每个产品都有部分需要不断重复枯燥无味的测试工作，通过自动化测试来执行

xx型号配置工具

开发人员或者测试人员在把设备接入管理系统之前，需要对设备做一些配置工作，我们开发出来了一个脚本，专门负责写配置信息到设备

更多的型号

随着时间的推移，新的型号产生了，有了新的配置项，相同配置项的值也不一样了，经过思考，做成了“给出几个常用的配置项，可以动态的新增或者删除配置项，也可以修改配置项的值”，自认为很完美的解决方案，经过测试后，发布到技术支持部。很快就派上用场了，技术支持的同事需要出差给客户的安装配置设备并接入管理系统，他急急忙忙的跑到我座位边上来让我教他使用我们的软件配置设备信息，我很惊讶，这么简单还需要教吗？看一看就懂了啊。然后我就从启动软件到点击xx按钮，再点击xx按钮，配置信息面板出现在了我们面前，你再根据你要配置成什么型号决定配置项，并设置配置项的值，点击OK，就好了
“额…，这个型号跟配置项的关系从哪里来啊？”
“啊？你是技术支持，对公司的型号不应该很清楚吗？xxx文档也有详细记录的”
“这样啊，我们这次去现场需要配置某某型号，要不你教我怎么操作吧”
“……，好吧，先选择xx，……，yy配置项， 设置配置项xx的值为vxx,……,yy的值为vyy，点击OK就可以了”
“我拿本子记一下”

这太难用了

他一定想说：这软件太难用了。我不得不重新思考软件的实现方式，最终的解决方案是：命令执行器+命令集。命令执行器就好比linux系统，可以执行很多的命令；命令集就好比是shell脚本。命令执行器写好之后，再根据技术支持、测试、开发人员的需求来编写命令集，比如前面提到的，型号A的配置命令集，型号B的配置命令集等等。再使用时只需要选择命令集确定即可搞定

总结

用户对于需求的理解是在不断进化的，这种进化可能发生在使用软件的过程中，也可能在看到其他软件某个很漂亮的实现，有太多太多的因素会导致客户对需求有新的认识，除非一开始客户就对理解的非常透彻，才能做到一锤定音，否则“需求是一定会变的”

需求分析的目的

某公司为了解决出外勤的同事中午回到公司能够吃上饭的问题，领导决定成立一个开发小组实现短信订餐的功能：
1. 出外勤的同事可以通过短信订餐，订餐前可以查询菜单
2. 请假的同事可以通过短信取消订餐
开发小组风风火火忙碌起来了，搭建环境，购买设备，购买短信平台账号，软件开发完成，但有时候会出现短信接收不到的情况，是我吗的软件问题？短信平台的问题？还是运营商那边出问题了？有太多的不确定因素了，总之就是很难解决
这是一个同事问了一个问题：“出外勤或者请假的同事打电话从前台订餐或者取消订餐不行吗？”

是呀，打电话告诉前台不行吗？
在上面的例子中，老板就是软件的客户，客户遇到的问题是：“出外勤的员工需要订餐，请假的同事需要取消订餐，避免浪费”，客户给出了一个解决方案：“短信订餐系统”
开发小组就相当于软件公司，他们从“短信订餐系统”出发，开始解决一系列技术上的难题，历经千辛万苦做出了一个偶尔会失灵的系统
“软件有什么用？”
“解决客户的问题。是客户问题的一种解决方案的具体实现”
“那客户的问题是什么？”
“出外勤的员工需要订餐，请假的同事需要取消订餐，避免浪费”
“那短信订餐系统呢？”
“哦，这是客户提出的一个解决方案。…….，哎呀，我们错把客户的解决方案当成了客户遇到的问题了，而没有去评估解决方案的必要性，是不是最优的解决方案”
分析客户遇到的问题，并寻找一种最优的解决方案，要从问题出发