讓誰參與團隊

在本章中，我們將探討開始時讓你的團隊邁向成功之路的最佳方法。我們討論的不是工具，而是誰將成為這個團隊的一員。不用擔心，你無需解僱或替換任何人；不過，你必須在目前專業知識不足的新領域培養專業知識。

我們將提供兩種主要方法：圍繞專家建構或發揮內部專業知識。我們還將討論遠距團隊的主題。

無論情況如何，一個寶貴的建議是：從優先考慮那些樂於且渴望學習新科技（本例中為 Erlang）的人開始。你無法強迫人們違背意願學習，但你可以協助自願學習的人。

圍繞專家建構

要獲得新科技或新事業領域的專業知識，最簡單的方法通常是聘雇擁有該專業知識的人。遺憾的是，這永遠無法真正解決你的問題；你得依賴你的專家處理所有事情。這最終會造成系統中所有變更的瓶頸，而在你的專家請假時導致大幅度延誤。

撰寫本文時，業界的平均任職期間低於 5 年。這表示，一個希望持續經營的團隊將會不斷聘雇專家，而且看不到盡頭。秘訣是在找到第一個專家後，培訓你自己的專家。我們認為，公司持續聘雇較資淺的員工，然後隨著歲月流逝看著他們變成專家離開公司，會比總是挖角專家和高階員工然後眼睜睜看著他們離開要更為健康。

在此絕無誤解，我們並非反對專業知識。我們主張應支持專業知識：專業知識如此重要，職務機關應專注於自行培養專業知識。凡無法提供助其員工成長的環境之單位，將任憑其競爭對手為其培養。因此，圍繞專業人才進行建構，表示該位專業人才便是建構團隊其他成員的夥伴。事實上，團隊的其他成員也應了解這一點，以便他們能調整心態，並確保能盡可能善加利用專家。

這應為他們充分了解的角色，而你應不時與他們討論。預期是，你應讓你的專業人才和組織中對於學習 Erlang 最熱心的員工組成小組，從小處開始。在最初幾週，你的專業人才的角色主要是提供你的員工投入工作所需的基礎知識。這通常會遵循大多數入門書籍的模式：基本語法和資料類型，教授遞迴和撰寫小型模組，示範如何測試其程式碼，然後陸續加入多重處理和 OTP 行為。

一旦團隊開始有信心具備基礎知識，你就可以讓你的員工開始著手開發你希望他們撰寫和長期維護的系統的第一個原型。一個有趣的做法是將第一個原型實際上用作培訓設置，而不是別的。所有參與者都知道原型並非用於生產，而且如果實際上用於生產，藍圖上的第一件事項就是在你擁有適當經驗後予以更換。

然而，原型很重要；透過選取他們熟悉的相關問題，這將成為一個測試環境，讓你的員工能夠自由地進行實驗，以便熟悉程式語言及其特性。這讓他們得以回顧其領域知識並教導專業人才，而專業人才會與他們合作，找出他們如何在 Erlang 的架構和語意中重新架構他們所知道的知識。這有望在他們之間建立融洽關係和默契，而兩者的關係會從「訓練者和受訓者」轉變為許多人彼此教授知識的關係。

在建立原型期間，你的專業人才應開始引導你的團隊探討更廣泛且複雜的概念：為容錯性開發（如何適當地建立監控樹狀結構？）、建置和部署 OTP 版本，以及最後是與效能相關性及生產除錯相關的疑慮。

我們最喜歡的實驗之一就是讓專業人才指導團隊建置自己的監控結構，理想上是利用團隊已開發的原型

1. 從團隊已識別的各個組成部分（網路伺服器、連線處理器、編碼器/解碼器、組態管理員等）開始，並將它們繪製在白板上
2. 繪製組成部分之間的通訊管道。強調傳遞訊息或進行網路通訊的各個位置。
3. 對每個通訊管道提問「這是我們預期經常會失敗的事嗎？當它發生時會怎樣？」讓團隊意識到系統中潛在的故障
4. 對於每個故障，提問每個組件持有的狀態會發生什麼事。是否為暫時性的？是否允許取消？是否能從某處重新建立或擷取？
5. 在可能會失敗的組件上面插入監督程式，並假設在每次故障之後，每個組件均從可預測的非動態狀態開始（由監督程式傳遞的初始引數）
6. 重複修改組件並重新架構它們；將無法承受損失的狀態移出失敗預見性更高的方塊，並思考在每次重新啟動時資訊如何傳輸到那裡。

我們在這裡見識到對 Erlang 最多的「啟發」。該團隊突然了解到，他們已經累積了足夠的了解，可以重新建構和重新架構他們設計軟體的整體方法。他們開始使用 Erlang 虛擬機器和 OTP 架構的獨特功能，並以不同的方式建構，利用新的可能性。即使部分開發人員退出 Erlang 訓練，並回到他們之前的工作中，他們很有可能會運用他們在架構事物的方法的經驗，並於舊的地方套用它。我們聽過有人這麼做，並且說他們在嘗試了那一種方法之後，對其 C#、Go，甚至 Ruby 設計有了不同的想法。

一旦你認為他們懂了，請要求整個團隊重新設計原型，使用他們現在知道的內容。他們可能可以保留一些組件並重新使用它們，但對於捨棄許多其它的組件，他們不必感到不好意思，你也不必：你會重新撰寫一件由幾乎是完全的新手撰寫的東西，變成由有某程度經驗的人所撰寫的東西。回顧過往，很有趣地將他們在原型中的工作，與最終的真實產品相比較。

執行完整的學習實驗可能需要幾個月，但即使經過幾週，你可能會看到你的部分非專家員工的信心逐漸增強，然後開始幫助他人。你的專家知道你希望他的專業知識廣泛流傳，因此應該實際上鼓勵這種行為，並開始在較基礎的問題上進行委派。然後，轉變為更成熟和有功能的團隊就會發生。人們會相互傳授各種主題；你的專家的專業知識會越來越不必要——大概只會在越來越難得的棘手問題上才需要——他們就能有空以更平等的方式參與專案，或開始轉移到你其他團隊，同時也希望採用該技術。

沒有專家的情況下進行建置

沒有專家的情況下進行建置絕對有點棘手。這並非不可能（有些人必須自己成為專家才能開始），並且有許多資源可用，包括書籍、會談、論壇、聊天室等，但這絕對更具挑戰性，成本也可能更高。沒有專家的情況下進行建置最大的風險在於，您可能不知道將在錯誤的路徑和壞的途徑上花費多長時間，而且您早期所做的錯誤學習可能會持續更長的時間。

這最終與常規開發並無太大不同，但您將心甘情願地朝那條路前進。因此，您可能想要以稍微不同的方式來架構事物。與其選擇一名專家和您充滿熱情的團隊成員，您將希望將需求和角色分配給所有人，嘗試獲得專家原本會促成的動力。

找出對函數式語言有先前知識的人，他們不可能知道一切，但他們已經領先一步。另外，找出一些自學者，他們喜歡坐下來深入探究某件事物。他們的任務是在幾週前閱讀書籍並找出各項事物，他們實際上就像只領先您幾週的鋼琴老師。您將希望找到樂於教學、撰寫文件或準備示範的人。這通常很難，因此如果您找不到任何人，請指派一個輪值時間表來承擔此項責任。讓他們負責進行更廣泛的資訊傳播、維護文件，以及快速「入門」來了解您在組織中所做的工作。

讓每個人進行一些開發並習慣語言的感覺，參與社群中的事物，並運用現有的程式碼。以下是幾個點子

• 深入了解現有程式碼，並展示說明各種函式庫及其方法，深入了解它們的結構方式。
• 如果您無法找出開源函式庫執行其工作的理由，歡迎在問題中詢問其作者，或詢問 Slack、郵寄清單或論壇上的人員。取得真正的答案，並將其顯示出來
• 對你所寫的程式碼進行程式碼審查，其中主要目的是一起討論你們（到目前為止）未達成共識的事情。這可能包括語法和對齊，但更可能會包括像你要記錄多少，你希望對哪些更好的測試方法的正規化，等等。
• 當你遇到難題時，快速聊天以找出哪些方法可以解決問題，你將如何進行實驗，以及最後找出如何做出決定的方法。
• 做實驗報告；如果團隊中的幾個人處理了一些棘手的問題，讓他們報告並與其他人分享他們的經驗。

你還需要在網路上請人幫忙。答案可能很慢，但最終還是可以得到。StackOverflow 還不錯，但從未真正管理過一個 Erlang 社群。更多互動領域（slack、IRC、寄送清單、論壇）有較長時間的會員資格，能更好地找出你實際需要。記住，對於某項技術的新手永遠有遭受XY 問題的風險，你的團隊也是如此。

如果你遇到問題，很難克服，或者覺得你需要的專家協助你確保你走在正確的道路上，另一種選擇可能是聘請顧問或諮詢公司一到兩個星期，回答你最大的問題，並幫助解決你最明顯的問題，這可能比找專家和聘用他們容易一些。

遠距或不遠距

Erlang 和其社群的問題是在，總是有人求職多於招募人力的人，而在同一時間也有招募人手卻找不到員工的人。這基本上是因為 Erlang 開發人員和 Erlang 公司的地理分佈不一定是相同的。想要找 Erlang 工作的人和想要找 Erlang 開發人員的人通常不會在同時間出現在同一個地方。

尋找遠端工作者意味著更輕鬆地找到專家或熟練的 Erlang 工程師，而且他們將能夠利用自己的網路引入更多人力。不過，這確實伴隨著習慣的改變，在 2020 年全球 COVID-19 大流行之後，大多數科技公司可能會嘗試一段時間。

因此，在這方面的最終選擇將來自你管理團隊的偏好；直接可用性可能會促使你聘用遠端工作者，更快速地為你的團隊增加專業知識；世界上大多數地方都沒有準備好的 Erlang 專家等著在他們的在地市場為他們工作。讓市場外的人快速幫助你可能會節省大量時間和成本，特別是在比較在沒有直接幫助的情況下從頭開始進行所有事情和培養自己的公司內專業知識的替代方案時。

此類省錢之道可能會改變團隊的工作方式與溝通方式。如果您目前沒有進行遠距或分散式工作，而且您的專家將是唯一一個遠距人員，這也代表您專家的挑戰；身為團隊中唯一的遠距人員可能會特別孤單，而要讓他們保持快樂可能會變得很複雜。

接下來

因此，我們已大致說明了如何進行，以及在專家的協助下或未經其協助開始工作時如何規劃工作。無論如何，請專注於團隊學習、訓練和成長。這是一個健康的模式，而且無論您是遠距或全都在場，它都是健康的。

針對這些大綱，我們可以開始探討您無論採用哪一種方法，都會想要執行的流程和實務。