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

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

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

為什麼需要強調在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，但是這裡只是舉例而已。

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

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

因此，在各部落，社群網站總是有各式的「轉職衡量」，「績效評估」，「個人職涯規劃」，「獵人頭的建議」...等等相關文章。(註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的海賊，應該怎麼分配金幣？

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

在每年不可計數的企業管理勵志書籍中，有越來越多把「時間」視為判斷事務的重要標準。想當然，個人「時間管理」變成一種必要的技能。然而，更近一步是在越短的時間，達到越驚人的效果，從早期的「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：增加工作效率？聽起來和前述的巫醫有什麼不同？就想要達到的效果來說，有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理，經過有效驗證，而且可以在未來檢討改善。

解決軟體專案困境的最爛方式 - 加班

「加班」是解決軟體開發專案困難的常見方式，但也是最爛的方式。(好方法？請參考：解決專案困境的三個方式)

負責控管專案進度的主管或專案經理，如果只會用「加班」這招來解決問題，那就不適合做軟體專案經理。

長期，非自願的(註1)加班沒辦法真正解決問題的各種經驗實證，早在許多談論軟體專案的書籍中存在。例如：人月神話，Peopleware，約耳談軟體，與熊共舞等等。從來沒有看過有任何「專案管理理論或實務認為加班有用」。

最根本的原因在於：知識工作者(軟體工程師)，其產出和付出的「超額」時間根本沒有關係，也因此，加班從來都不會解決真正的問題。

既然如此，為什麼加班文化仍然存在?

常見原因有：

1.  短期效應

特定目的的短期加班：例如參加週末創業活動，或者，產品銷售大會之前的熬夜修正demo問題等等。這些特定的目的，固定時間的活動，確實會讓人拼了命「加班」完成目的。但是，短期效應絕對不能當作一般專案管理的方式，大部份的專案都不是百米賽跑！

2.  專案經理本職學能不足，利用要求加班來展示苦勞。

專案經理沒有其他辦法，只會加總人時。因此，即便人月神話從初版印刷上市(1975)到今天已經超過40年！仍然有不少軟體專案經理即便看過人月神話這本書，仍然不可自免得繼續要求加班。因為，如果有加班，即便專案失敗，以往也被認為「沒有功勞也有苦勞」。

但是，以現在環境變化迅速，一個軟體企業中，如果「一直都只有苦勞」，被淘汰的速度遠比過去還要快得多。

3.  模糊的合約。

在某些糟糕的情況下，銷售可能會簽下模糊的合約，當專案經理看到合約內容時，其解讀方式和客戶「截然不同」。在各種專案經理訓練課程，以及各類商管叢書裡，都會說「要良好溝通」，但實務上，當專案經理手上已經拿到不合理，而且驗收條件極為模糊的合約時，幾乎不可能以「溝通」來解決。如果專案經理，誤接燙手山竽，而又沒有足夠的創新能力和技術能力來解決時，通常會誤以為軟硬兼施的「加班」，或許可解決這個問題。

但是，如果這次不能非加班的方式解決，下次就不可能有更好的方式。其後就落入惡性循環。可以google一下「台灣  接案公司」看看目前的現實情況。

4. 心靈激勵。

無論是「要有創業家的精神！」，或者是「我們在做全世界最偉大的軟體」，甚至是「世界的和平，人類的未來就靠我們了」。而又有太多人誤以為，只要有正確的心靈激勵，軟體工程師就可以像電影劇情，日夜匪懈的工作，還能有創造性的思考解決問題。

5. ...很多其他的理由。

如果你是專案管理人員，之前要求成員加班的理由到底是什麼？如果你是軟體開發人員？曾經被哪些理由要求加班？ 




既然如此，到底什麼是解決軟體專案困難的好方式？
除了可以參考這裡之外，還有三個原則：

1. 永遠都有選擇 - 「Say No」也是一個選項！

認為不正確的事情就應該說「不」。在正確的時間點不說，只會拖延，就不是個好的專案領導者。


以組織層面的角度：

就專案經理本職學能而言，一旦發現自己不是個好的專案領導者，應該要對自己說不，迅速辭職，改當一個好的程式設計師，或許是對專案最好的幫助。

就專案目標而言，倘若使用這的需求不確定，就應該選擇不做，或者選擇先做mockup，讓使用者確定需求，才不會浪費時間。

資源 - 特別是人力而言 - 在企業組織中，永遠都是有限。而良好的管理是透徹於在有限的資源中做有效的分配。加班不會讓分配變得有效，只會讓無效的分配繼續無效。

以技術層面的角度：

技術永遠有選項。一個複雜的功能，可能有起碼5種不同的實作方式，到底是選擇複雜但是有趣，還是選擇簡單，但是堅固耐用？就要視情況而定。

無論什麼事情，一定有選擇，絕對不會有「我們只能加班」這個選項。

2. 專案擁有人，必須參與專案！

近年來流行的Scrum，有一個必要的要點：專案擁有者(product owner)在每一個sprint之後要檢視產出。這個要點非常的重要，遠比正確做好燃盡圖，每天站著開會來得重要100倍。

專案擁有人，需要參與專案的每一階段進展，確實了解專案的人把時間用在哪裡，並且確實了解，每一個sprint產出都是專案擁有人最想要的產出。如此才能確保「做出對的事情」。

如何讓專案擁有者參與專案，就變成專案管理者「一定要做」的事情。

會把PMP的教材背的滾瓜爛熟 -- 溝通管理計畫書是要建立蒐集擷取散布各處的資訊，以及最終處置專案資訊的流程 -- 但實際讓連每一小階段讓專案擁有者「確定產出是他要的」都無法實際做到，簡直沒有任何意義。

在每個階段發個制式的email，裡面塞了很多複雜的圖表資訊，只會讓專案管理者「誤以為」一切都很順利。把確認每階段產出是他要的這件事情越往後延，風險就越大！

3. 磨利斧頭！

技術上的學習，會讓事情事半功倍。太陽底下沒有新鮮事，你所遇到的困難，可能已經有另外17個人遇過同樣的困難，而其中也許有9個人已經解決，解決的人之中有5個把相關資訊放在網路上。只要有正確的英文閱讀和google查詢能力，並能固定的自我學習，充實自己（參考如何充實自己），通常都能以更好更快更有效率的方式，解決軟體上的問題。

但是，千萬不要把「沒有時間學習」當作理由。當你的斧頭已經鈍到無法砍樹，還試圖用鈍斧頭砍樹來表現自己的努力，這是完全沒有意義。學習的目的就是磨利自己，將知識與技能銳化，才不會以無意義的舉動，做無意義的事情，加無意義的班。

---

註1: 凡事皆有例外，遇到天災人禍等不可抗力情況而加班其實算合理，不過即便如此，也應是極短的時間。例如，颱風天放假，隔天需要額外的工作時間。自願性質也絕對不會是長期，例如自己去參加創業週末，某種程度是自己為了自己額外工作，但頂多是一個週末，也不可能連續10個週末都在進行這樣的活動。

相關文章：
-->  換工作的面試-軟體工程師如何展現價值
-->  靠感覺做專案管理 - 鐵定失敗
-->  如何提高工作效率：三個務實的快速步驟
-->  心智圖：職場的第一個技能
-->  你確定知道專案進度嗎？
-->  80/20法則之軟體專案的三個運用重點

如何充實自己：大量閱讀的三步驟

閱讀是充實自己的最簡單，便宜，有效的方式。

閱讀不需要花錢去買書，以新北市的居民為例，只要就近找一個新北市圖書館的分館登記成為讀者，就可以線上借書。如果在該分館沒有，還可以運送其他分館或者總館的書到你最近的分館領取。方便到幾乎沒有藉口不閱讀。

閱讀是許多人的休閒活動，在躺椅上一邊讀喜歡的書，一邊吹著微風，是悠閒人生的象徵。小說文學，遊記漫畫，在這個情景下是再好不過的書。

但如果為了充實自己，那麼大量閱讀是有很大的幫助。

所謂大量閱讀和傳說中的超強速讀並不一樣

傳說中超強速讀，則是存在某個不太認識的人身上的特殊技能，總是會人試圖花錢去學習這個從來學不會的特異功能。

大量閱讀是在同一個主題下，透過不同作者的觀點來建立自己在這個主題下的知識。大量閱讀是閱讀超過7本以上同類主題的書，並且透過前人的知識，建立對這個主題的全面性概觀。

步驟一：選定主題，取得大量書籍

為了充實自己的大量閱讀，需要有個主題。例如：「創業」。也可以將主題縮小或者放大。例如：「精實創業」就是縮小範圍，而「企業管理」就是放大範圍。

有了主題自然就要去取得書籍。除非很有錢，否則大量書籍會先從圖書館借。現在圖書館幾乎都有線上查詢的網站。在線上查詢網站，查詢該主題。

以「精實創業」為例，在新北市圖書館網站，竟然只查詢到兩本。基本上除非主題過於偏僻，這種情況太不可能，當改為「lean startup」查詢之後，就找到了52本，雖然裡面有幾本不太相關，不過數量也已夠多。稍微瀏覽一下書名和簡介，就直接利用線上借書功能，盡可能借到不能借為止！通常是10本左右。



切記！！先別在網路上搜尋這個主題！！

由於撰寫網路內容的成本非常非常低，確實有可能搜尋到片段知識，但對於充實自己的角度來說，弊大於利。除非已經對這個主題有一定熟悉程度，只是需要找到特定問題的答案，否則在這個階段完全不適合利用網路！

步驟二：閱讀

等拿到那幾本書，就要開始閱讀。

大量閱讀的「閱讀」要從目錄開始。假設相關主題的書共有10本，先將這10本書的目錄，大致瀏覽一遍。根據自己的感覺，先列出哪些「章節條目」是重要的，那些可能是不重要的。對於某些「條目」 如果有很明顯的「正反面意見」就要特別留意，這個條目可能很重要。

目錄瀏覽過，就表示應該產生基本的心智圖筆記(參見步驟三）。現在請排序找到前三本要讀的書，將三本書依序讀過。

接下來，在記憶中，將這三本書的重要關鍵項目，轉折點，列在心智圖筆記中。這時候心智圖可能會一改再改。鉛筆會是最好的選擇。

當心智圖筆記大致完成，檢視自己的知識，看看對哪些條目有更深入的興趣，將剩下的7本書，以「條目」的方式閱讀。剩下的書，不需要每本的從頭看到尾，但是，可以針對有興趣的項目，或者重要的項目，特別橫向閱覽所有關於這個條目的章節。當然在過程中，如果發現這7本書裡面，有寫得非常好的，當然也可以從頭看到尾。

步驟三：心智圖筆記

專案管理的心智圖筆記

雖然說是步驟三，但是其實在閱讀的當下，就應該先做筆記。而心智圖，是最好做筆記的方式。

在閱讀的開頭，可以先把「主題」畫在中央，然後把書本的「章節條目」根據自己的興趣以及自己的分類方式，「記錄」其關聯性。這樣的紀錄，並不一定以章節名稱。以右圖為例，這個圖示紀錄「專案管理」這個主題的心智圖，其中右邊第一項「Practical way」指的「實務做法」，因此從專案計畫，執行，產出，結束，都被分到這一類。

注意！心智圖筆記的關聯與分類，乃是根據讀者(也就是你)的想法和關聯而來，他並沒有所謂對錯，他是讓你的心緒能夠抽離。除非你有鄧不利多的儲思盆，否則，這是目前已知最簡單最快速能讓你的思維視覺化的方式。

---

參考：如何充實自己：三個務實的快速方法

如何提高工作效率：三個務實的快速步驟

Give me six hours to chop down a tree and I will spend the first four sharpening the axe. 

 - Abraham Lincoln

白領工作者，或者，知識工作者的工作，追根究底是利用智慧知識和經驗，做出一些行為。例如：行銷經理，就是擴大產品的市佔率；軟體工程師，就是產出程式碼；業務員，就是賣出產品； 言情小說作家，就是寫書；專業經理人，就是領導管理團隊完成任務。

只要是知識工作者，不管用什麼方式衡量工作效率，理論上都可以持續提高。

就概念上來說，工作效率來自於三大方向，(a)技術與知識，(b)環境，(d)心理層面。

技術與知識。需要靠學習與經驗累積，而正確的學習和正確的經驗累積更為重要。請參考這三篇相關文章：自我學習的方向，片段知識的危害，工作中學不到東西。

環境。如果週遭都是工作效率極高的人，自然而然就會主動提高效率，然而環境有點運氣成分，大部份的人很難控制周遭環境。

心理層面。從馬斯洛需求階層論，到赫茲伯格的雙因素理論，心理與管理學界不乏各種相關的研究以及結論。但知識工作者，可以先參考Ted的這篇。


工作效率，絕對會和「超過」的工作時間呈反比。長期的加班對絕大部份的知識工作者而言只會降低效率，拖延成果，殘害自己與家庭。尤其是對剛進入職場的新鮮人，提升工作效率是最最最最重要的事情。工作效率的提升，會伴隨知識技能的成長，更多的時間運用，以及對組織產生真正的價值。高效率地利用時間，可以產生對職業生涯的正面循環；低效率的長期加班，則會產生很難逆轉的惡性循環。


只要願意嘗試，每個人都可以利用以下三個務實的步驟，持續並快速提升績效。做法很簡單，只需要筆記本和筆：

(1). 15分鐘每日計畫

每天開始工作前，先不要開電腦收email，而是拿出筆記本和筆，把今天最重要的幾件事情寫出來，分類事項，決定今天要先做什麼，要完成什麼，參考這篇的分析。切記先完成重要且緊急，以及重要不緊急的事情。

每日計畫只是簡要列出「打算完成」的項目，並且花一點點時間，沈思哪些真的可以完成，哪些是在80/20法則中最重要的完成項目。 也可以加上一些「保留」時間，用以處理意外。

(2). 15分鐘檢討改進

每天結束工作「後」。拿出筆記本，看看今天開始計畫的事情，哪些完成，哪些沒完成，哪些真的重要，哪些其實後來發現不重要。自己檢討一下自己的判斷為何不正確，為什麼該完成的事情沒完成，並且，簡要記錄一下，完成的項目大概花了多少時間，未完成的事項是因為什麼原因。

(3). 15分鐘重點學習

改進檢討結束後，找一小段時間，再把筆記本拿出來，看一下那些比預期晚完成的事項，哪些是因為自己的知識技能不足，導致太晚完成。列出這些項目。特別是找到「厲害的人一下子就可以做到」的事項。舉例而言，excel的PivotTable是資料分析的最基礎的方式，也是做big-data模型時，小規模測試的最好參考，會妥善利用PivotTable的資料專家，會比不會用的人更節省時間的驗證自己的模型。

在筆記本列出需要學習的項目，每天花15分鐘，在網路上學習這個技術或知識。每天只要專注於「一個能提升效率的事情」就綽綽有餘了。




知識工作者最悲慘的情況，莫過於努力了好幾天去做一件完全不需要做的事情，或者完美的執行一個完全不對的方式。

如果還沒有找到最適合自己的方法，請按照這三個務實的方式，每天花不到45分鐘，在2-3週之後一定會有顯著的效果。

---

這篇文章的乃是根據以下書籍參考，匯整，並且實際執行之後的結果。
- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over

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

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

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

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

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

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

例如：

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

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

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

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

2. 真正的問題很難找到

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

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

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

真正的問題也許是：

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

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

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

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

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

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

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

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

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

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

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

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






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

80/20法則之軟體專案的三個運用重點

軟體專案的Scrum的一次sprint之後，照例的檢討會議(retrospective)中，張經理收集了成員的意見，經過投票整理與排序，發現"不夠專注在重點上"是成員們最希望改善的地方。於是，張經理發表他的見解：「看起來大家可能是覺得瑣碎的事情太多，沒辦法專注於工作，這次新的sprint開始，大家試著把心思專注在重要的事情上」，接下來，張經理開始順道交代其他事情：「呃，上次要給法務部門的3rd party版權清單，老馮你準備一下；明天我們要定個下午茶，小陳你有空的時候幫個忙...」。....於是乎，最希望改善的地方就從未改善過。


Pareto Principle，又稱為80/20法則，指的是80%的結果來自20%的原因。這個法則是取名字義大利的經濟學家帕雷托。他觀察到1906年義大利的80%總資產屬於20%的人口。而此一情況被學者們，在其他領域也觀察到重複類似情形，因此被簡約成此法則。

80/20法則中的數字，有時候，會和實際領域不同而有所改變。例如，絕大部份的軟體，其90%的執行期間，執行的是其中10%的程式碼(參見這裡)。


在軟體專案管理中，能掌握80/20法則，等於是掌握80%的成功。

以程式撰寫為例：最重要的10%程式碼，關係到軟體運作的90%時間，掌握最重要的10%的效率與品質，就掌握系統的本身。當然，80%的bug來自於20%的程式碼。（參考這裡）

以測試為例：1000個測試案例(test case)如果能有效掌握哪20%的測試案例可以測出80%的潛在問題(bug)，就可以有效縮小測試。

以人員管理為例：在有一定人數的情況下，30%的程式設計師完成70%的主要功能。而有追蹤問題(bug)的來源時，80%的問題來自20%的模組撰寫者。


因此，掌握並改善20%重點，是任何專案的成功關鍵因素。

不過，這件事情知易行難。以反面來看，作為專案管理人，如果整個專案過程的每天都忙得焦頭爛額，隨時都有不同的人來進行不同的會議，螢幕旁邊有數十張待辦的便利貼。這很明顯的表示你一定沒有掌握到20%的重點，而你雖然很努力的想要完成任務，但並沒有朝向正確的努力方向。更慘的是，假如你認為這種忙碌可以顯示自己在組織的價值與貢獻，這種想法做為專案的領導者只會害死大家。


每個專案都是獨一無二，因此每個專案的重點20%都有所不同。然而，掌握關鍵的「20%」倒是有三個共同切入點。

1. 目的 - 真正目的

軟體專案的真正目的各有不同：有些是新產品開發，有些是既有產品增加新功能，有些是客製化專案。大部份的情況下，其目的通常不是「技術目標」，而是「達成效果」。

例如，網路商店需要開發mobile app，其目的鐵定不是為了要有一個Android APP或是iOS APP，而可能是要讓客戶在智慧型手機上也能購物。但也有有可能目的是要讓客戶在智慧型手機上容易查詢訂單。當然也有可能兩者兼具。但無論如何，技術目標：也就是有Android/iOS APP，與達成效果通常有相關，但專案管理者必須清楚兩者的不同：

達成效果是勢在必行不可或缺，但技術目標永遠都有其他選項。

網路商店不見得需要有APP才能讓使用者在智慧型手機上購物，可以使用符合智慧型手機規格的網站(所謂的響應式設計)，讓使用者利用手機瀏覽器進行購物，也可以透過簡訊或者撥打電話的方式購物，開發APP只是其中一個選項而已。

掌握真正目標之後，列出這個目標中的所有使用情境(user story)中最重要的20~40%的功能，而軟體開發的重點就放在這20~40%重要功能。集中力量完成最重要的20%，才不會「先」耗費力氣在無謂的事情上，「最後」才做真正重要的事情。

2. 時間 - 不倒退的沈默成本

時間是不會倒退的（參考這裡）。軟體專案裡的時間成本一旦投入，都屬於不會退還的沈默成本。也因為時間無法退回，一旦投入就是投入。因此，必須要確定「先」運用時間在重要的事情上。

80/20法則的重點在於：計劃先運用「未來的時間」，在有效果的事情上以先達到80%的產出。

舉例來說，一個程式設計師，在早上抵達辦公室，打開電腦的第一件事情，應該試圖確認「今天什麼事情對我最重要」，而一個開發團隊，每天第一件事情應該是「今天團隊完成什麼事情最重要」。因此，典型的scrum都會在一早展開standup meeting(快速會議)，以15分鐘的簡單開場讓專案團隊確保先投入在最需要進行的事情。

這也是一個聽起來簡單，執行起來並不容易的概念。有很多情況，團隊成員並未「徹底」實踐快速會議時的精神。

例如：某甲陳述：今天會開始開發模組A，預計今天會完成，而這也是他今天最重要的事情。然而某甲可能無意識地忽略掉昨天他的功能B的程式碼尚未簽入版本控制系統，因此實際上會議結束，其實他花了一早上在簽入程式碼，並且執行合併/建構系統。某甲並非不應該完成昨天尚未完成的事情，而是他對於「未來即將使用的時間」沒有腳踏實地的認知。

80/20法則運用在專案的時間管理上，最重要的精神在於「腳踏實地」，並且「確實展現事實」-- 缺乏這兩者，會讓80/20法則淪為壓榨程式設計師的幫兇。

3. 激勵因素與保健因素

激勵保健理論(參考這裡)，將影響人工作時心裡的滿意度因素分為兩類：激勵因素與保健因素。簡單的說，保健因素是「沒有會死，但是有也不會很高興的因素」，激勵因素是指「沒有的話不會怎樣，但有的話會很高興」。

激勵與保健理論，乃是在軟體專案管理中，80/20法則運用的最容易忽略的一環。特別是在兩個面向上：(a)軟體團隊經營
(b) 技術決策

(a)軟體團隊經營：

保健因素(薪水，電腦設備，工作環境)：無論加碼到什麼程度，對程式設計師的績效成長極端有限，然而一旦失去基本下限 - 例如減薪，則其他的激勵方式會突然失效。軟體專案負責人，應該在一開始，就先確保：保健因素是成員可以接受的。爾後專案執行過程，不要特別關注它即可。

激勵因素(個人成長，價值觀，成就感)：激勵因素才是大部份軟體開發專案成員「願意保持工作熱誠」的真正原因。負責人或者領導者，應該將團隊經營的80%重點時間放在保持激勵因素。然而每個人的激勵因素皆有不同，因此了解團隊成員個別的「真正需求」，才是需要花時間的地方。

舉例來說，有些團隊成員可能會抱怨沒有雙螢幕，雙螢幕對於撰寫程式的確很重要，專案經理想辦法弄給他雙螢幕之後，千萬不要以為這樣就會讓他心甘情願賣命。雙螢幕只是保健因素，是必要取得，但不是重點。專案領導者在團隊經營上，應該花20%的時間快速搞定保健因素，而後，花80%的時間確保激勵因素的存在。

缺乏激勵因素的團隊成員，並不代表一定會離職，也不一定代表任務不能完成。一個能力很強的人，可能因為暫時沒有其他選項而在現在的位子上滿足最低限度貢獻。這樣成員，反而成為一個潛在的問題，他隨時有可能因為任何短暫膚淺的因素而離開，更糟的是不離開而成為團隊困擾。而這種情況並非是該團隊成員的問題，而是團隊領導者，沒有辦法找到並維持適合的激勵因素。

(b)技術決策：

既然是軟體開發專案，必然會歷經各種技術決策。80/20法則一定是技術決策的主要運用重點。

以功能而言，如果有A功能與B功能在短時間之內，只能選擇完成一個。則技術決策應該從幾個方向考量：

方向一：中大型軟體專案一定有20%的重要功能，會滿足80%的使用者需求。哪一個功能屬於這類。

方向二：如果A與B都滿足方向一，則考慮哪一個功能會直接滿足「專案目的」。

方向三：如果A與B都滿足方向一與二，則考慮兩者哪一個對於此專案是屬於保健功能(沒有會死的功能)，哪一個屬於激勵功能(有的話會很高興的功能)。並且考慮專案目的，是屬於維護且保守的專案，還是開創性的新專案。開創性的專案自然優先考慮激勵功能；而維護型或保守的專案，當然要先考慮保健功能。



80/20法則的有效運用是判斷一個優秀的專案領導人的條件。以反面例子而言：有很多15年以上專案管理經驗的所謂專案經理，他所有的經驗可能都在於無謂的忙碌與焦頭爛額中度過，這樣的15年和1年沒有什麼不同。如果你是這樣的專案經理，為了團隊好，或許應該考慮轉換適合的工作跑道。

資深與中高階人才選用：三個要點

在資訊科技領域裡，資深或中高階人才選用遠比找到剛畢業很有潛力的人來的困難重重。

詭異的是，幾乎所有已經在資訊科技領域工作7年以上的資深專家，通常多少都會遇到獵人頭(hunter)的引誘。事實上，中高階的職缺其實很少，由組織內部升遷的機會很大。然而，如果真的從組織外部尋找，雖然看似符合條件者眾多，但能有效媒合卻是難上加難。

要點一：情境實例面談

絕大部份的中高階人才之所以是「人才」，乃是根據其真實的過去事蹟。而非未來想像。

在書面篩選階段，通常是根據過去工作經歷，決定要不要請來進一步面談。

而在面試階段，卻常落在討論未來的理想和展望。的確，未來的理想跟展望，的確很重要。不過，在面試階段，要判斷此人能否實現理想和展望，應該是根據其過去的「理想與展望的實際產出」。

一般外商HR的實務操作方式為：面談時著重於情境「實例」。(SAR: Situation Action Result) 

例如，有個軟體研發部門RD主管的履歷表中，表示有帶領軟體開發團隊開發軟體。此時開放性問題無法真正展現該主管的經歷，應該採用情境實例問題，了解過去的「真實例子」。

-- 爛問題範例 --

未來取向的開放性問題：「未來你如何帶領開發團隊？」「你覺得RD團隊應該如何與業務團隊溝通？」....這種問題的回答必定是十分鐘不著邊際的長篇大論。

-- 好問題範例 -- 

初級情境實例問題：「目前你的團隊共多少人，其中有直接report給你？」「此專案你本人有參與寫程式嗎？」「此專案你本人有執行code review嗎？」「這個專案一共大約產生多少行程式碼？」

......初級問題著重能取得簡單而無可偏頗的答案，答案可能為「是或否」，可能是「數字」。回答應該是在10秒內。




中級情境實例問題：「在帶領N個人的團隊裡，你個人做過哪一件事情對團隊合作最有幫助？你怎麼做的？結果是什麼？」「在之前的工作裡，你做過最糟糕的決定是什麼？為什麼此決定是最糟糕？」

......中級問題著重於過去的某單一事實，必須引導回答針對這個人的實際作為，以及產生的結果。如果詢問的問題是負面資訊，例如犯下的錯誤。必須確定是問到犯下「最大的錯誤」。在面談過程，如果一個中高階主管，在過去7年的職業生涯沒犯任何錯誤（或者拿一些小小的失誤當作談話材料），很可能是隱藏事實，但更糟糕的是，他不覺得自己有任何錯誤的地方。


高級情境實例問題會和另外兩個要點：「本職學能」以及「獨立執行單位有關」請參考以下兩節。


簡而言之，SAR的基本概念很簡單：找出事實，而非空想；討論實際，而非理想；了解過去，而非未來。這部不代表理想與未來不重要，而是要判斷中高階人才的理想與未來，應該是看他「過去實踐過多少」，而非不是他「打算未來實踐多少」。


參考資料：(Careerly, SAR)

要點二：本職學能

已經位於組織中高階，很有可能早已不具備，或者喪失本職學能。因此，正確判斷是否具有合適的本職學能極端重要。

然而，中高階位階的人，其本職學能比較抽象，需要有方法加以判斷。

資訊科技領域的判斷方式有：(1) 基礎經歷 (2) T型延伸 (3)培育人才


(1) 基礎經歷：

以職業籃球為例，目前NBA的總教練，必然曾經在他人生的某個時期是「頂尖球員」，也許只是在NBA眾多明星中的候補球員，但也至少是NCAA某個第一級學校的球星。縱使不是，至少也是在高中時期，某一個州的的MVP等級球員。總而之之，他必然曾經當過明星球員，因此在當總教練的時候，能夠了解一整隊明星球員的思維，球員在比賽時的「真正作為」

同樣的，假設在軟體開發，找尋中高階的帶人主管，他本人必須「曾經是軟體開發人員」，最最最起碼也需要有3年以上實務寫程式的經驗。一個的SA或PM，也許工作的經歷還不錯，但如果沒有務實的寫程式經驗就來帶領開發團隊，就好像一個資深的球隊經理，看過很多比賽，卻沒有實際上打過球，就來當總教練一樣的危險。

或許有人會說，有些人屬於「將將之才」，他當將軍比當士兵還適合，不應該以過去的基礎經歷來斷定。在其他領域，或許是，但在資訊科技領域，「沒寫過程式」就是「沒寫過程式」。


其他的基礎經歷，必須有「清楚的事實」的佐證。例如，在履歷表上有AWS的使用經驗，就必須要清楚地知道何謂使用經驗？是用過EC2/S3/Route53，還是用過那數十個服務的哪些服務？是自己親自使用還是「指揮」別人使用？使用的規模有多大？等等


(2)  T型延伸

T型延伸的基礎是先有「基礎」，因知識與職責擴展的關係，延伸到其他相關領域。例如，在已經有智慧型手機應用程式開發的「基礎之上」，延伸到線上行銷，社群開發等等。

誠如前一節所述，沒有基礎，延伸不具意義。

關於T型人才，請參考這裏與這裏。

(3) 培育人才 

並不是每個人都會是好老師，不過如果中高階人才承擔的任務與管理有相關時，能否「培育人才」將會是團隊成功的關鍵。在SAR的方式裡要找到培育人才的方式很簡單。初級問題像是「你個人過去六個月以內，做了哪一件事情最能幫助團隊培育人才？」。中級問題像是「」

要點三：獨立執行單位

資深的工程師和初入社會的新鮮人最大的差別之一，應該是能夠自我成為一個執行單位。判斷是否已經成為獨立執行單位，是選才關鍵要點。


判斷的基礎方式有：(1)自我培養，(2) 計劃未知，(3) 人才培育。



(1) 自我培養

可以在組織裡，自行培養自己，發起並參與適當的事件。在中高階人才中，不存在「組織要協助培養能力」的情況。

這並不代表不用學習，只是不應該透過組織來建構自己的職業生涯和學習計畫。資深與中高階人才，應該要能自己規劃學習計畫，主動學習，並且「主動」將自我成長與組織成長「整併」。

僅專注在自我成長，對組織沒任何好處。努力使組織成長，放棄自己的成長，對組織也沒有好處。雙贏才是長久之計。



(2) 計劃未知

沒有人能預測未來。但資深中高階人才，應該能透過本身的技術能力，工作經驗，長久累積的直覺，有效看出至少數個月後的可能發展，並能有效制定計劃。

計劃(plan)本身並不重要，重要的是做計畫(planning)。中高階人才應該能在有限的已知情況中，盡可能計劃未來，建構真正的目標，評估控制風險。

而這計劃並不是為了展示，也不是文書作業，也不一定需要900頁巨作。關於計畫，請參考這裏。


(3)人才培育：

請參閱前一節的培育人才。

工作學不到東西：三個自立的方法

在資訊科技的公司裡工作的人，無論年資，大概常會聽到有人提到「在這裡學不到東西」「這個team沒有給足夠的訓練」「在這裡的發展有限」等等的牢騷抱怨。抱怨自然是人之常情，不過，個人職涯最終還是決定於自己。換言之，大部分的情況下：公司，環境，同事，工作內容...等等大概都不是「學不到東西」的主因。

任何情況下，都有以下三個實質的方式可以嘗試。

方法一：理解事實

任何事情，一開始都應該理解事實。

先確定是組織或者公司無法給予足夠的學習機會，還是自己沒辦法自我學習？假設沒辦法判斷，99%大概是屬於沒辦法自我學習的情況。

事實無好壞之分，事實只是單純的事實而已。然而，試圖了解事實有時候並不簡單。

一個剛畢業的學生，除非是高斯， 埃爾米特之類的天才，否則幾乎在任何組織裡，都有可以學習的事物。特別是在資訊科技領域裡，無論是正面學習，側面學習，甚至負面學習，在一段不長時間內(1-3個月)一定可以學到某些新技術，某些新觀念，某些應該避免的不正確的事情。

如何了解事實？可以試著問自己以下問題：

（假設處在一個軟體開發的組織中）

* 在這個組織裡面，所有相關技術你都能有效掌握？

* 組織中沒有人比你資深？

* 組織中比較資深的人，你都了解他過去的工作經歷？

* 目前組織中使用的程式語言，開發工具，你都已經徹底瞭解其優缺點？

* 目前整體開發過程的技術問題，都已經了解真正原因，並能務實地加以改善？

* 對於類似的軟體開發專案，類似功能的產品，都已經了解相較於自己團隊的優缺點，以及技術差異？

如果以上回答都是YES。事實就是這個組織真的無法讓你學到東西。不過如果有回答是NO，事實可能是你需要知道怎麼學習。

方式二：學習如何學習

請參考如何充實自己篇。

學習的本身是需要學習的。雖然每個人的學習方式略有不同，但提昇自己如何學習的能力，遠比把自己放在「可被教學」的環境來的重要。

簡而言之：花錢去上教學課程，在工作中有資深同仁可以帶領，參加各類型研討會...等等，這些雖然絕對益於個人成長。但是，「靠自己獨立學習」卻是一個難能可貴的技能。

而這項自我學習的技能也是需要學習。這衍生出看似複雜的問題：個人能否自我學到自我學習的技能？

撇除邏輯上的矛盾，找到適合自己的方式最為重要。若還沒有找到，可以參考如何充實自己篇。

舉個實際一點例子，假如你想學習作為一個好的軟體團隊中的QA，隨便在google或者youtube搜尋一下相關字眼，起碼可以找到數十個相關的教學文件甚至錄影。

認真花上幾個小時看完以下網頁以及教學錄影，相信你對這個主題肯定有某程度的瞭解。這都是僅透過"how to be a good software QA" 以及相關關鍵字搜尋得來：
1 http://www.guru99.com/software-testing.html
2 https://www.youtube.com/watch?v=sab0dblUpIE
3 https://www.youtube.com/watch?v=G5RpYi2dT04
4 https://www.youtube.com/watch?v=j8kY9txH2bc
5 https://www.youtube.com/watch?v=xCwkjZcEK6w&list=PLXXvO4OXeJrfbPrI0CV-re2VkdiV1dC7X 
6 https://www.youtube.com/watch?v=vimfiZZ4NI0&list=PLZTe0pWS8OYv3KYWJTZT_3chbtpXBoiOz&index=6
7 https://www.youtube.com/watch?v=OLayCNOPWIo

8 https://www.youtube.com/watch?v=hMfPCdF07hA

方式三：做出結果

資訊科技相關工作，特別是和軟體開發有關的工作，「學習」是很重要，但是「產出」卻更為重要。而產出就表示有具體的結果出現。

例如：這幾年data scientist相關話題非常熱門，有許多已經在職場2-3年的軟體工程師，常常會以這工作能否讓他有「data scientist經驗」為學不學到東西的考慮因素。

然而，其實特定技術領域，學東西最正確的方式，應該是自己能做出「某種結果」。

如果想要有data scientist工作經驗？有太多現成的「真實」工作經驗可以自行取得。

在大部份組織內部，都有很多無形產生的資料。這些資料，絕對足夠一個程式設計師學習以及做出學習的結果。

例如：

•  程式碼版本控制系統(git, subversion, svs)。含有整個專案開發過程的「實質進展」資料，可利用他做時間序列分析，程式設計師個人績效分析。目前早有許多專案提供工具。
• 組織的AD資料。正常情況下含有可供內部公開使用的資料，例如組織架構，人員變更。
• Web Log。現在大部份的專案多少都使用HTTP，他必然會產生足夠大量的Log。一般Log分析工具（例如AWStats）已經可以做基本的資料分析，再配合machine learninig就可以做出各種有趣的結果

至於在組織外部，機會更幾乎是無窮盡的，也可以透過某些網站取得真實的資料，做真實的工作。例如：kaggle :在此有真實的專案，任何人都可以取得資料，透過自己的能力，完成資料分析專案。其他像是一般外包的網站：upwork.com也會有類似的工作，但可能不見得可以取得真實資料。

以結果為導向的學習，會比較腳踏實地，並且容易達到想要的效果。然而需要個人的興趣以及決心來支持。

---

參考：努力的三個迷思

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(3) 方法三：教學相長

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

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

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

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



* 在大組織裡的主動分享

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



* 參加研討會：

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



* blog/youtube教學影片：

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

* 找到具體達成的目標：

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

---

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