由“我要吃饭”的故事想到的

　　某天某客户跟你说：“我要吃饭!”

　　你非常关注客户这个需求：“请问您要吃中餐还是西餐呢?您想吃什么呢?”

　　客户非常开心，一下子说出了很多想吃的：

　　“西餐嘛，不错，听说那个菲力牛排很不错，配上红酒更加美味!”

　　“不过听说某某路的那个潮汕牛肉丸火锅，牛味很浓，牛气冲天……”

　　“哎呀，最近上火，还是不吃这些上火的东西了，吃日本寿司吧，听说那里有日本菜自助餐，有生蚝，正啊!”

　　“啊，不行哦，最近日本核辐射，海鲜还是不吃了”

　　……

　　最后客户说：

　　“你还是先弄一顿给我尝尝吧，见到菜才能提出具体需求啊!”

　　遇到这样的客户，你可能想找10个馒头塞到他嘴里面，让他撑饱，搞定!

　　以上故事纯属虚构，如有雷同实属不幸!

　　这个故事是软件项目需求工作的缩影，客户的表面需求似乎很多，而且变来变去，很可能是因为我们没有抓住“我很饿”这个根本需求。客户可能提出很多匪夷所思的需求，提出一些超出自己预算范围的需求，如果我们能抓住客户的根本需求，让客户认识到自己的预算限制，再加上我们高水平的发挥，我们是有可能做出能满足客户根本需求，并且符合预算的软件系统。

　　需求分析与需求管理

　　我们可能经常听到一些关于需求方面的说词，如：需求开发、需求分析、需求调研、需求管理等等，下面将这些概念稍微梳理一下。

　　1)需求分析：

　　其他说法：需求调研、需求开发

　　关注点：如何获取和确认需求?

　　2)需求管理：

　　“双赢”：客户能赢，我们也能赢!在“双赢”的基础上，处理以下问题：

　　a)如何签署需求?

　　b)如何处理需求变更?

　　需求驱动地工作。

　　a)用需求指导计划、设计、编码、测试、实施等工作。

　　b)不做或少做与需求无关的事情。

　　需求分析和需求管理的工作，我统称为需求工作。需求工作中的问题有些是需求分析的问题，有些是需求管理的问题，或者是两者兼而有之。

　　法则1：搞清楚需要

　　解决肚子饿的问题，是客户的根本需求，客户的根本需求或者说需求之源泉，我称之为需要!如果客户是公费吃喝的，嘴馋想吃东西，那么满足这个需要的做法又不太一样了。

　　客户一般不会直接说出需要，往往提出的是他自认为能解决这个需要的某种解决方案。“我要吃饭”只是表面需求，透过这个表面需求，找到需要是需求工作的根本!我们需要思考：客户为什么有这样的要求?客户希望解决什么问题?如果找到客户的真正需要了，那么我们需要进一步思考：有什么简单的方法可以满足客户的这个需要?

　　客户的需要其实很少会变的，变的是那些表面需求，多问问我们自己：我们抓住了客户的需要没有?有些客户对自己的需要很清楚，但有些客户可能只有朦胧的想法，我们需要总结出客户真正想要的东西并与客户确认。

　　法则2：搞清楚限制条件

　　10块钱解决肚子饿的问题，和100元解决肚子饿的问题，差异可以很大，所谓的看钱吃饭!

　　如果我们能搞清楚客户的需要，其实10块钱也可以有比较完美的解决方案的，可以去大排档吃个面、炒粉之类的，不是不可以的。某牛筋丸汤粉，才10块钱，但有8个牛筋丸，味道好极了，而且可以饱肚子!

　　除了预算，系统的技术条件限制，需要与第三方系统接口等其他限制条件，也需要事先搞清楚。需要、限制条件要和客户高层达成共识，一起努力找出在限制条件下可以满足需要的需求解决方案。

　　法则3：持续确认

　　曾经有人问我，几十页甚至上百页的需求规格说明书，如何让客户确认?

　　我反问：这几十上百页的需求文档是闭门造车写了n天后，才给客户确认的吗?对于客户来说，该文档是从天而降，他之前没有见过其中任何的内容吗?

　　需求不是等全部写出来才去确认的，要持续地逐步地确认。我曾经做过一个项目，连续5天进行需求调研的工作，第5天几十页的需求文档写出来了，给客户签字确认，客户很快就签字了!这份文档的绝大部分内容，在之前的4天他都曾经确认过，第5天只是一个最终的确认而已。

　　持续确认好处：

　　1、能尽快发现问题，能帮助我们尽早确认需要，避免后期可能的需求变更。

　　2、客户能逐步消化需求。

　　法则4：不要“二手需求”

　　曾经有一个某政府部门的项目，系统是各业务部门使用的，但需求只能从信息科那里获取。信息科的人自认为很牛，对项目组说：“需求向我们要就可以了!”而这个项目上线后，具体使用系统的部门就是不买帐，最后这个系统由信息科验收了。

　　信息科提供的是“二手需求”，向客户调研需求时，一定要避免“二手需求”!

　　上述案例你可能会觉得有点好笑，其实“二手需求”在项目组内也经常会发生。

　　某测试人员问为什么要做这个功能?开发说：这个你不用管，你这样这样测就可以了……

　　某实施人员觉得某功能看上去不太符合逻辑，提出疑问。开发说了一大通实施人员听不懂的技术用语，然后实施人员只能憋着不说话了。

　　项目组的测试人员、实施人员应该接触第一手的需求，最好能直接面对客户，而不是通过开发人员转述需求。

　　法则5：成为业务专家

　　你可能遇到过这样的情况，客户经常抱怨软件不好用，然后我们问：如何不好用?客户好容易说出了一些要求，我们按照这些要求修改了系统，但客户总是不满意，总是说不好用。诸如此类，不断重复。

　　客户说啥，我们做啥，是比较落后的一种层次。我们应该处在客户的利益，提出超出客户想法的解决方案。要打造有竞争力的产品或项目，成为业务专家是必须的，不能偷这个懒，不要仅停留在需求调研这样的层次，而是要引领需求，给客户带来更先进的知识和管理办法。

　　法则6：需求是“设计”出来的

　　手机订餐系统的故事我经常拿出来举例子，大意是：

　　某公司有一个订餐系统，但高层要求在这个基础上做一个手机订餐系统，让外出工作或请假的同事可以方便定午餐。手机订餐项目组花了九牛二虎之力，终于弄出这个系统，但问题多多。高层领导很不高兴：这点小事都折腾这么久!后来有人说：外出工作或请假的同事，打电话回公司，让前台帮忙订餐不就可以了?

　　“解决不方便订餐的问题”是需要，而“手机订餐系统”只是可以满足该需要的某种解决方案，我们完全可以通过其他更加简单的方法来满足需要。我个人观点：除了需要是来自客户的想法外，系统要具体做什么功能之类的需求，不是通过问客户问出来的，而是我们根据客户的需要，理解了客户的业务流程后，并根据限制条件，设计出来的!当然客户提出来的想法，会给我们带来很多启发，但我们不应该仅停留在需求调研的层次，而是提供一个高性价比的需求解决方案。

　　法则7：七分需求分析，三分需求管理

　　遇到客户变来变去的情况，我们可能第一反应是：有没有搞错!当初就应该让他签字!最好就是录音!

　　如果我们连客户的需要都搞不清楚，就去抱怨客户需求变来变去，那我们的水平未免有点低了。其实真正很难缠的客户、不讲道理的客户很少的，只是我们水平未够，不能理解或找出客户真正想要什么，才让我们误以为客户变来变去。

　　需求工作可能有很多问题，应该以做好需求分析工作为主，而需求管理为辅，两者比例大概是七三开。需求分析工作做好了，需求的问题可以减少很多，而且客户也会非常认可你的专业水平，这样后续的工作就比较容易处理了。

　　当然也可能会遇到很难缠又不能绕过的客户，遇到这样的情况，建议你看看“挨踢项目管理求生法则-战略篇”，如果从战略上判断该项目有很大问题，那么最好不要做这个项目，如果不幸要负责这样的项目，那么记住其中一个法则“输少当赢”。