几年前的某个时候,公司大伙都等着下班我却等着晚上加班,因为产品经理对产品的某个功能进行了调整和修改,我必须加班将其修改完善。对于这种事情我已经数不清了,产品经理的每一次变动都得让我们技术部门的同学们加班到深夜甚至到天明,如今回忆起来历历在目!今天这个文章我们不谈论是谁的责任,也不去抨击产品经理的无能,说说技术人员为什么总是在抱怨需求在变动这些事， 希望大家踊跃讨论。
一. 抱怨现象
最近我做了实施人员,经常到各个客户工厂去给他们实施项目,在这个过程中我了解到了软件的真实使用者,在这之间我就成为了客户和公司技术人员的传话筒,因为我本身也是做技术出身所以这样对消息的转化也就有了一定的优势。最近几次我在回来的路上一直再想同样一个问题,为什么技术人员总在抱怨需求的变动,之前我做开发的时候也是在抱怨,现在换了新人我给他们传话他们同样在抱怨，这是为什么？
案例一:
前面的文字中说道过给客户做的一个仓库电子看板,这个里面经历了几次较大的改动,每一次我回来给公司的技术人员反馈问题他们总是那么的不耐烦甚至抵触。
第一次给客户做的效果原型示例图如下：
分为两个部分，两个都是一样的只是显示内容不一样而已，一个是进料信息一个是出料信息。
第二次客户要求在下面添加一行文字:
这次添加的是下面的滚动文字，界面展示效果堪称不错，现场屏幕测试也完全OK。
第三次 客户要求下面的滚动文字可以替换,也可以不显示或者不滚动
第四次 客户要求字段显示的行数可以自定义
第五次 客户要求字段滚动的速度可以自定义
第七次 客户要求界面数据刷新数据的频率可以自定义
............
到了这个时候技术人员火了,MD天天改，天天这样改，有完没完？
案例二:
客户之前做统计报表都是Excel自己统计的,而且统计的还有模有样，在Excel中制作的非常漂亮而且显得非常专业，后来公司上系统了需要在系统中能够自动生成这样的报表,这里贴一个示例图看看客户的要求。
以上表格式Excel中的,客户要求在系统页面上显示一个这样的报表格式。因为使用者非技术人员之前就是一直用Excel这样做的，要求就是给他们做成如图的样子就可以了并且数据正确。
公司技术人员拿来之后一看这个报表也不怎么难嘛，很简单，数据在系统中都可以统计得到。
(1) 课题年份和获奖年份有啥关系
(2) 课题年份和课题数有啥关系,课题研究如果当年没有完成直到第二年才完成算哪一年的？
(3) 客户研究是以小组的形式来展开的，他们和小组是否有关系，表格中并没有体现小组的信息
(4) 课题和成果之间的关系是啥,怎么好像数量关系没有直接联系啊
(5) 课题和获奖是否有直接关系啊？
(6) 有了成果是不是就一定能够获奖啊？
..............
后来开发人员懵了，这是啥子需求哦，改一个不是这样的，该另外一个又不是这样的，客户又表述不清楚你想知道的东西，你确认一直认为客户所要的东西变了和第一次说的不一样啊！一个这么简单的表格到了最后花了时间，花了人力，最后结果还是一团糟.
二. 客户不清楚最终想要什么
以上两个案例都是最近我实施过程中的真实案例，我们用事实说话不做虚假假设。在最近的工作中类似的经历非常之多，这里只是举两个例子【我们这里说的是问题，如果哪位高人想说这表现出你们团队协作能力较差，或者公司整体能力不行等麻烦不要看此文了，这个问题不在此文章讨论，后续再说这些问题】。
案例一分析：
(1) 客户频繁的要求修改这些那些，说明客户自己本身也不知道需要做什么怎样的界面，界面需要展示什么数据。这是一个很正常的现象，如果客户这些都全部清除你也就只有码代码的份了，处理码代码的体力劳动你没有价值了。
(2) 很多要求是在现场展示的时候提出来的，说明客户很多时候就是随心所欲，甚至拿着手机看到了一个非常漂亮的东西也想往上面贴。
(3) 软件是否适用要在真正环境下才能校验"真伪",比如其中遇到的字体问题，在电脑上显示非常好，但是在大屏幕上显得非常小，远距离观看和近距离观看还是有差别的。
(4) 开发人员只是一味的跟着客户的节奏在走,客户说什么就是什么,说那里有问题就改哪里，最终代码没有结构性，满是补丁的可以勉强运行，只要再修改里面千疮百孔。
以上总结几点基本可以归纳出来在开发的过程中为什么会一直出现不停的修改，于是这也苦了开发人员，没办法那个谁说的"客户就是上帝"。
三. 开发人员未能真正理解需求
案例二分析:
(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留言了,因为不敢给客户打电话)
本文到此结束，文中所写只是个人经历和感受，不存在任何的偏见，可能和一些人的意见和想法有出入，但是不影响各位对此话题的见解！
