软件项目实施过程控制

项目实施过程控制

项目管理综述

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

主要领域:

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

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

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

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

●开发规范；

●项目计划和控制；

●沟通管理；

●质量控制；

●风险控制；

●项目实施管理；

●问题管理；

●人员管理；

●变更革管理。

管理目标及优先级

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

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

高目标。

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

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

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

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

风险管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、目标以及需求不明确

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

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

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

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

3、代码质量或返工风险

质量风险主要指开发代码的质量。如何提高开发人员开发的质量？在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有时开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，code review 时严格考核。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重