变更对每一个项目都是不可避免的，需求变更的确是被讨论最多的一个。个中原因，一是需求变更发生的概率最高，二是业界也的确尚未找到彻底解决需求变更问题。
范围变更是导致项目失败的主要原因。项目经理们都经历过不太成功的项目，“糟糕的范围控制是项目管理第一大失误”似乎已经成为是业内人士的共识。
一、需求那些破烂事
1.需求不明确
郭致星老师在《做项目，就得这么干》中给我们讲过一个经典的案例，这里我引用之：
案例
每每谈及"需求"，我都会想起2006年的经历。
那一年，我的一个项目经理带领一个团队为一个重要客户做项目。在做了基本的用户调研后，我的项目经理带领团队做了一个项目建议方案，根据用户（一位非常重要的客户于我们而言）要求向用户的领导做了汇报。汇报后用户很不满意——因为与用户的期望差距很大！用户不满意就只能修改……修改、汇报；再修改、再汇报……如此反复！
修改到了第五版，团队成员终于要造反了——这操蛋的客户，我们服务不了！重压之下项目经理找到了我——要么作为领导我一起陪他去跟客户汇报，要么不干了！我只好出面做工作，陪其一同前往。
可是，汇报的结果一如既往地不能令这位领导满意！我只好向这位领导请教其真正的需求是什么？想要的系统到底是什么样子？请其详细描述。这位领导的话是我工作近二十年来听到的关于需求最为经典一句：“我确实说不清我想要的东西是什么样子，但是我能说清的是你给我的东西不是我想要的！”
天哪——这就是操蛋的客户需求！
不明确的需求导致后续合同中的规定也往往是模糊不清的，有时只有几行说明，有时可能是套话、官话。对于项目参与者往往对客户业务不一定了解，如果对客户真正想要的需求没有真正了解，往往会导致后期无何止的修改。
2.需求理解不一致
来看一个耳熟能详的案例吧。
案例
客户：我家有三个小孩，我须要一个能三个人用的秋千。它是由一绳子吊在我园子里的树上。
项目经理：秋千这东西太简单了，就是一块板子，两边用绳子吊起来，挂在树上的两个枝子上。
分析员：这个无知的项目经理，两个树枝上挂上秋千哪还能荡漾起来吗？除非是把树从中截断再支起来，这样就满足要求了。
程序员：两条绳，一块板，一棵大树，接在树的中段；太简单了，工序完成。
商业顾问：您的需求我们以完成，我们通过人体工学，工程力学多方面研究。本着为顾客服务出发，我们的秋千产品在使用时给你如同游乐园里的过山车一样刺激，如同你在地面上坐沙发一样舒适与安全。
文档管理员：这么小的工程没有文档很正常，只要需求说明书与合同就可以了。
实施人员：我们的产品用户自己都可以完成安装，只要把绳子系在树上就可以了。
我们经常会遇到，按照客户书面上记录的需求进行开发后，客户却并不认可，而实际情况，客户对自己写的书面内容也并无异议。原因是对同样的内容客户的理解与我们的理解不同。例如，需求中写道：“购物后付款”，开发人员开发出来的是用户选择好商品进入购物车直接付款。而客户实际想要的是到购物车付款前先向客户发送一条短信验证码，让购买人二次确认无误后再付款。同样的文字，对细节的理解可能就是不同的，但实现的细节客户提供的需求里可能根本就没有提。
3.有些需求并没有直接写出来
中国文化植根于儒家思想，话多为隐晦而不直白的说出，客户提的多是自己期望解决的需求，而对于最基本需求往往不说，因为他认为你就应该有。如做一款手机，手机打电话的功能客户是不用说的；再如，智能面包机，做面包的功能也是不需要说的，他只会说如何智能法。
4.验收前总有提不完的需求
客户总是会在结项前提出各种需求，前期没有讨论过的各种需求都会在这个时候冒出来，让项目被动受制。造成这种情况的原因一般有两种，一是在项目开发过程中没有与客户充分的沟通，二是客户担心完成项目验收后乙方的支持和服务就难以保证了。以至于，所有需求不论重要与否，他都要求在结束前完成。
5.无条件的迁就客户
虽然项目成功的标准常被定为客户满意度，但无条件的迁就客户最终可能导致项目预算超支、时间拖期，反而会导致项目失败。客户在提一条新需求时可能自己都没有想清楚，也可能只是他的灵光一现，许多需求可能只是冗余需求。客户往往不懂技术，随便说出口的需求，可能让我们付出很大的代价。
6.沟通不顺畅
项目中，我时常遇到对技术完全不懂的客户，他们的许多想法根本无法实现，跟他解释又难以理解，弄得好像我们什么都做不了似的。对于这种客户有时会让我们有种无力感。
二、做好需求的管理和控制
项目成功涉及多方面：需求、进度、成本、质量、风险、人力资源、采购、干系人、沟通等，任何一个方面出问题都可能会导致项目的失败！
项目管理是一套系统的方法。实践中，对于需求问题，该怎么办？
1.确定项目范围
项目一定要有清晰的目标、准确的方向，大海航行靠舵手，项目经理要有定义好项目范围的能力，尽量把项目需求让所有项目干系人（范围相关的所有人）知晓，尤其要得到客户的认可，请务必要让用户确认。
我必须告诉你，不管他愿不愿意签字，你务必逼客户签字。记住：拿不到签字，下一阶段就不能开始。如果他们不愿意签字，为什么还要逼他签字呢？其实，我们真正想要的并非他们的签字，而是逼他们认真考虑项目问题。很多时候你不逼，他们就不会深入考虑和审查项目需求；果真如此，倒霉的最终还是你。
在需求和范围确认这件事上，项目经理需要“强势”一些，用各种可能的办法“逼迫”客户把需求考虑清楚。
不管用什么方法，在项目开始前，主要的项目干系人必须对项目目标、需求达成一致。当然，请注意一个原则：对事要硬、对人要软！
2.多问问为什么
对于客户每提出的新需求，我们尽量多了解他的目的是什么，多问、多想，当我们知道客户的终极目标时，我们就可以主导客户需求了。同时，我们了解了客户提此需求的目的后也有利于我们对需求的更好把握，不至于项目需求出现偏差。
再来另一经典的案例吧。
案例
福特汽车公司创始人亨利·福特说：如果在汽车时代早期询问客户有何需求，很多人可能都会回答说“要一匹跑得更快的马”。
“用户压根不知道自己需要什么，直到你把它摆在他面前”乔布斯如是说。
需求是什么？一匹更快的马？还是一辆汽车？毕竟用户都很喜欢。需求到底是什么？此时此刻，我想增加一个名词，就叫做“用户期望”。其实，现在很多项目人员嘴里嚷嚷着的更像是“期望”，而不是“需求”。
难道就真的没有办法弄清楚客户的真正需求？回到福特汽车的个例子上。
由于用户基于他们的阅历与认知，他们习惯给自己的需求套到现实中可实现的方法或物质中。所以他们回答一匹跑得更快的马。但并不意味着这就是他们的需求。需求可能不被察觉，经过大脑翻译然后输出，成了被我们理解成需求的期望。而这里就是那匹更快的马。逆着翻译，我们也不难得到他们的需求是“速度更快的代步工具”。
一定不要试图仅从技术层面讨论问题，项目经理是业务层面的管理者，项目是基于业务导向的。
3.需求理解要一致
需求理解的一致性是项目成功的基础，在项目管理的各个阶段，要让所有相关人正确的了解和把握需求。
4.要让客户参与到项目的各个阶段
项目经理要让客户参与到项目的各个阶段中，需求分析、总体设计、详细设计、编码、测试，要让客户参与到项目的每个阶段，并随时让客户了解和提出自己的真实想法。这样就不会导致项目在最后时客户提出各种需求，变被动为主动。
特别是在需求分析和设计阶段，当整理完需求文档和设计文档时，一定要请客户一起参与评估，以避免需求理解不一致，需求范围不确定等问题。
在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求阶段。其实，房地产行业已经给我们做好了先例：客户买房子之前是先要看看样板房和模型的，什么都看不到这房子你敢买么？除非你不是自己住！
要让客户对需求进行确认。当多次与客户确认需求后，尽量让客户签字认可，如不能签字也尽量让客户方领导在正式场合当面确认。
这样的好处有：
可以有效的控制需求，当客户再有想加的需求时总不至于那么理直气壮；
如客户真要加需求时，我们可以因需求变更而提出一定的经济补偿；
如果需求变更，项目经理可以凭借着签字在公司内部规避自己的责任，毕竟客户以前是认可的，这回再提增加需求，就不是项目经理能力范围了，可以请领导出面；
有了客户确认的需求，项目组可以放心的去完成项目，以减少需求变更所带来的影响。
5.做好服务，要让客户信任我们
客户之所以在项目结束前尽量让我们把所有能想到的做好，有时还提出各种刁难，就是怕我们在项目结束后就不能很好的给予支持了。对于公司和团队，我们要建立完整的服务机制并让用户看到。客户对公司和团队认可了，对后续服务有信心，客户就会允许把部分非核心工作放到将来处理。信任是种力量，让客户信任我们就要始终如一的做好服务。
6.充分使用需求变更管理机制
有时需求的变更是不可避免的，当发生需求变更时，我们要有一定的需求变更机制。首先要冷静看待需求的变更，与客户沟通好，要对需求变更的工作内容、工作量进行评估、因变更所产生的费用、针对需求变更提出的方案，并填写需求变更文件让客户签字，要让客户知道需求变更对项目产生的影响，对于需求的变更客户也要承担一定的责任（时间或经济）。
能否用一个正式变更控制管理系统拒绝对需求的变更至关重要，特别是客户第一次提出变更时。需要说明的是，这个正式的变更控制管理系统必须是在项目开始前就制定好。一个临时搬出来规定往往会被视为一种强词夺理，极可能会激怒对方。
三、结语
项目需求的管理是一个复杂的过程，它涉及到项目所有相关人的利益。有效的避免与客户的冲突，多给客户一些中肯的意见。同时，也要让客户参与到项目的各个阶段，要让客户了解项目的各个过程，让客户了解我们公司和团队，建立起信任度，在有信任的前提下做事，友好的沟通，会让我们工作起来更加舒畅。
【项圱原创】【未经允许，请勿转载】【版权所有，违者必究】
