怎样控制需求变更

  实际上就算美工和程序员的这样分工可以减少不少工作，但没有解决根本问题，只要客户不断更改就怎么样都要做些重复工作。可是要怎样才能控制需求变更呢？
  我向老总提写议确认书，并让客户签确认书，可老板说这是不可能的，你功能都没做出来，怎么让他们签啊？你做完功能让他们去体验，他们才知道有哪些地方是需要修改的，而页面的变更，实际上很多时候都是我们在开发或者开发完了，老总提出来要更改的。就像上周我们花了一周时间完成了一个功能模块，并经过了第1步测试，结果老板说要改页面，页面的布局和字段全都变化，相当于我们完全没做，而老板还以为页面的更改对功能开发影响不大，当然我也是今天才看到更改后的页面才知道的，而现在老板又在客户那边开会调研，我们无法沟通（而且更改后的页面除了老板同意外，其他美工和我们都觉得那样页面很难看而且变形了）:cry:
  更有意思的是，我们做的功能也一直不去确认，还在那边梳理流程，这样的话，我们开发的越多，以后也就改的越多，甚至又是完全重做！我感觉很可怕，可是解决的办法呢？我想只能做记录，记录下更改了多少，花费了我们多少时间，让老总感觉到其实这些是很耽误时间的，看他是否会重新考虑他现在的做法，不然的话，我们会死的很翘很翘！
  我相信很多人都遇到过这样的情况，不知道大家都是怎么控制需求变更的？怎么解决这些问题的？

评论

24 楼 softcat 2008-11-14  

pandonix 写道

movingboy 写道

看起来一个明显的问题是你们开发小组与客户的沟通、开发小组与老板的沟通不够充分、有效。由于软件开发的专业性，客户与老板都不懂得开发过程的复杂性，不懂得一项变动对项目的成本、时间及其它方面有什么样的影响，不懂得项目后期的变动与前期的变动对项目影响的差异有多大。要靠客户或老板单方面去理解这些是很困难的，所以开发小组必须能提供足够的信息，帮助他们去判断。如果开发小组自己也是懵懵懂懂的，就别希望客户在项目前期就能确认，别希望老板能做出正确的决策

再就你提到的几个具体的问题说说个人的看法：

1.我向老总提写议确认书，并让客户签确认书，可老板说这是不可能的，你功能都没做出来，怎么让他们签啊？

首先就个人经验而言，让客户在需求说明书（或类似的文档）上签字是很难的。就算是双方对需求的理解已经高度一致了，客户仍然会对未完成的东东心存疑虑，毕竟一份需求说明书不能列举所有的细节。此外如果客户签署了需求说明书，万一项目失败了，签字的那个人很可能成为项目失败的责任人。没有人愿意承担这样的危险（注意是危险，不是风险）

我们对于需求沟通的最基本的做法就是反复沟通和迭代开发。其实这并没有什么神奇的地方，道理也象白开水一样简单：

反复沟通是一个从粗略到精细的过程。每次沟通都能减少开发小组与客户对需求的理解的差异，或者修正以前错误的理解，或者比上一次讨论的更深入、更全面

迭代开发使得开发小组能比较快地提交新功能，对需求变更也能快速响应。而每次交付给客户试用的软件能让客户有更直观的感受，能更有针对性地提出问题，双方沟通的效率也可能提高

2.实际上很多时候都是我们在开发或者开发完了，老总提出来要更改的

我觉得开发小组可能需要更深入地理解需求，尽可能在项目前期就搞准确。这可能也需要你们学习更多的行业知识，了解更多的行业习惯。如果不这样，就很可能出现你开发的一个功能你觉得很爽、很酷，但用户却觉得很搞笑、很花哨......

老板或客户不懂得如何评估一项功能或变动会对系统产生多大的影响。比如是否会导致架构方面的改动、改动的范围或程度如何？是否导致返工、返工的工作量如何？（其实个人觉得更应该关注返工对于开发小组士气的影响如何）。所以你们应该在项目前期考虑各种可能的实现，在一定程度内做得灵活一点（留有变更或扩展的余地），而且，应该迭代开发

还有一点，开发小组要学会评估工作量和工期。面对一项功能或变动，如果开发小组说不清楚要干些什么，要多久（更妥当地说，多久是一个时间范围），怎么能希望老板能正确地评估收益和代价呢？怎么能正确地决定做还是不做呢？

说到底，客户不能在需求说明书上签字，老板在开发工作完成了才提出变更，最根本的原因是他们对开发小组在项目前期对需求的把握没有信心。他们不知道开发小组对需求理解到什么程度？开发小组的理解与他们的理解是否一致？开发小组到底要花多少时间才能把项目做好（不仅仅是做出来）？如果开发小组能打消他们的疑虑，或许开发过程会顺利许多

非常精辟，个人最欣赏的是movingboy对待需求变更的心态。当需求变得不可控，严重影响到项目开发和组员士气时，我们往往选择了抱怨，自然而然地期望能有一份与客户之间的“需求协议”。不可否认，有些时候，遇到老好人时，这是有可能的。特别是一些重视流程的大公司，甚至主动要求去签署这样的协议。然而，如果开发小组与客户（或老板）尚未建立“高度一致”的需求认知就签署这样的协议，往往是没有意义的，最终吃亏的还是开发人员。试想，待项目交互时，客户才发现很多功能并非他们所期望的，那对开发人员而言，简直就是噩梦。
    需求分析是一个迭代过程，应该是被不断细化的。极端情况下，有些模块的需求甚至要直到其他模块开发出Alpha版本后才有可能被完全明确。正如o6z所说：“需求变更不应该去控制，而应该是跟踪，更好的是做到去引导”。所以说，开发人员应该积极主动与客户（或者协助市场人员）不断地去细化需求。曾经认识这样一位项目经理：项目验收成功后，客户常常开玩笑说，他比客户自己还要了解该项目的业务。
    所以，个人认为，开发人员面对需求变更，最重要的是有一套如何应对变更的方法，或者说是“如何跟踪和引导”的方法。
    呵呵，非常期待o6z大师详细谈谈需求跟踪和引导客户的方法和经验：）

感觉这里参加讨论的人，都是从软件过程来提出解决方法的。
但是，面对成熟客户，这个是可以的。但是，现在LZ面对的不是一个成熟客户，很明显，公司领导层也站在客户那边，所以软件过程那些东西说了也是白说，而且老板是利益导向的（或者说是结果导向），根本不会管其中的变更带来的rework，所以建议LZ，在项目初期，现做静态的页面（好像是个web项目），业务逻辑的跳转也可以加上去，起码要让用户对UI的先做确认，而且对于用户来说也很直观，他们也可以提出相应的意见，数据库这些先不着急，等这些都确认以后，在开始开发中间的业务逻辑，这样起码，不会浪费太多的时间，而且可操作性比较强，工作也不会太大，毕竟那些静态页面后面开发也可以用啊。

23 楼 gutou9 2008-11-13  

levis2000 说的最实际了

22 楼 levis2000 2008-11-12  

我个人认为，在国内，除非是真正懂行的客户老板，他们的意见往往是表面的，不科学，是不需要太在意的，能忽悠就忽悠，让他闭嘴就行。关键是真正的使用者，比如7*24或者5*8的，他们提出的意见才最后决定这个项目的命运，你不得不去follow。

21 楼 DoubleEO 2008-11-11  

cmmi会有用的

20 楼 changyuxin 2008-11-11  

用户总是会提出新的需求啊！

19 楼 pandonix 2008-11-11  

movingboy 写道

看起来一个明显的问题是你们开发小组与客户的沟通、开发小组与老板的沟通不够充分、有效。由于软件开发的专业性，客户与老板都不懂得开发过程的复杂性，不懂得一项变动对项目的成本、时间及其它方面有什么样的影响，不懂得项目后期的变动与前期的变动对项目影响的差异有多大。要靠客户或老板单方面去理解这些是很困难的，所以开发小组必须能提供足够的信息，帮助他们去判断。如果开发小组自己也是懵懵懂懂的，就别希望客户在项目前期就能确认，别希望老板能做出正确的决策

再就你提到的几个具体的问题说说个人的看法：

1.我向老总提写议确认书，并让客户签确认书，可老板说这是不可能的，你功能都没做出来，怎么让他们签啊？

首先就个人经验而言，让客户在需求说明书（或类似的文档）上签字是很难的。就算是双方对需求的理解已经高度一致了，客户仍然会对未完成的东东心存疑虑，毕竟一份需求说明书不能列举所有的细节。此外如果客户签署了需求说明书，万一项目失败了，签字的那个人很可能成为项目失败的责任人。没有人愿意承担这样的危险（注意是危险，不是风险）

我们对于需求沟通的最基本的做法就是反复沟通和迭代开发。其实这并没有什么神奇的地方，道理也象白开水一样简单：

反复沟通是一个从粗略到精细的过程。每次沟通都能减少开发小组与客户对需求的理解的差异，或者修正以前错误的理解，或者比上一次讨论的更深入、更全面

迭代开发使得开发小组能比较快地提交新功能，对需求变更也能快速响应。而每次交付给客户试用的软件能让客户有更直观的感受，能更有针对性地提出问题，双方沟通的效率也可能提高

2.实际上很多时候都是我们在开发或者开发完了，老总提出来要更改的

我觉得开发小组可能需要更深入地理解需求，尽可能在项目前期就搞准确。这可能也需要你们学习更多的行业知识，了解更多的行业习惯。如果不这样，就很可能出现你开发的一个功能你觉得很爽、很酷，但用户却觉得很搞笑、很花哨......

老板或客户不懂得如何评估一项功能或变动会对系统产生多大的影响。比如是否会导致架构方面的改动、改动的范围或程度如何？是否导致返工、返工的工作量如何？（其实个人觉得更应该关注返工对于开发小组士气的影响如何）。所以你们应该在项目前期考虑各种可能的实现，在一定程度内做得灵活一点（留有变更或扩展的余地），而且，应该迭代开发

还有一点，开发小组要学会评估工作量和工期。面对一项功能或变动，如果开发小组说不清楚要干些什么，要多久（更妥当地说，多久是一个时间范围），怎么能希望老板能正确地评估收益和代价呢？怎么能正确地决定做还是不做呢？

说到底，客户不能在需求说明书上签字，老板在开发工作完成了才提出变更，最根本的原因是他们对开发小组在项目前期对需求的把握没有信心。他们不知道开发小组对需求理解到什么程度？开发小组的理解与他们的理解是否一致？开发小组到底要花多少时间才能把项目做好（不仅仅是做出来）？如果开发小组能打消他们的疑虑，或许开发过程会顺利许多

非常精辟，个人最欣赏的是movingboy对待需求变更的心态。当需求变得不可控，严重影响到项目开发和组员士气时，我们往往选择了抱怨，自然而然地期望能有一份与客户之间的“需求协议”。不可否认，有些时候，遇到老好人时，这是有可能的。特别是一些重视流程的大公司，甚至主动要求去签署这样的协议。然而，如果开发小组与客户（或老板）尚未建立“高度一致”的需求认知就签署这样的协议，往往是没有意义的，最终吃亏的还是开发人员。试想，待项目交互时，客户才发现很多功能并非他们所期望的，那对开发人员而言，简直就是噩梦。
    需求分析是一个迭代过程，应该是被不断细化的。极端情况下，有些模块的需求甚至要直到其他模块开发出Alpha版本后才有可能被完全明确。正如o6z所说：“需求变更不应该去控制，而应该是跟踪，更好的是做到去引导”。所以说，开发人员应该积极主动与客户（或者协助市场人员）不断地去细化需求。曾经认识这样一位项目经理：项目验收成功后，客户常常开玩笑说，他比客户自己还要了解该项目的业务。
    所以，个人认为，开发人员面对需求变更，最重要的是有一套如何应对变更的方法，或者说是“如何跟踪和引导”的方法。
    呵呵，非常期待o6z大师详细谈谈需求跟踪和引导客户的方法和经验：）

18 楼 温柔的重手 2008-11-11  

软件业就是服务业，服务业就是受气业。
看看医院的护士们，叫病人不要吃什么病人偏要吃，吃了还说你没有跟他交代，自己忘了吃药还说是你没有提醒，这种事情多了去了。
服务员更惨，明明是顾客撞到你身上把你端的东西撞翻了，你还得跟他说对不起陪笑脸。
老师也惨，别人小孩在学校打架打出血了，家长就来学校大闹，要学校赔偿。我靠那小孩打架还会当着老师面打么，老师也不可能每分每秒看着每个孩子啊。
以后教育孩子，打死不做服务业。

17 楼 温柔的重手 2008-11-11  

另外还有一点，客户和老板会认为软件做不完，是程序员的问题。按说，程序员如果就是，老板派多少活，自己就干多少活，就像装卸工一样，那也没多少怨言。反正是拿钱做事，拿多少钱，就做多少事。你系统爱怎么改怎么改，关我鸟事。项目做不完是你的事，反正我做了这么多事就得拿这么多钱。
但事实不是这样的，老板不停的修改，却说这项目是你负责的，做不完扣你钱。管事的管人的管项目的都在管程序员，谁都有提修改的权利，还说项目是程序员负责的，要程序员发挥主动性和创造性，这不扯淡么。

16 楼 温柔的重手 2008-11-11  

建房子，用户知道推倒重来的危险。做软件就不同了，有时候用户觉得，不就改一个地方，随便改改就可以完成，但实际上工作量十分巨大，但跟用户解释，用户听不进去。
比如，我说个，不就是让linux跑sql server吗，有什么难的，下个光盘装上不就行了，况且linux源代码都公开了，你们改改让它们兼容就好。

15 楼 winten 2008-11-10  

这个问题很普遍，只是lz的情况会相对严重些。
1.老板不应该把自己当成客户来提需求变更，客户直接给出的才是需求，这个应该和老板沟通的。
2.接下来就是怎么样从客户那边获取尽可能详细和确定的需求了，这些都需要反复和客户的沟通，沟通就是询问客户和重复客户的回答来进行确认，至于签字确认，这个应该是最困难的事情了，不同情况有不同处理的方法，毕竟我们的目的是从客户那边挖出更详细更准确的需求。
3.如果你们的项目成本是基于实际花费的人月数的话，并且客户也明白，那么可以适用成本这个手段来和客户谈需求的问题，我的经验就是让客户明白这个也需要成本那个也需要成本。

14 楼 xiaocheng 2008-11-10  

楼主的问题很普遍。
1.首先项目要做好各方面的需求，尽可能细，全面。
2.做的过程中不断与客户沟通
3.你们的项目经理要协作好客户与公司的沟通
4.合同要签订好
5.在做项目的过程中就要考虑好各种可能的需求，留好接口。便于修改
6.功能之间尽可能轻耦合

做好了上面的，我想开发是一件快乐的事，要知道维护阶段在软件开发过程中周期是最长的！

13 楼 bonepole 2008-11-10  

需求变更频繁,是个很脑火的问题,但做好基础业务架构在一定程度上能缓和需求变更带来的问题,这也与客户对软件知识的缺乏有一定关系!

12 楼 tiyan200808 2008-11-09  

只要有钱拿 管他那么多去。

11 楼 wokgsi2 2008-11-09  

软件项目开发本身是一个系统工程，它和造一座房子没有什么确别，需要经过一系列过程（需求调研、分析设计、开工干活、各种指标的监控、交付产品），然而现实中造房子很少会有过程中做大的调整或变更，究其原因是它们本身又有一些独特性，建筑行业经过几千年的发展在很多方面已经非常成熟，模式也非常的固定，甚至于很多建筑都是按照很教科书般的模式进行设计和开发的，而软件发展至今也不过6、7十年的历史，在很多领域还在探索甚至摸索当中，甚至对软件领域中项目以及项目管理的定义到目前都没有一个统一标准，所以软件项目开发本身也还在探索和发展中。那么楼主提到的需求调整问题也就不难理解了，当然也无需困惑，这本身就是软件项目开发的实际问题不可逾越，也没有项目可以规避这个问题。前面一堆废话，言归正传，在项目中我一般采用业务流程图+界面原型的模式，也就是做需求分析的同时产生业务流程图和界面原型，这样一来可以清晰自己的思路，二来可以换位思考站在用户的角度考虑流程是否合适、需求是否表述完整，然后在此基础上会和甲方（甲方的系统用户，如果有个负责人接口就更完美了）进行沟通、讨论达成共识，切忌过程中一定要本着做用户需要的软件的思想，否则会很艰难，也会觉得用户很不讲理，当然实际当中这个过程不可能一次性通过，会经过3到4次基本可以确定系统的需求，而且经过这个过程用户对系统也有了一个全面的认识，后期也就不会提出太大的调整，因为实际生活中是人其实都还是将道理的（政府的项目除外，当然政府的项目可以采用其他策略）。

10 楼 drliujia 2008-11-09  

迭代的确是帮助我们和客户“一起”完成优秀产品的好办法，但是现实中往往存在一个很难控制的问题，项目是有成本限制的，不可能陪着客户一直迭代下去，这里存在着一个矛盾，这个矛盾至少我觉得只能靠一些非技术的手段才能去弥合的

9 楼 movingboy 2008-11-09  

看起来一个明显的问题是你们开发小组与客户的沟通、开发小组与老板的沟通不够充分、有效。由于软件开发的专业性，客户与老板都不懂得开发过程的复杂性，不懂得一项变动对项目的成本、时间及其它方面有什么样的影响，不懂得项目后期的变动与前期的变动对项目影响的差异有多大。要靠客户或老板单方面去理解这些是很困难的，所以开发小组必须能提供足够的信息，帮助他们去判断。如果开发小组自己也是懵懵懂懂的，就别希望客户在项目前期就能确认，别希望老板能做出正确的决策

再就你提到的几个具体的问题说说个人的看法：

1.我向老总提写议确认书，并让客户签确认书，可老板说这是不可能的，你功能都没做出来，怎么让他们签啊？

首先就个人经验而言，让客户在需求说明书（或类似的文档）上签字是很难的。就算是双方对需求的理解已经高度一致了，客户仍然会对未完成的东东心存疑虑，毕竟一份需求说明书不能列举所有的细节。此外如果客户签署了需求说明书，万一项目失败了，签字的那个人很可能成为项目失败的责任人。没有人愿意承担这样的危险（注意是危险，不是风险）

我们对于需求沟通的最基本的做法就是反复沟通和迭代开发。其实这并没有什么神奇的地方，道理也象白开水一样简单：

反复沟通是一个从粗略到精细的过程。每次沟通都能减少开发小组与客户对需求的理解的差异，或者修正以前错误的理解，或者比上一次讨论的更深入、更全面

迭代开发使得开发小组能比较快地提交新功能，对需求变更也能快速响应。而每次交付给客户试用的软件能让客户有更直观的感受，能更有针对性地提出问题，双方沟通的效率也可能提高

2.实际上很多时候都是我们在开发或者开发完了，老总提出来要更改的

我觉得开发小组可能需要更深入地理解需求，尽可能在项目前期就搞准确。这可能也需要你们学习更多的行业知识，了解更多的行业习惯。如果不这样，就很可能出现你开发的一个功能你觉得很爽、很酷，但用户却觉得很搞笑、很花哨......

老板或客户不懂得如何评估一项功能或变动会对系统产生多大的影响。比如是否会导致架构方面的改动、改动的范围或程度如何？是否导致返工、返工的工作量如何？（其实个人觉得更应该关注返工对于开发小组士气的影响如何）。所以你们应该在项目前期考虑各种可能的实现，在一定程度内做得灵活一点（留有变更或扩展的余地），而且，应该迭代开发

还有一点，开发小组要学会评估工作量和工期。面对一项功能或变动，如果开发小组说不清楚要干些什么，要多久（更妥当地说，多久是一个时间范围），怎么能希望老板能正确地评估收益和代价呢？怎么能正确地决定做还是不做呢？

说到底，客户不能在需求说明书上签字，老板在开发工作完成了才提出变更，最根本的原因是他们对开发小组在项目前期对需求的把握没有信心。他们不知道开发小组对需求理解到什么程度？开发小组的理解与他们的理解是否一致？开发小组到底要花多少时间才能把项目做好（不仅仅是做出来）？如果开发小组能打消他们的疑虑，或许开发过程会顺利许多

8 楼 tobato 2008-11-07  

   你确定获取目前需求的方法"正确"么?如果获取需求的方法不正确,相对来说后期的需求变更会大很多.这个也不是你可以去"需求控制"的.或许你们根本没有看见"用户的问题"在哪里，用户和你们也没有"开始合作"。没有哪个用户会乐意随意在什么文件上签字，要是你们按纸面所写出来的东西没有解决“用户的问题”，那不是自己打自己的嘴巴么？
    与其与客户在需求问题上越来越对立，不如尝试与客户合作，一起解决用户真正的问题。什么时候你们把自己当成用户了，什么时候就不会觉得需求变更恐怖了.

7 楼 ozzzzzz 2008-11-06  

心态有问题。需求变更不应该去控制，而应该是跟踪，更好的是做到去引导。
我这里倒是要提醒你们关注另外一个问题，也就是项目部署完成和用户开始时候之后3个月的问题。在那个阶段，客户已经对系统的使用和功能有了比较深入的认识，对于系统的有了更多的要求，而如果你们的合同签的不好，很可能会死在那个阶段。

6 楼 litianyi520 2008-11-06  

love1981ly 写道

哎，不要抱怨了 ，那些客户就是那样的了。出了钱就以为很了不起，其实他们很可怜，自己都不知道做什么。只有作了改，改了在做了 。

十分同意，那帮子人都不知道要做什么，今天说这么做，明天又改，后天又改回来， 很爽的 在实际工作中不可能巧妙的解决这样的问题，在我看来必须给他们展现至少3种模板来参考，但还不能排除中途有变，有变就要加班，不加班就要拖时间~怪 只能怪公司的制度不好~工作流程不够规范

5 楼 love1981ly 2008-11-05  

哎，不要抱怨了 ，那些客户就是那样的了。出了钱就以为很了不起，其实他们很可怜，自己都不知道做什么。只有作了改，改了在做了 。