挨踢项目求生法则-需求篇

摘要：

知道什么是挨踢项目吧？什么！不知道？那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