IT项目管理总结

一、项目规划阶段

1.项目了解

  了解项目性质、项目需求、预期产品的功能、针对的客户群、项目目的；了解客户和公司对项目的看法、对项目的实际期望，与客户和公司进行需求分析和技术可行性分析。

2.需求分析   

  针对项目要实现的功能和性能，召开项目需求分析会议，根据项目分析需求、确定需求、整理优先级，保证项目组核心成员（产品经理、UI、IOS、Android、后台）必须清晰和统一理解产品需求；展示产品原型，详细讲述产品的核心流程、功能架构、信息架构，结合用户使用场景进行阐述，设计出符合用户习惯的界面和交互风格；开发出符合用户要求的交互和产品界面；搭建出更好的数据处理后台。

项目相关文档

序号

文档名称

1

产品原型文档

2

UI设计图

3

后台API文档

4

开发计划

5

可行性报告

    2.1创建WBS（工作分解结构）

根据产品原型，将需求细化分成工作包，每个工作包完成时间不超过一个工作日，超过的再次分解，直到分解成在一个工作日内完成的工作包；每个项目组成员明确工作包目标、时间和交付，避免出现资源空闲的状态或者无效的资源投入；明确项目组成员的工作职能和任务。

 项目细化分包：

1.项目经理细化分包；

2.项目组长细化分包，上报给项目经理汇总；

3.项目组成员细化分包，上报给项目经理汇总；

  项目细化分包意义：

    高度细分的工作任务，将极大的提高项目进度估算的准确性，更好的把控项目进度，同时督促未完成的工作及时完成，增加开发成员的紧迫感。

工作分解结构单位

工作包：

 

工作包编号：

 

工作描述：

 

负责人：

 

开始时间：

 

结束时间：

 

工作期限：

 

 

 

  

 2.2 绘制项目进度图

    根据工作包的前置任务和项目周期绘制项目进度图，依赖性工作包优先，再根据每个工作包周期，计算项目的关键路径，关键路径是项目从开始到结束的耗时最长的一条工作流程，决定了项目的周期。

目的：项目经理从整体更好的把控项目进度；

意义：

1.更加直观清晰的展现项目进度；

2.重点关注优先级工作包的完成情况，决定了项目进度；

3.项目如提前完成，优先级工作包是重中之重。

        如下：

清单

开发

完成

本次

待开发

开发中

测试

 

 

 

 

 

迭代

BUG

 

 

 

2.3 绘制项目进度甘特图

以项目开发任务中要求的日期为准，创建1、按照项目计划、启动日期和结束日期； 2、每个阶段计划和实际的开始、结束日期为主的进度甘特图。

目的：管理项目整体进度；

意义：项目进度甘特图详细记录了每项工作的任务顺序和完成情况。项目经理可以实时了解项目的进展情况。

 

 

3.协同管理

    培养项目组核心人员，协同管理项目进度，负责处理解决项目中遇见的技术问题，项目经理重点负责把控进度和协调工作。

二、执行阶段

项目进入开发执行阶段以后，项目经理的主要工作将围绕把控项目进度，协调各组、各部门之间的工作，为项目做好保障工作，确保项目按时交付。对于执行阶段的工作，给项目组成员分发项目进度计划，时刻提醒什么时间将要完成什么任务，每天都要关注开发人员的开发进度；及时的发现问题并解决问题，前期问题越多，后期问题越少；在检查的过程当中，有可能会发现一些还没发现的问题，或者跟这个任务相关的问题。任务的完成进度和完成质量，是影响项目进展的一个重要因素，项目经理的一个主要职能，就是帮助每个任务的快速推进。

     1.项目晨会

对于项目组晨会，主要议题如：

1. 项目组成员更新前一天完成的进度、用时，如未完成，估算完成需要的时间；

2. 项目组成员更新今天准备完成的任务和目标；

3. 有哪些进度需要其他项目组成员配合；

项目经理将每天晨会信息记录并更新到项目进度计划表内，实时把控项目进展，预测项目是否延期并采取相应措施（如增加项目成员或赶进度）。

注：晨会避免讨论问题，只更新状态，保证在10分钟内结束，如需讨论在晨会结束后单独沟通，防止浪费项目组其他人员时间。

 

      2.开发/测试阶段

针对APP项目，后台和APP的交互通过接口（API）来完成，应该让后台写好相应的接口（API）并编写假数据，方便APP端顺利开发。
    测试工作，开发设定好里程碑，设定原则不能超过一周，每发布一个里程碑，就必须完成测试，同时反馈给开发人员，避免周期过长对代码的熟悉性降低，修改BUG的效率降低。 一个项目或一个短迭代，应该列出都认同的里程碑列表；里程碑的完成有共同认同的验证方式。
　　

      3.需求变更

      3.1 分级管理需求（或变更） 

按照需求变更流程管理，项目经理提交正式的变更申请，项目组评审，评审通过后修改产品需求文档和产品原型，进入执行阶段。对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。  
      一级需求（或变更）是关键性需求，影响项目的正常交付使用的，定为“紧急（Urgent）”, 属于补救性的debug类型。  
    二级需求（或变更）是后续关键性需求，不影响前面工作的交付，但不完成新项目内容则无法提交或继续，属于“必需（Necessary）”。一般新需求关键性的基础组件，属于这个级别。  
    三级需求（或变更）是后续重要的需求，体现项目价值，属于“需要（Needed）”，重大的有价值的全新需求开发，属于这个级别。  
    以上三个等级是应该实施的，作优先级的排列。  
    四级需求（或变更）是改良性需求，不完成也不影响已有功能的使用的，完成对功能更好的，属于“更好（Better）”。一般是界面和使用方式的需求，如果时间和资源条件都允许的话，可以完成。  
      五级需求是可选性需求，一般为设想和可能，属于“也许（Maybe）”，选择性的完成。 

 3.2需求变更管理  
      项目可以分为三个阶段，即项目启动、项目实施、项目结束。需求变更的管理和控制贯穿整个项目的全过程。 需求变更管理，需要采用综合变更控制的方法。

      （1） 项目启动阶段的变更预防  
      任何软件项目，都会存在需求变更,这个应对从项目启动的需求分析阶段开始，需求分析文档越详细清晰，需求变更的几率就越小。

      （2） 项目实施阶段的需求变更     
      项目实施阶段的需求变更需要做分析变更请求，评估变更可能带来的风险和修改文档。  
      控制需求变更需要注意：  
    1.需求变更要经过同意并签字。  
      2.需求变更要经过需求管理流程。  
        （3）项目完成阶段的总结  
      项目总结工作应作为项目持续改进工作的一项重要内容，同时可以作为对项目、设计方案与目标的确认和检验。包括项目中发生的变更和项目中发生问题的分析统计的总结。  

      3.3 需求变更管理  
     （1） 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。  
    （2） 制订变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。  
    （3） 成立包括用户方和开发方决策人员在内的项目决策组，负责裁定需求变更。  
    （4） 需求变更先申请再评估，最后评审确认。  
    （5） 需求变更后，受影响的项目内容进行相应的变更，保持和更新的需求一致。  
    （6） 保存需求变更的相关文档。 

   

      4.阶段会议

    项目执行阶段，每完成一个项目里程碑，由项目经理召开里程碑会议，展示demo，由团队成员评审是否达到要求。未完成的计入下一阶段工作。开发组成员阐述本阶段的工作，分析总结经验教训，更好的完成项目进度。

三、项目结束

    3.1项目结束阶段，做好评估和验收，写项目评估验收报告：

     1.评估投资的回报率，评估实际和计划费用的差异；

     2.项目进度与计划时间的一致性；

     3.项目的整体质量，预期达到的效果；

     4.项目控制

     3.2开项目总结会，分析项目成功的主要原因、项目失败的主要原因，分析整个项目开发中的经验、教训，总结处理措施和解决方案，传承项目优势，奖惩开发人员；项目经理和开发人员分别写项目总结报告，做好项目信息归档。

3.3文件归档

项目步骤

文件名称

项目规划

项目可行性报告、策划书等

项目准备

WBS图、甘特图、风险计划、等

项目开发

例会报告、项目会议纪要、需求变更申请表、里程碑记录表等

项目结束

项目评估验收报告、项目总结、项目交付等相关文档

3.4项目全部工作完成以后协调部门关系，做好项目的移交、交付工作。
--------------------- 
作者：诺古言召 
来源：CSDN 
原文：https://blog.csdn.net/vc_bin/article/details/54914222 
版权声明：本文为博主原创文章，转载请附上博文链接！