软件项目实施过程控制

项目管理综述

科学且具有 可操作性的项目管理方法，是历史数据管理项目成功的重要砝码。方法是对不同类型的项目所获得的经验提炼和总结，明确定义了如何管理项目。总体而言，有三个

主要领域:

    项目管理领域：为项目管理活动如何进行提供指导；

    项目管理工作模式：满足项目管理目标或者应付特定项目管理情形的一系列步骤；

    项目管理工具模版：经过验证的输出，用来进行项目管理，并与项目管理领域相结合。

相应地，项目管理工作范围包含以下主要活动, 与我们的工作计划相一致。在项目过程中要执行的项目管理活动如下:

●开发规范；

●项目计划和控制；

●沟通管理；

●质量控制；

●风险控制；

●项目实施管理；

●问题管理；

●人员管理；

●变更革管理。

管理目标及优先级

基本管理原则：每位组成员既是积极的建言者，又是负责的合作者，同时也是决策的制定者。决策应在充分的讨论基础上由大家共同做出，一旦决策做出就必须被及时有效的执行。禁止再有异议。

1）按时按量完成项目的基本功能，按时发布产品及文档，这是本团队的最高目标。

2）遵循规范化的项目运作标准，文档严谨完整，代码注释充分，便于后续维护，这是第二目标。

3）产品运行稳定，界面友好，用户易操作，尽量从用户的角度去看问题，并提出解决问题的方案。

4）注重团队建设，成员分工合理，团队成员合作默契，气氛融洽。每周的讨论会积极建言。在开发过程中积极协作。

5）项目设计和开发上尽量有创新，有亮点。

风险管理

管理项目可能存在的风险，在进行项目计划时需要进行风险分析并制订风险管理计划，该计划作为项目计划的一部分进行描述。风险管理应贯穿于项目工程的始终。风险管理不是项目经理一人的任务，也不是一次性的任务。它是一个迭代的过程，各项目成员都有责任进行风险管理。建立一种有助于对潜在的风险及其发生的可能性和影响进行交流的环境对项目经理来说是相当重要的。

风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程,贯穿于整个项目过程中,风险管理包括风险识别、风险评估、风险解决以及风险管理策略。

在项目的实施过程中需要不断地识别和应对风险,并加以有效的控制,风险管理的好与坏直接影响项目的实施效果,从某种意义上讲,项目实施对于项目管理者就是识别、分析、应对、控制风险的过程,使项目的约束性目标和质量目标朝有利的方向发展。

项目不同于日常任务,它有明确的起止时间和目标,要在明确的范围、时间和成本约束下,达到相应的质量标准,并取得用户的满意。影响项目成败的因素涉及方方面面,并且风险伴随着项目的始终,是客观存在的,作为一个项目管理者,应该具备良好的风险控制意识,善于识别风险并分析风险的影响,从中发现影响目标的风险点,并施加影响或采取应对措施,把风险的负面影响降到最低,并且风险控制应该贯穿项目始终。

风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面,导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。

在制定风险管理计划时，主要包括如下活动：

1、在项目规划时，通常要对项目进行风险分析。风险分析通常是由项目经理和项目组成员参照 《组织风险选择列表》以及曾经开发过的项目所积累的经验来进行。

2、项目经理《组织风险选择列表》以及曾经开发过的项目所积累的经验识别风险，并将识别出的风险记录到《风险管理》之项目风险计划中。

3、项目经理将每类风险的可能性和影响程度记录到《风险管理》之项目风险计划中。

4、计算风险值和风险等级。对每个风险计算风险值，风险值 = 可能值*影响值。然后对每个风险确定其等级。

5、确定风险优先级。由于每个项目的资源都是有限的，所以风险管理(处理、减缓、监视和控制)必须把精力集中在这种最重要的风险子集上。

6、对风险分类。可以把风险进行分类，即相关的风险分组到一起：这些风险可能需要相似的风险处理或者可能会在同一领域发生反面影响。这种分组有助于理解风险的本质，并且会导致更为有效的风险处理和减缓计划。

7、确定风险的复评估间隔，对于 1 级风险在项目周例会上要定期进行跟踪并报告执行情况；对于 2 级风险则在里程碑会议上对风险进行报告。

8、项目经理将风险等级、排出的风险优先级以及对每个风险的分类，记录到《风险管理》的项目风险计划表中。

下面将详细描述一下这些问题以及出现这些问题时的应对方案:

1、目标以及需求不明确

为了市场竞争或内部管理决策的需要,业务部门提出的需求往往要求的时间比较紧迫,需求的提出大多停留在几张纸或口头的传达上,没有形成正式的业务需求文档,在没有明确的需求范围的情况下,有时为了迎合业务部门的口味匆匆开工,过程中用户不断地提出新的想法,技术人员开始疲于奔命和应付,很难保证项目的进度和质量,也难以取得业务部门的认可。所以,在项目的前期一定要采取相应的手段或措施,与业务部门共同明确项目目标、需求范围,充分考虑现有的时间和资源约束,将需求排定优先级,

对于关键的需求优先实现， 其他辅助性的根据过程中的具体情况进行滚动式计划， 并取 得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统 原型等手段让用户在前期充分暴露自己的想法和需求。

2、范围蔓延以及需求变更

    在有了明确的目标和需求范围的情况下， 需求的变更还是不可避免的， 业务部门在 看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控 制， 新的需求的加入通常会影响已实现的需求， 并且对项目进度和成本产生很大的影响。 项目管理者针对这种情况一定要采取严格的变更控制流程， 不能碍于面子， 否则最终的 结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相 关团队成员进行分析及评估， 作为是否实施的依据， 变更控制负责人根据分析结果判断 是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际 情况下可以采取一些软措施缓解矛盾。 需求变更风险：需求已经打上了基线，但此后仍然有变更发生，对项目造成影响。 如何减少此类风险的发生？ 前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。 找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户，所有的需求要经 过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确 认、User Case 确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变 更时， 严格按照需求变更流程执行。 在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。

    3、代码质量或返工风险

    质量风险主要指开发代码的质量。 如何提高开发人员开发的质量？在制定项目计划 时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有 时开发人员为了赶进度在比较紧张的时间需要完成指定的任务， 可能就存在很大的开发 质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这 个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的 主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，code review 时严格考核。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对 指导开发非常重要。 返工是项目组最不愿意看到的，既浪费人力、物力和财力，又影响团队积极性。需 求不明确或范围没有有效控制都可能造成返工， 另外造成返工的原因是质量没有达到用 户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是 100%完成， 但一到最后系统交互测试或集成的时候就会发现一大堆问题， 不得不花费很大精力回头 排查、修改程序，造成这种情况的主要原因是过程中质量保证没有做到位，把大部分问 题留在了后面。 这就需要在项目实施过程中采取有效的措施来规避返工的风险， 通常的 做法有同行评审， 比如概要设计完成之后， 邀请其他项目组的技术专家进行技术评审以 发现架构设计问题； 管理评审， 通过组织级的质量审计看产品以及实施过程是否满足质 量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要 求的代码，走查通常能够发现 50%-70%的错误；每日构建，这是一种非常有效的方法， 可以避免把各部分的集成问题拖到最后， 并且能够及时发现相应的错误， 日构建一般在 项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。

    4、人员技能和资源的不足

项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见， 一个 熟练的技术人员完成同样一个任务需要 3 天，但一个生手可能就需要 7-10 天。项目管 

理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求， 针对不同的 角色，及时采取相应的技能培训，以保证项目的顺利实施。如果对于项目中某些部分专 业性特别强或新技术，短期内又不能快速建立技能的情况，可以考虑将该块任务外包， 借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分 析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何减少 此类风险的发生？在项目开始前的技术评估阶段， 明确技术难点， 提前安排人员进行攻 克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找 可替代方案。 这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风 险在后期或中期出现。 项目所需人力资源无法按时到位， 导致资源风险。 如何减少此类风险的发生？这个 就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。

    5、缺乏良好的团队协作

    软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各 模块最终要集成在一起形成一个有机的整体， 这就需要各小组之间的密切配合， 界定清 楚工作界面及接口关系， 并在实施过程中持续地沟通交流和共享， 首先团队要融为一体， 产出的软件才能融为一体。 这是一个团队的软实力， 团队之间的协作好坏也将是个潜在 的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。

项目风险管理的要点： 

1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生 的风险不属于风险管理的范畴。这也将是考验一个项目管理者的经验和知识对能否 管理好风险至关重要的内容。 

2、对不可预期的风险，项目管理者要有潜在的风险意识评估，做好一些可操作性的预 案准备。 

3、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的 必要条件。 

4、风险报告是项目团队以及领导了解项目风险的一个有效手段。 风险报告的格式： 序号 风险简介 对项目的影响 解决方案或对策 。

5、团队管理

团队就是一组个体为实现共同的目标而相互依赖、 一起工作的共同体。 团队工作顾名思 义就是团队成员为实现这个共同的目标而付出的共同努力， 项目团队的工作是否有效直接关 系到项目的成败。 团队管理是个渐进的过程。世界上只有完美的团队，没有完美的个人。好的高效的团队 不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化，这需要大家共 同的努力。

a)营造良好的工作环境和氛围。 

b)建设优秀或鲜明的团队文化。 

c)保持高效的沟通。 

6、项目会议

组织会议是项目管理者日常工作中一项非常重要的工作任务， 项目过程中很多重要的决 定都是在会议中做出的，也有很多由于不成功的会议而对项目本身造成了不好的影响。

    首先看看不成功的会议常常表现为哪些形式： 

1）会议氛围不好，参与者发言不踊跃；

2）会议讨论常常偏离主题； 

3）会议没有取得预期的结果； 

4）会议时间常常一拖再拖。 这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的， 很多人都对这样的会议都有抵触情绪， 对此也是深恶痛绝。

以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚： 

1）会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有 可能取得成功，这是会议成功的充分条件。 

2）会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要 希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只 是一个发表想法的人，他不用对会议的成功承担责任。    

3）以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。

组织会议的十一条最佳实践： 

1）只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。 

2）提前发出会议议程，以便会议参与者知道他们来做什么。 

3）请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确 保必要人物都在的情况下一次会议参与者越少效果越好。

4）提前预约参与者的时间，以确保他们能按时到场。 

5）会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说： 

A.再一次强调会议的目标，我们来做什么。

B.强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会， 主要是讨论做还是不做以及告知大家我们要做什么， 而不要把太多的精力放在讨论 如何做上面。 

C.说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人的讲 话，等别人说完你再说等等。

6）会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围 是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。

7）会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成 果之一。

8）会议要有结论。我们常在会议上听到有人说："大家讨论了这么半天，结论呢？"。 没有结论的会议是没有意义的。 

9）会议后别忘发会议纪要，以及一些 Action，什么人什么时候做什么。 

10）会议后的 action 执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知 了会议的效果。 否则会让大家感觉到这是一个可无可无的会议， 大家以后参与的积极性 也会降低。很多会议往往都不注意这一点。 

11）按时结束的会议会受到所有人的欢迎。 

7、版本控制 

版本控制也是项目管理者的一个重要工作内容之一， 一个项目或产品的完成不可能是一 步到位的，在项目完成的后期可能会有多个不同的版本的发布（开发版本，测试版本，发布 版本等） 。需要做好版本的管理和控制。 

8、项目总结 

在项目完成后，总结整个完成项目的过程和经历，为下一次的项目启动提供参考经验， 完善不足，避免在类似的项目中出现可能存在的相同的错误发生。 

人员流失风险控制

我公司将派出一支经验丰富的项目团队来负责项目实施，这支团队包括很多资深人员，并且都成功实施了多个SAS系统的项目，可以确保项目按计划、高质量的交付。

我公司建立了一系列吸引人才的制度和管理办法，确保技术人员的稳定，降低因技术人员流失而给企业带来的风险；公司采取社会聘用和每年招收一定量的高等院校毕业生的措施，及时补充，由于不断发展而造成的技术、管理人才的需求。针对不同的需要，定期对公司员工进行各方面的培训。采用重奖等方式，激发骨干力量的工作积极性。本企业在技术管理方面也建立了一整套保密制度，以确保本项目技术不流失、不扩散。

我公司将进一步加强对人力资源的建设和管理，不断完善人力资源体系，对公司团队的稳定发展起到积极的作用。为配合企业经营战略和业务发展要求，在人员管理策略上，秉承一贯的关注人才、注重核心团队的建设与培养外，注重人员引进的质量以及科学管理，包括引入人才测评体系、任职资格管理、人员信息查询管理等方面。采取股权激励，保证骨干力量的稳定性，避免人才流失。

进度控制

控制进度是监督项目状态以更新项目进展、管理进度基准变更的过程。进度控制需要判断项目进度的当前状态；对引起进度变更的因素施加影响；确定项目进度是否已经发生变更；在变更实际发生时对其进行管理。控制进度是实施整体变更控制过程的一个组成部分。

项目设计认可里程碑是客户和项目组就交付的内容、构建的优先级和期望值达成一致意见的重要机会。它提供了重新评估风险和重新验证早期对时间进度和资源使用估计的机会。

项目组的每一种角色都提供一份计划和时间进度文档，用于描述如何构建功能规定中的产品。项目计划精炼了前景/范围文档中客户和项目组达成一致意见的部分。所以一份好的项目设计和计划是：

●从整体目标、使用者分类和每类使用者期望执行的活动中得到的。

●将客户的期望分类成一系列的逻辑服务：用户服务、业务规则服务和数据服务。

●这些服务统称系统的逻辑结构。

●明确定义界面设计、功能接口、数据需求、帮助系统和培训过渡活动等。

●定义外部接口、交互性目标、性能指标和其它应用到解决方案上的假设和。

●反映组队角色所有成员一致的承诺。

●控制内部的时间进度和外部交流。

基于里程碑的方法是一种重要的设计、评估和协调客户与项目组之间关系的过程。

●外部可见性

过程模型中的主要里程碑是整个项目组同步他们交付的内容，满足客户期望的时间点。项目设计和交付的内容可能会根据项目结果不同而不同。当项目开始时不可能了解所有的事情，是项目开发过程中不可避免的。

●里程碑是复查点，而不是冻结点

过程模型中的五个里程碑允许客户和项目组重新确认，或调整项目的范围和使用者的期望。

●目标驱动的方法

里程碑上交付的内容包含了每一个阶段的目标。

●明确的交流

明确的交流是项目成功的潜在因素。

进度变更管理办法

1. 项目相关各方有权对需求、工作任务、进度要求、人员调动等提出项目变化请求，项目变化提出方或发现方需填写项目变化报告，说明变化前的状态、变化原因、变化的内容，并提交对方的项目经理，需求调研结束后的由客户方提出的需求变更需得到我方的认可；

2. 如果项目变化被拒绝，项目经理应该负责解释原因，并填入项目变化报告；

3. 如果项目变化被接受，双方的项目经理重新制订该项目变化引起的工作量、预算、时间计划、人员安排等方面的影响，并将此内容填入项目变化报告。如该变化涉及第三方或转包方，双方的项目经理必须将有关分包方的项目变化，并要求分包方重新制订相应的计划；

4. 双方的项目经理在接到对方变更请求后 2 个工作日之内，应给予变化提出方明确答复；

5. 参与项目合作的相关各方在项目变化报告单上签字认可后，该项目变化生效，项目经理执行变化实施；

6. 项目经理根据项目变化报告单中进度的变化情况，修改项目进度计划，调整项目组人员组织结构，以及项目组成员的工作安排，修改项目预算等；

7. 我方对于重大的项目变化，项目经理应将项目变化报告提交客户经理，提请客户经理对于项目变化所引起的商务问题与客户进行协商；

8. 将项目变化报告单以及该变化所引起的进度计划、计划预算、人员组织结构、工作说明书等方面修改版本的提交项目相关各方；

9. 对于由于项目变化所产生的项目文档、代码等修改，遵照我方软件项目管理规范之项目变化管理实施规范执行；

10. 项目组成员以及项目相关人员有义务及时发现各种项目变化，并通报项目经理；

11. 项目经理有责任追踪项目变化的各项工作过程，直至变化管理工作完成，项目按新的项目计划执行。

变更参照基准

有变化就有参照，同样，项目中的变更也有其参照系，参照系的原则是按照项目进程

形成的各种有效文档，具体如下：

●项目合同

●项目合同中的《系统功能说明》

●项目管理方案

●需求分析阶段的《需求规格说明书》

●概要设计阶段的《概要设计说明书》

●评审形成的结论

●重要会议纪要形成的有效决议

●已经确认接受的需求变更

项目变更表

为保证项目的可管理性，需要对实施过程中的变更进行统一的管理，这样有利于项目风险控制，以保障项目的顺利实施。因此，我方设计了如下是项目需求变更的登记表，通过 Excel 表格集中管理项目变更。

变更控制委员会

变更控制委员会采用分级控制的方法，要结合简化办事效率和保证风险可控的原则，对于简单的需求变更由二级变更委员会评估，对于影响较大的变更由一级变更委员会来进行评估决策。变更控制委员会由贵公司和双方共同组成，人员在第一次项目启动会议中确定。

项目质量控制

质量管理

在本项目的实施过程中，公司将对项目实施执行严格的质量管理，以确保：

●整个系统的质量

●移交给贵公司各项交付内容的质量

●项目实施各阶段工作的质量

●客户对本项目的实施满意程度

质量管理内容

质量控制必须在开发生命周期中的每一个阶段都被重视，如需求分析、架构设计、详细设计、文档和代码等。

质量管理工作将指定专人负责，并按公司订立的质量审查、检核、记录、评估及更正的执行程序，

公司将在项目实施的各个阶段对如下内容予以质量管理：

●需求规格说明书

●系统概要设计说明书

●系统详细设计说明书

●系统测试方案

●系统测试报告

●系统安装手册

●系统用户手册

●系统维护手册

●系统培训报告

●系统试运行报告

●项目阶段总结报告

●系统源代码和执行脚本

●文档编写的一致性

●资料定义及资料使用的一致性

●测试案例的完整性与可行性

●客户配合程度的考虑与可行性

●系统学习的易懂性

●系统操作的方便性

●是否使用适当的分析、设计及测试技术和工具

质量管理准则

质量管理工作将指定专人负责，并按公司订立的质量审查、检核、记录、评估及更正的执行程序，依据以下准则进行：

●文档编写的一致性

●资料定义及资料使用的一致性

●测试案例的完整性与可行性

●客户配合程度的考虑与可行性

●系统学习的易懂性

●系统操作的方便性

●是否使用适当的分析、设计及测试技术和工具

质量审核方法

审核方法分内部审核以及正式审核：

●内部审核： 由项目组成员共同讨论所开发系统的内容，参与成员提出有关技术、方法及其它问题的意见。

●正式审核： 由项目组书面通知贵公司召开审核会议，并进行审核工作，将审核结果及修正意见以书面方式通知项目组。

项目业务功能设计质量控制

软件产品的功能设计质量控制责任主要是项目经理和业务模块负责人员，主要以项目组审计的方式进行质量控制。如下:

❑项目阶段：业务需求

❑项目文件：《需求说明书》《差异分析说明书》

❑项目评审内容：需求评审

❑项目评审人员：项目总监，项目经理，质量控制组组长，银行业务小组，繁德业务负责人，产品经理

❑项目质量监控评审内容：

●业务差异分析的完整性，并且是否符合业务主管部门的确认

●新提的业务需求是否符合人行规定

●是否通过银行内部审核

●业务界面是否已完成

●业务代号和科目号是否有新增以及正确归类

●会计记账的分录是否提供完整正确

技术设计的质量控制

概要设计评审：

软件产品的功能设计质量控制责任是项目经理和模块技术负责人员，主要以项目组联合审计的方式进行技术质量控制。

❑项目阶段：概要设计

❑项目文件：《系统概要设计总体书》

❑项目评审内容：系统概要设计总体审核

❑项目评审人员：项目总监，项目经理，质量控制组组长，业务模块负责人，技术模块负责人，产品经理

❑项目质量监控评审内容：

●是否已经全部实现新增的业务差异分析

●是否符合系统架构的设计原则

●数据字典公共字段已确认增加

●公共用的选择列表已形成

●涉及记账的模块耦合是否良好

●产品经理从产品的整体角度检查设计是否合理

质量保证标准

质量保证标准使用软件工程的方法，以软件质量控制为核心，抓住软件生产方法、需求分析、软件设计、软件生产工具、测试、验证与确认、评审和管理的原则进行检查和评审，基本标准如下:

1.业务人员提交Bug描述单

2.业务组长与技术组长共同分析，对描述的问题进行确认

3.如确认是bug，技术组长安排技术人员解决

4.技术人员解决后，进行自测，在Bug描述单里填写问题解决方法

5.技术组长对问题解决方法进行确认

6.将升级程序通过版本提交工具提交到业务测试环境

7.业务人员验证性（功能性）测试。

补丁升级程序：

补丁有专门版本提交工具，通过其将Bug修复包提交到生产环境。

需求变更管理

需求变更管理也是项目管理中最重要的一个环节,对需求变更管理的有效性将直接影响项目的成功与否。

对待需求变更的态度:

1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险。

需求变更管理的目标:

1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现上述的目标。需求变更流程:

1、确定需求的基准线。将以User Case作为需求基准线,在User Case确认之后的任何需求改变,都需要走需求变更流程,这一环节我们基本没有,期间有时候使的工作很混乱,也就是因为没有一个规范的变更流程而造成的;如果建立了这么一个流程规范和机制,需求变更没有走这个流程的将不被认可。

2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。针对接收到的需求变更的要求,召集相关人员讨论该需求变更的合理性、可行性,实施的代价以及对项目的影响。包括可能影响的项目范围、进度、费用、质量等计划。项目管理者作为项目的负责人,对项目的成功与否负有主要的责任。所以需求变更的决策者应该由项目管理者承担。

4、需求变更确认后由专人将需求变更记录下来,通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括(客户方、需求分析人员、测试人员、相关开发人员。

5、确定变更的负责人。承担需求变更的具体工作,比如基线控制,对需求变更的记录,并通知相关人员。

6、相关人员接收到确认的需求变更后,做以下事情。需求分析人员修改需求说明书和User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。

7、按照变更后的计划实施项目,并进行检查,跟踪,对变更后的实施反馈和可能出现的问题及时沟通和处理。

8、需求冻结。项目越到后期,需求变更对项目的影响就越大,所以在一定时候要进入需求冻结阶段,不再接收新需求或需求的变更。

沟通管理

为使项目干系人（包括项目相关人员、第三方厂商、项目主管、销售代表、 QA、项目组成员等）之间进行良好、有效的沟通，根据公司的项目管理规范，项目将采用如下沟通交流制度：

专题会议

为保证会议的有效性，在召开会议前必须明确会议目的、议题和进程。除紧急情况外，一般提前两天通知与会人员、发布会议讨论材料。会议中指定主持人和记录人，会议进程按照通知中的议程逐项进行，讨论后应形成明确意见和决定。对于不能按时得出结论的议题，主持人征求与会人员意见后可决定将该项议题留待其它专门时间进行会议讨论，同时确定下次讨论的时间、地点、人员、议程。会议结束后，记录人最迟在下一个工作日整理完成《会议纪要》，发送与会成员及相关人员，并存档保存。

  报告机制：

1. 要求各组员以周为单位记录工作进展，形成开发日志，并以电子文档的形式提交给秘书进行整理，最后由文档维护员进行维护。

2.每周例会上各位组员积极对当前的开发工作进行积极的评审和建言，由项目经理做最后的作口头总结，由项目经理主持会议并记录和整理会议的内容。文档维护员修改和维护相应的文档。并交由领导组进行会议评审并给出意见。

3. 组成员都要密切监控风险状态，发现风险后提交风险报告。由项目经理定期提交风险报告。必要时将突发风险通知所有组员，并由项目经理做出临时处理决定。然后在该周的例会上由组成员共同讨论对风险的处理意见。并形成风险处理的日志做为以后的经验。

报告格式：

报告主题、时间段、发现人、报告内容、审核意见

评审机制：

每日做出日报的内容包括：自己的任务、完成的进度、遇到的问题、如何解决问题等内容。

邮件/文档确认

由于会议沟通方式的前提条件较多（如相关人员、时间、地点协调安排），所以另一种常用的沟通方式就是通过网络发送邮件/文档。对于需要领导决策或相关人员反馈意见的邮件/文档，根据紧急程度不同，其确认过程从当天到三天不等。

对于合同中涉及到的需要提交给银行的重要文档，在提交的时候，必须请银行相关人员在《确认页》签收，纸质的签收记录存档保存。

项目例会

为了保证项目组内部成员的工作接口顺畅、沟通有效，项目经理组织每周五下午召开项目例会，就本周的工作进行总结，对进度、技术、工作难点等问题进行交流讨论，然后明确下周工作计划，任务分解到个人。

要求项目组在例会结束后形成《项目周报》，项目经理发送给项目主管、销售代表、 QA 等项目干系人。对于例会中讨论的问题，也应在项目周报中体现。

项目报告

总体说来，对于项目计划和进度跟踪的报告层次为：项目总体计划 -> 项目周计划 -> 项目成员周计划 -> 项目成员周总结 -> 项目周总结 -> 项目阶段总结 -> 项目结项总结。

对于项目每周进展的情况，项目成员填写《个人周报》，项目经理填写《项目周报》，提交项目干系人；对于项目各阶段进展的情况，项目经理填写《项目进展报告》，于各阶段结束时提交项目干系人；项目结束后，项目经理填写《项目总结报告》，提交项目干系人。

问题上报

对于项目实施过程中发现的问题或者可能影响到项目进度、项目质量的不确定因素，首先考虑是否可以在项目组内部解决；如不能，采取逐级汇报的方式处理：项目成员 -> 项目经理 -> 项目主管 贵公司与公司方决策层。

QA 负责跟踪问题的上报、解决过程，确保所发现的问题得到及时、适当的处理。

客户满意度调查

为了保证项目实施过程中及时与银行方面沟通实施感受和反馈意见，以便及时采取相应的改进措施，最终提高贵公司方的满意程度，将指定专职人员定期对贵公司相关人员进行客户满意度调查。

在项目计划阶段，专职人员与项目经理协商制定本项目的客户满意度调查计划，明确调查的时间点。

在项目实施过程中，专职人员按照计划进行对客户的调查，销售代表、项目经理应协助其与客户代表交流沟通。对于调查中发现的客户反馈意见，专职人员如实记录并反馈给项目干系人，必要时上报公司主管协调解决。

销售代表、 QA 负责跟踪客户意见的处理过程，确保客户意见及时、适当的处理。