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

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

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

真實故事：

有近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. 經過產品經理確認 才算？

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

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

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

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

從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) 再花時間去找到為什麼專案需求不明朗的背後原因，






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

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年沒有什麼不同。如果你是這樣的專案經理，為了團隊好，或許應該考慮轉換適合的工作跑道。

軟體專案品質控制的三要點

老馮是軟體專案經理，在專案進行的某一天，被高層找去開會。高層：「最近雲端計算很火紅，你的專案既然是跟Cloud有關，看能不能早點完成」。老馮就問：「那可不可以auto-scaling的功能不做？」。高層：「沒有auto-scaling哪能算雲端計算平台，當然要做啦」。老馮就又不死心地說：「怎麼可能功能不減少又要早點完成？我們都已經是早9晚9在加班」而老馮心裡沒說的是，加班也絕對不是解決的方法。高層：「那就看你們的能力啦，不然我在多加3個人給你好了？」。老馮：「...」




專案管理過程中，品質是最容易忽略的項目。在狀況複雜的專案，品質常常是自動被犧牲的事情。在沒有良好控制的專案，品質是最容易被省略的事情。


品質Quality的定義其實有點複雜（參考這裡）。基本上，在軟體上，一個可接受的品質通常是指：功能如預期的正常運作，並且沒有不預期發生的壞事。

例如，一個手機購物程式，在你執行登入，往下捲動查看最近的商品目錄，點選商品，下單，這幾件事情都如預期的運作，就表示功能沒問題。從看到商品到購買，整個過程沒有讓你覺得很慢，那就算是沒有不預期發生的壞事。

又例如：當你點選商品之後，看到商品大的照片，接下來你就橫向擺放手機，照片因而旋轉之後，再轉回原來的正向，結果手機程式就當機直接跳出，這就表示功能有問題。當你點選商品到購買，整個過程讓你等得很心煩易燥，每個動作都要5秒鐘的等候，那就算是不預期發生的壞事。



軟體專業經理人，應該都知道一條鐵律：品質，範圍，成本，三者不可能兼具。

軟體專案的成本指的是：時間，人力，金錢或其他投入的資源。

軟體專案的範圍指的是：軟體的功能，規模，支援的硬體範圍等等，範圍修改自然就是功能增多或減少。


三者不可兼具，指的是要顧全某一項或者某兩項要素，就一定會犧牲另一項。例如：某APP可以支援google+ 以及facebook 帳號登入，後來因為時間(減少成本)考量，最後決定僅支援facebook登入。又例如，某APP原本可支援google+ 以及facebook帳號登入，後來又希望可以額外支援維博登入，這時候就決定花錢(增加成本)找外包廠商實作此功能。

軟體專案中，另一條鐵律是：試圖三者兼具者，會自動犧牲品質。例如：某APP可以支援google+以及facebook帳號登入，而後又想要支援維博帳號登入。專案經理想要在不增加成本，又不減少其他功能的情況下，又不增加實作時間。硬是要額外增加此功能的結果，必定是品質會自動犧牲。

不知道品質會自動犧牲的專案經理，必定不適合做軟體的專案管理者。

軟體專案品質控制有三個要點：

要點一：來源

品質的來源是整個開發過程，從一開始的計畫以及團隊組成，就已經決定了品質的一半。

一個簡單合理有效的計畫，可以控制改變，掌握進度事實。開發方法是不是採用Scrum並非最關鍵。重要的是，計劃中的開發方法是否簡單並合理的被團隊認知。

舉例來說，傳統SI常會有RFC，也就是需求變更的管理計畫。在開發過程中，如果有需求變更，基本應該是1.先填一份表格，2.在專案會議中與客戶討論，3.互相同意修改之後進行變更。換言之，有需求變更(RFC)管理的情況下，必定是前期的架構，設計細節，規格等等都先完成了，才會開始進行開發，因此，就不可能使用Scrum的開發方式。


假如團隊的組成是可以選擇的，那這件事情也是掌握品質的關鍵因素。

要點二：架構

在實作上，架構是另一個品質的主要關鍵因素。一個優良而且簡單的架構，比較有可能在多人而且複雜的開發情況下，獲取最容易達到的品質。

精煉的軟體架構設計表面上容易，實際上困難。架構的設計要素，眾所皆知：內聚力高，耦合力低，不同模組之間首重介面溝通。

然而，任何有3至5年工作經驗的程式設計師，都可以規劃出極為複雜的架構，普通並且沒有實務經驗專案經理，會容易「讚嘆」這種複雜的架構。這會在不久的未來讓品質很快降低。

實務上，只要沒特別的控制以及重構，正在運行的軟體的熵(entropy)值通常會隨著時間越來越高。同時也讓軟體品質越來越低，或要花很大的成本達到高品質。

要點三：創意

在品質控管中，創意是最被人所忽略。特別是在傳統的開發環境裡，負責品質的相關專業人員通常傾向於「找到問題」，事實上，這的確是QT或者QC的主要責任，但軟體專案中，作為QA(Quality Assurance)扮演的任務就不僅如此，而是在整個開發過程中確保品質符合規格（註一）。

而有創意的QA是第三個重要的品質來源。

普通的QA會執行QT/QC的任務，在開發過程中參與設計討論，並且撰寫測試案例(test case)。在功能完成之後，會認真執行測試案例，或者撰寫測試程式碼以便自動化測試，而在過程中找到並且記錄問題，並督促程式設計師修正錯誤。以上這些都很好，而且也沒什麼不對。

但是！當時系統複雜，時間壓力大，程式設計師能力參差不齊等等困難情況發生時，普通的QA流程並不會對「範圍」以及「成本」有所幫助，因此很容易被壓縮或者犧牲。

有創意的QA會根據專案的情況，找出最好的解決之道。而非死命地抱著舊有的測試流程，在確定有問題的情況下還不進行改善。

創意的可能行動有很多，但總之就是要有「行動」。空想的創意是沒有意義的。有創意的QA行動，可分為技術類型和非技術類型：

技術類型

例如：透過pair-programming主動參與開發；除了自動化測試之外，撰寫當介面改變時的監視程式；對於程式設計師的commit做自動化分析...這些都是透過QA的技術能力，提早發現可能的問題並提早解決。

非技術類型

例如：著重架構的精煉與簡化；改善測試流程；利用其他資源(例如業務人員)進行測試；改善code review的方式；簡化bug記錄以及追蹤方式...等等，這些都是透過ＱＡ的協調作業能力，縮短或減小品質差距。


簡而言之，絕大部份的軟體專案品質控制，其實是需要有創意的QA，才能突破既有限制，創造更多價值。而QA要有創意也並不困難，只要願意嘗試，通常都有很好的效果。


參考：沒有QA？如何確保軟體開發品質

註一：ISO對於QA的定義："part of quality management focused on providing confidence that quality requirements will be fulfilled"

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

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

詭異的是，幾乎所有已經在資訊科技領域工作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也會有類似的工作，但可能不見得可以取得真實資料。

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

---

參考：努力的三個迷思

如何組成團隊：三個步驟

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

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


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

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

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


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

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

通常，由於各種背景壓力，組成團隊的方式通常就是先根據需要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。

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

---

沈思：

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

大學或研究所玩太久.(三個解決方式)

有幾次面試新鮮人，發現有些學生自覺得在大學研究所時代"玩得太久"，而對於即將投入就業市場有些自覺能力不足。

首先，如果照著學校教育做好該做的事情，就算沒有「玩很多」，老實說能力一樣是不足。想要在還未就業之前，就達到一個好企業的標準是有點難。當然在學時期，有很多事情，對就業有極大的幫助（至少就軟體以及網路產業而言），但是大概都不是台灣學校教授能教的。

這些事情像是：加入open source的開發工作，找暑期工讀，到外包市場接專案等等，都對自己有幫助。

但如果你已經來不及這麼做，就面臨畢業了。那麼除了延畢，隨遇而安看命運安排，拒絕面對事實...之外，其實有三個實質的作法可供參考。

對了，要記得，任何時候都為時不晚 只有覺得太晚的時候才太晚。



三個解決方式：

(1) 解決方法一：快速學習技術能力

想要投入資訊產業，不管擔任什麼角色，擁有技術能力永遠是對的。

找一個喜歡的目標，全面性的學習相關能力。不見得一定要花大錢上課，網路上現有的免費資源一定可以讓你在2-4週之內(最遲不超過4週)學會某種東西到一定程度。不管是Java programming還是HTML5，不管是Big data analysis還是photoshop應用。

如果對於快速學習技術能力有進入障礙，要記得這一定只是進入障礙而已。只要有興趣，願意專注，到目前為止還沒看過學不會的。真正問題在於有沒有專注的付出時間，如果確定資訊科技對你來說是完全沒興趣的，那也好，就此打住，改換跑道為時不晚。

(2) 解決方法二：尋找互蒙其利的機會，藉此重建履歷

很多時候，你需要的只是找到一個可讓你有學習機會的環境，這個環境可以促使你成長。如果不花錢，有什麼機會有這種環境呢？可以去看看upwork.com, guru.com, fiverr.com到上面以賠本的價格接專案來做，就會知道目前市場環境中缺乏什麼。

(3) 解決方法三： 打工與學習

這和解決方法二有什麼不同？打工是泛指先去做你不是很想做的事情，例如contractor。這除了可以讓你舒緩生活費用的問題，增加獨立性，也能獲取一些時間，讓你想一下自己有什麼選擇。

打工與學習，泛指各種範圍。在網路時代，只要知道怎麼找，資訊幾乎很容易取得。例如，如果你是26歲以下的女性，喜歡小孩想要學德文，au pair是一個看似誇張，但是合理的選項，參考這裡。




創意沒有極限。不要只接受片面的資訊，即便是這裡也一樣:)

---

沈思：

1. 經濟學鼻祖書：國富論一開始就是在說明分工的重要。這也是就業市場上，各種職業產生的真正原因。能不能找到自己相對於別人的比較利益優勢？

2. 以長期而論，自己想要什麼很重要。但是短期來說，自己有什麼選擇才是關鍵。

3. 這三個解決方法，看起來都沒什麼創意，但是跟隨波逐流比起來，還有其他方法可選嗎？

新鮮人如何提昇在組織中的價值：三個方法

請務必先看關於價值的這篇


稍微提醒，價值與績效的不同。

績效著重的是將評量標的量化，所以通常都會有明確的時間點、目標以及數字；而價值則看重在一個連續時間的累積。

比如說餐廳擦桌子 ，績效可能會訂成：在客人離開以後的五分鐘內要把桌子擦好，桌面必須全部擦過，不能有菜屑湯汁；而價值可能是：在客人離開後迅速把桌子擦乾淨，展現本餐廳專業乾淨的形象，並提供下一位客人舒適的用餐體驗。

所以你會發現，這兩個本質上其實是同一件事，只是觀看切入的角度不同；績效跟個人日常工作內容習習相關，而價值則是較與公司的整體特質相關。


(1) 了解組織需要的價值

身為一個新鮮人，通常前輩不會大費周章的跟你解釋組織需要的價值是什麼；而另一個悲傷的現實是：有些前輩自己也搞不懂組織要的價值是什麼？

所以這一部分通常必須要自己有意識的去了解。至於要怎麼能夠了解組織需要的價值？若完全沒有概念，可以參考以下方式

1. 參考資料：有些公司會寫出他們的價值，比如：IBM、Google、Microsoft，或者公司內部訓練裡會提到，但大部份很可能只是打打高空，只能給一個很粗淺的概念。

2. 角色扮演：想像自己是老闆或是主管，想想要怎麼提升組織整體的價值？比如是處理財務的事務，精準的重要性一定會高於迅速；而若是救火隊或急診室，快速解決問題一定會比完美來得重要。想想客戶為什麼要買公司的產品，它對使用者最大的幫助是什麼？

3. 工作觀察：倘若組織不大，可以從日常工作中觀察下列事項：什麼樣的工作有比較高的優先權？什麼樣的錯事大家會很嚴厲的對待？什麼樣的錯事大家可以一笑置之？想想為什麼？

組織需要的價值是會隨著時間變動的，了解組織需要的價值可以幫助自己更快的進入狀況，甚至做得好的話可以提前走下一步路，而不是每天被績效的項目追著跑。



(2) 發揮長處避開缺點


了解組織所需要的價值，同時你也要了解自己（相關文章）長處與缺點。把自己的長處放在組織要的價值上，就可以達到相輔相成的效果。比如說你是一個很細心有耐心的人，那就可以主動接下財務、編輯、校稿之類的工作；你若擅長收集統整資訊，那麼研究、匯整、之類的工作就比較適合你；若你可以在資訊不夠充足的時候，在短的時間內做出決定，那麼也許可以嘗試第一線的工作。

然而如果反過來，急性子選到財務對帳的工作；要收集完資料整體評估才能下決定的人被要求馬上要下決定，這樣就算工作做完沒出事，工作起來也是很累的。

事先了解自己與工作的屬性，當有適合的工作出現時，主動接下來，還可以塑造出工作積極的加分效果。另外有時身為新鮮人不一定有辦法選擇工作，但知道手上的工作跟自己屬性不合時，就要特別小心，才不會不小心出包。




(3) 專注於產生價值

如上一點所說，你找到一個極能夠發揮自己長處的工作，你也很認真地做好了它，但結果沒有人在意這件事？！

知道組織要的價值所在，才不會走冤枉路。專注在幫組織產生價值的事情上，對組織以及自己才有意義。

回到一開始餐廳擦桌子的例子：假設你是那位服務生，在尖峰時刻忙到都要「搓草」了，眼看有一張桌子前一組客人已經離開過了四分鐘還沒清理，而下一組客人已經站在桌子旁，甚至有人已經等不及入座了，此時你會怎麼做？

1. 直接衝過去在一分鐘內把桌子清理完畢，好符合擦桌子的績效要求。

2. 過去客氣地跟客人道歉，不影響到客人的情況下，儘速把桌子清理完畢以後再請客人入座，可以的話清理的時候還跟客人寒喧兩句。

或是你覺得有更好的作法呢？歡迎跟我們分享。

---

沈思：
了解組織所需要的價值，想辦法提升組織的價值，就等於提升自己在組織中的價值。如此一來，等同讓自己跟組織站在同一陣線上，而不是讓自己在組織中陷入一個你做工、我監督的對立狀態。

解決專案困境的三步驟(軟體主管的31堂課)

一個完美被執行的專案幾乎不存在，特別是越是有潛在價值的專案，通常會伴隨一定的風險，因此很難不遇到問題與困難。

有經驗的專案管理者，可以在問題發生之前先行規劃解決，這和專案一開始的結構設定有很大的關係。然而就像扁鵲的父兄的故事一樣，能在問題出現之前防範未然者，讓專案順利執行，這樣的人在台灣的環境，似乎難以被定義其價值，即便有也難以被發現。

總之，有價值的專案，無論如何，難題總是會在某時候出現。

在接案公司中，最常出現的可能是時程，需求過度擴張，等等常見問題。例如：協助政府建立某APP用以查詢政府


透過以下三個務實的步驟，協助解決問題

在這裡假設問題已經發生，必且這個問題不在專案進行的時候的風險規劃之內。

這些步驟乍看之下，可能會讓人覺得簡單到需要特別說明嗎？不過，實務上遇到專案困難時，由於時間的壓力以及人類固有的習慣，能保持平靜看待困難是不太容易的。因此，透過簡單的步驟。

某些人常會對於既定的步驟有些許誤解，認為規劃好的步驟可能會失去彈性，減低創造力。但如果掌握真正的精神，結果會正好相反。

(1) 第一：了解事實

大概不少人會認為這是一句廢話。不過，在遇到真正困難的時候，困難的本身通常會隱藏事實。


舉例來說，看似最常遇到的困難就是資源缺乏。以軟體專案來說，就是沒足夠的人力，或足夠的時間來做事情。

但是，絕大部份的人力不足，其根本原因都不是人力不足。

根本的因素可能是：現有的人沒有執行這方面專案的經驗；負責的專案經理能力不足，無法有效協調人力；現有的人員無心執行任務；規格不明確，而導致執行方向不正確，因而使專案到中後期看似沒有足夠的人力或時間完成...等等，諸如此類，才是真正的事實。

人力不足，沒有時間，只是表象。

專案負責人（可能是專案經理），必須要先找出事實。

一個很簡單的原則：如果有表象是「沒有人手」，「沒有時間」，「規劃的進度常常延誤」，專案負責人幾乎99%可以斷定背後必有其他原因。


了解並且面對事實是務實的第一步驟。缺乏這個步驟，任何其他的解決方法都沒有意義。

(2) 第二：模擬不同的解決方案

通常界定真正的事實之後，解決方式大概就隨即而出。然而，既然是困難的問題，就應該想出一個以上的解決方案，然後模擬可能的後果。

這裡強調提出不同的解決方案，因為既然是困難的問題，表示一定在有限的時間以及資源之內，無法簡單的解決。換言之，任何可能的解決方案都可以會犧牲某些東西。因此「模擬」就有必要性。

最簡單的模擬是拿一枝鉛筆一張紙，描述接下來會做的解決方案跟可能結果的流程圖。

舉一個最常遇到的例子：時間不夠，而時間不夠的主要因素已經界定為專案進行過程，常常有需求的改變，但是專案期限卻沒有改變。

假設，可採用方法有以下幾種：

Plan-A：開始軟性或者硬性延長工作時間。

Plan-B：與專案業主坦承需求改變已經造成專案延誤，用Scrum的方式讓專案繼續推進到期限，但在此之間，專案完成的定義也會被改變。

Plan-C：與專案業主談判，取得延期或者需求限制。

Plan-D：...（還有其他很多）

這些解決方式也許彼此是有相關的，例如B與C，其實都需要和專案擁有者（就是出資的人）協商。

模擬Plan-A：

拿出紙筆，寫下所有已知的資訊或事實：

* 目前為止團隊每週的產出
* 目前為止需求的改變數量，和造成的延誤時間，假設延誤10天
* 規劃需要加班時間總數：假設延誤10工作天，目前到期限仍有4週，等於是每週需要額外20小時工作
* 加班之後可能能夠多做的哪些功能
* 加班的總長度，這個例子是連續4週
* 過去加班的耗損率：每週超過10小時的額外工作時間，會讓人請病假的機率
* 長時間加班之後人才的保留率：每週超過10小時的額外工時
* 加班的這段時間，還是會有需求改變。
* ...等等...

將這些已知資訊，不過心裡知道與否，還是盡可能寫在一張紙上，在腦中想像這些資訊「拼湊」起來之後，對於目前專案，有沒有可能使用這個方法解決，而這個方式，其副作用是不是過大。

模擬Plan-C：

拿出紙筆，寫下所有已知的資訊或事實：
* 目前為止團隊每週的產出
* 目前為止需求的改變數量，和造成的延誤時間，假設延誤10天
* 專案業主對專案的瞭解程度
* 專案期限往後延，對於業主的損失
* 專案業主的協調能力
* ...等等...

將這些已知資訊，不過心裡知道與否，還是盡可能寫在一張紙上，在腦中想像這些資訊「拼湊」起來之後，模擬與業主溝通時的可能對話，以及可能產生的結果。

選擇：

將模擬的過程，用心智圖(Mindmap)或其他圖形化方式，寫在同一張紙上。這麼做是為了盡可能排除個人主觀意見，將自己的思緒，用鳥瞰的方式呈現給自己。

模擬數個方案之後，最重要的是選擇一個自己認為相對最佳的方案。

(3) 第三：執行解決方案

如果前兩個步驟，已經竭盡所能。那麼，第三個步驟就變得很簡單：根據第二的步驟模擬之後的決定，執行解決方案。

然而，既然是困境，就不應該預期解決方案一切順利。如何克服困難去執行，就看專案經理的智慧與能力。

執行解決方式同樣有很多需要注意的地方。不過內容絕大部份取決於每個不同專案的特定現況，因此不會有放諸四海通用的銀色子彈。

但是，由於專案困境常有相似性，因此尋求有經驗的朋友或顧問的建議，倒是一個永遠不會吃虧的選項。

---

沈思：為什麼有價值的專案總是會遇到困難？
參考->解決軟體專案困境的最爛方式