PMP管理：建立基本的项目管理流程和度量体系

项目集Roadmap机制

           公司的运营、部门的运作犹如行使中的高铁列车，一旦启动就很难停下来，部门中每位同事每天都很忙，最近两年互联网公司流行一个术语叫996（指工作时间从早上9:00到晚上9:00，每周6天），但是经过半年左右的996后，团队就会频繁的质问我们真的需要996吗？为什么每天都在救火？每个事情是真正值得做的事情吗？

           由于业务部门的业务不断发展壮大，业务启动时的单一仓库无法满足要求了，需要将货物挪仓，有时同一货物需要在不同仓库中发货，而开始的系统是针对单一仓库设计的，有些功能无法实现。例如某天的主管站会上一运营同事提出希望在不同的仓库间售卖同一商品时能够做到用户看到页面一个，并且评论共享。产品经理答应会后给出解决方案来帮助运营同事减少评论复制、页面复制的人肉工作量。但是，详细分析和了解目前系统架构和数据结构后发现底层商品逻辑不支持，需要对相关系统进行重构，也无法承诺具体什么时候能够重构完成。而仓库间货物转移早在2个月前就已经开始了，那是什么导致了如此重要的功能一直没有被提上产品开发日程呢？第二天项目经理和业务部门CTO就此事进行了讨论，得到的结论是平时大家都忙于应付紧急的事情，而这些重要的事情往往就被一而再、再而三的delay了。

           这类情况在其他部门也经常见到，因此对应的解决一个方法是设立部门重点项目集管理，通过每两周一次的产品roadmap 会议来对项目集中的每个项目状态在核心主管团队中review，以评估当前的重点项目是否有风险/问题、以及是否有新的项目需要纳入重点项目集中。

           下图是在K部门所使用的项目集列表，其中1~6个浅绿色背景的项目为部门重点项目。

           为了保障重点项目能够有足够的人力投入，和CTO及各位主管达成的协定是：一旦重点项目立项，那么需要保障人力来交付项目，如果其他项目或事情需要挤占重点项目的人力并且影响到重点项目交付的话，需要部门CTO批准。

三步评审法

在完成了三个试点项目后，摆在项目管理工作面前的问题是：如何找到适合于业务部门的项目管理基本方法和流程？诚然，原封不动的应用Scrum流程时机未到，并且阻力较大（涉及到组织结构的调整、新的角色职责、考评方式的改变），也无法照搬CMMI/IPD等繁重的流程体系。在和业务部门领导、及团队主管同事讨论后提炼出里程碑规划+迭代的项目管理基本思路，从项目启动到项目上线期间辅以3次主要的评审活动，取名为‘三步评审法’，这些评审活动的目的是使项目团队在‘做正确的事’方面更有保障。
通过对业务部门的项目交付流程的整理，梳理出如下图所示的基本过程，其中产品idea讨论阶段、和项目需求确认阶段是市场/需求小组和部门主管间的一些讨论，主要集中在市场前景分析、ROI预估等方面，不需要包含大部分项目组成员，因此这两个步骤没有纳入项目评审会议中。而最后面的项目总结阶段目前仅仅针对于有营收指标的一些项目进行分析，并没有覆盖到所有的项目中，所有项目的评审会议中也没有包含这一步骤。因此，‘三步评审法’包含的内容是下图中红色框内的内容：策划需求评审、交互/视觉评审、上线评审。

三次评审会议内容结构是：

会议名称	会议时长	会议目的说明	Input	Output	Owner	Approver	参与者
策划评审会	<= 1h	用户场景描述；技术可行性；项目的期望交付计划；	项目背景简介网站逻辑上如何被用户使用功能列表	交互计划项目整体大致计划确定项目组成员	项目经理	所涉及部门的leader们共同决策	项目组同事、所涉及部门的leader
交互/视觉评审会	<= 1h	阐述用户的交互体验是怎么样的	交互稿/视觉稿	视觉计划开发计划项目计划更新	项目经理	所涉及部门的leader们共同决策	项目组同事、所涉及部门的leader
上线评审会	<= 1h	各方判断是否可以上线准备启动上线后相关活动	上线评审PPT 可演示的软件	是否同意上线	项目经理	部门总监	产品总监、项目组同事、所涉及部门的leader

上述三个评审会时长限制在1个小时是希望会议组织者、参与者能够在会议前准备好，在会议上重点讨论有分歧的问题，避免冗长而低效的会议。

形成每周固定上线节奏

           结合前述访谈的反馈和试点项目的反馈，在业务部门中建议实施了每周二、周五两次固定上线节奏，上线窗口之外的上线均需要部门CTO批准，项目计划时将上线时间匹配入对应的上线时间窗口。这样的安排所带来的最直接的一个好处是使研发部门（开发、测试团队）的计划性更强了，工作也更从容了。
           通过两个月的观察和数据统计发现紧急上线频率下降的有限，实行固定节奏上线的机制后的第一个月紧急上线了20次（22个工作日）、第二个月紧急上线了18次（21个工作日），这其中主要原因是电商活动相关的一些修改和上线。通过和研发同事对这些数据进行分析，发现每次紧急上线的内容变少了，没有了以前那种搭便车的情况了，因而研发的压力并不是很大。

           要做的业务人员眼中的‘想发就发’的境界，下一步需要建立其比较完善的CI系统，其中最重要的是完善相关的自动化测试脚本，能够做到回归测试交由机器来完成，而测试人员聚焦在新功能的完备性测试和相关的探索性测试上。

最小度量数据集+闭环跟踪指标

           通过在试点项目中形成的数据统计，和业务部门领导达成了项目的最小度量数据集、以及闭环跟踪指标，其中最小度量数据集主要包含内容是：人力支出、及时交付率、规模变化率、线上bug。

           ①人力支出：在每次项目站会上收集项目成员投入到本项目的人力占比，单位为人天，用于衡量项目的基本人力投入。由于计算机服务器资源在互联网公司一般都是在云端了，所以这一块的成本基本不用在项目中进行记录和衡量了。

           ②及时交付率：用于项目延迟/及时交付情况，计算公式是：（项目实际上线日期-项目计划上线日期）/项目计划时长，日期对应的单位为工作日。

           ③项目规模变化率：可以使用人天或者故事点来衡量项目规模，规模变化率是指实际项目所花费的人天或故事点除以计划的人天或故事点，用于衡量产品方案的完备程度。获得较多数据后将可以用于项目缓冲时间的基准。

           ④线上bug：用来衡量项目质量的一个主要指标，记录线上bug 数量和严重程度。线上bug严重级别根据不同的业务可以进行划分，例如下面P0-P2级别划分是某部门的定义：

故障等级P0：重要性高的服务功能不可用或功能异常，且大面积影响到用户使用。

故障等级P1：重要性高的服务功能不可用或功能异常，但影响的用户有限；或者是，重要性中等的服务功能不可用或功能异常，且持续故障大面积影响用户体验。

故障等级P2：重要性中等的服务功能不可用或功能异常，轻微影响用户体验。

           其中闭环跟踪指标主要是在上线的1~3个月内对线上表现情况进行跟踪分析，记录的数据主要是营收和新用户数两大类指标，PV,UV以及复购率作为辅助指标。

全员培训

一个流程的确定和实施需要广而告之，让部门所有同事知其然、知其所以然，需要讲解为什么选取这样的流程、记录这些数据等内容，对部门全体同事进行培训，是开展后续全面项目管理必不可少的一个环节。

全员培训的内容主要放在如下四个方面

①流程和项目最小数据集：三步评审法的内容、输入、输出以及需要参与的人员介绍。解释为什么要进行项目的最小数据集度量，每个历史数据将如何使用（这些基本的数据不能用以团队成员的季度考评，主要用来衡量一个部门的整体的项目健康度情况）。

②成员职责说明：除了团队成员的各自角色介绍外，其中项目经理和产品经理的职责需要重点介绍，这是一般人比较容易混绕两个角色。项目经理主要工作职责是组织和协调项目中各项活动，提高团队效率；项目计划跟踪执行，识别风险和解决团所遇到的问题；服务于产品，使项目顺利交付。产品经理主要工作职责是理解用户需求、定义产品形态、形成需求列表和决定功能优先级。

③不同项目类型的定义：为了简单起见将项目分为重点项目、非重点项目两大类别。特别需要对重点项目的评选机制、变更流程要重点说明，并且让大家清楚的知道当前有哪些项目是重点项目。

PMP小知识：项目经理的职责：
（1）参与项目活动，给高级管理层提供关于启动项目的专业协助。（2）组建、建设和管理项目团队（3）领导项目计划编制工作。

优培东方
PMP^®1月班报名招生正在进行