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

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

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

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

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

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

例如：

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

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

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

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

2. 真正的問題很難找到

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

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

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

真正的問題也許是：

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

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

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

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

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

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

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

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

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

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

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

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






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

你真的知道專案進度嗎？

只要是從事程設式設計相關工作的人，必然曾經參與某專案(Project)。專案的大小不一而足，有些只有幾天或幾週，有些橫跨數年。

如果有幸負責專案管理，則無論規模大小，掌握進度是除了管理利害關係人期望之外的第二重要的事情！！而實際上，要管理利害關係人期望的最好方式就是能有效掌握真實進度。

「掌握進度」之後，才能調整應變可能發生的意外，降低風險。


只要看軟體專案進度的「掌握方式」，就大致可以判斷一個專案經理的「本職學能」到什麼程度。

一個好的專案經理，可以單靠自己，就能足以掌握專案進度。

一個普通的專案經理，可以利用流程，規範，加上開發成員的協助在一個合理的時間範圍內，掌握專案進度。

一個很爛的專案經理，會利用各種會議，各種形式文件的填寫(WBS之類)，直接或者間接的資訊，花很多時間，仍然不能掌握專案真實的進度。


很遺憾的是，好的專案經理很少，好的軟體專案經理，更是極端的少。因為他同時需要具備技術能力，透悉問題的能力，以及有效的專案管理能力。

要點一：以時間為單位

非軟體專案管理上，掌握進度的單位有很多種，例如「以執行預算」或者「實獲值」來掌握進度。（請參見PMP相關網站)

以軟體專案而言，「時間」才是真正掌握進度的單位。

當詢問負責的程式設計師：「A功能進度如何？」，而他回答「只剩下UI整合，加上DB欄位定義調整，就快好了」。這樣的回答，對於掌握進度幾乎完全沒有意義。因為，該程式設計師可能在A功能花了1天，然而UI整合與DB欄位定義調整，可能還需要另外花上3天，換言之「就快好了」根本不是真的，基本上只完成了25%。但該程式設計師並不是故意要說謊，因為或許最難的就是那25%。

程式設計師若以困難度為考量，進度就像下圖，功能完成之後，就「快要好了」。

但如果以實際時間進度為考量，則如下圖，功能完成之後，只完成了25%。離「快要好了」有很大的距離。

大部份的軟體工程師，著重於困難度。這並非不正確，只是專案管理在掌握進度時，實質進度必然是以時間為考量單位。即便「這件事情很簡單」，也必須要考慮「簡單的事情還是要有人去做」。

要點二：產出的事實

直覺上，大部份的產出當然是程式碼。實務上，非程式碼的產出許多時候會超過想像中的多 -  特別對於比較沒有專案管理經驗的人而言。

基本情況

最基本情境是，根據規格要完成功能A。一開始，程式設計師寫好了程式碼，並且自己編譯(compile)並簡單測試之後，簽入(commit)到版本控制系統中，並且和其他相關程式碼合併(merge)之後，整合成新的版本，並且新的版本經過QA測試後也沒問題。這個功能A就算完成。

在這個情境中，寫程式(coding)可能佔了70%的時間，另外merge以及測試可能佔了另外30%的時間。

專案經理要掌握的「事實點」在於：整合成新版本並經過QA測試後也沒問題，至此，功能A才算完成。

進階情況

在一個稍微複雜的專案裡面，根據規格要完成的某任務，實務上可分為「功能A」與「功能B」。一開始，幾個程式設計師分頭完成自己負責的功能，並分別自己compile並簡單測試之後，功能A與功能B就commit到版本控制系統的不同版本線(code line)。此時，QA分別進行測試，沒問題之後，協調某人「分別」合併功能A與功能B到主線(main line)並且整合成新版本。在整合過程，或多或少有需要修改的程式碼，也許在合併工能A的時候沒問題，但是在合併功能B的時候有出現問題，並也修正完畢。最後新的版本經過測試也沒問題。至此該任務才算完成。

專案經理要掌握的「事實點」在於，最後新版本經過測試也沒問題。至此，某任務才算完成。

但是，這和基本情況不同的是，整個過程很長，從數天到數週都有可能。coding本身可能僅佔50%。而合併，測試，在合併，修改等等可能佔了另外50%的時間。

與前述要點一相同，專案管理者要能掌握實際上的進展，跟「未來還需要花的時間」。在複雜的情況中要掌握，除了最後的產出事實之外，中間的進度掌握，需要靠專案管理人員對專案本身實務的了解。

專案進度的掌控，大部份是由專案經理個人獨立可以完成。其中，技術上的要素就是能否「判斷產出的事實」

而以軟體專案為例，專案管理者如要能判斷產出的事實，必須要能做「自己獨立」做下列幾件簡單的事：

1. 在版本控制系統中(git, p4, cvs等)，找出過去一段時間的所有commit過的程式碼變更，誰去變更，為什麼變更。

2. 在最近的新版本測試中，看到哪些新功能確實增加

3. 自行檢查目前bug的清單，並且找出幾個關鍵的bug



假如你是專案管理人員，而你不認為上述事情是自己應該獨立進行，或者你認為上述事情會花太多時間，


請參見下節：除去迷霧。

要點三：除去迷霧

許多「非技術背景」的專案管理人員，常常用各式各樣的大大小小的會議，來獲取專案進度的掌握：每天早上例行會議，每隔兩天來執行bug review，每個禮拜來討論整合進度...開會的本身並不會「加速」專案進行，過多的會議，肯定會「拖累」專案進度。

如果你是一位主管或專案經理，而你迫使專案成員每天花超過10%的時間(也就是40分鐘左右)在正式的會議上，並且只是為了呈報「目前進度」。那麼，你實在是個很糟糕的主管，要麻，你就盡快辭職，要麻，盡快提升自己的專案管理能力，否則你的存在只是浪費大家時間。

了解目前專案的進度，等於是除去迷霧，看清事實。除去迷霧的方式，必須要是「貼近事實」與「清晰的技術檢視」。

貼近事實

事實有時候很容易了解。例如：app要可利用facebook帳號登入。此功能容易判斷有完成，或者沒完成。

但有些時候事實很複雜。例如：某程式設計師宣稱，app要可以利用facebook帳號登入，他需要花12個工作天完成。12個工作天到底是長還是短？如果覺得太長，是因為寫程式的人能力不足？還是既有的app過於複雜，所以要加任何新功能都很難？


按部就班的貼近事實是讓該程式設計師先行「分解」這12個工作天。讓專案管理人員了解，他打算如何利用這12個工作天。

如果該程式設計師說「我這個是大概估計，12天就拿來做這一個功能阿，你還要我花時間去分哪天做什麼喔！我哪來這個時間」。這表示事實是，12天根本只是沒有基礎的猜測，他可能22天才完成，也可能2天完成。

絕大部分軟體專案，程式設計師的某行動完成都應該至少可以以「天」為最小單位，(也可是以「小時」為單位，不過太細的單位也會造成不必要的麻煩)。

超過2天估計，就應該可以分成「兩個以上的事情」，超過12天的估計，應該是建立在至少6個以上的某行動完成。


不能分解行動，表示沒有計畫，也對此任務沒有任何基本了解。

假設該程式設計師將app如何利用facebook帳號登入分解為以下工作：

(1) 修改UI: 3天
(2) 登入的程式碼: 7天

(3) 測試: 2天


專案經理應該要能看出，這樣的WBS其實完全是在應付專案經理，對貼近事實沒有幫助。他等同是一樣沒有了解任務。

如果無法將此任務交給別人，專案經理應該參與「計畫」與「分解」的過程。和程式設計師一起坐在某台電腦前面，將android studio打開，了解登入在哪邊加icon，如何到facebook取得App ID，facebook sdk如何使用。

對於有技術領導背景的專案經理，頂多花上一小時，就應該至少可以分解此任務如下：

(1) 到facebook developer網站了解sdk：1天
(2) 申請App ID以及了解相關規定：0.5 天
(3) 登入Icon要和美工討論實作方式：0.5天
(4) 執行登入，取得session：1天
(5) facebook帳號與其他帳號在db處理的不同：2天
(6) 與QA討論測試方式：1天
(7) QA測試：1.5天
(8) 其餘模糊規格的討論，例如是否可登出：0.5天

加總起來可能僅需要8天。但重點不再於天數減少，重點在於此計畫已經破除進度迷霧。當這個計畫開始執行，到了第三天，如果該程式設計師已經開始撰寫登入程式，那麼表示進度和預測相同，但如果他還在申請App ID，表示進度落後，專案經理需要調整進度，或找人幫忙。但無論如何，絕對在計畫開始執行的前期就已經知道如何處理問題，而不是到12天之後，突然發現根本無法完成。


(Android如何利用facebook帳號登入，請參考這裡)

清晰的技術檢視

前述的app利用facebook登入，專案經理之所以能和程式設計師一起坐下來定好比較清晰的時間，其首要條件在於具備清晰的技術檢視能力。

簡要的說，能區分技術難度，區分使用該技術對於專案的影響，以及，使用技術可能產生的風險。清晰的技術檢視能力，會有效提高對整個產品或者專案的洞察力。雖然，洞察力可以經過訓練磨練取得相關經驗，但實質培養卻需要有意識地進行。

技術檢視需要對技術的深度與廣度，每個專案經理所需要的技術能力各有不同，以下有個簡單的軟體專案經理自我問題清單，回答「是」就得1分。

低於5分表示是沒有技術檢視能力的專案經理。
高於8表示是罕見的擁有技術檢視能力的專案經理。

* [Yes/No] 你可以自己從版本控制系統中了解專案目前大致規模：(行數, 檔案數, 平均每工作日增加的程式碼數量)，無須依靠其他專案成員嗎？

* [Yes/No] 你可以自己找出哪些程式設計師的程式碼常常會出現bug，無須依靠其他專案成員嗎？

* [Yes/No] 你每一週會隨意抽出幾個程式碼簽入(check-in)看看有沒有明顯的問題，無須依靠其他專案成員嗎？

* [Yes/No] 你會手動編譯專案，無須依靠其他專案成員嗎？

* [Yes/No] 你隨時知道目前技術文件(程式碼註解, api 手冊, 使用手冊)撰寫的實際情況？

* [Yes/No] 你知道專案成員實際花在專案的時間

* [Yes/No] 當某個進度完成時，你可以自己檢查該進度是否真的完成，無須依靠其他專案成員。

* [Yes/No] 你會用專案開發的主要程式語言撰寫工具用程式（例如查閱系統log之類），無須依靠其他專案成員？

* [Yes/No] 你能自己估計團隊能力和團隊完成某模組的大概時程，無須依靠其他專案成員？

* [Yes/No] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？

如何組成團隊：三個步驟

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

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


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

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

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


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

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

通常，由於各種背景壓力，組成團隊的方式通常就是先根據需要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：需要團隊自我檢討任何不正確或可以強化的地方，檢討並非開批鬥大會，目的在於讓團隊能更有效率的，以及確保團隊真的朝向目標前進。

工作筆記的三個重點

這幾年來，市面上有如何做筆記的書。例如記事本圓夢計畫，重點就是要這樣記，不花錢學筆記(註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)你的筆記，以哪種形式存在，會留存比較久？

努力才會成功：三個錯誤方向

有努力不見得有收穫，但沒有努力就沒有收穫。因為努力是通往成功的唯一道路。

然而，對於努力有很多錯誤的認知方向。

以下列舉最常見的三個錯誤方向：

錯誤一：「用力」就等於「努力」

「努力」和「用力」是兩回事。

試圖只用雙手去移動開一整座高山是「用力」；研究各種方式和技術，挖出一條筆直的隧道是「努力」。

在專案遇到困難時，千篇一律的超時工作，無止盡加班是「用力」；探究各種技術的突破，讓專案有進展是「努力」。

在傳統企業推廣資訊科技應用時，苦口婆心的淳淳告誡是「用力」；透過強迫的方式，逼使使用者改變習慣是「用力」；透過各種巧思，讓人願意自己使用新系統是「努力」。

錯誤二：努力一萬小時就會成為天才

小提琴家Auer曾回答學生說：「用手指練琴，可以練一整天，但是如果用頭腦練習只要一個半小時」（參考這篇）

「努力」是需要花時間，然而，努力更要花的是思索以及驗證事物的本身是否朝著正確的方向。瘋狂的往錯誤的地方磨練一萬小時，不會讓錯誤變成正確。那努力一萬個小時變成天才，指的是有用頭腦的一萬個小時，而非不經思索的一萬小時。

但是，努力所花的時間容易被人看到，而且容易讓人產生「同情」。因而，在企業中長時間加班的人，很容易被表揚；在專案延誤時，帶領團隊不眠不休努力，容易被認為是負責任；讓專案順利完成，讓系統保持為定沒有問題，容易反倒被認為沒事做。如果你是領導者，切記不要過度獎勵沒有功勞也有苦勞的情況。

錯誤三：努力的筆直前進

如果目標與達到目標的方式是錯的，努力就變成可怕的慘狀。許多人常被一個故事所誤解（掉到奶油桶的青蛙）認為只要堅持下去，也許事情會有轉機。然而，故事裡的青蛙其實已經採用正確的方式 - 也就是一直游蛙式。如果青蛙使用更有持續性的方式維持生命 - 也就是水母漂，那麼無論如何不可能攪動成為乳酪。

幾乎任何情況下使用googlemap規劃最短時間的路程，絕大部份都不會是筆直：最短時間的路徑，通常不是最短的路徑。

努力的目標要正確：確定努力的目標是你真正想要的目標。

努力的方式要改進。努力的增加知識與能力，讓進行的方式可以朝向最正確的路徑，而不是看似最筆直的路。

在盈利企業裡面，整體努力目標應該是合法的獲取利益；然而，在企業裡面投入工作的個人，在工作上卻應該是根據自己的工作內容訂立正確的目標，如果是業務當然是獲取訂單，如果是生產部門，也許是極大化產量，也許是平衡品質與成本。但是，下班後，目標應該是自己的目標，例如陪伴家人之類。

一個業務，無論採用什麼方式當他的業績，一年後沒有達到目標，當他要「繼續努力」的時候，一定要採取別的方式。繼續堅持用舊的方式，也需要「努力」了解為什麼舊的方式可以持續使用，而不應該改變。

大部份的專案，目標通常都已經定好，然而執行的方式卻應該根據實際的情況改變。例如：在前期中期發現有重構(refactoring) 的需要，就應該先考慮重構，而不是試圖先達到某個帳面上的milestone。

大部份的辦公室日常活動，其價值都越來越低，努力的方向不是增加手指打字的速度，也不是加班完成任務，而是朝向去除完全不必要的事情，簡化或自動化簡單的事情前進。

---

沈思：

努力而失敗的例子太多，可以找到在你的工作領域上的例子嗎？

成長的最好方式 - 反省

曾子曰：「吾日三省吾身：為人謀而不忠乎？與朋友交而不信乎？傳而不習乎？」

反省是進步的最好方式。然而，檢討專案，檢討工作內容，或者檢討自己做對了，或做錯了什麼，卻是需要有結構性的方式來進行。光在腦袋裡想像是很難有具體效果。

普通人大概沒辦法跟曾子一樣每天反省自己，不過，新的一年通常是反思的最好時機。

檢討反省有三個要點：

重點一：目標導向

檢討需要有目標，就算是很隱私的個人檢討也是。反省的目標不同，就會有截然不同的結果。

以帶家人出去玩為例：

如果「全家開心出去玩」是「目標」。則旅途中的延誤，改變行程，物品遺失的檢討目標就應該是如何在意外發生的時候，讓家人仍然很高興的享受意外，享受旅程。

然而，如果心理設定的目標雖然是 ：全家開心出去玩，但檢討的目標卻是怎樣更有效率的旅行，那最後很可能導致全家旅行越來越有效率，但大家心情越來越不好。



以專案管理為例：

在專案完成，或者一個sprint的結束，在回顧檢討(retrospective) 會議的做法，通常是讓大家以「實例」，說明哪些事情做得好，哪些事情做得不好。接下來將這些實例分類，並且用投票的方式，選出最最最需要改善的幾點，指派專人在下一階段負責改善。

同樣的，負責人是以最終目標為檢討改善的目的。假設某手機APP的開發，最終目標是「能在耶誕節前有百萬使用者」，則列出最需要改善的幾點，都必須要朝最終目標前進才對。因此：「與客戶協調上架遞延到12/24日以便確保品質」就是一個不很合理的目標。

要點二：用事實去除人類偏誤

正常人都是以自己的主觀來看這個世界，因此每個人都有對事情的偏誤(human bias)。

檢討與改善的重點在於：盡可能認知人類認知偏誤的存在，讓偏誤在不造成致命影響。不過，要完全沒有影響幾乎不可能。

人類偏誤有很多，舉一些例子如下：

歸因謬誤：對於自己的行為，容易歸類為外在因素，對於他人的行為，容易歸類為內在因素。例如，自己遲到，容易認為是塞車，或者昨天太晚睡；別人遲到，容易認為是他的紀律問題。

負面偏見：人對於不好的記憶印象比好的記憶深刻。這可能和演化有很大的關係，人必須要先規避毒蛇猛獸之類的天然風險。

稟賦效應(Endowment Effect)：同樣的東西，如果已經在手上，則會難以放棄；但如果不在手上，卻認為比較容易取得。例如，自己的車子想賣，總是會想要賣比較高的價格，並且自己也會對這個高價格找出自認為合理的原因。這也是大部分物價易漲難跌的因素，因為銷售物品的人，如果已經用100元能賣出某物品：即便成本降低，即便知道降低售價可能增加業績，但在心理上很難主動降價。





誠如前述，要去除自己「所有的偏誤」是絕對不可能：沒有人是聖人，永遠不會犯錯。但是，去除不必要的偏誤讓自己朝正確的方向前進，卻是不難達到。去除自己的偏誤最好的方式就是根據事實。

因此，在檢討事情的時候僅就「事實」加以檢討。

例如：

事實是「專案每日會議，5個人有3人一定會遲到30分鐘」，根據事實檢討如何讓這3人不會遲到，不需去研究3人遲到的個別因素。也因此，根據事實，將會議時間往後延30分鐘是合理選項。

但是，如果有人試圖追尋某個老是遲到的人的「個人紀律」，「團隊精神」這並非不是事實，只是這類型的事實，沒辦法客觀認定，也不可能客觀評量某一個人的「個人紀律」比另一個人來的好。因此，這些主觀的「事實」，因太容易有主觀偏誤，不應該作為檢討的項目。


再舉另一個例子：

事實是「目前手機APP是使用者付費9美金才能下載，目前每個月約有1個新使用者」

檢討的目的如果是要增加收益，則在現在的事實基礎上，資訊是遠遠不足。因此，這個事實的討論結果勢必是「沒有足夠的事實」可以檢討。

當然要找到所有的事實也是不可能。所以，在這個例子中，起碼找到「新使用者為什麼會買」，「其他類似APP是否收費」，「其他類似的APP在不收費的情況有多少使用者」等等資訊，以便作為檢討的基礎。

方向三：行動優先

反省檢討的目的，不僅只為了知道「我錯了」，重點在於「如何才不會再錯一次」，或者「怎樣讓事情變得更美好」。

誠如前述，人非聖賢，要變成完美的人是不切實際的期望。然而，改變自己的一小部分想法跟行為，讓自己的未來變得更好，卻是可以腳踏實地的達到。

行動必須要和反省與檢討一致，至少邏輯上一致。行動的本身不見得一定要有所「行動」，有時候不做任何事情也是一個選擇，但如同這裡所描述，要確定「不行動」這個選項是和其他選項一起考慮過。

例如：「目前手機APP每個月有1個新的使用者，想推廣給更多使用者」，經過檢討之後，覺得「利用社群網站」：這裏的行動就是利用社群網站推廣。可能是利用facebook的廣告，也可以利用團隊成員每個人都到facebook上貼文，也可以建立粉絲頁。

無論如何，既然要檢討，就應該有行動。沒有行動的檢討，不具任何意義。

---

沈思：你大概多久會檢討自己一次？

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(3) 方法三：教學相長

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

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

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

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



* 在大組織裡的主動分享

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



* 參加研討會：

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



* blog/youtube教學影片：

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

* 找到具體達成的目標：

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

---

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

職業生涯的突破(基於務實的三步驟)

大部分技術人員，除了運氣很好之外，工作了幾年之後，幾乎都一定會遇到某個的瓶頸。

瓶頸可能是：無聊，無法升遷，無法勝任，人際關係，受外界誘惑，想要創業，太忙碌沒有自己的生活。

人總是有太多可以不滿的地方。但是光是在嘴巴抱怨，在心理咬牙，其實一點也沒用。

若真覺得有瓶頸，總是要有方式來突破。而我可以保證，任何技術專長的人，一定可以靠以下三個作法找出突破點。

(1) 了解事實

第一步驟，先取得自己的事實。這裡的事實是關於你的背景，你現在的工作的所有事實。不多不少的事實。Nothing more。

你要先了解事實，而不是你的想法。因為事實短時間不會改變，而想法常常變來變去。

例如：你是研究所畢業，現在約有800K存款，你現在月薪70K是事實，每天9am上班7pm下班是事實，你在公司目前做的事情是事實，這個公司目前年均毛利約15%，你過去6個月不曾去其他公司面試是事實，你有4個工作經驗是事實，你最後待的公司已經做了2年是事實，你沒有管理經驗是事實，你最後一次英文toeic成績是550分是事實，你老闆最後一次給你考績為B是事實，你的團隊有8個人是事實，你是其中第3資深也是事實，創業失敗率很高是事實。...諸如此類請列出重要的事實。

你想要東西和你的想法，不是不重要，而是你「暫且」不考慮。這點很難，但是很重要。記住，你的想法很重要，但是現在暫時先不要理會你自己的想法。

你的想法，例如：外面有更多好機會，每天上班很累，這公司很爛，薪水太少，履歷表足夠讓你找更好的工作，你在團隊里很重要但是老闆不重視，其實英文也變好了阿但是沒出差機會，對公司忠誠度很高，創業好像很不錯。...諸如此類是你的想法，有可能是事實，但也不見得是事實。

(2) 取得選擇權利

當你真正了解事實，才能執行第二步驟。

第二步驟是根據這些事實，取得選擇權，在這過程中還可以蒐集更多事實。例如，你可以去一些幾個公司面試，有些會給你offer，有些會拒絕你。這時候你的事實清單就可以多了一些可以的選項。

例如：
1. A公司你要求75K薪資，但是他拒絕給你offer。而對B公司，你提出71K的薪資，並取得offer。
2. 你跟天使基金談好可以取得500K初期投資。但是這個初期投資需要辭職才行。
3. 你撰寫了新的計畫，打算跟老闆提出來。
4. 如果不工作，你會去歐洲玩一個月把存款花光。

總之，以這個階段你有五個選擇，第五個選擇就是現在的狀態，什麼都不做。

(3) 選擇並且行動

第三步驟，就可以加入你個人的想法了，這五個選擇，是根據事實以及背景列出來的。而不根據你的幻想或者心情。無論如何，每一段時間(例如6個月)一定要做出現在有的選擇項目裡面的行動。

對！一定非動不可，即便是選項五，現在狀態什麼都不做也是一個你選擇的行為。做這樣的選擇，讓你在事實上有充分認知，如此心態上的結果就會截然不同，至少你一定會減少無謂的抱怨，而在未來的一段時間，將心思投住在你的選擇上。

(如果你覺得你的現況無法用這三個方法來突破，請聯繫我們：pm@mail.talent-service.com 。)

---

參考

努力的三個迷思
工作上學不到東西
因沒挑戰想要換跑道
工作太忙沒時間？
職業生涯的突破