需求变更对软件开发项目成败有重要影响,既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以实施需求变更之前必须做好控制。
需求变更控制的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。 (1)明确合同约束,建立需求基线 需求变更给软件开发带来的影响有目共睹,所以在与客户签订合同时,可以增加一些相关条款,如限定客户提出需求变更的时间,规定何种情况的变更可以接受、拒绝或部分接受,还可以规定发生需求变更时必须执行变更管理流程。
虽然软件开发合同很难在签订之初就能够精确定义每项需求,单靠合同是帮不上忙的,但也不能忽视合同的约束力。 明确和树立需求基线是需求变更的依据。
在开发过程中,需求确定并经过评审后(客户参与评审),建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线,做到小需求可以变更,但大方向要力保不频繁变更。
例如,对于项目中的需求,可以实行分级管理,以达到对需求变更的控制和管理。 (2)建立变更审批流程 在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低开发效率,浪费时间。
正是这种观念才使需求变更变得不可控,最终导致项目的失败。因此,小的需求变更也要经过正规的需求管理流程,否则会积少成多,积重难返。
明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个:一是将客户下达变更的流程尽可能地规范化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。
二是留下书面依据,为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”,一律是无效变更不予受理。
(3)分级管理变更,定时批量处理 软件开发项目中,“客户永远是对的”和“客户是上帝”并不完全正确,因为在已经签定的项目合同中,任何新需求的变更和增加除了影响项目的正常进行以外,还影响到客户的成本投入收益。因此,用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。
当遇到客户提出需求,不及时处理可能会使项目不能验收通过时,也不能一味拒绝不予开发。因此,当客户坚持变更新需求时,可以建议客户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。
例如,每周或每两周甚至每月召开一次需求变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,尽量避免由于处理零碎变更而影响项目进度。针对会议结果可向客户正式提交一份需求变更计划,注明变更引起的时间、成本、工期代价和增加工作量等。
要求客户配合需求变更计划,确定变更时限,控制变更规模,过时变更不候,离谱变更不做,保大局弃小变。 (4)安排专职人员负责变更管理 有时开发任务较重,开发人员容易陷入开发工作中而忽略了与客户的随时沟通。
因此,需要安排一名专职的需求变更联络人员,负责与客户及时交流,跟踪和汇报需求变更完成进度和情况。同时,可以成立项目变更控制小组,负责裁定接受哪些变更,小组由项目所涉及的多方人员共同组成,应该包括客户方和开发方的决策人员在内。
(5)确认客户是否接受变更的代价 要让客户认识到变更都是有代价的,要和客户一起判断需求变更是否依然进行。例如,变更是没有问题的,但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。
一般来说,如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果。通过与客户协商,这样开发团队即使没有回报,也不会招致公司和客户双方的埋怨。
如果客户认为该变更虽然有必要但是可以暂缓,双方签署备忘录后留待以后解决。如果客户认为该变更可有可无,多数情况下会取消变更。
这样即可防止频繁变更,也让客户认识到不是所有的需求都需要变更。
项目是以客户的需求为中心,而不是为技术而迁就需求。
本章包括以下内容: 一. 让客户畅所欲言,罗列出所有的需求 二. 透过现象分析潜在的需求 三. 利用自然的语言描述项目模型 四. 利用示意图和图表将用户的需求表现出来。 五. 什么人要看需求分析报告? 六. 建立需求变更日志,制作新版本的需求分析报告。
七. 本阶段重点工作角色 八. 总结 一:让客户畅所欲言,罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚,并把所有的要求罗列出来,不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量,从而被今后客户无止境的变更拖入泥潭,直接明白地跟客户把问题和要求一条条地列出来,把条理、归纳、分析先都扔到一边去,将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显,假如客户的需求做的都不完整,随时可能会产生意想之外的变更,甚至这个变更会破坏已经做的模型及结构,那么这个项目从开始就注定了会失败;比如站点所有的功能都实现了,本地测试起来也没有什么问题了,但是你却不知道客户的系统是要承受每天100万独立IP的访问,而你原来想当然的以为了不起就是1万独立IP访问的访问流量,稍微有经验的开发人员都会明白这样的设计是个灾难,无论是应用服务器、数据库还是程序全部要重新开发! 二:透过现象分析潜在的需求 很多情况下客户并非专业人士,在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关,这需要我们去为客户进行分析、归纳和整理,尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。 客户往往对需求的概念是非常模糊的,大多时候给出的需求都是笼统而且尺度难以控制的,这就要求业务人员在倾听了客户的详细说明以后,帮助客户进行整理和分析,同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
比如在为客户设计办公自动化系统的时候,也许就要为客户预留将来与他们的业务单位进行交互的通道;在设计邮件系统的时候要考虑可能会需要广告管理服务器;设计网络电子商店时今后增加库存产品进销存统计分析等等;限于时间财力的考虑,客户通常能够接受分阶段实施的开发过程,在需求分析时,提早为客户设想到今后的需求变更除了使项目开发更加顺利以外,也为今后业务的进一步深入打下了更好的基础。 笔者曾负责一个大型新闻网站的设计,当客户拿着将近五十页厚的一本设计要求报告时,我发现有四十页的内容对程序开发来说都是重复的,而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮,并且没有做任何说明,仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作,客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发,通过协商,客人同意了修改成站内搜索的引擎。
三:利用自然的语言描述项目模型 在业务员与客户进行沟通和调查时撰写的需求分析,尽可能用自然的语言进行描述,虽然客户的水平和资历有所不同,但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义,不至于在理解上产生偏差。对客户而言,这样的模型描述最接近真实,容易参与修订,并能以此为测试和验收的依据。
你必须面对这个现实:需求变更是不可避免的。项目经理应该做的,是如何在发生需求变更的情况尽量减少其对项目的影响。需求变更不可避免,不是说就不做需求变更的控制了,需求变更如果量很大,对项目的影响无论如何也降不下来,因此还是要在控制需求变更上下功夫,但不要奢望杜绝需求变更。
对于管理信息系统的项目,其需求的核心点在于业务流程,如果业务流程保证没问题了,那么系统就不会发生大的需求变更,界面调整一下,多一两个字段,甚至多一两个查询页面,都对系统不会产生太大的影响;但是如果流程变了,比如中间加了一个环节,或是环节间数据交互的变更,都可能会给整个系统带来很大甚至致命的影响,有可能因为某流程的变化导致整个系统都要重新翻一遍,这样的修改对质量的影响是非常可怕的。
要把握用户的流程,首先看用户这个业务流程是否正在正常的运行,在这种情况下,你把这个流程调研清楚了就没有问题了;但是如果业务流程是用户新构想出来,正指望着你通过系统去实施(也可以说试试)这个流程,那你就要小心了,必须仔细的分析这个流程的可行性,主动的和客户探讨这个流程的缺陷,可能面临的问题,必要时请有关专家做咨询,总之,一定要保证流程的可行性,否则流程一旦执行不下去,虽然软件本身没有任何质量问题,你还得改。
对于流程分析要了解哪些关键点呢,首先当然是有哪些环节,环节间的运作关系,比如报销流程,有填单、部门领导审批、财务稽核、主管副总审批、结算这些环节,简单来说是依次传递的;其次要了解每一环节的控制点,比如领导审批,可以通过、不通过,一定要注意不通过这个非正常流程的下一节点,也许是终点(该报销单作废,要求报销人重填),也许又到了填报环节(报销人可以修改后重新提交审批);然后一定要搞清楚环节间的数据和传递关系,这是非常重要的,因为这些数据和关系至少会影响两个环节的处理,甚至可能影响整个流程的处理,而其他的无需传递的数据项,一般只对某个环节的处理产生影响,即使发生变化也无关大局。
这三点把握住了,流程也就基本清楚了,但是要注意,了解这些信息首先是通过和客户的直接交流,同时一定要注意分析客户提供的每一环节的表单和最终的分析报表,确定每一信息的来源,因为表单和报表的数据理论上讲都是通过流程的处理得到的,它们真的都包含在流程处理中了吗?
你必须面对这个现实:需求变更是不可避免的。
项目经理应该做的,是如何在发生需求变更的情况尽量减少其对项目的影响。需求变更不可避免,不是说就不做需求变更的控制了,需求变更如果量很大,对项目的影响无论如何也降不下来,因此还是要在控制需求变更上下功夫,但不要奢望杜绝需求变更。
对于管理信息系统的项目,其需求的核心点在于业务流程,如果业务流程保证没问题了,那么系统就不会发生大的需求变更,界面调整一下,多一两个字段,甚至多一两个查询页面,都对系统不会产生太大的影响;但是如果流程变了,比如中间加了一个环节,或是环节间数据交互的变更,都可能会给整个系统带来很大甚至致命的影响,有可能因为某流程的变化导致整个系统都要重新翻一遍,这样的修改对质量的影响是非常可怕的。 要把握用户的流程,首先看用户这个业务流程是否正在正常的运行,在这种情况下,你把这个流程调研清楚了就没有问题了;但是如果业务流程是用户新构想出来,正指望着你通过系统去实施(也可以说试试)这个流程,那你就要小心了,必须仔细的分析这个流程的可行性,主动的和客户探讨这个流程的缺陷,可能面临的问题,必要时请有关专家做咨询,总之,一定要保证流程的可行性,否则流程一旦执行不下去,虽然软件本身没有任何质量问题,你还得改。
对于流程分析要了解哪些关键点呢,首先当然是有哪些环节,环节间的运作关系,比如报销流程,有填单、部门领导审批、财务稽核、主管副总审批、结算这些环节,简单来说是依次传递的;其次要了解每一环节的控制点,比如领导审批,可以通过、不通过,一定要注意不通过这个非正常流程的下一节点,也许是终点(该报销单作废,要求报销人重填),也许又到了填报环节(报销人可以修改后重新提交审批);然后一定要搞清楚环节间的数据和传递关系,这是非常重要的,因为这些数据和关系至少会影响两个环节的处理,甚至可能影响整个流程的处理,而其他的无需传递的数据项,一般只对某个环节的处理产生影响,即使发生变化也无关大局。 这三点把握住了,流程也就基本清楚了,但是要注意,了解这些信息首先是通过和客户的直接交流,同时一定要注意分析客户提供的每一环节的表单和最终的分析报表,确定每一信息的来源,因为表单和报表的数据理论上讲都是通过流程的处理得到的,它们真的都包含在流程处理中了吗?。
需求变更的控制关键在于建立建立相应的控制组织、变更控制和跟踪系统以及规范变更流程,主要有:
1、建立组织。项目启动时,需要尽可能的与客户沟通,建立正式的对变更进行控制的组织,成员包括双方高层(挂名)、甲乙双方的项目负责人、相关的需求负责人等。如果客户认为无需单独设置这样的正式组织,也会要求客户指定项目的负责人,每个相关的业务科室指定一名需求负责人,这样做的目的是如出现变更可以很快的临时组建一个对变更负责的组织,并且可以找到相应的负责人;
2、建立变更控制和跟踪系统。建立该系统的目的是统一管理需求变更和跟踪变更的状态,便于项目组测试人员、开发人员、系统分析员以及PM相互之间的沟通和交流;经比较和选型,可以选用了JIRA作为变更控制和跟踪系统;
3、规范流程。甲乙双方的项目组成立后,根据角色定义,确定变更流程。
1)变更申请。系统界面如按钮的位置、字段的位置的细微调整,不涉及到业务规则,对基线基本没有影响的变更,由测试人员直接在变更控制系统中提出;其他如操作风格的较大变化、业务规则的变化等,均要求客户提出电子和书面的需求变更单;
2)变更评估。由项目组组织人员对变更进行变更的合理性分析,变更替换方案分析,工作量的估算以及涉及什么模块、影响什么模块等影响分析;
3)变更决策。根据上节确定的沟通策略,与客户沟通交流,确定变更的处理方式;
4)变更实施。由测试人员在变更控制系统中填写变更信息(状态:待处理),由系统分析员填写处理方法和影响分析后交由开发人员实施(状态:处理中);
5)变更验证。测试人员根据变更控制系统的变更状态反馈(状态:已解决),待相应的版本发布后,对变更进行验证测试,这时候特别要注意的是记录该变更的修改是否引起了该模块或其他模块产生缺陷。通常,测试人员根据系统分析员在变更控制系统中标注的影响模块,逐一进行回归测试,以确保不影响原有模块的前提下变更已正确实施;内部测试完毕后,如系统已上线,则由客户相关负责人在模拟生产环境中进行验收测试;
6)沟通归档。变更验证后,测试人员关闭变更(状态:已关闭),项目经理告知客户已测试完毕,沟通发布时间并说明那些模块可能有影响以及发现问题的反馈途径和方式。
通过以上几种手段,如执行实施到位,基本可以有效的把变更置于控制之下。
最后,值得一提的是,变更实施或者系统缺陷修复涉及到多方面的人员,可能牵涉软件系统中的多个模块,处理和验证的流程复杂,沟通等管理成本高昂,如果变更和质量控制不好,会直接影响项目的进度和成本。
项目是以客户的需求为中心,而不是为技术而迁就需求。
本章包括以下内容: 一. 让客户畅所欲言,罗列出所有的需求 二. 透过现象分析潜在的需求 三. 利用自然的语言描述项目模型 四. 利用示意图和图表将用户的需求表现出来。 五. 什么人要看需求分析报告? 六. 建立需求变更日志,制作新版本的需求分析报告。
七. 本阶段重点工作角色 八. 总结 一:让客户畅所欲言,罗列出所有的需求 让用户将所有的想法尽可能的阐述清楚,并把所有的要求罗列出来,不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量,从而被今后客户无止境的变更拖入泥潭,直接明白地跟客户把问题和要求一条条地列出来,把条理、归纳、分析先都扔到一边去,将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显,假如客户的需求做的都不完整,随时可能会产生意想之外的变更,甚至这个变更会破坏已经做的模型及结构,那么这个项目从开始就注定了会失败;比如站点所有的功能都实现了,本地测试起来也没有什么问题了,但是你却不知道客户的系统是要承受每天100万独立IP的访问,而你原来想当然的以为了不起就是1万独立IP访问的访问流量,稍微有经验的开发人员都会明白这样的设计是个灾难,无论是应用服务器、数据库还是程序全部要重新开发! 二:透过现象分析潜在的需求 很多情况下客户并非专业人士,在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关,这需要我们去为客户进行分析、归纳和整理,尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。 客户往往对需求的概念是非常模糊的,大多时候给出的需求都是笼统而且尺度难以控制的,这就要求业务人员在倾听了客户的详细说明以后,帮助客户进行整理和分析,同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
比如在为客户设计办公自动化系统的时候,也许就要为客户预留将来与他们的业务单位进行交互的通道;在设计邮件系统的时候要考虑可能会需要广告管理服务器;设计网络电子商店时今后增加库存产品进销存统计分析等等;限于时间财力的考虑,客户通常能够接受分阶段实施的开发过程,在需求分析时,提早为客户设想到今后的需求变更除了使项目开发更加顺利以外,也为今后业务的进一步深入打下了更好的基础。 笔者曾负责一个大型新闻网站的设计,当客户拿着将近五十页厚的一本设计要求报告时,我发现有四十页的内容对程序开发来说都是重复的,而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮,并且没有做任何说明,仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作,客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发,通过协商,客人同意了修改成站内搜索的引擎。
三:利用自然的语言描述项目模型 在业务员与客户进行沟通和调查时撰写的需求分析,尽可能用自然的语言进行描述,虽然客户的水平和资历有所不同,但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义,不至于在理解上产生偏差。对客户而言,这样的模型描述最接近真实,容易参与修订,并能以此为测试和验收的依据。
可以在合同上规定,
在正式确定《需求说明书》前,可以由客户自由提出需求(当然需求分析人员保证需求的质量)。
一旦《软件需求说明书》完成,并且客户签字确认了它。那么就禁止客户随意的更改需求。
1)客户新/变更的需求按照某个价格另外的收取费用。
2)开发方有权拒绝客户的某种新/变更需求。
不过这要在合同中明确客户在确认了《需求说明书》后不得随意的提出新/变更需求。
需求变更,即对项目或者软件开发需求的更变,是指在跟客户签订了项目或软件开发协议之后,在完成交付之前,客户提出的对项目或者软件的功能或非功能性的更改要求。
客观地说,“项目一旦启动,变更也就随之而来”,但是,需求的变更必然会影响到项目的开展或者软件的开发,需求变更对项目或者软件开发成败有重要影响,我们既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以控制需求变更才是最好的应对策略。当然,需求变更控制的目的不是控制变更的发生,而是对变更进行科学的管理,要确保变更有序地进行。
一般地说,为了确保需求变更符合双方的利益,可以采取如下措施来控制需求变更:
1.分级管理客户需求,重点客户重点管理;
2.项目开发生命周期全过程需求变更管理,确保整个项目顺利完成;
3.专人负责需求变更管理工作,确保工作同步进行;
4.契约化管理需求变更。合作双方在签订协议之初,书面约定需求变更的提出方式、评价程序、修改要求、执行过程以及验收要求等。只有这样,才能确保需求变更按程序和要求有序进行。
5.需求变更必须提前沟通,双方要加强信息交换,防止搞突然袭击,更不能提出超越双方能力的需求变更。
声明:本网站尊重并保护知识产权,根据《信息网络传播权保护条例》,如果我们转载的作品侵犯了您的权利,请在一个月内通知我们,我们会及时删除。
蜀ICP备2020033479号-4 Copyright © 2016 学习鸟. 页面生成时间:3.795秒