物理結構對系統是至關重要的，但它們很少是槓桿點，因為改變物理結構通常不太容易而且見效慢。恰當的槓桿點，需要從一開始就被設計好。一旦實體的結構建立起來了，要想找到槓桿點，就需要理解系統的限制和瓶頸，在儘可能發揮它們的最大效率的同時，避免出現較大的波動或擴張，超出其承受能力。——德內拉·梅多斯《系統之美》
筆者認為，敏捷轉型是一個系統性的改進工程，具有時間和空間兩個維度的複雜性，故要用動態的眼光來觀察。作為參與組織全域性優化的改進工作者，視野不能侷限於研發過程，更要避免深陷於諸如“在某個小技術團隊內推行三三五五”之類流於形式的過程中。
推動敏捷轉型和做其他改進工作一樣，目的是幫助組織成功，故不可能一蹴而就。更何況組織的使命是達成商業目標，而非敏捷轉型成功，切勿捨本逐末。如果強行匯入，則好比通過大躍進方式達成共產主義，結果可想而知。甚至可能出現轉型尚未成功，公司卻已經在殘酷的市場競爭中倒閉了的情況，與“幫助組織成功”的目標背道而馳了。
企業的成長階段決定了組織當前的結構。所以，既然組織的使命是達成商業目標，更合理的轉型槓桿點，是著眼於宇宙的大尺度，基於組織處於不同階段時的結構和組織對專案經理（下稱： 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 還是事業部，取決於專案管理專業技能和改進物件的業務複雜度對該角色的影響當前誰佔主導（參考上圖特性團隊和元件團隊的決策模型），敏捷轉型的方向和節奏也會受此影響。這也將會是一個有趣的話題，但限於篇幅，不在此展開。
組織的進化是一個存在即合理的過程，從系統思考的角度來說，敏捷思想的引入只是作用於系統的無數個懸擺之一。且在組織的不同階段（時間或空間），會產生不同的時延作用，甚至可能違背當事人的初衷。作為組織級敏捷轉型的匯入者，我們一方面要積極面對組織現狀做系統思考，並因地制宜地匯入有利於組織成長的敏捷元素，另一方面也要及時觀察該系統的反饋效果，分析各回路的變化和主次關係切換，合理做出調整。
我驚恐地意識到，我急迫地希望重建民主，有些做法卻幾乎和理想主義者一樣了。我一直希望更快地推動歷史的發展，卻犯了“拔苗助長”的錯誤。我意識到，當我們試著創造一個新事物時，我們必須學會等待。我們必須充滿耐心地播種，精心澆灌土地，讓種子自己發芽、生長，它需要時間。你不可能愚弄植物，你更不可能愚弄歷史。——瓦茲拉夫·哈維爾（捷克共和國第一任總統、劇作家）
