怎样从容应对客户的需求反复

玻璃房

　　在需求分析阶段之后，与用户不要亲密接触，而是按照软件项目的周期，或者双方在初期的约定，定时通报软件研发的进展。

　　读过王玉荣的《客户为什么总是反反复复》，有感于自己的软件项目管理实践，借此话题介绍一点软件行业需求管理中的需求变更管理的实际经验，与各位读者共享。

　　在软件项目的研发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。我在自己的软件项目管理职业过程中，几乎天天面对用户的需求变更，切身感受到，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，用户的耐性渐渐消逝，研发人员的士气也越来越低落，最后所有的人都在等待一个结果：项目最好马上结束。所幸，在不断的学习和实践中，我总结了几点比较有效的方法，在软件研发阶段能够较好地解决这方面的问题。

　　1．需求分析阶段采用原型方法明确用户需求。

　　在软件项目的需求分析阶段，有大量需求信息需要收集、筛选、加工，这是需求管理的开始。客户和研发两方面的人员对需求的理解呈现“大体上共识多，细节上差异多”的特点。即使通过反复沟通，最终在时间表限制之内也能拿出一份“用户需求说明书”，但是以实践经验，用户需求的描述永远是“不够清晰”、“不够明确”的。这主要是因为在这个阶段，所谓的产品都在大家的大脑中构思，正如100个人读《射雕英雄传》，就有100个郭靖的形象一样，每个人的想法都是大致轮廓相同，而细节差异很大。在此阶段，原型开发是一个较好的辅助手段，它将存在于大家头脑中的虚境实实在在地表达出来，一个界面，几个控件，外观形式固定了，功能描述明确了，这就是研发部门对用户的需求理解。此时与用户再次沟通，用户基本上可以说出来：“这是我想要的”，或者“不，这不是我想要的，我要的是……”。一般情况下，原型之后的需求沟通就实际得多，双方的理解迅速向一个折衷方案靠拢，一个可以指导研发过程的需求说明书正式诞生了。

　　2．需求分析之后的研发过程采用严格的需求变更管理流程。

　　一旦需求分析阶段结束，此后如果用户要求有新的需求加入交付的软件系统中，需要走需求变更管理流程。这个流程必须在软件项目成立之初与用户约定好，一般的软件企业内部有需求变更的管理流程，可以向用户解释这种管理的必要性，直至与用户就此问题达成共识为止。不必担心用户不会接受，有过多次成功研发软件项目经验的需求变更管理流程，有着它不容置疑的合理性，这正是软件企业的经验和价值所在，用户最终会理解和同意的。

　　需求变更管理流程各家企业有各家的做法，借用CMM的需求管理KPA来讲，需要两级需求变更管理委员会（以下简称CCB）来处理，即产品CCB和项目CCB。产品CCB处理涉及到产品一级的需求变化，主要体现在需要多个职能部门，多个软件项目，以及与其他产品线的协调等问题；项目CCB处理本项目内部的需求变更，如不同小组之间的协调，接口变化等等。每一个需求都要经过CCB的审批，决定这个需求的各种属性描述是否合适，如时间紧迫性，采用的技术是否有风险，对系统的重要程度，需求变更的波动分析，需求实现的资源状况。在与会人员对需求属性取得共识之后，规划需求实现的版本，确定时间计划。

　　在此提醒大家，切忌对用户提出的需求拍胸脯，在此之前可以扪心自问：“如果拍了胸脯，以后不能按时完成，我能不能负担全部责任？”这样冷静一下就不会胡乱应承了。有一个比较好的方式减少这样的麻烦，就是在需求分析阶段之后，与用户不要亲密接触，而是按照软件项目的周期，或者双方在初期的约定，定时通报软件研发的进展。如果软件研发采用迭代式开发，就可以在每一期交付产品发布时做这个事情，征询到的用户需求将纳入以后某期的软件版本中。

　　3．为将要频繁改动需求的软件项目进行版本规划。

　　如果考虑到软件项目比较大，周期比较长，如超过一年，其间的需求变化必然多得不可胜数，建议采用迭代式开发，为每个阶段的产品进行版本规划。第一个版本一般是包括了软件系统最基本的功能，用户最关心的功能，它的研发过程实际上还为后续版本提供了系统构架和新技术探索。一个按时交付、质量较好的版本可以让用户保持对项目成功的信心，并给了用户在最终产品未出来之前逐渐接近最终产品的机会，这个过程将使用户需求更加明确和完善，以提高最终产品的一次成功的几率。所以第一个版本的完成是项目的重要里程碑，建议项目组在此时举行庆祝会来提高凝聚力，鼓舞员工士气。后续的版本规划，一般是需求的分期完善，对系统的缺陷做持续改进。这个过程将一直持续到软件的生命周期结束。

　　需求管理是CMM二级就开始关注的KPA，可见其重要性。关于这方面的书籍多种多样，不过最好的还是行之有效的实践经验。我在自己的项目管理中，充分应用上述经验，可以从容面对我的客户，希望它对您的项目成功有所帮助。



上一篇：需求管理和变更控制的经验
下一篇：需求管理跟踪矩阵与需求双向管理

sockpuppet_real

LZ存理论流，首先，引起需求的变化涉及的人不仅是开发人员（乙方）与客户（甲方），这里还有一个关键人，这个人也是大家经常遗忘的人，他是乙方公司的商务或叫与甲方承诺的关键人，商务作为软件公司营销的角色，一定会在有意无意间过多承诺甲方许多事情，这回导致真正实施开发的人员无法完成项目；
其次：我们作为开发人员实际类似服务人员，服务人员什么是最周到的？那就是提供优质的服务，也就是全力满足客户也就是甲方的要求，因此不管何时 何种情况 我们都应该竭尽全力满足需求变化，也就是欢迎需求变更；
以上两点，是我们实施人员必须做到让客户满意两点。
因此结论是：在客户要求下，必须欢迎需求变更。

但是怎么做呢？
不知道LZ了解卡诺吗？如果知道，请认真研究。
LZ要知道，不是甲方签了合同，就相当于给了钱，我们就可以忽略客户满意度了，因为现在客户可能是潜在下一个客户，所以无论如何，一定要让客户满意，具体请看TQM质量八大原则第一条。那么怎样既满足客户又能使公司利润率高呢？这个看似相反方向的目的实际上是有关联的，他们是一个闭环，我们需要找到平衡点就行。当商务（销售）要买东西时，商务一定将产品（服务）价值最高点展现，但我们都知道产品的价值是波动的，（也就是你在A或B点买相同的东西，价钱是不一样的）所以，我们也不要埋怨商务对甲方承诺过度的事情，我们只需要培训PM在具体实施过程中将产品在客户心中价值降低就可以，我们专业称法叫降低期望值，怎样降低期望值？有很多方法，以后再说吧。不过具体请看PMP相关知识体系有具体的案例可借鉴

4707599

LZ分享的经验很重要的，在现场中PM是直接面对客户，如何有效沟通并把需求合理的纳入需求管理矩阵当中，并协调好后方项目支撑资源，就如LZ所说的贯穿项目的重要工作。
但这里有二点：1、如何应对客户不合理需求，特别是领导层面的不合理需求，积极沟通并寻找替代方案尤为重要；2、客户领导层的利益关系区域，不同部门不同领导如何平衡对需求的理解程度，这也是造成需求反复的因素之一。

思步学堂

楼主2位都是高手。

qastep

客户需求的反复着实让人头痛，特别是项目后期的需求变更，看似简单的需求波及范围却极广。

追夢赤子心

不错 支持一个了

墨羽倾炫

前排支持下了哦~

鹿宝宝@

看起来好像不错的样子

兲丄嘚訫图

确实不错，顶先

一种夸耀

鼎力支持！！

是我的憧憬

very good.

废话多了没有味i

很有借鉴意义，先收藏了，谢谢楼主。

哥、没被超越

我也来顶一下..

恒久

没人回帖。。。我来个吧！

╭ァ雨悸

我了个去，顶了