上個月敏捷聚會舉行了一場 Lean Coffee，讓大家體驗共同決定想要探討的敏捷開發的主題並且參與對話。在討論的過程中，大家談到一個在敏捷開發過程中常見的困擾，那就是 scrum 的敏捷方法需要跨功能團隊，但當團隊成員並非具備跨領域的技能時該怎麼辦呢？大家針對這個問題談到如何讓成員學習成長的解決方法。
Jack Yen 表示他會向團隊成員傳達主動學習成長的觀念，建議成員多利用空閒時間充實技能，而不要成為團隊的累贅。不過他說大部分的工程師在技術或專業上多半不會有太大的問題，比較麻煩的是專案的經驗和領域知識，這部分還是要在實務上多磨鍊才會慢慢熟悉。新科 PMP 志豪老哥也提到要讓成員 OJT（on job training）來邊做邊學。David Ko 則是補充他的經驗，他會表達每一位成員都要懂每一種技能的觀念；然而當成員真的碰到技能上的問題時，應該要引導成員去學習，不過必須要讓成員自己親自動手。
大家的討論圍繞在團隊如何提供學習成長的機會；假如團隊成員每一個人都能在各方面領域有夠水準的表現，那麼團隊必然會有高效能的產出。不過同人在過去的軟體專案開發經驗中體驗到，讓成員學習成長是一條艱辛且漫長的路，領導者必須有耐心提供更多的時間和空間來促進成員的學習成長，否則很容易適得其反。這讓同人想到從另一種觀點去思考跨領域團隊的問題，我認為也許不是期待成員具備跨領域的技能，而是運用限制理論的觀點來突破團隊效能的瓶頸。
David Ko 在〈實施 agile 一定要多技能團隊嗎？〉提到多技能團隊的好處：
在敏捷的團隊中，他提倡 feature team，就是希望會這個專案所需要的技能的人都在（cross functional），並且他們會的不止一項技能（multiple skills）。 這樣做可以帶來以下好處：
- 資源調度容易：會的人比較多，比較容易做工作分配。
- 團隊互助支援：萬一有人請假或是離職，要找到支援的人比較有可能。
- 容易對系統架構作調整：因為大家對系統每個部分了解比較多，所以在談論系統如何重構時，比較能提出建言。
- 開發速度比較快：在調度容易的狀況下，開發時就減少一定要等誰做完的機率，自然會比較快。
本來團隊的產生就是開發組織因應專案所需而組成的任務編制，它通常需要跨領域的多技能以解決實際上可能發生的複雜問題。然而現實問題是，團隊成員來自組織的各單位，自然會比較熟悉他們所屬單位的角色型文化，而比較不熟悉團隊需要以解決問題導向的任務型文化，而且他們通常不容易在短時間內訓練出具備多技能的專業。除非成員們曾經在類似的專案中合作多次，但這個機會並不會太多，因為專案本身具有臨時性和獨特性的本質。因此，團隊的實際狀況通常是多技能團隊但成員不見得具有多技能。
其實成員彼此之間存在差異，團隊具備多樣性反而有助於發揮綜效。綜效的意味在於一位成員的輸出可以成為另一位成員的輸入，而不是每位成員都重覆在做相同的開發工作，這樣會造成資源浪費與增加發生錯誤的機會。當然，如果團隊成員都具有足夠水準的多技能實力時，通常不用擔心資源浪費和人為錯誤的發生，因為熟練的技能和經驗可以克服這些問題。然而，當成員經驗不足時，會很容易因為跨多技能的分心以及缺少溝通使他們因為不明究理而犯錯，因此應該思考如何讓具有不同技能的人能夠適當地分工合作以發揮整體效能。
由此來看，有兩種途徑可以達成多技能團隊。假如團隊成員每個人的多技能都達到一定的標準，也就是他們能力的標準差很小，代表成員沒有多技能實力的落差，那麼這正是以生管理論敏捷的原則來達到多技能團隊。但若是團對多技能是分散在不同成員身上，那就是團隊存在成員多樣性的特質，而透過不同角色的互動與合作，而增加團隊績效的總平均，而沒有因為彼此差異而浪費資源，則正是以生管理論精實的原則來達到多技能團隊。
因此，即使團隊並不是每一位成員都具備多技能，我們還是可能讓每一位成員都能為團隊盡一份心力。當然成員具備多技能有很多好處，但沒辦法勝任多技能工作的人仍舊可以讓他們做那些他可以表現得比做其它工作要更好的工作。前者運用絕對優勢來降低生產成本，而後者則是運用比較優勢降低機會成本。就像同人在〈成員能力優勢與團隊多樣性〉這篇文章提及團隊合作正是基於讓人們從事比較優勢的工作，然後再進行交易；只要存在比較優勢，進行分工合作對於擴大生產就是有利可圖的。相對優勢往往比絕對優勢會來得更重要：
依照團隊成員所具有的優勢，來進行分工，然後再將其工作產出加以整合，就能夠擴大團隊合作的效益。當然，在團隊之中，絕對優勢是最容易被看到而加以利用，但考量機會成本的損失，團隊合作應該重視比較優勢更勝於絕對優勢。
不過，重視比較優勢並不是非得採行讓資深的人設計，然後讓資淺的人按圖施工的做法。雖然這樣做可以節省資深人員的時間，讓他們有時間去做更重要的設計工作，但這樣的短期利益可能會造成較為資淺的成員沒有學習成長機會的長期痛苦。而且設計的人不寫程式很容易因為沒有驗證設計而造成品質上的瑕疵，當資淺成員發現設計有問題時，資深人員可能會因為卡在重要核心元件的設計而無法協助他們解決。通常這時候資淺人員會不知道該怎麼辦；他有時間可以去做別的工作，但卻沒辦法解決整個開發系統阻塞的狀況，最關鍵的地方就在於資深人員變成受限制的共用資源，在這種情況下資淺人員的學習成長往往是緩不濟急的。
因此，要突破團隊效能的瓶頸，同人的觀點是要先認團隊效能的瓶頸在那裡，然後在發生瓶頸的受限制資源身上，為它設計流程並給予緩衝來保護之，等到狀況改善了之後，再慢慢減少緩衝來放寬限制，但最重要的是我們不能讓人的惰性變系統的限制。也就是利用限制理論來突破團隊效能的瓶頸。
同人記得以前有一位長官花了很長的時間（大約二到三個月）設計一個系統核心的模組，但同人接手後發現有些問題需要他協助處理，但他需要趕上落後的進度，而且其他成員手上的工作都和他有關係，此外從客戶那邊回報系統嚴重的功能失常也需要他花時間解決。有一次我和一位高階管理者閒聊時，她問到我東西都卡在那位長官身上的問題要如何處理？當時同人就分享了限制理論的觀念，我說很多事卡在研發經理身上，那代表他是受限制的關鍵資源，會影響團隊的整體效能，即使其他人的效率再高也產出不了有價值的產品，而是產生更多在製品。因此，我們考慮的應該不是提升其他人的效率，那沒有什麼用，而是要如何設計緩衝來保護研發經理這個受限制資源，讓其他人配合受限制資源的應用。不過可惜她沒有辦法體會到同人所表達的觀念，後來管理高層對團隊效能所做的努力都未能突破瓶頸。
不知道 Jack Yen 還記不記得我上面故事提到團隊效能瓶頸不能突破的痛苦，同人當時剛好和他是同事，他是公司的 QA 經理。那天敏捷聚會同人提到限制理論的觀點時，Jack Yen 問我有沒有實例，我那時候隨口說沒有，但後來我想起來我曾經用 Kanban 帶 PG Team 的經驗正是一個實例。
當時我在 PG 的 trello 看板中為某些任務卡片 List 設定可容納卡片數量上限，用來進行 WIP 的管理。當我們發現某個作業階段的工作卡片到達上限時，就知道 PG 們有人的工作遭遇到困難或瓶頸，必須要立即設法處理，才能再處理其它新的任務；而不是找其它可以做的工作而做，把問題堆積等到最後再一併處理。雖然當時我帶領的 PG 團隊並不能算是多技能團隊，但我會利用 WIP 的觀念來要求 SA 先處理該驗測的功能，否則當待驗測的卡片滿了之後，PG 完成他們正在進行的工作時，就沒辦法再移卡片到待驗測階段給 SA 測試了，也就不允許 PG 開發後續功能，直到 SA 完成功能驗測為止。
其實同人很認同讓成員學習多重技能提昇團隊素質是很重要的一件事，過去我在為某個專案團隊導入 TDD、daily build、以及 formal inspection 等作法的時候也是希望成員可以透過這些活動來提升他們的技能。
只是有時候團隊的成員從組織的四面八方而來，他們有不同背景、習慣和資質常會為成員學習成長帶來一些挑戰，還有最累人的是專案經理會給你一個什麼都不懂的人，要你讓他 on job training。本來同人有提供了一份考題，可以讓他找到能力符合我們團隊需要的人才，但結果他並沒有使用那份考題。於是苦了同人和其他幾位負責帶領新人的同事，雖然羅馬不是一天造成的，但它不代表成員不需任何基礎，最後我們沒有把那位新人培養起來，最後公司只好把他調到其它專案。
因此成員學習多重技能可以使敏捷團隊發揮出高效能與高品質的產出，然而組織卻是需要為此付出一些代價的。當然以長遠來看，付出這些代價多半是值得的，然而如果組織高層並不想在這方面花費太多的成本時，其實我們還是有更簡單而低廉的方式來建立多技能團隊。我們可以朝向運用既有成員的比較優勢，以減少資源重覆投入的浪費，然後盡量把力氣花在具有效益的事情上，這樣運用精實開發的作法我們可以創造出團隊的綜效，這便可以突破團隊效能的瓶頸，更重要的是實現它的條件並不太高。
