需求变更的管理流程范文
时间：2024-03-05 17:49:06
导语：如何才能写好一篇需求变更的管理流程，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。
篇1
在电力施工过程中，需求变更的问题是不可避免的，它是通过流程把变更纳入可管理的范围内，避免产生这种混乱，但是如果需求变更的发展失控的话，就会使项目陷入一种混乱且不稳定的状况，从而严重破坏了整个项目的管理过程，如何正确进行需求变更的控制，是一个很重要的管理过程。所以，为了能更好地控制电工管理中的需求变更，我们必须做一些措施来使需求变更有计划的、有目的、更顺畅的进行，从而使电工施工过程进行良好的变更控制。
1 电工施工中引起需求变更的主要因素
在电力施工过程中，引起需求变更的因素有很多，例如增减工程量的清单的内容和工作量，包括施工进度计划的变动，施工程序的改动，质量标注的调整，技术要求的修改和补充，这些都是在电力施工过程中引起需求变更的因素，可以分为：
1、从需求变更的性质来看，引起需求变更的因素分为主观因素和客观因素。
①主观因素。例如电力设计工作的不细致，从而使工程实施过程中发现了很多在设计文件中没有考虑到或估算不准确的工程量，致使必须改变施工项目或增减工程量。
②客观因素。这就是指在电力施工中因为一些自然灾害或不可预见的事故、社会因素引起的停工和工期拖延等，这样的工程变更是不可避免的，也是无法预料到的。
2、从引发需求变更的对象来看，引起需求变更的主要因素
①某些施工单位主动提出工程变更。某些施工单位会向设计单位提出对图纸、设计说明不明确的问题的询问，或是提出技术修改图，对施工方法、施工议案提出修改，或是要求修改图纸等问题，这些都是施工单位主动提出的需求变更。
②由监理单位提出的工程变更。在电力施工过程中监理工程师要经常在施工现场巡视，凭借着他们自身的丰富实践经验，他们往往会发现工程中存在着很多问题，并针对这些问题提出工程变更的建议。
③设计单位提出需求变更。在施工过程中，设计单位或者是其驻工代表对原设计中存在的一些错、漏、缺、碰等问题，提出一些设计的修改和完善。
④由该工程的业主提出的工程变更。为了更好地完善使用功能，从而保证工程的质量、加快工程进度等原因，在施工过程中，业主时常提出一些工程变更的要求。
在电力施工管理中，由于需求变更会引发工程量现场签证、设计、进度的变化、合同变化等问题，我们需要对需求变更进行严格控制，从而将项目变更的影响降低到最小。
2 对需求变更的控制策略
对于在电力施工过程中，对需求变更的控制，如果仅仅按需求加强监督执行是不够的，因为这样的做法会造成项目各方对变更控制的乏力和被动，从而引发工程质量、工程成本等一系列问题的产生，甚至可能使在发展中发生变更失控的现象，这是要绝对避免的。要想在电力施工管理中，使需求变更得到控制，就要确定一个选择、分析和决策的流程，使所有的需求变更都要遵循和支持改流程，从而通过这个流程对需求变更进行控制。但是在遵循这个流程中还需要注意几方面的问题：
1、要有明确的授权。在电力施工管理之前，要事先明确工程各方有权提出变更申请的人员和有权受理变更的人员，决不允许未授权的人员进行私下协商，只有这样做才可以对需求变更有整体的控制。
2、对需求变更进行必要的审核。对电力施工管理中的需求变更不是所有的变更都要执行和立刻执行，审核的目的是决定是否需要变更和何时变更。
3、评估变更的代价和影响。在电力管理中的需求变更都是有代价和影响的，所以在确定变更之前，必须事先评估变更所带来的代价和影响，使工程双方了解了变更的后果之后，再一起做出判断和认可。
4、要严格执行需求变更的管理流程。小的变更也会引起变更最终的不可控制，所以小的变更也要进行正规的需求管理流程，并且施工单位要严格避免在变更确认之前，要按变更设想进行施工，否则可能会造成需求变更的整体失控。
3 需求变更的控制流程
在电力施工管理中，需求变更控制的主要手段是要明确定义流程并且可以严格的执行，主要分为提出、评估和实施的三个步骤。首先，要由授权的人员进行提出需求变更，无论是哪一方提出的需求变更，都要履行工程变更的手续，并以书面形式交给总监。其次，要由总监召集专业的建立工程师来进行审查，认为可行后，设计单位根据业主要求的设计变更进行设计，变更要求必须以书面形式给出，然后设计单位签署意见和设计出图。设计单位完成施工图的设计后，业主需要把图纸给专业的职能部门和审图机构审核，审核通过交还业主，再由业主组织设计、施工、监理各方一起对图纸进行会审，尽可能地把存在的问题提出来，进行研究和探讨，并由设计单位做出解答，形成文字资料后作为日后施工的依据。最后要由总监给出确认后的工程变更通知后，才可以交由施工单位进行执行，按照施工图进行施工。
需求变更实施之前，是要经过工程各方的审核、评估和确认的，在进行电力实施过程中要跟踪与验证，确保变更的正确执行，在变更实施的整个过程中，在没有拿到工程变更通知前任何一个步骤出现异议，整个流程都要重头开始，并且施工单位也不会进行施工，这样是为了确保整个需求变更始终是可以控制和管理的。
4 应注意的问题
目前，很多企业都在遵循质量与健康、安全和环境管理体系的互相补充、相辅相成，在电力施工过程中，他们为了在需求变更中遵循质量、安全和环境管理的一体化，为了更好地实施“ISO9000质量管理体系”和“HES-MS”的管理，他们将“ISO9000-QMS”、“HSE-MS”、“ISO14000-EMS”整合成一个系统，但是在具体操作中会遇到很多问题：
1、对“ISO9000质量管理体系”和“HES-MS”的管理范围必须明确划分，对于它俩的共用文件和资料应按所属管理的范围划分到所属的系统中，对影响二者的的文件应确定与“HES-MS”的接口，制定出明确的管理文件。
2、机构要统一，发挥资源优势。很多企业把质量、安全、环保等职能部门都分开属于不同部门管理，这样日程工作中协调减少了，增加了管理费用，造成了资源的浪费，因此各个部门机构要配备管理人员，从实际出发，健全管理机构。
3、体系要统一，工作重点要有所侧重。针对企业的具体情况，不同性质的企业需要遵循的管理体系是不同的，在电力施工管理过程中，是必须要遵循安全、质量、环境体系的一体化的，从而确保施工过程都有序进行，保障劳动者的安全和健康，实现经济效益、社会效益和环境效益的统一。
5 结论
在电力施工管理过程中的需求变更的发展如果得不到很好的控制，项目就可能会陷入不能正常进行的状态，变更的控制对项目正常有序的施工有着重要的影响，所以，如何正确的进行需求变更的控制，是一个重要的管理过程。定义需求变更是保证变更正常有序的一个有效的措施，并且需求变更流程使得变更施工能够有计划、有目的地进行，也只有这样才能对整个施工过程进行良好的变更控制。
参考文献
[1]范伟健.浅议电力施工管理中的需求变更管理[J].现代企业文化，2010（18）
[2]罗韦军.浅析电力施工管理中的需求变更控制[J].中国电力教育，2006（5）
篇2
从理论上讲，需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。这些需求在项目执行过程中都可能发生改变，即发生需求变更。
需求变更的表现形式也是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部，比如对项目人员的临时离职会发生突然的需求等。
原因
1、需求信息错位
在需求分析员确定客户需求之前，毫无疑问要和客户做好深度沟通。但是由于沟通渠道的限制，以及双方能力、教育、习惯背景的限制，往往会出现信息沟通偏差，就是我们说的需求信息错位。
当客户向需求分析人员提出需求的时候往往是通过自己的想法用一般语言来表达的，而且是基于客户对自己需求的理解角度上表达的，这就引起表达的结果对于真实的需求来说是一种仅仅从某个角度的一般描述，远远不能保证这样的描述可以得到百分之百的正确理解。以前有个盲人摸象的故事，这个例子可以解释一下为什么存在信息的偏差:顾客想要画一头大象，可是却不清楚大象的身子、耳朵、四条腿以及尾巴是什么具体样子，只能描述出这几个部分大致像什么。于是顾客告诉分析员，“我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子”。分析员听到这些，就按照自己对墙、扇子、柱子、绳子的理解画出了“大象”。
结果可想而知。然而这种现象在软件项目需求变更中并不少见的。
这里面还有一个细化工作的问题。细化工作是一般由需求分析人员完成，一般是根据客户提出的描述性的、总结性的文档去细化客户需求，将这种需求细化到一定程度后，就可以提取其中的一个个细小的功能，并给出描述。
但是不能光靠分析员做细化工作，还应该把这些细化过的功能描述与客户继续深入地沟通，否则以后将会发生因为细化而引起的不能适应范围的问题，比如原来是手工填入的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。
2、建设期的沟通局限性
现实中，一个大中型系统的建设可能要持续较长的一段时间。在整个建设内，当客户提出要求时，因为不能看到系统的运行情况，客户和开发商双方就会认为需求沟通方面不存在什么分歧，然而事实上还常常会有需求最终期限的问题，此时开发商就已经开始工作了。
最后当客户从开发商那里拿到差不多可以试用的产品时候，因为现在可以实际操作，他就会对现实的系统提出很多问题，就是我们说的需求变更，比如系统的界面、操作、功能、性能等方面。
3、客户所在环境的改变
当前客户的运营情况不确定，有可能客户行业的竞争度高，需要随时做出调整和反应，那么他们自然会经常提出需求变更的要求;也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发变更是需要随时准备应变。
一般说来客户会要求改变界面，改变操作方式，甚至改变业务，客户甚至会说:“当时我是那样要求的，不过现在我们的业务调整了。”这一切都是由行业大环境成的，所以对于这方面的需求变更必须要有一定的预测措施。
4、开发商的系统升级
为适应市场需求，或是由于竞争等因素，开发商自身会有可能存在进行开发系统版本的升级或性能改进、设计修正的要求，因此会出现需求变更。这时谁也无法绕开这个问题。
从上面的分析可以看出，就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以项目团队，或者说是开发商不要梦想会存在多么理想的需求分析，应该从一开始就要有客户需求变更一定会存在的准备。
代价
任何项目只要存在某个方面变更，那么就要付出对应的代价。需求的变更通常意味着需求的增加，同时也意味着相应的代价。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求所需要的成本，包括时间、人力、资源等方面。
同时，在评估代价、与客户讨论的过程中，要让客户了解变更的后果，变更之后面临最大的问题就是项目延期，让客户一起做是否继续修改还是要接受修改后果的决策。这样就会出现三种可能:
1、客户接受延期的后果，开发人员按客户要求做出修改，让客户知道为此需要付出延期的代价;
2、客户认为代价太大，那么开发人员就不必修改了，可以记录下需求，待到下一版本再做修改;
3、客户不接受变更的代价，导致项目夭折。
所以变更引起的后果一定要和客户沟通，确保客户了解后果。如果客户不知道项目开发人员为变更付出的代价，对他们的辛苦便难以体会，以致没完没了的提出新的变更。
然而对于这样的现状，我们该怎么办呢？
积极应对
1、完善软件项目需求变更的管理
需求变更管理就是要把项目的需求变更对项目的负面影响降到最低，即不为消除，只为减少。需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。
这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。
当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响。
2、项目启动阶段的变更预防
应对变更应该是从项目启动的需求分析阶段就开始了。 首先就是要和客户有一个深度沟通的过程，然后再做需求细分，做需求分析，同时在做这些的时候和客户实时沟通。
对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，双方的分界线也就越清晰，所以用户和项目经理扯皮的幌子就越少了。假如需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。
如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费，这样就可以弥补一下项目开发团队的损失。所以只要前面的需求分析做好了后面就会一帆风顺了。
3、项目实施阶段的需求变更
项目的实施过程中，需求变更是必然的，但是同时也是可控的、有益的。项目实施阶段的变更控制需要做的是分析变更请求以及评估变更可能带来的风险和修改基准文件。主要从以下几点考虑:
1）需求要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，无论是开发方还是出资方在项目开始前都要明确一条:需求变，软件开发的投人也要变。
2）需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。
3）小的需求变更也要经过正规的需求管理流程，否则会积少成多。冰冻三尺非一日之寒。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间，这样就使需求逐渐变为不可控，甚至导致项目的失败。
4、项目收尾阶段的总结
能力的提高往往不是从成功的经验中来，而是从失败的教训中来。项目开发团队要提高对项目总结的重视，以从以前的项目中吸取教训。
链 接
实施需求变更管理的的原则：
建立需求基线；
制定简单、有效的变更控制流程，并形成文档；
成立项目变更控制委员会或相关职能的类似组织，负责裁定接受哪些变更；
需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认；
篇3
一番景象。
自上而下
需求变更是软件开发人员面临的最大难题，很少有一个项目能从头至尾保持同样的需求。因此，可跟踪性是所有软件开发流程的基础部分，它可以及时发现流程中的问题，并及时修复。统计表明，如果在需求收集阶段修复一个缺陷需花费1美元，那么在设计阶段修复该缺陷就需花费两美元。依此类推，直至产品投入使用后才发现该缺陷，修复所需的费用将增至69美元。
通常情况下，跟踪通过自上而下的方法得以实现，即从需求定义开始，经过执行、构建、组装直到交付工作。自上而下的跟踪、报告有助于项目经理和测试人员在开发流程中协调分配、规划开发和监控状态。自上而下方法的核心是，确保正确管理和跟踪需求变更，保证软件代码的变更与需求变更同步。
形成闭环
但是，对于大多数质量、审计和测试验证程序而言，自上而下这种跟踪形式仍有不足，因为它不能分析实际生产的产品，也就无法确保按计划交付预期的需求、修复或请求，至少在开销极大的测试阶段之前无法完成上述任务。在此背景下，闭环跟踪的方法应运而生。所谓闭环跟踪就是将自上而下和自下而上两种方法结合在一起。自下而上的方法是通过有效的需求驱动开发流程来控制变更的执行，跟踪每个开发任务。此方法使用先进的构建分析和报告功能来实现，使得项目主管和测试人员可以在构建或测试阶段有效实施错误修复。
闭环跟踪的优势在于可以确保最后交付的代码符合客户的需求；开发人员可对流程中的各种变更进行全面评估，从而提高项目管理的可见性，增强项目管理的可预测性；有助于提高开发产品质量，提高客户满意度；推动符合能力成熟度模型集成(CMMI)标准的过程改进，有助于企业降低研发投入成本，加快投入产出进程。
篇4
通过对每一次收养过程进行严格的流程控制，动物保护协会最大程度上保护了动物的权利和人类的安全。其实流程存在于人类工作和生活的每一个地方，尤其是多人协作的情况，为了保证行动的最佳效果，减少失误，最佳的流程往往会被固定下来。不要小看流程固化的重要性，即使任何一个简单的活动，在不断的重复和大负载情况下，没有固定的执行流程，出错的机会还是很大的。
用流程应对变更
复杂的软件开发通常需要大量的人员参与，这其中流程的作用至为重要，尤其是对于开发过程中的各种变更，例如需求的变更、软件版本的变更等，更需要一套严密的流程体系来管控，才能最终保证变更被成功控制，而不是演变成为灾难。
软件开发不同于传统意义的工程技术(如建筑、机械等)，市场变化以及技术上的高速更新都注定了软件变更是非常频繁并且是不可避免的，可以说变更是软件开发的基石。一方面在软件开发环境下的内部活动以新特性、新功能增强以及缺陷修复等方式不停地制造着变更，另一方面外部因素，例如新操作环境，新工具的集成，工程技术和市场条件的改善等以另一种力量驱动着变更，而管理变更的能力就成为项目成败的关键。
作为国第一家在纽交所上市的软件企业，东南融通在不断发展壮大过程中就遇到了这种困扰。东南融通在全国设有3个研发中心、5个技术交付中心和70个服务机构，为了保证异地开发、交付团队的协同工作，提高软件质量，2006年，东南融通决定引入成熟的软件配置、变更工具。
首先在处理需求变更上，东南融通副总裁叶寿生告诉记者，在之前在没有成熟的执行流程情况下，客户A提出了需求，开发人员赶快在软件中进行修改，很快B又提出了一个不同的需求，而这两个需求可能是冲突的，开发人员就无所适从，同时混乱的修改过程使得最终的软件质量也无法确保。
而在引入了IBM Rational的配置及变更管理套件ClearCase和ClearQuest后，需求变化得到了很好的控制。需求变更提出后，被提交到变更委员会进行评估，以确定这个变更是否可以实现，需要多长时间、多少投入，同时经过分析后的需求也更加清晰，更易于开发者实现，
另外在版本管理上，采用了ClearCase和ClearQuest后，开发团队，尤其是异地协作的开发团队使用的版本得到了统一。叶寿生介绍，在每一个项目实施完成后都会形成一个不同的软件版本，而这些版本对应哪个客户，之前都要靠人的脑子来记忆，结果很在维护的时候就容易造成混乱，不知道该在哪个版本上进行更新和重新部署。
东南融通测试中心经理翁旭骥详细地介绍了身处厦门和上海的开发团队和身处厦门的测试团队是如何通过ClearCase和ClearQuest进行异地协同开发的。
首先，厦门的测试人员测试并提交了多个缺陷，系统会在指定的时间自动双向同步厦门和上海的ClearQuest数据库和ClearCase的VOB(Versioned。bJect Base)库。
当ClearQuest数据库接收到数据后，系统自动发送邮件给上海该项目的缺陷分配人，缺陷分配人收到邮件通知后，会登录ClearQuest并对待分配缺陷进行分配。当缺陷分配完后，修改缺陷的开发者就会收到缺陷处理的邮件通知。
当开发人员处理完分配给他的缺陷后，便会在ClearQuest中执行Resolve操作，于是缺陷自动变成“已解决”状态，等待测试人员验证。
当执行同步的时间到达后，系统自动将ClearQuest数据库以及ClearCase的VOB库进行双向同步。在同步完成后，厦门的测试人员会收到验证缺陷的邮件通知。测试后如果缺陷仍然存在，上海的开发人员就可以看到这条被驳回的缺陷，如果修改后该版本的程序验证通过，厦门的管理员就会在集成流上打一条基线，这条基线标识的版本即测试通过的版本。
ClearCase带来的对软件开发流程的严格管控，工作流程得到了固化和自动执行，免去了人工控制流程中可能出现的遗漏或拖延。同时，ClearQuest会对开发过程中的所有变更进行详细的记录，并要求修改者注明修改理由，并能够追溯到开发中修改的任意一个版本，让每一次变更都有迹可循。更值得一提的是，ClearCase还同时适用于Linux、Unix和Windows平台，最大程度地消除了平台之间的鸿沟，确保了团队合作的亲密无间。
在导人了Rational UCM以后，东南融通拥有了更严格而顺畅的开发流程，不但能够有效掌控开发周期和质量，也能有效降低维护成本，数据统计方面，更节省了50％以上的人力投入。
不仅是工具，更是平台
翁旭骥介绍，起初，测试部门采用了好几套开源的工具，但是这些工具彼此之间是割裂的，版本控制和缺陷跟踪彼此无法沟通，这给项目管理造成了很多的麻烦。而之所以看重IBM Rational的配置及变更管理套件，翁旭骥认为他们主要看中了两个方面，首先是其中蕴含的优秀的管理思想和最佳实践，其次是平台化的工具和强大的二次开发能力。
ClearCase和ClearQuest首先是Rational的一部分，它渗透进了Rational RUP(统一软件开发过程)的思想，变更被置于整个软件工程的视野下来考虑。另外针对变更管理，IBM提出了UCM(统一变更管理)的解决方案，具体产品就是Rational ClearCase和ClearQuest。
UCM是第三代的配置管理解决方案，在UCM中有两个重要概念：活动管理和工件管理，它们提供对所有类型的变更请求(例如产品缺陷、增强请求、文档变动等)的捕获和跟踪，还有对贯穿项目生命周期的所有工件的管理框架。
UCM通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次，根据活动(activity)来管理变更。通过Rational UCM，一个开发活动可以自动地同其变更集(封装了所有用于实现该活动的项目工件)相关联，这样避免了管理人员手动跟踪所有文件变更。
篇5
[关键词]项目管理软件需求开发进度成本质量管理模型
一、引言
软件需求开发是软件工程的一个重要环节，在软件生命周期中的需求、设计、编码、测试和维护等各个阶段中，需求开发处于软件工程的开始部分，它提供构建软件项目的根基，决定软件开发成果满足客户需求的匹配程度。软件需求开发环节的失误会随着开发进度的扩大而蔓延，资料表明，软件项目中由于需求开发管理混乱而造成的返工开销几乎占了总开发的50％。本文应用项目管理理论分析软件需求开发阶段的系统构成，并设计管理模型来提高软件需求开发的管理效率。
二、软件需求开发管理过程
由于计算机技术的迅速发展，使得软件需求具有模糊性、不确定性、变化性、主观性等特点，并带来软件需求开发管理的复杂性。软件需求开发是一定的组织利用有限的资源在规定的时间内完成，可以作为项目来进行管理，其管理过程由需求获取、需求分析、编写软件需求规格和需求验证四个阶段构成。
1.需求获取
需求获取是在问题和最终解决方案之间架设桥梁，其主要任务是和用户方的领导层、业务层人员进行沟通，获取用户的具体需求，并了解用户的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况，同用户建立起良好的沟通渠道和方式。软件需求获取的方法有：与用户交谈，向用户提问题；参观用户的工作流程，观察用户的操作；用户工作的情景分析；现有系统的问题报告和改进要求，事件和响应；市场调查和向用户群体发调查问卷；与同行、专家交谈，听取他们的意见；分析已经存在的同类软件产品，提取需求；从现有产品或竞争产品的文档中提取需求；从行业标准、规则中提取需求；从Internet上搜查相关资料等。
2.需求分析
需求分析主要通过建立业务模型的方式来描述用户的功能需求，为客户、用户、开发方等不同参与者提供一个交流的渠道。业务模型可以映射出软件产品的核心需求，即功能需求。功能需求应描述软件提供的功能和服务、对输入的响应，并描述特定条件下的系统构成等。软件产品本身可能还存在与业务无直接关系的非功能需求，具体与系统的总体特性有关，如可靠性、响应时间、存储空间等。非功能需求定义系统提供服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。通常这两类需求构成软件需求的总集。
3.编制软件需求规格
软件需求规格的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础，需求分析完成的标志就是提交一份完整的软件需求规格说明书。软件需求规格说明书以一种开发人员可用的技术形式阐述软件必须提供的功能和具备的性能，以及必须考虑的限制条件。软件项目客户通过软件需求规格了解软件项目能够提供的软件产品，检查软件需求是否满足需要；项目管理人员根据软件需求规格制定项目的开发计划和管理过程；软件开发人员通过软件需求规格理解要开发的产品及具体要开发的内容；软件测试人员通过软件需求规格验证软件。
4.需求评审
编写的软件需求规格说明书还应当进行需求评审，确保需求确定的科学性。可采用下列指标进行评审：(1)正确性:每条需求都正确代表构建软件系统所要完成的事情。(2)无歧义:每条需求只有一种解释。(3)完备性:需求不能发生遗漏，应全面考虑相关问题。(4)一致性:用户需求必须和业务需求一致，功能需求必须和用户需求一致。(5)重要性和稳定性分级:现有资源不足以实现所有需求时，可以根据级别的高低决定实现的先后，舍弃一些级别低的需求以保证项目的按期交付。(6)可验证性:需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。(7)可修改性:每一条需求都易于完整一致的进行变更，且不改变需求集的结构和风格。(8)可跟踪性:每条需求都是可溯源的，且存在一种机制使得在以后的工作中引用需求是可行的。(9)可理解性:用户和开发人员都完全理解需求集的整体行为、所提供的功能及其中的每条需求的含义。
三、软件需求开发管理模型
1.软件需求开发管理模型构建原则
软件需求开发是一项复杂的系统工程，管理模型的构建应遵循下列原则:(1)程序性原则：软件需求开发管理应遵循固定的业务流程，可将其划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段，前一阶段的工作完成后才能进入下一阶段。(2)系统性原则：软件需求开发要在限定的时间、成本条件约束下达到一定的质量，实现软件系统的最优，要求管理遵循系统管理原则，实现目标最优。(3)简化性原则：化繁为简，将模糊的、潜在的复杂问题明确化，以图表的形式表示出，并以简化的解决方案解决问题，便于项目管理。(4)平衡性原则：管理软件需求开发的具体事务要有一定的侧重。对于需求开发过程事项，应根据影响大小分清主次，关键的事项或者事项里的某个多发问题点，着重管理，达到在管理上的主次平衡。(5)高效性原则:模型的设计必须以促进需求开发目标的实现为前提，提供给相关人员一个展示需求开发管理和有效解决方案的平台。（6）时时控制性原则:及时控制需求开发过程中影响进度、成本、质量等问题，及时发现解决冲突事件，做到事前、事中、事后控制，保证项目按时保质保量完成。(7)动态性原则:开发中应关注信息技术的发展，将先进的技术应用到软件需求开发中，并学习借鉴相关软件需求开发的成果。
2．软件需求开发管理模型
基于以上分析，本文构建了软件需求开发管理模型，见下图：
该模型遵循了软件需求开发的管理流程。启动阶段，软件开发进行了可行性研究，软件项目已立项，项目正式启动。软件需求开发管理阶段是模型的主要部分，按照项目流程，依次划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段。总结阶段，对软件需求开发管理进行总结，并进入到软件程序设计阶段。模型的核心部分是应用项目管理的进度管理、成本管理、质量管理，对软件需求开发进行动态管理。进度管理就是制定出经济合理的进度计划，然后在计划执行过程中，检查实际进度与计划进度之间的差异，并及时找出出现差异的原因，采取有效的补救措施，以确保项目按时按质完成。进度管理应加强沟通，掌握可能延误进度的环节，并严格控制进度变更。成本管理就是对项目所需的成本情况进行详细地分析和估算，编制资源需求计划，并编制项目所需的成本估算和预算，在执行过程中，采取相应的措施对项目成本进行控制。成本管理应严格控制加班、浪费等额外支出。质量管理是为了保证项目的可交付成果能够满足客户的需求，围绕项目质量而进行的计划、协调和控制等活动，其具体内容涉及质量规划、实施质量保证和质量控制。通过进度管理、成本管理和质量管理，使软件需求开发成为进度快、成本低和质量合格的有机统一体。
该模型规范了软件需求开发的业务流程，并在整个软件需求开发的不同环节之间建立联系，明确需求开发过程与自身各任务项之间以及项目其余环节所存在的各种联系。模型各环节间的相关性、可追溯性保证了软件项目需求开发过程，可以遵循统一的管理模式。该模型具备可配置性。每个软件项目，都具有个性化管理需求，在进度管理、成本管理、质量管理等方面有不同的要求，可以针对具体的开发团队，项目要求，管理侧重点，扩增相应的管理模块，将此模型推广到任何一个软件需求开发项目。
3.模型应用
由于软件需求开发具有复杂性，其主要表现为需求描述问题，明确表达需求较难确定，并且难以统一；需求完备问题，需求没有遗漏，难以准确划定系统范围；需求的变更问题，需求变化是永恒，需求不可能是完备。模型应用需做好以下工作：（1）文档化管理。需求必须有文档来记录，该文档必须是正确的，是经过验证的，是在受控的状态下变更的。开发或管理人员常常会在含糊的情况下把认为是相对简单的需求忽视而省略文档记录，其实未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了，同时方便日后维护工作的展开。需求含糊的情况下要进行会议形式处理，并邀请相关人员参加进行需求澄清及确定，需求在进行多方确定后进行归档。同时软件需求的复用率也是相当高的，可以避免升级时重新将需求再次获取，只需要在原来的基础上作为文挡需求复用升级处理。（2）审核评估需求变更，减少变更的影响。在管理软件开发过程中，需求渐变是必然的，无论需求变化的程度如何，只要需求变更就必须进行评估。在需求变更之前必须由项目管理人员审核，再传给开发人员进行评估等工作。管理人员必需依据对整套系统的了解程度分析需求变更过程中可能受影响的系统及受关联的功能模块，并制定积极应对措施。(3)整体管理。应识别、确定、结合、统一与协调软件需求开发管理过程中所需要进行的各种过程和活动，保证进度、成本、质量等各要素的相互协调。
四、结语
软件需求开发在软件项目管理中具有重要地位。本文应用项目管理理论，设计了软件需求开发管理模型。该模型遵循项目管理流程，将软件需求开发划分启动、需求开发过程、总结三个阶段，并将软件需求开发过程划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段，模型应用项目管理的进度管理、成本管理、质量管理，对软件需求开发进行动态管理，实现软件需求开发项目目标最优。该模型能够提高软件需求开发管理效率，确保软件开发能够按进度，低成本，高质量地完成。
参考文献：
[1]景慎艳:软件项目需求管理的探索与实践[J].电脑知识与技术，2008（27）
[2]左怀远:软件项目中的风险管理研究[J].世界科技研究与发展，2008（3）
[3]孙琦龙:加强软件项目管理的实践模式[J].科技信息，2008（7）
篇6
关键词：测试风险管理；风险管理；软件测试
中图分类号：TP311文献标识码：A文章编号：1009-3044(2012)11-2518-03
软件本身的复杂性以及测试本身的特性决定了测试活动实施过程中风险的大量存在，而风险会影响测试活动的成败，严重时还可能导致整个项目的失败。因此，对测试风险的管理越来越引起人们的重视。
1风险存在的必然性
软件测试项目的风险来自于软件和测试自身的特点。
1.1软件的特点
1）软件产品是不可见的：软件项目的开发进度和软件质量管控过程是否符合标准很难衡量，使得软件的管理也难于把握；
2）软件生产过程形式多样，不存在绝对正确的形式：不同的软件开发项目，应采取不同的或者特定的软件开发过程。但在项目开发之初却不能确定正确的形式，只能根据项目的特点和开发经验选择，并在开发过程中不断的调整，真正适合该软件的开发过程只有在项目开发结束才能确定；
3）大型软件项目往往是“一次性”：项目一次性的特点使得过去的经验不能被广泛的借鉴。控制软件管理风险的唯一途径是设立监测系统，开展有效的风险监控和管理。
1.2测试的特点[1]
1）完全测试是不可能的：在有限的资源和时间条件下，找出所有的软件缺陷和错误，使软件趋于完美是不可能的，主要原因为是输入量太大、输出结果太多、路径组合太多；
2）测试具有病毒一样的免疫性：软件缺陷具有病毒一样可怕地免疫性，对其采用的测试越多，免疫能力就越强，软件测试工程师想要找出更多软件缺陷就更加困难；
3）测试是“泛型概念”：软件测试涵盖需求分析、概要设计等在内的整个软件生命周期，以确保每一个阶段都经住考验；另外，测试自身也需要来自第三方的评估和监督，以确保测试的可靠性；
4）80-20原则：80%的软件缺陷常常生存在20%的软件模块中。我们在系统分析、系统设计、系统实现阶段只能检测和规避80%的软件缺陷。在下一步的系统测试中，可以帮助我们找到剩余缺陷的80%，剩余4%的缺陷只有在系统交付使用后经过大范围长时间使用后才会暴露出来。所以，软件测试只能保证尽可能多的发现软件缺陷，却无法保证能够发现所有的软件缺陷；
5）缺陷的必然性：由于软件测试中错误的相关性，并非全部的软件缺陷都能够被成功修复。在缺陷的修复过程中会不可避免的引入新的错误，另外，在修复的过程中，我们往往还会受到时间、成本等各方面因素的限制，导致最终不可能完全的修复所有的软件缺陷。
2风险的评估
风险的管理基本的内容有两项：风险评估和风险控制。
风险评估是在风险识别的基础上，对识别出来的风险进行评估，主要从下列四个方面入手[2]：
1）风险概率分析，即对风险发生的可能性设置一个尺度，如很高、较高、中等、较低、很低等；
2）描述风险并预测风险发生后，对软件产品和测试结果可能产生的影响或造成的损失等；
3）确定风险评估的正确性，要对每个风险的表现、范围、时间做出尽量准确的判断；
4）根据损失（影响）和风险概率的乘积，来确定风险的优先级别，定制风险应对措施。
3风险控制的原则
风险控制是建立在风险评估的基础之上的，主要工作原则有[2]：
1）针对有些可以避免的风险，例如测试用例执行率未达到100%，可以通过制定测试规范，要求测试人员严格按照测试用例执行测试，并记录用例执行情况，来避免该类风险；
2）有些不可避免的风险，采取措施降低风险，尤其是等级较高的风险，将其转化为不会引起严重后果的等级较低的风险；
3）凡事预则立，事先做好风险管理计划，当风险成为现实时，可以更好的避免、转移或减低风险；
4）对风险的处理制定应急、高效的解决方案。
4软件测试风险分析与管理方法
软件生命周期包括问题定义及规划、需求分析、软件设计、程序编码、软件测试和运行维护六个阶段，而软件测试前面的任何一个环节的不严谨都可能增加软件测试活动的风险。软件测试活动中也存在各种各样的风险，其中常见风险有需求变更风险、测试过程风险、测试组织和人员风险。
4.1需求变更风险
在软件测试项目尤其是历时较长的大项目的实施过程中，总会不可避免的出现需求的变更。如何把握好需求的变更，减少需求变更带来的风险，成为影响整个项目成败的关键。
4.1.1软件测试项目需求变更的管理[3]
1）设定需求变更的参考标准，将需求基线。当软件测试项目组确认要产生需求变更时，用标准的变更申请表格将委托方的变更申请记录存档。每次的变更都应在需求基线的基础上进行。
2）软件测试项目组收到委托方提交的需求变更申请后，成立项目变更控制委员会(CCB)，负责对项目变更所带来的影响进行评估，包括测试项目的人力、物力、资金、管理、时间、质量、工作负荷等内部因素，以及资本、委托方要求的完工时间、项目负债情况等各个方面的影响。
3）变更确定后，选择可行的实施方案。为了将项目变更的风险降低到最小，力求在尽可能小的变动幅度内对测试项目的目标、预算、团队以及项目的进度等主要的因素进行微调。
4）需求变更后，要重新确定新的需求基线；受影响的软件计划、产品、活动等也要进行相应的变更，以保证和最新需求的一致性。
4.2测试过程风险
在测试工作中，主要的风险有[4]：
1）需求的临时或突然变化，导致设计的修改和代码的重写，使得测试时间不够；
2）测试用例没有得到100%的执行；
3）质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
4）质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
5）测试用例设计不到位，忽视了一些深层次的逻辑、边界条件、用户场景等；
6）测试环境与实际生产环境一般情况下都不可能完全一致，造成测试结果的误差；
7）有些缺陷出现频率不是百分之百，不容易被重现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
8）回归测试一般是选择性的执行部分测试用例，必然带来风险。
前面3种风险可以通过前期调研人员或测试人员与客户加强沟通或者制定严格的制度来避免的，而针对有些不可避免的风险，采取一些有效的测试风险控制方法来尽量降低风险，例如测试环境不正确，可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；针对程序中总是存在的“未发现的缺陷”，可以通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；针对经常出现的产品前夕，在某个不是很重要的新功能上发现一个严重缺陷的问题，可以通过去掉该新功能来转移因为修改此缺陷可能引起的某个原有功能上的缺陷的风险。回归测试只执行部分用例带来的风险是可以避免的，但出于时间或成本的综合考虑，一般是存在的。
提前做好风险管理计划和风险控制策略，可以更好的避免、转移或者降低风险：
1）在执行项目计划，做资源、时间、成本等的估算时，要留有余地；
2）在项目开始前，制定风险管理计划，重点把握边界上可能会出现变化、难以控制的因素；
3）重视人员队伍的培养，对每个关键性技术岗位人员培养后备人员，确保项目不受人员流动的严重影响；
4）制定工作机制和文档标准，保证文档的及时产生，便于项目知识的分享和移交；
5）对工作进行相互审查，不同的测试人员在不同测试模块上相互调换，及时发现问题；
6）日常跟踪所有工作过程，及时发现风险的迹象，以避免风险。
4.3测试组织和人员风险
4.3.1测试组织风险
测试人员不独立于开发者，测试人员独立与开发者的程度将影响测试结果。
1）成立专门的测试组织；
2）制定专门的测试管理流程和质量保证手册，规范测试过程，保证测试的质量；
3）委托专门的测试组织执行测试活动。
4.3.2人员风险[4]
测试项目尤其是周期较长的项目几乎不可避免的要面临人员的流动，从而增加项目失败的风险系数。及早预防是降低这种人员风险的基本策略。下面从第三方测试的角度具体介绍一下人员风险的控制方法：
1）指派一名项目副经理或项目经理助理协调项目经理管理项目工作，降低关键岗位人员流动的风险。但是一般只建议在项目经理这种比较重要的岗位采用这种冗余复制的策略来预防人员风险，否则将大大增加项目成本；
2）建立良好的文档管理机制，包括项目组进度文档，个人进度文档（测试日志）、版本控制文档、整体技术文档（测试策略、测试用例）、个人技术文档（测试执行记录、缺陷报告）等。一旦出现人员的变动，替补组员能够根据完整的文档尽早接手工作；
3）控制项目团队中外包或兼职人员的比例，且项目核心部分的工作应该尽量由全职人员来担任，以减少兼职人员对项目组人员不稳定性的影响；
4）加强测试项目组内的技术交流，定期召开项目例会，使测试组成员能够相互熟悉对方的工作和进度，能够在必要的时候接替对方工作；
5）为项目测试工作的开展提供尽可能好的基础环境，比如待遇、项目组内良好的人际关系和工作氛围等。良好的工作环境对于稳定项目组人员以及提高生产效率都有不可忽视的作用。
4.3.3外包人员风险
1）制定相关的管理流程文件，规范外包人员的活动，防患于未然，规避外包风险；
2）通过外派监管团队的方式对整个测试活动进行监控；
3）通过对测试活动的中间交付物进行检查保证测试的质量，例如：对设计的测试用例进行评审、对编写的测试代码进行抽查、检查测试执行的日志等；
4）对于外包测试的形式，除了避免承包方项目人员的泄密，还要注意双方数据传输过程中的信息保密。在采用外包测试的时候，不可避免地要进行各种信息的传送，可能是双方的电话、E-Mail交流，也可能是软件版本的传输，在条件允许的情况下要尽量使用VPN等方式。如果有必要，对传输的数据要进行加密。
5结束语
测试过程中的风险总是存在的，该文对测试活动中主要的风险进行识别和控制，并确定针对性措施，避免风险发生，或者把风险降到最小。要想做好风险管理工作，就必须彻底改变测试项目的管理方式，建立防患于未然的管理意识，并结合具体的实践工作不断地分析遇到的风险，总结各种风险的应对措施，指导实践，降低产品质量风险。
参考文献：
[1]张华.软件测试的常识[EB/OL].省略/html/2010-01-13/100144.htm.
篇7
近年来，中国的汽车市场迎来了爆发式的增长，从2010年开始，中国一跃成为世界规模第一的汽车生产国，成为全球最具活力的汽车市场之一，全国各省市先后出台了促进汽车产业发展的规划，各大汽车厂商也纷纷跑马圈地，产能成倍地增长。这意味着汽车厂商在迎来千载难逢的市场机遇的同时，也必将面临着激烈的市场竞争。
本文将通过对北京汽车股份有限公司（以下简称“北京汽车”）零部件采购现状的分析，运用项目管理的方法来规划和实施采购信息化系统建设，同时和大家分享项目实施过程中在范围管理、沟通管理和质量管理方面的一些经验。
一、北京汽车零部件采购现状
2010年9月，北京汽车正式成立，虽然有不少有经验、背景的人才加入，但是对北汽自主品牌来说，从研发、采购到生产的全过程还是像个蹒跚学步的小孩，一点点在摸索中成长。就零部件采购来说，其存在的主要问题是：整车厂以自身利益为中心, 不顾零部件企业的实际情况和利益, 用零部件企业的大量库存来换取自身的零库存, 并把价格战的压力推向零部件企业, 导致汽车行业整体供应链竞争力减弱；信息沟通的手段和工具落后，主要还是采用传统方式( 电话、传真、信件、E - mail）与供应商进行信息交流, 使信息不能及时传达, 导致采购效率低下, 企业对市场的反应速度迟滞, 造成生产与市场的脱节, 而供应商为了适应由于信息不畅造成的需求变化, 只得加大库存量, 导致流动资金占用过多；零部件定点和开发认可进度风险管控困难，成本对标与统计完全靠手工台账处理，人员流失导致数据信息流失，这种状态已经严重制约了采购业务的开展，尤其是在整车行业竞争如此激烈的大环境下，要求规范采购业务流程、提高工作效率、与供应商协同合作、共同发展的呼声越来越高，采购信息化管理也就势在必行。
二、北京汽车采购信息化系统分阶段实施计划
2011年下半年，在北京汽车各方领导的大力支持下，采购中心协同信息技术部开始规划零部件采购信息化系统，即SRM（Supplier Relationship Management，供应商关系管理）系统，这个系统是一种不断优化供应商选择，缩短采购周期，贯彻集中采购，并实现与供应商建立和维持长久、紧密伙伴关系的管理思想和软件技术解决方案。笔者作为该项目的项目经理有幸参与了整个规划和实施过程。根据采购实际业务开展的紧迫程度，将系统规划实施分成三个阶段进行，具体安排见下表。
三、北京汽车采购信息化系实施过程的管理模式
1.项目组织类型选择
由于采购SRM系统开发与实施涉及多个部门，如生产部门、零部件采购部门、供应商管理部门、财务部门、信息技术部、软件开发商等，根据项目需要每个部门需要安排一名关键用户，对参与项目的关键用户的要求是对部门业务熟悉且表达能力强，同时需求调研阶段和测试阶段需要全程参与，其余时间还是要参与到部门事务中去，所以项目的组织类型选择矩阵式管理。矩阵式管理较其他组织结构相比，至少有三大优点：一是提高工作效率，由于采用了灵活的组织结构，在资源上进行了共享，当项目出现的时候，可以马上调集与之相匹配的资源，组建跨功能部门的项目团队，提高了团队执行力，减少了沟通环节，加快了信息的共享，提高了反应速度，矩阵式管理使各个部门的管理聚焦到公司的业务发展上，更加有利于公司的战略实施；二是资源得到共享，在矩阵式的组织结构中，各个部门的资源得到了共享，使资源得到了充分的利用，减少了以前出现的“忙的忙死，闲的闲死”的情况，根据研究表明，采用矩阵式的管理模式比采用传统组织结构的管理模式要减少20%的资源；三是更加有利于人才的发展，采用矩阵式管理模式并不会影响到人才的晋升通道，而且采用跨部门的协作模式，有利于提高员工的综合能力的培养。矩阵式管理更加有利于人员的团队合作精神，避免了以前的部门本位主义。
2.项目的范围管理
项目范围是指为了达到项目目标，项目所规定要完成的工作及过程。利益相关方必须在产品方面达成共识，也要在如何完成这一项目达成一致的意见。项目范围管理是指对项目包括什么与不包括什么定义与控制的过程。这个过程用于确保项目团队和利益相关者对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解，简单地说，项目范围管理就是为项目划定一个界限，划定哪些方面是属于项目应该做的，哪些是不应该包括在项目之内的，定义项目的工作边界，确定项目的目标和主要的项目可交付成果。
针对SRM项目实施来说，需求调研阶段生成的需求文档就是对系统开发范围的界定，这个也是整个项目实施中的重点和难点，一般会占整个开发周期三分之一的时间。“磨刀不误砍柴工”，前期需求越明确，后续开发返工才会越少，进度才越有保障。否则有可能开发出来的产品和业务部门想要的内容南辕北辙，项目只能以延时或是失败告终。需求调研阶段，首先根据立项报告中的功能模块定义，规定好每个模块的调研时间，也就是确认需求调研计划和参与人员，当然时间是很紧凑的了。然后，我们组织关键用户和软件公司开发顾问一起进行头脑风暴，每个人根据自己业务的实际需要，提出需要哪些功能，业务流程应该是什么样的，页面该如何展示，审批流程应该是什么样的等等，开发顾问会详细记录这个需求内容，同时对讨论未决事项确定责任人，需要找相关领导确认明确需求，并生成会议纪要下发再次征询意见。讨论会后，需要关键用户将模块的业务流程进行梳理，生成模块的流程图。每个模块大概都需要三轮需求讨论才能定第一稿需求文档。由于关键用户一般都是业务骨干，但不是部门经理，没有决定权。第一稿确定后，需要集中各部门领导进行宣讲和征询意见，根据领导的意见再次修改后审批完成才能最终定稿。需求文档必须明确标记每个模块需要哪些页面、页面功能和字段有哪些、页面功能之间的关系、权限的设定、审批流等详细信息。同时为了以防万一，担心开发人员理解有误，需要软件开发商根据需求文档提供系统界面原型，作为需求调研阶段另一个交付物，界面原型同样需要关键用户和相关领导审批通过才能生效，这也是需求调研阶段的双保险，根据以往的经验，这样做后续开发过程中的分歧会比较少。
当然，再完善的需求也很难避免由于各种原因而出现需求变更或新增需求（范围变更）的问题。针对需求变化，首先需要提出部门提交变更申请单，项目组内部进行综合评估，首先判断这个需求是否真的有必要体现，如果需要，就要看需求变更对其他功能的影响，影响有多大；如果该变更不开发将影响其他业务流程，那一定要在本期上线前开发完成，否则系统无法使用。这种情况就需要调整开发计划，形成新的项目计划基线。如果该变更是单独功能，不影响其他功能的使用，看开发进度是否允许，时间充裕可以上线前开发；否则协商后可以系统上线后开发，但规定好具体完成时间。如果经项目组评估后觉得功能根本没必要体现，需求变更不予实施。变更申请单需要层级审批后，由开发经理评估费用和时间进度，按计划执行。变更申请单由信息技术部存档，作为项目收尾时结算的依据。
3.项目的沟通模式
项目沟通主要是项目团队与其他组织、项目团队成员之间的信息传递和理解。项目沟通贯穿于项目的整个生命周期，在确认系统需求阶段需要沟通；在项目计划阶段制定各类计划时需要沟通；系统开发和实施阶段需要沟通；在系统测试阶段需要沟通，以及上线运维阶段都需要沟通；可见沟通在整个项目实施过程中的重要地位，有效的沟通对项目的成功具有重要的意义。如果沟通不畅，相关人员不能理解项目经理的意图，无法做到上传下达，最终会导致项目混乱甚至失败。另一方面，项目团队内部及其与外部环境之间的信息沟通可以使项目组及时准确地获取项目的进展情况，对项目进行合理的组织和控制，因为只有以准确、完整、及时的信息为依据，项目组才能做出正确的决策和合理的计划。
针对SRM项目来说，采用的是轮式沟通渠道模式，就是项目经理作为信息中心分别与项目中不同类型角色发生联系，集中汇集和传递来自各个部门的信息，但是不同角色之间彼此之间不发生联系，只分别掌握本部门的情况，接受主管人员的指令并反馈信息。沟通的方式主要以书面沟通的形式，会议上沟通讨论的以会议纪要为准，个别沟通的内容以邮件为准，或是根据项目要求提交各类报告，这些信息可以长期保存且信息描述周密、逻辑性强，不容易产生误解和纠纷。但是缺点是耗费的时间比口头沟通要多，同时无法保证接收者是否能够正确理解，综合两者的优缺点，我们最终采用的沟通方式是以书面沟通为主，口头和书面相结合的方式，每次口头沟通后会落实到文字上双方认可再实施，保证沟通的有效性。
4.项目的质量管理
项目质量管理是为满足项目利益相关者的需要而开展的项目管理活动。针对SRM项目的质量管理就是软件功能测试，包括单元测试和集成测试。由于我们此次合作的软件开发商没有专业的测试团队，只是开发人员交换测试，一方面由于时间进度紧而测试不充分，另一方面对别人开发的模块需求不清晰测不出业务流程的正确与否。所以到单元测试和集成阶段，关键用户就要参与进来，每个关键用户测试自己所熟悉的领域，除了对页面字段功能进行验收外，还要对功能之间的业务逻辑进行验证，这样开发与测试并行进行，有利于保证进度。但是从另一方面来看，我们收到的最初的交付物错误百出，通过问题清单的形式发给开发经理进行修改和再次验证。虽然我们验证的比较充分，但是这样项目组面对的工作量就会成倍的增加。建议以后最好选有专业测试团队的软件开发商，让其分担项目组的测试工作量。
四、小结
篇8
关键词：软件公司；成本控制；探索
1经营决策阶段的成本及其控制
经营决策阶段成本是指公司经营方向的选择，这是成本管理的第一个也是最为核心的环节。不过对于大多数IT软件业公司而言，这个阶段往往是最大的问题之所在，有时经常凭一个觉得是灵感的想法或者对市场初步的直观层面的调研就进行的决策。而这样的结果是往往没有摸透市场的真实情况，轻率上马项目，造成方向性错误，以至于导致企业的危机。
该阶段的成本控制，关键在于经营决策前科学而深入的市场调研及准确分析，目前很多中小型IT软件企业，其经营部的职员大多都并不是社会调查专业的，因而他们做市场调查的过程中所采用的方法不太科学，如在样本选取及抽样过程不合理，没有按照严格的社会调查方法进行调查和数据分析，甚至问卷设计都存在倾向性导致调查数据信度偏低。此外，大量的公司自我宣传的各种形式的软文和竞争对手有意的攻击性文章夹杂在其中，并不是很容易的进行分辨，更何况数据的随意性，来源的不可追溯性各种情况，所以只能作为参考。
2需求整理及分析确认阶段的成本及其控制
需求整理指市场经营人员根据高管对于市场方向的决策，而提出的具体的产品或者项目的原始需求，需求分析是指技术员对市场部门的需求进行分析，评估其可实现性以及实现难度，大致工时等，提交相关需求分析报告，最后市场经营部门进行确认这个阶段。
该阶段的成本控制，首先需要搞清这种沟通过程中产生偏差的原因，最为主要的往往并不是技术语言和市场语言的差异，或者市场人员和技术人员之间的思维定势的差异，而在于两者缺乏确定的科学的流程和在交流之前的准备以及相关概念约定俗成的定义造成的问题，同时还由于沟通和确认环节由于其特殊性，经常难以被有效的纳入进度管理程序流程当中。而提高该阶段的成本控制效率，必须逐一针对性的解决以上问题，首先要清晰的确定并严格执行市场和技术沟通的流程，尤其是要明确每个环节的控制点，也就是双方交付给对方的关键交付物，一定要有清晰的共同确认的模板，同时每次沟通前必须对于一些概念有着清晰的界定，然后公布这些信息，并在沟通前做好充足的准备，明确每次沟通前要沟通什么，要解决哪些问题，沟通结束后要交付哪些文档让双方进行确认等，同时一定要通过线上或者线下的管理模式，讲所有沟通环节全盘把握，并纳入进度管理。
3规划阶段成本及其控制
规划阶段成本是指在需求已经得到确认后，进入技术规划阶段的相关成本控制，该阶段有些软件开发公司常常出现的问题是对于规划予以过度的期望和过于沉重的内涵，在实际项目操作过程中，这个规划实际上包含着技术规划和非技术规划两个部分，因为对这两个部分的混淆，导致一些技术层面和市场层面的东西不必要的纠缠在一起，并且直接导致项目进度的拖欠，而且会导致由于非技术规划的不清晰，直接影响技术规划层面的实施。
该阶段的成本控制，必须清晰的区分非技术规划和技术规划，尤其在公司内部技术部门和市场经营部门之间的职责，需要设立一个在提出需求到技术规划之间过渡的位置，即对于需求具体细节的整理，要对于交付物有着清晰的确定，尤其是在不同时期交付不同的关键文档，如除了上面说的那六个文档外，技术部项目组长在需求分析的时候，还应该明确提交功能模块分析，开发代价，功能流程图，功能关联性图，可维护性及可拓展性分析等六个文档，此外在项目开发规划阶段，还要对于控制点的一些要素进行详细的规划用来提交给市场部门，如详细页面元素，页面元素价值度分析，表现形式，页面结构，页面效果等。
4开发阶段的成本及其控制
开发阶段的成本指需求确定并且规划清晰后的具体开发过程的成本管理问题，该阶段相对其他阶段来说比较清晰，但这里笔者认为需要关注的是，如何使得人力资源得到最大程度的利用，它是指公司第一线技术人员的能力最大程度发挥的状态，包含几个层次，（1）全部时间利用，（2）最大效率利用，（3）最大潜力激励利用，这三步需要逐步递进实现。这个需要一种完善的内部管理制度，以及公平公正的价值认定模式和绩效制度，从而一方面促进员工本身的发展，一方面增加对人才的吸引力。
该阶段的成本控制，可以引入最大可控制成本的概念，这里是指人力资源最大程度发挥后所能控制的成本，是公司在一定投入前提下，最大的可能的减少因管理导致人力发挥不足够而造成的成本，该成本为人力资源的极致成本，无法再进一步降低，此成本状态下的仍然出现效益不佳情况，则可说明在经营定位和经营方向上的问题，而非内部问题。促使人力资源得到最大利用度和发挥度，在此基础上的成本，为最大可控制成本，以上可以通过内部的管理系统来很好的实现。5需求变更成本及其控制
需求变更成本指在开发过程中，由于市场部门的需求改变导致的成本增加而实施的控制，对于项目开发的过程中，需求的频繁变更就成本控制而言是致命的，很多项目由于需求的变更而导致破产。
该阶段的成本控制，最关键的是要对于需求变更过程进行严格的管理，要从需求变更的开始，对于整个变更的每个具体的步骤进行跟踪，并且严格核算每次变更所需要的工作时，从而做好评估。同时，务必要明晰需求变更的必要性和风险性，以及所带来的实际成本的增加，所以需求要尽量经过详细的论证。
6测试成本及其控制
测试成本指项目开发完成阶段，在交付验收前进行的测试过程中导致的成本及其控制，测试阶段对于一个项目的最终交付具有重大的意义，往往在测试阶段要才是使得项目真正完善的阶段，很多细节的修补都在测试阶段完成，正是测试使得一个项目成为一个可以交付，可以应用，可以产生效益的产品。但对于一些中小型软件开发公司而言，往往缺乏真正建制齐全的测试部门和专业测试人员，经常是技术人员进行兼任，这种方式相当普遍。但同时也导致了一些问题，主要是对于测试缺乏经验积累管理，或者说是错误管理，经常上次测试完出现的问题，过段时间又会出现，或者是开发下个项目的过程中又再次出现，增加不必要的成本。
该阶段的成本控制，笔者认为最关键的是对测试进行错误管理模式，采取“有错必改，凡错必究，错不再犯，预错于先”的管理办法，尽量在项目开发之前，就能整理出之前开发中出现过的所有问题，并用列表的方式进行技术会议，让所有开发人员进行错误共享，尽量把测试中可能出现的问题消灭再开发阶段，另外需要把测试过程化、即时化，每周甚至每天都要求每个开发人员在交付自己的子模块的之前就暗中预先准备的测试手册进行测试，通过后再提交，同时定时抽查某些核心功能模块，进行某个点的测试，这样全过程的控制，会最大程度的减少测试成本，同时要加快反应速度，一发现开发中，或者测试过程中的相关问题，必须跟进彻底解决，并纳入绩效考核中，杜绝再犯。
参考文献
［1］颉茂华，现代市场经济成本的成本控制新理念［J］.财会月刊2002,(06).
篇9
一、项目经理要有较强的观察分析能力，能够透过现象看本质，规划出执行步骤和措施；
二、项目经理需要有较强的经算能力，能够掌握具体任务的成本、工期及进度；
三、项目经理需要思路清晰表达准确，能够把遇到的问题、过程、解决方案，清晰地反馈给客户；
四、项目要较强需求分析确认意识；
五、项目要有较好需求变更控制技巧，做到项目成果于需求变更的双向跟踪；
六、项目经理要有较强的综合调度技巧和能力，对项目各环节清楚，也能使别人清楚，还要合理何时合适地调度各类人力资源。以上使我从实际项目建设过程总结的经验，现在我分别一一详细阐述，以供参考，相互学习。
正文
2006年，我作为项目经理参与了青岛市应急联动指挥系统的建设。该项目是奥运会帆船比赛城市青岛的110、122、119三警合一平台及应急联动单位协作平台，为了提升整个城市对应急突发实践的响应效率和处置能力而建设平安奥运而做。该项目的主持单位是青岛市公安局，项目构成有110、122、119接警平台，处警平台，联动平台，计算机网络，服务器，视频监控及录音服务系统等。
在项目建设过程中，我从客户需求调研、需求设计、需求确认、软件开发、整体实施各个环节的实际工作体验中，发现项目经理的能力几乎市项目成败的一个决定性因素。在项目经理作用于项目建设诸多能力中，我觉得以下几个方面尤其重要：
一、观察分析能力。
能够面对综合复杂的现象，分析处问题本质所在，抓住主要矛盾，并且很快建立应对步骤及措施，项目建设过程出现的问题都能被及时解决，项目才能顺利进行。具体来说，对于出现的问题和现象，项目经理能够分析出“是什么”，又能指出“有什么”（有哪些细节），进行采取合理的“怎么办”（解决问题的方法和步骤），最后再说明“影响什么”（有哪些风险）。这样，项目建设才能清清楚楚地进行（每一个干系人了解清楚），有条不紊地开展（每个人力资源明白措施及步骤）。观察分析，是一个综合能力。学者经书子集学富五车可谓之渊博；而运筹帷幄决胜千里方是致胜之道。项目经理应该注意将所学用于实际的观察分析，从复杂的想象中指出应对措施和步骤。商鞅变法时，遍历秦国风土人情，观察分析所存在的想象及问题，指出解决各类问题的步骤及措施（各类法令），就是一个典型的观察分析能力运用的结果。重视观察能力的培养和练习，项目才能走出项目的迷雾，让自己清楚，才能让别人清楚。我在青岛项目建设后期，总是习惯于清楚地分析问题“是什么”，指出“有什么”，设计“怎么办”，让观察分析能力充分发挥，所起的作用和前期有明显区别，终于由客户的抱怨转化成赞成。
二、精算能力。
大型项目建设，不是个人单枪匹马独闯独斗；而是一个团队协同作战。常听到一句话：“老虎统帅的绵羊可以战胜绵羊统帅的老虎”，正验证了这个道理。想做好统帅，就要了解和熟悉每一个细节，知道整个项目有哪些子任务，分解到哪些人力资源来完成，并评估到工期和进度。如果出现遗漏，就会造成工期延误。精算能力，正是体现项目经理这方面的才干。我在青岛项目建设之初，简单地分解工作任务，结果造成工作任务遗忘，工期受到延误；后来认真分解任务，精算到位，合理分配每一个细节，项目工期才得以弥补。
三、思路清晰表达准确。
如果自己的思路都不清楚，怎么让别人清楚呢？我们在生活中，经常碰到这样的人。他说话时，东扯一句，西扯一句，听着不明白他的中心思想，很难理解他所表达的事物。与其说思路清晰表达准确是一种能力，还不如说其是一种意识。这个技能从小学课文都已经开始练习了（小学课文都将中心思想和段落大意），应该每一个人都做好。如果说话前，先想一想自己要说的中心思想，然后在逐步分层表达，每一个都能说清楚自己要表达的意识。但是很多偏不这么干，没想好怎么说就开始表达，听得别人云山雾罩。包括我自己，在青岛项目建设之初，我说话前不喜欢做语言上的准备，说得别人越听越糊涂。后来我坚持，表达前先设计思路，然后在准备语言进行准确表达，就避免了客户越听越糊涂的现象。
四、需求分析确认意识。
项目尤其本身的特点，就是一次性满足固定客户的特殊需求。项目经理说做的目标就是满足这个客户需求。需求是什么，有什么，怎么办，项目经理需要于客户沟通，获取确认后，方是客户所要的需求。需求的确认就是完成这个工作的。项目经理应该使需求的理解，需求的设计结果得到客户确认；否则一个没有经过客户确认的需求和设计，使工程返工，推倒从来，白白浪费成本的导火索。我在青岛项目经历过这样的教训，客户提出需求后，我盲目开工，结果客户不满意，团队成员抱怨，成功工期都出现了问题。后来坚持需求签字确认，就大大降低了返工的概率。
五、变更控制技巧。
项目经理需要较好的需求变更控制技巧。对于项目的建设，由于客户随开发方一样，都是一个逐步熟悉的过程。项目的需求变化使一件很普遍的事情。有的开发人员抱怨客户变化无常，一天一个样。其实这是没有站在客户的立场想问题。对于需求变更一味地接受，增加公司的成本，也会造成工期延误；一味地拒绝，客户难以满意，甚至反感。其实这里需要一定的技巧和方法。其一、使客户准确完面地提出问题，坚持走一定的变更流程。例如需求要经过变更会议多方全面讨论分析，再经过需求理解设计，风险分析及实施分析等。其二、经过签字或者其他形式的确认。这样需求变更不是一个客户随意的行为，避免客户故意生事；开发方也能避免无效的多次返工，即使返工也是各方干系人都认可的工作。
六、综合调度能力。
项目经理对整个工程的把握，知道在合适的时间，调用合适的人力，完成合适的任务，使整个项目进展按时按步进行，体现其综合调度能力。大型项目建设是一种复杂而艰巨的任务，项目经理需要完成的事情很多。整体性思考问题，合时合适地安排调度，时其另一个重要的技巧。
以上是我在实际项目中体会的经验。其实在项目建设过程中，项目经理需要总结和吸取的经验还很多。项目经理应该从实际出发不断地总结、学习和体会，以让自己项目管理能力日趋完善。
篇10
关键词 业主 工程变更 核电站
一、引言
由于建筑工程项目的单一性、复杂性和长期性的特点，其工程变更是不可避免的。如果业主对工程变更控制经验不足，管理不善，往往会导致工期延误、投资失控等情况的发生，因此业主必须重视工程变更的管理，确保项目的顺利实施。我国纪检部门已明文规定：工程变更将作为纪检部门对工程建设项目重点控制、检查的四个工作环节之一。国外一些发达国家，例如美国，对工程变更的控制也很重视，据美国有关部门统计，一般工程变更费占合同价格的10-25%，对工程投资影响很大，政府会对投资项目提出严格要求并进行专门检查和评估。
作为中国的第一座引进国外技术并由国外公司承包建设的大型商业核电站，大亚湾核电站不仅引进了核电技术，也引进了先进的工程管理经验。目前在国家积极发展核电的能源政策下，大亚湾核电站应运成为了中国广东核电集团发展核电的人才和技术基地，近几年需新建大批的住宿、办公、培训、招待、运动场馆等行政基建项目。行政基建项目组借鉴电站建造时的工程管理经验，结合行政基建项目的特点，对工程变更管理做了及时的总结反馈，完善了变更管理，取得了一定的成效。在工程管理的实践中总结的一些体会和经验相信对业界同仁会有些启发和帮助。
二、业主对工程变更的管理经验
（一）要结合公司和项目，分析引起工程变更的风险因素或原因。
引起工程变更的常见因素（见图1），可以作为参考，另外要结合自己公司和项目实际，分析引起变更的因素，以便有的放矢，从源头上控制变更。以大亚湾核电站的行政基建项目为例，通过对2006年引起各项目变更因素的分析，发现主要有四条：一是施工图设计质量差；二是用户需求变化，功能性变更；三是施工技术规范书不完善，施工范围不清或项目遗漏；四是客观的不可见因素。对引起变更最多的设计因素（约占总变更额的50%），进一步分析，主要为各专业间接口（特别是安装和土建的接口的矛盾）和设计深度问题。
针对引起变更的主要原因，要及时采取有效应对措施，完善变更控制管理。如针对施工图设计质量差，采取了一系列措施。首先，对设计任务委托书，进行分析评估，找出业主设计任务委托书中的不足，并借助工程咨询公司的力量，编制了《建设工程设计任务委托书标准模板》，规范了今后设计任务委托书的编写，也使质量有了保证。其次，在设计招标中，采用综合评标法，并增加技术标在综合评标中的比例，最高到40%，使设计院加大技术力量投入。第三，在合同条款中明确规定，由于设计院的图纸缺陷，引起工程变更，造成业主损失，设计院要承担相应的经济责任。第四，加大图纸审查力度。除了业主以及施工和监理单位审查外，在施工发标前，还委托专业公司进行第三方图纸审查。第三方审查范围也从国家规定的强规的符合性审查扩大到图纸接口的审查。另外，把那些出图纸质量差的设计院从公司潜在承包商数据库中删除，今后不再允许其参加设计投标。
（二）工程变更控制要采用全过程管理，以预防为主。
工程变更发生在实施阶段，但一些工程变更，特别是重大变更往往潜伏在项目初始的筹划阶段。在该阶段用户需求调查、相互沟通以及项目筹划人员的预见能力，对项目的正确定位和预防重大变更的发生尤为重要。大亚湾核电基地行政基建项目前期的设计阶段中，有几个项目发生的重大变更都是由于用户需求和形势变化，导致原方案不再适用。用户一般不是专业的工程技术人员，在项目初期很难系统提出一份专业、完整的需求报告，而往往是工程建到一定阶段，用户看到实物后又会提出很多变更要求，使项目陷入被动。针对用户特点，我们把用户需求标准化，做成一个覆盖面很广的菜单式需求表，让用户填写，并签字确认。在设计阶段，应做出直观的效果图和模型，让用户在方案设计阶段提出意见。这就基本解决了用户在工程建造阶段提出变更要求的问题。另外，项目的筹划要建立在清楚用户需求的基础上，还要从专业角度了解更多信息，用发展的眼光明确项目定位，重大项目在必要时可请专业咨询公司协助进行前期筹划。项目初期完善、深入的工作，可以有效地预防重大变更的产生。
（三）项目管理中，要控制和减少的是不合理的工程变更。
工程变更可能会导致工程项目延期和投资失控，但业主人员也不要谈虎色变，一味避免或减少工程变更。实际上有些工程变更的实施可以提升项目的功能价值或减少业主损失，对工程建设或项目全周期费用控制有利。因此，要辨证地看待工程变更，充分利用变更，使业主利益最大化。如在大亚湾核电基地员工宿舍二期的建设中，有几栋楼的原始地坪较高，且为基岩，原设计中采用爆破施工降低地坪。在施工过程中，由于该现场与其他已投用的建筑物较近，且在人口较多的生活区，爆破施工时风险很大，进度缓慢。业主技术人员经研究将建筑物基础标高提高1米，也不影响建筑物的正常使用，经设计院同意，决定发出工程变更。该变更为业主节省施工费用约138万，缩短了工期，也大大减少了爆破施工的风险。
（四）建立规范的变更控制流程，并正确处理变更控制与效率的关系。
做好工程变更管理，业主首先要建立变更控制的流程和分级授权审批制度。以大亚湾核电运营管理公司为例，在公司的《合同采购政策》中，规定了变更处理的原则，如“除非涉及重大质量安全问题或可以为公司争取明显的效益，应尽可能减少设计和技术要求的变更。”而且一旦项目累计变更金额超过合同额的15%，变更要由批准原合同的上一级授权人批准。对于行政基建项目，由于合同额相对较大，如果超过15%，一般要公司董事会批准。在此政策下，项目部也制定了《行政基建项目工程变更管理》程序，对变更的定义、处理流程做了详细规定。一般来讲，变更审批环节越多，越容易控制变更的数量和变更的费用，而且各部门在审批中互相补充、制约，也能在一定程度预防个人主观因素甚至个人违规损害公司利益的情况发生。繁琐的变更审批流程，需要较长的流转时间，往往会影响变更的及时实施，甚至影响整个项目的工期。但过分简化变更控制流程，甚至先实施、再办变更手续的做法也是不可取的。建设单位要根据本公司的整体管理的要求以及工程项目的特点，正确处理变更控制与工程效率的关系。
（五）变更控制要充分利用支持单位的力量。
对一般业主单位来讲，由于工程建设是阶段性的，一般不会有太多的专业工程管理和技术人员及相关的经验，与专职从事工程施工的承包商单位相比处于劣势。因此建设单位可以和一些专业公司签订一些技术支持服务合同，充分利用外部单位的力量和成熟经验。如大亚湾核电基地的行政建设项目管理中，项目负责人由业主人员担当，负责项目的总体协调管理。在发标阶段，请造价咨询单位编制工程量清单，请招标单位编制招标文件并进行技术评标。在项目实施中，请专业公司进行第三方图纸审查，请监理公司负责变更令的编写、完工工程量签认，请造价咨询单位对拟发出的工程变更进行估价并负责承包商变更报价审核。这样专业公司介入了工程管理的各个环节，有效地控制了变更，弥补了业主技术和经验不足的缺点。
（六）在变更管理中，要明确各方责任，进行适当的考核和激励。
由于变更产生的原因很多，控制的环节也较多，再加上引进外部支持力量参与的人员和单位也多，如果不明确各方的责任，加强考核，变更控制的有效实施也很困难。在大亚湾核电基地的行政基建项目变更管理中，首先在建设单位内部，对每个变更按引起的原因进行分类，用户需求变化引起的变更责任方为用户，技术变更责任方在土建处，先控制由各部门引起变更的累计金额占合同金额的比例，作为部门考核指标，然后再由部门分解到员工量化绩效考核中，考核直接和年度考绩及奖金挂钩。对于外部单位，在合同条件中也明确规定了奖惩细则，考核他们的工作效率和效能。这样充分调动了所有参与人员的责任心和主动性，构筑起控制变更的道道屏障。
三、案例分析
大亚湾核电基地员工宿舍二期工程主要包括9栋6层的宿舍楼及小区的道路、绿化和半地下停车场。项目的预算金额为7000万元人民币，各种合同（含设计、监理、咨询、家具、施工等）的累计合同额为6500万。在工程变更的管理中，业主项目组严格按照规定的变更流程（见图2），充分利用支持单位的技术力量和经验，对每个变更的必要性、合理性进行把关，对变更方案和工程量及造价进行严格审查，并充分汲取员工宿舍一期的经验，调动项目管理人员的积极性，使工程变更得到了有效控制。
以土建施工部分为例，其合同额为5760万，工期为12个月。工程变更统计如表1。
其中最大的一个费用变更是由于设计院没有充分考虑大亚湾沿海、雨量大、台风多的气候条件，屋面和墙体防水设计不完善所造成的，单个变更的金额为49.7万元。
大亚湾核电站作为中国上世纪引进国外技术的最大的合资项目，工程的管理和公司的商务流程引进了香港和法国的模式，一直发挥着良好的作用。文中所述的行政基建项目的变更管理是在原来工程管理经验的基础上，结合目前的实际情况，不断总结、完善而形成，在工程实践中得到了验证。在近期完工的三个项目中，工程变更累计金额与合同额的比例分别为10%、5.5%和负2.4%，并且全部在项目的预算金额内。工程变更管理贯穿于工程全过程，对工程影响重大。业主作为项目的投资方和受益方，要高度重视，勤于总结反馈，充分利用外部经验和力量，结合公司和项目的特点，制定完善的工程变更管理制度，对工程进行科学管理，以保证项目的顺利实施。
（作者单位：大亚湾核电运营管理公司，天津大学管理系96届毕业生）
参考文献
李维芳：工程变更确认与控制，《建筑经济》，2007年第3期。
孟宪海：国际工程变更因果分析与管理，《施工技术》，2007年第2期。
