"拯救"Jira — 規模化團隊敏控創變之路

[#1]

作者：金魚哥

金魚哥，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 & WBS

精益求精

有了管理模式，就可以進一步豐富其內涵，進而建立管理指標體系。IT工程的管理指標有很多，根據實踐經驗我們總結兩點建議：

• 1）指標要容易蒐集，由基本元素構成，不要弄一堆沒有實際作用的字段，給IT團隊造成負擔；

• 2）指標要容易理解，容易計算，具有普適性和可執行性。

現今我們已建立了多個管理指標，而需要人工錄入的基本元素其實就3個：任務的預估工時、實際工時、到期日，但已經可以使用EazyBi製作很多有用的報表，以人力工時分配報表和人力工時成本分攤報表為例：

eazyBI - Utilization report

eazyBI - Productivity report & Project cost report

另外，在大型團隊的協同工作中，我們經常會遇到如何在全局受控情況下讓團隊更敏捷、如何識別關鍵任務、如何合理安排人力資源、如何讓團隊每個成員的任務透明化等問題，我們可以使用BigPicture和EazyBI輔助解決這些問題，並增加一個基本元素——任務的開始日期，如下圖示例：

BigPicture - Work allocation

easyBI - Personal tasks with Gantt chart

混合模型

回看我們的使命和目標，實際上我們需要的是一個混合模型即規模敏捷&精益管理

總結

成功= 自定義方法*人心工程

這是在《敏控創變：自定義成功項目管理》一書中總結的創變模型。

Jira是一個靈活的管理工具，它與其它管理工具最大的區別在於，Jira本身僅提供了通用的管理要素，我們可以根據實際的管理需求，靈活地運用Jira所提供的各種要素進行組合，把管理思想融入到工具當中，從而構建一個完整的管理模式。

從這一點我們也可以看到，在管理的運作中，工具僅是一個技術輔助，更重要的是人的思想共識，我們既要尊重團隊各角色的需求，也要保持一定的專業度和立場，才能達成協同形成合力，最終成功實現共同目標。