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

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

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

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


為什麼？

績效評估要及時

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

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

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

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

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

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

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

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

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

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

轉職衡量要完整

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

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

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

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

那麼，年末可以做什麼？

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

1. 不設定一年為單位

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

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

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

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

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

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

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

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

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

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

3. 不等候重要的事情

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

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

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

---

參考：

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間？

職業生涯的突破

成長的最好方式：檢討


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

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

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

企業巫醫 - 提昇效率的秘方

這裡有幾本書...

- The Productivity Project	最有生產力的一年
- Four hours work week	一週工作四小時
- The Art of Non-Conformity	不服從的創新
- THE $100 STARTUP	三千元開始的自主人生
- Do over	(不確定是否有中文翻譯)
- Nomad Life	遊牧生活

這些書籍有很直接的共通點：

(1) 個人經驗

和一般以二手資料的企業巫醫的書不同，這些書籍都是以「個人實際經歷」為主要組成。可能沒有精湛繁複的巫醫術語，但是「因為自己有做過」也比較容易說服別人。

(2) 專注，效率，生產力

這些書籍或多或少都強調個人效率的重要。基本上不外乎討論80/20法則，生理因素，心靈意志，工具方法等等。

(3) 個人品牌創業

這些書籍的作者，其實都是「個人品牌創業家」。個人品牌創業大約在2006-2008年之後，在網路上蔚為風潮。特別是在北美，這些個人品牌創業家通常都會有(a)自己的blog (b)自己的書籍 (c) 一個看似專精的知識領域...接下來通常就組合優勢開始以自己的名聲盈利。

為何強調效率與生產力的重要？

合理的推測，這類型的書慢慢也會在亞洲流行起來。雖然僅只以個人經驗與觀點來詮釋某個複雜的龐大主題，可能失於偏頗。但相較於純以「個人想像」和「無根據的推理」的企業巫醫書籍比較起來，還是踏實的多。


其中，「專注，效率，生產力」是三位一體的永不衰退話題。自從有工業革命開始，效率/生產力便是工業界主要獲利來源。在1995之後的網路時代，雖然「創意」與「變革」突然成為顯學，但究竟沒有效率，無法被執行的創意，等於是一種空想。創意變為有效可執行的事項，才有實務上的意義(參考這裡)



因此，能否有專注，高效率，高生產力的產出，變成知識工作者必備的能力。而也是「缺乏資源」創業者成功的關鍵之一(參考這裡)。

而也正是因此，「提高生產力的祕方」，在近年來變成出書的顯學，甚至也成為「被創業」的利基來源(註1)。

個人提升效率生產力的祕方

很遺憾，並沒有什麼祕方可以「簡單而且戲劇性」的提高個人效率或者生產力。至少，沒有不需要努力的祕方。

在業界確實有各種「顧問」，可以針對特定的個人，特定的案例，提供收費的咨詢服務(註2)。但最終，教練顧問只能提供指引，還是只有自己幫助自己。


先考慮以下低成本的「尋找自己的祕方」的三步驟，大概只要花2天：

(1)  4小時閱讀

花四小時專心看完以下五本書就好，應該都有中文版。

- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over


這些書所提的做法都比較務實，然而，不見得適合每個人。單看一本書，也會讓你的視野受到侷限。花時間去找一堆書來選，也太浪費。請先看上述幾本即可。看書並將自己覺得有用的地方做些記錄即可。

其中一本看起來是在講創業？即便你一點都不想創業，它提供的方式仍然對一般工作很有幫助！

(2) 停止接受資訊一天

如果你花了4小時看完那五本書，應該可以體驗到讓腦袋休息的重要。找一個假日，無論採用什麼方式，停止接收資訊一天 - 電腦，手機，書籍等等一概停用。隨便去做點跟工作無關的事情。

(3) 檢視並決定提升效率生產力的做法

經過了4小時學習，又經過了1天的沈澱。是時候可以決定哪一些「做法」，是最適合自己。只要是最適合自己的做法，就是自己的祕方。

如果還是想不到好方法，可以參考這篇。這是經過看了那五本書之後，經過一天的沈澱，個人認為最簡單適合自己的方式。也許對讀者也是個好的參考。

---

註1：例如，隔一陣子就會冒出來的「增加記憶力補習班」「全腦潛力開發課程」「超級記憶力」.....不過最終的結果，通常是這些提供祕方的企業巫醫們，口袋裝滿無知大眾的錢，而這些花大錢上課的群眾，其生產力與效率卻鮮少聽過提升的例子.....至少從來沒聽過任何創業有成的人曾經說：「喔！對了我創業成功的祕方，就是上了XX人的腦部開發課程，讓我記憶力變得過目不忘喔」

註2：在台灣大多以企業開班的方式存在，但這種效果極端有限。而美國英國兩地，都有針對個人的「導師服務」。但其收費都很驚人，而且大概也無法遠端服務。例如這家seven coach。也有很多個體戶，例如這位John Spence。

Scrum - 檢討完了...然後呢？

定時檢視目前的進度與問題，是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後，舉行檢討會議(驗屍會議)，找到在過去一段時間最需要改善的事項。

請參考前篇：Scrum - 回顧。檢討？驗屍！

假設團隊依照正確的Scrum的事實認定原則，踏實的列出問題。接下來就應該「解決」它。誠如前篇，所有的問題必須要有歸屬「某人」。某些事情是「很多人」或者「不知道什麼人」，這種情況的歸屬就屬於Scrum Master。

稍微強調一下，只要Scrum Master稍微不注意，就會讓歸屬人這件事情變成互相指責，試圖鞭屍，對人不對事的謾罵。但是，如果不試圖歸屬某人，就常會讓問題懸空，無法真正解決。

只要確切的定義真正的問題，就等於是產生了一半的解決方法。

不過有些常見老問題，還是值得探索一下。

例如：

(1) PM/PO 常常在Sprint中間要求修改規格，甚至新增額外的項目...

(2) 某個人的產出和績效，明顯的比其他人差很多...

(3) 某個功能的實際時程遠超過預估，以至於某些團隊成員需要很大幅度的加班...

而常見問題都有其共通性，常見的試圖解決方法也有共通性。然而，以Scrum而言，Scrum Master在此扮演非常重要的角色，因為所有的問題，其有效解決方式，應該都和Scrum Master本身有關。

Scrum Master必須要掌握以下原則：

原則一：試圖做到完美是不可能

    完美的team不可能存在，每次sprint應該試圖解決最重要的幾個問題就好。

原則二：持續做同樣的事情，不可能產生一樣的結果

    參考愛因斯坦的名言：Insanity: doing the same thing over and over again and expecting different results.

原則三：任何創意方式都應該嘗試：包括「無作為」

    
    當定義好問題之後，下一個sprint應該要試圖改善問題。但是，改善問題的本身有時候需要「時間」，而由於Scrum每個sprint都只有4週，Scrum Master應該要將「無作為」當作某些問題的處理選項。畢竟，有時候過度反應某個未來可能不存在的問題，也沒太大意義。

但是也請謹慎區分「無作為」和「逃避」，這兩者只有一線之隔(註1)。
    

針對身為Scrum Master的人，在此提供一些解決問題的範例：

(1) 時間相關的問題

由於時間是軟體專案衡量進度的唯一單位。時間是最初，也是最後要考慮的事情。因此許多檢討事項都和「時間」有莫大關係。

--- 在Sprint中某些時間估計錯誤，導致加班 ---

這在專案前幾的sprint特別常發生。建議解決方式有：

(a) 探詢真正的需求點和重要的事情，移除根本不重要的工作事項

(b) 減低時間浪費，特別是大型專案中開會的時間

(c) 無作為：因為團隊已經了解問題，而且下個sprint估算也應該會比較正確，加班問題很可能自然消失。

(d) 厲行「最大時間」單位，假設是1天。換言之，工作項目超過1天，就需要分拆成不同的項目，或者不同的完成階段。這樣可以在比較短的時間內，很快發覺時間錯估的規模。


絕對不建議解決的方式是：讓某些人繼續加班；犧牲品質；謊報進度...

--- 某個人的事情老是做不完 ---

這個也很常發生。如果是該員能力無法趕上團隊。似乎是個很大的問題。然而，絕大部分的團隊都應該利用分工導致的比較利益法則（參考這篇），根據相對優勢來分工。

細節請參見下一節：(2)人才和人力的問題


建議解決方式有：

(a) 先確定他不是不想做。假設有個不想在這個團隊努力的人，無論再怎麼調整，也都沒有意義。應該用最快的方式讓他好好離開。

(b) 讓他做可以用時間苦勞換取績效的工作，而非需要能力才拿達成的工作 ，例如將其人力保留用於意外任務或者PM臨時修改需求 

(c) 找到他的相對優勢，換言之，Scrum Master要略為調整scrum的精神，改以指派的方式指定工作。但這點需要觀察並且徹底了解他的優勢才有辦法執行。

--- 團隊有意外任務 ---

這個問題也很常見，可能的解決方式有

(a) 無作為：經過一番思考，發現這只是意外，下個sprint應該不會發生

(b) 根據前sprint所耗在意外任務的時間，重新估計下個Sprint意外任務要花的時間

(c)  設定意外任務防火牆：可以找一個專門的人，處理所有意外任務。不得已的時候也可以找工讀生，委外人員等等。

(2) 人才與人力的問題

許多軟體開發的相關研究，都一再顯示，一個好的設計師和普通的程式設計師的績效相差很大。某些1980-1990之間的研究認為可能差距10倍，當然這個10倍厲害的程式設計師的爭論很多(註2)。但就一般的情況來說，超過5個人的團隊，就自然而言有人能力以及產出比較好，而有可能有某人能力和產出都比較差。

一個團隊裡，人力和人才必須要平衡，並且由Scrum Master在前幾個sprint的結果瞭解哪些是人力，哪些是人才。人力和人才的衡量標準在於「產出」而不在於「個人能力」。換言之，即便大家都認為他能力很好，但是某些原因，他的產出只有一般般，那麼他就不是人才，而是人力。

但是，無論是人才還是人力，團隊的組合的先決條件就是1+1>2，團隊合作可以讓整個團隊獲利。Scrum Master在發現團隊有某些人的績效和產出問題時，應該優先考慮分配工作上的比較利益法則。（台灣經濟學的入門書通常會用蓋木屋與磚屋的例子：參見這裡）

要注意的是，過於追求表面上的公平，但是反而會團隊績效的降低。公平雖然重要，但是團隊合作產生的獲利更為重要。Scrum Master要能讓團隊追求團隊目標，而非追求個人公平。其方法有：

(a) 讓團隊成員看這篇文章

(b) 不要設定表面的績效衡量標準(例如：bug數量) 而是設定每個人不同的標準

(c) 所有不同的標準，朝向同一個目標。例如，在籃球比賽中，得分籃板助攻失誤阻攻...等等都是指標，而所有指標必須都要朝向球隊勝利才有意義。而不應該對每個球員設定同樣的目標。

(3) 目標的問題

目標指的是現在要做什麼，現在什麼事最重要，要達到什麼效果...簡單的說，每個專案都有其最終目標，但是在專案開發過程中，都有中間目標，PM/PO理論上應該會透過各類型中間的目標，達到（也有可能會修正）最後的目標。

然而，Scrum為了讓開發人員專注於工作，在一段短時間的Sprint是不允許修改目標。因此，如果遇到PM中間亂入，常常會造成團隊困擾。

但其實更為重要的是，如果團隊方向具有很大的不確定性，Scrum Master應該視其為「機會」，而非「威脅」。因為Scrum的天生優勢就是在於處理不確定性。

--- PM客戶或其他長官常常突然要求修改做的一半的規格---

(a) 無作為：因為這可能是專案開始的意外插曲，Scrum Master很確定下個sprint不會發生

(b) Scrum Master作為擋箭牌。在Sprint中間過程，用盡一切手腕，擋住所有需求修改，直到sprint結束為止。但是，允許PM重新開始一個sprint。

(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌，將擋下需求，或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼，放在另一個branch(分支中)，每個sprint結束之後，才檢討他的branch是否要合併。這個做法的依據在於，通常會修改的規格，都會被一改再改，與其影響團隊作業，不如將影響範圍降到最低。

--- Sprint產出PM不喜歡或不要了 那我們不是白做 ---

這樣的抱怨也很常見，它不是問題，而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可：

(a) 我們頂多白做4個禮拜，如果是project結束才發現這件事情？那浪費的成本是高得嚇人。

(b) 如果是PM不喜歡，那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤，在檢討會議應該要求PM改善此項目。



如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。

---

註1：許多事情好與壞都只有一抹微妙的界線。除了「無作為」和「逃避」之外，還有「足夠自信」vs 「自我感覺良好」；「自卑」vs「謙虛」...

註2：請參見這裡

註3：如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com

Scrum - 回顧。檢討？驗屍！

在Scrum方法中，每個Sprint結束要做事情是(1)實際交付產出 (2) 回顧檢討這個Sprint (3) 決定下個Sprint的開始。

其中，回顧檢討這個Sprint的做法，通常是一個2-4小時的Retrospective Meeting(回顧會議)，再加上改善動作。


實務上，回顧檢討是sprint最難做得好的項目。


困難因素在於，人類有天生的認知謬誤。回顧檢討會議既然是人來召開，人來組成，當然很難確切找到此Sprint的需要改善的問題，並對症下藥。偏偏，絕大多數專案Sprint問題和人有關。

說得更直白的：

    - 所有專案團隊的主要關鍵問題，都跟人有絕對的關係。每個sprint檢討會議不去檢討「人」，就等於是兇殺案發生而不去驗屍一樣。

    - 所有未來改善項目，其改善效果和速度，也都和人有絕對關係。

Scrum基本作法

在大部分的Scrum教學材料中(註1)，都很輕而易舉地說，團隊要在回顧檢討會議說，瞭解並討論三個項目：

(a) 這個sprint哪些地方團隊做得很好

(b) 這個sprint哪些地方團隊做得不好

(c) 下個sprint 團隊要做哪些事情使其變得更好



許多Scrum教學中，回顧會議都用一些簡單的方式：例如每個人提出3個意見，然後由Scrum Master逐一唸出，並且分類意見，接下來針對分過類型的意見投票，投完票之後再指定人選負責在下一個Sprint中改善。這個方式當然可以消除不少偏見和謬誤，但是容易忽略了「改善是需要針對人的行為而非針對事情」。


舉個某回顧會議中，團隊認為最需要改善的問題：

* 需求在sprint開始時還沒確定

這是個極為常見的sprint回顧問題，也通常是軟體團隊的困難。Scrum方法雖然試圖避免這個困難，但是還是非常容易在回顧會議中被提出來。筆者常看到會議記錄中，天真且單純的紀錄這一條問題....然後？也只是記錄而已。


這個紀錄有什麼問題？  ....有很大的問題！


大部分團隊，剛組成的時候，其Sprint檢討會議中，會不自由主的「避免」提出直接針對「某些人」的能力，做法，產出的問題。團隊會因為想要「努力團結」而避免針對人的討論。然而，除了超短期專案外，所有軟體專案，幾乎不可能「沒有人的問題」。反過來說，解決重要的人的問題，專案就會執行得更好。

回顧檢討要注重「人的問題」，並非單指某個人的能力不夠，也非某些人難以溝通。而是要透過實際的事物，探究人的行為造成的問題，而非問題的本身。「需求在sprint開始時還沒確定」是個血淋淋的事實。

但是，回顧檢討的重點在於，過去4周內，到底團隊成員知道是「誰做了什麼，或者沒做了什麼造成這個事實」，這才是重點。

正確的回顧檢討事實，可以是：


* 需求在sprint開始時還沒確定，因為Scrum Master沒有邀請Product Owner參加kick-off會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在kick-off會議沒講清楚，而團隊當時卻認為自己清楚需求，直到開始做了才發現不清楚，偏偏Product Owner之後就不參加每日例行會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在專案中間需求有改變，但是Scrum Master並未注意到大幅變更。

無論哪種回顧，都需要有「人」，「當時做的事情或這沒做的事情」，「產生的結果或沒產生的結果」。這樣的回顧檢討才會有意義。

但是，Scrum的方法論，看起來都是對事不對人。要如何在不交互指責的憤怒會議中，做到針對人的檢討，並能在下個Sprint還能持續團結合作？

如果你是專案經理或者Scrum Master，有三個基本的關鍵作法可供參考。(1) 先個人，再團隊。只內部，無外部。(2)  沒有問題，是最可怕的問題 。(3)實際事實，實際行為優先。

(1) 先個人，再團隊。只內部，無外部。

在會議開始之前幾天，先通知大家，回顧檢討會議的重點：先檢討自己，再檢討團隊，只檢討團隊內，不檢討團隊外。

(a) 先檢討自己的「行為」，再檢討團隊的「行為」。

並非要檢討個人的價值觀。例如，是不是很認真，很願意和其他人溝通...等等。而是自己先看自己過去做的「行為事實」，有什麼可以改善的地方。

例如：完成某功能程式碼之後，沒有先執行整合測試，就在某天每日會議報告已經完成，隔天發現，該功能有很多問題，還得修正進度，並且讓測試人員額外進行rollback。

另一個例子：這次sprint開始的時候，Scrum Master沒有堅持要Product Owner確定所有要完成的項目的需求，就讓Sprint展開。使得Sprint需要額外需求確認時間。

檢討團隊的行為，也和個人一樣。稍微不一樣的是，團隊行為通常是「個人行為」的組合。換言之，以「沒有人」為開頭的陳述就是團隊行為。Scrum Master或者專案經理，或者實際決定事情的主管，要特別注意，絕大部分的「沒有人」開頭的陳述，就要當作「自己」！

例如：沒有人發現在第二週自動測試的伺服器當機，連續好幾天的測試報告都沒有自動email出來，以至於團隊錯失及早修復bug的時間。

另一個例：沒有人提醒Product Owner開會的時間。

(b) 只檢討團隊內，不檢討團隊外

Scrum對於團隊有很嚴格的定義：做事情的人+Scrum Master = 團隊成員。

回顧檢討會議，必須要檢討內部，而不是檢討外部。許多檢討會議看似檢討內部，但其實是在檢討外部。

例如：加強和UX/UI部門溝通

這通常隱含對方不好溝通，我們只好努力跟他溝通。

又例如：公司有臨時交辦事項，團隊得分心處理

這隱含是更高階主管來的非專案任務，需要打斷專案時間。

這兩個例子並非不要改善。而是檢討回顧方式，會大幅「限制」或影響改善方式。與其他部門溝通問題，應該是具體列出過去4週，那些確切事情「被誤解」或者「理解錯誤」。根據實際的錯誤，來改變團隊對應的方法。

以UX/UI而言，釐清理解錯誤，可以用「雙方討論事情的時候，一定要至少要有mock-up」。

而以公司有臨時交辦事項為例。應該是「每個sprint預設的工作時間原本是160小時，下個sprint改為145小時，因為上個sprint臨時交辦非專案任務大約15小時」。這樣是以具體的事實，解決公司有臨時交辦事情的問題。

重點是：解決問題必須在「團隊內部能做的行為」，而非「希望團隊外去做的事情」。

會不會有回顧檢討的問題是「團隊內部解決不了」的事情？的確有可能，但是機率很低。團隊解決不了的事情，早就在sprint kick-off (開始會議)被隱含排除，所有團隊「認知到」的專案問題，幾乎都是團隊內部有方式解決或減少影響的。

(2) 沒有問題，是最可怕的問題。

有為數不少的專案團隊，在回顧檢討會議時，因為很多因素，無話可說。只好拿一些雞毛蒜皮的小事，或者看似重要但是不太重要的事情敷衍一下。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的。
* 我們的螢幕太小，寫code很不方便。
* 每天站著會議好累，可不可以坐著
* 能不能有免費可樂
* 昨天code view有說code style要統一但是還沒有
* 我們可以固定一段時間來分享一下大家coding的心得

如果檢討會議的重要事項，全都是這類型的，那有三種可能(註3)：

(A) 團隊有如NBA夢幻一隊素質極高，工作合作超級愉快，成果驚人。

(B) 團隊失去對專案的信心和動力，或根本不相信Scrum Master。

(C) 團隊絕大部分的成員經歷太淺，不知如何開始檢討。



--- (A) ---

如果你認為你現在的團隊是A，大概有49.99%的機會你是在欺騙別人。另外有49.99%的機會是你自己騙自己，或被別人騙。


--- (B) ---

如果你認為你所處的團隊是B，而你恰好是Scrum Master，或者是專案經理，或者任何領導階層。那你最最需要做的事情是「檢討改善自己」，而非「檢討改善別人」。一個團隊，大部分的人不願意說真話，最有可能有問題的一定是管理階層。

如果你認為你所處的團隊是B，而你非管理階層，也非Scrum Master。你可以先審視自己專案對社會的重要性。如果你是在核電廠，或者急診室，那你應該盡自己一切的可能，不計代價，不眠不休地改善現況。

然而，如果只是一般的軟體專案，建議你先就自己可以改善的地方檢討自己。確定當你看到不正確的事情時，會先審視自己的能力與做法。但也不需要強出頭，把自己當作革命烈士。畢竟，大部分的軟體專案並不是那麼重要。


--- (C) ---

這種情況似乎也常發生，但是解決方法很簡單。

首先Scrum Master應該在第一時間對於「雞毛蒜皮小事」，做立刻回應。對於每個小事的回應都是：下次不用等到sprint結束，中間任何時候都可以馬上找我講。這樣才會讓團隊成員養成自動自發，並容易判斷哪些事情很不重要。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的

...可以，馬上就換。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 每天站著會議好累，可不可以坐著

...不行，因為站立會議的目的就是要讓你累。以後想到這類型問題，不用等到sprint結束，任何時候馬上跟我反應。

* 能不能有免費可樂

...可以，你馬上去買，發票給我。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 我們可以固定一段時間來分享一下大家coding的心得

...可以，你馬上去發固定會議通知時間。以後一遇到技術分享的事情，只要不影響sprint時間，任何時候就直接去做，不用等到sprint結束。

(3) 實際事實，實際行為優先

Scrum的精神在實況與事實，而檢討的實況和事實在於「行為」而不在於「想法」或者「內心深處的感覺」或者「價值觀」。

這個概念非常重要。缺乏了這個概念，就容易讓檢討回顧會議，變成「互相責怪」會議。

然而，執行也很重要，執行不當，也會讓回顧檢討會議變成「互相責怪」會議。

首先會議一開始Scrum Master一定要強調，接下來的會議以事實優先，而事實當然是根據某人做的事情。在團隊成員互相不熟悉的情況下，要「反覆」的重述事實優先。並且在討論時，嚴守只看事實的承諾。

會議的形式此時就不太重要，不過：點名發表意見是個簡單的好方法。當然Scrum Master應該要自我拋磚引玉一下。

以下舉幾個常見例子：

成員J說：PM常常來叫我們改東改西，為什麼之前不確定好需求。

這時候Scrum Master應該列出這個sprint完成的task。追尋到底哪些task的需求被改變，大約影響了多少工作小時。
當然成員可能會說他不記得，就請他大致猜測一下。然後再跟sprint的時間做比對。如果改動所花時間很少，那其實不是問題。如果改動時間比率很高，才是值得關注的問題。值不值得處理，要看比率原則。-- (註4)

成員A說：我覺得我的task太多，都做不完。

這時候Scrum Master應該立刻請成員A把過去一個sprint做完的Task列出，看看是不是有做完，並且完成這些task是否有加班，或者，其實他的task是由別人完成，但是每日站立會議中並沒有說明？總之，現場應該了解事實，而事實也一定能被了解，不能等到「之後」。因為每個Sprint只檢討這個sprint，也就是過去4周左右，不可能需要很長的時間了解事實，也不可能有「我現在忘了要回去找一下」

成員K說：負責前端的人的bug太多，有時候負責後端的人都得幫忙修復bug。

這時候，Scrum Master應該立即根據bug清單，看看前端的bug數量，和負責解決bug的人。假設前端bug數量在過去sprint中有100個，而99個bug是由前端的人解決，有1個是後端的人幫忙解決，而且也只花了1小時。那麼這個問題根本不成立。只是因為後端開發伺服器的人，會特別記得「例外事件」就會有別人bug多太多害我多花時間的印象。這事情比例上多寡，是不是值得處理就要看「實際情況」列出判斷。一旦列出來給團隊成員看，就很容易大家一起判斷。

成員F：我coding速度是沒很快，但是有些速度更慢的人，就完成比較少的task，好像不太公平。

這時候Scrum Master應該根據git或其他版本控制系統，列出團隊成員程式碼數量。配合完成的task數量，bug產生數量(表示code品質不好) 以及bug解決數量(表示解決的問題)大約比對一下，看看團隊的產出是否「差不多」。當然，不同的作業系統，不同的平台，不同的程式語言是不能這樣比較。

不過大部分的情況下，這個問題並不會被提出來。但是，這個問題會存在在壓力比較大的團隊成員中，並且有礙於團隊成長。因此，Scrum Master自己必須要有客觀的衡量產出的方式！即便沒有人提出這個問題。

成員L：我們對所使用的open source工具不太了解，導致於需要學習的時間。

由於這個問題很具體，Scrum Master只需要確定這件事情是否還存在。下個sprint還會不會有不熟悉的工具需要使用。

後續？

 Retrospective檢討回顧會議中，如果找到重要的事項應該要改善。當然就是Scrum Master或者管理階層需要去「執行改善」的時候。前述內容都只有「找到問題」而關於如何有創意的解決問題，還請參閱後續文章。

---

註1：網路上參考資料非常多，例如：這裡，這裡 或者 這裡

註2：專案驗屍(postmortem)在許多人心中另有其定義，可以參考這裡，或這裡

註3：就只有這三種而已啊？確實有可能有別種，但是不太需要討論。例如：在某些軟體專案團隊的前幾個sprint，因為「蜜月期效應」的確真沒有大問題。也有很多軟體專案，本身的目標比較特殊：例如學校的畢業專案，或者政府國科會案，雖然要交付結果，但結果的本身根本不重要，當然也不有大問題。也有某些專案，並不適合採用單純的Scrum，所以無法使用檢討會議針對人進行檢討。

註4：Sprint的中途按照Scrum的精神本來就不能由PM/Owner隨意修改需求規格。但是，在這裡是Sprint的結束。如果Sprint中途真的發生臨時修改的事情，Sprint的結束當然要作為「事實」加以檢討。要注意的是，目的是檢討事實，而不是簡簡單單的說PM/Owner沒遵守「Scrum的規定」。Agile的精神中，團隊的溝通跟改善，遠比「規定」來的重要。由於軟體專案太常出現這類問題，所以後續文章也會有針對這種問題的建議解決方式。

Scrum - 專案壓力來自於無法掌握的命運

一個壓力實驗：

有兩個籠子(A,B)，都連結同一個電極器，各有一隻老鼠。A籠子中，有一個燈號和按鈕，當燈號亮起時，如果在數秒內，A老鼠沒有按下按鈕，則就會產生高壓電極，讓A,B兩籠的老鼠都被電的很不舒服。不過，如果燈光亮了，在時間內A老鼠按下按鈕，則A,B兩籠就都沒事。B籠的老鼠則是全然被動的，只要A老鼠能做好他的工作，B老鼠就沒事。當然，經過幾次電極之後，A老鼠很快就學會了一旦看到燈亮，就應該儘速去按按鈕。

過一段時間之後，哪一隻老鼠的壓力大？

經過健康檢查，A老鼠幾乎看不到壓力大的特徵。而B老鼠，則出現各種癥狀：高血壓，胃潰瘍，成長障礙等等不一而足。

(以上內容取自:數位痴呆症：作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難，而是在於自己「全然」隨著命運擺佈，無法控制。以A老鼠的情況來說，他仍然是被關著，而還得三不五時瞄一下燈是不是有亮，一旦亮了就得趕快反應。

然而，「至少有一件事情」A老鼠可以控制：他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實，固定的時間，以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內，每一個角色都有「至少可以全然控制」的事情，不但可以正確減低無法掌握命運的壓力，更能組合出正確的團隊合作方式。

Product Owner（產品擁有者或產品經理）

在傳統的「瀑布開發模式」，或者，系統整合商SI的「隨意無止盡需求模式」中，產品經理會就所有應該要做的事情列一個驚人的功能清單，交由專案經理負責領導開發。接下來的18個月，產品經理就在B老鼠的壓力下度過，即便有檢查，也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理，更有可能在每一段時間，修改需求，讓開發團隊變成B老鼠，不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任，這個責任用非常簡單而清晰的方式減低他的壓力：「撰寫並排序需要完成的使用者情境」。

專案開始時，產品經理會撰寫數個使用者情境(user story)並且排定優先順序，而每個sprint開始時，團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後，檢查這些當初答應的story是否有如預期完成，並且在下個sprint開始時，或確定，或重新排列，或增加，或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成，並且確定每sprint開頭都能選他最想要的事情先做完。因此，產品經理確實能掌握這個產品每一段時間的「樣貌」，而不是在最後關頭才求神拜佛，或者要求加班。甚至，在sprint的中間階段，若有必要，產品經理可以要求sprint停止，重新開始新sprint，用來調整後來才發現不正確的優先順序(priority)

Scrum Master (開發領導者)

過去一個團隊的技術領導者，帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理（或客戶）以及開發成員中的角色。

在傳統模式下，他若非變成一個技術獨裁者，用以壓迫成員前進並反抗大幅需求改變，就是變成試圖面面俱到的好好先生，用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description)，但事實上，困難的專案，不會因為一個很能講話的專案經理，就變得簡單。最後最常出現的結果是：專案經理總是能有效呈現「自己的貢獻和功能」，但無法反應在專案成功。換言之，常常看到自己從來不失敗的專案經理，曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理，其責任和角色也有很大的不同。而他能有效掌握的事情，也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」：完成了哪些事情，接下來要做什麼，有遇到什麼困難。確保每個sprint開始的會議，領導團隊能完成哪些使用者情境(user story)，並且確定這幾個要完成的事情，產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情，但是透過掌握每一個sprint，腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖，Scrum Master掌握過去真實進度。因而可以有效推測未來進度，並有足夠的證據顯示給產品擁有者。因此，才能有足夠的「動作權力」成為A老鼠：仍然在籠中，但掌握部分真實權力，以減少壓力。

Member (團隊成員)

傳統模式下，團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是：「某功能我們在要X月X日之前出來！」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是，在Scrum中團隊成員，決定使用者情境：「真正完成的所需要的時間」。而這個權力，僅代表一個事實：由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做，只要決定現在在做的事情，什麼時候可以完成，以及「真的去做他」。換言之，Scrum團隊真正的A老鼠，其實只有團隊成員，只有他才會真正的按下按鈕。然而，如果Scrum團隊不能掌握分工負責的精神，團隊成員很快就變成B老鼠：不是被無謂的壓力掌握自己的命運，就是試圖跳脫牢籠。

企業巫醫 - 實習生的三贏

巫醫通常會告訴病人事情的「權衡」：是想要錢還是健康？是想要貢獻祭品還是得罪惡靈？當需要獲得健康，當然就要犧牲其他東西。

許多事情的確是如此...總不能要馬兒跑，又要馬兒不吃草。

不過，對於需要創造性思維的現代企業，權衡在於真正的目標，和創意的達成方式。把馬車換成內燃機驅動的汽車，就是革命性的方式讓移動的東西大幅加速而且不用吃草。

企業實習生也是如此。

高明的策略，就可以達到三贏。普通的策略，就會犧牲某些地方。愚蠢的策略就是三輸。

以資訊科技產業來說，三贏的情況是：

對企業組織來說：有低成本的方式，獲得高潛力的「人力」。讓工讀生能先處理簡單，可學習，重複，但是可改進的工作，使團隊成員專注在複雜的開發活動上(註1)。藉此了解這些工讀生未來的潛力，同時也能透過有效分工，提升績效和產出。還能順便展現企業的社會責任決心。甚至，透過實習生循環來訓練組織內部未來的領導人才。

對社會來說：降低新鮮人「嘗試錯誤」的成本，增加投入的生產力。

對新鮮人來說：提早知道自己的興趣和能力。在還沒踏入職場之前，至少對工作有所體認，瞭解軟體工作真實的一面。無論未來是不是要從事同一行業，踏實並且正確的工作經驗，都能引導未來的發展。

普通的情況是：

對企業組織來說：在暑假期間，統一由HR辦理招募活動，發配到各個部門，和夏令營一樣在兩個月期間和團隊一起合作，可能有產出也可能沒有。

對社會來說：讓大學生研究生在暑假能有除了閒晃打電動之外的選擇。

對新鮮人來說：可能像參加夏令營一樣，但只要有認知，還是能學到很多。

有三輸的情況嗎？

會有三輸的狀況，通常是乩童式策略規劃，和不正確的預期：

乩童式策略就像是有件困難的事情，是在我們的智慧能力尚且不能了解，所以我們就去問乩童，而乩童也不懂，但是他可以「起乩」，透過起乩，從其他地方得到智慧，來回答問題。在各個部落的巫醫也都有類似「起乩」的行為。即便只是實習生策略也會有淪落到乩童式規劃的可能。而這樣的策略結果等於是靠運氣，運氣好的時候甚且可會收到好的效果，但不可能永遠都是好運氣。

對企業組織來說：只是因為「聽」企業巫醫起乩之後，覺得弄幾個工讀生來好像很不錯。因此，就隨便找幾個進來。但由於沒有組織，沒有計劃，就只能做沒有意義的工作。更有可能還會故意製造的沒有意義的工作給工讀生。參考這裡。

對社會來說：浪費了人力

對新鮮人來說：對企業造成不必要的負面印象。也沒有真正學習到工作的意涵。

如何達到實習生的三贏策略

達到三贏的方式，當然是以事實為基礎，避免乩童式目的，達到漸進式目標。

以資訊科技，或者，軟體開發相關企業來說，掌握以下事實，就容易達到三贏。

(1) 培訓是必要的：

的確有很多自動自發學習，又很聰明的學生。但是稍稍有計劃的訓練，可以大幅降低走錯路的時間。而培訓不只是「教」而已，找一些主題讓實習生自行學習也可以。

(2) 長期：

對資訊科技相關的工讀生來說，

A: 一個禮拜來兩天，連續6個月。

B: 全天候，但只有2個月。

這兩個方案看起來實際工作時間似乎一樣，但是，最後能達到的學習效果和產出，永遠是A比較好。因為，資訊科技並非勞力型的工作，而是思考智慧型的工作。當實習工讀生對技術產生興趣時，自然而然會再額外的時間，補足在技術和知識上的不足。而且，考慮到前期的培訓時間，超過6個月以上的實習才能可能達到三贏。

(3) 務實：

讓工讀生參與真正任務，但由基本開始。讓實習生去撰寫核心模組，是本末倒置的行為(註 2)。但只讓工讀生去打掃辦公室也沒太大意義 - 除非這是一間專業清潔公司。以軟體開發而言。以下幾件事情都是比較適合的切入點。

A: 簡單的執行測試計劃(test case)：是最容易入手，並且也比較能直接產出貢獻的事情。

B: 驗證文件：例如將api文件中的範例依照手冊執行看看會不會有意外，也是產出貢獻的一種。

C: 專案助理，協助收集進度，現況，簡單統計目前在版本控制系統(例如git/cvs/p4)裡的程式碼增減狀況...。這些看似助理類型的工作，可以讓工讀生對軟體專案的進展有很完整的概觀。

(4) 實習生的週期循環：

工讀生從開始招募，訓練，到離開，最好是6-18月之間。必須要簡單完成的循環規劃。實際的例子如：

A:  招募大三四研一二的資工資管資科相關學生。
B:  為期最短6的月 每週來兩天 時薪固定為XXX元。
C:  到期根據實際表現可能會續約一次。大部分會續約。
D:  座位和電腦設定已經事先準備好 (已經有check-list)。
E:  主要先進行測試相關工作，但偶爾做點瑣事（例如訂下午茶)。
F:  每年的都是由某資深工程師負責，今年負責人為某甲。
G: 合約到期離開的check-list。




(5)利用實習生培育未來的領導人才：

成熟的企業組織通常趨於緩慢成長。也就是說，除非有人離開，不然從升遷為基層主管的機會將會越來越少。然而，在團隊培育領導人才，卻是必然進行。讓有潛力的團隊成員，負責整個工讀生的循環週期。藉此，歷練作為領導主管會經歷的所有關於「人」的大小事情。畢竟，並非所有技術專精的人都適合當領導者，而透過執行實習生的策略，不只培育了實習生，也可以培育團隊的未來領導人才。即便最後發現某些技術專精的人不適合作為領導者，風險也比較低，畢竟他僅只負責工讀生，不是突然之間負責領導整個開發團隊。

很多時候，即便實習生不能達到原本規劃的要求，光是能夠陪為組織內部未來的領導人才就已經十分划算！

---

註1：「簡單，可學習，重複，但是可改進的工作」和之後提到的「無意義的工作」截然不同。以軟體開發中的測試工作而言，雖然某些情況需要大量人力測試，但是，更多狀況是當工讀生了解測試的意涵之後，大多數都能改進測試的方式，在某種程度達到自動化測試。而「做出」自動化測試程式，對工讀生來說就變成可學習到很多的工作。

註2：但也不能排除剛好招攬到一個天才中的天才的可能性。因此如果真有這樣能力的人，應該直接讓他轉成正職。

企業巫醫 - MBA無用矣

企業巫醫The Witch Doctors（中譯本為商周出版）是一本距今十一年的老書，但書中對於盛行於商業界的企業管理顧問的見解卻始終精闢。這本書的標題雖然聳動，但內容卻是不只是流於隨想批判，而是踏實的先提出數據，做橫跨時間與空間的研究，最後提出見解。破解在招搖撞騙的「大師」形象。

作者對「大師」的批評相當有建設性，幾乎在1990~2000年間的企管大師，都被他非常精闢而有建設性的評語跟分析過他們所提出的方法論：彼得杜拉克，麥可波特，愛德華戴明等等。而史蒂芬柯维，吉姆柯林斯則是被他列在不入流的範圍。


組織與企業經營的是合併藝術與專業的範圍，在因果模型中屬於複雜的範圍（參考這裡）。換言之，企業的大大小小的決策，與是否能達到效果，很難在事前看出，只能事後瞭解其因果關係。而有趣的，具有戲劇性的論點，逐漸就取代了嚴謹的研究。這讓迷惑於複雜邏輯的人，有了某種追尋的方向，從這個角度來看，「真正」的企管大師也知道這種現象，但他們一方面提出淺顯易懂的見解，另一方面也持續進行研究，這也讓大師的研究結果可供大家參考與學習。

「企業巫醫」則利用根本沒有人可能了解其因果關係，讓自己以有趣的方式解釋因果關係，從而謀利 - 開設顧問公司，提供考取證照方式，提供分析報告，寫書，演講等等。

萬一，自己解釋的因果關係沒發生，當然會拿另一套關係來彌補。就像在原始叢林部落裡的醫生一樣，當有疾病-例如嚴重流感時，會先說明和惡靈的關係，接下來可能拿某些植物的葉片猛力槌打你，打的你又痛又麻的時候叫你回家躺幾天。如果好了，證實的確是惡靈的問題，如果因此病情加重，併發肺炎，表示這樣的懲罰惡靈仍然不滿意，則會換一套方式，直到你痊癒或者死亡 - 當然死亡就表示惡靈趕不走(此段說明彷自企業巫醫一書)

在企管書籍，個人認為最最最有名的巫醫例子應當屬於「從A到A+」。用google搜尋「從A到A+」可以找到非常多人閱讀記錄，甚且有精闢的閱讀心得。該本書所說「嚴謹的長期觀察和研究取得」，分析好公司和「卓越」公司的差別，並且這些從數百家篩選出來的好公司中再篩選的卓越公司，肯定可以「永續經營」？

但是實際上根本不然。

2005年的研究就顯示A+公司，在1996-2005年間，就已經不太算是A+。不到幾年後：11家卓越公司倒了2家，9家之中僅有1家沒受到太大的金融海嘯影響。其中8家在2008危機期間甚至績效平均比其他SP500的公司還差。

從結果來看，從A到A+的理論根本沒用，但是，如同企業巫醫，作者後來竟然還寫了一本「為何A+巨人會倒下」用以自圓其說。非常典型的巫醫行為。

相對於企業巫醫，MBA的價值是否真正有用也很難說。某些研究都顯示，擁有MBA學位的CEO和沒有MBA的CEO在公司經營的成效上，沒有差異（參見這裡）。

然而，某調查顯示，擁有MBA學歷似乎對薪資有幫助(參見這裡），就這個角度來看，擁有MBA似乎還是有用的。但如果仔細看過這類調查，很明顯排除了MBA低薪，以及MBA本身的成本。

反倒已經有百年歷史的最最著名MBA產地的期刊 - 哈佛管理評論的一篇高學歷管理者的迷思。誠懇的點出問題：管理學位取得者，在學習過程中沒有學到真正學到務實的作法，而只是為了取得學位。開始工作之後，如果又沒透過工作經驗，學到新的技能，當然就沒用。

如果沒能對複雜的問題，保持清澄的理智，分析可能的問題，簡化並反覆查證因果關係，踏實的從不同的角度看問題，MBA的學歷可能會創造出一個一個的企業小巫醫，在組織裡三不五時的拿一些最新的企管叢書，當做驅趕惡靈的樹枝，到處鞭打真正在做事情的人。


企業巫醫相關文章：

如何拒絕或調整客戶不合理的需求 

實習生的三贏

時間乃最終之敵人? (上) 

時間乃最終之敵人? (下）

Scrum 認證!? 不要再浪費你的錢了!

管理類型的證照無用論，早在軟體工程界提倡Agile Movement的時候就逐漸存在。

以目前看起來取得成本最高的PMP在資訊科技的評價為例：比較客氣的說法像是這篇：雇用有PMP的專案經理需要更進一步了解其能力。而比較不客氣的說法會像是幾篇：PMP毀了專案管理，或者PMP證照無用。(註1)

而這幾年Scrum的方法論，因確切執行之後確實對軟體產品開發有顯著效益。隨之就有各類型推廣，教育，甚至認證產生。

然而，花大錢考Scrum真的有意義嗎？

(1) 認證市場

技術專業認證，絕對有其必要性，例如：醫生執照，律師執照，CCNA，SCJP，TOEIC，甚至，職業大貨車駕照，乙級中廚檢定...等等。擁有此技術執照，表示你至少「會」做某些事。

然而，非技術執照，只證實「考過」某些考試，一旦考試內容和實際會到的問題有差距，該執照就沒有太大意義。只能代表你對某些考試的努力成果。專案管理，企業經營方面的執照就屬於這類。這類型執照如果成本不是太高，倒也無妨。高收費的認證？等於是浪費錢。

一旦有高收費的認證，自然就會有認證教育訓練市場。教育訓練本身是好事情，可以讓人學習成長，但是，教育訓練本身如果是應付考試，意義就降的很低。

(2) Scrum高收費認證為何沒用？

迄今，Scrum認證有很多種類，單就Scrum Master而言，網路上隨便找，都可以找到以下七種，請參見下表。

證照名稱	考取成本 (以台幣計算)	組織
Certified Scrum Master	$30,000 (含16小時訓練課程)	Scrum Alliance
Professional Scrum Master I   Professional Scrum Master II	$4,500 $7,500	Scrum.Org
Expert Scrum Master	$3,000	EuropeanScrum
Certified Scrum Master	$3,800 (不含訓練課程) $4,500 (含8小時訓練課程)	GAQM
Scrum Master Certification	$13,500	ScrumStudy
Agile Scrum Master	$5,880	EXIN
Scrum Master Accredited Certification	$900	Scrum-Institute

筆者考過並取得最貴的認證以及最便宜的認證。其價格差距很大(三萬台幣 vs 九百台幣)。單就「考試內容」而言，最便宜的考試內容甚至還稍微難一點點。而最貴的CSM (ScrumAlliance)其實也就是台灣各教育機構最努力推廣的認證。

就考取認證作為職場價值這點來說：

1. 如果是沒有任何軟體專案經驗者，透過高收費教育訓練考取最貴的收費認證，基本上，和只自學而通過最便宜的認證，在Scrum基礎知識上根本沒差別。而在Scrum實務運作上，也沒差別：都屬於完全沒經驗。

2. 如果是有數年軟體專案經驗者，「有無證照」對於專案管理來說，只是履歷表上的一撇，一旦遇到真正的艱難問題：在Scrum上採取正確作法的經驗和收獲，遠比考證照的收穫大得多。因此，昂貴證照和便宜證照也無任何差異。

3. 沒有駕照，就不能合法開車。但沒有Scrum證照，在務實的企業中，只要你有足夠實務經驗，足夠證明支持你的能力，根本沒有問題。反之，如果有Scrum證照，但無法足以匹配的經驗，能力，而再加上創意不足，那麼甚至是有害無用。

(3) 建議作法

如果有想考Scrum相關證照，有三個強烈的建議：1.「自我學習Scrum」2.「確切運用Scrum」3.「考最便宜的」

1. 自我學習Scrum：

學無止盡，無論是Scrum還是其他未來可以出現的方法論，都值得一學。但更重要的是，如何自己學習。任何教育訓練都很有用，但也不可能完全取代自我學習。

自我學習的方式可參考這裡：如何學習Scrum 。以及這裡：如何成為Scrum專家，或者：scrum的缺點，或者 ：Scrum三件必要的事。

2. 確切運用Scrum觀念與作法在軟體專案中：

任何專案管理上的知識技能，如果不能有效運用在專案管理上，當然就沒有意義。以Scrum的每日會議(無論是不是站著開會)來說，其基本觀念在於：

「限時」 - 15分鐘
「事實」 - 只描述做完的項目，和下次打算做完的項目。(註2)
「困難」 - 只說明困難，不是要在每日會議上解決困難。

也許現實會讓Scrum Master或專案經理有所調整，但如果調整的方式不能切中Scrum觀念，則取得昂貴Scrum證照也沒有任何意義。(例如每日會議花超過40分鐘，肯定不符合任何一種Agile專案方式)

3. 以實力考最便宜的證照：

不可否認，還是有不少人認為一旦履歷表上有幾個証照，似乎會多一點點面試機會。另外，也有些有專案管理經驗者，自我學習Scrum想要有個目標來證實自己。

以這樣的立場，其實考取最便宜的證照即可。而最好是在沒有任何準備的情況下，抱著隨便考的心態。如果這樣考過了，表示Scrum的基本知識已經深入腦海中，考不過其投入成本也不高。

剛出社會的新鮮人，如果覺得萬一在面試時，有人對便宜的證照有疑慮？你可以客氣的敦請他去考考看，了解一下其考試的品質。

---

註1: 我們不是反對PMP。事實上，在其他工程領域PMP有其必要性。例如：cern的LHC是一個橫跨數十個國家，涵蓋土木，電機，資訊的龐大工程，PMP條列的九大項目，五十多種可能的文件在此就有點必要性。本文反對的是，以PMP(或其他管理證照)來判斷一個專案經理有沒有能力執行資訊軟體相關專案。

註2: 何謂做完？(definition of done)也是Scrum team需要在專案開始前定義好的。

註3: coursera.org 提供各種課程修業完成認證，目前沒有ScrumMaster，但是有類似Agile Management的課程，上課是免費，不過，取得認證約為3000~5000台幣之間。

犯錯怎麼辦 - 光是道歉是沒辦法解決滔天大錯的

人非聖賢，每個人，在任何時間地點，都可能犯錯。而一個人的職業生涯長達數十年，多少都會做出各種的蠢事。

錯誤也有各種不同的情況，細微小錯自然可以迅速改正，但如果犯下滔天大錯，不見得是道歉能夠解決。

最好的情況當然是「永遠不犯大錯」，透過個人本職學能，讓工作不會出現大錯。

但天有不測風雲，有時候錯誤的來源並非是能力不足，只是純屬於結構性意外，更可能屬於前人留下來的問題和漏洞，但無論如何，錯就是錯，大錯就是大錯。

鑄下大錯最好的做法的三步驟是：「面對」「處理」「學習」。但最後最重要的是，發揮創意把劣勢轉為優勢。

(1). 面對 - 承認錯誤，負起責任

如果是自己做的蠢事，道歉當然是必要的。如果不全然是自己做出來的，有時候也需要道歉，例如：企業產品發生問題，而你剛好是產品的負責人，雖然並不是你直接造成問題，但由於你是當時的負責人，自然要負起道歉的責任。

承認錯誤道歉僅只是第一步。負起責任不是簡單的口頭道歉，或者是土下座而已。所謂負起責任是要能「做出」行為。

既然是滔天大錯，道歉之後，隨即就是「妥善應對計畫」。這個計畫，一定要讓受影響的人清楚明白的了解。做計畫要快速，不見得完美，但是要全面，可以使用心智圖來協助達到全面性。

妥善應對計畫就和所有的計劃一樣，計畫的過程(planning)可能比計畫的本身來得重要。計畫的過程會大幅降低「連環出錯」的可能性，計畫的過程會讓「處理方式」變得有效，計畫的過程更可以讓受害的一方的影響降低。

舉例來說，如果某購物網站，因網站管理員操作不當，不小心刪掉資料庫中所有訂單，如果你是該網站管理員，首要之務當然是通知相關人等，道歉再道歉自己發生的錯誤。接下來，擬定「妥善應對計畫」：(1) 評估受影響的客戶數量，試圖從log或其他任何蛛絲馬跡中推估有多少訂單被刪 (2) 評估受到影響的金額，以及已經結帳後如果想退款的快速方式 (3) 首頁建立道歉網址 (4) 建立快速反應小組，提供電話與email讓受影響的客戶聯繫 (5) 相關社群網站或產品網站如果也受到影響需要找負責人協助  (6) 每日固定時間固定地點呈報修復進度 (7) ....這些應對計畫的細項可能有更多，但重點在於，有計劃自然能穩定人心，讓事實可以持續前進，而不會有錯誤的骨牌效應。

(2). 處理 - 誠實處理，控制損害

有計劃之後，接下來就是按計劃處理。處理原則如下：

(1) 誠實

不掩飾，但也不誇飾問題的嚴重性。誠實的處理可以挽回補償的事情，承認並道歉不能挽回的事情。在能力範圍中承諾最大的努力，但也不答應自己根本辦不到的事情。誠實的說明自己的能力不足，但也不能推託自己應該盡的努力。 

(2) 損害控制

既然是滔天大錯，大概一定會有很大的損害。按照計畫，盡可能將造成的錯誤損害降到最低。

(3) 小心骨牌效應

無論是壓力過大，或者環境本身的變化，錯誤常常是一連串發生的。處理錯誤最怕的是一錯再錯。例如，發生重大意外，投入直昇機救援，而直升機又發生重大意外的機率其實明顯的高於一般直升機普通飛行（參閱論文）。

(4) 不馬上釐清責任

此階段的重點在於執行計畫，控制損害到最低。而不是追究問什麼發生，是誰的錯！

(5) 記錄，檢討，修正計畫

即便計畫的執行很短暫，並且很急迫，也不要忘記簡單的紀錄，隨時檢討補救計畫的本身。並隨時修正計畫的執行。畢竟planning本身才是重點，而非plan。

(3). 學習 - 建立不貳過的絕對能力

當處理問題到一定的程度。無法在減低損害，但也不會讓損害繼續發生時。就是檢討學習的階段。

在這個階段，能補救都已經補救，無法挽回也都無法挽回。因此，是要檢討並且未來不會再發生的最佳時刻。檢討的方式有很多種，比較正式的做法為「post-mortem會議」。

會議進行方式採三階段，(1) 事實說明 (2) 事情經過的改善 (3) 避免再發生的作為

(1) 事實說明：

由犯錯的人或者代表人，從事件的開始說明到今天為止發生的事實。僅只是說明事實，並且釐清事實而已。

例如，購物網站不小心刪除訂單，過程可能是因為要釐清報表問題，以commandline方式進入資料庫，由於新增加一筆測試訂單資料，想要刪除資料時，執行delete的動作過程中，竟然忘記加上where condition。

事實說明過程可以提問，但目的是把事實釐清得更清楚。因此不需要問說：「為什麼當初你不這麼做」，也不應該說「你那時候腦袋在想什麼怎麼這麼蠢」之類和事實無關的話。

 (2) 事情經過的改善：

指的是「妥善因應計畫」執行過程中，有哪些可以改善的地方。基本上就是前段所述「處理」過程中的的檢討。如果有紀錄，則應該可以很快找到哪些地方還可以改善。

 (3) 避免再發生的作為：

這個階段就是重要的釐清責任階段。這個錯誤單純是人為錯誤？還是系統性錯誤？環境天災？釐清的過程要伴隨著「為了避免再發生而做的事」

單純人為錯誤：把某個人解僱就之後就不會發生？或需要靠某個檢驗機制？或讓檢查的本身加入SOP？或者過於粗心的人不適合做這個工作？怎麼樣定義何謂粗心的人？

系統性錯誤：這類型的大錯是不是歸咎於之前某人的設計不良？系統設計如何改善？系統性錯誤出現比率高不高？如果不能避免有什麼簡單方式可以大幅降低損害？是不是該雇用高手中的高手做好系統？

環境天災：特殊大地震或者異常天候？很低的機率才會發生？是不是要特別有處理方式？還是因為機率太低，可以視情況見招拆招？還是機率比想像中的高？

可以將所有「行動」逐一列出來討論。

最後，一定要「行動」。沒有行動的檢討，就不具備任何意義。而既然是滔天大錯，就必然一定要行動，才能做到不貳過。

---

I never lose, I either win or Learn: Nelson Mandela

最後，比較罕見的另一個重點：個人的創意與技能，要能將錯誤的劣勢轉為優勢。畢竟既然滔天大錯已經發生，能補救檢討都已經完成之後，有創意的將劣勢轉為優勢，是犯錯的個人最應該想的事情。

例如：一個遊戲app的廠商，推出新版本時，在伺服器端發現可承受的連線數量遠低於預估，導致於許多新玩家無法玩新版本遊戲，而舊版本又已經自動更新成新版本。當然許多新玩家會不滿，但如果遊戲廠商在處理過程中，額外彌補玩家的損失(送出高等級寶物之類)，其彌補的方式有額外的創意，這類型錯誤甚至可以額外吸引新玩家加入，這就是一種以創意和技能，將錯誤的劣勢轉為優勢的可能。

靠感覺做專案管理 - 鐵定失敗

真實故事：

有近70個工程師參與的軟體專案的組長會議中，除了專案經理之外，另有8個負責領導開發不同模組的組長一同與會。

例行的報告進度後，專案經理看了一下大家，帶著遲疑的臉說：「在兩三個禮拜大家的模組就都完成了，如果沒有問題的話，應該整個系統同時也都弄好了吧？」

負責UI以及整合模組的組長，看著大家漠然不語，也只能硬著頭皮的說：「現在最大的風險在於：如果所有模組都在最後實現完成，那根本不會有人知道組合起來會發生什麼事，所以我只好老實的建議，要不就額外增加整合測試的時間，要不就要減少某些模組的功能讓他可以早點進入整合」。

但其實大家心裡有數，這麼多人在短時間開發出來的系統，不可能在短期間整合完畢。

未料，專案經理似乎沒有體會事實，他說：「接下來大家就要在努力一點，就快要搞定了」。

可能是心情不好，在加上長時間加班的火氣：某組長就說：「我們到目前為止的問題是在於我們不夠努力嗎？」。

專案經理當然說：「不是，我知道大家都很努力...」話未說完，該組長就說：「既然問題不在於我們不夠努力，為什麼叫我們更努力，就可以解決問題？」。

專案經理：「...」

---

許多失敗的專案管理者，在遇到困境時，只會用幾個永遠不會有好結果的方式，來試圖解決問題。常見的方式像是：無意義的加班，默許降低品質，虛報進度，哭訴人力不足要求增加人力。在緊要關頭，這些作法都不會有好效果。只會這幾種方式的專案經理，儘快離開管理位階，才會是組織最大的貢獻。

最有天賦以及領導力的管理者，通常擁有不可言喻的直覺，並能透過直覺透徹專案。很遺憾的是絕大部分的人不會有這樣的天賦，特別是作為軟體專案經理者。很難具備以敏銳直覺，完成複雜系統開發。

然而，專案管理其實不需要天賦，所有人都可以透過自我學習，了解專案管理的精隨，透過自身的努力作個稱職的專案經理。和所有重要的事情一樣，首先是要了解事實。在略具規模的專案，應該透過事實的呈現，來了解專案目前進度，可能的風險，遭遇的困難，以及解決方式。

而且，只有盡可能了解事實，面對事實，才能引發可行的創意行動。


事實的取得有三個面相：

恰當的衡量：

恰當衡量，是判斷專案經理的好與壞的關鍵之一。恰當：簡而言之，必須是可行，正確，有效，有意義，精簡的衡量。

近年來Scrum蔚為風潮，其中一個重要因素是對於進度的恰當衡量。通常專案進行了一段時間之後，burndown chart可以清楚的顯示，現在專案的進展，和是否可能在預定期限內完成。也因為burndown chart展示的是不可否認的事實，讓Scrum的團隊在取得洽當的衡量之後，做正確的因應。

不恰當的衡量，出現在幾乎所有失敗的專案場景裡。

有些專案經理會依賴WBS的圖表，來看進度是否得當，但WBS是固定的無法調整，即便調整，也很難追溯過去調整的細節。WBS在軟體專案中，很難達到可行，正確，精簡。

有些專案經理，會依賴團隊成員報口述「完成」來斷定進度，在沒有看到「實品」（例如程式碼，每天自動編譯測試的build等等），口述完成不是「有效」衡量。

最慘的專案經理，會透過大型，繁複，耗時的會議，逐一確定已經完成的項目，花在「了解事實」上的時間，遠超過「做事情」的時間。這種本末倒置的既不可行，也不精簡。它唯一的好處只是在於讓原本不懂的人 - 也就是專案經理，花上不可置信的時間了解事情而已。一個不超過10人的團隊，要是每個禮拜耗費總時超過4小時在這類型的會議上，就表示專案經理沒有對技術有透悉能力，儘快換掉專案經理會是對團隊最有利的作法。

承認不確定性：

沒有人可以預知未來，必須承認不確定性，並且把可能的不確定性當做事實加以處理。當打算推測不可知的未來時，用過去之已知事實，並加上不確定性。

例如：未來3個月團隊的總人時？假設團隊成員共10人，每個月22個工作天。則總人時推測為220人日時，等於表示沒有推測。這220人日，根本沒有把「過去已知事實」考慮進去。比較好的推測應該是，220人日，減到(1) 過去3個月，這10人的總休假生病天數。再減掉(2)可能的季節性假日，例如颱風。再減掉(3) 組織已知的活動，例如員工旅遊，大型會議等等。當然，這些以過去的數字推測未來不一定準確。但是，以過去的事實推測未來的不確定性，總比當做沒看到的好得多。

一般專案管理中，不確定性會用風險管理來衡量並且控制。正是「真正」的風險，就是坦然面對事實。

失敗的專案經理在每週的報告中，會把「人力不足」當做風險，試圖避免未來失敗的責任歸屬 - 畢竟已經先在每週報告中說了，目前人力不足是風險，但是就是沒給足夠的人力。這其實單純是專案經理試圖逃避未來責任的作法。

人力不足壓根就不是真正的風險！如果人力不足是真的，那麼專案時程規劃不正確，對技術掌握不足，專案經理沒有創意來解決問題...這些才是真正的風險！假如真有人力不足，它必定不是突然出現的可能機率，它是「已經存在的必然」，風險必須是某種可能會出現的事件，萬一出現，會對專案造成及大的影響。例如，在建築專案中，大地震就是風險，必須要規範出現的機率，但它很有可能不會出現。

把不正確的風險當風險，以及不把真正的風險當風險，都是不願意面對事實的畏縮專案管理者會做的事情。

理解認知偏誤：

在專案管理中，人類認知偏誤(Human Bias) 不可能全部去除，但可以盡量避免。根據事實原則，專案經理應該承認：認知偏誤的存在，盡可能減少影響，但也要理解，不可能全然去除認知偏誤，畢竟人非聖賢，也非機器。自認為已經去除所有認知偏誤，等於是一種認知偏誤。

去除是不可能，理解並且降低偏誤，是取得真正事實的最重要的方向。

例如：在code view的精簡會議中，常出現偏誤在於，極為資深的員工的程式碼，通常比較不會被挑出問題。但根據研究，只要運用程式語言超過2年以上，資深與資淺員工，在程式碼撰寫品質並沒有太大的不同(參見約耳談軟體一書)。要去除這類型偏誤，最簡單的方式是透過系統送出匿名程式碼(在尚未commit之前)，要求成員利用email寫出自己的意見，而意見也可以是匿名。

高階主管為另一個例子：高層主管對團隊的了解，大部分來自第一線主管或二級主管。高級主管必須要認知，取的團隊資訊，必然經過過濾和扭曲。這幾乎是不可避免的事情，畢竟第一線主管或二級主管也是「人」。例如，如果發現有某團隊老是有問題，進度不佳，人力似乎永遠不足，高級主管如果找第一線主管了解原因，不會有第一線主管直接了當的說「是我的問題」。但是，一個團隊有問題，75%的原因是出現在領導者身上。去除認知偏誤的方式，除了越級訪談之外，高級主管不應該詢問一級主管的「看法」，而是直接詢問可以獲得的事實。例如：目前的問題，一級主管採用哪些「有價值的作法」來解決。

偶爾進行的團隊訓練活動，也可以將人類偏誤以討論的方式作為主題。讓團隊成員知道有偏誤的存在，自然就有可能減少偏誤的發生。



只要能根據「事實」，降低並去除認知偏誤，比較有機會在困難的專案狀況下，發揮團隊潛能，並且找到有創意的解決方案！畢竟，根據「事實」，一個營利組織必然希望團隊能帶給組織真正的價值，而非僅只是達成表面目的。

---

非戰之罪？組織變動的三個因應作法

世界越來越小，變化越來越快。企業環境更是如此

從2015年底的弊案開始，東芝一連串的裁員新聞便在網路上出現（參考這裡，這裡）。最近，由於有要徵約聘員工，通常是很難在約聘的職位上找到有經驗的軟體工程師，通常也很願意找剛畢業雖然能力不足但很願意學習的年輕人。可是，這位林先生卻是個例外。他是自願前來面試約聘職缺，而且有十幾年工作經驗的專案經理。經過詳談才知道，他也是東芝海外大幅裁員的其中一員。過往，林先生充足的筆記型電腦專案管理經驗，讓他幾乎沒有其他的資訊科技能力，對於軟體開發自然也是完全沒有經驗。環境的變動，不是他的錯，但沒有先針對可能變動而準備，會讓他失去工作之後的6個月內仍然難以找到足夠幫他解決房貸問題的方式。是不是雇用林先生？還不一定。每個人都應該針對不預期的組織變動而有因應準備，這才是重點。



在一個超過150人的組織裡，一般的員工其實很難對企業環境的變化做出正確的因應。更直接地說，組織重組(re-org)目的各有不同，但一定會順帶調整人員，而作為資訊科技的組織的一員，在重組時很可能會受到不預期的影響。

可能發生的最糟糕的情況是「被汰弱」，其次的情況是「改變工作」，最佳情況是「被留強」。

而作為資訊人員，軟體研發人員，除了隨波逐流，隨遇而安之外，對於組織的變動，能夠有正確的因應作法會是最好不過。

變動因素

組織變動的因素很多，而絕大部份通常都非單一個人所能控制（除非你是CEO）。

好的情況有：獲利太多，而跨大經營範圍；獲得額外投資；併購其他企業。

壞的情況像是：賠錢要砍部門；被別人併購；移轉工作地點到低成本的地方。

不好不壞的情況也很多：改變經營策略；將寶貴的人力資源移到別的地方；停掉某些產品研發等等；組織汰弱留強，調整人力品質。

對個人影響

組織變化對個人的真正重點在於「因組織變動產生的行為」，當然不外乎以下四項：

離開組織（資遣/開除/離職）：無論是被迫，自願，或者被自願。

執行讓員工離開團隊的任務（執行資遣/開除）：通常是中低主管的任務，也許是會執行讓人離開組織的任務，也許是更換工作內容以及更換部門。無論是被迫還是自願。

改變工作內容環境：做其他專案，升遷，換到其他部門，換老闆，更換工作地點，改變工作時間等等。

改變工作報酬：加薪，減薪，更改薪資計算方式，更改其他相關福利等等。


如果不是CXO，幾乎不太可能在很早之前，事先知道組織變動。不過，對於資訊的技術人員（程式設計師之類），即便是一般員工也能有比「隨波逐流」更好的因應作法：

做法一：事先因應。

首先，所謂事先因應，並不是事先知道各種變動因素發生。通常你知道變動因素發生的時候，一定已經是「太晚了」。

事先因應，指的是因應「黑天鵝事件」，也就是試圖因應未曾發生過的，但是一旦發生，會有劇烈變化的事情。但是，既然是黑天鵝事件，就不可能事先知道事件的種類，發生的原因，發生的時間地點。

事先因應指的是，培養自己，因應「未知」的事件。

作為資訊科技技術人員，相較於其他行業，培養自己比較簡單。剛出社會的新鮮人，當然就繼續學習新的技術，不管是程式語言，系統工具，開發流程，都有極大的學習空間。

稍微麻煩一點的是，工作7-10年左右，在可能不上不下的階段。這個階段，必須要先確實「認知」自己對現在組織的價值，並且透過這樣的認知，

乍聽之下很抽象。例如，你現在可能是軟體公司的技術小組長，帶領3-4同事進行軟體開發，這時候顯而易見的有兩個未來的選擇，(1) 你可以往技術方向前進，未來成為架構師(architect)或者技術長。這時候，培養優勢就在於，應該有意識的讓自己的知識範圍，隨著時間越擴展越大，並且不會僅侷限在這個組織之內。(2)你也可以朝向專業經理人前進。未來成為帶人的主管。這時候，培育的優勢方向在於：必須要同時兼備技術能力和判斷決策的能力。判斷決策能力的自我培養，必須要是有意識地進行。



找到自己的價值，發揮優勢，培育優勢。並且試圖擴展的優勢，讓它不僅限定在特定時段，特定組織，特定產業，甚至特定國家，。

做法二：創造選項。

至少在台灣，絕大部份的人，在任何事情上都有「選擇」。

有些選項，顯而易見。例如，有個選項是：覺得不喜歡組織的某些事情，就「選擇」離職了。

有些選項，因為認知偏誤，不容易看見。例如，有個選項可能是：覺得不喜歡組織的某些事情，就「選擇」去改變這個事情。

大部份的人，都可以輕易看出既有選項。但是，能「創造」選項的，或者看出非既有選項的。其實不多。

軟體技術上，能創造選項的例子比較多。例如，即便到今天為止，在很多企業仍有winXP的存在，但是他所使用的IE(8)很老舊。如果你的網站應用程式，一定要給這些企業使用，擺明著選項有兩種，一個是苦幹實幹，讓網站遇到IE8的時候，用比較老舊的javascript library，另一種是說服企業升級winXP。不過，只要稍微想過，很多技術人員都可以「創造」其他選項。例如部署新的firefox/chrome到winXP上。


然而，非技術的選項，能「創造」的可能性變少很多。但其實，這僅是受限於自己的目標錯置，認知偏誤，或者錯覺。

以組織變動的情況而言。也許你是「被自願」離職的員工，似乎也只有自願離開一途，但如果真的很不想被自願離開，首先需要知道你不想離開的真正目的，和你真正想要達到的目標。例如：或許是因為家庭因素，你需要穩定的收入，而非真的喜歡這裡；或許是你喜歡這個工作環境；或許是你一時之間找不到其他工作。原因可能有很多，但如果你的目標沒先想清楚，能創造的選項自然受限。

如果是因為家庭因素，你需要穩定的收入，而並非真正喜歡這個組織。你的目標應該是「在短時間能創造有穩定收入」，對於有技術背景的人，這並不難達到。難達到的是：「短時間創造極高收入」

如果是你一時找不到其他更好的工作。你需要「創造」找到更好工作的機遇。到linkedin上認識headhunter，加入open source社團，到社福機構提供技術能力當義工...等等都是可創造選項的機會。

做法三：根據事實。執行。

執行選項，特別是執行不那麼容易的選項，需要克服很多心理上的障礙。


特別是以非技術選項而言。突破個人心理上的障礙，執行最適合的選項是知易行難。

遺憾的是，沒有人能夠代替你執行。因此在此只能提出幾個參考點，協助克服認知與心理障礙。

(1) 只有自己才能負責自己的職業生涯。

(2) 軟體技術人員，在技術上都有過度自信的傾向。

(3) 沒有人剛生下來的時候是會寫程式的。

(4) 學習特定的軟體工具，平台，程式語言很重要。但要注意的是，不能把雞蛋放在同一個籃子裡

(5) 組織領導者（主管）的優劣與否的判斷很難。不過，試圖讓所有相關人等都滿意，大家歡喜的領導者，反而容易引導至糟糕的結果。




  

問對問題，如履平地。問錯問題，萬劫不復！

在不到十歲的年紀，有一次流感重症去看醫生。那時候還沒有健保，醫生通常還是會跟家長講一下治療方式可能的價格。當然，如果打一針可以好的比較快的話，多花個幾百塊可能也是值得的。但是！小時候的我很害怕打針。也許恐懼的神情被醫生發現了，他就好意地問『有比較大筒的針跟比較小筒的針，看你要打哪一種？』小時候的我，毫不猶豫的當然回答『小的針。』。結果，最後護士是拿出「兩隻」小的針筒，左右兩邊各打一針。

這個慘痛的經驗，後來讓我學習到，要完整考慮「問題」，至少要從三個方向思考：

1.問題可能不能代表真正的問題

無論是一般工作進行，還是特定專案，通常都有各式各樣的「問題」產生。有些可能是單純的疑問，例如「這個功能什麼時候可以完成？」。有些看起來比較複雜，例如「帳號如果被管理者停用，則正在登入使用中的session是否要立刻中斷？」

單純的問題，可能要考慮的更多。以「這個功能什麼時候可以完成？」為例。可以循用5 Whys 五個為什麼，來了解看似單純問題的真正本質，

例如：

「這功能完成的時間已經在系統有紀錄，為什麼要額外詢問？」--- 原詢問者回答：「只是想要知道有沒有意外」

「為什麼會想要知道有沒有意外？」 --- 原詢問者回答：「之前某高層詢問專案進度，我覺得這個功能因為比較複雜，不知道會不會有風險」

「為什麼高層會詢問專案進度？」 --- 原詢問者回答：「因為高層覺得專案預計完成時間太晚，想要用一些方式提早」

「為什麼會覺得預計完成時間太晚？想要哪種方式提早？」---原詢問者回答：「我也不知道，不要再問了！！」

2. 真正的問題很難找到

事實與真相就像船頭和船尾，首先會看到船頭，然後根據整個情況有多大多複雜，才會在最後看到船尾。

要找到真正的答案，必須要先找到真正的問題。

在許多軟體專案中，經常會有專案管理者以「人力不足」作為問題並試圖解決。但是，這個問題在絕大部份的軟體專案中，根本不真正的問題。

真正的問題也許是：

(a) 許多專案成員另有其他任務，導致投入專案的時間太少

(b) 專案需求不明朗，時常增刪變更，導致時間浪費

(c) 「人才」不足，而非「人力」不足，像是：
       (C-1) 專案管理者沒有看透技術關鍵的能力
       (C-2) 專案成員訓練不夠
       (C-3) ...其他...

而每一個問題， 背後又隱藏其他的問題。絕大部份的專案中，問題看似很多，但最重要的可能只有幾個。

專案經理的重要任務在於：決定真正重要的問題(忽略不重要的問題)，並且優先解決最重要的問題。

3. 真正的問題才能找到真正的答案

要找到真正的答案，必須要先找到真正的問題。

一旦找到真正的問題，等於已經產生一半的答案。不過，另一半的答案可能也不見得很簡單。

假設認為真正的問題是「專案需求不明朗，時常增刪變更」，答案的選擇可能有：

(a) 採取Scrum開發模式，確保每個Sprint的需求不會再改變，讓真正的專案擁有者能參與每階段的決定

(b) 暫停所有開發活動，在沒有完成細部設計與需求規格書之前，先不開始開發

(c) 再花時間去找到為什麼專案需求不明朗的背後原因，






最終，每一個成員，需要為自己找到最適切的真正答案。
隨波逐流，最終只能忍受左右兩邊各一針的結果。