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

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

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

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

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

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

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

心智圖 - 進入職場第一個必備技能

在畢業之後，投入職場的那一瞬間，假如你突然失去記憶，喪失所有技術能力，你最希望先恢復什麼能力呢？

相信一定是「學習各種技能的能力」「連結不同技能的能力」「延伸整合技能的能力」這類型的選項。概念上類似神燈可以實現一個心願，稍微有智慧的人，第一個願望，一定是希望有無限多的心願。

「心智圖」mindmap是最簡單，最容易學習的能力，可以用來連結學習延伸其他的技能的基礎。它應該是踏入職場第一個必備的技能。

心智圖極端簡單（請參見心智圖wiki），不過就是把心中想的主題畫在一張紙的中間，把跟這個主題相關的重要「事情」「項目」「動作」...等等，用線連在一起，而後還可以再延伸這些「事情」「項目」「動作」到其他細節，或者其他主題。

雖然心智圖很簡單，有不少人宣稱在高中就已經會用，但實際上熟練地使用者卻很少。

下面這張圖就是在撰寫這篇blog的後所畫的第一張心智圖：

這篇文章所用的第一個心智圖

心智圖的繪製，沒有任何特殊技巧可言，它只是想法的延伸。換言之，心智圖本身無法代替思考。但他可以讓抽象思考具體化，讓你更容易有全面的視野來觀察任何主題。這和哈利波特裡面的儲思盆有異曲同工之妙。只是你不需要去念霍格華茲，也可以學會使用心智圖。

經常利用心智圖，對職涯發展有莫大助益。然而，在台灣職場上，卻並不常看到有人使用心智圖，更常遇到某些特殊事情發生之後，才想到「當時如果用心智圖做紀錄會不會好一點」的情況。

其中一個主要因素是：缺乏練習，以至於當下沒「聯想」到有此工具。


有三個工作項目，是最好練習心智圖的機會：

1.  即時會議記錄：

即便有超強的打字能力，有意義，並能快速呈現重點的會議記錄，遠比把所有人講的的話一字不漏的記下來來得重要。臨時的會議，有結論的會議更是如此。

一邊開會，一邊將主題相關的人事物，用心智圖快速連結起來，可以在開會的過程中，掌握要點，避免會議「歪掉」，減少會議常見的三大毒瘤：「會而不議，議而不決，決而不做」

會議還沒開始，先畫出主題以及會議之後的行動

做法很簡單。首先：如果你是主持會議的人，會議還沒開始前，先在白板中間畫個圓圈，中間寫會議的目的。接下來先把「Actions」先畫出來。在會議一開始，就確保會議結束前，一定會討論出作法。如果你不是會議主持人，可以畫在筆記本上，這樣確保會議結束前，萬一Actions的圖形之下，沒有任何行動，也沒有人提及要有會後行動，你也會「主動提出」。

接下來，在與會人士慢慢來到之前，先把會議的背景，要討論的事情大綱，畫在主題的周遭，並稍加分類。以簡單的圖像表示與會人士。

會議即將開始前，先將背景以及可能討問的事項在白板列出來。以簡單的圖像代表與會者的討論。

隨著會議的進行，白板會越趨複雜，當然可以簡單的照相紀錄過。

會議的目的，當然是為了「議」- 也就是為了討論。而討論最佳的方式，莫過於把彼此的思維，投射到可以視覺化的地方。心智圖是最簡單，成本最低的好方式。

2.  分析與設計：

有複雜問題的時，可用以分析。例如：專案資源不足，遇到瓶頸，解釋複雜的人際關係等等。

有需要進行的事情時，可用以分析。撰寫技術類型的文章，就很適合先使用心智圖。

以這篇文章為例，在撰寫之前先以心智圖繪製草稿大綱，然後經過一些考量修正，先修改心智圖大綱到自己滿意的程度，在開始撰寫內文。

這篇文章的最終心智圖草稿，和第一張圖有些不同

各類流程，事物的互動，也是很適合使用心智圖分析。以旅遊為例，如果你沒有精美的行程設計，使用簡單的線上心智圖工具來繪製旅遊計畫，是方便又好用的方式。

以線上工具繪製的東京旅遊計畫

3.  任何超過3分鐘的技術問題討論：

程式設計師，專業白領階級員工常常會有「技術討論」。而技術討論光用嘴巴講效果很差。一圖勝千言，簡單的流程圖，循序圖，物件圖，永遠勝過長篇大論。

UML需要比較長的學習與練習，而心智圖卻很簡單。特別是用於觀念討論，大方向的設計（註1），

app使用者登入討論大綱

以mobile APP為例，在討論技術上，也許有程式設計師，在討論之前，先花上幾天搞個極為細緻的流程圖（例如這個），但很多時候只需要只需要三分鐘，在白板畫個圖就搞定。以右圖而言，顯示這個APP在使用這登入的討論大綱。


簡單的東西，通常可以運作得更優雅良久。心智圖並非萬能，它僅只是簡單。掌握心智圖的簡潔，快速，利用它來簡化，分析，記錄事務絕對可以讓職涯事倍功半。

---

註1: 資訊科技比較完整的分析圖形工具還是以UML比較適合

為自己工作 - 契合組織目標

雖然這幾年，創業蔚為風潮，但在台灣，大部份的人還是受雇於組織或企業。

「為自己工作」這句話看似自私，但其實所導引的結果才是對企業組織以及對個人有利。至少，對白領階級的知識工作者是如此。(註1)

表面上，大部份的人似乎並不是為自己工作。實際上，會去工作的原因是可獲得報酬（報酬涵蓋：薪資，技能知識學習，個人成長，成就感，社會參與感...等等），因此，無論表面原因為何，也無論自己是否有認知到這個事實，即便是受僱用者，絕大部份的人是為了自己，或者自己的家庭，而工作。

然而，在職場上常聽到各種抱怨心聲。其中有很大部分，其來源是沒有認知到自己是「為自己而工作」：

例如：

  *  工作很無聊學不到東西
  *  自己的價值不受到老闆重視
  *  對公司貢獻超級高，但是相對報酬卻很少
  *  做事人少，出嘴巴的人多 (特別是在政府單位)
  *  組織方向不正確，快要完蛋了

抱怨不是大問題，但失去自我方向之後，就很難在職涯上突破。個人的工作目的，必須要「由自己想辦法契合組織目標」。否則，就會有「不是為自己而工作」的念頭。一旦有這種念頭，很快的就喪失信念以及工作熱誠。

誠如前述：「為自己工作」這句話看似自私，但其實所產生的結果才是對企業組織以及對個人有利。

如果真切的認知到事實是「即使是受雇用，但自己其實是為自己工作」則進一步更能在工作上展現能力，切合組織目標。也更能給予組織更多的價值。因此，認知事實，才是生涯展開的最重要的事情。前述的理由就根本不會存在。

例如

  *  工作很無聊學不到東西：請隨意google一下就知道，企業組織雇用員工，不是為了讓員工學東西。而是解決問題或者產生新的價值。而工作學不學得到東西，也請google一下，都是取決於自己而非工作的本身。

  *  自己的價值不受到老闆重視：員工的價值就像在擺在口袋裡的針，只要你夠尖，有一天一定會穿刺而出。如果你覺得不是被擺到口袋，那就找到一個會擺你到口袋裡的組織。光是抱怨是沒有意義的。

  *  對公司貢獻超級高，但是相對報酬卻很少：先確定是自己的貢獻真的超級高。以業務員為例，許多大企業的業務，其業績是靠著大企業的品牌和產品，而非個人能力。以程式設計師為例，其程式產出，絕大部分是靠團隊能力，而非個人能力。

  *  做事人少，出嘴巴的人多 (特別是在政府單位)：也許你的生涯規劃就是要去這類型地方？如果是這樣，也沒什麼好抱怨。如果不是，就趕快離開，也沒什麼好抱怨。

  *  組織方向不正確，快要完蛋了：在一個快沉的船上，就是你發揮能力的時候。如果你自認為是個策略舵手，當然應該矯正組織方向。如果你覺得自己是在大組織裡的小螺絲，那麼你為何能「判斷」組織方向不正確？或許是你的判斷不正確？無論如何，你永遠有離開組織這個選擇。



在大部分時候，人總是可以找到契合組織目標的方式？主要有三種：「自然篩選」「個人規劃契合組織」「創業」

1. 自然篩選

當然，企業組織會自然的篩選「契合組織目標」的人。自然篩選的程度與經濟學上的「看不見的手」有過之而無不及。

例如：一個長期處於保守狀態的組織，自然而然會留下不積極的人。一個以退休津貼優渥的組織（例如公務員），自然而然，就會吸引「為了退休而工作」的人。當然，當一個人拼命念書，絞盡腦汁的通過高普考，一進去公家機關就數饅頭等著退休，自然就不會抱怨「工作無聊學不到東西」以及「自己的價值不受老闆重視」，畢竟，進來這個組織的真正目的，其實是為了退休...。

反過來說：一個新創事業，自然而然會吸引想要透過自己的能力，積極開創一片天地的人。而「退休津貼」就不可能是工作的首要目的。但工作是否有趣，組織方向正不正確，就成為關鍵因素。

雖然，個人沒辦法影響「自然篩選」，但如果你的工作目標，和「自然篩選」的目標不一致，當然會工作的很痛苦，而抱怨連連。

解決自然篩選的方式有三種：(1)離開 (2) 改變自己 (3)改變環境

其中，離開是最簡單的。辭職換新工作，自己創業，創業失敗後再創業等等，都是離開。

改變自己很難。但潛移默化之下，很多人會因為自然篩選的環境而改變自己。

改變環境其實難上加難！但是，一旦有機會做到改變環境，你就擁有一個難以言喻的經歷。這個經歷對職涯有絕對的幫助。

2. 職業生涯規劃契合組織

傳統企業組織都知道，激勵員工很重要。但組織出錢出力，費盡心思的「各種激勵」其實遠遠不如讓員工的生涯規劃契合組織目標。

就前段所述，其實無論如何，自然篩選會讓組織留下契合其目標的員工。但這需要起碼數年的時間，而前提也是組織沒有大的變故。 如果組織 - 特別是營利企業 - 的目標和其展示的行為不一致，自然篩選會失衡，要達到平衡。

因而「以個人力量做出契合組織的規劃」才是最簡單，最容易，最能獲得三贏的選擇。

除了工作內容外，每個人常遇到工作上乍看之下不可伉儷的因素，而認為自己無法契合組織目標。在你還沒有丟出辭呈之前，可以執行的個人能力與選擇非常的多。這些選擇都可以有機會做出契合組織的目標。

例如：

* 每天都做無聊的工作：既然是無聊的工作，表示是重複簡單類型，試著將這類工作最佳化，並自動化(註2)。 不知道怎麼自動化？那就去學阿，在工作中學習成長，並透過自動化的貢獻，不但提昇自己的能力，也讓組織獲取更多價值。

* 工作太多，常常超時加班，生活品質太差：所有企業組織，其存在的目的，絕對不是要員工加班完成目的。其存在的目的都是為了獲利。隨著組織分工，以及各種環境變化，容易產生以「加班」的方式來解決問題。這完全可以避免，請參考：解決專案困難的最爛方式; 如何提高工作效率; 80/20法則。也可以網路搜尋一下任何增加工作效率的方式。

重點在於去做！Just Do It！不去做，永遠不知道加班問題能否解決。

* 加薪升遷不如預期：如果是在大企業工作，加薪升遷的確常常不如自己預料。但如果你確定自己有這樣的價值，一段時間一定會被發現，如果不被發現，在離開之前請先想清楚「自己是否真有這樣的價值」？想清楚的方式也很簡單，可以去試著去應徵其他組織，看看有沒有其他組織願意提供給你更好的薪資福利。如果沒有，表示在當下你的確無此價值。如果是在小企業，薪資福利可能無法有大幅成長，但小公司能提供的通常是更多的自由和自我成長。既然你已經自然被篩選到小企業，或許本來就不是很期待制式的加薪升遷了吧。


* 組織做犯法或遊走在法律邊緣的生意：趕快辭職離開！越快越好。你確定你想要加入犯罪組織或者遊走在法律邊緣？！

3. 創業

創業，當然就是為自己工作，當然也一定會契合組織目標 - 因為你就是組織。倘若你創了業，卻因為各種原因，去做不是你訂立的目標的事情，那等於是沒創業。(註3)

不過創業成功難非常高（參考如何確保創業成功）。富貴險中求，高風險當然比較能伴隨高獲利，如果生涯的志向在此，盡可能參考已經成功的典範，或許能降低失敗機率。

---

註1: 藍領階級的勞動工作者可能不全然適用。

註2: 同註1

註3: 當然，也許你是共同創業，或者持有股份很少，那麼請視為在組織為自己工作，不要視為自己創業。

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

真實故事：

有近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%的原因是出現在領導者身上。去除認知偏誤的方式，除了越級訪談之外，高級主管不應該詢問一級主管的「看法」，而是直接詢問可以獲得的事實。例如：目前的問題，一級主管採用哪些「有價值的作法」來解決。

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



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

---

剛畢業準備加入開發團隊 - 三個必要的Scrum突圍方式

真實故事 1:

某個陰暗的冬天早上，悠晃進辦公室的當下，看到二十多個人圍成一個大圓圈。既不可能是營火晚會團康，也不會是祈福默禱活動。好奇的在旁邊觀察一下，在圈圈邊上的某個中年男子開始要求大家在這個stand-up會議報告進度，並祈許新採用的Scrum方法可以讓軟體開發有良好的發展。

真實故事 2:

某一次專案研討會中，演講者詢問與會人士，Scrum估計工時的時候，每個人每個工作天應該是多少小時才合理？新鮮人多半回答6-8小時。某些資管企管碩士生，大概讀了許多書，回答:「4小時」。而一個在軟體外包廠商工作的專案經理回答:「10小時」。

Scrum是最近幾年很流行的Agile(敏捷)開發方法之一。它的概念照理說簡單易懂，很容易在現有的團隊中採用運作，或許是因為趕流行？許多資訊產業開始以採用Scrum方法為榮。而各類型顧問也都開始教授Scrum，也開始頒發各種結業證書甚至Scrum Master的執照。就在短短數年之內，在台灣業界Scrum似乎無所不在，成功案例一個比一個容易找到。

但是就像其他簡單易懂的事情一樣。Scrum說起來比做起來簡單。實際實施的時候需要克服慣性與人性，克服與目標之間的各種障礙。但也因此，把握住Scrum的精神，最能夠讓畢業的學生以正確的方式加入軟體開發團隊 - 即便這個團隊此時並未實施Scrum。

追本朔源後，總是可以看出：太陽底下始終沒有新鮮事。Scrum最早正式出現在1986年的一篇文章中(Scrum最早的文獻)：透過個案的深入觀察，兩位日本學者對於有彈性，有效率的產品開發過程中發現一些相似的點：內建的不穩定性，自我組織的團段，互相重疊的開發流程，多面向學習，精微的控制，組織裡習得經驗的轉移..等等。文獻中的產品大部份都是硬體，例如汽車或者影印機。

乍看之下，和現在的軟體開發方法論似乎沒直接關係，但是，而後在經過其他學者的後續觀察歸納。這種以事實為基礎的彈性結構，遠比傳統官僚結構，更能在短時間達成高效率，甚且更容易產生創造性思考的價值。

理論歸理論，如何實踐理論在工作上才是重點。

近年來畢業的資訊科技背景的學生，的確在學校多少聽過Scrum，許多資管的學生甚至上了不少相關的課程。但就實務的角度，除非教授像這位荷蘭的老師（eduScrum）一樣，真心誠意的採用Scrum在課程的本身上，否則對剛畢業的碩士生或大學生而言，Scrum就只是個似乎看的到，卻無法做得到的事情。學界與業界間的藩籬，仍然巨大看似難以突破。

因此，提供以下有三個務實的方式，可以作為剛畢業的學生突破藩籬的參考。

1.理解事實

對於剛畢業的學生來說，理解事實，是基礎中的基礎，但也確是整個職業生涯需要不斷強化的地方。

以Scrum而言，每一個要做的事情 - 也許稱之為一項backlog - 在正在執行人的手上只有三種狀態：「還沒開始」，「進行中」，「已經完成」。

在每日stand-up，最常發生的是產生另一個狀態「快要完成」，也有可能混淆「已經完成」和「進行中」，更糟的是混淆「還沒開始」與「進行中」。

舉例來說，小馮在每日stand-up會議說：「訂單查詢功能已經差不多了，因為訂單查詢結果的排序雖然弄好了，可是分頁還有點問題，但是快要好了」。也許在學校裡和指導教授報告論文進度這種描述是可接受的。但是在Scrum的精神裡，這種描述不但沒有必要，而且會引發更多問題，因為，接下來大家就需要探究所謂快要好了，是還要多久？最簡單正確的描述應該是「訂單查詢功能正在進行中，原本預計2天完成，已經花了1天，接下來1天會繼續完成，目前估計和預估所需時間一樣是兩天」

重點並不在於咬文嚼字，而是在於對事情的清楚認知。當意識到一件事情沒有完成，在產品開發裡，終究是沒有完成。

每個人多少都有報喜不報憂的心態，也多少都希望別人對自己有好印象。因此，常會有自己也欺騙自己的時候。Scrum的每日Stand-up站立會議，僅說明三件事情：1. 從上次會議到現在完成了什麼 2. 在下次會議之前打算完成什麼 3.有遇到什麼困難。僅只三件事情而已，不多不少。

剛加入任何形式的開發團隊的人，能先確切的掌握和自己相關的事實，是看似簡單卻需要時間實現的基礎。

2.控制時間

既然Scrum是屬於Agile的方法論之一，當然符合最早的Agile 12項基本精神（參見這裡）。其中幾個精神和時間有莫大關係，例如，可用的軟體大重於詳細的文件，回應變化重於遵循計畫。而Scrum是最能達到的方式。

以團隊的角度，burndown chart(燃盡圖)是最能表達團隊目前能力，與專案時間預估的方式。他的做法極端簡單，請自行參考wiki。burndown chart展示了血淋淋的事實，可以透過過去一段時間的完成速度，有效預估專案可能的完成時間。由於這種做法去除了人類心態上的偏誤（例如：大家再努力一下，接下來某東西可能比較簡單...諸如此類），因此在沒有能力，沒有創意，沒有實務開發經驗的產品或專案經理的眼中，burndown chart只是拿來參考用，不能給長官看到。

以剛畢業的學生而言，最難的事情在於預估時間，特別是在比較長期複雜的任務。


解決方式為兩步驟：
  (I) 決定第一件要做的事情並且去做 
  (II) 額外增加研究項目(也額外增加時間)

(I) 決定第一件要做的事情並且去做  

對於很長的項目(backlog)，表示他可能隱含數個子項目，而每個子項目可能也不小。例如，讓系統可以支援facebook帳號登入。這可能就要分成數個項目。當然對於新鮮人，分拆項目可能會遺漏，但是，有分拆比沒分拆好，有估計比沒估計好。有分拆之後，如果有漏列項目，也可以清楚知道有漏列。有估計之後，估計的錯誤以後還可以作為其他項目的參考。
而分拆之後，就直接進行第一件要做的事情！確實的腳踏實地去做！不用等，也不用試著把項目分拆的很精細，估計得很詳盡。因為萬事起頭難，當已經開始進行，就很容易知道之前想法是不是正確，還有沒有遺漏。關於項目的分拆(breakdown)可以參考這篇。

(II) 額外增加研究項目

如果分拆之後，很明顯的仍然難以著手，就額外列出一個有限定時間的研究項目在最前面。換言之，花個固定的4到12小時進行學習與研究，將這件事情也列入整個開發流程中。時間必定要是有限的，畢竟絕大部份的產品開發，無論多困難，都還是在有限時間一定可以找到解決方案。

從另外一個角度而言，如果在有限時間無法找到合理的解決方式，對新鮮人而言或許你也並不適合做這個行業，可預見的未來裡，或許你會勤能補拙，試圖用更長的工作期間達到成效。但是這並沒有太大的意義。因為你並不拙，只是專長不在此，在有限的時間投入內，了解自己的專長不在此，或許更能幫助新鮮人找到最能讓自己發揮專長的地方。

3.確保產出

每個backlog表示一項「產出」。只要前兩個精神：理解事實跟控制時間，已經有效掌握，那麼這一項應該不會有太大意外。然而，對於剛畢業的學生來說，無論程式能力有多強，對於產出的完整性，常常會有誤解。不過這樣的誤解其實也很容易釐清。

一般軟體開發團隊，某人的某功能程式碼寫完之後，會經過以下階段：

1. 程式碼完成
2. Unit Test完成並通過
3. 簽入版本控制系統(commit)
4. 通過code review會議
5. 合併到產品主線
6. 通過自動化編譯建構
7. 通過自動化整合測試
8. 通過QA測試
9. 經過產品經理(Product Manager)確認

在Scrum一開始，便應該定義何謂backlog完成？
- 會是 1.程式碼完成就算完成？
- 還是 6. 通過自動化編譯建構 才算？
- 甚且是要等 9. 經過產品經理確認 才算？

有許多開發團隊，產出的本身是透過「默契」來達成。然而就新鮮人而言，一開始一定比較難取得「默契」。開口詢問，並且在三確定產出的「要件」是剛畢業的學生常忽略的要點。

參考閱讀-> 如何快速充實自己

工作筆記的三個重點

這幾年來，市面上有如何做筆記的書。例如記事本圓夢計畫，重點就是要這樣記，不花錢學筆記(註1)等等。

在 youtube上也有很多類似的教學影片，在youtube上搜尋"how to take notes"可以找到數十個教學範例：例如這裡。

大部份的筆記教學，大概都是透過個人經驗，指引筆記的技術。例如，有效使用不同顏色的筆，將一頁分成兩欄，左欄做為索引用途，右欄作為記錄重點用途，等等。

而筆記教學的目的，則和筆記教學的內容有根本上的差距。筆記的「目的」，通常極為崇高，例如實現人生夢想。但筆記教學「內容」，卻是極為底層，例如，試圖說明為什麼紅色的筆，適合書寫哪些東西。

其中的差距，其實只有三個難以實踐的重點。

找到並擷取重點，採取正確形式，定時審閱檢討。

重點一：重點

無論是會議紀錄，執行工作中的紀錄，在學習新技術的筆記，都應該擷取並且記錄重點。

這是無庸置疑，但不見得容易做到。

以軟體開發而言，會議記錄的首要重點在於「結論」，而結論的重點在於「會議後執行的行動」。會議的過程，熱烈討論的經過也可以摘錄重點，但都沒有最後結論來得重要。

以學習筆記而言，如果是要學習既存的軟體程式，以便於接手未來開發工作，學習的紀錄重點在於「為什麼」程式會這麼撰寫，而非程式怎麼被執行。因為「為什麼」的理由可能只有當時的工程師才知道，而怎麼被執行，卻是原始碼的本身就會告訴你的。

以日常工作記錄而言，工作八個小時之後，重點在於紀錄「今天你認為已經完成的最有價值的事」。並記錄為什麼這是有價值的。

重點的節錄，不見得只有「寫下來」這種方式。當特殊email出現(例如變更規格email)，可以直接列印出來貼在筆記本上，不但節省記錄時間，還可以完整紀錄email時間和收件人。當技術討論會議結束時，將白板的複雜圖形拍照，直接email，或者列印，或者交由虛擬助理後續處理，都是簡單有效的方式。

庶務(註2)上的重點，也應該當重點擷取紀錄，但要切記不要將紀錄庶務，當作有價值的東西。應該統一記錄在某處即可。

補充一下：

在工作中，重點難以找到的原因很多。例如：每個人認為的重點不一樣；重點有時候會轉移；這事情壓根就完全不重要...等等。

根據自己對團隊組織的存在價值的正確理解，再加上對自己目標的認知，才能記到真正的重點。

以startup為例：三個初創的創業夥伴，各有1/3的公司股份，則必須要對組織未來存在價值有正確共識。假設其中一個人目標是希望能在2年內損益兩平，而另外兩個人則是希望在兩年內能獲得某程度的市場佔有率。這兩個目標就非常不一致，透過工作筆記「重點」的紀錄，很快就可以察覺不同（請參閱第三段審閱）

以在大企業工作為例：一個10人的軟體開發團隊，其目標是在某日之前完成某產品功能。其中有3人是負責品質(QA)，另外6人負責開發(RD)，還有1位是專案經理(PM)。作為QA的人，其工作記錄重點，就應該會與PM有很大的不同。QA的所有工作相關記錄重點，應該是「到目前為止」的品質狀況。PM則應該是「到目前為止」所有利害關係人的期待是否被滿足。

重點二：形式

工作相關的筆記，正確的形式能獲取效率。

形式的優先順序應該是：

1. 圖
2. 表格
3. 條列式
4. 一段文字
5. 沒有紀錄

換言之，可以畫圖就不應該做表格，可以是表格就不應該條列，可以條列就不要用一段文字描述。可以有機會紀錄，就避免沒有紀錄。

以軟體工程師而言，mindmap (心智圖)可以擴大思慮完整性，並且將事情想得完整。UML的各種圖形標準，則已經涵蓋各種技術的表達的可能性，幾乎不需要其他規格的圖形。

如果是專案管理的角色，則RACI(表格)會很容易表達各種則關係。但是，如果要和利害關係人報告，則不可避免的應該使用投影片(slide)形式，作為表達的形式。

形式似乎很簡單。但是缺乏對形式的正確認知和練習，只會事倍功半。

一些例子：mindmap(心智圖)可以作為決策樹的前身或練習。任何文件(ptt,word)的表格，應該先在excel中實作之後，在插入投影片。任何excel的條列，必須是二維，並且應該先試圖使用pivot做簡單的分析。

重點三：審閱

定時審閱工作筆記，構成對於過去工作價值的概觀。


審閱的方式很簡單。固定時間（例如每兩週，每個月）把過去一段時間的筆記攤開，快速看過一遍。誠實的面對自己，「二次紀錄」需要改善的地方，特別是哪些事情「浪費時間」。然後，每年，固定時間（例如剛過完新年）審閱過去所有的二次紀錄的地方，再次誠實面對自己，審思如何改善。

如果你已經每天固定紀錄「最有價值的完成事項」，每個月應該花10分鐘，審閱過去的筆記。了解這些最有價值的事項，累積起來，確實讓這個月過得有價值。如果沒有，則應該「現在馬上」進行改變，即便只是稍微調整工作的方式，工作的目標，有改變都比沒改變好。

工作的會議紀錄，則要審閱並且演討「會議後執行的行動」。特別是沒有達到的行動。

工作的學習筆記，則要審閱之前有問號(?)的記錄之處，是否已經都了解。在工作中如果有發現之前紀錄沒有發現的問題，則應該額外紀錄遺漏之處。

沒有固定審閱筆記，跟沒有做筆記基本上是差不多的。

沒有審閱並事後查核會議紀錄，等於會議沒有紀錄。

審閱，能達到筆記真正的崇高目的，也就是幫助「未來」而不是僅只記錄過去。





註1:不花錢學筆記，這本書不是免費，還是要花錢買。

註2: 所謂的庶務，指的是某些資訊或者行為，本身也許有價值，也許沒價值，但無論如何，它不是這個團隊存在的重要過程或目的。例如：某個特殊系統的帳號密碼，大企業裡某些申請經費的特殊流程，辦公室阿桑固定掃地時間，福委會團購產品方式，某些高層主管定時會議的地點等等。很多大組織（特別是公務機關）中的老員工，把熟知庶務當作本身的價值。在資訊不發達的時代確實如此，但在今日已流於荒謬。

---

沈思：

1. 工作筆記的其實和紀錄的工具沒有太大的關係。不過，如果你是在西元2006年之前投入職場的人，在哪邊可以看到10年前你的筆記呢？今年(2016)你的筆記，以哪種形式存在，會留存比較久？

如何充實自己：三個自我學習的快速方法

資訊科技進展不只迅速，它順帶擴大自我學習的可能性。大部份的人只要能夠上網，就可以取得各種即時的訊息與知識。換言之，很多人都認為，資訊科技領域沒有什麼東西是學不會。

但是，沒有人一開始什麼都會。即便資訊工具改善過去知識的取得的不平等，但是自己要有意願和方式去學，這件事是沒辦法由技術來改善。


而為了充實自己而學習是沒有最好的方式。然而，多參考別人的方式，建立對自己最適合的方式是簡單並且直覺的選擇。

學習的目標，以及打算達到的廣度深度各有不同。如果只是很淺的了解個大概，只要用google搜尋，看看wiki大概就可以了。不過這樣的學習非常的片段，並且沒有組織。如果想要建立足夠的深度，這樣的方式獲取的知識過於片段，難以累積。(參考->片段知識的危害)


提供三種務實的方式，這三種方式的目標，廣度，深度，所需要的時間各有不同：

(1) 方式一：圖書館堆書

做法很簡單。只要你有想要充實並且學習的主題。無論是組織行為，還是憂鬱症；無論是個人領導力，還是專案管理。只要是社會科學，企管相關，科普等目標都蠻適合。

在這裏，假設你想要學習並盡可能瞭解"精實創業"。

首先帶著筆和紙，最好先不要帶手機或電腦，去附近的大學圖書館，或者比較大型的圖書館，例如新北市書館，台北市圖書館。

在圖書館的公用電腦，查詢"精實創業"以及相關字詞"創業"/"精實"，記下列出來的書本期刊，當然最好連同英文書也查一下。列出這類型的書籍在哪一樓哪一櫃，直接到書櫃上把所有相關書籍全部搬到座位上堆成一堆。通常相關書籍都會集中在同一櫃，所以搬動起來應該很方便。

接下來，拿起筆和紙，打開第一本書。抄下書名，作者，出版日。簡單瀏覽一下目錄以及推薦簡介，看完目錄之後，把你認為重要章節名稱，手抄在那張紙中。再打開第二本書，重複剛才的動作。如果有20本書，大概只需要花一小時就有完整清單。

然後，仔細看一下清單，排列組合並且思考一下，哪三本書，所可能涵蓋的範圍最廣，時間最新。快速地將這三本書的目錄再度瀏覽一次，選一本先看完。然後休息一下再看另外兩本。這樣大概需要花兩小時，就可以對這"精實創業"有足夠的粗淺了解。

最後，記得先休息一下。休息完之後，在腦中思考這三個小時裡面學到什麼。憑藉這三小時的記憶，在腦中描繪「精實創業」的概念與自己認為重要，或者奇怪，或者有疑惑，或者有爭議，或者和其他領域連接的地方：這些地方稱為轉折點。回到那張有目錄的紙上，找出某些書上有解釋你認為重要的轉折點，閱讀並且理解這些轉折點。如果有20本書，起碼可以找到3本以上有這類型的地方。最後這個階段，能夠建立從別人身上了解的知識批判性，不過也最花時間，可能起碼要3小時以上。

因此，花上六小時，你就可以曾原本不了解精實創業，變得比大部份的人都了解，肯定比只在google搜尋，看看wiki的人瞭解更多。不過，請注意這只是充實知識了解而已，真正的精實創業就像打籃球一樣，是沒辦法光用看的方式是不可能實踐。

這個方式，我本來以為是自創的，但是後來發現有很多人都用類似的方式，只是做法各略不同。果然太陽底下真沒有新鮮事。

關於大量閱讀，可以參考這篇：大量閱讀的三個步驟。

(2) 方式二：心智圖表徵

在已經有某些知識的背景上，試圖瞭解新的方向，或者找到自己缺乏的方向上，mindmap (心智圖)還蠻適合。他也很適合探索自己未知的事情，或者強化個人思慮的周密性。

在這裏，假設你想要學習並盡可能瞭解"軟體專案管理"。並且也認為自己想要擴張這方面的相關知識。

首先，拿一張紙（最好比A4大）一支筆，把主題寫在中間。將心裡認為可能的最重要項目連結起來。例如下圖：

把自己沒有經驗的，缺乏的地方做一些記號。通常我會使用問號？。接下來專心的根據自己缺乏的地方，尋找相關資料。重點在於，有組織的擴張知識，比片段搜尋來得有意義。

順帶一提，心智圖用法很多，"充實自己"只是其中一種。心智圖 (mindmap)不是什麼新科技，而且每隔一段時間就會有各式介紹文章，例如這裡，以及這裡。雖然介紹的範例與文章很多，但實務上，心智圖還是完全依賴人的過往經驗和創意連結。 

(3) 方法三：教學相長

這特別適用於資訊科技類型，例如程式語言，系統平台，或者任何技術。基本上，會先用其他方式（上網看書，練習實作等等）累積自認為足夠的知識與能力。接下來，想快速增加深度。或者充實自己想像不到的方向。教學相長是一個好方式。

就近找朋友或者同事，用你認為最精闢的方式，把技術和務實做法分享出去。光是在準備「教材」的過程中，就可以知道自己哪些觀念或者哪些方面不足，從準備教材的過程，就已經開始自我充實。

而最重要的是，取得聽眾的意見和問題。因為，他們可能會問出你想像不到的問題，讓你看到想像不到的視野。

實務上有幾個主動教學方式可以參考：



* 在大組織裡的主動分享

如果你是一個大企業裡面的員工，就自願性的訂一個會議室，訂一個主題，邀請一些相關的人來聽你分享某個技術。這樣的行為很簡單，而主管通常也很鼓勵主動進行。如果信心不足，可以訂一個極簡短的主題，這可以確保想來聽的人不會覺得浪費時間，也可以讓你精深的準備一個項目，提升自己的信心。



* 參加研討會：

參加研討會，並且把自己的知識在研討會上分享比想像中的容易很多。當然如果你要參加的研討會是類似IEEE的學術性質研討會，那你得花時間寫論文，而且不見得會被取用。不過，一開始先找lightning talk就很簡單，雖然只有幾分鐘，但是可以很快地獲取聽眾的真實回饋。



* blog/youtube教學影片：

近年來的分享知識方式。它無法立刻獲得聽眾回饋，但重點在於製作影片，或者撰寫blog文章之後，自己在試著重新閱覽一次，通常就可以找到許多漏掉的細節，或者過於瑣碎無用的地方，或者找到和其他人不同的觀點。

* 找到具體達成的目標：

例如：考取「低成本」證照，以Scrum為例可以參考這篇。

---

其他相關文章：
   * 如何在工作中成長
   * 換工作的面試-軟體工程師如何展現價值
   * 自我學習的三個參考方向
    * Team Leader提升能力的三個方向
  ＊ 如何提高工作效率
* 大量閱讀的三個步驟