在我們老家那裡有一句老話叫做，「魚唔過塘唔會肥」這是一句粵語，中文的意思是「魚不過塘不會胖」，意思用來比喻，人不經歷些什麼不會成長的意思。
如果我們是一個戰隊，我們跟你合作的就是隊友，技術儲備中的人才就是我們的後備軍，我們的目標是要讓每一個人都能夠成長，成為一個優秀的隊友，成為一個優秀的後備軍。
但前面好幾章節，我都提及，是「專案」依賴於「系統」的狀態，而不是「專案」依賴於「人」，既然如此，又為何要花時間去培養技術儲備的人才呢？
確實，我們需要準備很多「儲備」來應對各種變化，但不意味著我們可以放棄培養人才，反過來看，人才和團隊是一個相輔相成的關係，如果沒有優秀的人才，就不會有優秀的技術回饋給團隊，這樣團隊就不會有成長。
所以在技術儲備中的人才這個章節，如何管理和培養技術儲備的人才，也是我們要討論的重點。
對於這個話題，我們有以下幾個重點：
在我們的團隊中，我們會設計一個容錯的工作環境，讓每一個人都能夠在這個環境中，不斷的犯錯，並且從錯誤中學習。
而這個錯，也必須是「主導者」和「主要設計者」所能預計的錯誤，並知道如何去解決這個錯誤，再另外一個層面，我們更間接的讓每個人可以發揮自己的創意和想像力去解決問題，因為就算是「主導者」和「主要設計者」，他們的觀點也不一定完全正確的。
當有參與者找到或是發現一個問題，並找到和設計出解決方法，我們要讓他們去實作，並且在實作的過程中，不斷的犯錯，然後得出最佳的解決方案，這個結果馬上就會反饋給團隊，讓每一個人都能夠從這個過程中學習。
容錯，是一個很重要的環節，也是我認為大部分領導人缺乏的一個環節，因為他們總是希望一切都是完美的，但事實上，完美的事情是不存在的，所以我們必須要讓每一個人都能夠在容錯的環境中，不斷的犯錯，並習慣的犯錯然後糾正，這反而讓大家正視錯誤，而不會因為害怕犯錯而選擇不做事情。
繼承上一個問題，回饋機制有 2 個面向，一個是內部，一個是外部，內部的回饋機制，就是我們要有一個可以互相得知和討論的管道，將資訊傳遞給團隊，讓每一個人都能夠知道，這個問題是如何發生的，以及如何解決的，讓大家知道「我們現在有什麼能力了」
第二個外部的回饋機制，就是當我們和其他團隊協作的時候，對其他而言，我們是封閉的，我們需要有一個統一的窗口和管道收集並分析資訊，將外部的訊息帶回來團隊。
接著這種資訊的流動，能更快讓團隊的研究方向和目的更清晰，並和外部的團隊更有效的溝通，減少溝通成本。
在我們關於角色的討論中，我們提到，我們的團隊中，有「主導者」和「主要設計者」以及「參與者」，這些角色的分工，就是為了讓每一個人都能夠在自己的能力範圍內，做到最好，並且在這個過程中，不斷的犯錯，並且糾正，這樣的過程，就是漸進式成功。
所以我們分派的任務，必須是有難度，但又不會太難，讓每一個人都能夠在這個過程中，不斷地思考，研究和發現，內化這個過程。
你可能會發現，這個作法和「已知問題，並告訴你標準答案」的作法有矛盾的地方。
舉一個例子，我們的團隊中，有一個參與者，他的工作是寫一個表單，這個表單有三個欄位，輸入姓名，輸入電話，輸入地址，然後按下送出按鈕，就會將資料送到後端，然後後端會將資料存到資料庫中。
一開始他會這樣寫：
function submit() {
const name = document.getElementById("name").value;
const phone = document.getElementById("phone").value;
const address = document.getElementById("address").value;
const data = {
name,
phone,
address,
};
fetch("/api/submit", {
method: "POST",
body: JSON.stringify(data),
});
}
最後經過討論，我們發現，這樣的寫法，會有一個問題，就是如果使用者沒有輸入姓名，電話或是地址，就會送出空的資料，這樣的資料是不正確的，所以我們要加上一個檢查的邏輯，確保資料是正確的，並且如果 fetch 失敗，要有一個錯誤處理的邏輯。
async function submit() {
const nameInput = document.getElementById("name");
const phoneInput = document.getElementById("phone");
const addressInput = document.getElementById("address");
const name = nameInput.value;
const phone = phoneInput.value;
const address = addressInput.value;
if (!name || !phone || !address) {
alert("請輸入完整資料");
return;
}
const data = {
name,
phone,
address,
};
try {
const response = await fetch("/api/submit", {
method: "POST",
body: JSON.stringify(data),
headers: {
"Content-Type": "application/json",
},
});
if (response.ok) {
// 请求成功的处理逻辑
} else {
// 处理请求失败的情况
console.error("提交失败");
}
} catch (error) {
console.error("发生错误:", error);
}
}
經過一次前後比較，參與者會對這個問題有更深的理解，並且知道如何去解決這個問題，記憶深刻，因為那不是一個標準答案，而是他自己經過思考和研究後，得出的結論。
當然這只是一個舉例說明，在過去，也有人會對於這樣的過程有疑問，「為什麼不直接告訴他標準答案，而要讓他自己去思考和研究呢？」
而在這裡我會建議，如果你是「主導者」，可以在一開始的時候，不需要表示出「我自己知道答案了，但是你還是要自己想一下」的態度，而是可以和他一起討論，並且在討論的過程中，引導他思考，並且在他思考的過程中，給予一些提示，讓他自己去思考。
專案總有難易度之分，實作就是最好的練習，與其將專案當作一個負擔，何不轉換成一個機會，讓每個人在專案中實際體會到「業務」的運作和多邊，並將這些經驗累積起來。
「主導者」在這裡需要做一個支配的角色，也就是每一個專案，都不能一開始就直接分配下去，必須先由主導者來評估，這個專案是否適合這個人，如果不適合，就要找一個適合的人來做，這樣才能確保每一個人都能夠在這個專案中，有所收穫，除了這些因素因為，主導者還需要知道：
團隊的建立，不是一個短期的計畫，而是一個長期的計畫，更不能操之過急，以免適得其反，因為這是一個需要時間的過程，所以我們必須要有耐心，並且在這個過程中，不斷的調整，讓每一個人都能夠在這個過程中，漸漸掌握節奏和方向。
隨說這個過程緩慢，但也會因為每個人的程度不同，會產生不同的心智改變，有些人會覺得沒有壓力，一切還好；有些人會感覺到壓力，但是他們會想辦法去解決；有些人會感覺到壓力，但是他們會選擇逃避。
拿捏的力度和份量，就是主導者需要考量的，如果太輕，就會讓每個人都覺得沒有壓力，一切還好；如果太重，就會讓每個人都覺得壓力太大，無法承受。
而我覺得每個人都應該有自己的強項和天賦，假設一個人在某個領域很強，但是在另一個領域很弱，我們應該要讓他在強項的領域中，發揮他的能力，並且在弱項的領域中，讓他去學習，當然首先要挖掘他到底在哪個領域很強，哪個領域很弱，這個過程，就是主導者需要做的事情。
最後我們需要讓每個參與者「有意識」到 FID 的存在，並「有意識」的去改變，這個過程，就是心智養成。
最後一個就是「過塘訓練」，不用去 google 了，那也是因為我從小時候那個俚語演化而來的，在這個過程中，有些人會完成過塘，有些人會無法，但是我們不會因為這個過程而去評斷一個人的能力，而是會去評斷一個人的態度，因為這個過程，就是一個態度的養成。
我相信每個能夠成為軟體工程師的人，應該都不是笨蛋，每個人都是充滿著想法和創意的個體，但是在建構 FID 的初期，積極主動會是一個非常重要的態度，所以我們會在這個過程中，去觀察每個人的態度，而能力，就好像一個不會武功的人，但如果武器夠強，假以時日，也會變得很強。
iThome鐵人賽
看影片追技術