转载自本人运营的微信公众号“ 携程技术中心PMO”（ID：cso_pmo）
作者简介
金鱼哥，Atlassian企业用户，10年+软件开发管理和技术架构经验，曾工作于跨国银行及大型消费企业IT，对如何以工具实现规模化敏捷、跨产品团队协作及外包项目管理有丰富的落地经验。
从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使用实践中，已经尝试过多种管理方法，但都未能解决产品和项目维度的管理问题，我们通常会纠结的一个问题是，究竟Jira的“Project”应该按产品还是按项目，从“Project”的开放性角度看，应该更偏向于按产品，因为项目的一个重要特性就是有开始和结束时间，那如果以“Project”管理产品，项目维度应该如何解决呢？Epic其实有一个重要的特性 — Epic可以跨“Project”关联Story级问题类型（标准问题类型），若我们把Epic独立在一个“Project”进行管理，会产生什么意想不到的效果？
产品分开“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所提供的各种要素进行组合，把管理思想融入到工具当中，从而构建一个完整的管理模式。
从这一点我们也可以看到，在管理的运作中，工具仅是一个技术辅助，更重要的是人的思想共识，我们既要尊重团队各角色的需求，也要保持一定的专业度和立场，才能达成协同形成合力，最终成功实现共同目标。
部分图片来源于网络，版权归原作者所有。如果侵犯到您的权益，请联系我们。