【客户案例】家乐福使用 Jira 搭建统一管理平台

背景介绍

苏宁家乐福（以下简称家乐福）作为传统零售业外企，从前端到后端、从基础架构到应用，服务于各个业务部门的系统大大小小超过50多个，涉及到前端销售链路、供应链链路到后端的财务系统、人事管理系统等。和大多数传统企业一样，我们一般是通过购买、集成各种IT供应商的系统为主，自己负责研发和运维的系统偏少。IT其中一大部门就是负责和业务部门对接的各应用经理，承接业务需求，再把需求给到供应商进行开发和测试，最后几方一起配合进行 UAT 和最终上线的过程。在这个过程中应用经理同时也扮演了甲方项目经理的角色。

在我们没有使用 Jira 之前，PMO 收集和总结了一些当时的情况问题：

问题一、 业务需求管理没有纳入统一平台，各模块应用经理各自联络业务负责人，沟通和过程不够透明。管理层对于还有多少需求未处理、是否有相互影响，甚至重复的需求未知。

问题二、 在承接需求后，CR的实施流程不统一、缺少清晰的里程碑节点定义和标准化的定义。导致交付的CR存在质量问题，一些关键项目过程文档或输出物缺失。

问题三、 在CR上线的过程中缺少变更管理，经常发生由于上线了一个系统新功能导致其他系统受到影响而在上线前并没有识别出来的问题。

制定方案

作为 IT 的 PMO，在经过一段时间调查访谈、分析数据和实际接触之后，针对问题决定采取以下几个措施：

措施一：建立统一的需求管理和项目管理的平台，所有业务部门都通过同一个入口提交新业务需求。应用经理也在同一个平台进行对应需求的项目和CR的管理。

措施二：对于项目的里程碑 （包括CR）进行标准化定义，设定符合家乐福情况的自定义流程和审批节点

措施三：对于应用上线引入变更管理的概念，每周通过变更管理委员会（CAB）统一进行变更的执行讨论与审批

在经过市场上各种项目管理工具的对比之后，我们最终选择了 Jira Software 作为我们的统一管理平台，主要理由为：

1. 强大的工作流引擎 - 可以简单方便的定制化自己的工作流，同时在工作流比较复杂的情况下通过一定的开发和设定也能够轻松实现

2. 丰富的定制化 Issue Type - 根据不同的业务需求我们可以自己定制自己想要的 issue 类型和属性

3. 强大的 Marketplace - 能够让我们直接使用很多成熟的插件来帮助我们快速实现，节省了很多定制开发的时间

详细步骤

那么具体如何通过 Jira 来解决家乐福IT部门当时面临的几个问题呢？我们下面详细来说一下。

一、 定义Issue Type

根据我们的实际诉求，我们在Jira中定义了三个新的Issue类型分别是：

BR - Business Request：用于给业务用户通过service desk的统一portal进行业务需求的提报。

CR - Change Request：应用经理在承接了BR之后由IT方发起的根据自己审批工作流定制的CR流程。

RFC - Request for change：变更管理的主要issue类型，CR上线时需要创建单独的RFC来进行变更的审批。

三个 issue type 都可以是多对多的关系，用 link 进行关联。在设计之初，我们是把 RFC 放到了 CR 的最后一个环节的，但在后来发现变更的视角和 CR 的视角本来就不同。比如一个业务需求，在经过分析和评估后是需要对于三个系统都进行修改才能实现的，那么我们会分别创建三个 RFC 来跟踪各自的进度状态。而 CR 和 RFC 也是多对多的关系，很多情况下一个 CR 不会在一次发布就解决，而是分多次上线的，那么这样的情况下用 CR 一个 issue 管理到底的方式就不适用了。

反过来一个 RFC 有的时候往往是好几个系统一起上线为了同一个业务目的产生的，我们只需要将这次上线的一个 RFC 和不同的 CR 关联起来就好了，不需要分别创建和管理三个 RFC，也不便于识别变更中影响系统的范围。同样，有可能多个业务需求的 BR 最终也落实到一个 CR 来实现。在解耦了他们三个之间的关系后，才成为了一个各自带有各自属性和生命周期，互相之间又有 link 关系的三个 issue type。

二、流程的设计

BR - 我们希望所有的业务人员都可以提交新的业务需求，而不是之前那样只有知道找具体IT部门的某个人才能收到需求的情况。

我们使用了 Atlassian 的 Jira Service Desk 设定了一个专门接受新 BR 的项目。借助 Jira Service Desk 的快速定义表单和字段信息的功能，很快能够发布一个新的服务目录内容用于给客户提交新的业务需求，同时为后期我们做统一的 IT service portal 奠定了良好的基础。

流程上需要业务提交人和他的 N+1 审批人通过，然后这个 BR 就会通过业务选择的不同业务模块（Jira 中的 Component 功能）自动扭转到对应相关的应用经理手中。在应用经理进行初步的业务需求分析和评估后，会提交给 IT board 进行统一的业务需求审批。横向增加需求的评估考虑，让其他模块的应用经理也参与到需求评估的审批会议当中，充分考虑这个需求在不同系统中实现的情况和最优方案。

BR 提交和批复流程图

CR - 我们希望通过统一的标准化流程让管理者对于这些承接了的需求转化成IT内部的工作内容后的状态一目了然。对于必要的项目过程节点设置审批，保证项目的整体质量。并且为CR初期专门设定了费用批复的节点，由专门负责合同和采购的人员来统一接受和管理所有费用审批，从而释放了应用经理的精力，让他们更专注在需求和项目上。

RFC流程图

RFC - 我们通过线下的 CABmeeting 的机制保证每周一次进行变更的审批，通过大量定制的表单帮助变更实施者在提交申请的过程中充分对于这次发布/变更进行了准备。通过固定的带有仪式感的批复，让大家对于变更更加认真和重视。

三、 实施中的一些 Tips

• 由于 Jira 的工作流引擎、自定义字段的创建非常的方便快捷，基本上在简单的设计流程之后我们就可以发布上线进行测试了。不需要经过很多次的求证和讨论之后再去实施，在一点点的推行运作过程中再去做不断的优化升级。当然，这是需要建立在试运行在一个较小的范围内的，如果每天的发布一些流程变动给到所有人，那么他们也对于这个流程的制定产生抵触从而反感。

• 培养业务用户和 IT 用户简单上手的良好习惯，比如 BR 的创建就是一个 self-explanatory 的表单创建过程。如果很多业务部门的人经常过来问说这个 BR 怎么创建，那么可能这个 BR 的表单和流程已经设计的太复杂了。
  

• 给用户做 filter 和 dashboard 的培训，新的系统是复杂的、使用者一下子要接受很多内容。在开始根据不同的角色预先制作一些 dashboard 和 filter，可以帮助他们瞬间爱上 Jira 强大的报表功能。
  

• 多去聆听用户的反馈，设计者和使用者往往有理解上的代沟，经常去听取使用 Jira 后的回馈能够更快速的优化体验。Jira 的使用体验对于实行一个新的平台来说是很重要的，恰好 Jira 的高性能和强大的 filter 功能能够很好的帮助用户自主的把 Jira 按照自己的理解用起来。
  

• 善用 Atlassian 的生态系统：Atlassian Marketplace 里有几千款功能各异的插件，可以帮助团队节省开发时间 - 花很少的钱，甚至不花钱就能获得很多功能非常棒的 plugin！

• 最后一个也是最重要的，在实施新的系统和新流程时需要得到上层领导的大力支持，靠一己之力是很难将一个陌生的系统和流程推行给整个部门的。

后记

在实施了这三个流程之后，我们很轻松的就接入了新的 service request 类型，比如基础架构的服务器申请，云端的防火墙审批。RFC 马上也进行泛用性的升级让他不仅支持应用类型的变更，同时能够支持基础架构的变更等等。而对于 Jira software 真正的核心 - Scrum敏捷类型的开发项目，我们也在技术团队组建之后很快的实施建立起来。

甚至在后来 Jira 被业务部门接受后而开始从 IT Service Request 向 Business Service Request 延申了。

也许在家乐福，我们使用 Jira 的方式比较特别，但这就是家乐福的特色。我们用 Jira 建立了属于有自己特色的IT项目管理、需求管理、服务管理的统一平台。

Jira 的功能强大而灵活，我相信每个企业、每个团队都可以根据自己的特色和需求发挥 Jira 最大的功能和特色，从而满足自己的业务需求，提高团队的整体协同效率！