GrowingIO 增长平台产研项目管理实践

前言

项目是公司和组织的战略目标落地的一种非常重要的组织方式，项目管理的设计会对产品的生产和过程产出产生重要的影响。

Jira 是一款功能强大、可灵活配置的项目管理工具，能够满足不同规模公司的项目管理需求。

GrowingIO 从 2018 年引入 Jira Cloud 产品及服务，主要用于产研团队的项目管理，本文尝试从工作、人员、时间这几个方面介绍 GrowingIO 增长平台产研部门在项目管理设计上的选择，以及使用 Jira 这款项目管理工具进行的一些实践。

项目管理

项目的分类

GrowingIO 增长平台产研部门以季度为周期进行项目规划和组织，公司的战略目标以 OKR 的方式拆解到部门，这些 OKR 会进一步拆解为不同类型的项目，主要有以下三种类型：

● 产研核心功能交付项目

这类项目由产品主导，产品经理根据公司的产品路线规划，选择从客户侧梳理出来的各种需求，以这类项目进行立项，根据优先级安排在每个季度的迭代中完成交付。

● 产研团队重点项目

这类项目主要由开发主导，开发会梳理出每个季度需要完成的重大技术改进或者需要还清的技术债务，以这类项目进行立项，安排进季度的迭代。

● 绿色通道项目

作为一家企业服务公司（2B），经常遇到客户在新签或续约前提出一些对签单可能产生重要影响需求，这些需求不一定完全符合目前的产品路线规划，但实现的复杂度可能并不高，为了提高签单的竞争力，所以提供了这种类型的项目。需要业务团队对项目的预期收益进行评估，并对项目交付后预期收益的达成负责。产研对绿色通道项目的工作量进行评估，实现客户项目交付。

之所以会采用上文介绍的项目分类方式，其实是在特定环境、基于特定目标的项目管理设计，而这样的设计主要涉及工作、人员和时间三个方面的选择。

工作方面

从部门的季度规划来看，工作是以 OKR 拆解出来的项目为基本单位，每个季度会有多个项目存在，每个项目包含批量需求。出于 OKR 管理和进展跟踪的需要，这些项目会进一步分解成多个交付里程碑以及对应的任务。在 Jira 中，项目会拆解为一个或者多个 Epic，每个 Epic 会进一步拆解为不同类型的任务以及子任务，具体的拆解方式请见：需求的组织与管理章节。

在真正落地项目的执行环节，工作是以需求为基本单位安排进迭代中实现的。项目的工作分解结构（WBS）以需求进行拆解和组织实现了工作以项目为单位和工作以需求为单位两种方式的结合。这为部门 OKR 的实现和客户需求的实现这两个目标的平衡提供了额外的灵活性。具体的迭代活动设计请见：迭代管理章节。

人员方面

迭代中交付的具体需求往往集中于某个特定的需求领域或者业务领域，所以人员的组织以跨职能的特性团队为基本单位而不是以项目团队为基本单位，团队中包括产品经理、设计师、前端、服务端、数据端开发和测试人员，可以完成端到端的需求交付。特性团队在较长时间内保持稳定，从而能够培养人员对于需求领域或业务领域的了解和熟练程度。同时开发和测试人员也可以申请选择自己感兴趣的特性团队，从而扩展自己的业务领域。

时间方面

既然选择了项目工作以迭代的方式执行，那么时间上自然以迭代为基本单位。所有特性团队的迭代保持同步，每个迭代以迭代计划为正式开始、以迭代回顾结束。项目的时间规划和迭代周期对齐，每个迭代产生基于项目产出目标的可交付的产品增量。Jira 的 Scrum Kanban 提供了迭代管理的能力，每个特性团队的迭代任务都通过 Scrum Kanban 进行规划、执行和监控。

为什么这么选择？

通过以上几个方面的设计，我们在最大限度保障完成部门 OKR 的基础上为客户特殊的定制化需求提供了必要的灵活性。固定的迭代周期保障了固定时间都有可以交付的产出，也为项目计划的执行和监控提供了有效的参考依据。特性团队有助于提升人员在特定业务领域的熟练度，从而提升开发效率，也能增强团队的自组织性进行持续改进。

需求管理

我们在 Jira 上针对需求来源的不同的场景区分了不同的项目来进行管理，在每个项目下又根据不同的需求类型进一步细分出了事务类型，如下图所示。这样的事务类型划分看似比较繁琐，但我们觉得非常有必要，这可以辅助团队成员直观了解任务目标，对规范迭代执行过程也很有帮助，同时在迭代复盘中迭代团队可以通过收集到的迭代数据来分析团队迭代产出价值的分布，从而更好的帮助团队持续改进。

● Feature Request（FR）项目

用于收集和汇总客户提出的所有需求，作为产品需求的需求池。产品经理可以在改项目下对客户需求进行分类梳理，并管理需求的优先级。

在该项目下最初只建立了 Feature 这一种事务类型，之后又加入了 Epic 这种事物类型，方便产品进行进行归类管理以及后续迭代需求的管理。

● Infrastucture（INFRA）项目

用于收集和汇总客户提出的运维需求，包括客户系统升级和 POC 等需求、生产环境故障。同时运维相关的任务如：部署升级方案、 自动化脚本的开发、定期巡检等也都在这个项目下进行管理。

在该项目下建立了如下几种事务类型用于区分不同的需求：

• Task：运维相关的日常任务；
• 升级申请：用于处理客户的部署升级需求；
• POC 申请：用于处理客户的 POC 需求；
• 生产系统故障：用于处理客户生产环境故障。这里需要说明一下在私有化部署的产品中，生产环境故障不一定是产品 bug 造成的，环境和配置的变动、错误的运维操作、甚至认证文件的过期都有可能造成生产环境故障，在我们的实践中觉得这部分有必要和产品 bug 进行区分。

● Product Iteration（PI）项目

这是用于产研迭代管理的项目，所有迭代相关的需求、任务都是在该项目下进行处理。

在该项目下建立了如下几种事务类型用于管理迭代中的工作分解结构：

1. 项目级别

• Epic：通常是规模较大或者粒度较粗的需求，它由一系列用户故事或者其它相关任务组成，一个项目根据交付里程碑可以拆分为多个 Epic。

2. 任务级别

• Feature：梳理完需求细节被产品接受的新的需求。由于客户提出的需求内容和规模大小差别很大，这部分需求一般不会直接进入开发，大部分时候会转移成 Epic 或者由产品经理拆解成多个 User Story 安排进迭代；
• User Story：用户故事，这种类型主要是客户直接感知到价值的功能性需求；
• Tech Improvement：技术改进类事务，该类型主要是客户不能直接感知起价值的非功能性需求，或技术债务；
• Task：在迭代中除了用户故事和技术改进之外还有一些事务虽然并不直接产生价值但然需要执行并进行管理，比如：技术方案设计、测试方案设计、环境搭建等都会归于这类事务。
• 子任务级别
• Sub-Task：用户故事、技术改进和 Task 可以进一步拆解成前端、服务端和数据端开发人员的开发任务，方便开发人员跟进任务和对齐进展；
• Sub-Bug：开发过程中发现的 bug。

1. 其它

• Production Issue：生产环境中发现的产品 Bug；
• Engneering Service：需要开发同学支持完成的一些客户任务，比如：客户系统对接的联调、复杂的数据导出或者校验等。

下图描述了产研迭代项目下主要事务的分类逻辑：

迭代管理

出于项目管理的需要，项目的规划和技术实现的设计工作是穿插在迭代中进行的，参考 Scrum 迭代活动的内容我们根据自己的情况对其进行了扩展，并将迭代划分成了迭代前准备、迭代中、迭代收尾三个阶段，所有的迭代活动都设置时间窗口，方便迭代团队控制节奏。但当前迭代前准备和上一个迭代中会有重叠，这使得我们的迭代工作非常紧凑。

迭代前准备

● PRD Review

由于工作的组织仍然保留有以项目为单位的方式，所以我们需求定义阶段的仍然是以产品需求文档（PRD）作为产出的，有 PRD 则肯定会存在对应的评审环节。PRD 的评审一般要求提前一个 sprint 完成，为技术方案设计腾出时间。

● Tech Design & Review

技术方案设计是建立后续开发指导方案的重要环节，迭代能否顺利启动启动开发取决于相应的技术方案是否完成并通过评审。在迭代前的准备工作中技术方案设计和迭代梳理活动是在一个时间窗口内循序渐进交替进行的，这样有利于迭代团队充分了解迭代需求并给出适合的技术设计。

● Sprint Grooming

迭代梳理活动和技术设计一样也是知道后续开发的重要环节，在梳理活动中产品经理明确迭代任务的优先级，并和团队就各项任务的接受条件（AC）达成共识，确定迭代验收标准。

迭代中

● Sprint Planning

迭代团队在技术方案设计和迭代梳理活动的基础上对迭代任务参考工作量、复杂程度、不确定性等维度评估，最终明确迭代的交付内容和交付目标。使用 Jira 的待办事项列表（Backlog）功能可以管理待办事项的优先级和迭代规划。由于 PI 项目的待办事项会比较多，我们设置了一个用于缓冲的迭代，作为迭代待办事项列表。这个迭代不会启动，团队可以在 Grooming 后将任务放入这个迭代中，以方便进行迭代规划。

● Sprint Implementation

迭代执行过程基本上是按部就班进行，这个过程团队会使用 Jira Scrum Kanban 和站会的方式对进度进行对齐和跟踪。在 Kanban 中迭代团队成员可以看到自己负责的迭代任务以及状态，结合 Jira 预置的 Duedate 字段、事务状态和卡片颜色设置可以高亮显示任务是否延迟。

同时结合 Jira 提供的开放接口，我们自己也会开发一些 dashboard 用于迭代过程的可视化和监控。

● Code Freeze

迭代结束前的代码冻结，冻结代码后只允许提交 sub bug 修复代码。

● UAT & Sprint Review

代码冻结后 QA 组织在 UAT 环境进行全量回归，UI 和 API 自动化测试。产品和设计组织迭代团队完成验收。

● Release

UAT 和验收完成后版本发布至内部 demo 环境，供全公司同学试用，获取反馈。

迭代收尾

● Sprint Retrospective

早期迭代复盘时我们按照标准的 Scrum 迭代复盘过程进行，但是效果并不好。总结下来发现缺少了 复盘规划和迭代过程信息的采集，使复盘缺少抓手。经过改进我们在每个迭代结束会产出迭代报告，报告中利用 Jira 的统计功能记录迭代过程的相关数据：如 sub bug 数量、迭代任务的累积流图、控制图以及上文中提到的交付燃尽图。通过在复盘中分析这些内容，迭代团队能能更好的获得洞察，形成改进措施。

总结

本文介绍了 GrowingIO 增长平台产研部门项目管理的一些设计思路和相关的实践，整体的设计和流程还不是很完善，有大调整和改善的空间。整理这篇文章的时候其实我的心情还是非常忐忑的，相比大厂成熟的项目管理流程和设计，其实有班门弄斧之嫌。但就像前文所说，项目管理的设计其实是在特定环境下，针对特定目标所做的不同选择，分享出来接受大家的指正和批评，才能取众家之长，补自家之短。