首页>
试点项目的选取
首先试点项目要具有典型性和代表性：其中包括项目规模、人员构成、时间长度、结果跟踪。项目规模最好是平均规模的项目，不可太大或者为了制造出一个试点项目而圈定2-3人参加的小项目。人员构成应该是保持全部流程参与方的团队，例如一个典型的互联网项目需要有产品经理、交互视觉设计师、开发工程师、测试工程师、运维人员、运营推广员主要角色，在试点项目中最好能够包含这些全流程的角色。在互联网领域通常的项目交付时间长度应该是1~2个月，不可选时间太短（1~2周）或太长（＞3个月）的项目，时间太短可能一些项目活动都被剪裁了，时间太长则试点输出的结果需要很久才能得到推广。试点项目的结果跟踪指的是被选定的项目需要在项目开始的时候定义清楚如何衡量这个项目的成功与否（项目管理铁三角、线上数据表现、团队成员反馈、用户研究访谈等指标）
其次试点项目要得到业务部门领导的支持和授权，明确的让领导们知道这是试点，在试点过程中可能由于新引入的一些方法、流程不一定适合团队，而且可能会导致团队的效率下降。需要对试点项目希望达成的结果有统一认识，如通过试点项目找到比较适合目前团队的流程方法、度量指标，还是提高项目及时交付率，抑或是通过项目交付打造优秀团队文化和自组织团队。
最后试点项目团队成员需要知道自己身处‘试点’之中，犹如在拨打自助电话客服时被提示‘您的通话将会被录音’一样，使每个人有心理预期和准备，更能积极有效的加入到试点中来。
其次试点项目要得到业务部门领导的支持和授权，明确的让领导们知道这是试点，在试点过程中可能由于新引入的一些方法、流程不一定适合团队，而且可能会导致团队的效率下降。需要对试点项目希望达成的结果有统一认识，如通过试点项目找到比较适合目前团队的流程方法、度量指标，还是提高项目及时交付率，抑或是通过项目交付打造优秀团队文化和自组织团队。
最后试点项目团队成员需要知道自己身处‘试点’之中，犹如在拨打自助电话客服时被提示‘您的通话将会被录音’一样，使每个人有心理预期和准备，更能积极有效的加入到试点中来。
试点项目的执行、数据收集&分析
试点项目的目的要明确，需要针对性的收集数据，数据是为下一步决策改进提高基础，没有数据提供支持的决策基本上都是凭感觉和拍脑袋，正所谓‘无量化，不管理’。针对前面访谈所暴露出的主要问题，在试点项目中重点收集的数据有：项目人力支出、项目规模变化、线上bug数量、及时交付率。
项目人力支出
网易可以说是一个不差钱的互联网公司，很多产品/项目不需要进行相关的预算审核和营收考核的，大家可以在一种宽松的环境下发挥创造力，自由的打磨产品。但同时也带来一个问题，有些产品投入了上百人月但是用户规模、营收很不理想，就是导致团队成员怀疑其产品定位和质疑我们的价值、我们的ROI在哪儿。统计项目人力支出并不是想通过投入的人力来判断一个产品/项目的好坏，而是希望通过统计实际支出人力让部门总监知道在不同项目的人力投入，以及项目所带来的收益是否值得，后续如果有类似的项目是否还会投入这么人力、抑或是减少/加大人力投入，甚至需要考虑类似的项目是否可以直接从市场采购。
下图是一个对外合作项目的投入人力情况，数据来源是每周项目周会上每人记录在过前一周投入到这个项目的时间百分比，历时4个来月，总共投入了24人月。项目上线后的第一个月带来的销售额是2w多元，新用户数也区区可数不足千人。
在项目回顾会议上大家都认为这个项目的ROI 很低，需要在项目启动时慎重评估，项目发起方商务团队需要对接项目的结果进行预估和上线后有相应的衡量考核体系。
下图是一个对外合作项目的投入人力情况，数据来源是每周项目周会上每人记录在过前一周投入到这个项目的时间百分比，历时4个来月，总共投入了24人月。项目上线后的第一个月带来的销售额是2w多元，新用户数也区区可数不足千人。
在项目回顾会议上大家都认为这个项目的ROI 很低，需要在项目启动时慎重评估，项目发起方商务团队需要对接项目的结果进行预估和上线后有相应的衡量考核体系。
项目规模变化
在不同部门的初期访谈过程中，研发团队反复提到的一个希望是能够控制需求变更，减少变更。为了能够衡量项目开发过程中的需求变化情况，在试点项目中从项目规模维度进行了量化和记录。由于大家以前都没有接触过敏捷中的故事点估算方法，在大家对敏捷还没有什么概念的时候如果推行故事点估算的话将会遇到很多困难（故事点和人天间的换算、模块负责人估算的权威性等）。这里使用大家最容易理解的人天来进行估算，下图的项目在初始阶段时规模是112.5人天，中途增加了需求导致规模上升到145.5人天，同时实际花费的人力也是145.5人天，最后得出规模变化率为29%，其计算公式是：（实际花费人天-项目初始估算人天）/项目初始估算人天。
得出项目规模变化率的目的并不是想达到控制需求变化、减少需求变化，而是通过三个试点项目的统计数据发现在A部门中的项目规模变化率中位值是25%，通过回顾分析发现这些变化的需求大部分来源于两个方面：一是由于产品策划考虑不充分，例如一些异常情况的处理；二是技术实现上的难度比估算时更大。因此在A部门的后续其他项目中基本上预留额外的20%项目规模作为缓冲时间。
得出项目规模变化率的目的并不是想达到控制需求变化、减少需求变化，而是通过三个试点项目的统计数据发现在A部门中的项目规模变化率中位值是25%，通过回顾分析发现这些变化的需求大部分来源于两个方面：一是由于产品策划考虑不充分，例如一些异常情况的处理；二是技术实现上的难度比估算时更大。因此在A部门的后续其他项目中基本上预留额外的20%项目规模作为缓冲时间。
线上bug
在加入K部门后要求QA部门对线上bug进行了统计分析，并发出月度线上bug 总结邮件，P0级线上bug 是指已影响到用户使用的情况，不论影响了多少用户（如支付环节中支付不成功问题）。P1级线上bug 指的是不影响用户使用的功能（例如内部系统问题，活动页面图片/链接配置错误问题）。
| 统计时间区间 | P0 bug 数 | P1 bug 数 | 线上bug 总数 |
| 2015.7.16~2015.8.15 | 4 | 21 | 25 |
| 2015.8.16~2015.9.15 | 3 | 7 | 10 |
| 2015.9.16~2015.10.21 | 3 | 7 | 10 |
深入分析这些数据后还发现一个有趣的现象是约有1/3左右的线上bug是由于修改前一个线上bug 导致的，或者是由于测试场景不充分仓促上线导致的。基本上每天都在上线（当然如果CI做的好的团队、自动化测试足够的团队每天上线也许没有什么问题），合代码并进行手动回归测试基本上只有1天的时间。为了减少线上bug 的发生和做到有计划、有节奏的上线，因此制定了固定上线节奏（在K部门是每周二、周五两次）。
及时交付率
通过对部门中3个月里面交付的所有项目完成时间和计划完成时间的比较得出项目及时交付率，从3.11日到6.4日在部门中共上线了16个项目，平均项目时长31.8天（日历日），其中三个试点项目由本人作为项目经理，其他13个项目由开发负责人或者产品经理兼任项目经理。
16个项目中按计划日期上线的有8个（部门中的项目及时交付率为50%），这和访谈中大家谈到的项目延迟严重比较吻合。8个延迟项目中，延迟率从2%到60%不等，详情如下图所示： （由于涉及到公司具体的项目和人员在下图中的项目名称已做模糊化处理，项目经理一列中具体的人名已移除）
通过上图的数据可以看出超出一个月的项目延迟风险比一个月内的项目延迟风险要大得多，其中延迟57%、60%的两个项目主要原因是中途方案调整较大。
PMP小知识：项目管理办公室是提高组织管理成熟度的核心部门，主要作用体现在以下几个方面：
（1）为项目经理和项目团队提供行政职员，如项目各种报表的产生。
（2）最大限度地集中项目管理专家，提供项目管理的咨询与顾问服务，并将企业的项目管理实践和专家知识整理成适合与本企业的一套方法，提供在企业内传播和重用。
（3）充当高级管理层与项目经理之间的沟通桥梁。
（4）可以配置部分项目经理。
粤公安备案 44010602008731号