企業巫醫 - 如何拒絕或調整客戶不合理的需求

在各類型的軟體開發情境中，有時候開發人員會有機會面對客戶的需求。而最近就有一位研發團隊的工讀生，在即將離職時，問了一個經典的問題：

--------------
你們是如何拒絕或調整客戶不合理的需求？
--------------


問題的本身很經典，但是卻必須要追本溯源。

首先，需求(requirement)本身是很難被界定清楚，因為客戶也許也不能清楚的界定需求。Henry Ford 福特 - 福特汽車的創辦人，現代化造車的始祖 - 早在一百年前的名言，至今仍難屹立不搖：

--------------
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼，他們會希望跑得更快的馬"
--------------


然而，「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象，問了正確的問題，正確地理解回答。透徹的了解問題，才能知道客戶的需求是不是真的不合理，抑或，其需求背後有另外的需求。接下來才能知道怎麼反應。

還沒經過深思熟慮就直接拒絕，很有可能是自己故作姿態，甚至是知識技能不足的表徵。(註一) 

反過來說，隨意「答應」客戶，風險也很驚人。因為也許答應了一件根本不應該做的事情，或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸：客戶與企業都受害，甚至三輸：客戶企業與社會三者都受害。

而這聽起來極端荒謬的事情，卻一直在企業界發生。


因為誤解客戶需求，或者不夠及時調整需求導致於雙輸的例子，在近20年內的有很多，隨便找一些範例如下：

* FoxMeyer的SAP引入案例(1,2)

* Waste的SAP引入案例

* 台灣戶政系統當機事件(1,2,3)




那到底要怎麼做？

1. 根據事實的正確溝通

抽象化的形容詞，對溝通不會有助益。

例如：「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」

抽象化的言語，在務實的書面報告中越少越好。當然某些摘要形式的報告，會很抽象，但隨後必定附上務實的參考依據。

例如：

「高可靠度系統」：已兩台伺服器互為備援的方式，達到高可靠度

「網路速度很快」：過去對外連線的速度是1MB，現在提高到1TB，因此網路速度很快。

「網站介面很好用」：過去每個月平均有150次客服電話，是在詢問網站某些功能要怎麼使用，現在每個月僅有10次。並且，每個月平均使用人數並沒有減少。

2. 透過具體內容決定接下來的執行事項

互相理解現在的情況是第一步。接下來要做什麼是第二步。

為什麼決定接下來要做什麼和「客戶不合理的需求」有關？

首先，合不合理的判斷本身就很難客觀。對某人來說不合理的事情，對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見，只要接下來的執行「事項」，確實都是雙方認為最重要的事項即可。

和第一段相同，具體內容必須是清晰可見的動作(action)

例如：

* 將第一批手機抽15%樣本共150隻，進行電池過度充電放電測試。並在N月N號之前，給出測試結果報告。

* 將iOS app送到apple-store進行上架審核。

* 在使用者帳號管理系統上，增加可以使用fb帳號登入的功能，在N月N號之前，給出設計文件。

不是清晰可見的動作，會造成很多不必要的誤解，而誤解就會產生不合理的需求。


不清晰的動作例子如下：

* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試，一隻也可以嗎？要測試哪種類型的爆炸？太陽曬到玻璃破碎也算嗎？)

* 我們的iphone app要趕快上架了 -- (？是要上架到哪邊)

* 讓fb帳號也能登入系統  -- (是什麼時候要完成？只要登入就可以，細節我們自己決定就好了嗎？還是要先看一下設計文件)

3. 務實的密集檢討事實

這可能是最重要，但最被台灣企業所忽略，也最容易被企業巫醫上下其手的地方。

可參考這幾個地方：(a) 錯誤檢討，(b) 自我反省，(c) Scrum檢討


「務實」：指的是根據事實來檢討，而非根據感覺。即便是需求檢討也是。

例如：某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊，這樣的要求讓專案經理非常不高興，覺得根本不合理也太不可思議。

如果不務實檢討，那麼每次與客戶的會議，大概就在針鋒相對中度過。但是探究事實，其實是因為該企業內部系統無法擺脫WinXP，而又因為WinXP能使用的IE就是IE8，導致客戶有此需求。就網站廠商來說，當然不可能協助內部全面升級為Win10，但卻可以提供其他在WinXP上，仍然持續更新的瀏覽器(firefox)。


「密集」：指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到，並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤，也會在一定時間內被發現。

「事實」：有時候事實很難全面探究完整。有時候細節太多，即使都是正確的資訊也過於繁複。

巫醫在同樣的事實上，都會有不同的詮釋。例如：經過鞭打火烤病人之後，病人仍然掛了。巫醫的詮釋通常是：惡靈不願意離開病人，是天命所致。

而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開，乃是天命」。而應該「改變」執行方式，應對不合理需求。如果巫醫不願意改變(註二)，換一個醫生是根據事實最合理的方法。

---

註一：違法的需求，當然是要直接拒絕。這類型的基本常識，不在此討論範圍之內。
註二：如果巫醫很容易以事實說服，那就不是巫醫了

因為沒挑戰想換跑道：先檢討自己吧！

新的一年，總是容易遇到討論換工作的事情。目前，台灣資訊科技領域整體仍然缺乏人才，因此要換新的工作是非常容易的事情。

真正的問題在於：什麼原因想要換工作？如何換？新工作或事業會不會比較好？自己到底想要什麼？

這些問題根深蒂固地存在每個人的身上。不會有一體通用的方式為所有人解答。

不過，如果單純只是因為現在的工作沒挑戰性，無趣而想要換跑道，還請以下三點簡單的自我審思一下。

檢討一：「沒有挑戰很無趣」的真正源頭

牌桌上的至理名言：「30分鐘後如果你還沒發現誰是冤大頭，那麼你就是冤大頭」。在企業中，如果你沒發現有任何值得挑戰的地方，那或許你自己就是沒有挑戰的真正原因。

當你的工作變得沒有挑戰，而且無趣的時候，請先確定問題的真正源頭。

是不是因為你的能力或者表現，讓你無法得到有挑戰有趣的任務？還是你的視野讓你看不出挑戰性？

還是這工作或事業的本身，真的沒挑戰性？你已經是有如NBA過去的Jordan或者現在的Curry已經快觸到這個事業和工作的極限？還是你抵達的是自我的極限？

檢討二：選項

選項，永遠是考慮決策的要件。

換工作或事業是一個好選項。但是，在既有的領域中，擴展自己的視野和能力也是一個選項。

換工作是個選項。在大企業中，換部門也是一個選項。換工作這選項中，嘗試新的技術領域是個選項，但是嘗試截然不同的工作類型（例如業務相關部門）更是更大的不同選項。

在現有工作內容中，改變自己的做法以求突破，也是一個解決的選項。

選項可能很簡單，也可能很複雜，而且還會參雜很多人的因素。去除自我偏誤，取得個人最想要的結果，比想像中的簡單。不過，要預設自己以及相關人等有完全的邏輯推理是很難的。（參考：沈思）

檢討三：「沒有挑戰很無趣」有時候是真正的挑戰

在資訊科技的領域裡，多的是把原本看起來無聊的東西，重新找到價值並且延伸的例子。

如果你可以將無聊沒挑戰性的事情，轉成有價值，並且有挑戰的事情，等於是你證實自己絕佳的創意以及實踐創意的能力。

這樣的例子在不管在哪個領域很多，從很久很久以前的gmail，到近幾年的類似snapchat的app，許多都是一開始是沒很有趣，但是找到額外的創意之後，將舊有的東西突破。

隨著組織越來越大，表面上無趣的事情會越來越多，光是默默的忍耐並不會讓事情變得更好，只有把無趣轉換成價值，才能展現自己的創意能力。要怎麼做？可以參考這篇



參考文章：換工作的面試-軟體工程師如何展現價值

---

沈思：
一個海盜集團中的5個海盜找到了100顆金幣，每一枚都一樣的大小和價值。 

由於海賊王想要這五個部下傷透腦筋，自相殘殺，規定他們分配金幣的方式如下： 

1。抽簽決定自己的號碼（1，2，3，4，5） 
2。首先，由1號提出分配方案，然後大家5人進行表決，當且僅當超過半數的人同意時，按照他的提案進行分配，否則將被扔入大海餵鯊魚。 
3。如果1號死後，再由2號提出分配方案，然後大家4人進行表決，當且僅當超過半數的人同意時，按照他的提案進行分配，否則將被扔入大海餵鯊魚。
 4。以此類推

 如果你是號碼1的海賊，應該怎麼分配金幣？

企業巫醫 - 實習生的三贏

巫醫通常會告訴病人事情的「權衡」：是想要錢還是健康？是想要貢獻祭品還是得罪惡靈？當需要獲得健康，當然就要犧牲其他東西。

許多事情的確是如此...總不能要馬兒跑，又要馬兒不吃草。

不過，對於需要創造性思維的現代企業，權衡在於真正的目標，和創意的達成方式。把馬車換成內燃機驅動的汽車，就是革命性的方式讓移動的東西大幅加速而且不用吃草。

企業實習生也是如此。

高明的策略，就可以達到三贏。普通的策略，就會犧牲某些地方。愚蠢的策略就是三輸。

以資訊科技產業來說，三贏的情況是：

對企業組織來說：有低成本的方式，獲得高潛力的「人力」。讓工讀生能先處理簡單，可學習，重複，但是可改進的工作，使團隊成員專注在複雜的開發活動上(註1)。藉此了解這些工讀生未來的潛力，同時也能透過有效分工，提升績效和產出。還能順便展現企業的社會責任決心。甚至，透過實習生循環來訓練組織內部未來的領導人才。

對社會來說：降低新鮮人「嘗試錯誤」的成本，增加投入的生產力。

對新鮮人來說：提早知道自己的興趣和能力。在還沒踏入職場之前，至少對工作有所體認，瞭解軟體工作真實的一面。無論未來是不是要從事同一行業，踏實並且正確的工作經驗，都能引導未來的發展。

普通的情況是：

對企業組織來說：在暑假期間，統一由HR辦理招募活動，發配到各個部門，和夏令營一樣在兩個月期間和團隊一起合作，可能有產出也可能沒有。

對社會來說：讓大學生研究生在暑假能有除了閒晃打電動之外的選擇。

對新鮮人來說：可能像參加夏令營一樣，但只要有認知，還是能學到很多。

有三輸的情況嗎？

會有三輸的狀況，通常是乩童式策略規劃，和不正確的預期：

乩童式策略就像是有件困難的事情，是在我們的智慧能力尚且不能了解，所以我們就去問乩童，而乩童也不懂，但是他可以「起乩」，透過起乩，從其他地方得到智慧，來回答問題。在各個部落的巫醫也都有類似「起乩」的行為。即便只是實習生策略也會有淪落到乩童式規劃的可能。而這樣的策略結果等於是靠運氣，運氣好的時候甚且可會收到好的效果，但不可能永遠都是好運氣。

對企業組織來說：只是因為「聽」企業巫醫起乩之後，覺得弄幾個工讀生來好像很不錯。因此，就隨便找幾個進來。但由於沒有組織，沒有計劃，就只能做沒有意義的工作。更有可能還會故意製造的沒有意義的工作給工讀生。參考這裡。

對社會來說：浪費了人力

對新鮮人來說：對企業造成不必要的負面印象。也沒有真正學習到工作的意涵。

如何達到實習生的三贏策略

達到三贏的方式，當然是以事實為基礎，避免乩童式目的，達到漸進式目標。

以資訊科技，或者，軟體開發相關企業來說，掌握以下事實，就容易達到三贏。

(1) 培訓是必要的：

的確有很多自動自發學習，又很聰明的學生。但是稍稍有計劃的訓練，可以大幅降低走錯路的時間。而培訓不只是「教」而已，找一些主題讓實習生自行學習也可以。

(2) 長期：

對資訊科技相關的工讀生來說，

A: 一個禮拜來兩天，連續6個月。

B: 全天候，但只有2個月。

這兩個方案看起來實際工作時間似乎一樣，但是，最後能達到的學習效果和產出，永遠是A比較好。因為，資訊科技並非勞力型的工作，而是思考智慧型的工作。當實習工讀生對技術產生興趣時，自然而然會再額外的時間，補足在技術和知識上的不足。而且，考慮到前期的培訓時間，超過6個月以上的實習才能可能達到三贏。

(3) 務實：

讓工讀生參與真正任務，但由基本開始。讓實習生去撰寫核心模組，是本末倒置的行為(註 2)。但只讓工讀生去打掃辦公室也沒太大意義 - 除非這是一間專業清潔公司。以軟體開發而言。以下幾件事情都是比較適合的切入點。

A: 簡單的執行測試計劃(test case)：是最容易入手，並且也比較能直接產出貢獻的事情。

B: 驗證文件：例如將api文件中的範例依照手冊執行看看會不會有意外，也是產出貢獻的一種。

C: 專案助理，協助收集進度，現況，簡單統計目前在版本控制系統(例如git/cvs/p4)裡的程式碼增減狀況...。這些看似助理類型的工作，可以讓工讀生對軟體專案的進展有很完整的概觀。

(4) 實習生的週期循環：

工讀生從開始招募，訓練，到離開，最好是6-18月之間。必須要簡單完成的循環規劃。實際的例子如：

A:  招募大三四研一二的資工資管資科相關學生。
B:  為期最短6的月 每週來兩天 時薪固定為XXX元。
C:  到期根據實際表現可能會續約一次。大部分會續約。
D:  座位和電腦設定已經事先準備好 (已經有check-list)。
E:  主要先進行測試相關工作，但偶爾做點瑣事（例如訂下午茶)。
F:  每年的都是由某資深工程師負責，今年負責人為某甲。
G: 合約到期離開的check-list。




(5)利用實習生培育未來的領導人才：

成熟的企業組織通常趨於緩慢成長。也就是說，除非有人離開，不然從升遷為基層主管的機會將會越來越少。然而，在團隊培育領導人才，卻是必然進行。讓有潛力的團隊成員，負責整個工讀生的循環週期。藉此，歷練作為領導主管會經歷的所有關於「人」的大小事情。畢竟，並非所有技術專精的人都適合當領導者，而透過執行實習生的策略，不只培育了實習生，也可以培育團隊的未來領導人才。即便最後發現某些技術專精的人不適合作為領導者，風險也比較低，畢竟他僅只負責工讀生，不是突然之間負責領導整個開發團隊。

很多時候，即便實習生不能達到原本規劃的要求，光是能夠陪為組織內部未來的領導人才就已經十分划算！

---

註1：「簡單，可學習，重複，但是可改進的工作」和之後提到的「無意義的工作」截然不同。以軟體開發中的測試工作而言，雖然某些情況需要大量人力測試，但是，更多狀況是當工讀生了解測試的意涵之後，大多數都能改進測試的方式，在某種程度達到自動化測試。而「做出」自動化測試程式，對工讀生來說就變成可學習到很多的工作。

註2：但也不能排除剛好招攬到一個天才中的天才的可能性。因此如果真有這樣能力的人，應該直接讓他轉成正職。

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

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

那結論呢？

就人類來說，時間是中性的。它不是朋友，也不是敵人。它不是惡靈，也非天使。

在有限的職業生涯，如果你找得到自己的方法駕馭它，那非常恭喜！這可是上天給予的重大天賦之一。

如果始終在瞎忙中度過，或許試著混合數種前面的巫醫建議方式，可能會有些幫助。

但有幾個重點...

1. 考慮事實

企業組織為求營利的天賦，自然趨向去做幾乎任何可能產生商品競爭力的方式。以時間為衡量標準，恐怕是在天然資源和資本取得已經趨近最佳化的情況下，最合理的方式。

如果你覺得在企業組織工作時，自已的時間被無聊的瑣事白白浪費，氣的想要出來創業....那麼，你一定要先考慮是大部分的人，是自己無法控制時間，而非被別人浪費。這種情況下出來創業，會讓你本來每天花8小時幫某公司做事，變成每天花16小時，幫自己的公司做事。

時間既然是中性，增加效率當然是可行。加速？聽起來跟前述的巫醫有什麼不同(註4)？

重點在於：無論是個人還是組織。找到真正的目的，比產出效率重要。

而真正的目的在於考慮真正的事實。企業巫醫有許多手段和方式，都可以協助你找到「真正的事實」。

以個人生涯規劃而言，最終，這個事實也有你自己才能夠斷定。

然而，以在企業組織內部工作，真正的事實，或者是真正的目的，必須要來自「團隊目標」和「組織目標」。

2. 兵貴神速 v.s. 後發先至

重點在於：長期累積比短暫績效重要。

當企業組織可以在某個產品推出時領先，當然要持續領先推出其他產品，或者領先產品的其他服務。在這世界上有太多的先行者，無法保持領先而被後來者居上。兵法也有云：「後人發，先人至，此知迂直之計者也」，後發先至，其實是兵貴神速的對應。


個人工作上也是如此。快速完成的工作，如果不能累積優勢，就浪費了速度。以軟體工作而言，快速完成功能固然重要，但是功能上的完整以及品質，卻是快速的「基礎」。因而，採用敏捷開發的任何方法論，都不能以快速作為藉口，直接放棄功能上完整或者品質。

後發先至的基礎其實也在於「快速」。但是，個人快速的反應，其實是長久實力的累積。例如，對營運Linux平台十分熟悉，有很多年踏實經驗的工程師，自然在對應新的Linux雲端營運(例如AWS,Azure的Linux虛擬機)就比較容易適應。而過去僅在windows平台上有營運經驗的IT人員，如果整個系統要搬移到Linux為基礎的平台上，就算他可以很「快速」完成一部分，也不見得做的完整或者達到好的品質。

3. 時間乃最終之敵人 ...除非...

時間從很多角度來說確實是最終的敵人。它雖然是中性，但是它永遠都會流失。它的離開是必然而且無情。無論這禮拜天你做了什麼，禮拜天一定會過去。

因此，現實的說，時間乃最終之敵人...除非......讓它變成「敵人的敵人」。

以近年來的新興網路企業而言：

無論有沒有特別認知，事實上都試圖以「時間」來建立其他對手的進入障礙。若非以極高的成本獲得市場佔有率，讓其他競爭對手花更多時間才能開發產品，就是以需要時間累積的功能作為競爭主軸。

以個人的生涯規劃而言：

剛踏入社會的新鮮人，勢必缺乏實務經驗，無論是在爭取好的工作機會，或者是已經在企業裡面爭取好的表現，都不能是以「經驗值」來作為依靠。

以經驗值產出「工作表現」，大部分情況下新鮮人是無法和老鳥相提並論。但是相對於工作N年的老鳥比較起來，在「時間」上新鮮人擁有更多彈性。所謂時間，切記並非加班時間，而是「第一次就做對事情」的時間，透過學習和利用比較新的知識範疇，新鮮人可以比較快跳過錯誤的嘗試，在某些未來有發展潛力的範圍，有更驚人的表現。這時候，時間就會是朋友而非敵人。

相對的，已經工作了7年以上的老鳥。如果老是只能靠吹噓過去已經結束的專案經歷，無法產出對應的經驗值，那麼這七年時間就變成是最大的敵人。只是看到最新的技術，就隨意一頭栽進去學習，則時間就會是資深工程師的敵人，因為通常資深工程師的彈性時間實際上比較少。

資深工程師，在工作上必須要找到能夠善用這七年的成功或失敗經驗的地方，並試圖累積更多。即便是想要打掉重練，也應該透過經驗的累積，重練的更快，更好，甚至自動化。找到可以累積的地方，這時候，時間就是朋友而非敵人。

以作為組織內部的部門主管，專案團隊領導者更是如此：

當領導者使用以下手段時，是把時間當做敵人，(然而，要打敗時間實在太難)

* 加班
* 在軟體專案延遲時利用人月計算方式增加人力
* 以未來的產能估計時間，而非以過去的事時估計
* 以各種理由拖延專案，包含把責任推到別的團隊身上
* 專案過程並未檢視真實進度
* 假裝使用agile敏捷開發，實際上還是waterfall
* 不正視事實
* ....(還有很多)...

那麼不採用以上手段還有什麼可以做的呢？當然很多！如果你是領導者，但是想不出來其他方式，那麼你可能不適合擔任困難任務的領導者，因為「時間」永遠是你的敵人，而幾乎沒有人可以打敗時間。

---

註1：CP值，或者性價比，請參考這裡。

註2：這句話很多人都講過，包含郭台銘和柯文哲。不過，這個名言最早應該媒體大亨：梅鐸所說。另外，這句話在2002年也是某本書的名字。

註3：將時間視為第四個空間維度來描述，請參考狹義相對論。

註4：增加工作效率？聽起來和前述的巫醫有什麼不同？就想要達到的效果來說，有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理，經過有效驗證，而且可以在未來檢討改善。

企業巫醫 - 人才管理...人才根本無法被管理

任何能在企業講幾個小時的顧問，都一定會說「在組織中，人的問題最重要」

雖然這句話說的似乎很有道理，但是等同於廢話。這和「颱風明天會來，所以會刮風下雨」一樣，人盡皆知，說了等於沒說。

但是只要是軟性的課程，例如：成功主管的教練技巧之類。都會開宗明義的，告訴虛心向學的主管們，「人的問題很重要」，並且在接下來的8小時，展示一些似乎有用，但很難執行；或者幾乎沒用，但容易執行的技巧，來讓經理們主管們理解：「人的問題很重要 - 但是也實在太難  - 請自己好好體會，好好努力吧」。比較好的顧問，會拿自己豐富的失敗經驗(註1)，用作為警惕 - 這樣還算有價值。但只靠講話的顧問，就只能如同電視名嘴一樣，以幽默的方式打發大家的時間。

既然知道困難，也應該認知困難的地方，透過承認困難，踏實的因應困難，才能在人才培育與經營上找到對組織有用的創造性作法。

對於眾多企業巫醫來說，讓事情變得越複雜，越困難，越不能解決，自然就容易強化巫醫的效果，並且萬一巫醫的作法不靈驗的時候，也容易找到推卸的方式。畢竟，是惡靈不願意配合你的祈求，不是巫醫的錯。

如果你恰巧是資訊科技的主管：無論是軟體開發團隊經理，或者資訊部門主管，只要你負責「管理」團隊，則團隊的人才經營策略，應該會是你最先要考慮的。

無論組織有多大，無論你的職位有多小，無論人資部門的策略是什麼，無論工作壓力有多大，無論專案團隊所使用技術多神奇......無論任何理由，團隊的人才經營策略，應該是團隊主管首要考量的事情！

每個困難，作為負責管理人才的主管，都應該試圖做出合邏輯的，可執行，有創造力的解決方式：

困難一：區別人力與人才

人才之所以難管理，是因為「人才」根本無法被管理。「人力」才能被有效管理。

所有大型組織，很難真實區分人力跟人才。即便是做機械性動作的生產線員工，在效率和品質上仍然有極大的差別。從早期豐田Toyoto的全面品質管理(TQM)開始，到1999年許多人的智慧統整出精實製造(Lean Manufacturing)：揭示了一件明顯的事實：

「實際做事情的人，才是真正知道怎麼做的人」

但是，這個事實卻也隱含著另一件事情：

「在實際做事情的人之中，有些人才，才是真正知道怎麼做才好的人」


但人力跟人才很難區分。以資訊科技為例，任何可衡量的指標，都只能短暫有限的區分人力和人才的差別：無論是寫程式的速度品質，完成任務的完整度時間，程式維護的難易度，對新技術學習的速度等等。這些可衡量的指標，可以很快挑出老鼠屎，可以有效的找到連人力都不算的冗員，但卻很難在短時間裡認出千里馬。

把所有可找到的指標，綜合起來，確實比較可以找到潛在性的人才。但是所花的時間成本太高，而且利用指標的做法，很可能會無意間讓組織朝向「指標」前進，而非「目的」前進。

例如，以軟體專案為例，如果指標是「完成code行數」，配合「每千行code發現的bug比率」，則有可能會產生一個大而無用的系統，程式碼很長，而且根本不會被用 - 當然也不會有bug。

任何在人才策略上，所使用參考的指標，最好都是「隱性」指標，而且必須是簡單有用，常常可以反覆檢驗。例如，這個員工，過去12個月，曾經「主動」提出並且「實作」過哪些軟體專案重要的模組。或者，這個員工，在過去12個月，曾經「主動」做過哪些和軟體品質相關的事情。


此外，以過去的貢獻和產出為區分的標準：這在軟體產品開發上是一個稍微可行的做法。但是，所謂的過去貢獻，不應該是過去35年的貢獻和產出，頂多是過去3年的貢獻和產出。而也必須要確保，這些產出，能有效被歸屬。

舉例來說，一個軟體團隊有10個工程師，共同完成一個很了不起的產品，然而因為市場的關係，產品銷售不好，最後也停止銷售。這10個工程師，仍然擁有產出的貢獻歸屬。但是！這個軟體專案的專案經理，就應該承擔產品錯誤的責任歸屬。然而，由於大部分的產品經理都能言善道，因此，最常看到的是產品經理拿著過去失敗的經驗，拿來宣稱他「從錯誤中學習」，「得到寶貴的開發經驗」，更糟的是宣稱「產品的方向沒問題是公司策略改變」。

從錯誤中學習當然是寶貴的經驗，但是「必須真有學到，然後在爾後，因這些錯誤經驗而成功」。單只有「失敗的經驗」對未來毫無意義。請參考飛鼠裝跳傘(註2)。


在科技軟體產業，最踏實地的區分出人才的方式是：

(1) 面試時以情境實例面試法，了解他過去「做過的事情」，而不是未來「想要怎麼做事」

(2) 衡量工作情況是以「做出來的結果」，而不是以「講出來的結果」，當然也不是以待在公司時間長短，請假的多寡，發表的意見等等...

(3) 盡量試圖找出人才，而不是找天才。換言之，每個人都有某些能力和特性是組織所需要的，只要這個人可以把能力和特性「貢獻並且產生」出來，那麼他就是人才。反過來說，如果他會10種程式語言，還專精6種作業系統，並且還可以解決NP compete問題的難度。但是，卻因某些因素，沒辦法貢獻他的能力到組織或專案中，那麼他依然「不是人才」

困難二：培育或取得人才

資訊科技產業大部分都會宣稱自己很願意培養人才。少數倒是很誠實地說，他們想要直接用挖角取得人才 - 特別是最近幾年的中資企業。

由於培育人才表面上會遇到「培育後被人挖角」的風險。並且，取得人才，表面上通常能在比較短的時間，開始貢獻到企業。因此，許多在成本上沒有限制太多的企業，對於中階人才使用直接取得，也就是挖角，的機會越來越大。

這兩者都有很大的困難，但就資訊科技的角度而言，無論打算培育，或者直接到人才市場找到最適當的人，都不可能避免要「人才培育」。

資訊科技人才無法由人力資源部門統籌培育，必須要由技術性的部門執行，但是技術性的部門卻不見得有空，也不見得會知道重要性。

因此，常見情況是：「我們是on job training，有問題盡量問」。

代表事實就是：「我們不會，也沒有時間訓練你，將工作交給你之後，你就要自己想辦法學習，並且搞定它，當然有問題資深的人如果有空就會回答你。過一段時間你能生存下來就是好員工」

這表示，這個組織對人才培育的策略是......沒有策略，完全看個人造化和運氣。當然，最後的組織在人才運用的結果也是看造化和運氣。

對於規模夠大的組織，其實是可以用所謂沒有策略的方式，因為人數夠多的情況下，某些人才常常能夠單靠自己的能力，脫穎而出。但是在這種情況下脫穎而出的人才，很容易就會被其他組織「取得」。

雖然人才培育很困難，但是比較腳踏實地的做法是：

(1) 對剛加入的人，無論資深還是資遣，根據組織的現況，給予1-3個月的足夠學習期間，訂立學習計畫，在還沒有正式給予任務之前，有對整個團隊，先有全盤性的了解。

(2) 對於已經在組織很久的人，盡可能就現有的專案，進行延伸學習，這個延伸學習不見得是要去上課，可以提供他們「考證照」的經費，讓他們透過「考證照」來主動學習。請謹記：考證照不見得要考很貴的，因為重點不是在於證照本身，而是在於學習。

困難三：薪資獎勵

對於白領技術人才而言，薪資獎勵難以取得真正效果。

首先，傳統的增強理論，對人才：完全沒用！完全沒用！完全沒用！

但是對人力或冗員倒是有些效果。但企業組織為了表面上的公平，通常會試圖制定一體適用的政策，因此，大部分的傳統企業，或多或少都會運用蘿蔔跟棍子。

薪資獎勵，無論有多驚人，都屬於保健因素。換言之，如果不滿意，就很難留住人才，但如果滿意了，也只是「錢有到位」如此而已，一旦不能滿足激勵因素，換言之就是「心委屈了」，仍然無法用薪資獎勵來留住人才。

但反過來說，用夢想，希望，成就，甚至改變人類的命運等等「自我實現」的理念來作為取代薪資獎勵，恐怕也絕對行不通，因為激勵因素和保健因素，兩者無法互相取代。參考：雙因子理論。

大型組織中的某部門，或者某團隊負責人，通常也無法對薪資有大幅改變的權力，頂多是在年度考核的時候，決定某個人加薪的多寡，或者紅利的多寡。薪資獎勵，對有足夠規模的公司而言，整體結構早就是固定的，第一線主管僅有調整的空間。因此即便可以透過薪資獎勵來激勵員工，也不可能巨幅調整。即便可以巨幅調整，也不可能長期滿足。

因此，資訊科技根本不可能用薪資獎勵的方式激勵人才，留下人才，讓人才持續對組織貢獻。

既然不可能，就要換別的方式：

無法用薪資激勵人才的解決方式：

(1) 選擇

提供選擇，或者讓團隊了解選擇。

早在2008年，Zappos就已經設立了離職獎金。讓想要離開的員工，更容易選擇離開。因為，一個勉強留下工作的人才，肯定不會認真付出，他就會成一個人力，更慘的是會變成冗員。而組織要花更多的時間成本。

在台灣作為第一線主管，大概很難說服人力資源部門執行這麼激進的作法。但是，在職權範圍之內，可以清楚的告訴成員，離開組織是一個選擇，當然很歡迎你做出「貢獻」組織的選擇。大部分的人才，在被鼓勵自由選擇的情況下，一旦做出留下的選擇，其貢獻一定會是「人才」的貢獻。

這也不是什麼新鮮事。

從1945-1962年間，不斷重複進行蠟燭實驗。到最近一本很紅的書：如何讓馬飛起來，之中提到的Amabile所做的獎勵 vs 選擇研究。都不斷指出，有創造性的工作，在事先已經知道有獎勵的情況下，其實績效比較差。

以下摘錄自「如何讓馬飛起來」一書：

60名大學生，他們將參加一項人格測驗才能拿到學分，測驗過程中，研究人員假裝錄影機壞了，無法繼續進行。然後她告訴其中一組，稱為「無選擇─無獎賞」組，他們必須完成拼貼畫來代替測驗。另一組「無選擇─有獎賞」，必須完成拼貼畫，但是可以得到2美元。詢問第三組「有選擇─無獎賞」，是否可以做一幅拼貼畫，但沒有任何獎金。再問第四組「有選擇─有獎賞」，是否願意做一幅拼貼畫，拿2美元獎金。為了加強獎金效果，她在獎賞組創作時，把兩張紙鈔放在他們面前。最後全部的作品由一組專家進行評審。這次實驗裡，獎賞果真激發出最有創意的作品──來自「有選擇─有獎賞」組；但最沒有創意的作品，也與獎賞有關──來自「無選擇─有獎賞」組。沒有獎賞的兩組，得分在兩者之間。就創作而言，選擇改變了獎賞所扮演的角色。創意表現最差的那一組，問題顯而易見：他們感受到的壓力最多。

而「無選擇─有獎賞」，正是大部分上班族工作時的實際處境

但是，如果這個獎勵，是事先有選擇性的，也就是可以選擇，那麼績效會更好。文中所提到上班族工作的情況是，無選擇-有獎賞。

其實第一線主管，是有機會加以改變：只要坦然的羅列選擇，不斷的提醒團隊成員：「這是個全然自由的世界」，「你可以去你想要去的任何地方」，「我絕對不會阻止任何人離職，甚至會幫忙寫推薦信」，當然也要提醒：「我不想要任何人離開，在這個團隊我們會讓每個人有機會成長為人才」，「雖然我不能保證薪水，但我能保證你必有成長」

(2) 人才合作 vs 人力合作 

團隊如何合作，是主管最能影響團隊的事情之一。簡單的說，資訊科技團隊必須要能先考慮彼此優勢，透過發揮彼此長才合作；而不是考慮彼此的劣勢，透過避免發生問題的方式合作。

只要參考經濟學上的比較利益法則，找到團隊成員彼此間比較利益的優劣，就有機會讓大部分的人「變成」人才。

但如果在工作分派是以「剛好誰有空」這種區分方式，就會讓大部分的人變成「人力」。

(3) 成長優先 vs 產出優先

人才的成長培育優先，或者產出也就是績效優先？乍看之下是二選一的問題，其實是必須要獲得雙贏的問題。

請參見：工作太忙沒時間

作為第一線主管，必須要透過培訓以及帶領的方式，有效讓人才成長，透過人才成長，讓產出更有效率。

如果面臨二選一的情況，在短時間當然選最適合的。但是中期長的規劃，必須一定要能滿足兩者。

---

註1: 通常不太會有成功經驗的分享，因為在人才管理有真正成功經驗的人，很難有機會變成企管顧問。

註2: Franz Reichelt， 飛鼠裝的先驅，然而他過去的飛鼠裝實驗都沒成功過，就嘗試從艾菲爾鐵塔跳下，結果當然是...

犯錯怎麼辦 - 光是道歉是沒辦法解決滔天大錯的

人非聖賢，每個人，在任何時間地點，都可能犯錯。而一個人的職業生涯長達數十年，多少都會做出各種的蠢事。

錯誤也有各種不同的情況，細微小錯自然可以迅速改正，但如果犯下滔天大錯，不見得是道歉能夠解決。

最好的情況當然是「永遠不犯大錯」，透過個人本職學能，讓工作不會出現大錯。

但天有不測風雲，有時候錯誤的來源並非是能力不足，只是純屬於結構性意外，更可能屬於前人留下來的問題和漏洞，但無論如何，錯就是錯，大錯就是大錯。

鑄下大錯最好的做法的三步驟是：「面對」「處理」「學習」。但最後最重要的是，發揮創意把劣勢轉為優勢。

(1). 面對 - 承認錯誤，負起責任

如果是自己做的蠢事，道歉當然是必要的。如果不全然是自己做出來的，有時候也需要道歉，例如：企業產品發生問題，而你剛好是產品的負責人，雖然並不是你直接造成問題，但由於你是當時的負責人，自然要負起道歉的責任。

承認錯誤道歉僅只是第一步。負起責任不是簡單的口頭道歉，或者是土下座而已。所謂負起責任是要能「做出」行為。

既然是滔天大錯，道歉之後，隨即就是「妥善應對計畫」。這個計畫，一定要讓受影響的人清楚明白的了解。做計畫要快速，不見得完美，但是要全面，可以使用心智圖來協助達到全面性。

妥善應對計畫就和所有的計劃一樣，計畫的過程(planning)可能比計畫的本身來得重要。計畫的過程會大幅降低「連環出錯」的可能性，計畫的過程會讓「處理方式」變得有效，計畫的過程更可以讓受害的一方的影響降低。

舉例來說，如果某購物網站，因網站管理員操作不當，不小心刪掉資料庫中所有訂單，如果你是該網站管理員，首要之務當然是通知相關人等，道歉再道歉自己發生的錯誤。接下來，擬定「妥善應對計畫」：(1) 評估受影響的客戶數量，試圖從log或其他任何蛛絲馬跡中推估有多少訂單被刪 (2) 評估受到影響的金額，以及已經結帳後如果想退款的快速方式 (3) 首頁建立道歉網址 (4) 建立快速反應小組，提供電話與email讓受影響的客戶聯繫 (5) 相關社群網站或產品網站如果也受到影響需要找負責人協助  (6) 每日固定時間固定地點呈報修復進度 (7) ....這些應對計畫的細項可能有更多，但重點在於，有計劃自然能穩定人心，讓事實可以持續前進，而不會有錯誤的骨牌效應。

(2). 處理 - 誠實處理，控制損害

有計劃之後，接下來就是按計劃處理。處理原則如下：

(1) 誠實

不掩飾，但也不誇飾問題的嚴重性。誠實的處理可以挽回補償的事情，承認並道歉不能挽回的事情。在能力範圍中承諾最大的努力，但也不答應自己根本辦不到的事情。誠實的說明自己的能力不足，但也不能推託自己應該盡的努力。 

(2) 損害控制

既然是滔天大錯，大概一定會有很大的損害。按照計畫，盡可能將造成的錯誤損害降到最低。

(3) 小心骨牌效應

無論是壓力過大，或者環境本身的變化，錯誤常常是一連串發生的。處理錯誤最怕的是一錯再錯。例如，發生重大意外，投入直昇機救援，而直升機又發生重大意外的機率其實明顯的高於一般直升機普通飛行（參閱論文）。

(4) 不馬上釐清責任

此階段的重點在於執行計畫，控制損害到最低。而不是追究問什麼發生，是誰的錯！

(5) 記錄，檢討，修正計畫

即便計畫的執行很短暫，並且很急迫，也不要忘記簡單的紀錄，隨時檢討補救計畫的本身。並隨時修正計畫的執行。畢竟planning本身才是重點，而非plan。

(3). 學習 - 建立不貳過的絕對能力

當處理問題到一定的程度。無法在減低損害，但也不會讓損害繼續發生時。就是檢討學習的階段。

在這個階段，能補救都已經補救，無法挽回也都無法挽回。因此，是要檢討並且未來不會再發生的最佳時刻。檢討的方式有很多種，比較正式的做法為「post-mortem會議」。

會議進行方式採三階段，(1) 事實說明 (2) 事情經過的改善 (3) 避免再發生的作為

(1) 事實說明：

由犯錯的人或者代表人，從事件的開始說明到今天為止發生的事實。僅只是說明事實，並且釐清事實而已。

例如，購物網站不小心刪除訂單，過程可能是因為要釐清報表問題，以commandline方式進入資料庫，由於新增加一筆測試訂單資料，想要刪除資料時，執行delete的動作過程中，竟然忘記加上where condition。

事實說明過程可以提問，但目的是把事實釐清得更清楚。因此不需要問說：「為什麼當初你不這麼做」，也不應該說「你那時候腦袋在想什麼怎麼這麼蠢」之類和事實無關的話。

 (2) 事情經過的改善：

指的是「妥善因應計畫」執行過程中，有哪些可以改善的地方。基本上就是前段所述「處理」過程中的的檢討。如果有紀錄，則應該可以很快找到哪些地方還可以改善。

 (3) 避免再發生的作為：

這個階段就是重要的釐清責任階段。這個錯誤單純是人為錯誤？還是系統性錯誤？環境天災？釐清的過程要伴隨著「為了避免再發生而做的事」

單純人為錯誤：把某個人解僱就之後就不會發生？或需要靠某個檢驗機制？或讓檢查的本身加入SOP？或者過於粗心的人不適合做這個工作？怎麼樣定義何謂粗心的人？

系統性錯誤：這類型的大錯是不是歸咎於之前某人的設計不良？系統設計如何改善？系統性錯誤出現比率高不高？如果不能避免有什麼簡單方式可以大幅降低損害？是不是該雇用高手中的高手做好系統？

環境天災：特殊大地震或者異常天候？很低的機率才會發生？是不是要特別有處理方式？還是因為機率太低，可以視情況見招拆招？還是機率比想像中的高？

可以將所有「行動」逐一列出來討論。

最後，一定要「行動」。沒有行動的檢討，就不具備任何意義。而既然是滔天大錯，就必然一定要行動，才能做到不貳過。

---

I never lose, I either win or Learn: Nelson Mandela

最後，比較罕見的另一個重點：個人的創意與技能，要能將錯誤的劣勢轉為優勢。畢竟既然滔天大錯已經發生，能補救檢討都已經完成之後，有創意的將劣勢轉為優勢，是犯錯的個人最應該想的事情。

例如：一個遊戲app的廠商，推出新版本時，在伺服器端發現可承受的連線數量遠低於預估，導致於許多新玩家無法玩新版本遊戲，而舊版本又已經自動更新成新版本。當然許多新玩家會不滿，但如果遊戲廠商在處理過程中，額外彌補玩家的損失(送出高等級寶物之類)，其彌補的方式有額外的創意，這類型錯誤甚至可以額外吸引新玩家加入，這就是一種以創意和技能，將錯誤的劣勢轉為優勢的可能。

為自己工作 - 契合組織目標

雖然這幾年，創業蔚為風潮，但在台灣，大部份的人還是受雇於組織或企業。

「為自己工作」這句話看似自私，但其實所導引的結果才是對企業組織以及對個人有利。至少，對白領階級的知識工作者是如此。(註1)

表面上，大部份的人似乎並不是為自己工作。實際上，會去工作的原因是可獲得報酬（報酬涵蓋：薪資，技能知識學習，個人成長，成就感，社會參與感...等等），因此，無論表面原因為何，也無論自己是否有認知到這個事實，即便是受僱用者，絕大部份的人是為了自己，或者自己的家庭，而工作。

然而，在職場上常聽到各種抱怨心聲。其中有很大部分，其來源是沒有認知到自己是「為自己而工作」：

例如：

  *  工作很無聊學不到東西
  *  自己的價值不受到老闆重視
  *  對公司貢獻超級高，但是相對報酬卻很少
  *  做事人少，出嘴巴的人多 (特別是在政府單位)
  *  組織方向不正確，快要完蛋了

抱怨不是大問題，但失去自我方向之後，就很難在職涯上突破。個人的工作目的，必須要「由自己想辦法契合組織目標」。否則，就會有「不是為自己而工作」的念頭。一旦有這種念頭，很快的就喪失信念以及工作熱誠。

誠如前述：「為自己工作」這句話看似自私，但其實所產生的結果才是對企業組織以及對個人有利。

如果真切的認知到事實是「即使是受雇用，但自己其實是為自己工作」則進一步更能在工作上展現能力，切合組織目標。也更能給予組織更多的價值。因此，認知事實，才是生涯展開的最重要的事情。前述的理由就根本不會存在。

例如

  *  工作很無聊學不到東西：請隨意google一下就知道，企業組織雇用員工，不是為了讓員工學東西。而是解決問題或者產生新的價值。而工作學不學得到東西，也請google一下，都是取決於自己而非工作的本身。

  *  自己的價值不受到老闆重視：員工的價值就像在擺在口袋裡的針，只要你夠尖，有一天一定會穿刺而出。如果你覺得不是被擺到口袋，那就找到一個會擺你到口袋裡的組織。光是抱怨是沒有意義的。

  *  對公司貢獻超級高，但是相對報酬卻很少：先確定是自己的貢獻真的超級高。以業務員為例，許多大企業的業務，其業績是靠著大企業的品牌和產品，而非個人能力。以程式設計師為例，其程式產出，絕大部分是靠團隊能力，而非個人能力。

  *  做事人少，出嘴巴的人多 (特別是在政府單位)：也許你的生涯規劃就是要去這類型地方？如果是這樣，也沒什麼好抱怨。如果不是，就趕快離開，也沒什麼好抱怨。

  *  組織方向不正確，快要完蛋了：在一個快沉的船上，就是你發揮能力的時候。如果你自認為是個策略舵手，當然應該矯正組織方向。如果你覺得自己是在大組織裡的小螺絲，那麼你為何能「判斷」組織方向不正確？或許是你的判斷不正確？無論如何，你永遠有離開組織這個選擇。



在大部分時候，人總是可以找到契合組織目標的方式？主要有三種：「自然篩選」「個人規劃契合組織」「創業」

1. 自然篩選

當然，企業組織會自然的篩選「契合組織目標」的人。自然篩選的程度與經濟學上的「看不見的手」有過之而無不及。

例如：一個長期處於保守狀態的組織，自然而然會留下不積極的人。一個以退休津貼優渥的組織（例如公務員），自然而然，就會吸引「為了退休而工作」的人。當然，當一個人拼命念書，絞盡腦汁的通過高普考，一進去公家機關就數饅頭等著退休，自然就不會抱怨「工作無聊學不到東西」以及「自己的價值不受老闆重視」，畢竟，進來這個組織的真正目的，其實是為了退休...。

反過來說：一個新創事業，自然而然會吸引想要透過自己的能力，積極開創一片天地的人。而「退休津貼」就不可能是工作的首要目的。但工作是否有趣，組織方向正不正確，就成為關鍵因素。

雖然，個人沒辦法影響「自然篩選」，但如果你的工作目標，和「自然篩選」的目標不一致，當然會工作的很痛苦，而抱怨連連。

解決自然篩選的方式有三種：(1)離開 (2) 改變自己 (3)改變環境

其中，離開是最簡單的。辭職換新工作，自己創業，創業失敗後再創業等等，都是離開。

改變自己很難。但潛移默化之下，很多人會因為自然篩選的環境而改變自己。

改變環境其實難上加難！但是，一旦有機會做到改變環境，你就擁有一個難以言喻的經歷。這個經歷對職涯有絕對的幫助。

2. 職業生涯規劃契合組織

傳統企業組織都知道，激勵員工很重要。但組織出錢出力，費盡心思的「各種激勵」其實遠遠不如讓員工的生涯規劃契合組織目標。

就前段所述，其實無論如何，自然篩選會讓組織留下契合其目標的員工。但這需要起碼數年的時間，而前提也是組織沒有大的變故。 如果組織 - 特別是營利企業 - 的目標和其展示的行為不一致，自然篩選會失衡，要達到平衡。

因而「以個人力量做出契合組織的規劃」才是最簡單，最容易，最能獲得三贏的選擇。

除了工作內容外，每個人常遇到工作上乍看之下不可伉儷的因素，而認為自己無法契合組織目標。在你還沒有丟出辭呈之前，可以執行的個人能力與選擇非常的多。這些選擇都可以有機會做出契合組織的目標。

例如：

* 每天都做無聊的工作：既然是無聊的工作，表示是重複簡單類型，試著將這類工作最佳化，並自動化(註2)。 不知道怎麼自動化？那就去學阿，在工作中學習成長，並透過自動化的貢獻，不但提昇自己的能力，也讓組織獲取更多價值。

* 工作太多，常常超時加班，生活品質太差：所有企業組織，其存在的目的，絕對不是要員工加班完成目的。其存在的目的都是為了獲利。隨著組織分工，以及各種環境變化，容易產生以「加班」的方式來解決問題。這完全可以避免，請參考：解決專案困難的最爛方式; 如何提高工作效率; 80/20法則。也可以網路搜尋一下任何增加工作效率的方式。

重點在於去做！Just Do It！不去做，永遠不知道加班問題能否解決。

* 加薪升遷不如預期：如果是在大企業工作，加薪升遷的確常常不如自己預料。但如果你確定自己有這樣的價值，一段時間一定會被發現，如果不被發現，在離開之前請先想清楚「自己是否真有這樣的價值」？想清楚的方式也很簡單，可以去試著去應徵其他組織，看看有沒有其他組織願意提供給你更好的薪資福利。如果沒有，表示在當下你的確無此價值。如果是在小企業，薪資福利可能無法有大幅成長，但小公司能提供的通常是更多的自由和自我成長。既然你已經自然被篩選到小企業，或許本來就不是很期待制式的加薪升遷了吧。


* 組織做犯法或遊走在法律邊緣的生意：趕快辭職離開！越快越好。你確定你想要加入犯罪組織或者遊走在法律邊緣？！

3. 創業

創業，當然就是為自己工作，當然也一定會契合組織目標 - 因為你就是組織。倘若你創了業，卻因為各種原因，去做不是你訂立的目標的事情，那等於是沒創業。(註3)

不過創業成功難非常高（參考如何確保創業成功）。富貴險中求，高風險當然比較能伴隨高獲利，如果生涯的志向在此，盡可能參考已經成功的典範，或許能降低失敗機率。

---

註1: 藍領階級的勞動工作者可能不全然適用。

註2: 同註1

註3: 當然，也許你是共同創業，或者持有股份很少，那麼請視為在組織為自己工作，不要視為自己創業。

剛畢業準備加入開發團隊 - 三個必要的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) 再花時間去找到為什麼專案需求不明朗的背後原因，






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

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

在資訊科技的公司裡工作的人，無論年資，大概常會聽到有人提到「在這裡學不到東西」「這個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也會有類似的工作，但可能不見得可以取得真實資料。

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

---

參考：努力的三個迷思

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

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

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

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

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

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

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

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

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

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

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

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

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

錯誤三：努力的筆直前進

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

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

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

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

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

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

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

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

---

沈思：

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