客户为什么习惯变更需求

看了一篇文章，提到这个问题，为何盖个房子，不会盖到中间提出改变设计，是因为用户知道那样做成本太高了，而软件则不同，在客户眼里，修改软件是很容易的事情。

不能说没有道理。那么问题来了，1.为何用户有这种看法？2.还有别的原因吗？

先说第一个问题。

一是，我认为，客户不了解开发过程。不像对传统行业的了解，比如盖房子，很多人都见过，而且看在眼里的都是实打实的东西，水泥，沙子，图纸，一帮子工人在脚手架上忙活，各种吊车，机械，隆隆作响，动静很大，甚至还搞得尘土飞扬。成没多久，大楼起来了，占很大地界，高耸云端，多带劲。很引人注意，傻子一听见或者看见，都知道前面是工地了。

软件开发就不一样了，首先，从视觉上看，就是一帮子呆子，坐在那里敲键盘，顶多开个讨论会，画画白板，需求调研也是局限在小范围，很少人能知道，没有这么大动静啊。这些过程的产出物就是一些文档，程序，而且还都是电子的，没有体积，看不见摸不着。

客户不了解开发过程，不知道需求分析的工作内容是什么，产品是什么，当然也不知道什么系统架构，什么jquery，什么测试，什么发布部署，反正是，你告诉他个地址，他上去，就能操作，就是1屏屏的文字。挺多能看到服务器，存储设备，但是这个与软件没关系啊，都是买的成品啊。而且价值有时候比软件要高很多。

不了解的原因，是看不到，专业型太强，缺乏沟通，进而缺乏认同。

再一个不了解的原因是，我们本身就不规范，不标准，自身不硬气，误导了用户。没有设计文档，么有测试计划，么有测试用例，写出来程序，简单跑一遍，没事，老子做完了，就OK。用户觉得也很简单，这不是很快就改出来了吗。岂不知隐藏着一大堆错误，羊拉屎一样要拖好长时间才能稳定下来，其实这些都应该算在开发成本里，但是客户不认啊，以为你做的有问题，修复错误是理所当然的啊，潜移默化的就把这块工作和先前的开发割裂开了：修改很简答（虽然一大堆错误）。

还有一个，市场人员甚至是最底层的开发人员，往往问题想的很简答，客户提个需求，提个变更，答应的很痛快：“没问题，分分秒搞定，就是加个判断的问题，去个字段的问题。你擎好吧！”。没有仔细想好，各种情况，是否会影响到其他人，是否需要变更设计文档，是否会带来新的问题等

。

第二个问题，我们换个角度，客户为啥要变呢？

前面是讲的客户认为变的成本很低，所以喜欢边，其实客户也不是闲的没事，没问题也让你变来变去，折腾人玩，没有这样的用户，么有这样的人。但是为啥会法神该变更呢？

1，需求描述不清楚，客户也不知道自己要啥。这是客户本身的问题，等你做出来，我不是要的这个东西。我是要个盘子，你怎么个我造了个碗呢。

2，开发人员理解错另外，本来客户说的很清楚，1是开发人员业务知识不够，理解不透，在一个自然语言，容易有偏差，经过几首后，已经面目全非了，以前电视上经常有个游戏，几个人拍在一起，第一个人做手势告诉第二个人什么什么事。然后第二个人同样的方式传给后面的人，到最后一个人的时候，理解的与第一个人锁表达的意思已经是风马牛不相及了就是这个道理。

3，在一个，用户需求确认发生变化了，此一时彼一时。怎么避免这种情况恩，就需要设计人员对用户需求抽象的足够高，可以以不变应万变。再也给是在调研室，就预期到可能的变化，挺过配置来适应。

最后一个问题，怎么解决这个问题呢。

以后再写吧。类了。