跨組織協作

這一篇就來回到上次所提的話題，講一下 M 落實開發紀律以及協作的組織架構和方法。

就如許多人所熟知的 M 設兩大產品主軸：Windows 和 Office ，這兩個也正是規模最大的兩個團隊。比較有趣的是，這兩個團隊剛好也代表了兩種不同的子團隊組成方式。Windows 團隊自從有紀錄以來，他的組織一直有著比較嚴謹的架構。拜賜於系統軟體本來就有的結構，子團隊也剛好幾乎是一對一的對應，相互之間的互動也比較能夠有事先規定的規則。雖然後來幾經改革，將部分的子團體 （尤其是與 UX 有關的）設計成比較有彈性的架構，但是原則上還是比較像層次分明的軍隊，或是一統天下的大帝國。

反過來看 Office team 則走相對不同的路線：由於主要的子團隊都是獨立的產品，組合起來像是各個諸侯並存的聯邦。在很早期的 Office 版本 （95 以前），Word/Excel/PPT/Access 還真的是各自獨立開發的團隊，橫向連結整合並不多。是從 97 開始 (也是我進入 M 社服務的同時），在 SteveSi 的努力之下，開始成立所謂的 Shared teams，諸如 File Open/Save/Print、DDE/OLE、Copy/Paste、一致的介面設計等等，委由獨立的子團隊幫大家服務；這樣才逐漸形成到現今有著統一風格的產品組合。但也因為如此，Office team 的子團隊數目相當龐大，加上每個版本幾乎都有新產品加入 (當然也有淘汰，有人還記得 PhotoDraw?)，到現在應該還是維持成長的趨勢。

在這樣的前提之下，要有系統的進行跨團隊協作，自然是很大的挑戰。同時，就如同前面所說明過的，每一個版本由於專注點不同，工程管制的方法也都不一樣，這使得難度再提高一個層次，所以每一個版本的流程都是跌跌撞撞，坐著車子改車子的情況下完成。不過，幾個版本做下來，總還是能發展出一些基本的準則，維持跨團隊的運作和解題：

• 每個子團隊都有所主打的 end-to-end 體驗，而這個體驗的完成和流暢度，要由負責的團隊從頭盯到尾。在前一篇談到使用者體驗的文章中就談到過，台灣的團隊為了手機上的功能，連帶 PC 上的運作也要協助完成。通常協調的工作，是由各個 GPM 帶著 PM 們跟其他 stakehoders 利益相關者團隊打交道，發揮跟業務差不多的能力，周旋及妥協下完成任務。

• 每一個版本的總體品質指標，以及每個里程碑階段的追蹤，是由其中一個產品團隊所兼任，意思就是這個團隊還是有功能要開發，並不是只做流程管制。這個設計是刻意的，為的是讓這個團隊不會因為過度追求管制的 KPI，而影響甚至扭曲原來開發的目標。而這個 “流程警察” 也並不能做直接地糾正或管制，比較像是提供警示和必要的資料，產品開發的決定權還是在每個團隊的手上。

• 整個 Office team 有一個 Office Coordination Forum 的定期每週會議，每個團隊的 GPM、DM 或 TM 都會輪流參加。OCF 的主議題雖然是“流程警察” 提出，但是每個團隊如果有特定議題也可拿出來談，而且銷售團隊也會透過這個會議與團隊的 decision makers 溝通，是主要形成共識的重要場合。在這個地方形成的決定，連 CEO 也無法改變。

整體來說，Office 的協作進行是每個自治體的動態合作的結果。其中雖然沒有事先制定好的 playbook ，靠著約定俗成的經驗法則，以及團隊成員的共同智慧，來完成每一個艱鉅的任務。不可否認，能在這樣的環境下跟一堆聰明人合作，所能得到的成就感很難用言語說明。