如何做好需求变更管理――需求变更流程规范

“鼻粑粑”通过精心收集，向本站投稿了6篇如何做好需求变更管理――需求变更流程规范，下面是小编收集整理后的如何做好需求变更管理――需求变更流程规范，仅供参考，希望能够帮助到大家。

篇1：如何做好需求变更管理――需求变更流程规范

一、引言

由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加，这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。

二、目的

控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。

三、角色与职责

1、市场人员

1）负责产品需求的提交以及解答项目开发过程中遇到的需求问题。

2） 负责与客户的沟通确认，并及时反馈客户最新需求。

3）负责与项目经理的沟通

4）负责与客户协调沟通需求变更中需求部分存在的差异

5）负责将需求变更中的需求提供给客户签字确认

2、 项目组长

1）负责协调变更的需求并对变更的需求有拒绝的权利

2）负责对变更的需求部分设计的修改

3）保证项目的开发与需求的一致性

4）确定开发进度是否需要进行变更

5）分配新需求给相关开发人员

3、测试组长

1）负责相应测试需求分析书的修改

2）负责把最新需求及时传达到测试人员

3）保证测试进度与开发进度一致性

4）负责与项目组长及时确认最新需求

4、测试人员

1）负责更改测试用例，保证用例与需求同步

2）调控测试进度，保证任务的正常完成

5、项目经理

1）参与需求修改的评审工作

2）最终确认需求是否进行修改

6、配置管理员

1）负责更新需求文档，记录需求更改记录

2）负责需求变更信息的发布与跟踪

四、需求变更处理流程图

需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图：

1、需求变更流程(客户提出需求变更)

1）执行条件：

客户提出需求变更

图：需求变更流程(客户提出需求变更)

2）流程说明：

需求来源：客户提交相关需求变更

审核需求变更：评估如果实现该需求，需要的时间、人力成本多少；并评估对项目工期影响有多大？判断那些需求能够目前解决，那些需要留到下一版本解决，

最后输出一份审核确认表反馈给客户，和客户进行商讨。参与评审的人员要包含项目经理，项目组长，测试组长，市场人员。

配置管理员：对变更需求进行记录，需求文档进行更新，并通知相关人员

项目组长：负责调整相关开发进度表，评估任务时间，分发给相关开发人员

测试组长：根据变更需求和开发进度，对测试进度进行相对应调整，并修改测试需求分析书，分发需求更新给相关测试人员。测试人员对用例进行补充，修改。

客户提交的变更需求最后必须让客户进行签字确认。

2、需求变更流程（内部提出需求变更）

1）执行条件：

对项目进度不会影响严重

与客户原始需求无偏差

图：需求变更流程（内部提出需求变更）

2）流程说明：

内部需求变更来源：公司内部人员发现逻辑，需求上的问题，或功能上的建议以及开发、测试人员提出的需求不一致内容。

需求变更类型：需求有误、需求有遗漏、需求不明确。

需求变更审核：内部提交的需求应该经过项目经理，项目组长，测试组长，市场人员共同的确认才能确认是否修改。

项目组长：评审需求变更部分的工作量，判断需求变更的内容是否对开发进度有影响，如果需求变更对开发进度有影响，项目组长可以拒绝变更；将变更内容放 入下一版本进行修改，若市场人员认为必须在本版中进行修改，项目组长可以将变更的内容提交给项目经理进行处理，并决定是否在本版中进行修改。

需求信息发布：经过需求人员和项目组长的沟通、协调确定在本版中进行修改的需求变更，需求人员需要将变更内容的信息，以邮件方式通知相关人员。

配置管理员：对需求变更进行备案。

开发，测试：开发、测试人员接收到需求变更内容后首先审核设计文档和测试文档，修改变更的地方。并根据变更后的文档进行开发和测试。

五、附件

客户需求确认单

文档名称

文档摘要

客户确认

经办人签字：    单位公章：      确认日期：

本文出自：www.cnblogs.com/hlearning/archive//02/24/hjj.html

篇2：在Scrum中管理变更需求

变更控制是用于变更管理的一个传统项目管理流程，在传统的项目中，变更控制主要表现为填写一个详细的变更需求表，表中包含了像变更细节、对项目的影响、风险、缓解计划等条目。它还需要多人批准。传统的变更控制和敏捷相违背，因为它和“响应变化胜过遵循变化”的原则相冲突。在大量的表要填和大量的需求要确认的情况下，响应变更是困难的。精益敏捷Scrum群组发起了一个有趣的讨论，群组成员就Scrum中对变更控制的需求、变更可被跟踪的可能方法等展开了讨论。

为什么团队需要跟踪变更？

Ashish Pathak提到说，其原因之一是阻止产品经理在产品Backlog中添加不必要的信息。反过来，它也反应了产品经理的效率。讨论组同意说有时候，Backlog中的条目没有被深入思考，所以需要经常进行变更。Mary Poppendieck建议说，原则上，阻止往Backlog中添加变更听起来像一个流程味道（process smell）。但是，她也认为产品Backlog中变更的长度不应该太长：

任何一个Backlog的目标都是：它应该足够短、级别足够高，无特殊情况不需要修改。如果Backlog改变了，那么我认为你应该假设你的Backlog错了，而不是需求变更了。变更需求通常意味着Backlog太长或者太详细，无从下手；或者说需要花费太多的时间猜测它究竟讲的是什么。

她还提到以下内容：

如果你测量了变更长度（Churn，从Backlog条目中的变更创建开始到产品交付使用结束），我认为超过变更长度10-15%的话，那不是什么问题。但是如果超过了50-200%，那么这说明有些人正在浪费大量时间在Backlog中添加需要变更的信息，他们不清楚什么需要做和什么不需要做，

管理资料

变更长度太长通常传递了一个信号：Backlog被用来阻止变更和使组织免受不确定之“苦”，而不是创建一个流程来很好地响应已经发生的事件并允许组织处理这些不确定的事情。

讨论组一致认为，基于Backlog变更长度作分析会有益于产品经理调整Backlog，以包含相关的条目。讨论还说明了跟踪变化在很多场景中都是有帮助的，包括什么时候需要跟踪和变更相关的以往决定，以及什么时候跟踪已调整的需求。

那么，团队如何跟踪变更？

组里的大多数人同意说变更应该被加到Backlog里。Brian Bozzuto建议说，Backlog条目应该有个属性来标明故事的起始点。该属性的值可以为开始、新的和变更等。

无独有偶，Erik Landes也建议说应该使用一个基于方法（Approach）的精益看板来管理变更需求。Chris Woodill建议采用一个通用的方法来实现敏捷变更控制流程。根据他的说法，主要的考虑应该是让流程保持轻量级，并尽可能消除浪费。

他的主要观点如下：

将变更记录到Backlog表或者变更

尽可能消除确认（Approval）

必要情况下，使用一个简单的变更控制表

加入利益相干方和相关操作

这样，在特定的情况下，也许有必要跟踪变更。使用如产品Backlog变更长度等工具跟踪变更，可帮助从根本上消除流程中的浪费，还可能让产品经理更加高效。当然也有其他一些原因和方法来跟踪变更，但是关键点是让流程保持精益，并尽可能提供一些有用的详细信息。

查看英文原文：Managing Change Requests in Scrum

本文出自：www.infoq.com/cn/news//12/change-requests-in-scrum

篇3：如何应对频繁的需求变更

在项目启动时就做好需求分析

一味的满足任何人的任何想法是错误的，所谓众口难调就是这个道理，要帮助需求人要找到真正的关键用户，进行充分的客户分析、市场分析，要和需求人达成充分的一致，不能在双方对项目的认识都在模棱两可的时候启动项目。

最好有“过来人”的参与

如果这已经是一个成熟的行业，可以找一位在此方面确实有丰富经验的人员共同参与进来。在没有合适角色的情况下，可以选择分阶段进行，

也就是摸着石头过河，根据实施效果随时调整进度和方向。

明晰项目范围

在产品实际应用中，需求永远是没有止境的，首先解决至关重要的、核心的、当前急于解决的需求。明确现在需要做的有哪些，下一步需要做的又有哪些，长期的拉锯战，对需求人和执行者都是一种摧残，对项目成本也有极大的压力。

做好自身技术可行性分析

根据需求分析预测，哪些技术能够利用团队现有技术,哪些技术团队不具备需要补充新的技术人员。

相关阅读：

分析解决“项目中十件最痛苦的事”（一）：解决需求变更

篇4：互联网产品方法论:需求变更循环

文章描述：恰恰PM的工作缺不了项目管理，更缺不了对于需求的管理，偶然的原因，和团队分享了我对于项目进行中“需求变更”的理解和管理方法，忽然发现之前写过很多产品思考和细节思考的东西，但从没有整理出方法论，后续应该多整理下方法论。

IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情，项目失败的原因千千万，我认为需求管理、需求变更管理是个很重要的因素。恰恰PM的工作缺不了项目管理，更缺不了对于需求的管理，偶然的原因，和团队分享了我对于项目进行中“需求变更”的理解和管理方法。忽然发现之前写过很多产品思考和细节思考的东西，但从没有整理出方法论，后续应该多整理下方法论。

我认为对需求变更这件事是需要无限关心的，它的目的在于两点：

1，管理需求变更的过程，实际上是不断明确项目目标的过程，是自我完善的过程。

2，需求变更对虚拟团队的打击是PM需要避免的，无论是对PM的信任度，还是对于自身的挫折感，都很重要。

我整理的需求变更循环如下：

1，需求质量

需求包含调研过程、沟通过程、文档产出等内容，PM前期需要尽可能的想清楚、表达清楚，包括大局、节奏和细节。需求质量的高低能够对后续的变更起到决定性的作用，杂乱无章、漏洞百出的需求必然会导致无尽的需求变更。但需求质量也并不是绝对的，要看项目，看开放方案，对于敏捷开发来说，质量要求也许70分就够了，快速迭代才是硬道理。对于重大项目，也许要80分才能过各级的评审。但无论如何60分是必须的，需求达到一定质量才能立项进入开发阶段，这也是一般情况下采取的项目评审方式。

2，团队理解一致

PM团队、项目虚拟团队的沟通效果最重要，要明确每个人的理解一致。PM把自己的调研、设想、预期描述清楚是第一步，这也是PM的必须课。但更重要的是要明确每个人的理解是一致的。要知道很多时候不同的人对于同一句话，同一个描述段落，理解很有可能是不一致的，这必然会导致后续的发展不一致。因此团队成员每一个人的理解是一致的这件事很重要，不光是为了给大家 ，更重要的是让大家做同一件事，

3，越早发现问题越好

问题发现的越早，产生的破坏力越小，对项目进度的影响也越小。可行的方法有很多，随时关注开发进度、进行每日例行站会都是好方法。PM的责任当然不是启动开发后把所有的事情交由项目经理（或者开发负责人，或者什么人）去管理，正确的方式应该是要不自己就是项目经理，要不自己也参与项目的管理工作，最低自己也得随时关注项目的进度。

4，积极面对

发现问题后不能等待，要么变更要么放弃，必须做出选择。事实上经常会遇到一些情况，让我们很难去积极面对，比如资源紧张，比如时间紧张，比如麻烦太大，比如无法向老板交代，比如无法向同学们解释，比如会让同学们鄙视等等。但不作为永远都是下下策，积极面对是解决问题的唯一出路，也是必须要使用的方式。

5，及时更新文档

文档虽然不是最重要的，但记录变更非常重要。无论是对团队成员来说，还是对自己来说，记录变更内容都是非常重要的。每个人的记忆力都是有限的，每次评审都是没有记录的，每次邮件都是杂乱无章的，每次会议纪要都是不正式的。唯一正式、可靠的就是需求文档，将变更内容及时更新不但是良好的工作习惯，也是对项目团队负责人的表现，任何人这样做都会获得别人的尊重。

6，冻结时间点

需求太多、诱惑太多、我们每个人都是个完美主义者。无论是从用户角度出发，还是从自己的完美癖好出发，还是从领导交差出发，好像都需要把事情做到极致。但极致是需要一步一步来的，为了避免项目延期、成员灰心丧气，我们需要有个冻结需求的时间点。同事为了保护团队和项目进度，要自我严格执行，任何时候都反过来想一想，我自己是不是已经成为了项目失败的原因，想一想我的所作所为是不是已经是问题本身而不是解决问题的方法了。

7，必要的妥协

事无完美，快速迭代得永生。无论是技术代价还是人力代价，都是有阀值的，虽说技术没有实现不了的想法，人力代价往往也不是问题，但时间代价是实实在在的。而且，世界上没有一口吃成胖子的事情，也没有万事如意的情况。妥协是必要的甚至是每天都要面对的，妥协并不是放弃，而需要仔细的思考和规划。也许之前考虑的就不成熟，也许后续可以更好的安排。

8，事后总结，才能进步，避免重蹈覆辙。

daxu.net/archives/1333.html

篇5：需求变更与重新设计的勇气交互设计

如果设计之前的重要业务规则，主要解决问题都不能确定，那么还是不要开始设计了，

否则，总是在你设计完成之后被告知需要增加一条业务规则，不久后，又需要增加一条。如果你不想重新设计，你只能在原有设计基础上增加一个解决方案，再增加一个。增加若干个以后，你会发现，最初的设计思想和目标已经被完全打破。设计已经变得不伦不类了。

面对大的变更你只有重新设计了。如果没有时间，懒得去做的话，被不断声讨的是设计阿，而不是需求变更。

npr的重新设计 说道：

In some cases, we spent significant amounts of time working through a problem only to realize that our initial idea simply wasn’t going to work. We had to be okay with scrapping time-intensive, developed ideas and completely starting over when necessary.

面对变更和被验证的失败，要有重新设计的勇气！

本文来自：www.lunaticsun.com/article/small-or-big-redesign-is-essential

篇6：营销管理要满足整个营销流程的每一种需求

企业每天都在做营销决策，有关于渠道的、关于促销的、关于价格的，这些决策决定了企业在市场上的成败，我们看到，成功的企业总是少数的，很多企业是昙花一现，或在垂死挣扎。有人估算中国企业的平均寿命是3-5岁，民营企业的寿命为2.9岁，而《财富》 500强的企业，平均寿命也只有40-50岁。中国企业寿命偏短，部分企业是因为营销管理出了问题。那么营销管理的出发点是什么呢?营销管理到底是管什么呢?有人说营销管理是管销售队伍，防止销售队伍“叛变”，用选人、留人、晋人等手段把他们管住，让他们老老实实地卖货;有人说是管理经销商，认为经销商是企业生存、发展的根本;有人说是终端为王，一切营销管理都要围绕终端展开。

要分析营销管理到底是管什么，还是回到市场营销的本质上来。每个人、每个企业在社会上生存和发展，都有需要，并愿意付出一定的报酬来满足部分需要，于是这部分需要就形成了需求。可以通过很多方式来满足需求，有自行生产、有乞讨、有抢夺、有交换等。市场营销的出发点是通过交换满足需求。

五种需求缺一不可

营销管理要管什么需求呢?这个问题涉及到企业的很多方面，企业强调团队合作，强调供应链，因此各个环节的需求都要考虑到，这样的营销政策才是好政策。有个笑话说，某单位科研人员得到了一笔奖金，于是领导准备进行分配。在分配时，出了问题，到底要给发明人多少奖金呢?给团队其他成员多少奖金呢?领导很难定，于是让每个人阐述分奖金的理由。其中看门的老大爷说：“我不给你们看大门，仪器设备都会被偷，怎么搞科研?”打扫卫生的张头说：“我也有功劳，我负责打扫卫生，我不掏厕所，你们会憋死的。”

这是个笑话，但在营销中，企业制定营销政策，要充分考虑营销政策推行的各个方面，其中主要是企业、消费者、经销商、终端、销售队伍，这五个方面。营销管理要满足企业的需求、满足消费者的需求、满足经销商的需求、满足终端的需求、满足销售队伍的需求，在不断满足需求的过程中企业得到了发展。

满足企业的需求

企业的需求有那些呢?企业追求可持续发展，说白了就是可持续赚钱。企业可以短期不赢利，去扩张，去追求发展，但最终目的是赢利。所有的人员、资金、管理等都是为企业实现可以持续赚钱的手段。按照营销理论，企业要坚持“4C”原则，以消费者为中心，

但实际上“以消费者为中心”是企业思考问题的方式，企业要按照自己的利益来行动。老板要把命运掌握在自己手上，要操控市场，要掌握市场的主动权。企业发展的不同阶段，市场发展的不同阶段，企业有不同的需求。

市场孕育期，企业开发了创新产品。企业面临两个问题，一是要迅速完成资金的原始积累，另外要迅速打开市场。所以此时企业可能采取急功近利的操作手法，怎么来钱，就怎么来，怎么出销量就怎么来。可能采取的政策是高提成、高返利、做大户等。

市场成长期，企业飞速发展，出现了类似的竞争对手。因此企业要用比对手快的速度，扩大市场份额，占领市场制高点。可能采取的措施是开发多品种、完善渠道规划、激励经销商等。

市场成熟期，在市场成熟期，企业需要延续产品的生命周期。企业要追求稳定的现金流量，同时还要开发其他产品。这时企业要不断推出，花样翻新的促销政策。

市场衰退期，企业要尽快回收投资，变现。

从上面简单的生命周期描述中，我们看到，不同时段企业有不同需求，满足企业需求是第一位的。营销管理是对企业需求的管理，以满足企业的需求为根本。所以作为营销决策者首先要考虑：“我的老板要求我做什么?公司现在需要我做什么?股东需要我做什么?”然后在具体落实企业需求的过程中，考虑下面的四个需求。

满足消费者的需求

中国的消费者是不成熟的，所以才容易被企业误导，策划人搞得概念满天飞，风光三、五年。真实的、理性的消费者需求是什么呢?消费者对好的产品质量有需求，消费者对合理的价格有需求，消费者对良好的售后服务有需求。消费者的需求对企业来说是最重要、最长久的，企业可以满足短期利益，忽略消费者需求，但消费者是用“脚”投票的，他们会选择离开。

著名的春都，发家于火腿肠，上市公司。在九十年代是中国知名企业，行业先锋，但在多元化战略下，迷失了自己的方向，主营业务大幅萎缩。为在价格战中取胜，春都竟然通过降低产品质量，损害消费者利益，来降低生产成本，含肉量一度从85%降到15%，春都职工用自己的火腿肠喂狗，戏称为“面棍”。只考虑自己需求，而没满足消费者需求的春都，付出了惨重代价，销量直线下滑，市场占有率从最高时的70%狂跌到不足10%.春都的灭亡是必然的，只考虑企业的需求是危险的。企业可以在一段时间欺骗所有的消费者，也可以在所有的时候欺骗一个消费者。但群众的眼睛是雪亮的，企业不可能在所有的时候欺骗所有的人。所以对企业来说，满足消费者的需求是企业存在的价值，是企业最长久的保障。在满足需求的基础上，企业还要发掘需求，引导消费的潮流。甚至去取悦消费者，去讨好消费者。

【如何做好需求变更管理――需求变更流程规范】相关文章：

1.需求建议书

2.变更协议书

3.变更协议

4.变更证明

5.变更建议书

6.变更合同

7.变更管理制度

8.变更申请书

9.合同变更

10.企业需求管理求职简历