工作感言：挖掘需求
大学的时候，跟着老师做项目，但是没有一个项目是按时间完成的（有的项目压根就没有明确的时间），每个项目都是做到一定的阶段（也有可能是快到交赴时间了），给客户演示一下，然后由客户提意见（有时甚至会把前面的需求都推倒），如此反复，最后客户就将就着用（加上一定的维护），不了了之就算是完成了。
当我在公司里主持开发一个项目的时候，才真正感受到需求不清带来的巨大痛苦。当要做一个项目的时候，客户向我描述他的需求，然后我把这些需求形成文档，设计，等开发到一定阶段，让客户看一下我们的进度，再提一下意见；这一看真是乱了套了，客户看了之后总是能提出“新”的需求，我们再改，客户再看，再来“新”的需求......搞得我一头的包，感觉这项目真是个无底洞、无尽的需求，真是苦不堪言。有时我真想骂客户：你怎么回事嘛，你就不能一次把需求说出来，你在玩我呀？
怨气归怨气， 为什么用户总是不能完整地描述需求，为什么我们一次次给客户演示未完工的系统，仿佛是一次次在给客户追忆他的需求？客户在看了之后，往往会提出新的需求，通常有以下这两种情况。
1，客户往往只描述他认为很重要或很关注的需求（功能），对于他们自己认为“理所当然”，“本来就是这样的”，“当然要有的”的功能一言带过或只字不提，但这些功能往往是必不可少的，我又不是这个领域的专家，客户认为理所当然的东西我却一无所知，当系统成形时，客户一看没有，这自然就是“新”的需求了。
2，客户描述需求随意发挥，缺乏严谨。具体表现在流程描述上自身本来就考虑不周，当发现特殊情况不能满足时，这又是一个新的需求了。
经过以上的总结，我发现记录客户描述的需求只是获取需求（需求分析）的一部分，更多的技巧则在于挖掘用户的需求，对客户的需求挖掘得越记充分，后面我们的工作将会越轻松，在实践中我总结出以下几种方法：
1，学习一定的相关知识，找出“理所当然”，“本来就这样的”等隐式需求。方法有：找相关领域的书藉，通读一下，找相关的系统（GOOGLE，BAIDU一下，肯定有不少），自己动手实践一下，费了以上的功夫之后，一般可以找出不少这样的需求，不要怕麻烦，记下来，去跟客户交流一下。
挖掘需求1：质检出了问题，即采购数量<申请数量（采购部只能按申请数量采购），满足不了申请人的需求，怎么处理，客户：这样情况下次当然是同样供应商下次供货时顺带把要补给我方的数量一并发过来，客户认这是很自然的，他的企业一直都是这样操作的，理所当然的事。
挖掘需求2：当情况紧急时，是待下次采购一并发过来，还是马上让供应商补过来，客户：这还用说，当然是马上让供应商把货单独送过来。
2，多推敲流程，多问自己几个为什么，看能否自圆其说。客户讲业务流程时一般只讲主流程，分支流不太提起，这部分要多加注意。
挖掘需求3：即然采购到货物品会有一些有质量问题，为了满足申请的数量，采购时是不是多加一点较合适；客户：是这样的。
挖掘需求4：多采购数量依据来自哪里？客户：统计供应商的货品合格率。
3，多与客户交流，一般客户有多人的话，可以先整体交流一次，然后逐个交流，形成文档，逐个确认，整体讲解，客户有问题的话，再交流，再形成文档，再确认，再讲解，如此反复，直到需求清楚为止；一般如此反复3次左右即可解决问题，这方法说起来容易，实际操作起来需要有耐心，吃得了苦，不怕麻烦。不要急于开始编码（这个错误我犯了真不少），需求不清，编码就是做负功，编得越多，后期改得越痛苦（我前期做项目就是做成了这样，苦呀）。
以上图为挖掘需求后所得到的流程图，是不是比客户原来说的多了很多，假如不去做这些工作，仅仅是按客户的说的来做系统，在中间再把这些需求一个一个加进去，是不是我们又该暗骂客户了？（说明：该流程只是我为了举例拿出来的，本身也有很多不严谨，不能自圆其说的地方，不必太过较真，知道我要说的意思即可）。
我运用此思路整理过最近两个项目的需求，100%完全抓住客户的需求当然是做不到的，能够抓住客户85%以上的需求是没问题（还要看做需求分析的时间是否充足），其中一个项目我花了将近半个多月整理需求，当时客户看了就比较满意，开发完成（花了一个半月）后给客户演示，大的功能客户基本满意，但还是客户还是追加了五个小功能（汗），但不伤筋动骨，都是些小功能，大概又花了一周来加上去，即可交付，想想之前的辛苦也是值得了。在痛苦地应对多变的需求中挣扎了许久之后，终于摸到点小门道了，与大家一起分享。
当我在公司里主持开发一个项目的时候，才真正感受到需求不清带来的巨大痛苦。当要做一个项目的时候，客户向我描述他的需求，然后我把这些需求形成文档，设计，等开发到一定阶段，让客户看一下我们的进度，再提一下意见；这一看真是乱了套了，客户看了之后总是能提出“新”的需求，我们再改，客户再看，再来“新”的需求......搞得我一头的包，感觉这项目真是个无底洞、无尽的需求，真是苦不堪言。有时我真想骂客户：你怎么回事嘛，你就不能一次把需求说出来，你在玩我呀？
怨气归怨气， 为什么用户总是不能完整地描述需求，为什么我们一次次给客户演示未完工的系统，仿佛是一次次在给客户追忆他的需求？客户在看了之后，往往会提出新的需求，通常有以下这两种情况。
1，客户往往只描述他认为很重要或很关注的需求（功能），对于他们自己认为“理所当然”，“本来就是这样的”，“当然要有的”的功能一言带过或只字不提，但这些功能往往是必不可少的，我又不是这个领域的专家，客户认为理所当然的东西我却一无所知，当系统成形时，客户一看没有，这自然就是“新”的需求了。
2，客户描述需求随意发挥，缺乏严谨。具体表现在流程描述上自身本来就考虑不周，当发现特殊情况不能满足时，这又是一个新的需求了。
经过以上的总结，我发现记录客户描述的需求只是获取需求（需求分析）的一部分，更多的技巧则在于挖掘用户的需求，对客户的需求挖掘得越记充分，后面我们的工作将会越轻松，在实践中我总结出以下几种方法：
1，学习一定的相关知识，找出“理所当然”，“本来就这样的”等隐式需求。方法有：找相关领域的书藉，通读一下，找相关的系统（GOOGLE，BAIDU一下，肯定有不少），自己动手实践一下，费了以上的功夫之后，一般可以找出不少这样的需求，不要怕麻烦，记下来，去跟客户交流一下。
挖掘需求1：质检出了问题，即采购数量<申请数量（采购部只能按申请数量采购），满足不了申请人的需求，怎么处理，客户：这样情况下次当然是同样供应商下次供货时顺带把要补给我方的数量一并发过来，客户认这是很自然的，他的企业一直都是这样操作的，理所当然的事。
挖掘需求2：当情况紧急时，是待下次采购一并发过来，还是马上让供应商补过来，客户：这还用说，当然是马上让供应商把货单独送过来。
2，多推敲流程，多问自己几个为什么，看能否自圆其说。客户讲业务流程时一般只讲主流程，分支流不太提起，这部分要多加注意。
挖掘需求3：即然采购到货物品会有一些有质量问题，为了满足申请的数量，采购时是不是多加一点较合适；客户：是这样的。
挖掘需求4：多采购数量依据来自哪里？客户：统计供应商的货品合格率。
3，多与客户交流，一般客户有多人的话，可以先整体交流一次，然后逐个交流，形成文档，逐个确认，整体讲解，客户有问题的话，再交流，再形成文档，再确认，再讲解，如此反复，直到需求清楚为止；一般如此反复3次左右即可解决问题，这方法说起来容易，实际操作起来需要有耐心，吃得了苦，不怕麻烦。不要急于开始编码（这个错误我犯了真不少），需求不清，编码就是做负功，编得越多，后期改得越痛苦（我前期做项目就是做成了这样，苦呀）。
我运用此思路整理过最近两个项目的需求，100%完全抓住客户的需求当然是做不到的，能够抓住客户85%以上的需求是没问题（还要看做需求分析的时间是否充足），其中一个项目我花了将近半个多月整理需求，当时客户看了就比较满意，开发完成（花了一个半月）后给客户演示，大的功能客户基本满意，但还是客户还是追加了五个小功能（汗），但不伤筋动骨，都是些小功能，大概又花了一周来加上去，即可交付，想想之前的辛苦也是值得了。在痛苦地应对多变的需求中挣扎了许久之后，终于摸到点小门道了，与大家一起分享。
