最佳实践 | "拯救"Jira — 规模化团队敏控创变之路

作者介绍：

金鱼哥，Atlassian 企业用户，10 年+软件开发管理和技术架构经验，曾工作于跨国银行及大型消费企业 IT，对如何以工具实现规模化敏捷、跨产品团队协作及外包项目管理有丰富的落地经验。

金鱼哥在本文中和我们分享了他在接手管理公司的 Jira 后，通过近一年半的努力，如何将之前“历史遗留问题众多”、被团队吐槽的工具，成功转变为企业关键系统，成为大家都离不开的平台，同时赢得了同事和领导高度认可的过程。

在开始本文之前，我们先来了解一个概念：什么是敏控创变？“敏控创变”是王二乐等项目管理大师在《敏控创变：自定义成功项目管理》一书中提出的基于组织情境的敏捷受控项目管理方法。

从 2017 年中开始，经过了一年半时间的努力，我们基于 Jira 完成了 IT 团队（500+ 人员规模）从粗放型管理到精细化管理转变，建立了软件工程协同管理体系和指标体系，Jira 也成为我们公司软件工程管理的核心工具，成功地实践了“敏控创变”的管理方法。然而回想整个转变的过程，有着很多可以与大家分享的故事。

接到重任：一个被“吐槽”的工具

两年前，我们公司提出了“优化结构，效益导向”的战略目标，目标具体落实到 IT 部门，则拆解为两部分要求：一是加强 IT 工作协同，提升 IT 工程效率；二是提高 IT 管理成熟度，建立管理指标及 IT 项目的成本核算与分摊方法。

这是一个复杂的课题且必须要有合适的工具支持才能完成，而我们当时最直接的选择就是 Jira 了，原因是公司 IT 部门已经购买了 Jira 和一系列插件，并已在 IT 内使用了近两年的时间。似乎一切都顺理成章，基于 Jira 工具，实现 IT 管理要求。

然而现实并没有想象中顺利，恰恰相反，由于过往几年中 Jira 的使用缺乏专业指导和管理，它早已成为各 IT 团队“吐槽”的焦点。在一次管理工具意见收集的会议中，公司 IT 部门中的核心团队反馈了 Jira 存在的各方面问题，并希望我们能尽快更换管理工具，以便完成公司战略目标。

“是否要废弃 Jira”？这是一个非常困难的选择：若废弃，则意味着此前在 Jira 及相关工具上的投入将白费，需要寻找新的管理工具，除了要考虑新工具的适用性，还需要考虑工具的稳定性、扩展性，并要做好数据迁移；若要继续使用 Jira，则要证明其能够满足我们的使用场景，扭转大家在前期使用中对 Jira 的不满情绪。然而无论是哪个选择，都要确保 IT 团队能达成工具使用的共识，才能建立 IT 协同管理体系，最终达成目标。

寻找问题的根源

“有果必有因”，要解决这个难题还必须回到问题本身：“究竟我们的管理需求是什么，为何 Jira 不能满足使用场景”？为此，我们以核心 IT 团队为切入口，对团队中各角色人员展开调研，在综合大家的反馈意见后，我们得出一个重要的结论：产品化管理模式，并绘制了以下产品化管理示意图：

我们首先来看左边的“产品”部分，在现今的技术架构体系中，一个综合性平台通常划分为前端和后端两大部分。前端主要分为移动端和 PC 端，移动端主要由 iOS、Android、微信及 Gateway 等构成，PC 端按 SOA 结构，会按不同的功能服务划分子系统或模块，例如常见的 CMS 子系统、产品模块、订单模块等；后端则主要是中台和后台，基于微服务化设计，这部分一般会达到 20+ 个服务。若从产品的角度看，上图中“产品（子系统/模块）”的一列，其实都可作为一个独立的产品，有着各自跟随业务需求而不断演变发展的生命周期。

再看右边的“项目”部分，IT 部门在接到业务部门提出需求后，会创建对应的 IT 项目，并拆解为产品需求，由负责该产品的开发/测试人员作具体实现，例如一个“双 11 的促销”项目，其实现不仅包括移动 APP、微信、PC 模块的前端需求，也要以产品、订单、支付等中后台服务的修改作支持。需要注意的是，同一时间在进行的项目不会只有一个，每一次的整体迭代上线，一般都会包含多个项目需求。

从上图我们可以了解，我们的项目总体有两个管理维度，一个是产品视角的 PBS（Product Breakdown Structure），另一个是项目视角的 WBS（Work Breakdown Structure），而我们的最大痛点就在于这两个维度的管理问题：产品负责人关注产品每次发布所包含的内容；产品团队希望按各自习惯的敏捷方式运作；需求负责人关注所负责项目的进度和花费成本；项目负责人关注每次整体上线的时间及包含的项目；开发人员关注的是分配给自己的任务和时间要求；开发总负责人关注如何把任务管理与具体开发/测试实施相结合，实现DevOps，提升 IT 工程效率。

我们知道，Jira 是从缺陷管理开始逐步发展的，可以说 Jira 的核心是“Issue+工作流”，并未从产品管理的角度考虑。而 Jira 中对“Project”的管理，从字面上理解似乎更偏向于项目维度，那是否意味着使用 Jira 产品就无法同时解决产品和项目两个维度的管理问题呢？

柳暗花明又一村

其实我们的 IT 团队在过往两年的 Jira 使用实践中，已经尝试过多种管理方法，但都未能解决产品和项目维度的管理问题，我们希望寻找到更有经验的专业顾问来帮我们解决这个问题。在与国内各个 Atlassian 合作伙伴沟通后，最终选定了 Atlassian 白金级顾问咨询公司——安迈无限（Unlimax），帮我们设计解决方案。通过安迈无限的王宏老师的专业指导，帮我们迅速打破僵局，从此打开了一片广阔的天地，而关键的一步棋就是 Epic 的特性。

我们通常会纠结的一个问题是，究竟 Jira 的“Project”应该按产品还是按项目，从“Project”的开放性角度看，应该更偏向于按产品，因为项目的一个重要特性就是有开始和结束时间，那如果以“Project”管理产品，项目维度应该如何解决呢？Epic 其实有一个重要的特性 — Epic 可以跨“Project”关联 Story 级问题类型（标准问题类型），若我们把 Epic 独立在一个“Project”进行管理，会产生什么意想不到的效果？

安迈无限的王宏老师帮我们设计的 Jira 管理模式如下图所示：

产品分开“Project”管理，且仅管理“Story - 子任务”两级，产品团队可根据各自的管理习惯采用敏捷板、看板等工具，与其他产品组互不影响，还可充分使用“Project”中的其他属性，例如使用“Project”中的“版本”管理产品版本，使用“模块”细化产品模块，并可独立设置“权限”，满足了产品团队的管理需要。

在项目的“Project”中管理“Epic”级，对应项目级需求，其实通常我们所谓的项目，也是一组需求集合，与 Epic 原本的定义是匹配的，细分需求和任务拆解到各产品“Project”中，完成项目和产品间的关联，以该“Project”的“版本”管理整体的“上线版本”，满足了需求负责人和项目管理者的成本计算和项目排期。更重要的一点，Epic 作为最小上线单位，可以与工程实施的 DevOps 工具对接，完成任务管理和工程实施链路。

更上一层楼

完成 Jira 产品化管理模式的解决方案后，核心的问题解决了，但“Epic-Story-子任务”的三层级结构并未解决以下问题：

1）Epic 作为最小上线单位，要完成一个业务需求，必定涉及多个 Epic，例如“双 11 促销”，可以拆解为 11.1 上线的“双 11 第一波”、11.5 的“双 11 第二波”等多个阶段，应该如何表示这些 Epic 的关联性？

2）Epic 已是 IT 部门对业务需求的拆解，业务部门更关注的是各业务需求的实施进度以及某业务需求各阶段实现的内容；

3）一个业务需求通常会涉及多个综合平台的多个产品线，例如“双 11 促销”，除了面向终端用户的电商平台，还需要 ERP 平台的生产、物流，SAP 平台的财务等多个跨平台跨产品线共同完成；

4）在 IT 实施中，包含 ODC 和 SOW 两种模式，任务拆解的方式可以满足 ODC 模式的成本计算，而 SOW 是按整体和最终结果计算，若业务需求由两种模式混合完成，应该如何计算业务需求最终的成本？

所谓“站得更高，看得更远”，要解决这些问题我们只需要增加一个层级，一个业务部和高层管理更为关注的层级，这个层级直接与公司战略目标和成本分摊挂钩，而“业务需求-Epic/SOW”的拆解关系，正是业务视角的 OBS（Object Breakdown Structure）。至此，我们整个 IT 协同管理模式也设计完成了，最终“业务需求-Epic-Story-子任务”的四层级结构IT协同管理模式示意图如下：

使用 Structure 插件，可清晰地看到需求和任务间的拆解关系，示例如下：

.Structure-OBS 示例图：

.Structure-WBS 示例图

精益求精

有了管理模式，就可以进一步丰富其内涵，进而建立管理指标体系。IT 工程的管理指标有很多，根据实践经验我们总结两点建议：

1）指标要容易搜集，由基本元素构成，不要弄一堆没有实际作用的字段，给IT团队造成负担；

2）指标要容易理解，容易计算，具有普适性和可执行性。

现今我们已建立了多个管理指标，而需要人工录入的基本元素其实就 3 个：任务的预估工时、实际工时、到期日，但已经可以使用 EazyBi 制作很多有用的报表，以人力工时分配报表和人力工时成本分摊报表为例：

.示例 EazyBi 报表-人力工时分配报表

.示例 EazyBi 报表-人力工时成本分摊报表

另外，在大型团队的协同工作中，我们经常会遇到如何在全局受控情况下让团队更敏捷、如何识别关键任务、如何合理安排人力资源、如何让团队每个成员的任务透明化等问题，我们可以使用 BigPicture 和 EazyBI 辅助解决这些问题，并增加一个基本元素——任务的开始日期，如下图示例：

.BigPicture-资源工时

.EazyBI-个人任务甘特图

总结：成功 = 自定义方法*人心工程

这是在《敏控创变：自定义成功项目管理》一书中总结的创变模型。

Jira是一个灵活的管理工具，它与其它管理工具最大的区别在于，Jira 本身仅提供了通用的管理要素，我们可以根据实际的管理需求，灵活地运用 Jira 所提供的各种要素进行组合，把管理思想融入到工具当中，从而构建一个完整的管理模式。

从这一点我们也可以看到，在管理的运作中，工具仅是一个技术辅助，更重要的是人的思想共识，我们既要尊重团队各角色的需求，也要保持一定的专业度和立场，才能达成协同形成合力，最终成功实现共同目标。