團隊過程管理演進之路

職能團隊依據業務領域需要劃分爲跨職能團隊，怎麼讓團隊運轉起來？怎麼組織跨團隊的事情？怎麼提升團隊的自組織能力？怎麼了解團隊的效能情況？怎麼拉通價值流上的角色？本文爲你闡述團隊管理的進化、精細化之路。

團隊是什麼樣的？

我們的團隊分爲職能團隊和跨職能團隊。

圖片

組織架構上通過職能進行組織：

• 業務團隊，包括品牌、供應鏈、營銷、生產、運營等部門

• 產品團隊，按照產品線劃分，也可能是產品線的聚合，比如 C 端、B 端

• 開發團隊，往往按照技術棧劃分，同時考慮領域的劃分，比如大前端包括前端、移動端，後端又根據領域劃分各個小組

• 測試團隊，通常是跟開發團隊分開的，隸屬質量保障部門，保持獨立性

在日常工作過程中，需要產研配合，在產品線上進行產品迭代開發。因此形成了跨職能的產線團隊，跨職能團隊由產品經理、開發、測試共同組成。

我們從哪裏開始？

過程導入

我們從職能團隊按照產品線重組了虛擬的跨職能產線團隊，那麼團隊形成後從哪裏開始呢？我們需要有一個基本的管理過程框架，讓團隊 RUN 起來，我們採用的是 Scrum 的框架。

圖片

Scrum 框架的要素總結起來叫 3-3-5-5：

3 個角色

產品經理（PO）；Scrum Master；團隊（開發 + 測試）。

3 種交付物

產品需求池；迭代需求池；版本交付。

5 個活動

PO 將需求提在產品需求池中，經過評審、設計、迭代規劃（KO），進入迭代需求池；

採用雙週迭代的形式，交付版本，迭代週期和版本週期一致，都是兩週；

迭代中的每一天都有站會，以同步狀態、發現風險、解決障礙；

版本交付後有針對交付成果的評審會；

有針對迭代過程的回顧會。

5 大價值觀

承諾；專注；開放；尊重；勇氣。

過程導入中的物理看板

在引入框架初期，我們更多使用物理看板引導團隊進行各項活動，因爲物理看板有更強的交互感、代入感、儀式感，對於過程活動習慣養成很有利。

圖片

比如利用迭代看板進行每日站會：

• 看板上每一列代表任務的狀態

• 列中的每個卡片代表一個任務，任務對應到一個人

• 行首的每個卡片代表一個需求

• 看板右邊是迭代燃盡圖，用以指示進度風險

團隊每日站會之後，我們會有一個 SOS 的站會，利用 SOS（Scrum of Scrum) 看板解決跨團隊、跨部門的風險預警、障礙解決：

• 每個卡片代表一個問題記錄

• 行和列是部門及團隊

標準化流程規範

經過一段時間的運行，就逐步形成了穩定的工作流，定義出從需求提出到上線運營的過程，在這些過程之上有一些規範。

圖片

特別是在角色間進行工作轉換的卡點上，爲了保證過程質量和效率，規範更爲重要：

• 業務提出需求給產品

• 產品和研發進行需求評審

• 產研做迭代規劃向業務運營給出版本承諾

• 開發提測需求由開發階段進入測試階段

• 開發、測試將需求交付產品進行驗收

這些卡點上的流程規範保證團隊在一定的規則下運轉，團隊有了很多共識，減少衝突、提高溝通效率和質量。

同時，我們在雙週迭代過程中也形成了一定的工作節奏：

• 週四進行版本發佈，既要關閉上個迭代，又要啓動新迭代

• 迭代啓動之前的週一，產品經理將待評審的需求列表給到研發團隊，啓動需求評審、設計

• 迭代啓動後的 2-3 天進行用例評審

• 爲保證迭代內版本按時交付，規定周 4 是最晚的提測時間

• 測試啓動後 2-3 天進行 UED 驗收

• 測試完成定時啓動產品驗收

這樣團隊對於工作節奏有了一個共識，跨團隊、跨部門也工作在相同的節奏中，對於協同效率非常有利。

至此，我們團隊運轉得應該就比較良好了，也會暴露一些問題，比較典型的跨團隊大粒度的事情怎麼組織。

怎麼組織跨團隊的大粒度事情？

組織或部門中往往有一些比較大粒度的需求，需要在一定時間內完成（有 deadline）；這些事情往往是比較重要的，比如新產品特性攻堅、雙 11 大促支撐等。因爲重要，所以需要特別重視和對待，我們稱這些事情爲專項。

我們把專項相關的人聚集在一起，形成一個虛擬的專項團隊，方便把專項的過程、活動顯示出來。

圖片

實際運作過程中，通過一定的措施，讓專項需求實際在迭代團隊中交付：

• 專項需求拆分至迭代團隊

• 專項里程碑劃分與迭代及版本週期對齊（雙週）

• 迭代站會之後設立專項每日站會進行專項相關跨團隊的溝通

• 專項定期會議（比如週會）進行溝通

通過專項虛擬團隊，我們既將專項過程好價值特別呈現，又將專項落地融入到迭代開發中，降低了管理成本。

如何提升團隊自組織能力？

技術 PM

過程導入初期，PMO 的同學到部門中引入過程框架，通過迭代活動，對團隊進行輔導，形成了穩定的過程規範和工作節奏。

伴隨團隊的逐漸成熟、團隊對於人才培養的需要、成員自身發展的需要，我們首先引入技術 PM 的角色。

技術 PM 從團隊中來，通常是研發同學擔任，主要承擔 Scrum Master 的職責，推動過程活動流暢進行，對迭代過程結果負責。在選擇的時候，通常跟職能部門 leader 共同商議，選擇有潛力的同學，作爲部門人才儲備。

技術 PM 在技術和管理方面都要有良好表現，在管理方面我們建立了技術 PM 的成長路徑、能力模型、評價反饋機制和長期培訓賦能計劃。

在團隊過程不斷成熟、發展的同時，不少同學後面順利成爲了團隊 Leader。

Owner 機制

除了技術 PM，我們還明確了幾種類型的 Owner：

領域 Owner

參與長週期、大粒度項目規劃；

價值分析、系統分析、架構設計；

對齊產品架構與技術架構。

項目 Owner

專項立項、項目團隊建立；

專項實施過程監控、協調、溝通；

項目結項評價、價值達成評價。

故事 Owner

需求評審、規劃、設計；

需求落地過程跟進；

需求價值達成評價。

這樣就形成在不同層次上事情都有人負責，分擔了管理壓力，提高管理的精細化水平和效率。在提升團隊主人翁意識的同時，提升了團隊自組織能力。

怎麼了解團隊的效能情況？

作爲部門或者團隊的 leader，經常會問這樣的問題：

• 我的團隊在幹什麼？

• 我有多少人？需要多久完成一個新需求？

• 我的團隊乾的如何？質量、效率怎麼樣？

想得到相對確切、量化的答案，我們需要數據支撐，而數據來自於團隊日常活動。

電子看板的引入

前面我們說在過程導入初期，使用物理看板，提升代入感、參與感，但過程數據除非人工記錄，就會丟失掉。

電子看板就很容易解決這個問題，我們來看看電子看板的優勢：

• 通過電子大屏的方式，我們可以模擬物理看板的儀式感、代入感

• 電子看板數據自動記錄，不會丟失

• 不受區域的限制，使得信息傳播更容易，信息更透明

• 信息切換容易，能展現更豐富的信息，比如需求列表、bug 列表、燃盡圖

• 跨團隊的需求依賴關係、跨團隊項目需求聚合跟進等，展現了更大範圍的信息

• 不受地域限制，像哈囉這樣在上海和杭州都有研發中心的公司，使用電子看板開每日站會或迭代規劃會就很方便

• 通過與其他的系統的連接，打通、獲取更多功能和信息

擴展電子看板應用

我們對電子看板進行了一些擴充的應用，Jira 是主要使用的電子看板。

圖片

利用 Jira 插件爲 Jira 本身進行了擴展

利用 BigPicture 進行項目規劃；

利用 ScriptRunner 進行數據搜索擴展；

利用 EasyBI 進行報表數據統計；

利用 WebHook 與釘釘等第三方系統連接。

與其他系統結合

與項目管理平臺結合，生成數據報表；

與質量管理平臺結合，將用例、測試過程與需求綁定；

與 CI/CD 系統連接，將代碼分支創建與需求綁定，打通價值流與 CI/CD PipeLine。

團隊視角的數據報告

有了電子看板的加持，我們就很容易回答部門 leader 的幾個問題了：

• 通過既往人力分佈，回答幹了什麼的問題

• 通過進行中人力分佈，回答正在幹什麼的問題

• 通過對需求池情況的分析，回答還有多少事情要乾的問題

• 通過迭代報告，回答在時間維度上幹得怎麼樣的問題

• 通過專項報告，回答在重要事情上幹得怎麼樣的問題

研發效能

剛纔我們聊的是從團隊、部門 leader 的角度對於團隊情況的分析、評價，這只是研發效能的一個場景視角。

研發效能整體上是爲了我們的過程能夠持續高效率、高質量交付有價值的需求。

圖片

通常通過多種類型的指標進行評價

質量；效率；能力。

可以從多種維度和場景進行評價

團隊組織層級：組織、部門、團隊各層級；

時間維度：迭代、月度等；

需求層次：專項、需求；

角色：根據角色特點呈現相關信息，比如技術 PM 對於過程的把控程度。

研發團隊是怎麼關注價值交付的？

研發過程與價值交付

我們在講效能的時候，更多時候在說效率、質量、工程能力，對於價值方面的關注往往被忽略，特別是研發團隊。

那麼我們來看看研發過程對於價值交付的關注是怎麼樣的。

需求設計階段

直接參與價值達成預估；

系統可實現性、人力成本預估，作爲成本體現在 ROI 分析中；

通過業務流程分析，映射到產品、技術架構，相互對齊；

對於系統失敗的損失進行風險預估。

研發落地階段

通過對質量、效率的關注，加速價值交付；

通過技術沉澱、技術創新加速業務孵化、築建業務壁壘；

通過大數據、算法、數據埋點等技術形式進行價值分析。

線上運營階段

數據採集、分析，評價價值達成情況；

數據協助產品 / 業務改進、決策；

保持穩定性、進行業務監控，保障業務價值持續、穩定輸出。

可以看到我們的研發活動與價值交付在每個階段都息息相關。

之前我們講 T 型人才觀，更多是對於跨技術棧能力培養，現在也包含了產品業務思維等軟實力的擴充，我們需要在團隊中樹立這樣的人才觀念。

拉通產研—目標、過程、價值

價值交付牽涉到端到端的協同，研發團隊需要與產品、業務團隊一起進行目標對齊、過程協同、價值評價。我們採用產研月會的形式，拉通雙方。

產研月會的主要內容有：

對齊目標

確定新項目的優先級和等級；

對齊階段性目標；

指導細粒度優先級；

指導迭代規劃。

同步進程

進行中項目完成狀態、風險；

階段總結項目過程及投入分佈；

跟蹤改進措施。

關注價值

量化分析項目達成情況；

分析成功或失敗的原因；

產生新的需求或改建措施；

產生產品，業務決策。

產研月會是階段性的拉通會議，可以在更長週期 OKR 目標制定拉通、指引下進行，形成自頂向下、不斷檢視、適時調整的良好循環。

我們得到了一個什麼樣的管理框架？

圖片

我們從導入基本的 Scrum 框架開始，讓團隊在穩定的過程規範以及節奏下工作，提升了團隊內部以及跨團隊的協作；
引入電子看板，使得信息更透明、數據能記錄、對過程有更客觀的評價；
通過引入技術 PM、領域 Owner、故事 Owner、項目 Owner 在各個層次上發揮作用，提升了過程效率同時，提升團隊自組織能力、主人翁意識，也豐富了團隊的人才儲備；
通過產研月會，拉通產研的目標、過程、價值，延伸了過程端到端的協作；
通過豐富的效能指標、場景應用，客觀評價過程、發現問題、持續改進過程；
在這樣的管理框架下，我們的團隊能夠持續改進和進化。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Q9gczCwf8A_W1DBaEBs30A