自從 Ruddy 老師提倡：《專案之初，首重看見全貌》的觀念，這想法與我過去引導團隊的 視野 很雷同。因為我一直用 視野 在思考全貌這件事，這反映了各個組織層面的運作、協作、溝通、產能。

我這邊講的『視野』一詞，可以是 Perspective (遠景)、Aspect (觀點)、View (視圖)、Dimension (維度)、 …

視野包含的 X、Y、Z 軸，三軸構成的整體全貌：

• X 軸 - 產品 (Product): 抽象的事，也就是產品的概念，例如 ERP、CMS 都是一些產品
• Y 軸 - 團隊 (Team): 具象的人群，可以是 技能團隊、跨職能團隊 (任務團隊) 或者 管理團隊
• Z 軸 - 架構 (Architecture): 具象的物，也就是技術架構與實踐，包含單體架構、微服務、分散式架構 … 等。

這些會構成三種主要排列組合 (XY、XZ、YZ)，形成了全貌的層次。除了三軸，另外看不到的是 時間軸 (T)，會牽動 X / Y / Z 的改變，講的是 企業的發展階段。我畫了一張圖，呈現如何用三軸看到視野與全貌在組織運作的關係，底下分別說明三軸的關係。

updated 2019/04/27
這張圖於新竹敏捷社群 Meetup 的分享：導讀持續交付 2.0 - 談當代軟體交付之虛實融合

全貌的層次

Google Map 是我最常比喻的例子，因為他的 Zoom In / Zoom / Out 就是一種視野感、層次感。從地圖上可以看見全世界、看見台灣、看到台北市，是三個層次的視野，三個層次的全貌。三個層次的視野，面對的問題不一樣，思考的出發點不一樣。

X、Y 軸：產品線與團隊的問題

通常初創團隊，這兩個是貼在一起的，也就是：

• X = 1 (單一產品線)
• Y = N (技能團隊數)

這通常會需要打個一兩年的仗，確認產品在市場的可行性與模式。幾年後，如果現金與模式都找到穩定的供需，可能會有多個產品線並行：

• X = M (多產品線，M > 1)
• Y = N (技能團隊數)

這時候開始面對協作問題，因為 M cross N 導致效率低落。而背後另一個因子會慢慢浮出來，他就是 Z 軸。接下來 Y 的質可能會開始有所調整，從原本的技能團隊，改變成跨職能組織。也就是現在常聽到的 矩陣型組織、跨職能團隊。

如果是一個大公司，也就是全部的產品線，包含各個產品線與客戶的關係，各個產品線與組織的對應關係，各個 #組織與技術架構 的關係。

所以 XY 軸對應到時間線，要面對的問題：

• 前：快速交付產品，面對市場
• 中：穩定產品交付的品質，產品與團隊的協作效率
• 後：除了上述兩個，通常 Z 軸的問題會慢慢浮現，需要被重視，他就是架構。

所以總結要面對的問題：協作與共識

Y、Z 軸：團隊與技術架構的問題

Z 軸可以代表技術與架構所組成的複雜性，Y 軸是團隊。

新創前期面對的技術，大多由草創成員決定，確立的方式大多是以熟捻的、開發速度快的優先，這時候 Z 複雜度相對不高。一段時間之後，隨著人員異動， Y 軸的質產生異變，Z 軸隨之也跟著牽動著。同時因為產品線 X 軸的拉大，YZ 軸通常很快在幾年之內會有很大隱性的變化，Z 軸代表的『複雜度』問題會漸漸浮上檯面。

幾年後，X 軸已經是多個了，Y 軸已經是跨職能團隊了，這時候的 Z 軸，除了複雜度的問題，技術管理的問題浮上來。

整理 YZ 軸的兩個核心問題：

• 複雜度：也就是技術爆炸，既有的架構維護與管理、新架構的導入與管理
• 技術管理：新技術的選擇、導入與實踐

X、Z 軸：產品線與技術架構的問題

康威定律 描述 產品架構 於 組織團隊 直接關係，這個關係直接影響整個公司的溝通效率與產能。所以 XZ 軸就是在描述康威定律。

而康威定律實際上呈現的則是，溝通問題，所以單一討論 XZ 軸沒什麼意義，因這裡面沒有人，也就是 Y 軸：團隊？

所以當探討 XZ 軸的問題時，背後其實隱藏著 Y 軸，也就是產品線、組織架構、技術架構必須一起看，才能看到真正的問題。而這三個放在一起時，第一個要面對的問題，就是 溝通。如何有效、高效、一致性的達到共識，就是最重重要的議題。

因為這些因子疊加再一起，所以總結最後要面對的問題有兩個：複雜度、溝通

T 軸：時間的問題

前面三段，其實都是用 T 軸在貫穿描述，時間會改變 X、Y 軸，也會牽動 Z 軸，前述提到的視野，是立體的三軸，三軸構成的體，隨著時間的前進，組成新全貌。

對於企業來講，時間代表著幾個面向：

1.企業發展階段

如下圖：

不同階段的重點有不同，三軸的重點也不同。舉例來說，在成長期階段的企業，這時候的 X 會很高，Y 軸，如何留才、培養團隊成員的素質，會是關鍵。因為人才會導致 Z 軸的複雜度有所變化。

以史為鏡，可以知興替

更多企業階段性的整理，參見 不同階段的企業

2. SDLC

軟體開發的生命週期管理，詳細參閱 Software Development Lifecycle

3. 專案管理

T 軸另外的面向則是 專案管理，也就是如何讓專案符合時程，任務達到業務目標。

4. 敏捷開發

怎麼讓 開發 有效執行，不管是了解 SDLC、還是專案管理，這年代敏捷開發的方法論是有效的，其核心概念就是：

讓開發人員好好的把事做好

怎麼樣能讓工程師把事情做好？

1. 降低 WIP (Work in Process)
2. 降低干擾 (Context Switch)
3. 控制好優先序、減少插件
4. 學習型組織
5. 建立有效的溝通模式

用視野看見全貌

視野 (Perspective) 有各種面向，看近看遠、看深看廣、看過去現在未來，都是視野。Google Map 除了有 XYZ 軸，也有各種層次 (layer)，像是衛星、交通、3D … 等。實際上用全局的方式，探討各個面向的問題，以全貌了解本質，才不會走偏，或者看錯。

這篇文章描述的『全貌』，只是從企業內部看到的而已，如果把業務以及市場加進來，可能又不是如此了。

延伸閱讀

站內延伸

• 人生的視野
• Role And Responsibility
• 事件管理與康威定律
• 不同階段的企業
• 溝通 = 成本
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
• 軟體交付的三體問題
• Software Development Lifecycle
• Cost in Context Switch
• 不同階段的企業

相關文章

• 企业的组织架构是如何影响技术架构的？
• 当技术为组织所累时怎么办？将你的组织架构旋转90度！
• 业界微服务楷模Netflix是这样构建微服务技术架构的
• 99%的程序员认不全的软件开发定律
• 波蘭化的台灣：工程師該賺多少才合理？

更新紀錄

• 2021/04/20: 更新時間 T 段落，增加內容