前言
我的项目是公司和组织的战略目标落地的一种十分重要的组织形式，项目管理的设计会对产品的生产和过程产出产生重要的影响。
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）我的项目
这是用于产研迭代治理的我的项目，所有迭代相干的需要、工作都是在该我的项目下进行解决。
在该我的项目下建设了如下几种事务类型用于治理迭代中的工作合成构造：
- 我的项目级别
Epic：通常是规模较大或者粒度较粗的需要，它由一系列用户故事或者其它相干工作组成，一个我的项目依据交付里程碑能够拆分为多个 Epic。 - 工作级别
Feature：梳理完需要细节被产品承受的新的需要。因为客户提出的需要内容和规模大小差异很大，这部分需要个别不会间接进入开发，大部分时候会转移成 Epic 或者由产品经理拆解成多个 User Story 安顿进迭代；
- User Story：用户故事，这种类型次要是客户间接感知到价值的功能性需要；
- Tech Improvement：技术改良类事务，该类型次要是客户不能间接感知起价值的非功能性需要，或技术债权；
- Task：在迭代中除了用户故事和技术改良之外还有一些事务尽管并不间接产生价值但然须要执行并进行治理，比方：技术方案设计、测试方案设计、环境搭建等都会归于这类事务。
- 子工作级别
- Sub-Task：用户故事、技术改良和 Task 能够进一步拆解成前端、服务端和数据端开发人员的开发工作，不便开发人员跟进工作和对齐停顿；
- Sub-Bug：开发过程中发现的 bug。
- 其它
- 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 增长平台产研部门项目管理的一些设计思路和相干的实际，整体的设计和流程还不是很欠缺，有大调整和改善的空间。整顿这篇文章的时候其实我的情绪还是十分忐忑的，相比大厂成熟的项目管理流程和设计，其实有班门弄斧之嫌。但就像前文所说，项目管理的设计其实是在特定环境下，针对特定指标所做的不同抉择，分享进去承受大家的斧正和批评，能力取众家之长，补自家之短。