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

你真的知道專案進度嗎？

只要是從事程設式設計相關工作的人，必然曾經參與某專案(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。

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

---

沈思：

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

成長的最好方式 - 反省

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

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

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

檢討反省有三個要點：

重點一：目標導向

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

以帶家人出去玩為例：

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

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



以專案管理為例：

在專案完成，或者一個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上貼文，也可以建立粉絲頁。

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

---

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