一.网易互联网项目管理体系概论
1.1 互联网项目管理工具实践
环节包括：需求，设计，研发，发布和运营。要形成运营，研发和产品的闭环。
1.2 核心理念
1.2.1 核心目标
形成产品探索，产品研发和产品运营的产品闭环周期。形成闭环可以探索调适，持续改进并不断发展。流动性（快）的重要性：调适能力，应变能力和创新能力。另外，我们要提升各个环节的效能，其要素就是效率和质量，效能是产品目标下的价值，也是研发效能上的延伸，这样便可以提高产品成功的概率。
1.2.2 核心框架
三大环节：产品运营，产品探索和产品研发。关注效能：质量和效率。形成完整闭环，不断验证和改进。每个环节包括核心过程和核心指标。
核心过程由产品探索和产品研发组成。产品探索包含策划，交互，视觉，研发和验收。实体是产品功能，产品策划对产品功能的生命周期负责。产品研发包括分析，设计，评估，开发，测试和上线。实体是产品版本，产品开发对版本的整个生命周期负责。
核心指标包括效率，质量和周期三大部分。效率即投入产出比。定义为完成规模/完成周期的总人力投入。它描述产品团队生产效率情况，用于监控预警效率上的问题，但单个数据值没有意义。影响效率的常规因素包括人力浪费多（人力冗余，人员等待，沟通协作和延期），完成的工作量太少（半成品多，完成效果差和待做需求少）。
质量方面一般主要关注线上bug数，它是指一定周期内线上环境发现的bug数总和，描述产品质量情况，监控预警产品质量的问题，但单个数据值仍然没有意义。常规影响因素有两个方面，一个是Bug原因分类（环境原因，用例缺失和测试不充分），另一个是Bug引入阶段（产品策划，交互设计和研发）
周期是指产品交付周期和产品研发周期。产品交付周期是指产品功能从开始策划到验收上线的时间，描述产品响应能力和迭代速度的情况，监控预警产品响应能力和迭代速度问题。但单个数据值没有意义。常规影响因素有产品需求（颗粒度太大，优先级管理不够），产品研发成本高（耦合度高，自动化程度低）。产品研发周期是指产品版本从计划开始到实际发布的时间。
1.3 最小数据集
要理解项目管理中的最小数据集，首先得理解两个基本概念：规模和工作量。规模是指产品功能的大小，描述单位为故事点，是相对值。工作量是指完成产品功能的工作时间，其描述单位为Person Hour/Day，是绝对值。
1.3.1 基础数据定义
- 计划规模story point：周期初计划的所有故事点之和
- 实际规模story point：周期末实际的所有故事点之和
- 完成规模story point：周期末所有关闭的故事点之和
- 内部bug数：周期内发现的所有开发阶段bug数之和
- 线上bug数：周期内发现的所有线上环境bug数之和
- 计划研发周期：计划的版本开始时间和结束时间长度
- 实际研发周期：实际的版本开始时间和结束时间长度
1.3.2 建立在基础数据定义之上的最小数据集
1.3.2.1 完成率
计算方法为完成规模/实际规模的百分比。意义：指示周期内需求交付的情况。期望的趋势是完成率逐步增高。潜在负面影响：一味追求完成率，可能导致DoD制定及执行不严格，可能导致质量的降低。推荐用法：人天的规模计算，受制于人员技能等，推荐逐步向故事点过渡。
1.3.2.2 需求蔓延率
计算方法为实际规模/计划规模的百分比。意义：指示周期内需求变更的情况。期望需求蔓延率逐步接近于1。潜在负面影响：一味追求蔓延率，可能导致业务拥抱变化能力变弱。推荐用法：过程中可能发生需求变更，推荐及时记录说明，但不应影响延期率分母
1.3.2.3 延期率
计算方法为（实际研发周期-计划研发周期）/ 计划研发周期。意义：指示团队按期交付情况。期望延期率逐步趋近于0。潜在负面影响：一味追求按期交付，可能导致质量降低以及规模缩减。推荐用法：过程中可能发生计划变更，推荐及时记录说明，但不应影响延期率分母。
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）的创建则是需要策划和研发为实现产品功能而拆分相关任务，产品策划在策划或者交互，视觉之前要创建子任务：
- 策划：策划任务
- 交互：交互任务
- 视觉：视觉任务
- 研发：研发任务，包括前端，后台和测试
- 待上线：走查任务
产品策划监控和更新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 主干流程
- 外部合作立项流程：里程碑和合作意向
- 核心小组：
- 横向/基础能力（架构师，产品经理，项目经理）
- 垂直业务（模块负责人，产品经理）
- 目标调研
- 产品调研（竞品调研，场景分析）
- 技术调研：可行性分析
- 环境/资源分析：可行性/实施条件
- 目标确认
- 交付标准
- 完成时间
- 目标分析分解
- 产品概要：产品经理负责，产品框架，功能/非功能需求，发布策略
- 技术概要：架构师/模块负责人负责，架构概要设计，技术关键路径，技术风险
- 环境/资源需求：SRE负责
- 项目计划：项目经理负责，需求拆分（纵/横），时间节点，交付物/标准 & 负责人
- 研发：信息同步，交付节点检查，风险管理
- 交付验收：内测/灰测流程
- 运营/反馈：线上运维规范，Ticket流程，故障处理流程
3.2.3.2 产品研发流程
- 需求评审
- 设计评审
- 版本计划
- 版本研发
- 版本上线
- 版本走查
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 问题类型关系
- Epic
- Feature：产品，运营
- Story：开发
- Task：职能角色
- Bug
- Ticket：技术支持
- Advise：任何人
- Incident：技术支持
3.2.4.2 需求管理过程
3.2.4.3 Story生命周期
3.2.4.4 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 应对和总体控制变更
设立变更委员会，由项目经理，开发负责人，测试负责人，产品负责人，交互负责人和视觉负责人组成。系统架构灵活设计不要写死。需求优先级安排要明确定义并得到众人认可。
