組織級敏捷轉型的四個階段

物理結構對系統是相當重要的，但它們不多是槓桿點，由於改變物理結構一般不太容易並且見效慢。恰當的槓桿點，須要從一開始就被設計好。一旦實體的結構創建起來了，要想找到槓桿點，就須要理解系統的限制和瓶頸，在儘量發揮它們的最大效率的同時，避免出現較大的波動或擴張，超出其承受能力。——德內拉·梅多斯《系統之美》

筆者認爲，敏捷轉型是一個系統性的改進工程，具備時間和空間兩個維度的複雜性，故要用動態的眼光來觀察。做爲參與組織全局優化的改進工做者，視野不能侷限於研發過程，更要避免深陷於諸如「在某個小技術團隊內推行三三五五」之類流於形式的過程當中。

推進敏捷轉型和作其餘改進工做同樣，目的是幫助組織成功，故不可能一蹴而就。更況且組織的使命是達成商業目標，而非敏捷轉型成功，切勿捨本逐末。若是強行導入，則比如經過大躍進方式達成共產主義，結果可想而知。甚至可能出現轉型還沒有成功，公司卻已經在殘酷的市場競爭中倒閉了的狀況，與「幫助組織成功」的目標背道而馳了。

企業的成長階段決定了組織當前的結構。因此，既然組織的使命是達成商業目標，更合理的轉型槓桿點，是着眼於宇宙的大尺度，基於組織處於不一樣階段時的結構和組織對項目經理（下稱： PM ）的定位，解決組織「難以達成商業目標」的痛點，而後逐步拓展系統邊界和提高 PM 的職責範圍，不斷地進行全局的敏捷化。

#階段〇：小做坊

這個階段，組織對 PM 角色的訴求並不過高，由於初創團隊纔是真敏捷。有贊 CTO 崔玉鬆也常常感慨早些年奮鬥的日子：團隊小，溝通成本低。哪須要什麼項目管理啊，吼一嗓子的事兒，上午與負責產品和業務的同窗討論完畢，下午搗鼓搗鼓就弄上線了。

只是這種模式不可持續，有兩股力量在推進組織往不一樣的方向進化：業務和技術（以下圖）。其中：

1）通常來講，技術側的複雜度風險會比業務側更早暴露，因此管理者介入技術側並在此沉澱的管理方法也較多，技術團隊的管理成熟度逐漸提升。 2）技術側的學習門檻高於業務側，故對人員技術深度的要求高於廣度。 3）初創企業須要儘量多的人員能支持全部業務，業務廣度優先於深度。

#階段一：職能結構

彼時，有贊業務主要圍繞微信商場城SaaS展開，組織結構相對簡單，從做坊式分工過渡到了職能結構形態。爲提高技術管理的成熟度，有贊在該階段引入了 PM 角色，故該階段的 PM ，最重要的使命，就是關注研發生命週期管理，創建研發項目的管理體系，用「項目」這種形式來創建研發人員的合做方式，目的是使組織從無序到有序，並培養羣體的規則意識，提高研發團隊的管理成熟度。

有贊在研發項目管理體系的搭建過程當中，適當地導入了一些敏捷的元素，一方面讓規則創建在當下研發人員熟悉的工做流程上，另外一方面又不至於過重，給人留下瀑布式項目模式的烙印，爲將來的調整留出空間。隨着組織成熟度的提高，能夠加入更多的敏捷元素。

敏捷轉型的過程，就是在不斷試探中逐漸減小管理投入及增強自組織能力的過程。

#階段二：事業部結構

有贊啓動雲業務，抽象底層能力，並在此基礎上嫁接出更多的垂直領域（好比：美業、零售連鎖、教育等等），沒有人能全局掌握如此寬泛的業務知識，業務複雜度變得很突兀了（以下圖）。因而，在商業目標的驅動下進行了新一輪組織架構調整，事業部的特徵慢慢造成。事業部制也就是德魯克所推崇的「聯邦分權制」，在該模式下，各職能部門被拆解，人員以小組單元形式重組到以達成特定商業價值爲目標的各獨立業務領域中。

從宏觀上看，這種模式像極了敏捷團隊，角色齊全，目標惟一。但在事業部內部觀察的話，每一個角色並不是單我的，而是一個由 TL 管理的小組，因此微觀上仍是職能結構（甚至有一些提供共享能力的角色僅以虛線形式存在於事業部內，實線的職能特徵更強）。但總的來講，商業目標使得原來職能結構時期的部門牆正在瓦解。

此時， PM 能夠騰挪的空間開始變大。與原來單一業務下的大組織相比，事業部化以後各團隊的規模變小（但仍是有上百人），對接該業務線的 PM 能夠夯實大部分在階段一的改進點，並根據小團隊作更深刻的優化。其中特別有效的一個手段，是基於事業部下各二級業務線的需求生命週期管理。

隨着 PM 在研發生命週期的做用的發揮，咱們發現流動效率的瓶頸，已從技術側左移到表明需求生產的產品側，故 PM 的職責範圍再也不只是研發側，而是從需求生產到研發上線的整個需求生命週期的項目管理。系統的邊界就變成了：商業目標落地爲業務需求，是系統外部的驅動力。同時，因爲在研發側有充分的沉澱和賦能，研發過程的管理能夠逐步交接給技術團隊本身完成。

一方面， PM 能夠酌情下降研發管理細節的關注度，而應把精力重點放在產品側的過程管理（好比：設置 APO 和 PO 、產品側里程碑、需求價值跟蹤等），以及需求從產品側到技術側的界面（好比：統一需求池、需求預估、資源衝突處理等）。另外一方面， PM 逐漸引導事業部，在不改變組織結構的前提下，進一步劃分爲以商業目標爲導向的多個虛線特性團隊，並嘗試解耦。

隱藏細節，本質上是一種爲了站到系統更高層級上作更全面思考的必要手段。

#階段三：矩陣結構

爲了提高市場競爭能力，有贊須要在更多的垂直行業提供解決方案。和事業部模式相比，這是一種更靈活的組織形式，是面向新商業模式的一系列嘗試。它不改變現有的組織架構和彙報關係，以臨時組建全鏈路項目的方式，拉動整個組織上下游資源，圍繞短時間業務目標進行的一場綜合行動。它的特色是短頻快，打得贏就打，打不贏就跑。

PM 在本階段須要關注的全鏈路項目管理，包括了銷售、市場、產品、技術、運營、服務等多個環節，而每一個環節都會有一系列的動項，每一個行動項都須要用子項目的方式管理其過程。階段二所關注的產品研發項目，在這裏只是其中的一個行動項而已。站在更全局的視角，細節進一步被隱藏。

該階段彷彿又回到了「臨時組建項目」的工做方式，並且細節操做層面可能會散在各處。但實質上，這類項目的各方資源在宏觀上更內聚，由於每一個職能角色都會有一個核心人員參與其中，在覈心團隊實踐「三三五五」反倒更加容易和有效（相似於 Scrum Of Scrums ，但會作得更重），組織典型的特徵是：目標更聚焦、市場反饋更早、需求迭代更快。固然，由於各行動項須由核心人員帶回各自職能單元落實，故仍然要歸屬在統一需求池的框架下。

與產品研發側相比，協調各職能角色的難度更大。故 PM 須要將產品研發業已沉澱的管理能力賦能給其餘職能單元，有助於各職能角色對齊目標和行事方式，避免 PM 既要顧全大局，又要由於組織中各職能單元成熟度不夠而不得不處處救火。

#階段四：戰略業務單位結構

在該階段，組織將在大型的多元化產品市場中進行多種經營，提供不相關的產品與服務。有贊還沒有走到該階段，故筆者暫無實踐經驗能夠分享。但能夠預見到的是，隨着組織的壯大，單個 PM 能夠觸達的組織範圍是有限的，故須要依託組織的力量，是歸屬於 PMO 仍是事業部，取決於項目管理專業技能和改進對象的業務複雜度對該角色的影響當前誰佔主導（參考上圖特性團隊和組件團隊的決策模型），敏捷轉型的方向和節奏也會受此影響。這也將會是一個有趣的話題，但限於篇幅，不在此展開。

組織的進化是一個存在即合理的過程，從系統思考的角度來講，敏捷思想的引入只是做用於系統的無數個懸擺之一。且在組織的不一樣階段（時間或空間），會產生不一樣的時延做用，甚至可能違背當事人的初衷。做爲組織級敏捷轉型的導入者，咱們一方面要積極面對組織現狀作系統思考，並因地制宜地導入有利於組織成長的敏捷元素，另外一方面也要及時觀察該系統的反饋效果，分析各回路的變化和主次關係切換，合理作出調整。

我驚恐地意識到，我急迫地但願重建民主，有些作法卻幾乎和理想主義者同樣了。我一直但願更快地推進歷史的發展，卻犯了「適得其反」的錯誤。我意識到，當咱們試着創造一個新事物時，咱們必須學會等待。咱們必須充滿耐心地播種，精心澆灌土地，讓種子本身發芽、生長，它須要時間。你不可能愚弄植物，你更不可能愚弄歷史。——瓦茲拉夫·哈維爾（捷克共和國第一任總統、劇做家）