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

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

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




  

你真的知道專案進度嗎？

只要是從事程設式設計相關工作的人，必然曾經參與某專案(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] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？

工作筆記的三個重點

這幾年來，市面上有如何做筆記的書。例如記事本圓夢計畫，重點就是要這樣記，不花錢學筆記(註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) 第三：執行解決方案

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

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

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

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

---

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

資訊系所學生就業 (三件值得注意的小事)

除了少部分往學術界持續邁進的人之外，畢業生遲早要就業。

但就過去數年面試新鮮人的情況來說，大部分的學生並沒有對就業有所準備。這似乎是理所當然，本來就不可能有充分準備，不然就不叫新鮮人。

而業界常常把問題放在學校並沒有充分"教育"學生該有的知識與技能，使得學界與軟體業界脫節。

這似乎也不是台灣單獨的問題，早在數年前有人在美國抱怨此事。而且類似的抱怨一直都沒停過，例如這裡。新鮮人面臨的困難，很多也都是像這些文章中一樣，是認知上的問題，例如：絕大部份的人，可能一開始只是會被要求做個小螺絲釘的工作。這和他幻想中，技術高超的程式設計師經過不眠不休的努力，就可以達成驚人的成就，然後改變這個世界有很大的不同。這裡有相關的認知現實描述。

因此一開始得先適應周圍環境，而大部份的學生畢業的時候(不管是哪個學校畢業)都須要先認知自己知識(或者常識)不足以適應環境。越有這種認知，適應的可能越快。

所以，以下是快要畢業，打算就業前，或者選擇公司的時候，建議學生先做好準備。

(1) 暫時不要看BBS，新聞，facebook一段時間。

PTT大概是台灣獨有的特殊環境，它很有趣，有時候資訊很快速。可是很遺憾的是隨著資訊量越來越多，他的正確性越來越差。如果你不是極端理性，意志堅定，很容易受到不良資訊的影響。如果可以的話，至少為期一個月。至於台製新聞跟facebook就更不用說了。

(2) 確實知道自己在搜尋什麼(當你打算google一下？)。

剛加入的新鮮人，特別是畢業於2008年之後的，在遇到困難的時候，一定習慣google。而google也很少讓人失望，通常都能找到某種答案。

但要注意的是，答案也許正確，但是資訊過於片面。日子一久，就很難獲得全面的視野。例如，查詢"android AsyncTask"，如果你想要看中文資料，前幾個結果都會是某些人的blog，當然不是說這些人寫的一定不對，而是blog(特別是中文)常常是片面資訊，就算他好心貼上正確參考資料，可能也不會有人耐心查詢。對於中文閱讀者來說，最好是google之後自己找看看哪一個才是官方正確資訊。歹事，目前沒有中文的官方資料，api最好的參考是-> http://developer.android.com/intl/zh-tw/reference/android/os/AsyncTask.html

(3) 謹慎選擇工作 但更要謹慎選擇主管。

在台灣能夠選擇的工作實在太多，台灣優良的企業也很多。第一份工作，當你有難以決定的情況時，請謹慎擇一個好主管。

面試的時候，不只是面試者選擇你，而且你也必須要選擇面試者。當然如果面試你的人，不是你的主管，那這個公司等於是跟公家機關沒啥兩樣，不如乾脆去考公務員。


如何在面試的時候知道是不是好主管？

一個好主管能夠清楚地知道自己負責組織的真實情況，而夠培育員工，能夠掌握現實，並且能夠處理困難。因此由詢問以下問題來判斷這個主管是不是個好主管：

  (a) 請主管描述自己未來1-3個月工作內容。

     如果講的比較含糊，可以單刀直入的問清楚。如果發現永遠都問不清楚，很有可能你進來這個公司的時候，發現這個主管無法控制組織前進的方向，做的工作和面試談的完全不同。要注意的是，工作的確一定要有彈性，以及隨時應變市場變化，但是市場的變化，不會讓一個新鮮人無法確定未來1-3個月的工作。而如果要靠一個到職不滿新鮮人來"負責"各類型的變化，那這個公司風險也太大了。

  (b) 請主管說明，上一次有新鮮人進來的時候，他是如何培育新人。

     同樣也是要清楚了解，是單純指派資深員工指導，還是有培育時程規劃，如果有規劃，可否讓你看一下，參考一下。當然也有可能上一次有新鮮人來的時候是10年前的往事，那就要考慮這個組織的老化性。

  (c) 請主管說明，當你來加入團隊的時候，他最有可能擔心哪件事情你做不好。

     這是要清楚了解，主管經過面試，對你有沒有清楚的認知，如果認知差距過大，那可能大有問題。舉例來說，如果你非常精熟java，但是並不熟悉Linux上的開發環境，在一個完全Linux的開發環境的團隊裡，如果主管認為你學習linux一定沒有困難，可以三天搞定，要不就是他不認清現實，要不就是你在面試中已經證明自己是天才。

---

沉思：

* 網路上的資訊很多，事實上無用的瑣碎的資訊，遠比切實的資訊來的多太多！短時間切斷資訊聯繫，對整理思緒有幫助嗎？

工作太忙沒時間？改善的務實三步驟

圖片來源為Hakan Forss的部落格，要引用此圖需要連同其網址一起引用：http://hakanforss.wordpress.com

在資本主義社會下，有效率的工作是基本條件，但是在資訊科技的發展中，有效率的工作逐漸顯示人的本身才是無效率的源頭。這並不代表資訊科技的進步與有效性，這只是代表人扮演的不可取代價值。

人的價值在工作上會順帶產生工作的壓力，因為所有的企業都會要求成長，不只是企業的成長，還有個人的成長。

不過，無論如何，在你還沒有丟出辭呈，自己開創事業之前，最好的選擇永遠都是強化自己的能力，改善現況，為組織產生更多價值。

對於很忙碌的人而言，要改善現況最常的反應是：「每天都那麼忙，哪有時間做這個」「哎唷，講都麻很簡單，你又不是做我的工作」「我常跟老闆提啊，可是他都沒這麼做」。

這些理由都和明明知道運動有絕大的好處，但是卻會找理由無法持續運動的人一樣。其實只是心理不想去做，或者恐懼未知，或者不真心認為這很重要，因此都能事後找到很多藉口。

很多理由並非是藉口，「事情太忙沒有時間」可能是真的。但是，這可能是最容易，而且是最需要先解決的一件事情。

只要你不是以下職業類別：核電廠工程師，急診室醫護人員，駐守太空站人員，戰地記者，美國總統...。都可以透過以下三個務實的方式，改善「事情太忙沒有時間」。

這三個步驟，極其簡單，只要願意做，幾乎沒有做不到的可能。這三個步驟，沒有引用任何了不起的學問，也不具備任何學理基礎，它就是簡單到值得讓有心改善的人一試。
執行這三步驟的成本極端的低，但效果卻非常驚人。更重要的是，產生「有空時間」是充實並精進自己能力的最基本的一步。

三步驟為：記錄，分析，去除。

步驟一：紀錄

拿一本筆記本，或者excel檔案，或者googledoc，如果是手機app的狂熱者可以考慮使用Toggl。每天花5分鐘紀錄所有的工作花的時間，工作內容，工作價值區分，工作分類。如果可以的話，順便連生活的事物也一起記錄（例如通勤，睡覺等等）。

這個紀錄是給自己看的，所以不需要欺騙自己。

工作內容：當然就簡單記錄做什麼事情，軟體工程師大概就是寫程式，開會，處理email，與他人討論規格等等。

工作分類：根據組織本身的情況，因任務而給的分類，例如為了某A專案寫的程式，為了某B專案而開會，為了交接某C舊的軟體產品而開會等等。

工作價值區分：根據自己的想法，以重要不重要，緊急不緊急，將工作分成四個象限：重要而且緊急，重要而且不緊急，不重要而且緊急，不重要而且不緊急。

所花時間：可以是小時為單位，也可以是10分鐘為單位。但是，必須要是連續。換言之，不太可能有連續24小時的寫程式時間。因此最簡單的方式是有開始和結束時間。

再次強調紀錄必須簡單確實，紀錄本身不能太時間，不需要很精確。紀錄只會給自己看，千萬不要欺騙自己。

另外，這一步驟通常1個月就可以進行第二步驟。如果第二步驟的分析過程，讓你覺得有問題，那你需要額外的3個月的紀錄。換言之最多4個月的紀錄就足夠進行分析。

步驟二：分析

分析的本身是不難，把所有紀錄用excel加總分析，數字必須要是有總量和百分比。

第一要分析的是：工作價值區分。這些工作所佔的百分比，例如：

「不緊急而且不重要」： 50%

「不緊急而且重要」    ： 15%

「緊急而且不重要」    ： 20%

「緊急而且重要」        ： 15%

在分析階段，最重要的是了解事實。而非改善事實。如果「不緊急而且不重要」+「緊急而且不重要」的時間比率，也就是所有不重要的工作比例，加起來低於60%，很有可能你沒有正確認知任務，或者是對自己說謊，或者是記錄的時間不夠長。因為這樣的事實是有違統計常理（參考資料）。

一旦了解事實，就可以往第三步邁進。不過分析的時候，可以順便注意一些事情：

(1)「緊急而且不重要」＋「緊急而且重要」，也就是所有緊急工作的比例，加起來超過60%。表示幾種可能，一種可能是：你是長時間被工作逼著跑的人，你的任務幾乎都很緊急：老實說這個機率很低。另一種：你是自己認為工作會逼著你跑，你的任務幾乎都很緊急：這個機率比較高。

如果是"是長時間被工作逼著跑的人"，使用流程，半自動化，轉移專注的方式是之後要考慮的重點。不過誠如前段所述，這種情況除了特殊職業之外，其實極端的少，大部份是屬於下一段的情況。

如果是"是自己認為工作會逼著你跑的人"，先在記錄和分析上，重新正確分類事情才是能繼續往第三步驟前進。如果你真的認為所有事情都很重要，都很緊急，在心態上無法設定優先順序以及分類，那不管怎麼做都沒有人能幫得了你，本文的後段也不用再看了。

(2) 了解「緊急而且重要」「不緊急而且重要」的工作所含的工作分類。

也就是說，你能要試圖列出所有重要工作裡面，哪些緊急，哪些不緊急。而這些工作分類，這個階段，探討出：如何將緊急而且重要的工作的緊急因素去除。

(3) 「不緊急而且不重要」的工作分類。每個人多少都會去做這類事情。然而，如果你認為的工作的本身，幾乎統統屬於「不緊急而且不重要」的象限，那麼你可能對工作本身有很大的認知差距。

舉例來說，你可能是負責舊軟體產品的支援工程師，舊產品可能用戶少，營收少，也沒有未來的可能性，你直覺就會認為幾乎所有事情都不緊急而且不重要。首先，假如真是如此，那組織應該乾脆就會將舊產品汰除。舊產品仍然存在必有原因，可能是維持與舊客戶的關係，確保這些舊客戶滿意度，並且讓舊的客戶有機會試用新產品。因此，任何讓舊客戶滿意的事項，應該都屬於重要的範圍。

步驟三：去除

李小龍有很多名言，以下是其中最重要的一個：

One does not accumulate but eliminate. It is not daily increase but daily decrease. The height of cultivation always run to simplicity.

當已經知道事情的分類，意義，加總之後，並不是要著手去修改事務，而是先「去除」。

去除的本身最為困難，需要勇氣，知識，技術，經驗。

從最簡單的方向開始去除最容易。但在開始之前，一定要先確認"步驟二：分析"的結果是大致正確。

(1) 不做「不緊急而且不重要」的類型工作：不做這類型的工作，一旦發現這類型的事情出現：直接不做，不用多做考慮。不需要解釋，也不用感到慌張。

(2) 將「緊急而不重要」類型的工作，先行移轉，半自動化，或者流程化。「緊急」和「不重要」這兩者是某種程度的自相矛盾。但通常矛盾的產生在於，「緊急」先出現，可是你無法馬上判斷重不重要，直到完成任務之後，事後才知道重不重要。

這時候原有的記錄和分析就派上很大的用途。例如你是程式設計師，你的老闆常常打斷你的思慮，跑來問一些產品功能上的問題，說要給業務人員馬上回應。如果整個團隊都是這個情況，就會落入大家困於緊急但不重要的情況。移轉：指的是將這類的情況移轉到其他地方：或許是專門一個處理，或者外包給工讀生，或者是透過清楚地固定訓練，讓業務人員自己了解情況。

(3)將「緊急而重要」類型的工作，設定篩選。半自動化，或者流程化能簡單的重分類問題。例如急診室，所有進來急診室的人當然都是緊急且重要，但是，急診仍需篩選，護士會以最標準的流程，很快的評估進來的病人的緊急程度。讓真正緊急的事情能最快速處理。在軟體研發工程師，如果是在產品研發階段，幾乎不太可能遇到緊急而重要，有的話十之八九應該是天災人禍。因而，只要注意這類型的工作的區分正確與否即可。

(4)將處理「不緊急而且重要」的時間與價值提升。這點相當重要，不過並不是本文要討論的範圍。在此我們專注於”去除“

經過去除的過程，你會多出起碼少則20%，多則60%的空閒時間。


再次強調一下，這三步驟不是什麼秘密，也不需要用到高深的技巧，你僅需要對你的工作加以了解，並且執行正確即可。

人生唯一公平的地方只有時間，每個人每天都有24小時。有額外的時間，就能思索自己的未來，不會淪於找不到方向。

參考：如何提昇工作效率 

---

沈思：
轉移，流程化，半自動化似乎很重要？

資訊新鮮人：三個關於價值的概念

亞當斯密，在國富論中描述商品的價值只有三種來源：勞力，土地，資本。雖然那是1776年的事情。但至今變化仍然不大。勞力：泛指人的各種智慧以及努力；土地：指的是各種天然資源；資本當然就是投入的錢。


村上春樹，在尋羊冒險記中描述組織的價值有兩個部分：意志，收割。雖然那是小說，而且還是現實與科幻混合的小說。意志是指推進組織的能力，具有統御可能性的能力；收割可能是指將即將得到的利益完成。



Dave Snowden，在他的研究裡面，定義了Cynefin架構，將事件的反應系統分成：簡單(simple)，複合(complicated)，複雜(complex)，混亂(Chaotic)。

簡單：指的是事情的反應有很明確的因果關係定義，根據定義來做事情即可。

複合：指的是事情的反應之間，確實有因果關係，但是這個因果關係可以透過分析，學得而來。

複雜：指的是事情的反應之間，雖然有因果關係，但這因果關係沒辦法事先知道，只能事後知道。

混亂：指的是事情的反應之間，沒有因果關係。



這三個人講的事情看似沒關係，但是對於社會新鮮人對於價值的三個重要概念，卻是重要的參考。

(1) 何謂價值

幾乎任何東西都有價值，只是每個人評估價值的方式不一樣而已。在經濟學上最簡單的方式就是，你的某個東西，願意和別人交換什麼東西。那就是對你來說的價值。當然，交換太過麻煩，因此金錢變成一種簡單的衡量媒介。

在經濟學上常用價格來當作價值的衡量方式。不過價格本身就有很多種定義。

如果將範圍縮小到，投入資訊產業的新鮮人所關心的方向。價值可以縮小到：個人的智慧與努力，去交換某種東西。當然這某種東西很容易就被歸類為薪資，而如果是創業家則是利潤。

交換只有已經交換才有意義。因此，價值只有在交換成立的時候才有意義。例如，當新鮮人在104要求月薪5萬，這並不真的是他的價值，他的價值可能是4萬，也有可能是50萬，只有在成立的當下 - 也就是雙方同意月薪的那一瞬間 - 價值就成立了。所以，更重要的觀念是：價值沒有所謂的高與低，只有當時的事實。換言之，以價值的觀點來看，沒有過高的薪水，或者過低的薪水，只有雙方同意交換的成立價值。

當然，很多人互相同意的交換成立價值，就變成常見的成交價。股票某個時間點的價格，就是那個時間點的某一些股票的成交價，而非所有股票在那個時間點都是同一個價格。

最直接了當的說：如果覺得這薪水，對你來說太少，那就不要答應。但當你答應了某薪水，也不要抱怨 - 起碼在幾個月之內，沒什麼好抱怨的。而當你「自認」應該要提升價值時(就是該加薪了)，必須要是有交換的可能，才叫做價值提升。(就是真有人願意以這樣的薪水雇用你)

價值當然可以互相比較，常聽人說性價比高還是低。然而不同事務交換的時候，比較的基準自然會不一樣。就此而言，在資訊科技產業的任何兩個程式設計師，都無法互相完整比較價值，因為兩個人的智慧勞動以及產出一定無法有效比較。

另外，同一件事情，在從不同人，不同時空背景取得，會有極大的價值差異。例如，你坐計程車上班會花錢，然而，如果在你搭車的時候剛好遇到同事，順道搭便車，他可能完全不會收你任何費用。

(2) 組織的價值產生

組織，特別是營利組織，其價值等於是可產出的商品（或服務）。而任何商品的價值來源有三種：勞力，土地，資本。由於資訊科技產業（特別是軟體）並沒有用到很特別的天然資源，因此土地幾乎可以排除。而勞力和資本就變成資訊產業最主要的價值產生來源。

資本的構成與取得也不那麼簡單，不過不在我們的討論範圍之內。當然政府政策的影響也不在這短短的文章討論範圍之內。

勞力當然包含智慧技能等等，而企業內員工對於工作的付出智慧與勞力的方向，大概可以分成Cynefin架構中的那四種。


簡單(simple)：任何工作的行為是可以預知因果關係，必且可以透過各種手段最佳化，這些手段可能是由機器取代，可能無法由機器取代。例如銀行櫃台的大部份業務，都可以由ATM取代。某些日式的餐飲店，其服務流程經過妥善的最佳化，任何顧客的情境以及行為都可以編列在他們的制度與管理方式裡。因此，簡單類型的工作，可能產生最大價值在於能否提出最佳化。

複合(complicated)：任何工作的因果關係可以透過分析與瞭解而取得。工作本身可能是困難的，但是工作的效率還是可以評量，工作的內容，可能需要少許技能，但也有可能需要很高的技能才能完成。這類型的工作，其價值高與低，取決人的能力，使用的工具，採用的策略技術。這類型的工作可以學習，但學習時間長短不一定。複合類型的工作，可能產生最大價值在於是否能提出好的架構，並且有訓練有素的專家。一般的程式設計師，維修瓦斯爐工程師，一般醫生，護士，理財專員等等都屬於此類。

複雜(complex)：事件與工作的因果關係只能事後知道，無法在事前分析瞭解。然而，其因果關係仍然存在。聽起好像很複雜，然而這類型的工作，不見得很困難，只是要產生價值的時候，可能需要不停地進行嘗試與練習，才能事後了解因果關係，透過事後練習了解。例如，開一家新公司當創業家，獵人頭工作，業務類型工作，特殊類別的醫生，各類型的研究單位等等。

混亂(Chaotic)：事件與工作沒有因果關係，或者就算有，也是人的智慧無法得知，藝術就是此一類型。這類型的工作可以透過學習，擴張知識，反覆練習獲得經驗，來提昇可能性。但是難以評量。例如，畢卡索的畫作，張大千的書法，可以由他學生們學習模仿，也無法就價值評量。在企業上常見的例子是賈伯斯，他對apple的貢獻無法被學習，也無法被評量。有人認為開拓性質的研發也算此類，例如具有極端價值的演算法工程師，組織微積分的牛頓，構思相對論的愛因斯坦等等。

當然在以上的例子非常粗略，只是拿來參考用。組織的價值產生，就在透過人的智慧與勞力，資本的投入用以執行四種系統架構的事物。這四種系統架構，其產生價值的地方都不盡相同。

但今天幾乎可以確定的是：(a) 簡單的工作會趨向被自動化方式取代，無法自動化（例如餐廳）則會被低勞力成本取代。(b) 複雜的工作，透過科技的進步會簡單化。(c) 混亂類型的工作仍然屬於個別人的天賦範圍，可以培養但無法預測。

因此，真正的組織價值，在於透過意志，驅動複雜工作的架構，屆此拉近因果關係的差距，以及建立相較於其他組織的優勢。

(3) 價值不公平的觀點

誠如"何謂價值"所描述。價值只有交換的時候才會成立，而既然雙方樂於交換，何來不公？

大部份的情況下，所謂樂於交換通常是在資訊互相全然透明的情況。然而資訊全然透明是幾乎不可能，因為人根本無法處理足夠大量的資料，也無法體驗所有可能的情況。例如，一個新鮮人，畢業之後最多也只能面試50家企業，不可能窮其心力面試完所有可能的工作。但反過來說，一個企業的工作(如果不是屬於「複雜」或者「混亂」類型）幾乎都可以找到起碼50個合格候選人。因而，由於資訊的不對等，大部份的情況下，企業比較容易可以找到性價比高的員工，但新鮮人比較難找到性價比高的工作。

換言之，以個人的角度，解決不公平的方式有很多種。從價值的觀點著手有兩個可能：

(a) 投入組織意志的部分。

投入職場的大企業的人，都不太可能一開始就是驅動組織經營策略的人。通常都是某個小部門的小螺絲釘。因而要成為組織意志的一部分是很難的。然而，如果是投入在小公司，假設是只有5個人，那麼投入組織的意志部分是非常輕而易舉的事情。

不在組織的意志部分，並非就沒有價值，而是在組織的意志部分，個人的能力與可產生價值很容易顯現 - 無論高或低，好與壞。

(b) 強化處理複雜或者混亂的問題的能力。

混亂的問題大部份是屬於藝術類型。藝術很多都是「無價」，因為無價，也難以在此討論。不過所有能處理混亂類型的人，幾乎都是在某一個領域知識廣博，經驗豐富。因此，不間斷的學習一定會有幫助。

處理複雜的問題可以透過自我能力的培養，經驗累積，從他人（例如職場導師）學習而來。複雜的問題相當困難，但是一旦累積了架構性解決的能力，這優勢幾乎不會消失。

(c) 將複合的問題簡化。

透過資訊科技，將複合的問題簡化，可能是最近幾年最常看到資訊科技對組織產生價值的地方。大數據(Big Data)對網路書店上推薦購書就數此類。許許多多不同的手機應用程式(app) ，提供人類各種溝通方式(例如line) 也是屬於此類型。


(d) 將簡單的問題加速或自動化，進而最佳化。

將簡單的問題加速或自動化，可能是資訊科技新鮮人常會忽略掉的一點，但這點其實對價值的提升比想像中來的重要許多，特別是在大組織內。加速或自動化處理簡單的問題，可以讓人專注於其他架構問題，縮短內部公文流程，自動記錄某些事件等等，都屬於此類。這做起來相當容易，而且假以時日效果也很好。

當事情或者問題可以自動化之後，進而就可以最佳化。例如，過去政府有複雜的公文簽核流程，在紙本的年代，很難統計看出真正的瓶頸，透過自動化公文傳遞，很快的看出到底哪些公文花多少時間流過哪些不必要重複的地方，進而就可以去掉不必要的地方。以開發手機APP的流程為例，當視覺設計師的mockup，可以自動產生可供UI/UX測試的可供驗證app時，就可以進而快速取得使用者操作的經驗流程，進而讓UI/UX能最佳化手機APP的使用便利。




將複合的問題簡單化，簡單的問題自動化，自動的事情最佳化：是最基本產生價值的概念。

---

沈思:
   - 資訊新鮮人能在多短的時間內對組織產生價值？

務實專案管理(FLA)的三個重點...(從team leader的角度)

軟體工程與專案管理的方法論以及參考書籍非常多，無論是最傳統的PMP，到近幾年強調的Agile, Extreme programming，以及創新公司最常用的Scrum，這些方法都不外乎希望能盡可能圓滿達成專案目標。

而越後面產生的方法論，似乎都盡量想要化繁為簡，貼近事實，以便彈性的因應改變。例如Scrum就是將需求變更控制在sprint開始或結束，並且讓每個短暫的sprint(3-5週)可以專心於現在的計劃，改變於是乎就受到控制。

專案經理的角色和技術領導相輔相成，只是目的截然不同。專案經理最終的目的其實是”管理利害關係人的期望” (Manage stakeholder expectations)。實務上，這個目的甚至比專案在時間成本內達成來的重要。

技術領導雖然不是專案經理，但實務上，技術領導的小團隊是專案執行的最適切單位，因而技術團隊領導者也是反映真實狀況的適切人選。

技術領導當然不見得一定需要知道專案管理的細節，然而在軟體專案的執行中，技術領導者瞭解得越多，越能讓專案有機會成功。瞭解得越少，越容易受困於專案管理的本身。

(參考案例一）

專案經理(PM)在專案一開始就召集所有分析師(兼為小組長)進行傳統的WBS製作，完成了一份洋洋灑灑專案管理文件。在缺乏專案管理的知識下，三個月後在專案中期，某小組長發現有很多事情其實未列在WBS中，他就很掙扎要照常繼續回報列出來的項目？還是要重新修改WBS？

(1) 萬事起頭難：起初，專案計劃

作計劃這件事很重要，相關的名言也很多：

• 廟算者勝，得算多也；未戰而廟算不勝者，得算少也；多算勝，少算不勝，而況於無算乎。
• A goal without a plan is just a wish
• Fail to plan, plan to fail
• Plans are of little importance, but planning is essential.
• You can't predict the future, but you can plan for it
• The general who loses a battle makes but few calculations beforehand
• Planning is everything. Plans are nothing!

任何專案管理方法論都會涵蓋”做計畫”(planning)這件事情，原因也很簡單因為這實在太重要。可是也太容易被忽略誤解或輕視。

無論任務範圍大小，多寡，範圍，一個適切的”文字化計劃”對於軟體專案絕對重要！特別是有任務是整個團隊曾經執行過類似的，”原則上”只要根據以前的經驗”照著作”就可以達成，這種特別容易被資深員工忽略的任務特別容易出錯，更何況”照著作”等於是打算重覆過去的經驗，而不是打一開始就意圖要精進。

忽略："現在時間很急迫，不趕快做來不急，就不先搞計劃了"

越是急迫的事情越不能出錯，減少出錯的最基本方式就是先行計劃。更重要的是簡單的思考整件事情，並且寫下來，適事情大小，不但不花太多時間，而且最能降低的風險以及未來避免浪費時間來修正錯誤。

誤解："作計劃要花很多時間"

一個複雜的任務絕對需要花時間計劃。但是一個簡單的任務，可能只需要花15分鐘把心裡想做的事情簡單地寫下來。這個過程就可能會讓團隊避免發生前述案例中無聊的錯誤和不必要的問題。

輕視："作計劃是給老闆看的，反正事情都不是照計劃進行，計劃對我們沒有用"

這種想法跟不打算作計劃完全一樣。等同於靠運氣跟個人當時心情來決定最後任務的好壞。

做計畫並非僵化，計劃的本身形式也不拘，一個簡單的心智圖(mindmap)就可以整理思緒 揭露許多未來的可能性。

下圖是本文撰寫的第一個計畫，可以和最後的結果比較看看，雖然粗糙，而且之後順序以及結構也有很大的改變，但是計劃的本身卻是很簡單可以引領思考。

　

(參考案例二）：

有個售前支援團隊，與各國業務長久一起合作習慣了，常常四處進行軟體產品展示任務。有一天得到通知要去東南亞某國家進行安裝測試，大家都以為當地業務會大致把前置作業搞定，因此就迅速訂機票出發。到現場才發現，客戶負責的技術人員當天根本就沒來上班！整個作業只好延宕一天。

任務分配

團隊合作必然涵蓋工作分配。在資訊科技領域中，分配的方式也有很多種。而對於一個團隊的技術領導者而言。當已經對自己以及團隊的能力有基礎認知之後，有效的工作分配是一開始就要先計劃的事情之一。

技術領導者必然是已經瞭解自己也大致瞭解團隊能力，同時也瞭解任務內容之後，才能進行計畫任務分配。任務分配可以是團隊所有人一起討論，也可以技術領導者自行決定，但無論如何一定要先考慮團隊成員能力彼此之間的比較利益。

比較利益法則最早出現在經濟學鼻祖大作國富論的第一章(亞當斯密,1776)。衍生的，基本概念很簡單，只要有效分配，任何情況下都可以達到1+1>2的效果，即便專案成員某些人明顯地比其他人能力還差。

(2) 專案專案執行中面臨的問題

專案執行面臨的問題 - 人的偏誤

人類判斷事情會先採用快速直覺，這乃是上百萬年來的演化，無論是視覺上還是意識上皆是如此。以下簡單列出常見的人類認知偏誤：

歸因謬誤（Attribution Biases): 

解釋別人的事情時，會傾向別人的內在因素，解釋自己的事情時，會傾向外在因素。例如：會議有別人遲到，心裡會想這是這個人紀律問題，沒志力起床。自己遲到，會解釋是因為交通問題，昨天事情太多太晚睡。

錨定效應(Anchoring)：

有參考點或第一次接受的訊息時，會過度偏重參考點。例如某地區最近賣出的房價是一坪100萬，則臨近的房子無論好壞，預售價格為一坪50萬時就會被認為"很便宜"，即便一坪50萬對絕大部分的受薪階級來說還是貴得要命。

沈沒成本(Sunk Cost)：

過去已經付出去的，不管未來的選項如何，其成本都不會變。也就是說不同的選項無關過去的成本，只關係未來。例如當已經花錢買了張電影票，但是臨時聽說同一時間有某明星簽名活動。這時候有兩個選項，一個是繼續看電影，另一個是去參加喜歡的明星的簽名活動。無論是哪個選項，其該電影院票價成本都是存在，因為錢已經花下去。換言之，要考慮的只是，現在看這個電影是不是比得到喜歡明星的簽名重要，而不是考慮如果去參加簽名活動會損失電影票的錢。

過度自信(Over confidence)：

人類對於評估自己的能力時都會過度自信。例如，在一個50個人班級裡面，所有人自我評估考試成績的"名次平均"在技術上說應該是25，但是通常自評估的平均值都會遠小於25。也就是大部分的人都會高估自己的能力。

羊群效應(Herding Effect)：

在團體中，個別成員會不自覺跟著團體中心行動。例如，股票市場中，市場最常發生一直買或者一直賣的情況。而如果是在競爭市場，有特別突出的公司時，其他公司會學習特別突出的公司的行動。

專案執行面臨的問題 - 進度(時間進程 vs 距離進程)

在專案或者任務執行之中，技術領導者多少需要有效評估跟瞭解現況。而目前進度是最重要的"現況"。在比較嚴謹的專案管理領域裡面，有許多評量進展的指標，例如已投入成本和預計完成所需的成本比例(一般PMP常用方式)然而，在資訊科技領域中，比較適當的衡量應該還是以時間進度能準確反應事實。

所謂時間進度指的是，還有多少時間可以達到目的。舉例來說假設某人要去日本玩，從家裡到機場需要一小時，而飛行時間為兩小時，抵達機場之後到旅館需要一小時。因此當我們詢問他的進度時，當他的飛機抵達日本的當下，他會回報進度完成75%，尚有25%未完成。

然而，如果是距離進程，也就是以還有多少距離可抵達就有很大的不同。舉例來說，家裡到機場僅有50km，飛機實際飛行距離為1000km，機場到旅館假設有50km，所以當他的飛機抵達日本的當下，他會回報進度完成96%！只有2%未完成。

單以事實來看，這兩者都是事實，可是呈現於資訊科技控制進度與瞭解現況來說，恐怕是以時間進度比較能夠掌握。畢竟，當一個團隊成員說有件事情只剩5%完成，而且你知道他在這事情上做了3小時的時候，在沒特別問清楚的情況下，你大概直覺上認為只需要幾分鐘完成，而非剩下的5%距離，需要在1小時完成。

不過專案進程的事實搜集，有太多太多慘痛的例子是在混用時間進程和距離進程的估計。事實上，由於人類天生的偏誤，在距離很短的時候，會不自覺採用距離進程來回報狀態。這時候技術領導有意識的取得"時間事實"才最重要。

專案執行面臨的問題 - 技術問題

技術問題層出不窮，不過大部份專案的技術問題，通常可以解決。然而，技術問題通常也很難概化討論之，他和專案的特性以及屬性有關。

不過就軟體專案而言，有個兩個看似有些衝突的基本概念一定要知道：

(1) 每個人的技術能力與技術方面的產出差距可以達到10倍以上。而每個組織的能力與技術產出，也有近十倍以上的差距 

(2) Scrum的方法論裡面，假定短時間每個人的績效不會成長，也不會改變

我們以後會再來討論這兩點。不過建議先對agile, scrum有初步研究。

(3) 專案的結束：好的結尾比好的開始更難

第三個重點，專案的結束。很多大公司，無疾而終的專案很多，軟體專案通常無論如何都還是會結束，只是結束的方式好不好而已。

礙於篇幅，我們在日後的文章再來討論專案的結束

---

沈思：

* 為什麼這次有些項目會在日後再討論，沒辦法先提示一些重點嗎？

* 對於務實的專案管理方式的諮詢服務，請與我們聯繫。