[原创]浅谈需求管理的核心－明确客户需求
需求管理恰如裁缝的量体裁衣，它直接关系到项目中产品的成型。一个项目的成功，很大一部分要求满足客户的需求。
需求管理的关键：
明确客户的需求
下面结合作者在负责项目的经历，谈谈项目中的需求管理。
u 明确客户的需求
如何明确客户的需求? 在和客户进行沟通的时候，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。
明确客户需求，简单而言，通过如下几个步骤：
1：让客户畅所欲言，罗列出所有的需求
2：透过现象分析潜在的需求
3：整理和评审需求分析报告
Ø 让客户畅所欲言，罗列出所有的需求
让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕"勾引"起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；
Ø 透过现象分析潜在的需求
很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
Ø 整理需求分析报告
需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 ，需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。
需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题
帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解。
最后，需求分析报告一定要双方共同签字确认。
u 关于需求管理的漫画
下面以一个这个图在参加很多会议的时候都听别人讲过，特别是那些卖需求管理软件的，今天无意在网上搜索到，放在这儿以留存并与各位分享。大体的意思就是客户向软件提供商描述一个需求，但每个人的理解都不一样，辗转的过程中，越来越走样，当最后客户以大笔的钱买到成型的产品时，已经完全不是当初所想的那个东西。耗时费力，其实客户需要的不过是一个轮胎秋千而已，绕了那么多弯，也真够冤的。
需求管理的关键：
明确客户的需求
下面结合作者在负责项目的经历，谈谈项目中的需求管理。
u 明确客户的需求
如何明确客户的需求? 在和客户进行沟通的时候，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。
明确客户需求，简单而言，通过如下几个步骤：
1：让客户畅所欲言，罗列出所有的需求
2：透过现象分析潜在的需求
3：整理和评审需求分析报告
Ø 让客户畅所欲言，罗列出所有的需求
让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕"勾引"起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；
Ø 透过现象分析潜在的需求
很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
Ø 整理需求分析报告
需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 ，需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。
需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题
帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解。
最后，需求分析报告一定要双方共同签字确认。
u 关于需求管理的漫画
下面以一个这个图在参加很多会议的时候都听别人讲过，特别是那些卖需求管理软件的，今天无意在网上搜索到，放在这儿以留存并与各位分享。大体的意思就是客户向软件提供商描述一个需求，但每个人的理解都不一样，辗转的过程中，越来越走样，当最后客户以大笔的钱买到成型的产品时，已经完全不是当初所想的那个东西。耗时费力，其实客户需要的不过是一个轮胎秋千而已，绕了那么多弯，也真够冤的。