项目管理方法

XXXXXX有限公司

北京本地管理工作计划探究

开发一部：  pekey

日    期：  2017年 4月 8 日

 

第一章 引言

北京团队发展至今，虽然在各方面有所进步，但总体来说，管理上有所欠缺。尚未能完全独立承担应有的任务。由于北京团队的特殊性，无法按照杭州总部的工作规划来按部就班的执行，特殊主要表现在几个方面：

1、现场性，所处的环境为客户现场。

因为在客户现场，所以DT或投产演练、及后续的运维过程中，北京团队的成员因“就近原则”优先处理现场紧急任务，从而会耽误本身的工作任务。

2、环境问题，多次因环境的问题导致任务延迟。

环境问题主要表现在没有统一自主的开发环境（主要是xnet、MQ、数据库等环境），虽然行方提供了组装测试环境，但由于系统、数据库管理员等权限的问题导致很难维护。通常要借助行方的力量，有时候会因为一个授权的问题延误很久。

3、网络问题，VPN或外网、内网链接不顺利。

VPN账户冲突，导致大家在连VPN的时候常常出现异常，又没明显的错误信息（大家解决的方式就是一个个链接去试）；awifi是目前最常用的外网连接方式（网卡只能一个人用，有时大家都着急入版本就只能等待），大部分情况能提供良好的网络支持，偶尔也会在提交版本或者入库时无法使用导致紧急任务延迟；内、外网络切换不顺畅。

4、沟通问题，缺少较好的介质与总部实时沟通。

现在最常见的沟通方式为微信或者电话，由于语言表达或者成本的问题，有些问题无法描述清楚，最终的结果是讨论的结果与实际的执行大相径庭。除此之外，电话沟通时，对方因会议或其他情况无法马上做出响应时，另一方只能不定时的重新打电话建立沟通，极为影响效率。

针对以上的问题，经过思考，针对北京团队的项目管理措施、重点项目管控、团队负责人的自我规划及17年度重点关注、提升、推动工作等方面阐述，北京本地团队的管理工作规划。

第二章  项目管理措施

在上一章节提到了北京团队所面临的一些问题及困惑，下面主要谈一下我对北京团队管理的一些想法，主要从项目的整体管理、项目范围管理、进度管理、成本管理、质量管理、人力资源管理、沟通管理、文档与配置管理、风险与变更管理等几方面描述一下项目管理的措施与规划。由于北京团队基本上是从项目立项后开始，所以项目的立项与招投标管理不予考虑。

2.1项目整体的管理

项目整体的管理，其实是项目负责人对整个项目的整体把控，明确输入与产出。跟踪项目的整个过程，分析、监督和控制项目的整体情况，保证成本核定及质量、风险等管理，与总部的管理方式大体一致，不做详细描述。

北京团队需要注意的是：项目负责人在做整体管理之前一定要明确项目成员及项目范围，在项目立项后两周以内需拿到所有项目相关文档，明确任务内容、了解大体目标，确定概要预估，在第三周初以报告文档（概要文档，能表述清表达意思即可）形式提交PO及部门经理，并在本周内完成理解偏差的纠正。

2.2范围管理

北京团队负责人应注重项目的范围管理，由于条线的产品经理、架构师等都在总部，加上北京团队对整体业务的把控不到位，所以在项目范围上应当重视，且总部应予以引导及支持，协助规划好项目范围划定。

在项目大体范围确定后，采用WBS（work breakdown structure）工作分解结构来对项目范围进行分解、细化，逐步分解为更小的，更易于管理的项目单元。编制WBS的计划，根据对需求的理解，罗列出工作分解的详细范围，罗列所有功能点。可根据WBS的最低元素评估工作计划、安排进度及项目跟踪。

WBS制定完成后，需要项目相关的干系人确定，确定后可作为项目范围基准参考，形成工作说明书（SOW），任何的变更都可以依据该基准进行分析、评估后做出变更结论。

WBS作为项目范围管理过程中的一个输出产物，应包含需求细化、功能点分析、人员成本评估、项目进度计划。所以，分解的越准确，对进度和成本的估算就越准确，而且分工明确。

2.3进度管理

影响北京团队项目进度的最主要因素时上个章节提到的现场性，由于外部不可推卸的任务而影响本身的进度。除此以外时分工的问题，个任务单元的活动有依赖，环环相扣，有的是需要并行，有的是需要串行。这是就需要项目负责人根据实际情况来沟通外部因素导致的进度延迟、合理安排人员处理串行任务。

项目负责人应处理的几个主要任务：

1、里程碑：项目重大事件及问题或一个显著的时间点。

理论上讲，项目应该严格按照里程碑上的时间点完成任务，除非发生需求变更。

2、逻辑关系：当多个项目活动产生依赖时，依赖关系形成了逻辑关系。

完成-开始，后续活动开始前，必须完成前导活动。

完成-完成，后续活动结束前，必须完成前导活动。

开始-开始，后续活动开始前，前导活动必须开始。

开始-完成，后续活动结束前，前导活动必须开始

3、项目跟进及逾期赶工：

项目工期缩短时，要在计划中串行的顺序活动中重叠安排工作，达到快速跟进。赶工时尽量以最少的成本、最大限度的压缩单个活动周期，从而压缩总的项目周期（通常需要加班，加工时来解决，这将会增加人力成本）

4、工作量偏差统计：

在项目经行过程中，跟进项目的实际工作量，精确到人/时，每周统计出本周实际工作量，与计划工作量进行核对，得出工作量偏差统计结果，并根据统计结果分析超前和滞后的原因，及时在里程碑范围内适当调整工作计划。

北京团队应当注意的是：

（1）在项目经行过程中，遇到外部因素需要暂停进度时需向项目负责人汇报，由项目负责人评估是否会对项目进度产生重大影响。若影响较大，应由项目负责人沟通回绝，并说明理由。不能因为外部因素而导致本身项目滞后而造成的人力成本增加。

（2）项目负责人应分析好前中台与后线的逻辑关系，协调好任务的安排。尤其是在系统组装测试过程中，沟通好先后顺序。在本身任务中，多单元的活动也要分析，对于串行的任务，任务量不大的话，最好安排一个人执行。

（3）若项目成员有不可推卸的原因请假，需及时汇报PO或部门经理，要求增加人员来零时替代。

（4）项目工作量评估不可单采用乐观估值或悲观估值。过于乐观会导致项目后期严重加班来补救，造成工作量超时；过于悲观会导致项目后期无所事事，人员浪费。（目前情况来看都是过于乐观）

2.4成本管理

成本应考虑项目估算、预算、成本、净值等。

北京团队更多考虑的应该是：进度偏差、工作量偏差。

成本管理方面主要还是根据项目进度来把控，通过工作量偏差统计来实时调配人员，到达工作量饱和。对于不同等级的项目成员，安排不同的工作，达到每人都能在自己的计划范围内完成自己的任务。避免经常加班，增加人力成本的情况。

2.5质量管理

质量管理的原则：

1、质量首先应该满足客户的需求，只有质量成本一致，才能让客户满意

2、项目全员参与、质量责任明确到人

3、不许镀金

4、预防胜过检查：质量出自计划、设计和建造，而不仅仅出自检查

5、质量应持续改进：PDCA循环（计划-执行-检查-改进）是质量改进的基础。

所以，北京团队应当

首先满足需求（重中之重），要求所有成员在项目开发过程中事事关注需求，以需求为轴线开展任务。

质量的检查不只是项目代码的检查，还有对需求理解，潜在性的问题做相关的检查。

制定质量管理目标，在项目前期做好预防。如代码规范检查，不能到了提交版本才去检查，要阶段性的检查。

代码注释：要求代码注释率不低于30%，负责逻辑代码注释率不低于50%，JavaBean对象的每个字段，数据库的每个字段均应添加注释，且对于枚举类型要列出每个类型的含义。方法参数应明确每个参数含义（尤其是xnet接口）

文档质量：项目分支建立时，应包含一系列的文档资料，需求分析、设计文档质量要高，不能含糊其辞。在详细设计文档中，要每个成员对自己模块做详细补充。

2.6人力资源管理

在项目初期，总部的条线PO应整理出业务干系人，项目负责人整理出，前中台所有参与者的工作职能及联系方式。最终汇总成一个excel提交到项目文档库中提交SVN管理。（这样可以使项目成员直接的协调与沟通）

项目人力资源计划与编制。

项目的团队建设，主要是组织结构的划分及职能分配。

项目的团队的管理

1、实时了解团队成员的动向及问题

2、解决处理成员间的矛盾，主要是前中台与后线的矛盾

3、求同存异

4、合理对话，解决分歧

 

2.7沟通管理

沟通是项目负责人的重要职责。沟通也不只是项目负责人的任务。项目的进度是否高效很大程度和沟通有关。在上一章节的问题中也提到了沟通的问题。

北京团队的沟通主要还是以会议的形式为主：

1、每周应当举行一次周例会，团队负责人关注一下每个人在本周的具体表现及任务完成状况。

2、团队负责人需定时的和总部举行会议汇报情况（项目进度，及人员的工作饱和度）

3、每次的会议应当形成简要的会议纪要

除会议形式以外，团队负责人还需出差和总部经行沟通（主要是在需求分析及项目设计阶段，务必要确认范围，分解项目任务，制定好完善的工作计划）

项目成员间的沟通，形式多样化（微信、电话、邮件等）。

希望在非正式沟通中大家能相互理解及予以帮助，把每个人需要请求你的事情放在心上，若有事脱不开身，在事后及时和对方联系。

在于甲方沟通时最好在电话沟通结束后，以邮件的方式知会对方。

2.8文档与配置管理

文档与配置管理涉及到对内部测试和DT测试及投产的影响，所以文档与配置管理是很重要的环节

北京团队: 所有的文档及配置管理均需入SVN统一管理

1、增加对入库版本的管理：团队负责人针对每个项目创建入库版本模板，每个成员，在入库后，都要维护该模板，将自己入库的版本信息填写。好处是在测试前，每次的版本入库内容清晰，节省最终汇总的人力物力。

2、增加项目详细设计文档的管理：团队负责人会编写项目设计文档，对每个分解的功能做概述（主要包括设计方案及逻辑流程），项目成员在完成被分配的任务后，需在设计文档中相应的功能模块中增加详细步骤（主要包括：页面截图，类图、逻辑图、核心伪代码【重要功能才写】）

3、jar包维护文档，若jar包有变动，应在该文档维护好。方便其他人在build中维护jar，避免引起不必要的编译错误。

2.9风险与变更管理

项目变更会导致相应的风险，在项目变更后要及时重新评估工作计划，合理调整工时，与业务沟通尽量确保工期延长。

变更管理要按照总部的变更流程，变更责任到人、分工明确、可追踪、过程记录要完整，每次变更需形成文档。

项目风险几乎是每个项目中都会存在的，由于前期需求分析不明确、客户零时增加新功能、开发过程中遇到难以解决的突发问题等等。

在遇到项目风险的情况下，负责人首先想到的是加班来赶工期。北京团队也一直是这么做的。这并不是一个好的解决方法。

希望能形成问题库，最好每个人在遇到棘手的问题，经过很艰难的排查后一定要形成文档，详细描述问题发生的原因，如何经行解决的，类似的问题可以从那几方面来考虑等内容。

问题库同样是知识库，加入SVN统一管理。对于公司的一些新技术、新框架、或者常用技术及框架，应提供公共下载的地方，供大家学习。团队内部组织学习小组，互相讨论沟通。

2.10建议

针对第一章节所存在的问题，作为北京开发二组团队负责人，想提出以下几点建议：

1、北京团队需要建立内部的网络，需提供自己的开发环境（最好是linux环境），北京团队需要自己内部的SVN库（主要负责资源库、问题库、相关文档等相关信息），创建统一oracle数据库（国内、自贸区、海外）。搭建Xnet通讯服务及MQ环境，方便北京团队内部开发及组装测试。

2、沟通问题，最好能提供固话或者视屏电话会议等。北京团队缺少小型会议室及投影仪等，在会议讨论及代码review等方面都不太方便。

3、网络方面，VPN冲突及awifi不稳定的问题，chinanet貌似更好一些，需要收费，建议采用chinanet独人独享网络。

第三章  自我提升

作为团队负责人，在17年度重点工作从项目组长角色（关注编码）朝项目管理方向转变（关注设计及管理）。

1、思想转换，以项目设计、管理及培养新人为主。减少自身的编码时间，以把控项目进度，解决开发问题主要方向。

2、组建北京二组开发团队，落实好新人的培养。

3、加强和总部的沟通工作，深度学习xpads后线业务及管理制度。

4、制定详细管理措施（质量管理--代码注释，命名规范等；进度管理--项目分解规划；沟通管理--明确会议章程等）