摘要：
知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。
作者：张传波
www.umlonline.org/school/
由“我要吃饭”的故事想到的
某天某客户跟你说：“我要吃饭！”
你非常关注客户这个需求：“请问您要吃中餐还是西餐呢？您想吃什么呢？”
客户非常开心，一下子说出了很多想吃的：
“西餐嘛，不错，听说那个菲力牛排很不错，配上红酒更加美味！”
“不过听说某某路的那个潮汕牛肉丸火锅，牛味很浓，牛气冲天……”
“哎呀，最近上火，还是不吃这些上火的东西了，吃日本寿司吧，听说那里有日本菜自助餐，有生蚝，正啊！”
“啊，不行哦，最近日本核辐射，海鲜还是不吃了”
……
最后客户说：
“你还是先弄一顿给我尝尝吧，见到菜才能提出具体需求啊！”
遇到这样的客户，你可能想找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：七分需求分析，三分需求管理
遇到客户变来变去的情况，我们可能第一反应是：有没有搞错！当初就应该让他签字！最好就是录音！
如果我们连客户的需要都搞不清楚，就去抱怨客户需求变来变去，那我们的水平未免有点低了。其实真正很难缠的客户、不讲道理的客户很少的，只是我们水平未够，不能理解或找出客户真正想要什么，才让我们误以为客户变来变去。
需求工作可能有很多问题，应该以做好需求分析工作为主，而需求管理为辅，两者比例大概是七三开。需求分析工作做好了，需求的问题可以减少很多，而且客户也会非常认可你的专业水平，这样后续的工作就比较容易处理了。
当然也可能会遇到很难缠又不能绕过的客户，遇到这样的情况，建议你看看“挨踢项目管理求生法则-战略篇”，如果从战略上判断该项目有很大问题，那么最好不要做这个项目，如果不幸要负责这样的项目，那么记住其中一个法则“输少当赢”。
如果本文对你有帮助，麻烦点击一下“推荐”，谢谢！
作者：张传波
www.umlonline.org