如何學好工作英文 - 極簡計畫書

在台灣職場上，英文能力是工作能力重要的一環。英文能力不好，並非職業生涯就會失敗，也不是就不能賺很多錢，只是會「受到各種限制」。有正確足夠的英語文能力，會讓職業生涯有「更多選擇」。

除了在自己的職位上，有需要以英文讀寫和對跨國組織的溝通之外。還有兩件極為重要的
其是：

(I) 擴大其他知識學習的能力。當你可以順暢地閱讀聽取英文資訊時，你路上的知識來源，就遠比只會中文多了數倍。

(II) 擴大資源取得的範圍。當你可以流暢的使用英文，就可以把想做的事情，透過網際網路外包給其他國家。


就和其他計劃一樣，執行力永遠比計畫詳盡來得重要。而執行力是透過「限定時間」的「分階段」採用「正確方式」達成。


如果你目前還沒有自己的方法，或者，曾經試過自己的方法只是不太成功。那麼請考慮這個極簡一頁計畫書。

到此下載計畫書。

這個計畫乃是參考(註1)的做法，與實務驗證改善而來。此極簡計畫適用於TOEIC 695分以下的上班族。


「如何學好工作英文 - 極簡計畫書」的使用步驟如下：

(1) 找到原因，定義目標

第一個，也是最重要的步驟是「坦白原因，定義目標」

每個人真正想學好工作英文的原因都不同。而真正的原因才是讓個人努力的動力。

找到自己想學好工作英文的真正原因。可以用消滅法，判斷這個原因是不是最重要原因。在計畫書中，將最重要原因填在80%欄，次要和第三原因填在16%欄與4%欄。將80%欄遮起來，想像一下，當這個原因消失之後，自己是否就不想精進工作英文了。如果這個原因消失，但是自己還是很想精進工作英文，表示不是真正原因，或者描述的不正確。

請填寫找到真正原因填寫於左上角。

目標是在未來一段時間(14週)預計取得的成長。

極簡計畫有兩個既定目標：

(a) TOEIC 800以上 
(b) 能以英文簡報10分鐘關於現在的工作進展 

另外，可以去掉目標(b)，也可以自己制定目標(c)。但是，沒有特別原因的話，必須要留著TOEIC 800的目標。

在右下角的目標準備，就是為了確保自己已經報名TOEIC。

(2) 學習材料準備

極簡計畫學習教材都是不用錢，而且對工作英文來說效果很好！

「起床後15分鐘」的教材是BBC網站，需要電腦或者手機才能使用。

「空閒的10分鐘」教材是一本英文書。

(a) 聽/說教材

聽和說請用BBC網站教材。這些課程都是以影音方式大約3-7分鐘。
請先設定好書籤於瀏覽器中，或者用手機也可以。實際學習方式請看: (3) 執行 

BBC英文學習課程：有用！簡單！又不花錢！

BBC English You Need
http://www.bbc.co.uk/learningenglish/english/course/english-you-need

BBC English At Work
http://www.bbc.co.uk/learningenglish/english/features/english-at-work

(b) 空閒時間的純閱讀：How to Read a book。

建議直接列印出來。目標是看完第一，第二部分。約138頁，每天10分鐘閱讀一頁半左右。

(3) 時間分配

太長時間等於是挑戰自己的意志力，但是每天工作很累的人的意志力是有限的(註2)。

這個計畫是以3個月(14週)為目標時間，每週6天，每天僅25分鐘。這25分鐘，分成早上起床後15分鐘，和空閒10分鐘。

早上起床後15分鐘

早上一起床，要花15分鐘學習英文。如果你平常是9點起床，就改成8:45，如果是8點起床，就改成7:45，如果是7:30起床，就改成7:15。無論如何，一定是起床後的第一段15分鐘是在學習英文。早點起床學英文，絕對比晚點睡學英文的效果強太多太多！

空閒的10分鐘

在每天空閒的時候：坐捷運，上廁所，上班休息時間等等，花10分鐘閱讀。強烈不建議在睡覺前閱讀。這10分鐘最好是連續的10分鐘。

實際作法請看(3)執行。

在計畫書中央有個6x14的表格。在表格上有開始日期，下方有結束日期。直接填好開始日期以及14週之後的結束日期。

時間耗費其實很少，所以要確切執行，其實不會是時間問題，也大概不會是意志力問題。恐怕只是「習慣」與「執行技巧」的問題。

14周之後，無論如何，時間到就結束，並且以實際方式檢討結果。

(3) 執行！

當極簡計畫準備完成，接下來當然就是執行極簡學習計畫。
計畫執行非常非常簡單，所花費時間也非常非常少。

執行是每天，或者說每星期至少六天，做三件事情：
(a) 早上起床學習15分鐘以上
(b) 空閒時間閱讀10分鐘以上
(c) 把計畫書上的進度表格塗黑，並且自我檢查是不是有按照計畫進行

(a) 首先是起早學習15分鐘

所要做的事情是到BBC網站上，在BBC English You Need或者BBC English At Work選擇一個課程來「聽」。只聽不看，有聽不懂的暫時不理會。BBC的課程很短，大約5分鐘而已，聽完之後，在看上面的英文說明，還有不懂再查字典。

經過3-4天，如果你認為太簡單，BBC也有進階教材：

http://www.bbc.co.uk/learningenglish/english/course/towards-advanced

但是對於簡單的教材必須熟悉到「輕而易舉的理解」，才能進展到進階教材。而坦白說，倘若你的TOEIC成績不到850分，進階教材可能不太適用。

(c) 其次是每天空閒閱讀10分鐘：

找空閒10分鐘閱讀

教材是How to read a book。閱讀方法是印出來，在每天空閒的時候：坐捷運，上廁所，上班休息時間...等等，任何空閒的10分鐘都行，連續10分鐘閱讀。強烈不建議在睡覺前閱讀。


閱讀方式是，直接看完，中間看不懂的字先圈起來，如果可以的話，猜測一下不懂的字的意思。讀完一個段落，約1.5頁，閉起眼睛回想一下這一頁的意思，然後，再去查字典。切勿背單字，應該去了解整個句子的意義。

How to read a book是本經過設計的老教科書，用到的單字有限，其目的是在教學生「如何閱讀英文書」所以，當你看完這本書就可以一舉兩得，確保可以你的英文閱讀能力，真正往前進。

(d) 每天檢討：把計畫書上的進度表格塗黑，並且自我檢查是不是有按照計畫進行。

這個部分最重要的是，不要欺騙自己。請參考下一段(4)過程檢討。

(4) 過程檢討

極簡計畫書中央有個6x14的表格表格。每個格子代表一天，每天當你完成「早上起床15分鐘」和「空閒10分鐘」的學習之後，就可以把它塗黑。只完成一項就塗一半，都沒做就留空。

必須要把這個計畫放在每天都一定會看到的地方，例如辦公桌的某個小角落。表格上面只有開始日期跟結束日期，中間並沒有日期，但請不要趕進度，每天最多也塗黑一格！

如果有不預期的情況發生：例如連續兩天沒有按照進度進行。不要試著去彌補它！不要在某一天連續趕兩三天的進度，而是要找到一個方式，讓這不預期的事情，「以後」不要再發生。不彌補是因為過去的事情本就「已經過去」，和彌補錯誤比較起來，在極簡計畫中，更重要的事不讓錯誤再發生！

(5) 計畫結束

極簡計畫的概念是，無論如何，結束時間一到，計畫就結束了。

這時候必須要知道和原定目標有多少差距，如果TOEIC考了815就表示達成，考了790就表示沒達成。如果可以輕鬆地用英文解釋現在的工作狀態，就表示達成了。

然而，因為是你自己自定的目標，其實在計畫結束後，可以很清楚的看到過去14週以來的成果，即便沒有達到目標，應該會有大幅進展。也不見得要對自己太嚴厲。

重點在於結束之後，可以再次啟動下一階段的工作英文學習計畫。把握原來的極簡計畫的關鍵：限制時間，清楚目標，過程執行，檢討結果，並且不要花太多時間，當然就可以讓自己的下一次計畫效果更好。

到此下載計畫書

問題與解答：

Q1：可否修改計畫書？

Ans：極小幅度更動當然可以，例如把14週變成12週或者15週，把每天25分鐘改成30分鐘。但強烈不建議進行大幅更動。因為此計畫是經過設計與驗證，對絕大部分上班族是最能在耗費最短達到最大的工作英文進步。

Q2：我沒辦法早起學英文。

Ans：無論你現在做的是什麼樣的艱難工作，早起15分鐘通常是可接受的範圍。如果你沒辦法早起學英文，大概就表示你不太想或者不需要精進工作英文。

Q3：這計畫對我來說太簡單？

Ans：此計劃是用於大學研究所畢業後開始工作2-3年的上班族。如果你英文已經很好了(例如，TOEIC已經850分以上）當然就不適用此計畫。

Q4：此計畫對我來說太難？

Ans：如果你已經大學或研究所畢業，然而仍然覺得很難使用英文聽說讀寫，這計畫可能是有點難，但絕對不是做不到，只看你有沒有決心而已。

Q5：為什麼一定要去考TOEIC？

Ans：TOEIC是目前為止，比較有公信力的商用英文測驗，它並不困難，很適合「不準備」的情況下完全按照實力去應考。當然應考前還是要看一下題型，考試方式，跟考試用具。

---

參考：

* 註1：在義務教育的語言學習，大部分的人都認為沒效率而且也不實用，不僅只是台灣而已，而是放眼世界皆然。有本書可以參考一下: Fluent in 3 Months。這本書有中文版。

* 註2：意志力的研究有很多矛盾的地方，請參考這裡。

建立軟體開發團隊 (1) 計畫 組成

... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作，不可能有完美的狀況。但是，妥善的計劃，能大幅降低軟體團隊的運作風險，並且讓團隊成員專注於發揮專長和創意，減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面，例如：

(1) 目標極端困難。例如：要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如：團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成，目標也還沒確認，就已經有時間壓力。例如：一個2-3個人合作的新創公司，剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如：在大企業中，因為高層要求，一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員，在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標，併購等等)，讓某個團隊大幅流失人才，而需要重整補齊人力。

(7) 因為文化與跨國合作困難，導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人，最最基本的認知就是：

軟體團隊組成這件事情：本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊，其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考：

(1) 了解探索事實，盡可能將事實攤在陽光下

許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」，或者「假設在3個月後可以找到2個優秀的iOS開發人員」，或者「假設大部分的使用者都有fb的帳號」，或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下，很多事情的確有假設，才能進行下去。

但是，在建立團隊的時候，除了瞭解背景假設之外，先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景：

可參考下節「確切定義短期中期目標」。如果是非營利組織，團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業，營利組織，除了獲利之外，也可能會伴隨其他更遠大的目的。例如：「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體，也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的，如果只是單單純純想賺大錢的公司，例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的，就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知，才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊，自然不會將社會責任活動當作是團隊成員想要做的事(例如：到沙灘撿垃圾，協助獨居老人)，當然「培育企業人才」也不太需要，甚至Scrum裡面的「自己選取task來做」也根本不用，採用由上而下的軍隊式管理，讓工作以最有效率的方式完成，才是這種團隊的最好方式。


(b) 資源現況：

目前的現況是不可否認的事實，但許多人一開始的時候，會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人。...這就是資源現況。

但也有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣，其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人，年預算只剩下600萬台幣，所以可以找10個人，但是平均年薪只能為60萬，或者找6個人，平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人，資源現況的瞭解和掌握，必須要越清楚越細節越好。實際上，絕大部分的情況下，只要稍微多花個幾個小時，就可以掌握到很多現況細節。


(c) 組成專長：

即使已經是軟體開發的專家，這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定，組合的專長可能大致確認。然而，某些專長不見得是「團隊成員需要有的」，這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段，需要清晰可見的專長分佈圖。

以上圖為例：簡單地列出做一個購物網站可能需要的專長，並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是，這樣的圖並不是要完全技術上正確，而是要做為未來計畫的參考。因此有可能一再修改，也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素：

哪件事情做好了，會讓這個團隊成功。成功關鍵因素應該只有1-3個，不應該太多。 這個關鍵成功因素必須要很「實際」，能夠被「衡量」，當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例，他的關鍵成功因素不只是火箭能發射，還要能「掉回地球後，能自己站立，以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而，建立組成的本身也有關鍵成功因素。例如，在2個月內吸引3個具有5年工作經驗，並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然，不可能花幾百天的時間，只是為了收集事實，只要在合理的時間內，盡量收集了解重要的事實。

(2) 確切定義短期中期目標

前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言，八九個短期目標完成後，差不多就等於一個中期目標完成。

任何軟體開發計畫，必定會有目標，而讓團隊朝向「同一個方向」前進。所謂團隊，當然是一群人往同一個方向前進，才能叫做團隊。一群在同一個組織架構的人，或者在同一個老闆底下工作的人，不見得是一個團隊，很有可能每個人在軟體開發

(3) 根據目標擬定計劃和備用計畫- Plan B

兵法有云「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」

計劃本身並不重要，但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情！

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容：

(a) 團隊目的，短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是，哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示，根據分佈圖，來劃分團隊組成。

切勿用想像的方式。

以上圖為例：這是一個打算建立電商網站的技術分布圖，和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示，團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節，而且也把技術不相干的東西納入（例如裡面有個API doc，其實是還沒有去做的事情）。但整件事情的精神在於「視覺化」。透過視覺化，對團隊的變化才有整體性的考量和規劃，而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡。


(d) 初始化工作項目

當團隊的成員是逐漸到職，最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節，但是是隱含的關鍵成功因素。

初始化工作項目，在新成員到職的前幾天，最好是鉅細彌遺。規劃了新成員第一天到第五天，「每天」要做的事情和達成的結果。並規劃前4週，要達到的大項目，以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短，對團隊的組成越有利。

規劃前五天的細目，絕對不會讓這個新成員變得沒有創意，也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內，先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項，如果在前一段時間沒有擺脫，之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目，同時也是檢閱清單：

Day-1  
    - Mentor介紹工作環境，取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限，確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件，Mentor協助了解文件內容
    - 參加Scrum會議，理解Scrum雞與豬的原則 
    - 在Mentor協助下，建立自己開發環境

Day-3
    - 在Mentor的協助下，在自己的開發環境確定能修改程式/簽入(commit)/建立branch，最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例，這些看似細節，但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡和這裡。

簡而言之，建立團隊的過程也需要被檢討。

例如：

新加入的成員，在當初面試的時候所呈現的能力，和實際上工作的產出，是否吻合。

新的成員對於非技術類型的雜事，是不是很快能找到資訊。例如git的位置，目前各個branch的狀況，自動化建構的方式，建立開發環境的方式等等。

---

註1：如果這個挑戰對負責組織團隊的人來說太過困難，最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天，或者品質降低一些；但是一個失職的領導者，會讓整件專案崩壞。


註2：例如xspace

註3：建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術，需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等

Scrum - 團隊中永遠的反對黨

最近被問到的幾個問題：

   - 怎麼聚焦討論，譬如說有人很愛插話，或者有人很愛在會議室角落另開討論群，或者有人非常堅持己見，很愛先否決對方 ...

   - 有遇過非常固執的人，總是以否定句開頭去否定對方嗎 ？

   - 有人固執的反對什麼事情都反對

....


以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力，並且也假設，團隊成員對於「溝通」都有某種程度的共識和經驗。

然而，實際情況通常不太美好。

** 技術人員常常會因為麻煩，而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心，很多人在開會時候搞不清楚情況
** 某些人常常提很多意見，而且實在太多意見！

任何由人組成的團隊，多少都有溝通問題。如果你是團隊領導者，或者Scrum Master，溝通問題一定是你必須要負責的問題！

Scrum溝通問題，就像處理bug一樣，最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。

建立這三個基本共識，可以讓未來的溝通變得簡單清晰，減少不必要的誤會。

(1) 建立雞與豬的基本共識

專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。

** 負責人（R = Responsible），負責執行 
** 誰批准（A = Accountable），對任務負全責的角色，通常是負責人的老闆 
** 顧問（C = Consulted），提供意見或建議的人 
** 通知誰（I = Informed），被通知結果的人，例如其他部門的相關人等 

在Scrum專案中，可以被簡化成兩種人：雞和豬。(雞與豬的故事可以在網路上找到很多版本，例如這裡)


豬：負責做的人也是負全責的人

雞：所有其他人（當然必須是和這個專案有關的人）

在溝通時，所有雞都可以出意見，但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿，雞只要下蛋而已。

就平等的軟體開發Scrum而言，任務是有自己選取。但是就實務上，專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候，等於是分配「誰是豬」！

任何會議上，對「豬」的正面或負面意見都可以討論，但是最終決定必須要是「豬」。

例如，PM決定哪個功能要先做，而工程師都反對，原因是嫌未來會有其他麻煩的事情產生。然而，就決定功能的先後次序來說，「PM就是那隻豬」而其他所有人「都是雞」。

團隊必須要有清楚的認知，才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知，是團隊領導者的任務。

 (2) 建立事實優先的基本共識

Scrum溝通，必須，而且只能，建立在事實上。

這也是為什麼每日例行會議只說明三件事情：哪些工作完成，接下來做哪些，遇到什麼問題。

假設有人在某討論會議中說「現在UI速度很慢，登入要等很久」。某種程度來說，可能是事實。但是，「慢」以及「等很久」，都只是形容詞，必須要請他提出何謂慢，什麼叫做等很久才能繼續有意義的討論。

或者，有人提出「如果先做A會讓之後變得很麻煩，應該要先做B」。這其實也是模糊的說法，A和B這兩個功能，如果先做A是會讓以後時程延後8小時？還是8天？還是8個月？這才是根據事實的討論。

然而，這種建立於事實的共識，Scrum Master必須要不厭其煩的提醒和導正，才能建立這種共識。

(3) 建立產出優先的基本共識

大部分的專案，都是需要產出某些東西。無論這個東西是軟體，或者硬體，或者某些解決方案。

在團隊討論中，要讓「為反對而反對」的人閉嘴的最佳方式，就是以「產出優先」而不是以「嘴巴講」優先。

例如，某工程師強烈反對A做法，希望改用B做法。最好的方式就是請這個工程師，作出他自己希望的A做法，用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」，那表示他的強烈反對，也不是那麼強烈。

至於對於「只反對而不提出取代方案」的人，其意見大概也只是僅供參考。如果經過負責的豬判斷，其意見很好，當然可以欣然接受，加以改進（例如在code review的時候）。





如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。

不過，越早了解，並試圖解決溝通問題，通常成本越低。

那麼可能的解決方法有：

(1) 自己的問題？

如果你是一個領導5人以上的團隊領袖，無論你的名稱是Scrum Master還是專案經理，如果你認為團隊裡「大部分的人」都有溝通上的問題。

那麼真正有問題的人是你！！

但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為，讓團隊容易產生溝通問題。

問題的產生點可能是：

(a) 試圖面面俱到，顧及每個人的感受，而非先考慮事實。每個人都喜歡受人愛戴，但是在軟體開發團隊中，鄉愿和受人愛戴只有一線之隔。唯有根據事實，腳踏實地領導事情的進展，才是長久之道。為了顧全少數人的面子，或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情，對團隊從來都不會有好處，反而只會讓多數沉默工作者更難獲得信任


(b) 未掌握Scrum精神，只是掌握Scrum的作法。請參考這裡。

(c) 其他，請參考：作為技術領導者的方式。

(2) 解決老鼠屎

如果團隊之中，溝通問題老是產生於某個人。

除非此人是像高斯，愛因斯坦之類的天才中的天才，否則不應該容許有嚴重溝通問題的人存在於團隊。

這類型人有幾種表徵：

(a) 無論什麼事情都悲觀 
(b) 事情不分大小時常抱怨 
(c) 問題都是別人的錯  
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物

其實，每個人或多或少都會抱怨，也會有悲觀的時候。此乃人之常情。但是如果非常嚴重，那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎，即使被稀釋了幾萬倍，也不會有人想吃那鍋飯。團隊也是如此，一個負面老鼠屎，其影響範圍遠超過5個好隊友。

老鼠屎不見得就是錯的，他或許自己創業會變成一個好創業家。因此，及早讓不適合目前至個團隊生活的人離開對大家都有好處。

(3) 縮小範圍

當溝通問題發生，可以將重要的溝通，盡可能縮小範圍，讓溝通清楚簡單。

這聽起來是淺白無聊。但是，實際上在團隊之中，太多無聊的溝通錯誤發生，以致於這麼簡單的事情，仍然值得注意。

以Scrum而言：「DOD」什麼是完成，乃是基本的問題。即便團隊已經彼此合作過一段時間，仍然三不五時要確定一下什麼叫完成。

以溝通進度而言，必然將最近在做的事情，縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說，軟體開發中，如果有一個人的某A任務，需要20個工作天，那麼在3天的進度報告，絕對不能聽到「還有17天就完成」，而是要縮小範圍到：「下一個milestone會是明天，而預期也會如期完成」。因為，最近的一個檢查點(milestone) 如果不能如期完成，就代表未來的17天，很有可能也不會如期完成。反過來說，最近的一個milestone會完成，那麼未來就比較有可能如期完成。

縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。

有個真實的案例：有個團隊舉辦慶功宴，由甲和乙兩位負責。甲很熱心的定好了餐廳，並且就「自認為剩下的事情乙會處理」，然而乙心理認為，既然甲定了餐廳，表示後續的小事情甲也會處理，畢竟許多事情和餐廳有關係。那麼到了慶功宴當天，當然除了餐廳定好之外，其他的雜物(例如當天如何報帳之類)一件都沒完成。

另一個真實的案例：有個軟體開發專案，大家都認為某甲的程式需要重構(refactorying)。但是，某甲認為他需要4周才能完成，因此遲遲不肯進行，大家也難以和某甲溝通。專案經理於是縮小範圍，先找某甲也認為很小規模的一個功能-原本預計一天-加以重構，透過pair-programming，確定某甲專注於這個任務上，最後只花了1小時。因為有這樣的證明，專案經理於是要求某甲先完成全部程式碼翻修，最後整體只花了2天就完成，雖然仍是麻煩事，但遠比某甲估計的4周來的快太多。其原因也很簡單，重構是繁瑣麻煩的事情，當然會被估計成很長的時間。

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

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

因此，在各部落，社群網站總是有各式的「轉職衡量」，「績效評估」，「個人職涯規劃」，「獵人頭的建議」...等等相關文章。(註1) 

不過，就實際情況來說，假如你到「年末」才考慮這些重要事情，那麼已然太遲。


為什麼？

績效評估要及時

大部分的企業在年尾都有績效評估。但以個人職涯而言，這些事情，應該是每隔一小段時間 (例如一個月) 就應該自我有所評估，並調整未來的做法。

就好像今年初打算減肥20公斤，並降低體脂肪到20%以下，而直到年底才量體重體脂肪，基本上已經太晚。即便最後仍然達到目的，也可能只是運氣好。

無論層級高低，無關老闆是誰，無論組織狀態，每隔一段時間，個人應該就事實以及個人產出部分自我評估一下績效。更重要的是，了解別人(特別是主管)對自己的「真正評估」。

自我評估，必須要根據「事實」，與其他人的「衡量」。不應該根據自己的想像，以及感受。

舉例來說，如果你是個軟體程式設計師，每個月你都如期產出符合品質的程式碼，並且bug數量也很少，那麼確實是個好工程師。

反之，如果相較於其他軟體程式設計師，你的程式碼產出低於其他人，bug數量也多，即便你有參加福委會，搞了很好的尾牙活動，你的績效評估恐怕依然很糟。

但由於，許多績效評估是根據「相對績效」來判定。而由於人類有天生的偏誤，自我評估一定會趨向「好的結果」。

因此每一小段時間，你一定要試圖取得主管或其他相關人的「真正看法」。越嚴格的越好。如果在2016年2月，你知道主管對你的績效是不滿意的，那麼你還有很長的時間可以改變(註2)。但如果你是在2016年底年終考核，才赫然發現主管與你對績效的「看法」不同！那幾乎沒有翻盤的可能。

另一個重點在於：績效評估是為了自己的職業生涯，不是為了組織，也不是為了讓主管決定薪資。

如果你覺得，如果要做每月的績效評估，公司/主管應該要主動進行才對？那表示你根本不是個能獨力處理事情的人，同時也表示你的主動性太差，也很難自己成長。

轉職衡量要完整

年底並不一定是換工作的最好時機。只因許多人因為領到年終，所以剛好離開「忍受很久」的工作，所以一時間就似乎有很多職缺出現。然而，某個人忍很久的工作，通常表示下一個人也不一定好受。

換工作的考慮有很多，無論哪一種考慮，都需要基於事實（請參考這裡）。簡單的說，在這份工作遇到的困難沒有解決，下一份工作一樣會遇到。

完整的換工作衡量需要對自己在「事實」上的長期認知。包括過去一段時間有去哪些地方面試？並且被錄取？自己倘若離開這個組織，對組織有沒有影響？自己如果沒收入，可以支撐幾個月？

更重要的考慮是：自己真的想要的是什麼。

那麼，年末可以做什麼？

當然還是得進行轉職衡量，績效評估，個人職涯規劃，參考獵人頭的建議...等等。可是更應該進行的是「檢討自己」與「改變自己的實際做法」。

1. 不設定一年為單位

以個人生涯規劃而言。應該將「一年的結尾」。從新定義為「一個月」或者「一季」的結尾。

並自現在開始，設定自我評估的時間單位，例如一個月。

每個月直接詢問主管或者工作上最相關的人：「有哪些地方需要改進」「哪裡做的事情有問題」「這個月哪邊沒有超乎期待的表現」...。

對於調整職業生涯也是以比較小的單位取得回饋。

當然，這並不代表不能有年度目標，或者五年以上的願景。只是，檢視願景和目標的單位必須要有及時回饋的可能(註3)。而單指個人而言，每個人的記憶有限，根本不可能有效回顧12個月前發生的事情。因此採用Scrum的精神，以大約一個月為單位應該是最適合。

2. 不重複過去無效的做法

恆毅力是一本在誠品門口有超過5公尺橫幅廣告的書。作者以她數年的研究顯示恆毅力是成功的重要因素。

毅力耐心確實是朝著目標前進時不可或缺。不過，實際作法的調整也很重要。以創業為例，pivot幾乎是必要。

每過一段時間，應該就事實來檢討，目前做法是否達到效果。如果沒有，就應該衡量原因，考慮改變執行的方式。不見得一定要改變，但一定需要檢討。

改變當然有可能帶來風險，甚至會比沒改變的時候更糟糕。然而，不改變就沒有前進的可能！

3. 不等候重要的事情

誠如第一段所述，年末考核等到年末就太遲。其他和職涯有關重要事情也是，不應該年末才進行。

因此，今年年末可以設定未來「重要的事情」頂多等到下個檢討點 - 例如一個月後。

每個人所意識到的重要事情都不同，有很多時候心裡覺得一件事情重要，和實際上真的很重要是截然不同的事情。一個人的真正行為，才是斷定他認定重要不重要的指標。

---

參考：

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間？

職業生涯的突破

成長的最好方式：檢討


註1: ....對... 這篇也不例外

註2: 所謂調整，一樣要考慮手邊有的選項：可以針對不好的地方改善，也可以試圖換個工作項目。甚且也可以換工作。

註3: 有些人可能會用「爬樓梯可以一步一步，但是要跳過鴻溝不能分步驟吧？」來辯解過短的時間區間會有其他問題。不過，這真的是問題嗎？跳過鴻溝的確是一次跳過，但起碼助跑的時間和助跑距離的測量，也是必要的前一步啊！

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

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

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


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

首先，需求(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)讓客戶看到，並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤，也會在一定時間內被發現。

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

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

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

---

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

Scrum - 專案壓力來自於無法掌握的命運

一個壓力實驗：

有兩個籠子(A,B)，都連結同一個電極器，各有一隻老鼠。A籠子中，有一個燈號和按鈕，當燈號亮起時，如果在數秒內，A老鼠沒有按下按鈕，則就會產生高壓電極，讓A,B兩籠的老鼠都被電的很不舒服。不過，如果燈光亮了，在時間內A老鼠按下按鈕，則A,B兩籠就都沒事。B籠的老鼠則是全然被動的，只要A老鼠能做好他的工作，B老鼠就沒事。當然，經過幾次電極之後，A老鼠很快就學會了一旦看到燈亮，就應該儘速去按按鈕。

過一段時間之後，哪一隻老鼠的壓力大？

經過健康檢查，A老鼠幾乎看不到壓力大的特徵。而B老鼠，則出現各種癥狀：高血壓，胃潰瘍，成長障礙等等不一而足。

(以上內容取自:數位痴呆症：作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難，而是在於自己「全然」隨著命運擺佈，無法控制。以A老鼠的情況來說，他仍然是被關著，而還得三不五時瞄一下燈是不是有亮，一旦亮了就得趕快反應。

然而，「至少有一件事情」A老鼠可以控制：他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實，固定的時間，以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內，每一個角色都有「至少可以全然控制」的事情，不但可以正確減低無法掌握命運的壓力，更能組合出正確的團隊合作方式。

Product Owner（產品擁有者或產品經理）

在傳統的「瀑布開發模式」，或者，系統整合商SI的「隨意無止盡需求模式」中，產品經理會就所有應該要做的事情列一個驚人的功能清單，交由專案經理負責領導開發。接下來的18個月，產品經理就在B老鼠的壓力下度過，即便有檢查，也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理，更有可能在每一段時間，修改需求，讓開發團隊變成B老鼠，不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任，這個責任用非常簡單而清晰的方式減低他的壓力：「撰寫並排序需要完成的使用者情境」。

專案開始時，產品經理會撰寫數個使用者情境(user story)並且排定優先順序，而每個sprint開始時，團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後，檢查這些當初答應的story是否有如預期完成，並且在下個sprint開始時，或確定，或重新排列，或增加，或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成，並且確定每sprint開頭都能選他最想要的事情先做完。因此，產品經理確實能掌握這個產品每一段時間的「樣貌」，而不是在最後關頭才求神拜佛，或者要求加班。甚至，在sprint的中間階段，若有必要，產品經理可以要求sprint停止，重新開始新sprint，用來調整後來才發現不正確的優先順序(priority)

Scrum Master (開發領導者)

過去一個團隊的技術領導者，帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理（或客戶）以及開發成員中的角色。

在傳統模式下，他若非變成一個技術獨裁者，用以壓迫成員前進並反抗大幅需求改變，就是變成試圖面面俱到的好好先生，用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description)，但事實上，困難的專案，不會因為一個很能講話的專案經理，就變得簡單。最後最常出現的結果是：專案經理總是能有效呈現「自己的貢獻和功能」，但無法反應在專案成功。換言之，常常看到自己從來不失敗的專案經理，曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理，其責任和角色也有很大的不同。而他能有效掌握的事情，也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」：完成了哪些事情，接下來要做什麼，有遇到什麼困難。確保每個sprint開始的會議，領導團隊能完成哪些使用者情境(user story)，並且確定這幾個要完成的事情，產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情，但是透過掌握每一個sprint，腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖，Scrum Master掌握過去真實進度。因而可以有效推測未來進度，並有足夠的證據顯示給產品擁有者。因此，才能有足夠的「動作權力」成為A老鼠：仍然在籠中，但掌握部分真實權力，以減少壓力。

Member (團隊成員)

傳統模式下，團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是：「某功能我們在要X月X日之前出來！」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是，在Scrum中團隊成員，決定使用者情境：「真正完成的所需要的時間」。而這個權力，僅代表一個事實：由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做，只要決定現在在做的事情，什麼時候可以完成，以及「真的去做他」。換言之，Scrum團隊真正的A老鼠，其實只有團隊成員，只有他才會真正的按下按鈕。然而，如果Scrum團隊不能掌握分工負責的精神，團隊成員很快就變成B老鼠：不是被無謂的壓力掌握自己的命運，就是試圖跳脫牢籠。

軟體專案的現實：解決人的問題

無論是否採用agile的開發方式，所有軟體專案，最大問題的來源都是人。

人的問題，通常會極現實的影響專案的進行。然而，妥善運用agile的精神和Scrum的方法，有機會讓人的問題降到某個程度。

某個朋友，姑且稱為K，在專案扮演專案經理的角色，遇到以下狀況：

我最近有遇到一個問題，不知道怎麼辦，下面的人一直做不到我的要求，或者動作很慢，即便壓日期給他，他還是沒辦法達到，但實際上它任務並不多，只是開test case，我不太知道怎樣push他，我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說，解決方式似乎也很簡單。首先專注於優先項目，接下來根據事實檢視工作，最後才考慮能力問題。

一：專注於優先項目

每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保，在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說，要確保團隊成員專注於目前任務上的方式很簡單：就是腳踏實地的「問」。在該成員一來辦公室的時候，就坐到他座位旁，親切的詢問他昨天早上在做哪些事情，昨天下午在做哪些，並實際上「看」到做的結果。就可以確定他是否專注，而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實，而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」，一起坐著看實際上的狀況。

二：工作檢視

以Scrum而言，每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成，沒有完成即便是已經達到99%也一樣是沒有完成。當然，前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum，則應該盡可能在團隊開始時，就先定義何謂「完成」。

以開test case為例，完成是指把要做的功能的test case詳述在某個測試文件管理系統上？還是只要先用excel或者wiki列出來即可？test case完成後是否要先讓團隊成員審閱，看看有沒有問題？要不要先估計每個test case執行會花的時間？test case的前置作業 - 例如建立測試資料等等，是不是也要涵蓋在其中？

當有完整的工作完成定義之後，要讓負責進行工作的人「決定時間」，而非「被決定時間」。

以軟體專案而言，任何超過2天的工作項目(task)，都應該分階段完成。畢竟，就事實而言，一個人不可能「連續工作2天」，每天一定會停住工作，下班回家。而這些階段應該要有階段產出。以test case而言，假設有10個新的user story需要建立test case，則今天完成了4個，表示還有60%尚未完成。

三：能力分配

如果團隊成員的確很專注於工作，而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩，牽涉範圍廣。以軟體專案而言，能力並非只是撰寫程式，測試程式，理解規格等等。能否和其他人合作，也是能力的一環。

一個規模中等的軟體開發團隊(4-7人)，如果有一個人的能力「極端」的差，確實會造成專案很大的問題。

在Scrum的情況下，這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多，但未來的sprint的進度，是以團隊能力來考量，因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下，可以先找到該成員的相對優勢。排定一些學習項目，來提昇該成員在這個專案中的相對優勢，並且在未來安排相對優勢的工作。值得一提的是，根據經濟學的「比較利益法則」，每個人一定會有所謂相對優勢：請參考這裡，和這裡。

關於軟體開發團隊的個別能力，還需要注意以下幾點：

1. 每個人都會成長，但是....

每個人都會成長學習新知識和能力。但是！在中短期專案裡，必須先考慮個別能力與優勢。

換言之，團隊領導要像下象棋一樣，找到每個人的「專長」，能妥善組合專案，就是個好的領導者。

而差強人意的領導者，則是常常試圖規避個別成員的「缺點」，這樣比較不會出大問題，但也容易產生差強人意的結果。而最糟糕的領導者，則會把人當做圍棋，看到人非黑即白，見到專案漏洞時，看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質)，但在軟體開發專案鐵定行不通。

2. 能力是綜合考量...

能力必須綜合考量「全方面」：例如是否好溝通，是否能處理複雜的設計問題，能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外，如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者，應該先思考自己是不是「問題的來源」，甚至要思考自己是不是根本不適合作為團隊領導。

3. 讓不適任的成員離開...

讓不適任的成員離開，某些時候是個可行的解決方案。特別是某些企業管理派別認為，投入時間在不適任的人身上，他有可能變得適任，也有可能不會改變，然而投入時間太多，會造成專案延誤。

以Scrum的角度來說，這個情況不太會發生，因為2-3個sprint之後團隊速度已經確立，無論適不適任，專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言，讓破壞性的不適任者離開，當然是解決方式，但不見得要「找另一個人進來」。

---

相關文章：人才管理，心智圖，為自己工作...

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

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

那結論呢？

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

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

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

但有幾個重點...

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

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

在每年不可計數的企業管理勵志書籍中，有越來越多把「時間」視為判斷事務的重要標準。想當然，個人「時間管理」變成一種必要的技能。然而，更近一步是在越短的時間，達到越驚人的效果，從早期的「24小時學會某東西」系列，到「7分鐘運動燃脂72小時」，都是試圖在短的時間內達到CP(註1)值最好的結果。


時間似乎是最終的敵人？


也許，在某些時候，「搶先一步」是競爭的最佳方式。不是大的打敗小的，而是快的打敗慢的(註2)：就變成企業主事者認定的最好成功方式。畢竟，如果可以用很少的投資(小)，只要用比較少的時間(快)，好像就可以打敗大但是慢的競爭對手？聽起來永遠不吃虧阿！再者，兵法有云：故兵聞拙速，未賭巧之久也。似乎，只要速度夠快，總比慢來的好？

更近一步的說，許多人逐漸視時間為最終測量維度。例如Compete Against Time，就將時間視為在商業上，衡量事務的最重要方式(註3)。甚至有人認為應該是唯一的度量方式。

就經濟學始祖亞當斯密1776年的說法，企業組織價值的來源主要由三種事情組成：資本，土地，勞力。土地：泛指一切自然資源，勞力：泛指人類的智慧和努力。任何商品的價值，都是由這三者的其中一種，兩種，或者三種組合起來。

時間快轉到2016，隨著全球化經濟發展，資本以及自然資源，對於企業的影響已經遠遠不如「勞力」，更確切的說，是人的努力強化資本和自然資源的運用。即便現在存在著比1776工業革命初期更自動化的設備，更能節省人付出肌肉的努力，但面對更趨複雜的環境，人類的「智慧腦力」似乎需要付出的更多，某些人需要付出更多的腦力，讓其他人少動點腦？而最終，變成某些人在相較短的時間，付出較多的腦力，產生較好的結果，可以大幅讓商品的價值領先市場的其他人。


總之，各種訊息「似乎」都顯示，即便時間不是最終的敵人，也是先要處理的「衡量指標」


以廣大勞工而言，衡量生存的指標，就從古時候的「每天能耕多少田」，轉為「每天能在工廠做多久」，而再變成「每天在電腦前面完成多少工作」。只要能在越短的時間完成越高品質的工作，就會越有機會加薪升遷。


然而，事實上只有極端少數的人，能夠妥善駕馭自己的時間，也因此，「時間」變成企業巫醫用來恐嚇部落子民的惡靈之一。


巫醫有三種方式來處理「時間惡靈」

一：加速 - 跑的比它快

各種企業巫醫的，也在強化此信念，教導讀者「加速」用來增加巫醫的崇拜。

例如，最有生產力的一年，超強時間術，早上三小時完成一天的工作，時間整理術... 請隨意搜尋類似標題，一定可以找到超過100種以上的方式，書籍，甚至mobile app。

這些加速的書籍，有些的確是有用的個人經驗，就像南美巫醫累積了數世代的經驗，分辨有效的草藥一樣的有些用途。然而，通常僅能適用於巫醫自己。關於「加速時間」，就像投籃命中率一樣，可以學習，可以練習，但是因為環境的因素，每個人終究有其極限。

事實上，「加速」全然是靠自己的經驗和能力，就像大部分的感冒是靠自己的抵抗力痊癒一樣。採用巫醫的建議手法，確實有幫助，只要自己意識到這樣樣的手法是在幫助自己的經驗與能力即可。過度崇拜「方式與手法」，會容易走火入魔。(參考：2013年的9個todo app)。

二：有效利用 - 80/20法則的極端利用

光是加速，能取得的效果總是有限。頂多取得20%-30%的進步就很了不起。唯有改變方式，甚至改變目的，才有可能取得3倍或者10倍的改變。

從「加速」改為「有效利用」，就成為在2008金融危機之後的顯學。

例如：為什麼菁英都是清單控，Scrum一半的時間做兩倍的事，少但是更好，其實工作不必這麼累 ... 一樣有成千上百的書都屬於此累。

這類型的「找重要的事情做就好」的書，其實真只有這個重點，那就是掌握80/20法則，先做重要的事情，你的職業生涯就是彩色的。

但是，企業巫醫沒辦法告訴你，在你身上哪個20%是最重要要做的事情。誠實的巫醫永遠只能說「施主，這要問你自己阿」。而拐彎抹角的巫醫會用「斷捨離」，「時間矩陣四象限」，「人生優先清單」等等技術性的手法，告訴你，你還是得自己找到那重要的20%。

三：心靈層面 - 永遠都有的一招

幾乎所有的企業巫醫都會的一招：將所有的事情，推移給心靈與精神層面。

例如：心靈慢活療癒，慢活，從容的力量，慢一點成功又何妨，被討厭的勇氣...

就心靈層面觀點而言，這些巫醫也許可以帶來平靜，而平靜讓人的思慮或許可以更周延，並降低更多的壓力。但是，這些巫醫雖然好意的想要讓世界變得更美好，但是絕大部分的人類是社會性動物，試圖全然擺脫外在的影響，等於是要人類放棄天性。當企業組織內變得越來越快速，光是一個人在裡面「慢活」是難上加難。

那結論呢？

請參考下篇：企業巫醫 - 時間乃最終之敵人? (下) 。

---

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

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

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

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

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

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

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

但是只要是軟性的課程，例如：成功主管的教練技巧之類。都會開宗明義的，告訴虛心向學的主管們，「人的問題很重要」，並且在接下來的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， 飛鼠裝的先驅，然而他過去的飛鼠裝實驗都沒成功過，就嘗試從艾菲爾鐵塔跳下，結果當然是...

數據分析從零開始 - (2)資料取得和前處理

既然要分析資料數據，自然要有資料數據才能分析。資料取得是必要的事情。

資料來源有很多種，取得並且事後處理的難易度各有不同。

但可以確定的是基本情況是：

1. 資料的時間，會遠超過自己的想像

2. 在開始進行分析之前，資料整理的所花的時間精力，也會遠超過自己的想像

3. 資料整理，幾乎不可避免

4. 資料整理，沒有捷徑也沒有神奇的密技，只能靠不懈怠的努力耐心以及經驗

5. 實際上有創意，有價值的數據分析，都不能免除資料取得和整理。 

第一手資料：

在「嚴格的一手資料」定義下，做資料分析的人真的拿到一手資料的機會極端的少。不過如果你是購物網站的大老闆，則購物網站上產生的營運資料，web server的log等等，對你而言就是第一手資料。

實務上最常看到的第一手資料，應該就是網頁存取日誌(web log)。在2016年網頁伺服器市場上，apache加上nginx仍然佔了半數以上，其他的網頁伺服器種類雖然也不罕見，但網頁的log格式反倒似乎都很統一，因此，以網頁存取來說，資料取得跟分析都已經存在既有的工具。剩下就看規模和個人技巧。

其他類型第一手資料就包山包海，以業務來說，發票檔案(invioce)當然是貨真價值的第一手資料。以軟體開發來說，git上所有的commit log也是第一手資料。

以現在軟硬體的成本之低，第一手資料原則上都可以盡量保持「原來的樣子」，頂多保存的時候壓縮而已，不太需要進行破壞性過濾處理。

要點一：使用shell 做基本的確認以及雜訊處理。

mac或linux可以用的基本文字處理的技術太多。伺服器的log最基本的處理方式，應該先用shell快速瞭解一下現況。

舉例來說：

以下指令可以把access.log中的第11欄，http response code列出來，並且簡單統計一下各return code的次數。

#cat access.log | awk '{print $11}' | sort | uniq -c

以上圖來說，結果就是有3個http return 400，有134個return 200，沒有任何500的回傳值。至於什麼是http return code，請參考w3規範。

要點二：用excel做最基本統計檢視

過去許多excel版本都有筆數的限制（最多六萬五千多筆），2013之後就放寬很多（大約一百萬筆），請參考官方網站。

即便有數量的上限，也非常值得資料中，先擷取樣本來試著分析。使用樞紐分析表，可以很快看到資料欄位彼此可能的關係，在未來進行分析時候是很有用的參考。

如果到現在你還不知道什麼是pivot-table(樞紐分析表)，那表示你根本不懂excel。  怎麼使用樞紐分析，請參考官方網站的說明。下一篇，我們會用政府公開資料簡單做個樞紐分析表。

要點三：以自動化的方式產生濃縮的摘要（二手資料）

只要能取得第一手資料，盡量使用自動化方式，自動產生有意義的濃縮摘要，這個摘要就算是二手資料。

當然，這要配合要點一的shell文字處理，例如以下指令：

#cat access.log | grep "GET /login" | awk '{print $6}' | cut -d ":" -f 1 | sort | uniq -c

這可以產生簡要報告，說明登入(login)頁面每天有多少人次來使用，執行結果如下圖：

這圖上的執行結果顯示，9/12有15個人次，而9/13有2個人次。

現存二手資料的資料

所謂二手資料當然就是不是直接產生資料的來源的資料。資料分析採用二手資料的機會非常高。

所有組織外部取得的資料，絕大部分都算是二手資料。因此在下一節中會特別說明外部資料的取得處理。

要點一：取得過程的紀錄，以及基本分析

無論資料是自己拿或者這別人給，都需要紀錄取得的過程。

舉例來說，如果IT「自動」會給你一份，wifi的使用者登入時間，以及最後封包產生時間，你就需要有方式「自動」記錄這個過程。

如果是外部網站，也應該要記錄當時取得的方式，假設是curl取得，則用了哪些參數，執行多少時間等等。

基本分析則和前一節相同，先用shell和excel對資料有基本理解。

要點二：正確性判斷

二手資料很可能不正確，或者，對資料的解釋不正確，會大幅影響資料的使用方式。

資料解釋不正確：舉例來說，只要有用過就知道，政府公開資料很多都宣稱編碼是utf-8，但實際根本就是Big5（例如 房地產實價登陸）。

資料不正確：二手資料取得的資料本身判斷正不正確很困難，特別是在大規模的資料收集下，很難簡單判斷正確與否。而且有些資料的正確性，可能連第一手資料來源都不能保證（例如天氣觀測）

但是可以透過「多面向」的方式來探究單一資料的正確性。簡單的說就是多找幾種資料來交叉比對。舉例來說，如果你的天氣資料來自不同的網站，如下兩個圖：

雖然這兩個圖在同一個時間點的氣溫還是差了兩度，不過起碼是一個合理的範圍，因此大致還能知道資料是合理。

要點三：自動化進行轉換格式以及二次儲存

二手資料無論是什麼格式，幾乎都會被轉移格式，或者合併，或者改換儲存媒介。例如csv檔案，常常就被改為json格式並且存進nosql中。

但重點是要「自動化」進行。雖然格式轉換或者改變儲存的形式，幾乎都有現成的工具可供匯入匯出，但是只要太多「人為手動操作」，都會讓資料處理越來越花時間，越來越難保證整個流程的品質。

外部取得資料

<<TBD>> ...請見下一篇