【转】维护项目的管理策略案例

维护类项目的定义：

       （1）在已交付的软件基础上增加少量功能；

       （2）对已交付的软件进行局部的需求变更；

       （3）修改已交付软件的bug；

维护类项目的特点：

       （1）工期短，客户要求相应快；

       （2）对已有的软件进行局部修改，投入的人力少；

       （3）变更容易对已有的功能造成影响，容易注入新的bug；

       （4）需求沟通、设计方案的确定、测试的工作量大于开发的工作量；

       （5）维护的请求比较多；

    （6）维护的请求具有不可预测性，随时可能会发生；

基于上述的特点，制定如下的维护类项目管理策略：

      1 变更的影响范围应该经过市场、需求、开发、测试的评估，识别对成本、工期的影响、识别技术的风险，然后进行决策是否接受此次维护请求；

      2 每个维护请求一定要有一个责任人，比如称为维护项目经理或产品经理等，负责该维护项目的始终；

 3 维护请求的进展状态进行跟踪管理。

 4 新增的需求在描述时应采用：功能需求描述+界面原型的方式，功能变更的需求应描述清楚功能的输入、处理、输出。

 5 需求的外部确认：一定要电话和客户沟通确认需求，然后给客户发送描述了如下内容的确认邮件：角色+功能+目的+验收标准。

 6 需求的内部沟通、策划会议：在本次会议上：

（1）   需求交底：由需求人员讲解需求，开发人员、测试人员和需求人员达成一致，不再另行进行需求评审；

（2）   快速设计：大家一起对做什么、怎么做、怎么测进行讨论，并记录设计与测试的核心思想；

（3）   工作量估算：在此次会议上一起讨论进行任务分解与工作量估算。

      7 定义WBS分解的模板，帮助项目组成员完备的识别任务，任务的颗粒度不超过8个工时，每个任务定义明确的交付物。

     8 维护成本核算：开发人员在项目管理工具中每天录入完成的任务与实际工作量。

     9 项目**：每天跟踪项目的进展，每周举行公司级的例会高层汇报。

     10 本次新增代码，要求开发人员新改代码工具静态检查，公司定义哪些错误或告警必须改，项目经理抽查是否修改了该改的告警。

     11 项目经理指定人员进行新增、修改的代码比对，对新代码进行代码评审。

     12 系统测试时应首先对所有修改或新增的功能进行测试，然后进行波及到的其他功能进行测试，如果时间允许，执行全面回归。

     13 周期性发布版本时，要定义版本发布计划。

     14 QA人员在过程中和项目结束时分别审计一次，帮助项目组总结经验教训。