- 會議太多了,員工開會效率降低了50%!
上篇文章《研發效能組織架構：職能獨立vs業務閉環》介紹了職能獨立型組織架構和業務閉環型組織架構的特點，優劣勢。也許有的小夥伴可能對這兩種組織架構沒有深刻的體會，而本文就是想透過資料說話，想僅僅透過計算這兩種組織架構下開會時間這一項，讓大家知曉職能型組織架構帶來的巨大溝通成本，也讓大家清晰看到兩個組織架構之間巨大的效率差距。
產研運協同主要工作流程
下圖是一個迭代過程中產研運協同時涉及的主要工作流程
-
綠色的會議為全員參與的會議
-
粉色為專業職能團隊內部的會議
-
通常來說PO(Product Owner)幾乎每天都會梳理使用者故事
產研運協同主要工作會議
下表詳細列出了在一個迭代中涉及到的主要的會議，包括會議涉及的角色、輸入、輸出和會議目的。
這裡有幾點要重點說明
-
運維和運營小夥伴可以按需參加。
-
通常產品和運營不分家，所以也可以把運營劃分到產品團隊中。
-
產品團隊和設計團隊之間的溝通會沒有體現在其中
-
迭代評審會和迭代回顧會，對於小團隊來說可以合併成一個會議，但需要控制時間
-
會議時間為我們專案中開會的實際時長，不同團隊、業務和規模下也許不同。
職能獨立型組織架構迭代日曆
此表只包含了一個迭代中最基本的會議。有很多橫向的會議沒有放在其中，比如團隊與使用者的各種溝通會議，職能團隊之間橫向溝通的會議，設計師走查會議，還有一些非預期的會議和溝通等。
非預期的會議和溝通所佔據的時間在職能型組織架構下是非常多的，主要是因為在這種組織架構下，因為缺少一個初步判斷和處理的點和人，很多非預期的問題都要透過各種角色開多次會議拉通、對其來解決。舉個簡單例子，公司的法務聯絡專案組要求進行軟體著作權登記。這對於正在迭代中的專案組是個非預期的事件。這就開始溝通了，PMO拉會，全員到齊開始商量誰來做這事，怎麼做，大概多長時間，是否會對專案產生影響，影響多大，是否延期。有人主動擔當還好，要是都推卸，肯定是一個多次溝通，部分需求延遲上線的結果，相當於砍掉部分需求。
按照上面的時間我們就可以粗算出一個迭代（10個工作日），開會時間分別為：
-
站立會：0.5h*10=5h
-
PRD評審會：1h
-
迭代排期會：1h
-
測試用例評審會：1h
-
迭代評審會：1h
-
迭代反思會：1h
-
藍色部分為各個職能團隊內部的會議，折算成全體人員會議時長為2h
所以職能型組織架構下，一個迭代開會總時間最少為 12 h，佔比12/(8*10)=15.00%
兩週開會的時間就要佔據一個人總工時的15%。是每一個人的15%，想想就多麼的可怕。
業務閉環型組織架構迭代日曆
對於業務閉環型的團隊，很多職能團隊之間被動的拉通、對其變成了團隊內部之間的自我驅動，主動承擔。職能團隊之間正式的交流會議就沒那麼重要了，團隊內部之間更多的是非正式的交流。團隊內部之間最好的交流時間就是「現在」，最好的交流地點就是「工位」。
-
需求初審和迭代排期會，可有可無，甚至是早會的時間就可以消化掉
-
迭代評審會、迭代反思會、甚至是團隊週會，都可以合併成一個會
-
PRD評審會和測試用例評審會，只需要對應功能的人員參加即可，也不需要全員全程的參加會議，甚至只需要坐到一起溝通一下，根本也不需要定會議室，也不願意去會議室，更願意座位上直接溝通。公司的會議室可是非常難預訂的，非必要不去搶，搶會議室費時費力費腦筋。
-
PRD內審、技術方案內審會、測試用例內審會也只需要小範圍內參與討論即可。
同樣按照上面的時間我們就可以粗算出一個迭代（10個工作日），開會時間分別為：
-
站立會：0.5h*10=5h
-
PRD評審會：1h
-
測試用例評審會：1h
-
迭代評審&反思&雙週會：1h
所以業務閉環組織架構下一個迭代開會總時間最少為 8h，佔比8/(8*10)=10.00%。相對於職能獨立型組織架構，一個迭代每一個人開會時間降低4h，開會時間佔比減少50%。每個迭代保質保量幹完活的前提下，整個團隊還可以放假半天，多麼明顯的一個效率提升。
本文總結
本文僅僅透過計算一個迭代週期內，團隊內部每一名成員的開會時間，發現了兩種組織架構下巨大效率差異。通常情況下業務閉環組織架構要比職能獨立型組織架構，一個迭代裡每一個人開會時間降低4h，開會時間佔比減少50%。組織架構變化帶來的效率提升遠比架構、技術基礎設施更直接、更直觀和更吸引人。心動否？要不要試試？
閱讀我的更多文章
研發效能組織架構：職能獨立vs業務閉環破局DevOps｜8大北極星指標指引研發效能方向
DevOps | 研發效能價值如何衡量
高效能敏捷交付團隊反思：特性團隊(FeatureTeam)+Scrum
研發效能組織能力建設之特性團隊FeatureTeam（上）
研發效能組織能力建設之Scrum管理框架核心精髓（中）