如何建立信任關係 (軟體主管的31堂課)

一個好的主管，會讓其團隊成員高度信任，在軟體開發團隊中，如果主管可以有效地和團隊成員建立健康的信任關係，就容易達成三贏效果：對企業有利，對團隊有利，也對個人有利。相反的，如果團隊主管不受信任，那麼組織內部就容易內耗，很容易就形成三輸的情況。普通的團隊則是部分成員信任團隊主管，部分則不太信任，主管意識到這點，其實是很有改善的機會。

何謂信任？

信任並不是說團隊成員要變成主管的莫逆之交，在危急的時候就算赴湯蹈火也都在所不辭。當然可以達到這點很好，但在企業團隊內是不太可能。所謂信任是指，團隊成員對主管決策方式以及最做事方式，有預期感，並能相信這樣的決策和做事方式，即便自己不了解，甚至不完全贊同，也願意有效的合作。

如何建立信任。有些事情對於建立信任的雖然有一點點幫助，但效果有限，例如典型的團康活動。有些事情則是對建立信任有決定的影響：

(一) 傾聽了解個別成員：

信任是「個人」心理狀態，因此，有效地傾聽個別成員在組織的需求，針對個別成員的需求，量身定做互動的方式。

傾聽的重點在於「傾聽」，中途插話，表達太多意見都不是傾聽的要訣。

(二) 共同接受並完成工作上的挑戰：

這和傳統軍隊建構團隊的方式雷同。一小組人一旦一起面對挑戰，並且度過挑戰，就容易互相信任。在經歷生死戰場的退伍軍人戰友，特別容易建立長期的信任關係，就是因為如此。
當然在企業環境大概不會有生死攸關的情況，但仍然有許多挑戰。好主管的要務在於對挑戰的本身必須要是正面看待，

例如：在跨國企業中研發團隊總是對某國家的另一些工程師作法相當不認同，並常在討論中發生意見衝突。團隊常常對主管抱怨狀況。不適任的主管在此最容易做的事，就是一起跟著抱怨，並且將責任歸於其他人，試圖在團隊塑造共同敵人，這樣短期團隊成員或許會開心，但是衝突並不會因此解決。一個好的主管，會將這狀況是為共同挑戰，讓團隊成員明白如果我們可以一起解決這樣的衝突，不但對組織有好處 - 可以讓跨國團隊更有效工作，對自己也有好處 - 在履歷表中就可以多一項很難得的成功經歷。

(三) 建立一致性：無論任何事情的好壞

建立一致性是在不公平的社會環境中，讓團隊成員認為主管會公平處理事情的最有效方式。所謂的一致性，倒不是指不能改變作法，而是指作法本身有可預期的一致性。

例如，在營運團隊中常常有假日需要輪值的情況，最簡單的方式是直接按照姓名或者到職日期，輪流安排成員在假日值班。表面上看起來是最最公平，實際上有可能是公平，但也有可能不公平，因為每個人上班期間的工作內容可能不同。一致性並不是說不應該輪流值班，而是指輪流值班的班表如何取得共識。例如，每次班表都是每3個月前產生，產生之後，會在兩週內先逐一詢問個別的需要，個人的需求被滿足後之後，在隨即email公布並詢問有沒有需要調整，並且在一週後正式啟用此輪班表。幾次之後，團隊成員對主管的做事方法就有一致性，知道主管在困難事項一定會先詢問個人，調整每個人狀況，還會在所有人面前再度公佈一次，然後再做最後調整。

這樣一次一次建立一致性，無論事情的好與壞，也無論主管個性，就容易建構工作上的信任關係。

軟體工程師的職稱頭銜重要嗎？

軟體工程師根據所在的環境不同，通常有不同的職稱頭銜。例如：程式設計師，工程師，技術經理，架構師，策劃工程師，平台工程師等等。對應於英文可能會有：programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中，升遷可能是職稱上的轉換，例如在前面加個「資深」，大家就都知道你被升遷了。

對於轉換新的工作來說，職稱頭銜是否重要呢？

1.以工作的本質來說不重要

就技術為主的軟體工程師來說，(假設並沒有直接負責管理員工)，職稱頭銜幾乎不重要，更重要的是做事情的內容和能力的展現。

假如在一個組織裡，一位新進員工的職稱是「sr architect資深架構師」，但他的工作內容實質上是對客戶提案，撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作，通常還是評估實際做的事情為主，並非職稱。

2.以團隊角度來說可能很重要

職稱是公開的，一個團隊組織裡如果有工程師，資深工程師，資深架構師這三種不同職稱的人：一般來說，大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟，職稱的功能有時候類似制服，當你在路上看到穿著警察制服的人，在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而，就軟體開發組織成長來說，職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係：團隊貢獻中，絕大部分的人會認為自己佔比重比較大，因而，在決定升遷或者其他公開獎勵時，一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中，大部分的人會認為自己佔比重比較大：許多實驗（參考這裡）都說明，假設一個團隊的總貢獻是100分，有10個人自己評估自己佔的比重，並且加總起來，很容易就超過150甚至250，但這實際上是不可能的。

也因為大部分的人都有這種偏誤，導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會，可以採用「無職稱」或者「自選職稱」的方式。

3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時，無論是中期還是短期發展，組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織，對團隊成員，甚至對組織外的人都有好處：

- 對組織的優勢

在組織內，成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」，而非「職稱頭銜」決定自己「做出的事情」。自然而言，團隊成員就會以提高自己的能力和對組織的影響力，並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密，再也不會影響其他人的心情。

當組織要招募人才時，組織會更專注於了解應徵者「過去做的事情」，而不是過去有的頭銜職稱。過去我們面試的時候，常常在履歷表中看到非常驚人的頭銜，但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高，錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時，在他對外面試的時候，很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明，團隊成員專注於工作的本身而非頭銜的表面公平性不足時，更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時，更容易專注於尋找人才得要件。換言之，本來評估能力和是不是適合，本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試，就更容易避免錯誤。

如何組成團隊：三個步驟

分工合作，是人類社會進步的主要原因之一，也是幾乎所有人類活動的基礎（參見國富論：第一篇第一章論分工）

新創公司，資訊產業也不例外，建立一個好的團隊，是擴展未來的主要關鍵。雖然好的團隊沒辦法保證生意蒸蒸日上，一切順心如意。但是一個糟糕的團隊，卻是可以保證企業和組織的失敗指日可待。


市面上團隊合作的企管叢書，方法論，激勵理論，顧問大師...很多。但就和所有的事情一樣，越是很多人在談論的事情，越是困難。成功的團隊真實例子極為罕見。

萬事起頭難，「組織並成立團隊」是達到成功團隊的第一要務。許多人常依賴運氣，或者隨遇而安的隨意組成團隊，但其實組織團隊是一種可以學習的艱深技術能力。

資訊相關工作的人，如果有機會能扮演組成團隊的角色，並有意識的學習其中，將會是個人成長的重要關鍵。（無論未來是朝純技術領導方向前進，抑或管理方向前進）


有很多原因，會讓一個人扮演組織團隊的角色。也許是一個新的專案，讓你來領導專案，而恰巧專案開始的時候沒有既定的人。也許你是新創企業的創始人，你打算聚集一些人來開發創新事業。也許你是資訊相關科系的學生，因為課程需要必須組織團隊完成專案。

不管如何，如果你有「從頭開始找人選人，組織團隊，完成某件事情的機會」，請衷心的痛哭流涕的感謝上帝，這樣的經驗，在資訊科技領域裡是十分難得。

通常，由於各種背景壓力，組成團隊的方式通常就是先根據需要N個人，然後「儘速」透過各種管道，找到可能的人選，經過正式面試，或者非正式的聊天，就逐一邀入加入此團隊。這種方式沒有不妥，只是這樣的方式（如果算是一種方式的話）有很大的成分依賴運氣。如果不想依賴運氣，其實需要考慮的實務步驟也不多。


以資訊相關工作為例，組成團隊必須要有以下三個步驟：

步驟一：定義目標

--- Your goal shouldn't be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs.   (MoneyBall)

定義目標，必須要在團隊開始組成之前，就先找到並且定義完成...最起碼是團隊差不多組成的時候就應該決定。

定義目標並不容易。

例如，以類似的資訊系統外包案而言，有些明顯的目標是「在成本內完成專案並驗收通過」或者「在期限內通過驗收」。但是，倘若一開始的合約是低價得標，而且還是業務亂搶合約，那麼一開始就已經知道不可能在時間成本內驗收通過。則團隊目標必須要轉換，例如「完成專案過程可順便完成重複利用的元件讓未來標案能大幅降低成本」。

大部分的資訊團隊真正的目標並非「技術達成」。例如，「完成iOS APP線上購物」這通常不是真正目標，真正目標通常是「在某移動通訊市場上，讓使用者可以線上購物」。

在營利企業裡，大部分的真正目標通常關聯到增加收入或者降低成本。而在非營利企業（例如研究單位）團隊的目標有可能非常模糊。例如，一個碩士班的實驗室團隊，他的目標可能是「培養人才」，也可能是「讓主持的教授獲得升遷的點數」。

定義目標雖然不容易，但掌握以下三點可以除去大部分的誤差：

(1) 定義目標後，審視檢查這個目標背後是否還有目標。例如，籃球比賽目標，某球員目標是得30分。但其背後還有個目標就是球隊要贏球。在球隊沒贏球的情況下得30分可能沒有意義。

(2) 定義目標後，檢視此目標是否只是某個大目標的一小部分。例如，某些NBA的球隊，會談論是進入季後賽的目標，然而背後的大目標其實應該是拿到總冠軍 - 無論有多艱難。

(3) 定義目標後，檢視此目標是否因為其他條件未達成就失去意義？這時候所謂「其他條件」或許可能是目標。例如，一個團隊負責營運線上購物網站，其目標是「網站每分鐘必須可以提供10萬個使用者同時進行交易，7x24服務不中斷不當機」。然而，若此線上交易網站平均上線交易人數每分鐘才1人，即便營運團隊達到技術目標，商業目標肯定無法達成，則此團隊目標也沒有太大意義。不如改成「與業務團隊合作線上行銷活動，讓每分鐘平均交易人數成長XX%」

步驟二：組合優勢

--- The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour. - (Adam Smith)

無論用什麼方式找到團隊成員，資訊相關的團隊必然有分工，而分工必須要能讓成員發揮相對優勢。而每個相對優勢，都可以達到步驟一的目標之一。

構成團隊過程可能很多，但無非是找到某人，詢問意見，在某時間此人加入。然而，「加入之後做什麼」著重於考慮組合優勢。

台灣經濟學的入門書通常會用蓋木屋與磚屋的例子（參見這裡）簡單的說，組織團隊時，把成員的時間投入在相對優勢的工作上，可以達到1+1>2的效果。

實務上，分工時請考慮一下三點：

(1) 根據相對優勢來分工：盡量只考慮優勢，而不是先考慮缺點。

(2) 分工的結果，還是必須朝「真正目標」前進

(3) 整個團隊需要了解分工與分派任務的原因 

步驟三：產生運轉動能

--- All things are difficult before they are easy.


團隊組織完成，要開始運作，不會像籃球比賽一樣，十個人在場上，裁判吹哨跳球就開始。

團隊前進需要累積動能。就像騎腳踏車一樣，從靜止到穩定前進，會花比較多力氣，然而一旦穩定前進，就很輕鬆。

產生動能指的是團隊成員已經彼此合作，彼此鏈結工作，發生問題也可以彼此協調解決。

以資訊科技為例：

最常見也是最糟糕的產生動能方法是由專案經理透過一連串的方式 - 通常就是開會 - 持續讓事情前進。團隊成員花在正式會議上的時間比例只要超過10%(也就是每週超過4小時)就屬於這種類型。


最佳，但是最罕見的產生動能的方式是由每個團隊成員，透過自身的判斷，做會讓事情前進的動作。類似足球或者美式足球的比賽。在資訊科技團隊中，這種組合需要時間磨合成員，而且也須一點點運氣，讓團隊的成員大部分的能力都可以足以某種程度的獨當一面。

如果你剛好是資訊科技/軟體開發的團隊領導者，至少要先避免最差方式，並且透過你的領導能力，讓團隊慢慢的朝向最佳的方式前進。

實務上有三個重點方式：

(1) 資訊透明：讓所有進行的事情透明的讓所有人取得。要注意，資訊透明指的是針對確定的事實透明。非確定的事實就是所謂謠言，要緊記：謠言止於智者，起於智障！

(2) Scrum中的豬雞原則：請參考這裡。在組織產生動能過程，豬負責的事情就由豬來決定，雞只是提供參考意見。

(3) 檢討 retrospective：需要團隊自我檢討任何不正確或可以強化的地方，檢討並非開批鬥大會，目的在於讓團隊能更有效率的，以及確保團隊真的朝向目標前進。