自我感覺良好的能力不足: 預防與解決之道

在軟體開發團隊的招募中，技術能力當然是不可或缺的一環。候選者如何自己評斷技術能力，也許和如何評估候選者的技術能力一樣重要！

換言之，謙虛的人比自我感覺良好的人，可能實質上的能力更好。這在「達克效應」中說明得十分清楚。

達克效應簡單的說：是指能力不足的人通常會高估自己的能力 無法正確判斷自己能力的不足。不過經過提高能力之後，是可以認知到過去能力不足的事實。
這個理論雖然廣為人知，但真正去證實的人很少，因為大家總是覺得很合理，

該論文研究分為四例，無論是哪個例子，結果都類似下圖(註1)

本圖取自論文：Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments

該圖是取自研究案例二，研究者讓所有受測者考一個邏輯考試，這邏輯考試取自於美國的法律學校入學考(LSAT)，主要看一個人的邏輯思考是否完整，有興趣可以參看這個網站。

當然考試不是重點，考完試之後，將結果分成四組人，最差的就是bottom，最好的是Top。所以在上圖中，很明顯bottom組的結果當然是在最下方。但有趣的是在於，最爛的一組，在預測自己的成績與能力，卻是和實際上差距很大！次佳組(3rd)其實實際成績和自我預測最接近。而成績最好的那組，反而感覺非常「謙虛」！？是唯一反而預測自己考得不好，同時也自覺的不好的一組。但實際上考的成績卻是最好的。

研究有四個案例，考試的範圍跟內容各有不同但結果很一致。

這篇論文，雖然很直觀，但寫得有點幽默，所以竟然還得了搞笑諾貝爾獎，細想其實很有啟發性。尤其在組織中，員工的自我感覺良好是績效評估產生問題的最大因素之一，那麼在組織中有什麼樣的解決方式呢？

預防的方式：招募時的預防

尤其是軟體開發團隊，招募一個謙虛的人，比招募一個很有自信的人更容易找到真正有能力的人。倒不是說有自信是不對的，但自信心往往容易落入低能力的範圍（請參見上圖)。

要判斷自信與能力最簡單的方式有兩種：一者，就是根據過去實際的產出內容來衡量，例如詢問他過去工作中，實際上做了什麼事情，導致於貢獻的產生，而不是只問了貢獻的結果。其二，設定簡單的測試環境，例如直接在白板上討論演算法問題。

解決的方式：衡量產出而非能力

絕大部分的企業組織都知道，衡量員工的績效乃是基於產出，並非能力。當然，能力好的人自然有機會有更高的產出。

在軟體開發團隊中，衡量產出極其困難。每個團隊幾乎都因人而異。有幾個方式倒是可以適用於大部分的狀況 
(1) 員工自評，並且加上3位以上的同僚互評。
(2) code review
(3) quality

由於最近比較忙，關於產出的衡量有機會再寫。:)



------
註一:本圖擷取自該論文本身：https://pdfs.semanticscholar.org/e320/9ca64cbed9a441e55568797cbd3683cf7f8c.pdf

主管的責任：三件不能做的事情 (成為主管的31堂課)

作為用人主管，是帶領團隊前進的最重要的人。無論團隊是2個人還是200個人，主管應該對團隊的成敗擔負最大的責任。

企業內用人主管(people manager)是指的要直接負責員工的招募，任用，考核，薪資，工作指派，管理，領導，培訓以及資遣。

而現代化企業團隊本身的績效，最大影響因素其實不是某個別員工的能力與態度，團隊主管(領導者)才是最大影響。

無論團隊大或者小，也無論是什麼樣的團隊。團隊主管會大幅影響團隊合作(參考這裡)，也會大幅影響員工對團隊的參與感(參考這裡)，也會大幅影響個別員工的績效(參考這裡)。

簡而言之，團隊主管承擔大部分一半以上的成敗責任，如果是小規模的團隊，也就是團隊加主管成員為五人以下，團隊主管會承擔100%成敗責任。(參見這裡,這裡,這裡)

當然根據組織和工作任務的不同，主管有不同的事情該做。不過，有三件事情是管理上，一個現代企業的好主管，不能也不會做的事情：

(1) 將個人與團隊績效不好，歸為外在因素 
(2) 以情緒感受為先，事實為後
(3) 無法修正自己溝通方式，認為部屬難以溝通

1. 將個人與團隊績效不好，僅歸為外在因素或歸責於部分團隊成員 

當主管個人或者團隊績效不好，無論是業績數字不好，或者專案延誤，或者原定目標沒達成，當然是很多不同的原因導致。

然而，作為主管應該知道績效的大部分來源是「主管與主管的領導管理」，因此，績效不好，當然要先「檢討自己，以及自己管理與領導的方式」。

這並不是說，外在因素沒有影響。當然許許多多因素都會影響成效。然而，如果不是先檢討以及改變自己，作為用人主管，最容易落於「怪罪」

2. 以情緒感受為先，事實為後

某些主管大概參考了許多以「權力」為中心的書籍，例如：這本或者這本。又或許根據個人經驗，知道要說服別人，情感優先是非常重要的。因而在優通重要事情，或處理意外時，常常會以「情緒早於/優於事實」的方式進行。

最明顯的例子就是，團隊某些成員犯了錯，主管可能在第一時間會是說：「我很生氣，因為你做了某某某事情，後來某某結果發生」。

但合理的情況，應該是「某某結果發生了，是因為你做了某某某事情，因而我很生氣」

這並非在字句上的咬文嚼字，也不是探討主管的講話藝術。問題是在於主管本人內心深處事實的重視表達。

前者主管先重視的是「自己個人心情好惡」，其次是「團隊成員怎麼做事」，最後才是「那件事情的結果」。

只要幾次之後，團隊成員在工作進行上就有兩種可能。(a)成員在潛意識中，自然會認定主管是以情緒優先，知道自己無論績效能力好壞，最重要的是討老闆開心，對自己職涯不利，若有機會自然會儘速離開。(b) 成員不知道產出的標準為何，只知道主管的情緒標準。然而，情緒標準在現代化企業中難以作為成效指標，因而難以在結果上確切達到組織要的效果。 

(3) 無法修正自己溝通方式，認為部屬難以溝通

特別是在小團隊(少於五人)，主管與團隊成員的溝通好壞，並非取決於團隊成員，而是取決於主管本人。

主管認為某團隊成員難以溝通有幾種可能，但這些可能性都不是「難溝通」的理由，主管應該都能和任何部屬達到「工作期望的有效溝通」 

(a)：某成員是我招募進來，但怎麼講都很溝通：如果他真的這麼難溝通，表示招募選用對該主管來說是失敗的，換言之，責任仍然在主管身上。

(b)： 某成員不是我招募進來，怎麼講都很難溝通：主管擁有考核和解雇的權利。難以溝通的時候，應該以事實溝通成效，如果主管對自己有權限的屬下都難以溝通，更別說沒有權限的橫向單位。

當主管認為某屬下難溝通，最糟糕的做法恐怕就是在一對一面談時，坦然的溝通說：「我覺得你很難溝通」。因為這表示，主管在內心深處不能理解「溝通是雙向」的簡單事實。因而，很難溝通只能見裡在於「我們兩個很難互相溝通」的事情上。根本不可能建立在「我個人沒問題，是你很難溝通」的事實上。

和前段相同，這並非咬文嚼字，也不是認為用人主管是不會犯錯的聖人。而僅只是要說明，特別是擔任主管的時候，溝通絕非單向問題。必須要先認定問題所在，才能找到正確解答。

當主管認定溝通問題單存於對方，那麼問題鐵定無解，因為問題鎖定方式已經不正確。單只要求對方「改善溝通方式」，最好情況是對方改善了，但是自己沒改善，此問題還是會出現在其他部屬身上。造成主管認為自己的屬下統統難溝通，這種主管應該儘速被開除才是對組織最有貢獻的時候。

當主管認定溝通問題在於雙向，解答方法自然呼之欲出。有幾個方式可供參考：(a) 密集但是以事實為基礎的短溝通 (b) 盡可能使用精確直接而且短的溝通方式 (c) 建立互信關係用以輔佐溝通。 最近沒麼時間所以上述方式會在之後文章再說。

參考資料
(1) 自我感覺良好的認知能力不足

面試的前晚準備 - 極簡計畫書

無論你是社會新鮮人，還是職場打滾了十幾年的老鳥。當你準備要去工作面試的前一天晚上，有計畫性的準備面試，絕對比沒有任何準備來的好。

職場新鮮人自然會從網路或其他地方，獲得許多面試準備的要領，試圖做到面面俱到。然而，已經到了前一天晚上的話，要抱佛腳也應該要有正確的方向。例如，努力準備英文自我介紹，大概就不是一個前一天晚上能做的好方向 (註1)。

職場老鳥，即使已經是工作N年以上，應徵的是資深技術相關職位，在前一天晚上「提升技術能力」當然是不可能的。不過，卻可以準備好自己的強項，來增加面試成功的可能性。

某些資深職場老鳥，通常有「知我者伯樂，不知我是你的問題」，「良禽擇木而棲，這塊木頭反正也不好」的想法。這些想法不見得是錯的，然而，這不應該是「不做面試準備」的藉口。因為無論該公司好或者不好，既然要前往面試，你的唯一目的應該就是「被錄取」，而錄取之後，再來考慮要不要答應還不遲。

而面試前一天的準備，對資深技術人員來說，其實更簡單，並且也很容易讓面試方看得出你的資深價值。舉例來說，準備「要問」的問題，對資深老鳥就非常重要，這些問題的重點不在於獲得「解答」，而是在於讓面試者知道你的資深程度和專業性。

「面試前一天的準備 - 極簡計畫書」

與其說是計畫書，不如說是一個檢核清單，任何人應該可以在一個半小時之內，完成清單上的項目。按此索取極簡計畫書。

計畫書的目的是在面試前的晚上，約1.5小時之內，用合理的技術方式，盡可能提高自己既有能力的展現，藉此提高面試成功的可能性。 

使用步驟說明

(1)：找到組織背景資料。  [15分鐘]

在組織相關資料區塊中，填入公司組織名稱，代表人，營業額，毛利率等等可以找到的資料。

如果是營利組織，幾乎一定能透過名字或者統編，找到基本資料。非營利組織或者剛起步的新創事業，可能缺乏某些資料，但是可以將難以取得的資料當作「要問的問題」。因為，專業人士，通常會問出真正關鍵性問題。

(2). 要問的問題：   [35分鐘]

要準備問對方的問題。現在的面試，幾乎都會讓被面試者發問，而這段時間難能可貴。因為，這些問題是100%可以由自己控制，也就是說自己可以決定要問什麼，也可以決定不問。因此，面試前一天，反而應該花多一點點時間在準備「要問的問題」。

要問的問題的「真正目的」是要讓面試者認定你的能力和潛力，而不是你真的想要知道問題的答案。因此，最最最愚蠢的問題，莫過於詢問公司福利，社團活動，上下班時間，哪邊可以蒸便當，之類的無聊問題，這些問題，應該是透過人資或上網搜尋取得答案，而非浪費在寶貴面試時間上。

要問的問題至少要準備7-10題，而可以視面試情況決定要不要問。

基本問題像是：

• 如果我被錄取了，我在到職前3個月，要完成哪些具體工作內容？
• 目前這個職位，是因為有人離職而要找取代者，還是一個新職缺？此職位已經懸缺多久？
• 請問您如何評估一個人適不適合這個職位 
• 面試到目前為止，你覺得我是否適合此職位

至少必需要準備2-3個進階的技術性問題，技術問題並非指「特定的技術」，而是指「讓你側面了解更多」的問題。例如：

• 請問您會在這裡工作最主要的原因是什麼？
• 目前這個團隊，曾經遇到最大的障礙或困難是什麼？
• 請問您擔任這個團隊的主管已經多久了？

當然，進階技術問題通常比較敏感，在開口之前應該要客客氣氣的說「如果不方便講也沒關係」。

請在表格中，挑選要問的問題，並且在備用欄位，填入你自己想到的問題。

(3). 被問的問題：   [30分鐘]

面試者在面試的時候，手上一定會有你的履歷表。無論你之前對你的履歷表有多熟悉，在前一天晚上，應該再次看一下當初你寄出去給該公司HR的履歷表。

因為，要從中找到「以面試者的角度，認為需要在確認」的問題。並針對這些可能被問的問題，簡單準備一下解答。

技術專業性的問題，對於職場新鮮人，需要再次確認「真實性」，以免被人認為誇大能力。因為，職場新鮮人通常的確會「誇大」自己已經有的能力，例如其實只是在學校學過c語言，寫過幾個作業，通常就會把c語言當做「自己會的程式語言」，但是這和職場上的「會」可能有些差距。

而對於職場老鳥，只需要注意一下「曾經做過的事情」和「曾經有的貢獻」即可。

例如參與的研發團隊人數，自己扮演的角色等等。履歷表上的明顯缺陷，才是一定會被詢問的地方，例如某個工作僅做了6個月，或者在前一份工作到今天有3個月個空閒時間。

請根據表格，檢視履歷表，並且填入自己的模擬問題和可能的回答。

(4). 面試的時間地點交通方式與服裝。  [5分鐘]

聽起來很不可思議，不過確實有一定比例的人會過於緊張，太早或者太晚抵達。
也甚至有人壓根就忘記面試時間或地點。

前一天晚上應該確認一下面試時間或地點。

某些職位(業務單位等)可能對服裝有一定的考量，當然也得花一點點時間準備。

(5). 面試之後？

無論面試的好與壞，其結果一定要誠實的記錄在計畫書中，因為它可以作為自己下一次面試的參考。

結果只有分成兩種：錄取或者不錄取 - 無論原因為何。有些組織會考慮資深人員的面子問題，可能會用「目前組織人事凍結」等等軟性理由，不過對面試者來說，就只有錄取和不錄取兩種結果。

難以回答的問題：在這欄中，盡可能就自己的記憶，記下自己覺得難以回答的問題。如果是技術性問題，表示自己有技術需要加強。如果是其他問題，也應該記錄起來作為參考。

這個計劃書，應該自行根據面試的公司不同，做不同的調整。極簡計劃書僅是在你沒有更好的主意時，提供參考而已。


按此索取極簡計畫書。

---

註一：英文能力確實是許多工作的加分條件，但前一天晚上，臨時抱佛腳準備英文自我介紹，對英文本來就不好的人其實一點用都沒有，而對本來英文能力就已經很好的人，也幫助不大。

企業巫醫 - 向上管理的實務作為？

向上管理是個歷久不衰的名詞，它和「人格特質分析」「領導與管理」等名詞雷同，每隔一小段時間就會以各種形式，出現在企業巫醫們的討論中。

近期隨意查詢就可以找到不少相關文章： 向上管理(cheers雜誌)，如何讓老闆聽我的，反對老闆的六種方式，向上管理的四步驟 ......

「向上管理」向來是一個譁眾取寵的話題，眾多企業巫醫仍然以泛泛之談，試圖教導並解決一個現實而又務實的問題。

企業巫醫，總是能選定看似重要的無法辯駁，共通的話題，而且此類話題完全視個人情況而有截然不同的作為。因此，企業巫醫可以提出極端空洞的說詞，卻又多少讓人覺得有趣。除了「向上管理」之外，「創業」「創意」「領導與管理」「人格特質」等等都是屬於這類。

實務上，「向上管理」不能是打算進行的行為，而是產生貢獻中的其中一個結果。換言之，追逐向上管理，等於是捨本逐末的追逐影子行為。

因此，先務實地做到基本三件事情，假如踏實的做到了，向上管理就不是問題，而是附帶的結果。

1. 真正了解關於自己的現況事實

事實現況聽起來簡單，要找到也很簡單，但是要承認自己的現況事實其實有點難。

事實必須是清楚的，不模擬兩可的。例如，假設你是NBA球員，去年平均上場25分鐘，平均得分14分，這就是事實。至於你的技術能力好不好，並不是「事實」的一部分。以資訊科技的相關工作來說：參與過專案是事實，寫過java/python程式是事實，取得JSCP證照是事實，有Scrum證照是事實，帶領過開發團隊是事實，參與open source相關研討會是事實。

然而，具有良好溝通能力不算是一種事實，喜愛資訊科技不算是一種事實，

現況也必須是清楚的，不可能模糊。例如，目前薪資是現況，工作年資是現況，是否有直接report的人(也就是是否為管理者)是現況，最近一年有沒有拿到其他公司的offer也是現況，曾經拿到比現在薪水高的offer也是現況。

然而，覺得自己薪水被低估不是現況，覺得自己不受到重要不是事實，幾乎大部分的感受也都不是現況的一部份。

請參考這裡，這裡，這裡。

2. 讓自己的實際產出超乎期待 

二因子激勵理論，描述「保健因子」和「激勵因子」兩種個人激勵因素。而其實這也是務實的評斷自己工作的方式。請參考這裡。

要確定自己的產出超過期待，必須要確定產出有「超出」。

以基層程式設計師而言，在過去一年該寫的程式功能都有如期完成，並且品質在一定範圍之內。這樣的工作內容並沒有「超乎期待」，只是滿足「現在的薪水」而已。

要超乎期待的方式有很多。最容易的方式，是在目前工作範圍之外，「額外」並且「主動」完成有意義的事。例如，以基層程式設計師而言，在過去一年該寫的程式功能都有如期完成，並且品質在一定範圍之內，並且，主動地在額外的時間舉辦小規模研討會，分享工作上技術的進展。另一個例子，以基層程式設計師而言，在過去一年該寫的程式功能都有如期完成，並且品質在一定範圍之內，並且，由於主動學習其他程式語言，因此在其他專案上也能做額外貢獻。

3. 建立短中期職涯計畫並確實執行

在資訊科技產業中，實踐長期職涯規劃幾乎是不可能(註1)。

然而這並不代表自己現在就應該隨波逐流，看主管決定什麼就做什麼。個人應該要維持短中期的職涯規劃。特別是短期規劃。

短期規劃，必須要和技術能力以及現在工作有密切相關。

例如：

「作為一個程式設計師，未來8個禮拜，要能學會Scala基本用法，並且提出現在產品裡用Scala做分析的計畫」

「作為一個QA新鮮人，未來4周，要能將現在100個手動測試的case，至少其中20個變成自動化測試。同時，原本的工作也不會拖延」

中期計畫乃是半年到2年左右。必須要是「可以明白斷定達到與否」的目標。

例如：

「作為一個QA新鮮人，在2年內我想要變成資深QA，斷定是否為資深QA是以是否升遷或取得其他公司資深QA的offer」

當你完成數個短期計畫，通常表示你也踏實的逐步成長。即便有些短期目標沒有照時間完成，也沒關係，幾次之後，仍然是踏實往中期目標前進。

重點在於：這些目標是你自己決定的，並非主管或其他人硬塞給你。而目標既然和目前工作有關，自然就會協助你在工作上成長。


......
如果你非常非常確定已經完成以上三點，但覺得在這個組織中的成長仍有阻礙，還是很需要「向上管理」，用以獲得好的評價，獲得升遷？這基本上是不太需要，因為你應該儘速離開這樣的組織才是最好的方式。

---

註1: 「長期職業規劃」和「個人理想夢想」並不同。個人理想夢想可以需要很長很長時間實踐，也可能只需要很短的時間，也可能和職業無關。當然個人夢想就需要長期投入，也可以規劃，也可以不規劃。不過，不投入自己時間的夢想，通常就是空想而已。

企業巫醫 - 贅字 廢話 泥巴仗

在組織中，溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單，畢竟人類是靠群體合作而存活在地球上。不過，在企業內部的有效溝通並不如想像中的容易(註1)。

某些人在對話或文字表達上，有意無意的更增加溝通的難度。如果是無心的，僅只是造成困擾而已。但如果是刻意為之，會讓溝通困難，讓事情滯礙難行。

無論有意無意，溝通上常見三個問題：「贅字」「廢話」「泥巴仗」

在這三個之中，贅字和廢話很煩人，但真正要解決的是可怕的泥巴仗。

贅字

典型的例子，像是最近淡江大學解聘兼任教師的新聞：高教工會主任：「學校也一再地向（兼任教師）表示說，也是因為今年的8月1日，勞基法要開始適用於，未具本職的兼任教師身上，學校不想負擔這樣的人事成本，所以他們才會做了一個解聘跟不續聘的動作。」

有人稱這類型的贅字為「語言癌」。(註2)

凡舉「關於XXXX這個部分」，「做一個XXX的動作」，無意義的拉長語句都是。

當然也有些人認為拉長語句是「敬語」的表達方式(註3)。

此外，狀聲詞：「嗯」「唉」「阿」因為在對話中，有實質表達情緒的功能，所以不算是贅字。

不過，贅字真正的影響其實很小，只是太多贅字會讓聽的人很不舒服而已。

廢話

在說明事情，或者文件上，用過多虛浮的形容詞，掩飾無意義的內容。或者，重複不證自明的真理，用以掩蓋無法找到重點的對話。

在政府機關的公務人員出國報告網，可以輕易地查詢到充滿廢話的報告。

例如：一個公司是多面向的結合。(簡單的說，整句都是廢話)

例如：透過本次會議實際瞭解大陸生醫相關市場現況，就本所研發之核醫藥物推廣應用極具參考價值，可納入本所未來研發方向之參酌。 (簡單的說，出國去參加這個會議，最後只是參觀看看而已，沒什麼東西是真的影響組織的研發方向！)

另一個例子：不論是什麼樣類型的數位化工具，除了便利性外，都應兼顧到安全性，日後推動電子化政府的過程中，應與各級資訊安全主管機關做密切的合作，確保資訊科技的演進不會成為資安漏洞。（資訊科技本來就不應該是資安漏洞，各級安全主管機關本來也就應該合作，哪會需要出國參加會議之後才知道這兩件重要的事？)

當然，某些企業網站資訊，也是廢話很多。不過，大部分是似是而非的術語，構築專業能力的感受。

例如：透過嚴格的專案控管與扎實的系統建置專業能力，我們有信心提供客戶最安心、最可靠的大數據優質服務。(如果把形容詞拿掉，這句話其實很短：我們提供專案控制和系統建置的大數據服務。但更具體一點，就是：其實有案子我們就可以接來做，大數據只是個行銷名詞)

有時候廢話很煩人，因為要花些力氣才能抵達事實真相。廢話浪費的很多時間，不過如果採用Scrum方法論，在會議上只專注於現況和事實，應該不太可能會有廢話太多的問題。至於網頁資訊和技術文件，就應該盡可能去除廢話。

泥巴仗

最高級，並且更難應對的是泥巴仗。

特別是在中大型組織，中階主管通常都位於關鍵職位。而好的中階主管，仍具備本職學能(註3)，會根據事實來溝通。也因此，優秀的中階主管通常會強調技術事實，產業事實，專案事實，資源分配事實...等等諸多事實根據，作為溝通以及決策的基礎。因此，反倒不會強調本身的溝通協調能力。因為這樣的能力，如同影子一般隨附在工作之中。

然而糟糕的中階主管，由於已喪失本職學能(註4)，就會強調其「協調溝通」成為其最重要的工作。然而，不基於事實和邏輯的溝通，會變得混亂不堪。某些糟糕的中階主管，在遇到爭議性問題時，會用打模糊的方式，試圖讓大家在泥巴仗中度過。而最高階的泥巴仗，會用看似合理的邏輯，但展示對技術完完全全無法掌握的事實。

例如：這個影片，非常經典，看似誇張，但在資訊科技產業其實常常發生。在該影片中，真正做事情只有一個人，而中階主管遇到技術難度的問題會省略甚至推諉，不能體會真正的重點而死咬不重要的細節，而技術人員要探索細節又會說這是專家的工作範圍。當然該影片是太誇張了一點，但其實在中大型組織時常發生類似的事情。

另一個例子：在老大靠邊閃中的有名片段，first thing or second thing。主角完全是用打泥巴仗的方式，在黑幫大老會議裡，刻意激怒某老大。而其他大老反倒會覺得生氣的老大很沒風度，一開始沒發現主角在打泥巴仗。

在此徵求案例：徵求在資訊科技中，重要會議裡打泥巴仗的案例。 


混亂泥巴仗是很可怕，要對應泥巴仗有先決條件，就是這不能是在「只有兩個人」的情況下。換言之，會議或者文件，至少要有三個人在場才有機會擺脫泥巴仗。

只有兩個人的情況下，只要有一人刻意打泥巴仗互相把對方弄的髒兮兮的，而且這個人還是中高階經理，另一個人根本不可能解決。唯一的方式是，儘速逃離現場，在下次確保有第三人以上在場。

在有起碼三人的情況下，以下方式可以解決泥巴仗問題。

1. 不隨之起舞

泥巴仗成立的條件是互抹泥巴。例如，在軟體專案中，當大家在解決A模組為何落後時，如果有人反覆提及一些沒有直接關連的事情：也許是另一個專案也落後了，也許是某RD的溝通態度不好。這些都是泥巴仗的徵兆。

2. 以白板展現事實

人的思考和言語是線性，因此在看穿複雜問題時，光是在腦中想是很容易被泥巴仗牽著走。

最好的方式是，一旦發現「同時」討論兩件以上的事情，就應該在白板畫圖或者條列。

畫圖是最好的選擇，最簡單的可以考慮心智圖或者魚骨圖。一旦有人試圖混淆事情，只要指一指說明我們現在在討論這個點，等討論完有決定之後，再往下一個點前進。而如果兩件事情有關連，就用線條與另一個點來說明此關連。

這也是為什麼，幾乎所有優秀的資訊從業人員(無論是低階還是高階)在會議中都喜歡坐在白板附近。

3. 耐心

簡單的說，就是有耐心的條理事情。透過工具(白板或紙)讓事情呈現。當知道對方採用泥巴仗手法-無論他是不是故意，就表示事情不會很快結束，因此要秉持著耐心條理問題。更重要的是，把這件事情當做類似刷牙洗臉的小事，在處理過程中沒有心情起伏 - 當然就不憤怒生氣)。

---

註1:特別是為求避免衝突，每人的說的話和實際心裡想的都有差距(參考left hand column)，這讓組織 - 特別是資訊科技組織 - 運作上增加不必要的難度。

註2:  並不是去除重複字眼，極端簡潔就是好事。在文學作品中，言詞的優美有時候會透過層層疊疊的語句產生，請參考這裡。不過單就企業組織的溝通 - 例如開會 - 應該和寫小說是不一樣的。

註3: 參考這裡。

註4: 以資訊科技來說，最基本的本職學能是寫程式，其他可以參考這裡或這裡。

畢業前六個月 - 建構職業生涯

在台灣的碩士生，畢業前六個月通常忙於論文。如果不考慮繼續就讀博士，畢業前六個月其實是建構職業生涯的最佳機會。

更確切的說：畢業前六個月是讓你日後容易取得理想工作的最佳準備期間！

為什麼需要強調在6個月前建構職涯規劃？

環境上有許多現實的情況，例如，大部分好工作機會，其主管都傾向雇用有經驗的程式設計師。然而，絕大部分剛畢業學生並沒有實際軟體開發經驗。

因此，剛畢業的學生如果剛好獲得一個適合自己，能夠成長，能夠有所貢獻的工作，那麼就會進入良性循環。這個工作會讓這個學生更容易找到下一個好工作，或者即便不換工作，也能在目前的組織中成長。


反之，剛畢業的學生如果找到一個不適合自己，到處瞎忙，只是以時間換取薪資的工作，那麼就進入惡性循環。這個工作會讓該學生不容易找到比較好的工作，即便勉強換工作，也得靠運氣。

如果不想靠運氣，也沒有富爸爸，也不想自行創業(註1)，則要做的事情很簡單：

(1) 考慮現況
(2) 設定短中期目標
(3) 建立事實

考慮現況

首先，最重要的是，取得一些關於自己的事實。是不是想要做關於軟體開發相關工作？想要做哪一類型的相關工作？是否知道自己還缺乏哪些能力？哪些地方的工作，可在短時間有巨幅成長？

如果想要當個程式設計師，要考慮的現況：

1. 能使用哪些程式語言：是真的會，而不是只寫過hello world和學校作業。並且有「事實」可以佐證。例如在github上的project，或者工讀經驗。

2. 能掌握資訊技術工具：是真的能掌握，而不是用過一兩次或者學校作業。並且有「事實」可以佐證。例如：工讀經驗，利用資訊工具做的個人專案等等。

3. 能掌握團隊專案合作方式：例如是否有Scrum相關證照(註2)。

4.....<其他還有很多請自行想像>

如果想要從事資訊業，但是一開始就做SA/PM類型的工作，在軟體開發職涯裡其實不太腳踏實地，不過，真不得已可以參考這篇：資訊科技學生畢業後只想當SA/PM (三個創意作法)

設定短中期目標

某些職涯教練，或許會建議新鮮人設定長期目標。甚且透過各種神奇的方式推展或瞭解自己的熱情(passion)所在：例如希望自己五年之後賺10億之類的。

大部分的長期目標雖然有趣，但是用處不大。設定可預計的中短期目標更為重要。

以6-12個月為期，讓自己在畢業前達某些技術性和非技術性目標，對未來職業生涯非常有幫助。以未來想要當程式設計師的學生為例，在畢業前六個月可以訂立以下目標：

* 開發並且將一個Android APP放在googlestore上：熟悉在android平台上開發APP，因此需要熟悉Java。

* 取得Scrum Master證照

* 閱讀3-4本關於軟體QA的書籍，並且運用在現在的專案上。(含建構測試案例，執行測試，系統化記錄錯誤，...)

訂立目標必須要是

(1) 有非常清楚的結果。如果目標是「熟悉java」，則最後有沒有達到此目標是非常模糊的，但是目標是開發android APP並且上架，就表示必須要寫java到某個程度才行(註3)。

(2) 可以在6個月之內達到。不要設定一個花10年才會達到的目標。如果真的有長期目標，當然可以設定長期目標，但是需要伴隨可以逐步前進的短期目標。例如，或許你想要成為java大師中的大師，這可能要花上數年，但必定可以有個6個月能達到的前期階段，例如：「不靠任何補習方式，就取得SCJP」

(3) 其結果會伴隨建立事實。請參考下一段

建立事實

在畢業前六個月，是最適合建立「事實」的時候。

建立事實，和畢業前花時間美化履歷表有很大的不同。

美化履歷表，是可以靠一兩個禮拜，找一些專業人士協助就可以很輕易的達到。但如果自己的「事實」不夠充分，再怎麼美化也沒有意義。

前一段關於短中期目標，只要你的短中期目標定義夠清晰。這些就是你要建立的事實。

如果你是在未來6個月即將畢業的學生，對自己的技術能力非常沒有自信，然而又想從事軟體工程師的工作，可以考慮建立以下三個事實：

* 透過自己決定的開發專案(例如Android APP)，徹底實踐品質管理(QA) 

     (a) 找一個不用錢的QT工具：可以參考這裡。
     (b) 在開發專案的過程中，徹底運用此工具，確保自己的專案品質。
     (c) 將結果詳盡記錄，就成為自己能當QA的事實

* 透過自己決定的開發專案(例如Android APP)，徹底理解並且妥善運用git(或任何版本控制工具)

      (a) 版本控制是軟體專案的基礎中的基礎

      (b) 需要徹底了解如何branch，如何merge，如何處理conflict

      (c) 其結果構成了解專案開發的基礎事實

* 取得Scrum Master證照

     (a) 參考這裡
     (b) 雖然大部分的管理類型的證照意義都不大，但是取得成本不高的情況下，展現了你至少是瞭解Scrum。

---

註1: 想要自行創業的準備不太一樣，首先要了解創業如何必然成功，再參考其他相關資料。

註2: 花大錢考管理類型證照其實不划算，但是可以考慮花小錢，請參考這裡。

註3: 對，我們知道React Native可以讓你不需要寫java，但是這裡只是舉例而已。

企業巫醫 - 統計與謠言

In god we trust all others bring data 
  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低，同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會，例如：十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪，例如：誠品可怕迷魂盜，泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇，例如：裝翅膀飛起來

。

最糟糕的類型，莫過於以「統計數字」造出看似符合邏輯的謠言。並且，從這樣的謠言中獲得利益。


許多時候，數據本身難以查詢正確性。而且由數字導引出的邏輯，更容易因人而異，因地制宜。從數字所引導的偏誤，有時候甚至比單純的謠言還可怕，因為它可能會在網路上留存多年，難以辯證。如果只是單純搞笑也就罷了，如果個人或者組織，以這類型的資料來作為決策的判斷依據，那下場可能非常慘。錯誤的資料，比沒有資料更糟。


不過，只要稍微留意，加上合理的好奇心，統計謠言是有機會判斷其可能性：

(1) 不解釋的數字

在各類文章或研究報告中，為求精簡，只會根據重要數字做衍生推論。然而，數字背後通常還有「未解釋」的數字，而這個數字可能更為重要。

以企業僅21%的需要大學以上學歷為例。這篇文章，簡單說明勞動部的調查，僅有21%的企業需要大學以上的學歷。然而，這個數字有很大的問題。

也許，該調查隨機抽了100個企業主，其中只有21個企業主宣稱需要大學以上學歷的員工。

也許，該調查抽樣了企業主的「100個正在招募工作職缺總數」，這100個職缺中，只有21個是需要大學學歷。

這兩者有極大的差距。前者，可能這21個企業主，所需要員工數量高達2萬人，而另外79個企業主，所需員工只要79個人也說不定。而後者，正在招募的職缺，和「已經在職」的學歷也並未顯示。而單就此推論，僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化，而沒有附上數據的真實來源的推測，其解釋很容易被扭曲。然而，被扭曲的解釋，當然比較有戲劇性，比較容易被注意。

勞動部網站根本也找不到這份調查。

此外，很多政治性民調也是屬於此類，涵蓋許多不解釋的數字。

(2) 接近完美的不可能

網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示，越早退休壽命越長。(參考這裡，這裡，這裡)  

這份數據流傳非常之廣，被引用次數非常多，每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字，是退休年齡跟「壽命」的對照表如下。

retire	life
49.9	86
51.2	85.3
52.5	84.6
53.8	83.9
55.1	83.2
56.4	82.5
57.2	81.4
58.3	80
59.2	78.5
60.1	76.8
61	74.5
62.1	71.8
63.1	69.3
64.1	67.9
65.2	66.8

不會統計的人也可以看出，在這個表中，越早退休，壽命越長。如果49.9歲就退休，那麼可以活到86歲。65.2歲才退休，就只能活到66.8歲。

以相關係數簡單計算，他的相關程度高達-0.96，換言之，這是一份極為完美的負相關數字。

這種過度完美個數字，應該要看研究論文的細節加以瞭解。例如他的樣本有多大？是什麼時候做的研究。就可取得的事實來看，他的樣本很小，並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲，所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是，這些數字並非真實研究論文，卻在很多人的轉貼中，莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因，是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷，財務規劃，人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外，別無他因。雖然已經有些人發現不對勁，例如這裡。但是許多第一次看到此研究的人，仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究：請參考這篇研究。該篇的結論就交由各位判斷，但至少它的研究方式，數字細節，都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng，懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者？)。至今2017/Jan/11尚未收到回覆。

(3) 邏輯上的不可能

邏輯上不可能，或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來，竟然遠超過全國GDP，而且高過很多。這在邏輯上是不可能的事情，因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查，而且其實也不打算認真做統計的相關文章上，例如這裡。因為在許多時候，謠言只是想要造成吸引人的目的，其真實性不重要，當然就也不特別檢查數據。所以自己造成自己數據兜不攏，邏輯上不可能的情況並不少見。

這和前兩者不同，邏輯上的不可能，可以單就資訊本身的內容加以探索，或者是再加上一些事實根據來檢視。因此，比較容易看出謠言的真實性。




最後，稍微提醒一下：廣告的統計宣稱，其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證，一般市井小民根本無法查證屬實與否。

企業巫醫 - 誰掌握你的升遷？

只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷，沒有別人。

大部分無法獲得升遷的理由，都只是自己的藉口而已。常見藉口(註2)如下：

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了，還在裁員
- 比我資深的還很多，很難輪到我


在大組織裡，個人升遷(promotion)仍然是職業生涯重要考量。因而，企業巫醫們的一些闡釋也頗有道理，例如這篇，或者這篇。但有些過於偏激，而且會舉一些憑自己想像的例子。這類型的巫醫頗多，在google上搜尋"升遷"就可以找到不少。


那麼，自己要如何掌握自己的升遷？

超乎期待：做出超越目前工作職掌的成績

升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織，或者主管，要認定你可以承擔更大的工作範圍，最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種，這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。

方向一：保健因素

保健因素指的是，沒達成會有負面影響，但是有達成，且做得再好也不會是超越工作職掌的事情。換言之，有絕對的必要性，但是超過也沒有意義。

例如：

作為員工，準時參與會議，準時上班，按組織規定請假。
作為一個程式設計師，準時交付符合品質的程式碼。
作為客服人員，在時間內回復顧客問題。
作為專案主管，讓控制並管理團隊時程，沒有延誤

有些是屬於規定類型，有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的！非但不用考慮升遷，甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解：

(a) 誤解一：消極應對

既然這並非升遷，或者有額外價值的項目，那麼也許我就做的勉強符合，60分就好。這樣的心態會讓這些的保健因素，很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化，(或自動化)的方式處理。

消極應對，只會讓保健因素變得個人缺點，得不償失！

(b) 誤解二：這不是保健因素

在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素，我做到這件事情就是超乎期待」。

事實上，絕大部分的由上而下指派的任務，幾乎都屬於保健因素任務。

例如，你負責撰寫android app任務，根據自己的努力，確實在規範的時程內，以規範的品質上架完成。這「本來就是」你的任務。完成這件任務，的確是好事，但如果沒有做出超越任務的範圍，那就是預期內的職掌。既然是預期內的職掌，當然會取得預期內的「報酬」，例如薪水。自然也不會取得「額外」的報酬，例如鉅額加薪或升遷。

試想，你搭計程車，司機在合理的時間內，安全的把你載送到你要求的地點。你自然會付出正確的車資，不太可能付出「額外」的費用吧。

方向二：激勵因素

如果有做到，會讓人感到「很滿意」。

這個方向並不容易，但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例，如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務，並且未要求額外收費，在你開心的抵達要求的地點時，非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考：

(a) 參考方式一：擴增保健因素

這個方式比較基本。例如：一個app的程式設計師，被要求在6個月內完成app並上架，結果在5個月就完成，並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」

(b) 參考方式二：額外的相關支援

類似計程車卡拉ok。例如：android app程式設計師，被要求在6個月內完成app上架。結果的確在時間內完成。並且，由於他採用react native，竟然也順便完成了iOS app。這就是額外的支援項目。

(c) 參考方式三：擴大 

主動執行擴大職掌範圍的任務。例如app程式設計師，其任務是開發app並上架，如果主動協助開發伺服器端，或其他功能模組，就算是擴大範圍。

更顯著的例子是：app程式設計師，其任務是開發app並上架，但主動組織團隊，做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。

其他：

離開組織，以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然，離開組織之前，要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方，也不可能解決問題，只是碰運氣而已。參考這篇，或者這篇，或者這篇。

創業是自己造成升遷的最簡單方式。在那一夕之間，你就變成董事長兼CEO了。然而，能不能生存並獲利，又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易，參考這裡，與這裡。

---

註1：在某些地區，某些情況下，當然有不得已的時候。例如，如果你是生在阿富汗，伊拉克，索馬利亞等國家，確實很難掌握自己的命運。所以，本篇指的是一般在台灣的普通上班族。

註2：為什麼這些是藉口？請參考說明如下：

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現，甚至可能被瓢竊或者搶功勞。但長時間不可能！而且事實上，如果你真的能力極佳努力也夠，僅只是沒被看到而已？那你應該很容易可以找到更好，並且更容易看到你的能力和產出的地方！

(b) 爛主管的確有可能打壓好員工，但沒有人強迫你為某個主管工作，你當然可以離開。但是在離開之前，請先參考這本書(我愛白痴老闆)。也可以參考（得罪老闆怎麼辦）


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美，因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且，適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作，那不升遷的確是合理
(b) 如果工作真的太難，那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的，資源缺乏不是問題，只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單，可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單，但是對主管來說你沒把簡單的工作做好，以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了，還在裁員
-- 比我資深的還很多，很難輪到我

(a) 如果升遷是你最重要的考量，應該離開這類型的工作環境

企業巫醫 - 年底才績效評估或考慮轉職？已經太遲。

年末，巫醫們會試圖對迷惘的人們，提供某些指引。

因此，在各部落，社群網站總是有各式的「轉職衡量」，「績效評估」，「個人職涯規劃」，「獵人頭的建議」...等等相關文章。(註1) 

不過，就實際情況來說，假如你到「年末」才考慮這些重要事情，那麼已然太遲。


為什麼？

績效評估要及時

大部分的企業在年尾都有績效評估。但以個人職涯而言，這些事情，應該是每隔一小段時間 (例如一個月) 就應該自我有所評估，並調整未來的做法。

就好像今年初打算減肥20公斤，並降低體脂肪到20%以下，而直到年底才量體重體脂肪，基本上已經太晚。即便最後仍然達到目的，也可能只是運氣好。

無論層級高低，無關老闆是誰，無論組織狀態，每隔一段時間，個人應該就事實以及個人產出部分自我評估一下績效。更重要的是，了解別人(特別是主管)對自己的「真正評估」。

自我評估，必須要根據「事實」，與其他人的「衡量」。不應該根據自己的想像，以及感受。

舉例來說，如果你是個軟體程式設計師，每個月你都如期產出符合品質的程式碼，並且bug數量也很少，那麼確實是個好工程師。

反之，如果相較於其他軟體程式設計師，你的程式碼產出低於其他人，bug數量也多，即便你有參加福委會，搞了很好的尾牙活動，你的績效評估恐怕依然很糟。

但由於，許多績效評估是根據「相對績效」來判定。而由於人類有天生的偏誤，自我評估一定會趨向「好的結果」。

因此每一小段時間，你一定要試圖取得主管或其他相關人的「真正看法」。越嚴格的越好。如果在2016年2月，你知道主管對你的績效是不滿意的，那麼你還有很長的時間可以改變(註2)。但如果你是在2016年底年終考核，才赫然發現主管與你對績效的「看法」不同！那幾乎沒有翻盤的可能。

另一個重點在於：績效評估是為了自己的職業生涯，不是為了組織，也不是為了讓主管決定薪資。

如果你覺得，如果要做每月的績效評估，公司/主管應該要主動進行才對？那表示你根本不是個能獨力處理事情的人，同時也表示你的主動性太差，也很難自己成長。

轉職衡量要完整

年底並不一定是換工作的最好時機。只因許多人因為領到年終，所以剛好離開「忍受很久」的工作，所以一時間就似乎有很多職缺出現。然而，某個人忍很久的工作，通常表示下一個人也不一定好受。

換工作的考慮有很多，無論哪一種考慮，都需要基於事實（請參考這裡）。簡單的說，在這份工作遇到的困難沒有解決，下一份工作一樣會遇到。

完整的換工作衡量需要對自己在「事實」上的長期認知。包括過去一段時間有去哪些地方面試？並且被錄取？自己倘若離開這個組織，對組織有沒有影響？自己如果沒收入，可以支撐幾個月？

更重要的考慮是：自己真的想要的是什麼。

那麼，年末可以做什麼？

當然還是得進行轉職衡量，績效評估，個人職涯規劃，參考獵人頭的建議...等等。可是更應該進行的是「檢討自己」與「改變自己的實際做法」。

1. 不設定一年為單位

以個人生涯規劃而言。應該將「一年的結尾」。從新定義為「一個月」或者「一季」的結尾。

並自現在開始，設定自我評估的時間單位，例如一個月。

每個月直接詢問主管或者工作上最相關的人：「有哪些地方需要改進」「哪裡做的事情有問題」「這個月哪邊沒有超乎期待的表現」...。

對於調整職業生涯也是以比較小的單位取得回饋。

當然，這並不代表不能有年度目標，或者五年以上的願景。只是，檢視願景和目標的單位必須要有及時回饋的可能(註3)。而單指個人而言，每個人的記憶有限，根本不可能有效回顧12個月前發生的事情。因此採用Scrum的精神，以大約一個月為單位應該是最適合。

2. 不重複過去無效的做法

恆毅力是一本在誠品門口有超過5公尺橫幅廣告的書。作者以她數年的研究顯示恆毅力是成功的重要因素。

毅力耐心確實是朝著目標前進時不可或缺。不過，實際作法的調整也很重要。以創業為例，pivot幾乎是必要。

每過一段時間，應該就事實來檢討，目前做法是否達到效果。如果沒有，就應該衡量原因，考慮改變執行的方式。不見得一定要改變，但一定需要檢討。

改變當然有可能帶來風險，甚至會比沒改變的時候更糟糕。然而，不改變就沒有前進的可能！

3. 不等候重要的事情

誠如第一段所述，年末考核等到年末就太遲。其他和職涯有關重要事情也是，不應該年末才進行。

因此，今年年末可以設定未來「重要的事情」頂多等到下個檢討點 - 例如一個月後。

每個人所意識到的重要事情都不同，有很多時候心裡覺得一件事情重要，和實際上真的很重要是截然不同的事情。一個人的真正行為，才是斷定他認定重要不重要的指標。

---

參考：

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間？

職業生涯的突破

成長的最好方式：檢討


註1: ....對... 這篇也不例外

註2: 所謂調整，一樣要考慮手邊有的選項：可以針對不好的地方改善，也可以試圖換個工作項目。甚且也可以換工作。

註3: 有些人可能會用「爬樓梯可以一步一步，但是要跳過鴻溝不能分步驟吧？」來辯解過短的時間區間會有其他問題。不過，這真的是問題嗎？跳過鴻溝的確是一次跳過，但起碼助跑的時間和助跑距離的測量，也是必要的前一步啊！

因為沒挑戰想換跑道：先檢討自己吧！

新的一年，總是容易遇到討論換工作的事情。目前，台灣資訊科技領域整體仍然缺乏人才，因此要換新的工作是非常容易的事情。

真正的問題在於：什麼原因想要換工作？如何換？新工作或事業會不會比較好？自己到底想要什麼？

這些問題根深蒂固地存在每個人的身上。不會有一體通用的方式為所有人解答。

不過，如果單純只是因為現在的工作沒挑戰性，無趣而想要換跑道，還請以下三點簡單的自我審思一下。

檢討一：「沒有挑戰很無趣」的真正源頭

牌桌上的至理名言：「30分鐘後如果你還沒發現誰是冤大頭，那麼你就是冤大頭」。在企業中，如果你沒發現有任何值得挑戰的地方，那或許你自己就是沒有挑戰的真正原因。

當你的工作變得沒有挑戰，而且無趣的時候，請先確定問題的真正源頭。

是不是因為你的能力或者表現，讓你無法得到有挑戰有趣的任務？還是你的視野讓你看不出挑戰性？

還是這工作或事業的本身，真的沒挑戰性？你已經是有如NBA過去的Jordan或者現在的Curry已經快觸到這個事業和工作的極限？還是你抵達的是自我的極限？

檢討二：選項

選項，永遠是考慮決策的要件。

換工作或事業是一個好選項。但是，在既有的領域中，擴展自己的視野和能力也是一個選項。

換工作是個選項。在大企業中，換部門也是一個選項。換工作這選項中，嘗試新的技術領域是個選項，但是嘗試截然不同的工作類型（例如業務相關部門）更是更大的不同選項。

在現有工作內容中，改變自己的做法以求突破，也是一個解決的選項。

選項可能很簡單，也可能很複雜，而且還會參雜很多人的因素。去除自我偏誤，取得個人最想要的結果，比想像中的簡單。不過，要預設自己以及相關人等有完全的邏輯推理是很難的。（參考：沈思）

檢討三：「沒有挑戰很無趣」有時候是真正的挑戰

在資訊科技的領域裡，多的是把原本看起來無聊的東西，重新找到價值並且延伸的例子。

如果你可以將無聊沒挑戰性的事情，轉成有價值，並且有挑戰的事情，等於是你證實自己絕佳的創意以及實踐創意的能力。

這樣的例子在不管在哪個領域很多，從很久很久以前的gmail，到近幾年的類似snapchat的app，許多都是一開始是沒很有趣，但是找到額外的創意之後，將舊有的東西突破。

隨著組織越來越大，表面上無趣的事情會越來越多，光是默默的忍耐並不會讓事情變得更好，只有把無趣轉換成價值，才能展現自己的創意能力。要怎麼做？可以參考這篇



參考文章：換工作的面試-軟體工程師如何展現價值

---

沈思：
一個海盜集團中的5個海盜找到了100顆金幣，每一枚都一樣的大小和價值。 

由於海賊王想要這五個部下傷透腦筋，自相殘殺，規定他們分配金幣的方式如下： 

1。抽簽決定自己的號碼（1，2，3，4，5） 
2。首先，由1號提出分配方案，然後大家5人進行表決，當且僅當超過半數的人同意時，按照他的提案進行分配，否則將被扔入大海餵鯊魚。 
3。如果1號死後，再由2號提出分配方案，然後大家4人進行表決，當且僅當超過半數的人同意時，按照他的提案進行分配，否則將被扔入大海餵鯊魚。
 4。以此類推

 如果你是號碼1的海賊，應該怎麼分配金幣？

軟體專案的現實：解決人的問題

無論是否採用agile的開發方式，所有軟體專案，最大問題的來源都是人。

人的問題，通常會極現實的影響專案的進行。然而，妥善運用agile的精神和Scrum的方法，有機會讓人的問題降到某個程度。

某個朋友，姑且稱為K，在專案扮演專案經理的角色，遇到以下狀況：

我最近有遇到一個問題，不知道怎麼辦，下面的人一直做不到我的要求，或者動作很慢，即便壓日期給他，他還是沒辦法達到，但實際上它任務並不多，只是開test case，我不太知道怎樣push他，我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說，解決方式似乎也很簡單。首先專注於優先項目，接下來根據事實檢視工作，最後才考慮能力問題。

一：專注於優先項目

每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保，在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說，要確保團隊成員專注於目前任務上的方式很簡單：就是腳踏實地的「問」。在該成員一來辦公室的時候，就坐到他座位旁，親切的詢問他昨天早上在做哪些事情，昨天下午在做哪些，並實際上「看」到做的結果。就可以確定他是否專注，而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實，而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」，一起坐著看實際上的狀況。

二：工作檢視

以Scrum而言，每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成，沒有完成即便是已經達到99%也一樣是沒有完成。當然，前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum，則應該盡可能在團隊開始時，就先定義何謂「完成」。

以開test case為例，完成是指把要做的功能的test case詳述在某個測試文件管理系統上？還是只要先用excel或者wiki列出來即可？test case完成後是否要先讓團隊成員審閱，看看有沒有問題？要不要先估計每個test case執行會花的時間？test case的前置作業 - 例如建立測試資料等等，是不是也要涵蓋在其中？

當有完整的工作完成定義之後，要讓負責進行工作的人「決定時間」，而非「被決定時間」。

以軟體專案而言，任何超過2天的工作項目(task)，都應該分階段完成。畢竟，就事實而言，一個人不可能「連續工作2天」，每天一定會停住工作，下班回家。而這些階段應該要有階段產出。以test case而言，假設有10個新的user story需要建立test case，則今天完成了4個，表示還有60%尚未完成。

三：能力分配

如果團隊成員的確很專注於工作，而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩，牽涉範圍廣。以軟體專案而言，能力並非只是撰寫程式，測試程式，理解規格等等。能否和其他人合作，也是能力的一環。

一個規模中等的軟體開發團隊(4-7人)，如果有一個人的能力「極端」的差，確實會造成專案很大的問題。

在Scrum的情況下，這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多，但未來的sprint的進度，是以團隊能力來考量，因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下，可以先找到該成員的相對優勢。排定一些學習項目，來提昇該成員在這個專案中的相對優勢，並且在未來安排相對優勢的工作。值得一提的是，根據經濟學的「比較利益法則」，每個人一定會有所謂相對優勢：請參考這裡，和這裡。

關於軟體開發團隊的個別能力，還需要注意以下幾點：

1. 每個人都會成長，但是....

每個人都會成長學習新知識和能力。但是！在中短期專案裡，必須先考慮個別能力與優勢。

換言之，團隊領導要像下象棋一樣，找到每個人的「專長」，能妥善組合專案，就是個好的領導者。

而差強人意的領導者，則是常常試圖規避個別成員的「缺點」，這樣比較不會出大問題，但也容易產生差強人意的結果。而最糟糕的領導者，則會把人當做圍棋，看到人非黑即白，見到專案漏洞時，看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質)，但在軟體開發專案鐵定行不通。

2. 能力是綜合考量...

能力必須綜合考量「全方面」：例如是否好溝通，是否能處理複雜的設計問題，能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外，如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者，應該先思考自己是不是「問題的來源」，甚至要思考自己是不是根本不適合作為團隊領導。

3. 讓不適任的成員離開...

讓不適任的成員離開，某些時候是個可行的解決方案。特別是某些企業管理派別認為，投入時間在不適任的人身上，他有可能變得適任，也有可能不會改變，然而投入時間太多，會造成專案延誤。

以Scrum的角度來說，這個情況不太會發生，因為2-3個sprint之後團隊速度已經確立，無論適不適任，專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言，讓破壞性的不適任者離開，當然是解決方式，但不見得要「找另一個人進來」。

---

相關文章：人才管理，心智圖，為自己工作...

企業巫醫 - 時間乃最終之敵人? (下)

上篇：企業巫醫 - 時間乃最終之敵人? (上) 

那結論呢？

就人類來說，時間是中性的。它不是朋友，也不是敵人。它不是惡靈，也非天使。

在有限的職業生涯，如果你找得到自己的方法駕馭它，那非常恭喜！這可是上天給予的重大天賦之一。

如果始終在瞎忙中度過，或許試著混合數種前面的巫醫建議方式，可能會有些幫助。

但有幾個重點...

1. 考慮事實

企業組織為求營利的天賦，自然趨向去做幾乎任何可能產生商品競爭力的方式。以時間為衡量標準，恐怕是在天然資源和資本取得已經趨近最佳化的情況下，最合理的方式。

如果你覺得在企業組織工作時，自已的時間被無聊的瑣事白白浪費，氣的想要出來創業....那麼，你一定要先考慮是大部分的人，是自己無法控制時間，而非被別人浪費。這種情況下出來創業，會讓你本來每天花8小時幫某公司做事，變成每天花16小時，幫自己的公司做事。

時間既然是中性，增加效率當然是可行。加速？聽起來跟前述的巫醫有什麼不同(註4)？

重點在於：無論是個人還是組織。找到真正的目的，比產出效率重要。

而真正的目的在於考慮真正的事實。企業巫醫有許多手段和方式，都可以協助你找到「真正的事實」。

以個人生涯規劃而言，最終，這個事實也有你自己才能夠斷定。

然而，以在企業組織內部工作，真正的事實，或者是真正的目的，必須要來自「團隊目標」和「組織目標」。

2. 兵貴神速 v.s. 後發先至

重點在於：長期累積比短暫績效重要。

當企業組織可以在某個產品推出時領先，當然要持續領先推出其他產品，或者領先產品的其他服務。在這世界上有太多的先行者，無法保持領先而被後來者居上。兵法也有云：「後人發，先人至，此知迂直之計者也」，後發先至，其實是兵貴神速的對應。


個人工作上也是如此。快速完成的工作，如果不能累積優勢，就浪費了速度。以軟體工作而言，快速完成功能固然重要，但是功能上的完整以及品質，卻是快速的「基礎」。因而，採用敏捷開發的任何方法論，都不能以快速作為藉口，直接放棄功能上完整或者品質。

後發先至的基礎其實也在於「快速」。但是，個人快速的反應，其實是長久實力的累積。例如，對營運Linux平台十分熟悉，有很多年踏實經驗的工程師，自然在對應新的Linux雲端營運(例如AWS,Azure的Linux虛擬機)就比較容易適應。而過去僅在windows平台上有營運經驗的IT人員，如果整個系統要搬移到Linux為基礎的平台上，就算他可以很「快速」完成一部分，也不見得做的完整或者達到好的品質。

3. 時間乃最終之敵人 ...除非...

時間從很多角度來說確實是最終的敵人。它雖然是中性，但是它永遠都會流失。它的離開是必然而且無情。無論這禮拜天你做了什麼，禮拜天一定會過去。

因此，現實的說，時間乃最終之敵人...除非......讓它變成「敵人的敵人」。

以近年來的新興網路企業而言：

無論有沒有特別認知，事實上都試圖以「時間」來建立其他對手的進入障礙。若非以極高的成本獲得市場佔有率，讓其他競爭對手花更多時間才能開發產品，就是以需要時間累積的功能作為競爭主軸。

以個人的生涯規劃而言：

剛踏入社會的新鮮人，勢必缺乏實務經驗，無論是在爭取好的工作機會，或者是已經在企業裡面爭取好的表現，都不能是以「經驗值」來作為依靠。

以經驗值產出「工作表現」，大部分情況下新鮮人是無法和老鳥相提並論。但是相對於工作N年的老鳥比較起來，在「時間」上新鮮人擁有更多彈性。所謂時間，切記並非加班時間，而是「第一次就做對事情」的時間，透過學習和利用比較新的知識範疇，新鮮人可以比較快跳過錯誤的嘗試，在某些未來有發展潛力的範圍，有更驚人的表現。這時候，時間就會是朋友而非敵人。

相對的，已經工作了7年以上的老鳥。如果老是只能靠吹噓過去已經結束的專案經歷，無法產出對應的經驗值，那麼這七年時間就變成是最大的敵人。只是看到最新的技術，就隨意一頭栽進去學習，則時間就會是資深工程師的敵人，因為通常資深工程師的彈性時間實際上比較少。

資深工程師，在工作上必須要找到能夠善用這七年的成功或失敗經驗的地方，並試圖累積更多。即便是想要打掉重練，也應該透過經驗的累積，重練的更快，更好，甚至自動化。找到可以累積的地方，這時候，時間就是朋友而非敵人。

以作為組織內部的部門主管，專案團隊領導者更是如此：

當領導者使用以下手段時，是把時間當做敵人，(然而，要打敗時間實在太難)

* 加班
* 在軟體專案延遲時利用人月計算方式增加人力
* 以未來的產能估計時間，而非以過去的事時估計
* 以各種理由拖延專案，包含把責任推到別的團隊身上
* 專案過程並未檢視真實進度
* 假裝使用agile敏捷開發，實際上還是waterfall
* 不正視事實
* ....(還有很多)...

那麼不採用以上手段還有什麼可以做的呢？當然很多！如果你是領導者，但是想不出來其他方式，那麼你可能不適合擔任困難任務的領導者，因為「時間」永遠是你的敵人，而幾乎沒有人可以打敗時間。

---

註1：CP值，或者性價比，請參考這裡。

註2：這句話很多人都講過，包含郭台銘和柯文哲。不過，這個名言最早應該媒體大亨：梅鐸所說。另外，這句話在2002年也是某本書的名字。

註3：將時間視為第四個空間維度來描述，請參考狹義相對論。

註4：增加工作效率？聽起來和前述的巫醫有什麼不同？就想要達到的效果來說，有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理，經過有效驗證，而且可以在未來檢討改善。

企業巫醫 - 時間乃最終之敵人? (上)

在每年不可計數的企業管理勵志書籍中，有越來越多把「時間」視為判斷事務的重要標準。想當然，個人「時間管理」變成一種必要的技能。然而，更近一步是在越短的時間，達到越驚人的效果，從早期的「24小時學會某東西」系列，到「7分鐘運動燃脂72小時」，都是試圖在短的時間內達到CP(註1)值最好的結果。


時間似乎是最終的敵人？


也許，在某些時候，「搶先一步」是競爭的最佳方式。不是大的打敗小的，而是快的打敗慢的(註2)：就變成企業主事者認定的最好成功方式。畢竟，如果可以用很少的投資(小)，只要用比較少的時間(快)，好像就可以打敗大但是慢的競爭對手？聽起來永遠不吃虧阿！再者，兵法有云：故兵聞拙速，未賭巧之久也。似乎，只要速度夠快，總比慢來的好？

更近一步的說，許多人逐漸視時間為最終測量維度。例如Compete Against Time，就將時間視為在商業上，衡量事務的最重要方式(註3)。甚至有人認為應該是唯一的度量方式。

就經濟學始祖亞當斯密1776年的說法，企業組織價值的來源主要由三種事情組成：資本，土地，勞力。土地：泛指一切自然資源，勞力：泛指人類的智慧和努力。任何商品的價值，都是由這三者的其中一種，兩種，或者三種組合起來。

時間快轉到2016，隨著全球化經濟發展，資本以及自然資源，對於企業的影響已經遠遠不如「勞力」，更確切的說，是人的努力強化資本和自然資源的運用。即便現在存在著比1776工業革命初期更自動化的設備，更能節省人付出肌肉的努力，但面對更趨複雜的環境，人類的「智慧腦力」似乎需要付出的更多，某些人需要付出更多的腦力，讓其他人少動點腦？而最終，變成某些人在相較短的時間，付出較多的腦力，產生較好的結果，可以大幅讓商品的價值領先市場的其他人。


總之，各種訊息「似乎」都顯示，即便時間不是最終的敵人，也是先要處理的「衡量指標」


以廣大勞工而言，衡量生存的指標，就從古時候的「每天能耕多少田」，轉為「每天能在工廠做多久」，而再變成「每天在電腦前面完成多少工作」。只要能在越短的時間完成越高品質的工作，就會越有機會加薪升遷。


然而，事實上只有極端少數的人，能夠妥善駕馭自己的時間，也因此，「時間」變成企業巫醫用來恐嚇部落子民的惡靈之一。


巫醫有三種方式來處理「時間惡靈」

一：加速 - 跑的比它快

各種企業巫醫的，也在強化此信念，教導讀者「加速」用來增加巫醫的崇拜。

例如，最有生產力的一年，超強時間術，早上三小時完成一天的工作，時間整理術... 請隨意搜尋類似標題，一定可以找到超過100種以上的方式，書籍，甚至mobile app。

這些加速的書籍，有些的確是有用的個人經驗，就像南美巫醫累積了數世代的經驗，分辨有效的草藥一樣的有些用途。然而，通常僅能適用於巫醫自己。關於「加速時間」，就像投籃命中率一樣，可以學習，可以練習，但是因為環境的因素，每個人終究有其極限。

事實上，「加速」全然是靠自己的經驗和能力，就像大部分的感冒是靠自己的抵抗力痊癒一樣。採用巫醫的建議手法，確實有幫助，只要自己意識到這樣樣的手法是在幫助自己的經驗與能力即可。過度崇拜「方式與手法」，會容易走火入魔。(參考：2013年的9個todo app)。

二：有效利用 - 80/20法則的極端利用

光是加速，能取得的效果總是有限。頂多取得20%-30%的進步就很了不起。唯有改變方式，甚至改變目的，才有可能取得3倍或者10倍的改變。

從「加速」改為「有效利用」，就成為在2008金融危機之後的顯學。

例如：為什麼菁英都是清單控，Scrum一半的時間做兩倍的事，少但是更好，其實工作不必這麼累 ... 一樣有成千上百的書都屬於此累。

這類型的「找重要的事情做就好」的書，其實真只有這個重點，那就是掌握80/20法則，先做重要的事情，你的職業生涯就是彩色的。

但是，企業巫醫沒辦法告訴你，在你身上哪個20%是最重要要做的事情。誠實的巫醫永遠只能說「施主，這要問你自己阿」。而拐彎抹角的巫醫會用「斷捨離」，「時間矩陣四象限」，「人生優先清單」等等技術性的手法，告訴你，你還是得自己找到那重要的20%。

三：心靈層面 - 永遠都有的一招

幾乎所有的企業巫醫都會的一招：將所有的事情，推移給心靈與精神層面。

例如：心靈慢活療癒，慢活，從容的力量，慢一點成功又何妨，被討厭的勇氣...

就心靈層面觀點而言，這些巫醫也許可以帶來平靜，而平靜讓人的思慮或許可以更周延，並降低更多的壓力。但是，這些巫醫雖然好意的想要讓世界變得更美好，但是絕大部分的人類是社會性動物，試圖全然擺脫外在的影響，等於是要人類放棄天性。當企業組織內變得越來越快速，光是一個人在裡面「慢活」是難上加難。

那結論呢？

請參考下篇：企業巫醫 - 時間乃最終之敵人? (下) 。

---

註1：CP值，或者性價比，請參考這裡。

註2：這句話很多人都講過，包含郭台銘和柯文哲。不過，這個名言最早應該媒體大亨：梅鐸所說。另外，這句話在2002年也是某本書的名字。

註3：將時間視為第四個空間維度來描述，請參考狹義相對論。

註4：增加工作效率？聽起來和前述的巫醫有什麼不同？就想要達到的效果來說，有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理，經過有效驗證，而且可以在未來檢討改善。