上次我們已經針對組織分成好幾個領域，接下來我們要說說「人」的部分。

也是整個過程，最「難」的部分，所以我會分成兩個章節來說明。

這個章節，我們來焦點說說「人」的分配。

當我們人很少

在一個組織中，人的數量是有限的，而且人的數量不多，那是不是表示我們什麼都做不了呢？非也，如果人很少的時候，就算只有一個人，也能夠做出很多事情。

因為在 FID 中，是「人」服務領域，而不是完全依賴人，所以我們可以按照自己的工作時間，來分配給不同的領域。

• 清楚知道自己的工作時間和工作目標
• 依照前一章節的「成本」和「重要」來分配工作時間

當我們人變多了

隨著組織的成長，人的數量也會變多，這時候我們就可以依照不同的領域，來分配不同的人。

在這裡有幾個重點：

• 人的數量不是越多越好，而是要依照組織的成長來增加
• 一個人可以同時服務多個領域，但是要注意「成本」和「重要」的分配

以上是大概一個部門的組織架構，按照這個架構下來，我們不但可以同時培養工程師的技術，也可以培養工程師的管理能力，隨著技術增長，工程師在某個領域的知識也會越來越專精，甚至可以設計出一套屬於自己的架構。

主導者

主導者，通常是部門的主管或 Leader，他的工作是：

1. 調研領域的技術可行性，初探，而非深入
2. 研究跨領域的合併和整合，並且提出建議
3. 調整領域的人力分配，並且提出發展建議和方向
4. 定期拉起每個領域的進度，必要時淘汰或放棄領域
5. 綑綁領域的成果，並保持成果的可用性
6. 引導成員熟悉領域的技術，並促進 KM 的建立

而一個主導者的主要日常就是第一段所說的樣子，按照時間來分配做不同領域的事，保持各個技術的熟悉度和敏銳度。

主要設計者

主要設計者，可能是 Leader 兼任，也可以是資深工程師，但也可以是很有天賦的工程師，我就曾經遇過好幾個很有天賦的工程師，雖然是新人，但是很快就能夠熟悉領域的技術，並且能夠提出很多建議，這時候就可以讓他們擔任主要設計者，他們的工作是：

1. 深入調研領域的技術可行性，並實踐出成果
2. 抽象設計出該領域的架構，這設計必須能解決當時的專案問題
3. 計畫和執行研發時程，設定短中期目標。
4. 協調和分配領域的人力，並定期收集成果，確保研究方向正確

主要設計者有幾個特點，那就是他們將會是這個技術的專家，大家遇到這類型的問題，都會來尋求他的協助。

例如：

1. A 是 UI 的專家，所以當有其他同事遇到 UI 的問題，就會去找 A
2. C 是 DevOps 的專家，所以當有其他同事遇到 DevOps 的問題，就會去找 C
3. B 是 JAMStack 和 Serverless 的專家，所以當專案需要 JAMStack 和 Serverless 的時候，就會去找 B
4. E 是 IoT 的專家，所以當專案需要 IoT 的時候，就會去找 E

當我們遇到一個問題：

問：我們現在有一個專案，需要遠端操控一個機器人，這個機器人需要有一個 UI 來顯示操控的畫面，並且需要有一個後端來接收操控的指令，並且將指令傳送給機器人，這時候我們該怎麼做？應該找誰來協助？

參與者

參與者，他們通常是新人，或是對於領域的技術不熟悉的人，他們的工作是：

1. 學習和熟悉領域的技術，並且能夠獨立完成任務
2. 協助主要設計者完成階段性任務。
3. 回報領域的問題，並提出修改的方法
4. 回報研究成果，並且協助主要設計者整合成果

參與者在一開始並無法給專案太多建議，也不應該給他們太多的壓力，因為他們需要花時間來熟悉領域的技術，所以在一開始，給他們的任務必須是簡單的。

然後逐步增加難度，並讓他們學習該組織的運作，以免產生劇烈的衝突。

KM

KM 就是 Knowledge Management，也就是知識管理，這是一個很重要的部分，因為在 FID 的過程中，我們最終要得到的是「知識」。

這些知識包含了：

1. 在組織內，我們通常會遇到的問題，以及它的解決方法
2. 在解決問題的過程中，我們所學到的技術
3. 主設計者設計的架構，以及架構的演進過程
4. 架構的擴充和整合方式
5. 架構的優化和改善方式

紀錄方式不限於任何形式，只要能被紀錄下來，並且能夠被搜尋到，之後再找一個稱心的地方彙整起來即可。

執行專案的工程師

通常我會把執行專案的工程師，分成兩種：

1. 由主要設計者帶領的工程師的專案：這專案是第一次採用或是第一次使用某個技術，所以主要設計者會帶領工程師一起完成專案，並且在專案結束後，將專案的成果納入 KM

2. 一般專案：這類型的專案，通常是已經有一個架構，或是已經有一個成果，所以工程師只需要依照架構或是成果來完成專案即可，建議給予工程師一定的自由度，讓他們能夠在專案中學習到新的技術，並且將成果納入 KM

有一個心得是，不管專案類型大小，都要做專案回饋，這樣才能夠讓我們的專案越來越好，而且也能夠讓我們的專案越來越快速。

並且針對專案的特性協調和分類工程師，不要浪費每一次犯錯的機會。

基礎架構

在我們為所有人都找到領域後，平日的工作還是要做的，基礎架構會是所有人都會用到的，也看得懂的專案模板，一個 FID 可以有多個專案模板。

針對不同的情境和需求，我們可以設計出不同的專案模板。

但有一些模板是針對不同的技術，例如：

• JAMStack，由於技術選型的問題，我們可以設計出一個 JAMStack 的專案模板，並只能用特定的技術來開發
• React 專案，可以是以 Next 為基礎，或是以 Gatsby 為基礎，或是以 Create React App 為基礎，都是可以的（當然也可以自己設計），而我是用 Next
• 或其他特定語言的模板

這個基礎架構最大作用，就是為了大大降低大家開發新專案時的成本，並將成本轉移到真正值得研究的地方上。

總結

以上是一個 FID 中會涉及到的「角色」，但是這些角色並不是一成不變的，而是會隨著組織的成長而改變，所以我們要隨時注意組織的成長，他們分別是

• 主導者
• 主要設計者
• 參與者
• 執行專案的工程師
• 基礎架構（需要有個人負責設計，並且維護）
• KM（需要有個人負責統籌和整理，並且維護）

而且這樣的組織架構，也有一些風險。

這樣子的運作是存在不確定性的，尤其是在一開始建立的時候，這些不確定性會讓人感到不安，尤其是在一開始的時候，我們會遇到很多問題，而且這些問題都是我們沒有遇過的，所以我們會覺得很不安和不確定，但是這些都是正常的，只要我們能夠堅持下去，就會看到成果。

所以安排在這些領域的人（尤其是主設計者），都必須有一定的抗壓性和人格特質。