PMO 是干什么的？不就是個拉會的嘛？

這種根深蒂固的誤解，就像，你說你是學計算機的，別人以為你是修電腦的。如果你是這么想的，那這篇文章應該會重新認識項目管理，以及PMO這個角色。

我們之所以寫這篇文章，一是覺得國外傳到中國來的PMO守則、指導方針等，存在水土不服的問題，我們現(xiàn)在遇到的問題甚至可能都比國外還要復雜。二是，我們在得物飛速發(fā)展的過程中結(jié)合理論與實戰(zhàn)積累了一些經(jīng)驗，希望可以跟相關(guān)從業(yè)者探討和交流。

文章從得物技術(shù)團隊的發(fā)展不同階段遇到的挑戰(zhàn)出發(fā)，PMO在不同階段的工作方向重心，實踐沉淀，能力建設演進等。

一、技術(shù)團隊的發(fā)展

近幾年來，得物的業(yè)務百倍增長，得物技術(shù)團隊作為業(yè)務快速擴張的重要支撐，團隊規(guī)模在2年多時間內(nèi)也發(fā)生了指數(shù)級的變化，以20倍+的速度快速增長，在此過程中，得物項目管理團隊-PMO和技術(shù)er協(xié)同摸索、實踐總結(jié)出了一套得物技術(shù)千人量級的規(guī)?；艚輰嵺`。

圖片

與單個敏捷團隊通常選擇Scrum或者Scrumban的模式相比，得物PMO認為需要在此基礎(chǔ)上選擇適合自己的大規(guī)模敏捷框架，同時需要根據(jù)團隊發(fā)展的不同階段及時調(diào)整框架，而不能照搬業(yè)界熟知的框架，需要進行自創(chuàng)和優(yōu)化。

本文將從得物技術(shù)部的敏捷迭代在落地過程中的實踐出發(fā)，對比敏捷行業(yè)敏捷實踐的共性及差異性，以大規(guī)模團隊的實踐做為切入點，以點帶面帶大家了解千人規(guī)模的敏捷迭代在得物的落地實踐。

二、千人敏捷迭代的挑戰(zhàn)與解題思路

電商業(yè)務本身屬于長流程業(yè)務，從產(chǎn)品上架到用戶下單再到履約，涉及到商品管理、訂單處理、支付結(jié)算、物流配送等多個方面。長流程的業(yè)務存在較重的上下游依賴情況，業(yè)務模式的復雜度疊加組織快速發(fā)展：新人快速進場、多地協(xié)同，端到端交付的協(xié)作復雜度呈指數(shù)級上升。

先來看看這個過程中遇到哪些挑戰(zhàn)：

• 團隊規(guī)模快速增長，敏捷團隊如何劃分才能夠更好的保障業(yè)務需求的可持續(xù)交付？
• 業(yè)務和產(chǎn)品既要還要，心里對需求吞吐沒有預期？
• 需求、項目太多研發(fā)和測試的資源缺口如何提前識別并解決？
• 跨業(yè)務線的需求優(yōu)先級總會出現(xiàn)不一致，需如何保障團隊之間的協(xié)作？
• 跨團隊的需求交付時間不一致？
• 如何確保大規(guī)模團隊的研發(fā)效率？

這些問題在不同行業(yè)、不同團隊規(guī)模、不同團隊成熟段階段都可能會遇到，大家都會有不同的切入點和解決方式，我們把上面的問題，歸因到兩類：

• 團隊（資源）的劃分及使用
• 業(yè)產(chǎn)研協(xié)同模式

首先來看團隊劃分，團隊的組織形式和工作方式的選擇始終要與公司的發(fā)展階段相匹配，得物技術(shù)部從早期的100+人規(guī)模到現(xiàn)在的千人規(guī)模，過程中也伴隨著業(yè)產(chǎn)研團隊協(xié)作方式的變化，資源要根據(jù)公司的發(fā)展階段，以業(yè)務順利開展為第一調(diào)整目標快速做到支撐。

團隊組織方式的變化，先看下面的圖例：

圖片

可以看到在調(diào)整之前，團隊交付的組織形式是職能型的架構(gòu)組織，資源按照共享的方式在使用，因為各業(yè)務都有自己的優(yōu)先級，資源使用每次都要經(jīng)過多輪溝通后才能達成一致，資源使用的溝通成本很高；在這個痛點下，與業(yè)務及產(chǎn)品溝通后，將技術(shù)部團隊交付組織形式進行了調(diào)整，調(diào)整后的團隊按照各個業(yè)務線進行了資源歸屬的劃分，一個業(yè)務線團隊支持著這個業(yè)務線下不同的產(chǎn)品或者功能交付；從這個虛擬團隊的組織形式可以看到Spotify的影子，Spotify Tribe對應業(yè)務線；Spotify Squard與該業(yè)務線下下一級的功能交付團隊相對應；Spotify Charter對應前后端等團隊的職能組織。

這樣的實踐經(jīng)過百人規(guī)模向千人發(fā)展之后，逐漸進行了沉淀，形成了最終特性團隊(Feature Team)模式設計的矩陣型組織結(jié)構(gòu)，旨在與業(yè)務模式相匹配，實現(xiàn)研發(fā)協(xié)同與管理模式的有效設計。該組織設計涉及橫向職能維度和縱向交付維度的雙向發(fā)力，具體體現(xiàn)在以下方面：

• 特性團隊業(yè)務域PM聚焦端到端交付價值

根據(jù)業(yè)務領(lǐng)域劃分特性團隊：將研發(fā)職能團隊劃分為多個特性團隊，每個團隊負責一個或多個業(yè)務板塊的研發(fā)交付工作，實現(xiàn)持續(xù)端到端交付用戶價值。

設置業(yè)務域PM統(tǒng)籌各職能角色：業(yè)務域PM負責統(tǒng)籌各職能角色，協(xié)同推動特性團隊實現(xiàn)業(yè)務目標。

• 職能團隊TL聚焦組織發(fā)展&技術(shù)演進

• 職能TL專注組織發(fā)展：組織建設、人才發(fā)展，通過招聘、培訓和指導，提升團隊成員的技術(shù)能力和職業(yè)發(fā)展。

• 職能TL專注架構(gòu)演進：職能TL聚焦技術(shù)基建、架構(gòu)演進等工作，推動技術(shù)發(fā)展和創(chuàng)新。

通過這種組織架構(gòu)設計，得物技術(shù)部能夠?qū)崿F(xiàn)跨職能協(xié)作、端到端交付、業(yè)務目標導向和技術(shù)創(chuàng)新驅(qū)動等目標。特性團隊模式的應用有助于提高團隊的敏捷性、創(chuàng)新性和協(xié)作效率，使得技術(shù)部門更好地適應快速變化的市場需求和業(yè)務挑戰(zhàn)。

圖片

得物敏捷迭代在推廣落地過程中并沒有死搬硬套行業(yè)內(nèi)的一些敏捷框架，諸如團隊級的敏捷框架Scrum甚至是組織級的大規(guī)模敏捷框架SAFE等，而是結(jié)合自身業(yè)務和團隊的特點，借鑒和落地好的敏捷實踐，形成了自己特色的解決方案。

其次我們來看業(yè)產(chǎn)研的協(xié)同，除了在組織架構(gòu)的設計上保持靈活性之外，還結(jié)合敏捷項目管理方法，定義了適合得物產(chǎn)研的協(xié)同模式。

價值導向

敏捷開發(fā)中，產(chǎn)研交付以用戶價值為導向，傳統(tǒng)項目管理的鐵三角（成本、時間、范圍）轉(zhuǎn)變?yōu)椤凹s束”，在固定的時間周期內(nèi)（Timebox），結(jié)合可用資源，交付高價值&高質(zhì)量的需求。

圖片

小步快跑

需求在沒有上線之前只是假設（假設這樣做可以解決用戶的問題），敏捷開發(fā)中，通過需求拆分，高優(yōu)先級需求識別及迭代交付機制，盡快將一個需求從提出推進到上線，能夠盡早收集用戶反饋，驗證需求價值，并及時響應變化。

圖片

雙周迭代

基于以上，得物選擇了雙周迭代模式?；诘乃伎既缦?，1周時間較短，無法交付相對復雜的需求，同時對于存在App端的互聯(lián)網(wǎng)公司，頻繁發(fā)布也會打擾用戶。3周時間較長，對在做創(chuàng)新或者需要快速迭代的業(yè)務模式起不到試錯的效果。所以2周是一個相對剛好的節(jié)奏。

但是2周是一個整體節(jié)奏，并不是意味著所有需求必須等到2周才能發(fā)布，2周是最晚的發(fā)布窗口，在版本結(jié)束之前達到發(fā)布標準的可以任何時間發(fā)布，但是如果沒有趕上2周的窗口，那只能等下一趟；可以參考SAFe中的ART（Agile Release Train）的概念，火車不等人。

這里強調(diào)一下迭代周期和發(fā)布能力是要區(qū)分開的，對于APP的迭代周期來說是以兩周作為維度，但是發(fā)布是可以根據(jù)實際情況單周進行甚至任意時間點進行的動作。

得物有很多的業(yè)務線和對應的業(yè)務類項目，在每個迭代周期結(jié)束后，所有團隊都會同時調(diào)整資源的投入方向，甚至可能會在不同的業(yè)務域之間進行資源調(diào)配；在同一時間節(jié)點調(diào)整避免了因多迭代周期節(jié)奏在不同的窗口期調(diào)整帶來的協(xié)作成本并降低了人為風險。

另外，團隊規(guī)模變大后，一些效能相關(guān)度量指標及統(tǒng)計報告都會以迭代周期統(tǒng)計，如果各個業(yè)務域節(jié)奏不一，會導致數(shù)據(jù)的橫向沒有可比性，這也是在制定迭代周期時容易被忽視的地方。

最后，當解決了團隊資源和產(chǎn)研協(xié)同的問題之后，持續(xù)改進效率問題就變得尤為重要，在這里我們不討論coding本身的效率，一起來探討如何有效的設置研發(fā)效能度量指標才能真正的幫助到我們做到持續(xù)改進。

研發(fā)效能度量

沒有度量就沒有改進的方向，設置合理的度量指標事半功倍，否則度量會變成笑話，給團隊帶來負面影響。

舉個簡單粗暴的例子：人均完成需求數(shù)/每迭代；我相信大家都不會選擇這個指標是因為軟件開發(fā)本身是一個基于變量（需求大小、人員成熟度、開發(fā)環(huán)境及上下游環(huán)節(jié)）進行的工作，這與機械制造行業(yè)的流水線工序是完全不同的工作，不能夠用工業(yè)標準的思維來衡量軟件質(zhì)量開發(fā)。所以要做好研發(fā)效能的度量要有一些基本的原則，才能用指標更好的評估現(xiàn)狀，為團隊持續(xù)改進提供正確的方向。

1. 指標更多的注重團隊，而非個人；此處的意義與OKR的本質(zhì)不謀而合，指標的設定是促進團隊協(xié)作，共同達到組織目標，而并不是個人KPI
2. 指標重要的是關(guān)注趨勢而非絕對值；因為團隊的差異性，指標絕對值很難做到絕對的橫向?qū)Ρ?，無法精確的定義；可以更多從趨勢上去分析，把關(guān)注點放在進一步的改善上
3. 指標注意平衡性，避免在單一指標上越走越遠；指標既有北極星指標，又要有全面的群星指標，做到相互制約
4. 指標也需要隨著團隊的能力提升做適時的調(diào)整；團隊實時都在變化，指標的定義也要定期的回顧合理性，適合團隊階段的指標才能起到改善的指導意義

得物技術(shù)部基于以上的原則制定了研發(fā)和測試過程指標，從交付速率，內(nèi)建質(zhì)量，持續(xù)發(fā)布能力及線上質(zhì)量幾個維度定義了一系列指標，在此我們不一一展開。

三、Type—P規(guī)?；艚輰嵺`

對以上的思路進行整理，我們用以下一些字母來進行釋義，可以簡單的稱之為：Type-P：

• T：Time-bound，每個目標都有DDL，幫助人們在正確的時間內(nèi)設置正確的優(yōu)先級、計劃，并保證目標可達成的交付原則
• y：yauld，敏捷的、活躍的，在一個通用大框架下靈活變通，符合得物價值觀：擁抱變化的原則
• p：unity of purpose，業(yè)務目標、技術(shù)認知一致的、協(xié)作意識統(tǒng)一的合作原則
• e：efficient、effective，高效+有效的，從流程→協(xié)作→工作產(chǎn)出均高效、有效的效率原則
• P：Poizon，得物，Type-P，也就是得物特色的敏捷實踐

在整體闡述Type-P時，為了方便理解，引用主流的規(guī)?；艚軱ESS、SAFE作為參考。

Type-P、LESS、SAFE是基于不同的背景、邏輯所構(gòu)建的項目管理實踐方法，只有左右之別，不存在高低之分。借鑒意義并非是非此即彼的。

圖片

Type-P的一些特點

整體節(jié)奏統(tǒng)一

• 由項目管理團隊-PMO統(tǒng)一管理、發(fā)布：得物App版本發(fā)布日歷；
• 技術(shù)部整體遵循相對統(tǒng)一的版本節(jié)奏時間要求：雙周版本，固定服務端/客戶端發(fā)布日，方便所有業(yè)務、產(chǎn)品、技術(shù)團隊共識評審、交付節(jié)奏。

統(tǒng)一的單域敏捷標準/流程/規(guī)范

• 由項目管理團隊-PMO統(tǒng)一收口技術(shù)部門級別的單域敏捷標準/流程/規(guī)范，并出版統(tǒng)一的項目管理白皮書，從需求階段、開發(fā)階段、測試階段、發(fā)布階段，分階段闡述各階段的關(guān)鍵活動、組織者、參與者、準入/準出標準、項目管理工具RDC操作指南。

統(tǒng)一的版本管理

• 相同的時間周期內(nèi)進行研發(fā)交付工作，可以為數(shù)據(jù)收集和分析提供一致的時間框架，有助于建立統(tǒng)一的數(shù)據(jù)采集規(guī)范，提高數(shù)據(jù)準確性，使得各業(yè)務線橫向的度量數(shù)據(jù)具有可比較性；
• 幫助PMO和管理者更好地識別潛在風險并加以解決，如某業(yè)務域出現(xiàn)的資源瓶頸，可以通過度量數(shù)據(jù)識別出同版本周期內(nèi)人力相對富裕的團隊，及時進行人力借調(diào)，以保障需求交付；
• 資源協(xié)調(diào)和透明度的提升可以在技術(shù)部所有團隊的角度提供更大維度的操作空間。

靈活調(diào)整、裁剪的分域治理

• 分域治理：以業(yè)務條線維度整體劃分業(yè)務域、分域治理：業(yè)務域X、業(yè)務域Y、業(yè)務域Z等等。

各類資源數(shù)各域固定；

各域單獨一份product backlog，業(yè)務一號位決策，域內(nèi)優(yōu)先級決策高效。

• 各域流程靈活調(diào)整、裁剪。

在抽象出Type-P的核心原則的過程中，發(fā)現(xiàn)和Type-C的命名非常相似，也期望得物所特有的Type-P在經(jīng)過過去、現(xiàn)在、未來的努力之后，不僅是得物特色，也能同Type-C一樣，成為一種業(yè)界通用的“標準接口”，給更多同業(yè)/同行更多的參考、借鑒意義。

四、PMO團隊實踐過程中的演化

敏捷實踐過程的落地離不開PMO團隊，這個過程中PMO首先承擔了以下的一些工作。

• 制定Type-P的組織級的項目管理框架、流程及維持運行一致，并持續(xù)優(yōu)化
• 規(guī)劃、建設統(tǒng)一項目管理工具：研發(fā)協(xié)同平臺（簡稱：RDC），從流程、報表、資源、效率等維度支持部門級項目管理健康運行、監(jiān)控、優(yōu)化
• 分域支持各域項目管理個性化治理：確保符合各域在Type-P的大流程框架下，靈活增加、調(diào)整、裁剪，以適配業(yè)務/產(chǎn)品/技術(shù)團隊的真實使用訴求
• 承接獨立項目、在流程、機制、跨域協(xié)同中起到重要支持、提效作用

這些工作其實業(yè)內(nèi)大部分團隊是一樣的，但是隨著團隊人數(shù)的增多，團隊成熟度的變化，敏捷實踐階段的改變，PMO團隊的定位和方向也是隨著變化的。

從“吞吐優(yōu)先”向“價值優(yōu)先”過渡。流程落地、項目管理工具落地是在實踐過程的前期一定會去做的事情，這個落地過程中的問題也會因為各種因素層出不窮，這個階段的落地目標也會把團隊的吞吐情況作為第一目標去完成。

當落地階段完成之后，常規(guī)PMO團隊所需要完成的事項就變成了基礎(chǔ)工作，團隊目標也從“吞吐率”轉(zhuǎn)向了“價值”，這里的價值有兩層含義：第一是需求和項目的交付更注重業(yè)務本身的價值，形成端到端的閉環(huán)，從需求提出本身的價值角度判斷優(yōu)先級，提升團隊交付的意義。在業(yè)內(nèi)，很多團隊的閉環(huán)交付受到業(yè)務形態(tài)和外部因素的影響，在尾部復盤階段會推行的很艱難。第二是PMO自身在職能團隊和業(yè)務團隊中的價值，幫助團隊找到流程卡點和人效洼地，提出改進方案和提升研發(fā)團隊效能產(chǎn)出。這需要PMO和團隊建立足夠的信任感，提升自身在團隊的影響力，信任感的建立不是一朝一夕的，需要在日常的工作中真正幫助到了團隊，才會逐漸形成。

這個目標看似簡單，但是實際過程中還是會有很多難點，需要得物的PMO具備更強的個人綜合實力和軟技能，業(yè)務感知力、數(shù)據(jù)分析能力、談判技巧、團隊洞察力、社交能力等，迭代和項目管理是基本盤，需要花更多的時間在技術(shù)團隊的人效提升上，哪怕是交流溝通去建立信任，也是一件花時間的事情。

五、小結(jié)

本文先從團隊發(fā)展的角度，看我們遇到的一些挑戰(zhàn)；第二部分針對這些挑戰(zhàn)，不斷去嘗試解題思路；這些挑戰(zhàn)是從實際出發(fā)，結(jié)合實際問題我們歸納到兩類，一個是資源，一個是協(xié)同。那從資源協(xié)同的角度，我們怎么抽象化地解這個問題？解這個問題就兩個思路，一個是解資源的，另一個是解協(xié)同的，協(xié)同上又用到了價值導向、小步快跑和雙周迭代的思路。不管是協(xié)同、資源、還是問題也好，都會牽涉到「研發(fā)效能度量」，通過上文的思路和舉措，基本上就是把我們遇到的挑戰(zhàn)給解決了。另外，也補充說明了得物特色的敏捷管理思路Type-P，區(qū)分主流項目管理框架，因地制宜，打造了得物特色千人敏捷項目管理。

每家公司所處的行業(yè)，階段各不相同，敏捷宣言也已經(jīng)從1.0升級到了2.0，隨著AI時代的到來，符合各自敏捷場景的落地又會有更多的變化和挑戰(zhàn)，希望通過上面的一些介紹，能給大家在敏捷落地過程中有一些啟發(fā)，也希望大家可以擁抱變化，一起交流，共同進步，開創(chuàng)一個屬于我們自己的敏捷時代。