三. 开发人员未能真正理解需求
案例二分析:
(1) 技术人员太小瞧了一个简单功能的开发.这里我一定要将这个排到第一点,个人觉得这是态度的问题，对于问题处理的态度问题。
(2) 技术人员对给出的浅显得需求未能去深入挖掘，不然不会到了开发过程才发现年份之间关系有问题。
(3) 非专业人士的表达不能够理解是因为技术人员没有站在使用者的角度去想这个问题并且表达出来(我承认这个有点难度,但是作为有价值的的技术人员必须学会这么做)。
(4) 发现问题没有去归纳总结，而且没有及时去反馈问题，也没有去沟通问题。
四. 案例分析总结
以上单独分析了两个案例，一个案例问题出现在客户这边，一个案例问题出现在开发人员这边，我这里暂且这样划分。
总结一下导致需求变动的原因:
(1) 客户本身不清楚自己具体要做成什么样子,而且客户的想法较多
(2) 客户现场的真实环境导致你某些程序不能满足(适应环境,有机会影响环境,生物的适应性)
(3) 客户不能正确表述他所要的东西,虽然他心里非常清楚想要这个,和程序员一样语音组织表达能力较差(实际上需求没有变,表述不一样理解不一样)
(4) 开发人员小瞧了简单的业务需求,没有深入去挖掘潜在的问题和需求,问题最终逐步暴露出来
当然需求的变动还有很多其他的原因，比如市场的需求变动，客户操作习惯的变动,业务的发展变动这些都会直接导致程序需求的变动,以上的原因导致的需求变动就足以让技术人员叫苦不迭了。
五. 技术员能不抱怨么
说来很奇怪,我一直认为技术人员就是”很奇怪的动物”，从开始工作的那个时候开始走到哪里都能够看到抱怨的程序员，没有一个公司的程序员对需求变动不抱怨的，但是最终抱怨之后还是默默的修改变动的需求，说明程序员都是善良的！偶尔会抓狂但是他们还是会默默付出。
对于后来我介入了这两个功能的开发,并且做了一些工作来调整这样的状况:
案例一中我自己在纸上罗列一些环境和硬件清单:
1. 客户屏幕分辨率使用的是1280*768,最大分辨率支持1990*1280,刚好公司有这样一个屏可以模拟测试。
2. 客户使用xp系统(使用的工控机,没得办法),那我们也安装一个xp系统，虚拟机就好[建议尽快抛弃xp系统,这个系统现在的确非常头疼]
3. 远距离看屏幕字体大小,不要在电脑屏幕上看
4. 需要自定义动态设置的参数全部罗列,显示数据行数,字段数,刷新频率,翻转时间,滚动文字等等，每一个都具体在纸上罗列，然后对着去实现
5. 问题分析主次,画好数据传输的逻辑图,问题优先级分等级，哪些问题是有关联的，程序层次关系等等
6. 交给另外的人员来测试,没有参与过开发的(很是惭愧我公司没有测试人员)
案例二中我给开发人员指出一下几个问题:
1. 课题年份和获奖年份的关系， 我先假设几种关系，使用穷举法：
(1) 课题研究是否获奖要到第二年才确认，甚至是第三年
(2) 课题研究是否获奖一定是在第二年确认
(3) 课题研究是否获奖一定是在当年确认
(4) 课题研究和是否获奖本身没有任何关系
2. 课题成果和获奖之间的关系，同样先假设几种关系,使用穷举法:
(1) 课题研究有成果就一定能够获奖
(2) 课题研究有成果可能能够获奖
(3) 课题研究成果和获奖没有关系
.........
上面是简单罗列的问题,我相信如果你能够将这些问题罗列出来，说明你解决问题的思路已经非常清晰了，这个思路和技术无关，也就是你已经明白你要做的东西了。同样你清楚这些东西那么你就很容易去有的放矢，针对具体的问题解决问题，而不是盲目的去修改代码然后编译一次交给实施人员去给客户看行不行。对应客户自己本身不能表诉那么你就从他表达出来的内容拆分几种假设，然后你可以以你的专业语言去描述给他听，他自己要明白你描述的是否是他想要的东西问题就解决了。
我当然知道技术人员的抱怨是必比不可少的，我工作也有些年了，到现在还避免不了偶尔去抱怨一下，就跟家庭生活一样偶尔也会有烦心和不愉快的时候，如果你坦然去接受面对这些问题我相信你会从容很多。
六. 总结
(1) 永远不要奢望客户清楚的告诉你他们想要什么东西，更加别异想天开的他们会给我们整理一份非常完美的需求文档(如果有客户为你做了很好的一份需求文档，那是因为你的善良感动了上帝)。
(2) 客户的问题是你发挥自己能力和体现价值的时候
(3) 好的程序层次结构，代码的健壮性能够很好的应付客户需求的变动
(4) 你和你的程序一定要比客户想的多，而不让客户为你想更多的问题
(5) 深入挖掘客户的需求，这个不会让你吃亏的，挖掘需求也有很多办法，只要你真的再为客户想问题那么解决问题的方式一定很多
(6) 没有一层不变的需求，也没有完美的客户，更加没有完美的个人，要坦然面对工作中的问题
(7) 沟通是解决问题的最好最直接的方式,直接打电话不要使用QQ发消息留言(最反感QQ留言了,开发人员最喜欢QQ留言了,因为不敢给客户打电话)
