2017年的一个笔记，记下来备忘
客户为什么习惯变更需求？
看了一篇文章，提到这个问题，为何盖个房子，不会盖到中间提出改变设计，是因为用户知道那样做成本太高了，而软件则不同，在客户眼里，修改软件是很容易的事情。
那么问题来了：
1.为何用户有这种看法？
2.除此之外，还有别的原因吗？
先说第一个问题，作为一个外行，用户为何认为修改软件是很容易的事情？
一是，我认为，客户不了解开发过程。不像传统行业，比如盖房子，很多人都见过，而且看在眼里的都是实打实的东西，水泥，复杂的图纸，一帮子工资在脚手架上忙活，各种吊车，机械，隆隆作响，动静很大，甚至还搞得尘土飞扬 。没多久，大楼起来了，占很大地界，高耸云端，多带劲。很引人注意，傻子一听见或者看见，都知道前面是工地了。
软件开发就不一样了，首先，从视觉上看，就是一帮子人，坐在那里敲键盘，顶多开个讨论会，画画白板，需求调研也是局限在小范围，很少人能知道，没有这么大动静啊 。这些过程的产出物就是一些文档，程序，而且还都是电子的，看不见摸不着。
客户不了解开发过程，不知道需求分析的工作内容是什么，产品是什么，当然也不知道诸如程序架构，什么jquery，什么测试，什么发布部署，反正是，你告诉他个地址，他上去，就能操作，就这么简单。挺多能看到服务器，存储设备，但是这个与软件没关系啊，都是买的成品啊 。而且价值有时候比软件要高很多。
不了解的原因，是看不到，专业型太强，缺乏沟通，进而缺乏认同。
再一个不了解的原因是，我们本身就不规范，不标准。没有设计文档，么有测试计划，么有测试用例，缺少可视化的文档和过程。写出来程序，简单跑即便，没事，就OK。用户觉得也很简单，这不是很快就改出来了吗，岂不知隐藏着一大堆错误，羊拉屎一样要拖好长时间才能稳定下来，其实这些都应该算在开发成本列，但是客户不认啊，以为你做的有问题，修复错误是理所当然，潜移默化的就把这块工作和先前的开发割裂开了。
还有一个是，市场人员甚至是开发人员，往往把问题想的很简答，客户提个需求，提个变更，答应的很痛快：”没问，分分秒搞定，就是加个判断的问题，去个字段的问题。“没有仔细想好，各种情况是否会影响到其他人，是否需要变更设计文档，是否会带来新的问题等鞥。
第二个问题，我们换个角度，客户为啥要变呢？
前面是讲的客户认为变的成本很低，所以喜欢变，其实客户也不是闲的没事，没问题也让你变来变去，折腾人玩，没有这样的用户，么有这样的人。但是为啥会发生该变更呢？
1，需求描述不清楚，客户也不知道自己要啥。一个是是客户本身的问题，在一个是我们需求调研的问题，没有问出用户真正想要的，等你做出来，客户说了， 我不是要的这个东西，我是要个盘子，你怎么个我造了个碗呢。重新做吧。
2，开发人员理解错误，本来客户说的很清楚，1因为开发人员业务知识不够，理解不透，在一个自然语言，容易有偏差，经过几首后，已经面目全非了，以前电视上经常有个游戏，几个人拍在一起，第一个人做手势告诉第二个人什么什么事。然后第二个人同样的方式传给后面的人，到最后一个人的时候，理解的与第一个人锁表达的意思已经是风马牛不相及了就是这个道理。
3，最后一个，用户需求确实发生变化了，此一时彼一时。怎么避免这种情况恩，就需要设计人员对用户需求抽象的足够高，可以以不变应万变。再也给是在调研室，就预期到可能的变化，挺过配置来适应。
那么问题提出来了，怎么解决呢。
1，标准化我们的开发过程。
2，做好与客户的沟通，是我们的产品，开发过程透明化，可视化。是客户实实在在看到我们的工作内容和工作成果。
3，让更多的人参与到项目中，通过各种形式，让开发过程可见，通俗点讲就是闹出点动静来，越大越好，越多人知道越好。
比如，
（1）定期与客户汇报项目进度，让客户了解我们做了什么，下一步需要做什么。工作量有多大；
（2）一起讨论解决方案，让客户深入到我们的工作中，了解问题的复杂性，实现细节，把后端的业务逻辑毫无保留的展示给客户，不要老浮在表现，处于旁观者的角色，得到对方的认同。
比如用户登录这个界面，看上去很简单，想着也不复杂。不就是我输入编号和密码，你到数据库中对比下，是不是正确吗？但是有真么简单吗？
（1），首先，要做一个登录界面，登录界面需要美工来美化吧。
（2），再者，登录方式，可能会支持多种登录方式，比如内部验证，外部验证，如果用域用户验证，就要访问域服务器，调用与服务器的验证接口。
（3），有时候，为了防止暴力攻击，还要设置随机码，随机码的生成算法，展示方式，时效性都需要考虑；
（4），账号和密码传输的安全性，是不是需要加密，采用什么加密手段，是不是需要数字证书和秘钥；
（5），后台验证的时候，还需要解密，还要检查弱密码。怎么检查弱密码，是不是还要有弱密码表？弱密码表怎么实现，正则表达式？长度控制？字符控制？常见词控制？
（6），还要检查密码更改周期，如果快到了，还要提示用户修改密码，密码超期了怎么办，怎么找回密码，等等。
所有的这些，都是客户看不到的东西，我们要想办法让用户了解隐藏在后面的这些内容，比如通过流程图，方案的形式给客户汇报。举个通俗的例子，就像种土豆，地面上看着就一个土豆秧子，不显山漏水，提溜出来，一堆土豆蛋子。
3，演示系统，
问题解决进度，项目开发进度表，使客户深度参与到开发过程中来。
对前面说的原因，比如需求描述不清楚，开发人员理解错误，客观上确实发生了变化。前两个原因没有好的办法，只能是使用一种有效的需求描述语言或者方式，吧需求清楚的出来，没有遗漏，没有错误，没有二义性。这个描述语言是n多软件工程大师奋斗终生的目标，比如uml。再一个通过需求管理手段，约束这种变更，是使客用户重视这种变更，减少变更随意性，比如走需求变更流程。确实需要变的，要体现在流程上，体现在工作量上，总之不能随意变，不能不明不白的变。