如何在工作中成長

過去招募時，常聽到軟體工程師的離職原因，是因為在公司已經沒發展空間，無法成長。在某些情況下的確有可能，但更多情況下是工程師限制了自己成長，並非公司已經沒有成長空間。

每個人所謂的成長有很多種類，有些人追求的是技術的成長，有些人則是職位的成長，當然每個人多少都會追求薪資的成長。無論如何，環境確實是職涯成長的重要因素，只是工作環境的選擇，通常只決定了個人成長的一部分，而非全部！

如何在工作中成長有幾個要點：

(1) 培養成長心態

成長心態與固定心態在過去幾年中常被討論，無論是ted還是書籍皆如此。

簡單的說，擁有成長心態的人會視問題與困難為自己的挑戰，知道克服了挑戰之後，自己會成功並且有所成長。並且，擁有成長心態的人，會審慎看到自己以及環境的問題，不會一昧地把問題歸咎於外在因素。並且，擁有成長心態的人比較容易知道努力不見得會成功，但是不努力鐵定不行。

關於成長心態還有很多常見故事，請自行上網搜尋。但在此舉個反面的例子：完全不具備成長心態的人，會將自己的問題歸咎於環境問題，直接的表現在職場上就容易極短時間換了許多工作，詢問過去做得不好的事情時常歸咎於環境等等。

(2) 建立能和現在環境結合的學習清單

只要是正常合理的公司，通常都有值得學習的地方。有時候，光是公司仍然還能賺錢這點，就已經值得學習。

然而，軟體工程師的天性就是學習「新事物」。對於已經熟練的技術和事物，久了總是會覺得厭倦。厭倦倒是無所謂，重點是厭倦之後怎麼辦？成熟的軟體工程師通常會了解，真實的環境需要的是「能正確無誤並且低成本有效率的工具與環境」，而非需要「最近好像很熱門的嶄新技術」

成熟的軟體工程師能找到環境與自己的平衡，如果要學習新事物，就應該建立學習的方向，最簡單的方式不外乎就是建立學習清單。

技術上的學習清單容易取得，但是，能和個人現在身處的環境結合就需要認真的想一下。

(3) 主動執行

執行自己的計畫聽起來容易做起來難。大部分的情況下，軟體工程師(特別是處於大公司中)都會認為自己在為別人工作。

事實上，至少在台灣就業市場上的勞工都是在「為別人工作的情況下為了自己而工作」。因為現行的台灣就業市場，已經非常接近自由透明的市場，只要「有能力」通常都可以有非常大的選擇。

執行各種學習計畫的要點在於「這是為自己而做」而非為了別人。

一個考慮離開目前環境的軟體工程師，通常會將「能在工作中成長列為尋找新公司的重要條件」。但其實更重要的是要讓自己有能力「無論在任何環境中成長」是為更重要要做的事情。

企業巫醫：手寫的工作筆記，讓你跨越困難

筆記本加上一支筆，大概是最便宜，最容易改善工作的工具。

網路上有非常多「如何做筆記」的相關文章，特別是如何做學習筆記(例如這裡,這裡,這裡)。在職場上，特別是知識工作者，幾乎都有做記錄的必要，然而由於資訊工具的改良，許多人會改用手機，平板，電腦來做筆記。畢竟數位化還是資訊快速膨脹的主流。

在此並非建議走回頭路。數位化記錄，絕對是必要而且有幫助。企業裡面的知識庫，wiki以及追蹤工作工具(jira, redmine, trello等等)，絕對是讓組織整體提高做事的透明度，持續傳遞經驗知識的最好方式。

然而，對於個人職涯發展而言，還是建議要透過工作筆記，來提升職涯發展，增加自己的能力與視野的人，最好還是擁有一套自己手寫記錄的方式。

原因如下：

(1) 手寫的學習效果遠遠超過打字

有太多太多研究顯示，手寫的理解與記憶效果，遠遠超過打字。請參考：這篇，這篇，這篇，這篇。或許有人會說，工作筆記又不是學校筆記，但如果深究這些研究會發現，其實概念相當一致，也就說，手寫某件事情，會增強對這件事情的「理解力」，「創造力」與「想像力」，然而打字卻不會！而廣泛知識類型的工作也是，職場上對事情的理解和掌握越高，越有想像空間，當然工作本身做得越好。

(2) 成本低

當然，現在平板也可以手寫，所以廣義地說，如果習慣的話，平板也是可以。然而，再貴的筆記本，其運用成本，仍然比平板低。除了價格之外，運用成本包含環境限制（例如要充電）。

(3) 手寫讓思考聚焦

無論是用哪種輸入法，即便是最簡單的注音，只要一段時間，每個人的打字數度都會遠超過手寫速度。然而，正因為如此，手寫可以讓頭腦有思考聚焦的功能。腦中會自己思索，應該聚焦的關鍵，進而思考關鍵的意義，這對掌握工作的要點，並且讓一個人在繁忙工作中，找出一條正確的道路有絕大的幫助。請參考這篇。


那麼，要如何做工作筆記？

(1) 立刻買一本

假設你沒有筆記本，也沒有做工作筆記的習慣，那麼就「現在馬上去買一本」。習慣的建立是需要時間。不建議去買很貴的Moleskine筆記本，即使是代購團購的Moleskine也是頗貴。當然它的質感，可長期保存，書寫良好，硬殼和收納設計都首屈一指。不過其實隨便到文具店買不到一百元的即可。

(2) 上班中隨身攜帶，隨時紀錄

聽起來簡單，但要養成比帶手機更隨身的攜帶是有點難。無論是開會，還是座位自己位子上，確保重要的事情，都應該即時簡單的紀錄。筆記本應該是隨著時間紀錄。而且，並不限制記錄內容。如果是開會，建議使用心智圖的方式記錄。
提醒一下，筆記本並不僅止手寫手畫，也可以將重要的檔案email，直接列印貼在筆記本上。未來當重新檢視工作時，有莫大的幫助。

紀錄的內容以「事實」為優先，同時當然要記錄時間。工作記錄並非你自己的日記。雖然，這是自己私人的紀錄，但最好不要紀錄感想或情緒；而是確切記錄事實，因果，困難，解決方案，效果等等。

除了記錄之外，筆記可涵蓋「簡單計畫」，也就是「本來打算如何做」。例如，在工作中發現你對某技術不了解，於是你就在筆記本中草草紀錄一行「學習某技術」。隨即在這行字下面，就可以做得簡單的計畫，例如：1. 10分鐘上網查詢。 2.問一下某某同事。 3.在本週末練習此技術。

當你有任何打算做的事情，拆解成為執行的行動，簡單紀錄，日後就很快可以檢查這些行動是否完成，或者計畫是否要改變。

要注意！工作筆記是幫助你「動起來」的最好方式！

(3) 每月摘要，自我檢討

工作筆記，最最最重要的功能就是，每個月找個20分鐘的時間，將過去一個月自己做的筆記認真看過。然而透過紀錄，回答自己以下問題：(a) 這個月我有做幫助公司組織哪些重要事情 (b) 這些事情做完了沒 (c)隨便換個人也能做這些事嗎？ (d) 過去一個月我有沒有學到新事物(e) 有沒有遺漏重要的事情還沒進行。將這些問題，自我回答到筆記本中。
這種檢討方式，特別適合在坐捷運的時候進行。


筆記本加上一支筆，大概是最便宜，最容易改善工作的工具。如果你認為自己的職涯發展受到侷限，或者遇到困難，而你又沒有做筆記的習慣的話，那麼其實不妨一試，只要長期累積必有成效。

企業巫醫：就業大環境不好的問題該如何解決？

曾有一次面試某碩士畢業社會新鮮人，他說：「許多企業找碩士實習生，都是讓他做高中生能做的事情」。

然後詢問說那麼為什麼大學或碩士在學的學生，願意去做這種高中生會做的事情的。畢竟，在台灣決定選擇實習也是學生的選擇，並非被強迫的。他的回答是：「大環境的問題，市場情況，不能怪學生，他們很多都涉世未深，不知道這些工作沒學習成長。既然是實習，企業就應該有"習"的部分。現在大環境是這樣，並不代表這樣是對的。」

接下來又再請教他，如果你是企業主，這些實習生比較無趣的工作，如果不找碩士實習生，應該找誰來做，他回答是：「可以找私立大學的學生」

其實觀念無所謂對錯，對於這位新鮮人的想法，每個人大概都有不同的解釋。然而有件事情倒是很重要，當環境不好的時候？應該要什麼方式解決？

(1) 個人永遠都有選擇

相較於生在阿富汗，敘利亞，烏干達之類的戰亂地區，大部分的台灣人都有選擇。特別是如果你上網看到這篇文章，就表示你能上網，同時也就表示你可以取得的資訊知識範圍遠比任何30年前的人多幾億倍。

當然，選擇多寡因人而異，但是當你心裡想著：「好像只能這樣」或者是「我這樣的背景就很找到更好的」或者是「不知道該怎麼辦」的時候，也許應該更廣泛的思考有哪些選擇。

有經濟壓力（貸款，家人等等）的時候選擇是比較少。大概不可能離開一個自己很不開心的工作，畢竟還是需要收入。但你仍然可以選擇「自我學習」。

為什麼要「學習」？很簡單就是因為要增加選項

(2) 如何增加自己的選項

不可否認的是，祖上積德的人，一出生選項就比較多。然而，選項少的人也不應該因此唉聲嘆氣。與其花時間抱怨大環境，不如花時間增加自己的選項。

最簡單，而且最沒有成本的是：到公立的圖書館借書，透過閱讀來增加知識。擺脫經濟壓力的最重要的關鍵，而且增加選項的關鍵應該是自己的知識和技能。

不過，學習知識技能也有不同的方式。有些學習時間長，有些較短。舉例來說，如果你突然之間想變成醫生，那麼至少也得花上7年，而且重讀醫學院幾乎是唯一可能。但如果你想成為一個手機遊戲專案經理，卻是有可能從零開始：先主動自願參與手機遊戲測試，再主動閱讀和QA有關的書籍，並開始投遞遊戲測試工作，例如這裡。透過變成遊戲產業的一份子，逐漸增加自己的知識能力...這樣確實是可讓沒有相關技術背景的人，進入遊戲開發的世界。

其他自我學習的議題可以參考這裡。

(3) 不要自我設限的方式

許多人會自我設限，而自己限制自己，是無法面對大環境的其中最最最大的原因。
自我設限的情況例如：

「這個是某部門的人負責的，所以我就不想碰」
「我英文不好啊，所以就不考慮外商的工作」
「家裡有固定開銷，所以沒辦法亂換工作」
「我本來就不會讀書，不喜歡讀書，看到書就想睡覺」
「不知道怎麼開始」
「我就只能先這樣，不然也不能怎樣...」

這些即便都是事實，也對自己沒啥幫助。

然而，想要突破自我設限，最根本的方式是從累積「短期，有成效的事情」開始。例如，英文不好，就買本哈利波特1的英文版，每天花15分鐘讀一頁。累積習慣之後，再開始增強聽力。重點在於「每天只有15分鐘」，一次投入太多，非常容易放棄。

其次，找同伴一起。這就像是慢跑或健身活動，總是一群人比較有效果。人類畢竟是群居動物，在群體中容易自我約束自我成長。

最後，尋求資深的人意見。這也是為什麼網路上，常常有匿名發問，查詢資訊的原因啊。

建立高度自我激勵之軟體開發團隊的三個方向 (軟體主管的31堂課)

1999年美國的籃球夢幻隊1992 dream team 是所有籌組團隊的人遙不可及的夢想。他們除了籃球技術精湛，經驗豐富之外，更重要的團隊都有拿到奧運金牌的唯一目標，此一目標會讓他們自我激勵，根本不需要額外的刺激。這樣的團隊組成似乎可遇而不可求，在軟體開發的世界幾乎鮮少看到例子。

無論如何，建立能高度自我激勵的團隊，是主管最重要的工作之一。如果你是團隊主管，你必須認識到這是你最重要的任務。

自我激勵會造成工程師的職涯成長，而看得到自己的職涯成長，是能驅動效率的最好的因素(註1)。

軟體開發工作，通常是需要高度的心智活動以及集中的創造力。要造就高強度心智活動，幾乎很難單純由「薪水」或者「物質獎勵」來滿足工程師。加薪獎勵與升遷固然非常重要，但它能維持的效果頂多3-6週，之後所有的工程師都會認為這樣的加薪獎勵與升遷是「理所當然」，並且很快地將獎勵拋諸腦後。這不是說工程師都不懂惜福，而是研發工作本來就很大部分的來源會來自成就的滿足感，而成就的滿足感幾乎是加薪升遷無法長期提供的(參考 1)(註2)。非營利事業有可能天生就存在這樣的激勵因素，例如，慈善組織試圖拯救世界的所有窮困兒童，研究組織試圖大幅延長人類生命到200年...然而這些組織一般都有極為獨特的目標以及具有個人魅力的領導者。

一般的營利組織以及軟體開發團隊如何建立一個能自我激勵的團隊呢？

有三個方向：(1)選對人 (2)找交集 (3)自我導航

(1) 選對人

在選用人才時，就先確定此候選人是正面思考，能自我激勵，自我成長。因為要維護一個人的正確態度，比要矯正一個人錯誤態度來得容易太多。

換言之，選擇已經能夠自我激勵，並且確定此候選人在他過去工作經驗中，已經有自我激勵的事實。

不要選擇個人技術能力很好，但卻在自我激勵上面有非常負面的紀錄。因為，要培養技術能力並不難，但要改變人類的思考模式實在難上加難。現存的coach教練式領導，不過也就只是希望透過引導，造成行為上的調整(參考富比世, 英文版？)，要引導到行為心態的調整，教練(coach)幾乎必須要和學員長期合作才有辦法做到。

選擇的重點在於透過過去的實質發生的紀錄，而不是透過詢問未來的問題。這個做法在選人時非常重要，選擇能高度自我激勵的人才，此人必須在過去工作時，已經展現高度自我激勵的情況。例如，你可以詢問面試者：「請問你最近工作上遇到最艱難的狀況，或者壓力最大的狀況，當時你是怎麼處理的」。這個問題重點在於"最艱難"以及"當時怎麼處理"。有時候面試者可能說沒遇過太艱難的情況，那麼也可以詢問"普通難"或者"壓力普通大"的情況。一個工作超過3年以上的人，當然可能運氣超級好，從來沒遇過艱難狀況，然而絕大部分的人，都可以說出幾個艱難狀態。這時候，不需要太早評斷，也不用加入討論，而是要徹底瞭解，在這個狀態下，面試者通常會表達過去的事情和想法，暫且將其想法放在一邊，妥善記錄事實。最後再由事實來判斷。

舉例以下的對話為例：

主管：「請問你過去遇到工作壓力最大的時候，當時是怎麼處理的？」

面試者：「之前在HXC工作時常常加班到很晚，要趕專案當然覺得壓力很大。怎麼處理喔？就想說當練功啊，學到東西我就要離開了」

主管：「當時你如何判斷已經學到東西然後可以離開了」

面試者：「呃？...就那時候我負責的app都推出去了」

此例的事實是。面試者因環境工作時程長壓力大，處理的方式是轉換心態-當練功，並且設定好離開環境的方式。請記得在此並不判斷好壞，而僅是記錄而已。然而，設定好離開環境的方式並不是以學到東西為主，而是做完東西。光是這樣可能還不足盼對此人是能積極自我學習還是消極無法激勵，需要更多挖掘過去的行為的討論才會確定。

(2) 找交集

我們不可能知道別人腦袋在想什麼，每個人都有所謂 left-hand-column，即便已經選擇最能高度自我激勵，自我成長的人才進入團隊，而且他們也都是非常坦誠並努力工作的人。但我們要知道每個人都有不能說，不想說，或者不適合說的事情。 
有些領導者會試圖找出這些事情，但其實有沒有找到不重要，重要的是「重視left-hand-column的存在」。

一個好的領導者，會找出交集。確保雖然人人有不同想法，但整合個人，團隊以及組織的交集，大家可以獲得三贏狀態(win-win-win)往同一個大目標前進！

當然，一個能力好而且能自我激勵的成員，可以自己找到此交集。不過身為領導者或主管，應該要時時注意：每人對這個交集其實都不太一樣。但好的團隊的每個人，應該都有部分交集。

最底線是：一定要避免三輸的局面。聽起好像很荒謬，但軟體開發的世界偶爾常聽到雙輸或者三輸的狀況。不必要的長期加班，幾乎都會造成雙輸或者三輸。長期加班必然會造成人才的耗損，幾乎也不能避免地造成團隊無法緊密成長，所以起碼就是雙輸，最後也常常造成組織本身無法長期經營，那就變成三輸了。

要建立能自我激勵的團隊，找到每個人不同的交集點。如果真找不到，則很有可能該人才並不適合這個組織，如果一半以上的團隊成員你都找不到目標的交集點，或許你本人並不適合當領導者。

交集點的例子很多，某些有資深能力好的工程師，除了團隊環境之外，或許可兼顧家庭是職涯的重要考量。因此，彈性的工作時間，和受到控制的可在家工作，就會是這類資深工程師(註3)的「left-hand-column」而這可能是最容易取得交集的地方。做法很簡單，就是讓資深工程師自行定義產出和目標，

(3) 自我導航

自我導航(Autopilot)是指團隊成員知道自己為什麼要做，知道該做什麼，知道怎麼做，知道什麼時候做。而更有甚者，他知道自己什麼還不會，所以需要特別努力學什麼。

一個能自我導航的工程師鐵定是資深的工程師，他會自我衡量自己在團隊中的「交集」也會自己「選擇」適合成長的環境。換言之，根本不需要煩惱這樣的成員。

對與已經是自動導航的工程師，僅僅只需要「教練式引導」(coaching) 。領導者或主管，應該必須對coaching有一定程度的了解，如果還不了解，現在就是學習的好時候。

在此最底線是千萬不要micromanagement -  也就是枝微末節都要管。大部分的資訊工作都是高度腦力工作，枝微末節都要管意味兩種可能
(1) 團隊成員根本無力勝任這樣高度腦力工作，而你組出這樣的團隊表示你也不適合作為建構團隊的人
(2) 團隊成員可以勝任高度腦力工作，但你身為管理者想要插手，表示你並不了解高度腦力工作的統御管理方式，所以你大概也不適合作為建構團隊的人。

要怎麼樣知道領導者管理者是不是「微觀管理」？只要看他實際做的事情就知道，當時「實際要做的事情」超出「本身的意義」就是這類型。

舉例來說，上班有規範時間，並非微觀管理，沒有規範在大部分得時候反而浪費大家的時間。然而，毫無彈性的硬性規定人必須出現在辦公室的時間，其實就超過規定上班時間的意義。對軟體開發團隊來說，上班時間規範是為了讓團隊容易一起面對面討論，互相砥礪解決問題。例如組織定義9:30~18:30是工作時間，然而，因個人因素不在範圍之內，例如想要8:30~17:30只要該成員能確保他的scrum團隊夥伴都知道他和大家時間略有不同即可，成熟的團隊的紀律來自「自我認知和團隊合作」，並不需要管理枝微末節。同樣的，「規定現在要加班」也是某種程度的管理枝微末節，順便強調一下加班其實是解決問題最爛的方式，尤其是被規定加班。

抱歉 沒有什麼神奇的快速方式！

組織理論其實並沒有捷徑，也沒有什麼神奇的快速絕招。然而只要方向正確，忍耐個幾個月都會看到成效，但是簡單的路總是難行。當然，特定快速的環境 - 例如非常新的新創產業，還不確定能否獲利 - 似乎不值得這樣長期投資？也有不少人主張時間不等人？然而，對大部分的資訊產業來說，大部分的情況是跑馬拉松而非短跑。

技能與績效的考量:

在這裡省略一件很重要的事情！
我們並沒有討論技術能力和工作績效，但其實在軟體開發團隊中個人技術能力與個人工作績效是非常非常重要的！沒有好的能力與產出，要怎麼激勵自己恐怕都沒太大用處。然而，績效和能力應該比較容易在面試與履歷表中檢核出。因此才不在這裡討論。

---

註1:  要使團隊有高效率，自我激勵是最好的方式 。然而其他方式也存在，例如鞭子與蘿蔔。
註2:  但是如果薪水實在太少，不能滿足基本需求，就不在此討論範圍之內。
註3: 不過要特別注意，資深和年紀沒有絕對關係。必須要是做事態度資深，而非年紀資深。

企業巫醫：應該要在同一間公司待多久？

一個在就業市場工作的人，到底應該在一間公司待多久才算「正常」。就產業的不同，自然有截然不同的答案。就資訊科技領域來說，過於頻繁地更換工作，會讓求職者更難找到好工作。

何謂頻繁更換？當在現有工作遇到瓶頸，自己有機會透過自身能力改善瓶頸，然而卻選擇離開就算頻繁。

真要講個數字的話：
* 工作7年以上，在最後7年的職業生涯中，但不在任何組織中待超過2.5年，就會被列入低優先考量 - 並非完全不考慮，而只是不優先聯絡。
* 工作3-7年，但不在任何組織待超過1.5年，也是屬於低優先考量。
* 工作3年之內，其實到不用太在意。

理由是 考量「大部分的情況」，而非考慮「極端情況」。

大部分的情況是：

工作7年以上，但最後的七年，沒有在任何組織待超過2.5年，表示曾經換過起碼4~5個工作。然而資深的工程師，通常其工作內容是比較困難的，並應該能展現其架構設計與實作的經驗。可是，如果其架構設計，並沒有被「市場驗證」那就很難用各種方式評斷他的真實能力。講得更直白的是：也許這位資訊工程師，雖然有Ｎ年工作經驗，但搞不好每次都挖洞給別人跳，自己拍拍屁股就走了。或者是，也許他工作能力其實普通，但「自我感覺太好」因此老是覺得自己應該找到更好的工作。而更重要的事實是，他的確離開了，這事實也表示這4~5個工作並沒有「留才」的意願。兩年半是最低限度檢驗一個工程師，在技術上能取得「市場驗證」的時間，兩年半表示工程師至少經過兩次以上的績效考核，並且其工作的正面負面評價也容易以事實檢驗。

極端情況是：這位資深工程師運氣太差，雖然各方面能力都好，但就是遇人不淑，常常遇到公司倒閉。或者有不得已的家庭因素。

許多企業巫醫都有各種不同的見解（請參見最下面的參考文章），但整體來說，職涯長短雖然因人而異，但最好不要把自己視為特殊例外。而應該以市場上的事實，來推估自己職涯最適合的況狀。

舉例來說，有些人認為只要沒有成長學習性，就應該換工作，但是過去七年沒有一個工作做超過兩年半，難道表示這五個工作的內容「統統都學精通」？如果老是遇到不好的工作機會，是否就表示「自己對專業工作機會的好壞判斷有問題」而專業機會的判斷，通常也是資深工程師應該要具備。

就業市場的事實是過於頻繁換工作「通常」表示有問題，頻繁換工作的大部分人是屬於通常，而非特殊例外。


參考文章：
* 在一個公司裡為何要待十年的十個好理由
* 在一個公司待太久不好嗎？
* 在同一公司內部發展職涯才聰明
* 在同一間公司不要待超過四年喔
* 你在公司待很久了嗎
* 在一個公司待太久會對職涯不利嗎？

何謂：資深工程師

在招募人才過程中，經常被問到「資深工程師的定義是什麼？」

以軟體開發的角度而言，資深工程師有三個面向：

* 技術能力
* 實質經歷
* 團隊合作

聽起來簡單，其實不太容易。

技術能力指的是對「現在使用的技術的直接掌握能力，以及持續成長態度」。

實質經歷指的是「過去曾經做過哪些事，取得哪些成果」。

團隊合作和前述的實質經歷略有關係，不過指的是「處在組織裡，透過自己的能力對組織造成正面的影響」

在人才招募中的過程，在有效時限內，對應徵者針對這三個面向判斷是否符合「資深工程師」是有點難。有幾個方式可供參考。

技術能力

現在使用的技術的直接掌握能力。最簡單的方式是設計考試或者實做作業，根據其結果來判斷技術能力。典型的證照例如SJCP, CCNA都屬於此類。當然， 也常有組織採取直接面談的方式來判斷技術能力。

直接掌握的能力，當然不包含應徵者，自我宣稱說："這個我google的到"，或者，"我不記得但是查得到"。畢竟大家都可以查得到，既然都查得到就不是判斷的標準。

技術能力的判斷上：考試，作業，面試各有其優缺點。簡單的說，人為介入越多，就有不客觀的判斷；但是，無人介入的純客觀單純考試，難以判斷設計概觀等複合的技術能力。

使用半開放性的實做作業，加上2人以上，事先決定好的面試結構，應該是比較妥善的方法。不過，請避免幾個認知偏誤：(1)月暈效應 (2) 羊群效應 (3) 觀察者效應。這些偏誤，在技術面試時會特別嚴重，因為許多人會誤以為技術面試很「客觀」，但實際上，所有面試都很主觀。唯有特別注意偏誤，才能盡量降低主觀性。

月暈效應：因為某些光環，讓面試官覺得應徵者可能很厲害，而沒有去驗證事實。舉例來說，有三十年程式設計經驗，又做過某些驚人專案，就假設此應徵者「隨便學什麼都會」。又或者某應徵者可能是網路傳說的「大神」，就覺得他可能很厲害對團隊很有幫助。

羊群效應：面試之後的討論，如果有人先有意見，沒意見的人可能就會追隨之前的意見。

觀察者效應：因為外表或履歷表的直覺或第一印象，而讓面試官試圖尋找錄用或者不錄用的證據。而非客觀的先收集事實。

最後，在技術上持續成長態度很簡單，能認知到一個事實「當自己學的越多，表示自己不會的越多」，並且真有實質行為-固定閱讀也好，非工作之外寫程式也好，其他任何實質行為佐證對資訊技術有成長喜好。

實質經驗

所謂資深，當然表示在軟體開發類型的工作上，有很多經驗，並且這些經驗取得成果。

資深的實質經驗，通常包含「好事」以及「壞事」。更重要的是，經歷過的壞事，知道如何真正改善它。並且認知到，不是所有錯誤都是別人的錯，必然有自己的錯。

面試實質經驗也一樣要破除上一段的認知偏誤。就不再贅述。

團隊合作

資深工程師，能體會真正的團隊合作要素：(1) 技術溝通透明 (2) 控制進度透明 (3)  立基於事實的溝通

技術溝通透明是指：任何單純技術上的選擇，使用，表現，都是透明的。簡單的說，能真正了解技術完全不需要任何的隱瞞性。

控制進度透明是指：了解透明進度對團隊非常重要，並也了解：控制進度的單位是時間，而不是工作內容。

立基於事實的溝通是指：雖然許多事情必須要有假設和猜測，但就工作上的決定，必須要盡量立基於事實。舉例來說：「我覺得最近的release可能會有問題」這就是一種猜測的說法，然而：「最近的release並沒有執行回歸測試，所以我覺得可能會有問題」這也是一種猜測，但卻是立基於事實的猜測。

企業巫醫：市場領導者的鐵律 .(書摘)

Discipline of Market Leaders 市場領導者的鐵律。

不確定是否有中文翻譯書籍。

書中描述，要成為優良企業組織，必須將以下三件事，做到某種可接受的程度，並且必須要在其中一件事情變成市場的領導指。

(1) Operational Excellence 作業最佳化
(2) Product Leadership 優質產品
(3) Customer Intimacy 客戶關係


(1) Operational Excellence 作業最佳化

產出高效率，低價格，容易購買的流程與產品支援。盡其所能降低成本，盡量標準化，簡化各種控制，加上有精確的中央控制，與能做到整合性高速的管理系統，減低浪費。範例企業是Walmart和Dell。

(2) Product Leadership 優質產品領導

產出最好的產品或服務，專注於產品創新，產品開發，探索新市場的可能性。並盡可能追求未來的創新，領導未來的可能性。範例企業是Apple。

(3) Customer Intimacy 客戶關係

著重客戶關係管理，將執行面交由最靠近客戶的員工，縮短對客戶服務的距離，幾乎永遠以客為尊，願意在一般的產品或服務上，對個別客戶進行客製化最佳化，客戶滿意是最大的核心價值，影響所有流程。範例企業是Ritz Carlton(飯店集團)，IBM。


其他參考：富比世

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

任何軟體專案或產品，達到高品質是開發團隊必然的目標。不過高品質並非垂手可得，它需要團隊的共識和努力才能達成。

確保品質有很多方式。過去常見的方式是瀑布式開發方式(waterfall)中，在程式設計師確定code complete之後，靠QA/QT/QC(註1)來執行測試，並且在測試週期中，驗證是否符合設計規格，並記錄追蹤問題(bug)，有時候甚且扮演催促修復的角色。因而，特別是大型團隊，專門「處理」品質的QA角色十分重要。很多時候，團隊可能面臨沒有QA的狀態，此時要如何確保品質呢？

為什麼會沒有QA

有時候，環境造就沒有QA的局面。例如，新創公司可能也只有5個人，無法有專責QA。又例如，大型企業中因資源分配不均，導致某些專案無法有專責QA。

但更多時候，沒有QA指的是，沒有能做「真正QA工作」的人。也許團隊裡面有許多人持有QA的職稱。但很可能僅做到QC/QT的工作(註1)。實務上，在軟體開發團隊中，實際做的事情其實比職稱來的重要。就品質的角度而言，QA大部分的時間應該花在開發循環「前期」或者「中期」。以Scrum中的Sprint來說，在kick-off時，QA應該花最多時間在定義DOD，決定產出的評斷標準，在sprint每天活動中，QA應該花時間在檢視產生的程式碼(code review)並且透過每個工作產出，主動改善現有品質。換言之，QA應該比單純的程式設計師，更會程式，更知道系統的交互作用細節，並能透過直接或間接修改程式，直接影響開發過程中的品質。因為，開發前中期的品質修正，效果好，成本低，遠比開發「後期」再來幾個測試循環來的有效！

簡要的說，能真正做QA工作的人，必須能比程式設計師團隊更會寫程式。起碼也要是「曾經」非常會寫程式。

如果團隊不巧沒有這樣的人，有三種方式可以在沒有QA的情況下確保軟體開發的品質：

方式一：Scrum

Scrum方法論中，概念上每個Scrum成員都是「同樣質量」。換言之，Scrum進行中重視的是產出，每個SPRINT的結果是「可交付的東西」。而Sprint中間要完成的細項，應該將品質涵蓋入內，而由自行取得該任務的人，完成其保證。

有許多作法和上面這段熬口的說明有關。首先，DOD (definition of done) 除了涵蓋unit-test之外，其實應該也涵蓋整合測試。如果不涵蓋整合測試，就應該另外有一個任務是專做測試。並且，每個story完成中，必定涵蓋這個story應該要有的使用測試(用以檢驗規格)以及回歸測試(用以檢驗是否有副作用)。這些測試，可以單獨成為一個工作，也可以作為DOD的一部分。

無論如何，基本概念是：「人人應該都可以生產程式碼，當然人人應該都可以測試」。實際執行時，或許有些人比較常「拿到」測試工作，但這並不代表這些成員就只是進行測試而已。有些人比較常拿到「寫程式性質」的工作，但並不代表這些人不負責品質。

Scrum的團隊重視每個Sprint的共同結果，此結構也讓沒有QA也能達到高品質。因此Sprint的長度不能太長，太長就會落入「團隊中自行區分QA和Engineer」的後果。

方式二：Pair Programming

Pair Programming是指兩個人一起用一台電腦，一個鍵盤來共同寫程式。這作法在2000年左右發展的Extreme Programming被大大推崇，不過能有決心推動的團隊並不常見。

由於Pair Programming讓每段程式碼至少都會被兩個人看過，而且在頭腦中想過。它可以避免大部分的低級錯誤(拼錯字)，也可以避免懶人錯誤(程式風格，漏寫unit-test)，然而，更重要的是它讓兩個程式設計師的真實想法，在執行同件事情的時候被「好好溝通」。而這更大幅避免對設計或需求的誤解。

Pair Programming似乎有效率和產能上的疑慮，但無論如何，它確實是在沒有QA的情況下，確保開發品質的絕妙方式。強烈建議閱讀一下wiki上的Pair Programming最下面的參考論文。

注意！

前兩個方式雖然符合敏捷開發的精神，並且能從系統結構層面，解決問題。然而，這兩種方式都必須要有結構性的改變，除非是剛剛成立的新團隊，要造成結構性的改變很困難，而且，即便做的好，也得花上其他心血才能有「能見度」，有能見度，才有所謂的功勞。

有兩個古時候的例子：

(a) 鶡冠子扁鵲：扁鵲曰「長兄最善，中兄次之，扁鵲最為下。」魏文侯曰：「可得聞邪？」扁鵲曰：「長兄於病視神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於閭。若扁鵲者，鑱血脈，投毒藥，副肌膚，閒而名出聞於諸侯。」

(b) 孫子兵法：故善戰者之勝也，無智名，無勇功，故其戰勝不忒。

然而，對於一個軟體專案的主管而言，這些結構性的改變才是自己真正的價值。即便價值很難被衡量，但價值會永遠存在自己的手上。

如果短時間難以改變環境，可以考慮以下的方法三：

方式三：Part-time & Automation

工讀生(part-time student)和自動化測試(automation)似乎是兩個不同主題，但就確保軟體開發品質而言，把他們當做「一件事情」來處理，會有驚人的效果。

簡單的說，就是雇用3至4個優秀的工讀生，每週上班2-3天，組成工讀生團隊，執行測試任務，並且在熟練測試任務之後，開始進行測試自動化撰寫，並且在小組長(team leader)帶領下視情況參與更多品質管理的事情。這聽起來是個繁複的事情，但執行起來，遠比方法一二簡單。

其步驟如下：

(a) 選定一位以後想要朝專案經理或主管方向前進的優秀資深工程師，讓他作為工讀生團隊小組長

(b) 到各大學相關科系徵求大四以上的長期工讀生，一般來說，只要能妥善說明對他們未來就業的好處，通常可以找到足夠優秀的人。工讀生至少需要在職6個月以上。

(c) 組成團隊後，第一個月僅只需要熟悉目前軟體系統，第二個月才開始讓他們執行測試計畫，回報並記錄問題

(d) 在此過程中，由小組長指定測試內容和範圍，換言之，這段期間，其實小組長才是扮演QA的角色。而其他成員都可以將繁瑣的測試交給工讀生。然而，程式的品質仍然是所有成員負責，工讀生不在Scrum的範圍內，因此不「負擔責任」。

(e) 當測試進行2個以上SPRINT，工讀生應該已經開始覺得測試是很煩人的事情，但也應該知道品質對產品的重要性。這和在學校做專案計畫有天壤之別。因此，就可以開始由小組長領導工讀生進行測試自動化。

(f) 測試自動化並不期望把所有整合測試/回歸測試，100%統統自動化。只要把「簡單瑣碎」的測試自動化，通常就能節省一半以上的時間

(g) 通常六個月後，3-4人的工讀生團隊就能完成部分整合測試，和大部分的回歸測試。而下一輪的新工讀生，可以選擇從頭開始打造新的測試自動化，也可以接手前期工讀生做到一半的自動化。打造新的自動化通常可以用新的工具，新的角度來測試既存系統，可以讓品質在一次提高。接手前期工讀生的自動化，可以讓自動化範圍更廣，空出時間來做其他的事情


工讀生進行自動化測試的開發，對組織，對小組長，對工讀生有三贏的效果。(參考：實習生的三贏)

組織：讓沒有QA的團隊，能確保高品質的產出。除了要花些微的工讀費用之外，讓團隊成員能把瑣碎的事情下放給優秀的工讀生，使團隊成員能集中心力，但又同時負責個人生產的品質。同時，由於利用工讀生來培養小組長，讓組織能了解這個資深工程師，適不適合作為領導者，萬一不適合，頂多也是犧牲工讀生而已。

小組長：沒有人生下來就會當主管，當主管必須要有經驗，而工讀生團隊是主管最容易讓資深工程師測試自我的地方。因此小組長可透過這獨立運作的團隊，練習各種管理技能。

工讀生：大部分優秀的大四以上學生，都猜得到業界和學界的差異。許多人可能會在暑假應徵summer intern，然而其實短短兩個月，通常會做比較獨立的專案，雖然都很有趣，但是和在學校有很大的不同。加入實際開發團隊，即便只是做測試，也能了解「現實和學校」的差距，並且體會到軟體專案開發時，品質的重要性。讓有此六個月經驗的工讀生，更容易在未來找到更好的工作。

---

註1：關於Quality Control, Quality Test, Quality Assurance, test engineer, SQA的各種工作角色的區分，請參見wiki。然而，誠如前所述，工作角色名字不重要，做出事情才重要。

How to build a self-motivated software developer team

A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 

(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.

Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.

(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.

Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.

Skill sets and performance concerns:

There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.

工作中速度與效率的迷思

孫子兵法：兵聞拙速 未睹巧之久也

媒體大亨Rupert Murdoch：不是大的打敗小的，而是快的打敗慢的

效率以及速度，在職場上的重要性應該眾所皆知。然而，速度並不見得會產生「效率」，當然也就可能沒有「績效產出」。

工作中的速度與效率常見有幾種迷思如下：

速度的相對論

在職場上，速度時常是相對的。

有個笑話最適合描述這樣的相對論：兩個好朋友去非洲野營，在帳篷睡到半夜，聽到有獅子在附近低鳴，似乎打算把這兩人當作食物。其中一人開始穿衣服鞋子，另一人惶恐地問「我們有辦法跑得比獅子快嗎」，已經穿完鞋子正在做熱身操的那位仁兄回答：「我不需要跑得比獅子快，我只要跑得比你快就好」

然而，相對論的確有其迷思與限制。例如，在大型企業中，或許你已經是個主管，相對於其他同事，你也有創意，而且你辦事速度也很都快，看似一切穩當。但是有一天，你所屬的部門被公司老闆出售給外國企業，而該企業也表明只需要技術人才，不需要主管階級時，你才發現原來速度的比較對象，不應該僅僅是在自己的組織之中。(沒錯，這裡說的是HTC最近的賣部門給google的事情)

過程與結果的本末倒置

速度應該是「過程」，而效率和產出，才是「結果」。

把速度當作結果等於是本末倒置。

所以，讓網頁的使用者回應時間，從2.5秒，加速到0.25秒，看似一個有指標性質的結果。但已產出的觀點來看，其實可能是要達到「服務更多使用者」「增加效率」或甚至「減少電費」這些確切結果的「過程」。

工作中單以「速度」作為結果的績效指標，很快就會導致局部最佳化的組織問題。

沒有目標的ASAP

當詢問同事/主管說「請問這件事情應該何時完成」，如果時常聽到ASAP-as soon as possible 越快越好，而沒有具體的解釋，其實是危險的指標。

沒有具體衡量的速度，可能導致幾種錯誤想法：

(1) 這是不計一切代價要越快完成越好的事情，即便犧牲性命也在所不遲，因為一旦完成就會有很美好的事情發生。這樣的想法過於革命性的危險，事實上，僅有極端少的事情是不計一切代價，連生命都可以不要的。

(2) 每個人的時間感受不同。也許CEO的告訴中間主管的ASAP，在當時他的心中是指3個月，而中間主管告訴工程師的ASAP，在他當時的心中是指3個禮拜，可是，工程師的感受可能是5天。最糟的情況是，工程師會誤以為ASAP表示可以犧牲品質，如同上段所述，是可以不計一切代價達到速度。

(3) 有太多事項都是ASAP時，表示根本沒有設定正確的目標以及優先順序。




附註，關於速度突破職場困境，請參考這篇

簡單的路難行 - 人才的激勵與維持

資訊時代前的資本主義中，價值的產生來自三個要素：土地，勞動，資本 - 參見亞當斯密國富論。然而在資訊時代，絕大部分的人都知道，員工(也就是勞動力)，是最最能夠產生價值的地方。換言之，只要找到最厲害的團隊，就可以幫企業做出做適合的產品與服務，並最能產生獲利。

但是，簡單的路難行。

在壹週刊有一篇容易的路最難行中，黎老闆描述了早在40-50年前，即便是一個成衣小工廠，人才仍然是獲利的最高因素。即便付出比別人高3倍的薪資也值得。但是，簡單的路難行，即便全世界都知道簡單的道理，可是執行起來實在太難。

大致有三個原因(特別是在台灣)

大型企業敘薪

台灣大型企業的都有薪資結構，對於已經有工作經驗的人，不太可能提供比過去多25%以上的薪資。就算這個人過去已經證明是難得的人才，也很難以「倍數」成長，頂多是以「百分比」加上激勵獎金成長。

小型新創企業資金不足

這應該很容易理解。和壹週刊黎老闆的文章一樣，小公司為求生存，不得不盡可能壓低薪資（改用夢想股票激勵）。然而，壓低薪資會導致於找到「人力」而非取得「人才」。這變成惡性循環，小公司變得更難獲利。要突破困境，恐怕企業主必須要有決心和毅力維持「難行之路」。請參考黎老闆的這篇。

CP值的誤用

CP值用在買東西是很合理。用在專業人才的工作績效是非常扭曲的作法。例如，兩個很爛的程式設計師，其薪水加起來跟一個好的程式設計師一樣。甚至，做一些簡單的工作也跟優秀的程式設計師差不多。然而，遇到複雜，開創性的工作時，三個臭皮匠很難贏過一個諸葛亮。

解決之道？

如果你是新創公司的企業主。建議看一下黎老闆的「一個創業者的道白」系列文章。非常有啟發性。

如果你是大企業的主管，畢竟已經受組織本身的限制，能做的事情稍微受限，但只要緊記一件事情，一定會有所幫助

激勵方式：主管對於團隊成員的真正最好的激勵方式，是找到讓團隊成員能自己激勵的方式。

(這段話節錄自 Work Happy 一書，作者為Jill Geisler)

如何成為Scrum專家 - 極簡計畫書

Scrum是推進團隊進度，合作專案的敏捷方法論之一。在過去幾年來從資訊產業，金融業，甚至學校教育，都有不少人在倡導這個簡單而且踏實的方式。因為Scrum有很多優勢，例如減低壓力，具有務實的彈性，容易評估現況，易於控制品質。這些優勢，可以用在大部分的企業環境中。因此，成為Scrum專家對職業生涯很有幫助。

學習Scrum並不困難，在各企業巫醫的網路資料中，早就擁有看不完的資料。請參考這篇。

對職業生涯有幫助的不僅是「學會什麼是Scrum」，更重要是成為Scrum專家。或者，至少成為在他人眼中的Scrum專家。專家的定義，請參考註1。

或許你在職場有2-4年的工作經驗，作為一個團隊成員，在專案領導人的帶領下，參與以Scrum為基礎的專案。然而，這不會讓你變成Scrum的專家，因為你只是「照著做」而已。

在此提供一個極簡計畫，可以在很短的時間內讓自己變成Scrum專家。

如果懶得看說明的長篇大論，可直接到這個網頁下載計畫書

開始之前的條件

這份一頁極簡計畫書有使用上的條件：

(a) 必須要有還不錯的英文閱讀能力，TOEIC750以上。如果你的英文能力自認不夠，請參考這裡。

(b) 必須要有2-3年以上的實務工作經驗。而且在工作環境中，至少聽過Agile/Scrum。

(c) 必須打從心裡認為有效使用Scrum是有好處的。換言之，不能是因為「有人叫我要學Scrum」而學Scrum。因為，此極簡計畫書本身執行的方式也是Scrum！


如何成為Scrum專家極簡計畫書的使用步驟如下：

(1) 確認目標的實質意義

此極簡計畫是要在2個月內，讓執行計畫的你變成「Scrum專家」。而何謂Scrum專家的實質意義就是在此極簡計畫中三個sprint的「實質產出」。

Sprint-1 知識：讀完2本Scrum書籍，以及2份網路資料

Sprint-2 證照：取得Scrum證照

Sprint-3 研討會：舉辦公司組織內Scrum研討會或分享會

這三個實質產出的組合意義，目的就會讓你成為Scrum專家。即便不是Scrum大師，至少也是被大部分人承認的專業人士。

這三個Sprint各有已經設定好的任務(Task)，所有任務完成後，就表示該Sprint完成了。而每個任務本身的描述都是有簡單清晰的「完成條件」definition of done。

(2) 分配每個Sprint的時間

計畫書中，每個Sprint各有數個任務，每個任務都有估計的時間。時間是以小時為單位。加總起來，會有要完成Sprint所需要的總時數。

一般軟體專案Scrum估計都可能會有錯，在Sprint過程中，要能實際反映團隊實際的「速率」，因此前1-3個Sprint的燃盡圖很重要，可以讓團隊知道實際的效率。所以每個Sprint都是固定時間，大約4-6週，sprint時間到就結束了，只會看做完哪些Story，在下一個Sprint才調整要完成的story數量。

然而，個人Scrum做法會略有不同。整體概念仍然一樣，但因為Product Owner也是「你自己」，因此Sprint時間可以變動。換言之，可能第一個Sprint是4週，第二個Sprint是5週。

請在極簡計畫書中，每個Sprint任務表格上方，填寫預計的Sprint開始的日期，和結束的日期。Scrum是要反應實際狀況，因此，也許整個sprint需要5小時，但因為你有本來的工作要做，因此可能要花2個月才能有5小時的空閒。

(3) 每日工作

當有超過30分鐘空閒的時候，就可以把那張極簡計畫書拿出來，在這個Sprint選一個任務(Task)開始「執行」，或者，繼續上次未完成的任務。這些Task都是大約設計成30-40分鐘完成，但是根據Scrum的精神，每個人的績效不同，因此也有可能會花的時間多或者少，但無論如何，在還沒完成已經做一半的任務之前，不要換任務！

當然，如果該日沒空，自然就不需要拿出極簡計劃書來執行。

每個任務，都有完成條件，確定滿足完成條件後就可以塗黑空格，並且在右邊簡單的紀錄所花費時間，和大約日期。時間不用太精確，以半小時為單位即可。有些任務很簡單短暫，也許10分鐘就完成，但也以半小時紀錄就好。

如果沒辦法在0.5小時內完成一個任務，那要請自己休息一下，再決定要繼續完成該任務，也可以決定今天就先到此為止。

不能有某任務做到一半，就「先拿了」下一個任務，也不能有這個Sprint還沒完成，就先開始做下個Sprint的某個任務。當然Sprint中的任務，有些是沒有前後關聯，因此Sprint中的任務不需要按順序。只是，一旦開始做，就一定要做完為止。

某些任務需要下載檔案，請參考註2的各個下載網址，可以一次下載完成。

在計畫書中的任務描述都很簡單清楚，但如果真有問題，也歡迎來信詢問

(3) Sprint 結束自我檢討和下個Sprint的開始

完成Sprint中所有任務之後，表示這個Sprint完成。要花15分鐘時間，先自我檢討一下Sprint過程中有哪些阻礙，而自己應該怎麼改善阻礙。

接下來就要開始下一個Sprint。實際上，本來Sprint的開始是需要先討論Story和Task的選擇。然而，極簡計畫書希望你不要花時間在研究這些Task重不重要，而是先努力的花時間搞定它。畢竟這些任務所需要的時間都不多，實務上也對你有莫大的幫助。

不過，或許有些任務你早就已經完成，那就可以看一下完成的條件(DoD)，已經達到就可以自動塗黑。

(4) 計畫書完成？專案結束了嗎？

三個Sprint完成之後，這個極簡計畫書就達到它的功能。但就個人專案的角度來說，專案不見得要結束。只是這時候你已經有足夠的能力和經驗，可以決定要不要繼續以Scrum的方式來學習Scrum。

(5) 3個Sprint結束後的彩蛋！

很簡單，當你完成這個極簡計畫書，實質上你自己完成了一個Personal Scrum。

彩蛋要靠自己完成。請在計畫書背面以三個Sprint的各任務所花的時間，「手工」繪製燃盡圖。

這件事的意義在於，你有確切證據證明你能有效運用Scrum在非工作事項上。也證明你有自我學習的能力。它可以用在未來履歷表，面試，或者說服同事Scrum不如想像中困難，只需要一點點毅力去執行。


在此下載計畫書

常見問題：

Q1：這個極簡計畫書，很多地方跟我在工作上用的Scrum都不一樣啊？

Ans：當然不一樣，因為他屬於Personal Scrum。但是它的最基本精神是一樣的。請參考這裡，了解Scrum哪些最基本精神比較重要。

Q2：我不就是自己的Product Owner？為什麼我一定要用這三個產出來達到「變成Scrum專家」。

Ans：你當然可以自我決定產出和任務，也有機會變成Scrum專家。極簡計畫書，是在如果你還沒有好的定義時，可以透過過去人的經驗，減少時間浪費，讓你專注在精進自己。

Q3：為什麼要取得Scrum認證，這樣就會變成專家嗎？

Ans：有些人可能會以「取得相關證照」，作為專家的標準。這的確是個參考標準，但也只是參考而已，因為Scrum並沒有所謂官方證照，所以市面上各種證照到底哪一個比較適合？請參考這篇「Scrum認證！不要再浪費錢了」。在此採用的是Scrum-Institute的低成本證照。

---

註1：即職場上的專門行業，指具備專業化知識及技能的職業人士。通常，專業技能須符合科學原理，經過長時間的學習及訓練，並有經專業認證的考試獲得的合格證書或執照，擁有自我約束行為的職業操守（或道德）及可量化的專業標準等。...定義細節請參考這裡。


註2：各種需要下載的資料

(a) 任務 1.4 的2個pdf教材
* https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf
* https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

(b) 任務1.7的wiki頁
* https://zh.wikipedia.org/wiki/Scrum

(c) 任務2.1的pdf
* http://www.scrum-institute.org/Scrum_Books_International_Scrum_Institute.php

(d) 任務3.1與任務3.3的材料

* http://www.eduscrum.com/

* https://www.crisp.se/gratis-material-och-guider/scrum-checklist

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

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

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

(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：意志力的研究有很多矛盾的地方，請參考這裡。

快速學習技能 - 解決職場困境

快速學習工作上需要的技能，而技能與知識同時成長，是在職場上能空出時間，進而控制時間的最好方式。

在這世界裡，「在N小時內學會XXX」的書籍研討會不在少數。這些都很有參考價值，然而，學習是非常「個人化」的事情。例如：國高中花很多時間在補習班的學生不在少數，但真能夠發揮補習的目的 - 也就是考上最好的學校 - 卻僅有少數。

有些書籍，宣稱找到共通的方式可以在N小時內，學習「任何」技能。並且當然以自己過去一年學習到的技能，作為鐵 證 (參考文末的註1)。不過，共通的方法都僅能參考，每個人終究都還是需要找到自己的方式 - 只要是真的想學。

在職場工作，會遇到的困境很多，有很大一部分是「人」的問題。但無論哪種問題，如果你是個「技術上的狠角色」，你就有很大的機會撇除人的問題。即使無法排除，擁有更多技能，就表示有更多選擇 - 大不了就是離開現在的環境。

技能的快速學習，首要之務，應該是找到自己的方法。

在還沒找到之前，或者，自己現有的方法似乎有所侷限。倒是可以考慮以低成本的方式，嘗試一下各個企業巫醫所提供的方式。

重點在於：有方法遠比沒方法好！

以下是幾個常見共通步驟與確切花費時間：

(1) 原因與目標確立

不知為何而戰，當然容易半途而廢。

有些原因很清楚，例如：目前會寫java，而現在因為工作需要學習Scala。有些是個人喜好，例如：常喜歡去日本旅行，想學基本對話比較方便。有些則是好奇性質，例如：聽說Big Data大數據分析很紅？不知道到底是那是什麼。有些技術是「執照類型」：例如開怪手，駕駛遊艇。

無論是哪種原因，需要一個簡單的目標，例如：學會Scala，了解Big Data，學會日文會話，學開船等等

不應該花太多時間在目標確立，最多0.5小時。

(2) 階段性成果確立

長期預測是很難，而且接近不可能。因此，快速而踏實的方式是計畫階段性成果。

階段性成果指的是一個「可以衡量的」，「有意義的」，「可展現的」，「務實的」極短期目標。

所謂極短期，是指20小時之內：也就是禮拜一到禮拜五，每天2小時，連續兩週。

這並不是指，超過20小時就是太多，也非20小時就能夠變成專家。而是必須要讓自己在20小時內「有所成果」。

舉一些例子如下：

Scala：撰寫網路爬蟲程式，可針對wiki做特定字串資料檢索和統計。

日文會話：用日文會話辦理飯店check-in，詢問餐廳資訊和找路。

Big Data大數據：選擇並且看完三本大數據的科普書籍。

學開船：考取動力小船執照。


階段性成果的確立，其實和每個人對該技能瞭解程度的不同而有所有不同。了解的越淺，就會訂出越模糊的階段性成果。但其實無妨。因為這只是第一階段的成果而已。

其實，要能確立階段性成果，某種程度已經完成一個小型計畫。計劃本身是死的，「做計劃」這件事情才是重點。這個階段應該花費3-4小時的時間。

(3) 找到練習與取得知識的方式

取得知識和練習的方式非常重要。這方式必須要同時符合「階段性成果」和「目標」。

要快速學習知識和技能，必須「專心花一點時間」得先找確切練習方式，取得知識材料，和額外獲得協助的地方。

取得知識最踏實而且快速的方式，其實還是圖書館。先考慮，或者試用一下圖書館堆書法(參考這裡)。

然而，許多技能是需要練習的。例如：寫程式，學日文，Linux操作等等，就需要找到最適合自己的練習方式。

以學會寫Scala程式而言：即便只是做個簡單的網路爬蟲，仍要再細分小階段，先準備環境，簡單了解語法，知道怎麼使用Scala來執行http get...等等。每個練習的動作，都是為了達到階段目標。

以學日文會話而言：最好而且便宜的方式應該是「馬上去找」語言交換。其次則是去借幾本基本會話的書，再加上幾個app/網站。(註2)

當然，有些技能最簡要的方式，還是花錢受訓，例如「動力小船駕駛」。這反倒是最簡單的，只要有決心即可。

除了花錢受訓之外，這階段恐怕需要額外的時間，預計6小時是合理的。


步驟(1)到(3)，最好是不要花超過8小時，也就是一個假日的時間。

(4) 練習與取得知識

這一階段的重點在於「專注」。如果計畫是兩個星期，共計20小時，則這時候，就該專注於自己決定的方式，無論如何，都要在兩星期/20小時之後來檢視成果。

這也是為什麼，設定階段性成果時間不能太長(註3)。

如果的目標過於抽象，例如要「瞭解什麼是Big Data」，在這段練習與取得知識的過程，就會變得更加含糊不清。以因此，階段性目標才會設定成「看完三本科普書籍」，這樣才能檢視成果。

要讓自己專注的方式有很多：短時間專注可用番茄工作法。長時間則需要計畫與經驗，而目前你在看的這篇文章，實務上就是在解釋，如何將學習技能知識時間專注於學習。

在這個階段，根據計畫的不同有不同的時間。但是切記「越短越好」。如果不確定時間長短，那就以10個小時，每天2小時為準。

(5) 自我評量

必須要有客觀方式自我評量。

因為是自我評量，當然一定要確實。

以學習Scale的第一階段：完成網路爬蟲為例，如果在20小時內完成，那麼就可以有信心的說學習Scale已經前進很多。

以學習日文會話來說：如果可以和日本人測試對談飯店用語，那就表示階段性成功。

再次強調：快速學習技能的階段性成果，必須要以務實為主。許多人在學日文一開始是以背熟50音為第一階段。但這其實不太務實。因為死背永遠是無聊的，而且即便你可以把50因背得滾瓜爛熟，在日文能力 - 特別是會話 - 的務實進展也等於零。

(6) 收成：前進或者換目標

達到目標後，請隨意犒賞自己。

而接下來，就是要決定往下一個階段前進，或者更換目標。

這時候的更換目標，並不是半途而廢，畢竟你已經前進了一段務實的路。這和達不到目的而放棄，無論在心態上，還是事實上都有很大的不同。

往前進的時候，記得也是重複設定一個「短期可達到」的務實目標。

例如：

學習scala，已經完成網路爬蟲程式，接下來的目標是在Spark中，以scala撰寫一個可分析http log的分散式程式。

瞭解Big Data大數據：已經看了三本書，接下來的目標是找一個有意義的主題，寫一篇部落格文章。

這樣的快速學習，真的能解決困境嗎？

快速學習能讓你在職場上，取得更多的「選擇性」，讓你對事物有所掌控。這才是針對困境的真正解決之道。

或者也可以跟我們聯繫取得困境的快速協助。

---

註1: 有幾個例子

   * Fluent in 3 Months: 三個月內可以流利的學會任何語言。作者甚至示範了中文學習，對外國人來說，學非拼音文字真的難為了他們。

   * The First 20 Hours: How to Learn Anything FAST. 作者示範了如何快速學會各類不一樣的技能：瑜伽，寫程式，風帆板，圍棋...但個人覺得比較難以置信的還是「新鍵盤佈置：colemak 」

   * The 4-hours 系列：作者Tim Ferriss寫的幾本書。內容從健身到創業都有，其中都會涵蓋快速學習的方式。

註2: 請參考Fluent in 3 Months 一書

註3: 當然如果你是想考動力小船執照，由於上課時間是固定，當然沒辦法「更快」。