UEDC-网易互联网项目管理体系学习笔记

一.网易互联网项目管理体系概论

1.1 互联网项目管理工具实践

环节包括：需求，设计，研发，发布和运营。要形成运营，研发和产品的闭环。

1.2 核心理念

1.2.1 核心目标

形成产品探索，产品研发和产品运营的产品闭环周期。形成闭环可以探索调适，持续改进并不断发展。流动性（快）的重要性：调适能力，应变能力和创新能力。另外，我们要提升各个环节的效能，其要素就是效率和质量，效能是产品目标下的价值，也是研发效能上的延伸，这样便可以提高产品成功的概率。

1.2.2 核心框架

三大环节：产品运营，产品探索和产品研发。关注效能：质量和效率。形成完整闭环，不断验证和改进。每个环节包括核心过程和核心指标。

核心过程由产品探索和产品研发组成。产品探索包含策划，交互，视觉，研发和验收。实体是产品功能，产品策划对产品功能的生命周期负责。产品研发包括分析，设计，评估，开发，测试和上线。实体是产品版本，产品开发对版本的整个生命周期负责。

核心指标包括效率，质量和周期三大部分。效率即投入产出比。定义为完成规模/完成周期的总人力投入。它描述产品团队生产效率情况，用于监控预警效率上的问题，但单个数据值没有意义。影响效率的常规因素包括人力浪费多（人力冗余，人员等待，沟通协作和延期），完成的工作量太少（半成品多，完成效果差和待做需求少）。

质量方面一般主要关注线上bug数，它是指一定周期内线上环境发现的bug数总和，描述产品质量情况，监控预警产品质量的问题，但单个数据值仍然没有意义。常规影响因素有两个方面，一个是Bug原因分类（环境原因，用例缺失和测试不充分），另一个是Bug引入阶段（产品策划，交互设计和研发）

周期是指产品交付周期和产品研发周期。产品交付周期是指产品功能从开始策划到验收上线的时间，描述产品响应能力和迭代速度的情况，监控预警产品响应能力和迭代速度问题。但单个数据值没有意义。常规影响因素有产品需求（颗粒度太大，优先级管理不够），产品研发成本高（耦合度高，自动化程度低）。产品研发周期是指产品版本从计划开始到实际发布的时间。

1.3 最小数据集

要理解项目管理中的最小数据集，首先得理解两个基本概念：规模和工作量。规模是指产品功能的大小，描述单位为故事点，是相对值。工作量是指完成产品功能的工作时间，其描述单位为Person Hour/Day，是绝对值。

1.3.1 基础数据定义

1. 计划规模story point：周期初计划的所有故事点之和
2. 实际规模story point：周期末实际的所有故事点之和
3. 完成规模story point：周期末所有关闭的故事点之和
4. 内部bug数：周期内发现的所有开发阶段bug数之和
5. 线上bug数：周期内发现的所有线上环境bug数之和
6. 计划研发周期：计划的版本开始时间和结束时间长度
7. 实际研发周期：实际的版本开始时间和结束时间长度

1.3.2 建立在基础数据定义之上的最小数据集

1.3.2.1 完成率

计算方法为完成规模/实际规模的百分比。意义：指示周期内需求交付的情况。期望的趋势是完成率逐步增高。潜在负面影响：一味追求完成率，可能导致DoD制定及执行不严格，可能导致质量的降低。推荐用法：人天的规模计算，受制于人员技能等，推荐逐步向故事点过渡。

1.3.2.2 需求蔓延率

计算方法为实际规模/计划规模的百分比。意义：指示周期内需求变更的情况。期望需求蔓延率逐步接近于1。潜在负面影响：一味追求蔓延率，可能导致业务拥抱变化能力变弱。推荐用法：过程中可能发生需求变更，推荐及时记录说明，但不应影响延期率分母

1.3.2.3 延期率

计算方法为（实际研发周期-计划研发周期）/ 计划研发周期。意义：指示团队按期交付情况。期望延期率逐步趋近于0。潜在负面影响：一味追求按期交付，可能导致质量降低以及规模缩减。推荐用法：过程中可能发生计划变更，推荐及时记录说明，但不应影响延期率分母。

扫描二维码关注公众号，回复： 5242867 查看本文章

1.3.2.4 内部bug率

计算方法为内部bug数/完成规模的百分比。意义：指示开发过程中的质量，部分指示测试质量。期望：内部bug率逐渐降低。潜在负面影响：开发可能拒绝承认bug，影响测试提交bug。推荐用法：在开发没有提升改进前提下，此数值可以大体衡量测试质量，两者互相制衡，以期获得客观有效的bug。

1.3.2.5 冒烟通过率

计算方法为通过的冒烟用例/全部冒烟用例的百分比。意义：指示提测质量。期望：冒烟通过率上升，一次冒烟达100%。推荐用法：较为坚定支持冒烟通过率100%。潜在负面影响：应谨慎对待冒烟用例的选择，过多过细的冒烟用例会造成冒烟滥用；过少的冒烟用例会无法起到主干保障作用，冒烟测试不应引起开发测试的对立，妥善引导。

1.3.2.6 线上bug数

计算方法为线上bug数量统计。意义：指示线上质量。期望：线上bug数逐步降低。潜在负面影响：出于团队绩效的博弈，可能线上bug情况会有少记漏记。推荐用法：部分bug可能因为过于细小而被认定不计入线上bug，可以接受不同的团队对于线上bug认定标准不同。

最小数据集的意义在于关注效能并持续改进。监控项目实施过程中的各种问题。效率指标有：完成率，延期率和需求蔓延率。质量指标有：冒烟通过率，内部bug率和线上bug数。周期指标有：交付周期。

总结一下，核心目标是产品闭环周期内提升各环节效能（效率，质量），以提高产品成功概率。核心框架有三大环节，关注效能并完整闭环。核心过程有3个。产品探索过程（策划，交互，视觉，研发和验收），产品研发过程（分析，设计，评估，开发，测试和上线）和产品运营过程。核心指标：效率指标，质量指标和周期指标，体现为最小数据集。

二. 网易互联网项目管理工具实践

2.1 JIRA工具

2.1.1 类型定义

包括4种主要的类型定义。EPIC表示产品目标，STORY表示产品功能需求，SUB TASK表示完成功能所需任务，BUG表示产品缺陷。

2.1.2 STORY 工作流

• 开始
• 策划中
• 交互中
• 视觉中
• 开发中
• 待上线
• 关闭

2.2 需求管理

2.2.1 功能需求生命周期

有三个大的阶段：需求准备，研发计划和研发上线。需求准备阶段对应：开始，策划中，交互中和视觉中。从交互中开始，做研发计划。研发上线对应研发中，待上线和关闭。

2.2.2 方法

产品目标（EPIC）的创建要满足SMART原则，可以使用用户故事地图。功能需求（STORY）的创建则是在目标确定后，针对目标分解为功能需求，需满足INVEST原则并录入到JIRA。任务（SUBTASK）的创建则是需要策划和研发为实现产品功能而拆分相关任务，产品策划在策划或者交互，视觉之前要创建子任务：

1. 策划：策划任务
2. 交互：交互任务
3. 视觉：视觉任务
4. 研发：研发任务，包括前端，后台和测试
5. 待上线：走查任务

产品策划监控和更新STORY状态直到验收关闭，各子任务负责人接到JIRA任务需要按照要求完成任务，并及时更新状态，直到验收关闭。原则：一人一单，负责到底。产品策划要关注功能需求的完整生命周期，对最终交付负责。整个过程遵循看板管理方法和JIT原则，增强流动性，限制半成品。看板面板可用于产品团队站会，同步更新目前产品进展。

2.3 研发管理

2.3.1 版本和迭代

迭代（Sprint）是研发计划周期，有固定时间周期，迭代结束不一定要上线交付，一个迭代可以包含多个版本。而版本（Version）则是一次上线功能需求集合，版本周期按需调整，版本结束要上线交付，一个版本可以跨多个迭代。

2.3.2 迭代计划

通过待办事项（Backlog）的面板来计划迭代工作和发布版本。由项目经理组织安排版本计划，同时对应研发需要做好分析和评估，确认是否能在迭代内完成。完成需求准备的Story才能进入Backlog，网易会把进入视觉状态的Story放入Backlog中。产品经理对Backlog进行唯一的优先级排序，优先级高的功能优先排入当前迭代计划。计划迭代上线的版本，也可参考发布火车的模式：每隔一定周期定时定点发布，能赶得上的就上线，赶不上就安排下次上线。迭代周期内，要尽量控制变更，如遇hotfix，也需要单独建版本进行记录和追踪。在估算工作时子任务的估算累加作为故事的估算。过程监控通过SCRUM面板和燃尽图进行，燃尽图监控进度风险。做好缺陷记录和跟踪和版本发布。

三. 网易云计算敏捷转型

3.1 云计算项目介绍

网易云计算是网易云基础服务，深度整合IaaS，PaaS及容器技术，提供弹性计算，DevOps工具链及微服务基础设施等服务，帮助企业解决IT，架构及运维问题，使企业聚焦于业务，是新一代云计算平台。

技术架构

模块

销售-产品闭环

角色分工

3.2 全流程项目管理

3.2.1 团队组织形式

有三种组织形式。首先是模块团队。是一种实体团队，负责完整的模块服务体验，负责模块的技术架构，负责模块的质量和维护。其次是职能团队，也是一种实体团队，负责对某职能的人力支撑和调度，负责对某职能的专业能力提高，负责对某职能的人员培养。最后是功能团队，这是一种虚拟团队，临时且动态，直到功能交付，跨模块，跨职能组成，负责对某功能的交付。

3.2.2 流程闭环

效能闭环

目标主干流程

3.2.3 全流程

3.2.3.1 主干流程

主干流程

1. 外部合作立项流程：里程碑和合作意向
2. 核心小组：
   • 横向/基础能力（架构师，产品经理，项目经理）
   • 垂直业务（模块负责人，产品经理）
3. 目标调研
   • 产品调研（竞品调研，场景分析）
   • 技术调研：可行性分析
   • 环境/资源分析：可行性/实施条件
4. 目标确认
   • 交付标准
   • 完成时间
5. 目标分析分解
   • 产品概要：产品经理负责，产品框架，功能/非功能需求，发布策略
   • 技术概要：架构师/模块负责人负责，架构概要设计，技术关键路径，技术风险
   • 环境/资源需求：SRE负责
   • 项目计划：项目经理负责，需求拆分（纵/横），时间节点，交付物/标准 & 负责人
6. 研发：信息同步，交付节点检查，风险管理
7. 交付验收：内测/灰测流程
8. 运营/反馈：线上运维规范，Ticket流程，故障处理流程

3.2.3.2 产品研发流程

产品研发流程

1. 需求评审
2. 设计评审
3. 版本计划
4. 版本研发
5. 版本上线
6. 版本走查

3.2.3.3 上线规范

上线规范

3.2.3.4 线上运维规范

线上运维规范

3.2.3.5 故障处理流程

故障处理流程

3.2.3.6 业务交付流程

业务交付流程

3.2.3.7 工单处理流程（Ticket流程）

工单处理流程

3.2.3.8 建议反馈处理流程（Advise流程）

工单处理流程

3.2.4 项目管理工具

3.2.4.1 问题类型关系

问题类型关系

1. Epic
2. Feature：产品，运营
3. Story：开发
4. Task：职能角色
5. Bug
6. Ticket：技术支持
7. Advise：任何人
8. Incident：技术支持

3.2.4.2 需求管理过程

需求管理过程

3.2.4.3 Story生命周期

Story生命周期

3.2.4.4 Task生命周期

Task生命周期

3.2.5 数据统计

3.2.5.1 效率

包括：总体完成度，有效产出率，bug率。

效率

3.2.5.2 质量

包括：bug总数，百人天bug率。

质量

3.2.5.3 周期

周期

3.2.5.4 可用率

可用率

3.2.5.5 硬件资源使用情况

硬件资源使用情况

3.2.5.6 市场运营数据

市场运营数据

四. 高速发展的网易严选如何应对变更

4.1 严选变更管理

4.1.1 预防

进行立项评估，首先是项目背景与价值，项目目标，竞品情况，方案概要，设计系统或相关方，影响范围，期望上线时间，效果评估，存在风险。其次是需求分析，包括需求拆细，检查与老需求是否有关联。然后是方案评审，专业和多角度地各方确认，最后风险评估。

4.1.2 应对和总体控制变更

变更流程确立

设立变更委员会，由项目经理，开发负责人，测试负责人，产品负责人，交互负责人和视觉负责人组成。系统架构灵活设计不要写死。需求优先级安排要明确定义并得到众人认可。