顯示具有 提高工作效率 標籤的文章。 顯示所有文章
顯示具有 提高工作效率 標籤的文章。 顯示所有文章

9/04/2019

如何提昇士氣激勵團隊成員 - part2 - 三件一定要做的事 (成為主管的31堂課)


激勵團隊成員士氣,是在軟體開發團隊中,最好的提高績效與成果的方式。這又是一個所有人都知道,但是很難真正做到的事情。想要作為一個好主管,應該要有某幾種可激勵人的行動。

有幾件用處不大,做了不會有傷害,多少會花點時間,如果有其他人的協助當然可以執行,但是不建議主管花太多時間在這類事務上:

* Team Building:找個空擋帶著團隊成員出遊
* 零食飲料:在辦公室塞滿各類型零食飲料
* 生日卡片,慶生會等等

真正有用的事情,恐怕都要花點時間,有幾件事情的做法可供參考如下:


一:透過聆聽了解團隊成員的需求


在1vs1的時候,放下心中成見,專注於聆聽團隊成員的真正心聲與需要。每個人會工作有必然真正的原因驅使並激勵這個人。

困難點在於每個人的激勵因素都不同,一般認為,軟體工程師會持續激勵有高績效產出「可能是」因為:

(a) 完成程式執行順利時候有種滿足感
(b) 自己也能夠學習成長
(c) 團隊溝通順暢協作愉快
(d) 強烈認同組織目標
(e) 對團隊有影響力 能夠被人認可
(f)  ....其他...(家庭之類)

以上雖然都有是原因,但是每個人真正的「激勵因素」卻差距很大。需要靠one-on-one時,盡量耐心聆聽出每個人真正背後原因

絕大部分的情況下,軟體工程師不會真正為「錢」而工作,當然千萬不要因為這樣就降低薪資,錢是屬於保健因子,沒有足夠在人才市場競爭力的薪資,是絕對無法找到能力好的工程師。但是,工程師會留下來持續高績效的產出大部分也不是因為錢。

二:根據需要,量身訂做能做的事情,滿足真正的需要

聽起來好像是廢話,但是每個人的需要會讓主管該量身定做的事情差異很大。而且執行起來極端困難 -- 不過本來作為主管就是困難的事情。

為團隊成員量身定能做的事情,不見得很花時間。舉例來說,如果成員A今年才剛畢業,那他可能想要的是獲得工作上的成長跟成就,能跟著團隊好好做完整事情比較重要。因此幫他建立「該做完的事情清單」,並且「幫他了解該事情的意義」對他會很有幫助。
而假如成員B已經工作十年,在這個組織沒換過工作,加薪幅度不錯,有時候做得很好,但有時候差強人意。這時候應該跟B的好好談談的未來工作的可能性。透過一些方法,幫他了解他自己在市場上的價值,例如鼓勵他去其他公司面試,這並不是要他離職,而是透過取得其他工作機會,了解自己在市場真正的價值。
這點有空會再說明一些實質作法。既然是量身定做,每個人情況都有所不同,如果你管理的團隊不確定該如何進行,也可以email與我討論: consultant.3rd@gmail.com

三:透過直接了當的方式,表達重視團隊成員


絕大部分的人都是「被需要的」。在許多時候,主管多少會忽略「現在做的很好」的團隊成員,將心思放在做的不是很好的人身上,這其實無可厚非,畢竟,現在做的好的人,雖然通常表示思慮成熟,做事完整,並且也能自我學習。然而,這並不代表這樣的人知道主管「其實很重視他」,尤其是高績效的人常常也是獵人頭無時不刻的挖角對象。

直接了當在one-on-one的時候,對現在績效高的人講這句話:『你對我來說非常重要,我們團隊是真的需要你,我也很需要你的繼續協助』必要的時候可以在one-on-one開頭,中間,結尾都講一次。



9/01/2019

極端簡單解決問題的技術:check-list (成為主管的31堂課)


軟體研發主管應該要能順手使用許多解決事情的技術,例如甘特圖,流程圖,心智圖,時間序列圖等等。然而有時候,簡單的check-list 檢核清單能夠快速統一想法,解決問題,特別是在情況複雜紊亂,但又需要統一某種結果的時候。


案例:S公司擁有橫跨數個國家的雲端營運團隊(devops),但就如同許多創新公司一樣,營運團隊一開始並沒有統一的流程,許多devops會自行發布想發布的服務,造成其他人的困擾。更有甚者,在預期有大流量的時候,常常忽略許多小細節沒有處理,然而又常常有很多人在做同一件事情。



檢核清單check-list的概念很簡單,跟SOP有點類似,就是列出一串要有的事情,當有的時候就打勾。最簡單常見的例子就是旅行攜帶物品清單,如下:

[ ] 護照
[ ] 美金
[ ] 變壓器
[ ] 盥洗用具
[ ] 雨傘

你大概會覺得簡單到不行的東西有什麼好說得?在快速成長的團隊中,有許多工程師都想要以「自動化」的CICD以及系統監控來解決問題,這當然是合情合理,但是在完成之前呢?很多事情是需要「時間」來完成,在能夠自動化之前,人工仍然避免不了。更有甚者,許多事情可以自動化,但是決定的方式卻無法自動化。

以該案例的情況來說,預期有大流量的活動時,可以在前幾蔫由主管決定一個清單,例如googlesheet 或其他文件知會所有相關人,例如:

[  ] 在N月O日P時,所有人停止部署服務 
[  ] 在N月O日Q時,A負責檢查可承受的流量
[  ] 在N月O日R時,A與B討論並決定要額外擴增多少服務
[  ] 在大流量活動日的 D時起到E時止, C負責監控系統流量,
[  ] 在大流量活動日的 D時起到E時止, A/B/K 各負責某某系統的服務正常性檢查
....

這個清單可以很長,但是清楚揭示所有人在大流量時應要負責的工作,送出之後即便有問題,也可以就事實來討論。以軟體團隊而言,check-list必然包含三件事情 (1) 直接負責人,通常只能是一個人名 (2) 時間:預計完成時間 (3)產生的結果:衡量這件事情如何被完成。



8/29/2019

節省招募時間 - 電話面試的技巧 (成為主管的31堂課)


在軟體「人才」的招募上,通常會花上比預期還要多時間,人才難尋是軟體產業其中最困難的問題。自招募流程上,各種審慎的過程當然不能省略,例如技術評估,面談等等。然而,整個過程可以透過各種方式,提前篩選適任或者不適任的人。其中,電話面試在台灣是最被忽視的一項。大概也是因為台灣交通十分方便,特別是大台北地區,面試者一般都不會因為「太遠」而放棄,但交通因素並不是電話面試最大的好處,電話面試最大的好處是可以低成本有效地去除偏誤,有效增加後續篩檢的正確率,並節省時間。


案例:在某次研討會中,軟體研發團隊主管K說,我從來不做電話面試,因為我想要看到應徵者的臉孔跟肢體反應,這樣我比較容易判斷個性。


電話面試有幾個好處:
(1) 去除偏誤:尤其是對外表的偏誤。已經有太多研究證實,沒有人能夠避免對外表的偏見,只是多或者少而已。也因此許多研究指出,履歷表不放照片才是最好的方法。當然也有人持反對意見,不過整體來說,雖然遲早會見到本人,但電話面試的確可以去除主管對外表的偏誤。案例中的主管K試圖去判斷個性,但容易流於自我偏誤。

(2) 節省彼此時間:一般面談起碼也要花2個小時,而電話面試至少可以先過濾掉10~15%的明顯不適合的應徵者。許多資深的軟體職位起碼要收20個履歷表才能找到1個人。換言之,電話面試,在表面上起碼可以少讓2個人來辦公室,但其實背後意義不僅於此,操作得當可以讓另外18個人對你的組織更有興趣更能在面試中努力表現,而非因為獵人頭介紹隨便來試看看。

(3) 其他:其實還有很多好處,例如再度驗證履歷表的真實性等等。

電話面試的技巧:

一:結構性問答而非開放性討論


電話面試必須要「固定詢問有意義的結構性問題」,而不是開放性討論。透過結構性問題收集了解事實。

結構性問題例如:
* 你為何想要離開現在的公司
* 是從什麼管道知道我們有在找軟體開發人才
* 你最近一次跟主管起衝突的時候,當時你做了什麼
* 最近三個月,你學了什麼新的資訊技術是跟工作無關的
* 你最近一次code review是什麼時候

這些問題回答不要評論好壞,只是記錄最為後續判斷。

不要問開放性的問題,除非你要找的是很會唬爛的人,開放性的問題通常都是假設性的問題,例如:

* 如果你跟老闆吵架了你會怎麼做
* 要是你加入一個有大流量的公司,你要怎麼做分散式系統設計

二:基本的事實查核


事實查核比想像中重要,倒不是因為履歷表造假的問題,而是在看履歷表的時候可能會有自已的假設,這些假設可能會有認知偏誤。

簡單的事實查核問題
* 請問你想要離開現在公司的原因
* 請問你當初加入這個公司的原因
* 在2013/3~2014/10年這段期間,你履歷表中似乎沒有在任何地方就業,請問是什麼原因呢
* 您在2012年某公司A的離職原因是什麼

進階的事實查核
* 在履歷表中,您有描述溝通是你的強項,請舉一個最近一次你解決非常困難溝通狀況的例子好嗎?
* 您剛才說在某公司A的離職原因是公司內部高層政治鬥爭很嚴重,可以舉一個政治鬥爭的然後影響到你的工作的實例嗎?

三:回答面試者對公司以及團隊所有問題


優秀的人才鐵定會想要再加入一個團隊時,了解一些事情。讓面試者詢問問題,不對問題做衍生性的回答,也不做假設,只是誠懇地回答問題。並且在最後再詢問「請問你還有任何想要了解的問題嗎?任何問題都可以現在詢問」

當面試者問了廣泛性的問題,請必定要他縮小範圍。否則,廣泛地回答對他也沒有好處。舉例來說:常遇到面試者問「呃 ...我很重視軟體工程文化,請問一下貴公司的文化是怎樣」這種問題太過空洞,可以直接告訴面試者「我們也很重視工程文化,但你的問題太過籠統廣泛,這樣我也會回答的籠統廣泛對你也不好,可否你縮小問題範圍,或者問實際的某件事情,透過實際上事情你就可以判對我們的文化對你來說好還是不好」。如果是容易溝通優秀的人才,很快能了解,因而他們就會問類似這樣的問題:「喔 我了解,那我想問,請問你會進行code review嗎」這樣彼此就可以針對事實討論。

更重要是這樣的事實討論,可以讓他了解優秀主管通常是實事求是,而主管也可以了解他能不能馬上抓到重點。



藉由這三個項目,一個好的主管可以初步篩檢適合或者不適合的人。另外一個值得一提的是:電話面試中間盡可能不要提早判斷面試者適不適合,盡可能是電話之後才根據筆記來判斷是否要邀請來面試。

11/16/2017

軟體專案管理 - 版本控制系統內的程式碼基本分析


孫子兵法:夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!

任何軟體開發專案的基礎都是「程式碼」。即使,專案經理不需要親身撰寫程式碼,但是必然要能夠透過程式碼,取得專案關鍵資訊,作為專案領導管理的最佳參考。(關於專案進度,請參見這篇。)

版本控制系統(git, cvs, p4, svn等等),則是有效控制程式碼的基礎,開發過程大部分的事情會發生在這裡,也應該發生在這裡。

如果你的軟體開發專案,沒有使用版本控制系統!!??...呃....請參考註1。

版本控制系統「至少」可以提供以下這些重要而且基本的訊息給專案管理者:

(1) 截至目前為止,有多少人實質參與專案
(2) 截至目前為止,專案的實質規模(程式碼檔案數量 行數等等)
(3) 一段時間內,此專案程式碼品質的推測
(4) 一段時間內,例如過去48小時,軟體團隊的實質產出
(5) 一段時間內,例如過去7天,有沒有人在非上班時間內工作


專案管理者(或者Scrum Master)應該自己取得這些訊息。為什麼??



"Доверяй, но проверяй
 - 俄羅斯名言,意思是 Trust, but verify  

冷戰期間美國總統雷根特別愛用此名言,根據wiki說明,雷根是受到一個作家的影響






因為,過去專案管理者常見兩種極端:

(1) 極端放任自由:在Scrum的精神下,雖然每天站立會議和燃燼圖,都可以揭露專案最確切的進展,完全相信成員的口頭回報
(2) 極端間接的繁複審閱:在沒有技術背景的情況下,透過頻繁而起瑣碎的會議,加上各式各樣文件追蹤,試圖了解目前進展。

這兩者都有明顯的問題,Trust, but verify才是正確做法。以Scrum的精神取得每日進展,並且,專案管理者應該「自己」想辦法檢查。專案管理者,如果沒辦法自己檢查,表示對此專案的本職學能不足。(註2)


專案管理者能夠做的程式碼基本分析有很多。好的專案管理者,至少需要能自己「動手」,利用工具或者程式,透過事實,了解下面三件事情:

(a) 基本專案狀態分析:哪些人寫了哪些程式碼
(b) 哪些程式碼檔案很重要:某些程式碼就是常有問題
(c) 哪些人需要額外關注:某些人工作壓力大常加班

以下以git為例,其他版本控制系統也能做到類似的事情。


基本專案狀態分析


靜態程式碼分析工具有很多。例如,gitinspector可以揭露整個專案的大致情況。gitinspector的安裝使用請參考這裡
以github上的serverless.com為例,在github上clone這個專案,並且執行#gitinspector的結果如下:


首先會大致列出作者和過去的產出摘要,例如Aaron在這個專案一共commit了8次,包含170行程式碼跟刪除87行。這個表當然不能作為績效考核用途,但是可作為參與度的重要參考。很明顯的Austen鐵定比Chris的參與度高很多。




接下來隨即會列出還存在的程式碼行數。以Austen來說,他還有2713行的程式碼存在。和他的總新增行數與刪除行數有很大的差別。這很有可能是他參與了開發初期,而開發後期的版本沒參與。




哪些程式可能容易有問題?

程式設計師每天辛勤的工作,自然會知道哪些程式常出問題。而專案管理者必須要由技術面來獲取正確的資訊。版本控制系統會記錄每次程式修改的原因(如果commit的備註正確的話)。最簡單列出「要注意的哪些程式碼檔案」

git log指令,可以加上 --grep=<string> 來濾出字串,以下例子只用fix當作過濾條件,並且配合linux其他指令:sort, uniq 就做出簡單的報表:


~/serverless# git --no-pager log --name-only \
--grep=fix  --pretty="%s" | sort | uniq -c | sort -n
     19 lib/ServerlessState.js
     19 tests/tests/actions/ResourcesDeploy.js
     20 lib/ServerlessProject.js
     23 lib/actions/EndpointDeploy.js
     23 lib/actions/ProjectInit.js
     23 lib/actions/RegionCreate.js
     23 lib/SerializerFileSystem.js
     24 lib/Serverless.js
     25 lib/actions/ResourcesDeploy.js
     25 lib/actions/StageCreate.js
     25 tests/test_utils.js
     27 package.json
     27 README.md
     28 lib/actions/FunctionRun.js
     34 lib/actions/FunctionDeploy.js
     38 lib/actions/FunctionCreate.js
     55 lib/utils/index.js
    101 tests/all.js

當然,以上報表只是列出有fix字串的commit中,哪些檔案出現次數最多。 tests/all.js 明顯是最多的,但也很明顯這檔案本來就是會被一直修改。此外,README.md也是一樣,大概也不是真正有問題。不過其餘的檔案倒是可以額外關注一下。

程式有問題的的判斷方式有很多,除了在commit的紀錄中說明是[fix]或[bug fix]之類。但也可以考慮總行數,刪除的行數,增加的行數,並且配合QA/bug tracking系統,才較為完整。


哪些人需要額外關注?


「人的問題」,永遠是最難解決的問題。然而,卻也是要優先解決的問題。組織中必然有需要「被關心」的人。

專案組織中,最要被關心的人是「表現好且有潛在壓力大」,以及「表現不好且對團隊有負面影響」這兩種。其中,表現好的人更是要優先處理。

除了每天例行工作接觸之外,專案管理者應該要有確切的「數字」。假設,我們想知道在此專案中,哪些人常常「晚上」工作。最簡單的方式是分兩步驟,先用git列出作者時間,然在寫個簡單的統計程式,列出所有人的「晚上」工作時間和「平常」工作時間次數。

* 步驟一:先取得所有的branch, 然後, 以下git log指令可以列出作者和時間,並且輸出到檔案author_time_log

 

# for BRANCH in $(git branch -a | grep remotes | grep -v HEAD | grep -v master); do git checkout --track "${BRANCH}"; done
# git --no-pager log --all --pretty="%an,%ai" > author_time_log


檔案內容大概如下
....
Austen Collins,2015-08-05 18:28:18 -0700
Austen Collins,2015-08-05 17:26:26 -0700
ryanp,2015-08-05 17:04:37 -0500
Derek van Vliet,2015-08-05 09:31:56 -0400
Michael Friis,2015-08-04 18:54:03 -0700
Austen Collins,2015-08-04 15:04:46 -0700
Colin Ramsay,2015-08-04 22:03:48 +0100
Chas Warner,2015-08-04 14:53:59 -0600
Austen Collins,2015-08-04 11:19:31 -0700
Austen Collins,2015-08-04 11:15:44 -0700
Austen Collins,2015-08-04 11:11:06 -0700
Austen Collins,2015-08-04 11:09:24 -0700
....


* 步驟二:撰寫簡單的分析程式,設定正常時間是早上7點到晚上8點,其餘都算不正常時間。用人名為單位加總之後,就可以產出簡單的報表。簡單的統計程式原始碼請參考這裡

此表中,Eslam幾乎有一半的commit都是在晚上產生,而Kamil則是標準完全正常時間工作。

Joe Turgeon [1, 0]
Erik Erikson [15, 7]
Ian Serlin [1, 0]
David Hérault [1, 0]
Peyton Zhou [2, 0]
Kazato Sugimoto [2, 0]
Nick den Engelsman [1, 0]
Kiryl Yermakou [0, 1]
Austen Collins [575, 267]
Kamil Burzynski [101, 0]
Frank Schmid [9, 2]
Jacob Evans [13, 1]
Michael McManus [1, 0]
Eslam A. Hefnawy [158, 132]
Dave Newman [0, 1]
Ryan S. Brown [35, 6]
doapp-ryanp [129, 48]
Michael Friis [1, 0]
Matthew Chase Whittemore [2, 0]


當然這並不代表Eslam的表現好而且壓力大,這只是提供給管理者參考的事實。專案管理者,必須要事實層面,檢查軟體專案的狀況,因為很多時候「會吵的小孩有糖吃」,只單純被煩就會給糖的專案主管,其實對團隊是沒有價值的。


小心統計陷阱

統計數字都可能會有陷阱,程式碼的基本分析也是統計的一種,自然要小心陷阱的存在。專案管理者應該要善用統計數字,切勿被統計數字所左右。請參考統計與謠言


 


註1:軟體開發專案不使用版本控制系統,會讓專案本身暴露在極端的風險中。如果你是專案管理者,讓專案暴露在風險中就是你的責任。如果你只是個開發人員,儘早離開高風險的環境才是上策。

註2:某種情況是,專案規模過於龐大,例如參與開發者超過100人,某些技術確實不見得能完全掌握,但專案管理者,仍然要保有部分自行檢查的能力。




10/17/2017

工作中速度與效率的迷思




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

媒體大亨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時,表示根本沒有設定正確的目標以及優先順序。




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

8/19/2017

如何成為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


8/17/2017

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



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

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

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




8/14/2017

工作3年後 - 如何主動換個好工作

工作3年後 - 如何主動換個好工作

畢業開始工作2到3年後,是個轉捩點。許多專業工作者(例如工程師)都在剛畢業後2-3年就會主動考慮換工作。

要隨便換個工作不難,但是要換個「好工作」其實非常非常難。

最踏實的作法是對「換好工作」這件事情有具體的目標和可行的作法。雖然這和每個人的職業和背景的不同,而有差距,不過計畫的步驟其實差不多。

想要跳過說明,可在此取得「TS 換個好工作 計劃表」。

有很多原因,會讓工作2-3年的人想主動換工作(註1),以下是幾個常見原因:

(一) 未來發展:覺得現在組織沒辦法讓自己升遷,增加責任範圍,學不到技術等等。

(二) 生活品質:薪水不夠,加薪幅度不夠,工作時間過長等等。

(三) 組織狀況:大組織內政治因素過大,小公司極端不穩定,產業外移等等。

(四) 興趣:現在工作內容沒有興趣,感到厭倦無聊,或者發掘自己的興趣在一個截然不同的產業等等。

(五) 想創業:這不在本文討論範圍之內。(註2)


除了以上原因之外,「最爛情況」也可能是換工作的原因。所謂最爛的情況,是指「非理性行為」:年輕人畢竟容易血氣方剛,容易產生各種憤怒:「對微妙小事看不順眼而憤怒」,「因為覺得老闆好爛而憤怒」「覺得不被重視而憤怒」,甚至,「我的老闆沒被大老闆重視」也可能是原因。

但其實,企業組織只要沒有違反法律,這些爛原因,絕大多數都是無聊而且不必要的。因此也不在討論的範圍之內(註3)


要找工作很容易,要找到好工作很難

再次強調,換工作很簡單,但是要換到好工作很難。對於困難的事情必須要有計畫的完成它。

計畫如下:


(1) 了解自我原因


了解自己為什麼想主動換工作的原因,是最基本,但是卻最容易被自我扭曲誤解的第一步。

有個簡單的方式可以讓自己對自己「誠實一點」:將自己為什麼要換工作的三個最主要原因,依優先順序寫下來。根據80/20法則,第一個原因約佔80%,第二個原因是16%,第三個原因最多是4%。舉例如下:

80%:因為學不到新技術
16%:因為加薪幅度不到10%
4%:覺得厭倦無聊

先把80%的原因遮起來,模擬假設解決了80%的原因,只剩下另外兩個原因,還很想主動換工作嗎?如果不太想換了,才表示你誠實的面對了自己。如果還很想換,就表示那80%的原因根本不是主要原因,請換個主要原因再試一次。這步驟是要迫使自己誠實面對自己,了解自己真正想換工作的原因。當然,想要換工作的原因可能更複雜,但一定要先認知問題的存在。

因為「解決問題的第一步是認知問題的存在」。而如果不先了解自己真正想換工作的原因,那就很難了解自己認為「好工作」的定義。

當然在這個時候,很有可能會覺得不想換工作,或者想創業為自己工作,那也很好,重點在於找到自己心裡真正的原因。


(2) 足夠計劃實施時間


在台灣,知識類型的工作者,最好要有3到5個月的準備時間。以下的計畫就是以3個月的準備時間為準。

3個月看起來是個冗長的時間,但如果你只有2-3年工作經驗,只準備了3個月就換到適合自己的好工作,其實是極端快速的。要達到極端快速,需要妥善計劃。

如同精實創業和敏捷開發的「時間控制」原則,這3-5個月時間是固定的,如果期限內沒達到效果,應該重新檢討,重頭開始。


(3) 定義目標


當準備換工作,目標必須是要換個好工作。而定義「好工作」就顯得很重要。每個人的好工作定義都不同,但該目標必須要「解決當初最重要的換工作原因」。

目標的需求描述,可以是4至8個項目。描述的內容要和換工作的三大原因有所關連,但不見得要一比一對應。也可以加入額外條件,像是地點之類。最後,描述的目標一定要有幾個「參考公司名稱」,因為畢竟換工作,最終還是換到某個公司,目標公司並非表示你非他不可,而是有個顯著的參考值。

例如:

 * 要學到比較完整的軟體開發流程
 * 透過轉職加薪,要比現在多15%
 * 工作內容聽起來要有趣
 * 工作地點在大台北地區
 * 加班頻率不高
 * 有國外出差的機會
 * 目標公司:四零四科技,趨勢科技,LINE台灣


(4) 瞭解與目標的距離


了解與目標的差距,最簡單的做法就是「馬上去面試一次看看」。但這樣做是有點風險,因為許多外商,通常在拒絕應徵者之後,可能3-6個月都不太會讓這個應徵者再來面試一次。

其次,花半天的時間,上網搜尋相關資料,特別是在104, linkedin上的公開資訊。可以看出這些公司最近需要的人才的技術能力為何。通常比較大公司很容易找得到「面試經驗談」可作為參考:要記得只是參考而已。

另外,也可以透過linkedin找到該公司的HR或者主管,虛心請教哪些技術能力及程度,是必備條件。有兩點要稍微注意的是:(I) 目標應該放在知識與技術能力,暫時先不要考慮「軟技能」像是人際關係之類的。(II) 英語能力是屬於技術能力的一種,並非軟技能

列出此時此刻,自己和目標最大的3-5項差距:

 * 對比較嚴謹的開發流程沒經驗
 * 對Linux不熟悉
 * 英文溝通能力不太好
 * 線上程式測驗比較難 
 * 沒有大數據相關工作經驗


注意!如果在這個階段,你認為沒有差距了,就勇敢地去面試。一旦被綠取,那麼你也已經達到計畫的目的。然而,要是沒被錄取,就表示「實際上」的確有差距,必須要回憶面試過程,找到其中差距,然後用下一段(5)行動,來補足差距。


Action speaks louder than words


(5) 行動


計畫最重要的部分就是行動,沒有行動的計畫是死的。不過,好計畫也是行動的關鍵。不知道怎麼行動比較好?可在此免費取得通用版本的「TS 換個好工作 計劃表」作為參考。

換個好工作的主要行動有五項:

(A) 急速提升目前工作績效


快速且大幅提升目前工作的產出效率和在組織內評價,是縮短與好工作距離的「最佳做法」。絕大部分的用人主管與人資主管,判斷應徵者的未來潛力,是透過他「過去工作績效」。

換言之,要換個好工作,關鍵成功因素是把現在的工作做到最好!而且是「以別人的角度」認為你做得最好,而非從自己的角度。

實際做法是:

首先,列出三項在1-2個月內可以達到的「額外」工作目標。並確定達到之後,現在的主管「鐵定」會非常滿意。可以主動和現在主管確認,這些額外的目標確實有很大意義。當然在這個時刻,不需要跟他說你有換工作的打算。

接下來,用盡「所有能力」,去達成這些目標。所有能力包含以下各種可能:

 * 厚著臉皮請教同事應該怎麼做比較快
 * 快速學習新技能以達成目標 (參考下一段)
 * 在做的過程中虛心向老闆求教
 * 每天提早40分鐘抵達辦公室做這三項額外目標
 * 用80/20法則,找到目標的關鍵任務先行完成

絕大部分的人,無論是什麼樣的工作,都能透過這個方式,在1-2個月內,展示出「大幅提升績效」的結果。並且是會獲得「外界肯定」,而非自我感覺良好,自覺大幅提升。


(B) 急速學習技能 


在瞭解與目標差距中,已經列出數個技術差距,而每個技術差距,都應該可以用學習技能來補足。

快速學習的本身,也有一定技術可依循,請參考這篇:快速學習解決職場困境

每個技術差距該做的事情都不一樣。不管列出幾項差距,最好是「一項一項」逐一解決,盡可能不要同時解決。考慮現實,3-5個月最多也只能增加3個技能。而每個要解決的技能,必須有極為明確的目標。這也是極速學習的關鍵:清楚定義目標,在大目標下逐一達成每個小目標。例如:

 * 對Linux不熟悉:熟悉LPI-201, LPI-202,通過線上測驗
 * 英文溝通能力不太好:考TOEIC目標成績850
 * 線上程式測驗比較難:每天花10分鐘,到Leetcode或topcoder上找中難度的題目練習



(C) 急速打造通路


通路(Channel)是在商務上,將產品送至客戶面前的方式。

對於知識工作者來說,「你自己」就是產品。而企業組織,就是客戶,企業組織雇用員工也是一個「市場」,而市場,常常是被通路所控制。既然你是產品,就應該要妥善處理你的通路,而非讓客戶來決定通路。

最基本的通路,可能也是最差的,是所謂求職網站104, 1111之類,當然,有3年工作經驗,也可以用求職網站。但它恐怕不是最好的方式。

另一種通路是linkedin,和求職網站稍有不同,linkedin需要更大的主動性去維護 履歷表。

再者是獵人頭公司(headhunter),大部分的情況下,獵人頭公司對3年工作經驗者不會有興趣,當你只有三年工作經驗,獵人頭可能只會對你的聯絡方式有興趣,等你「長大一點」再跟你聯繫還不遲。然而,有些做法可以讓獵人頭提早對你有興趣。其中一個做法就是透過業界導師推薦。

最佳的通路是「內部推薦」。如果剛好有認識的同學朋友在該公司內部,那你的運氣就實在太好。但是如果沒有任何認識的人?創造認識的人就是最好的方式。

如何創造認識的人?透過linkedin或者其他社群網站了解內部員工都參加哪些活動,或者研討會。主動參加那些活動和研討會,就會自動認識內部的人。稍微熟悉一點之後,就可以厚著臉皮懇求幫忙送履歷表。幫忙送履歷通常不是問題,問題在於「是否真心推薦」才是重點。技術類型的工作,參與相關的研討會,參與比賽,參與開源開發專案等等,絕對是能獲得真心推薦的方式。


(D) 應徵/面試


當準備到一個程度的時候,就應該去應徵面試。何謂「到一個程度」,只要你按照原定計畫,2-3的月就一定會到某個程度。你就應該「驗收」努力的成果,而非覺得「不夠完美」所以想持續學習。

不夠完美是一定的,因為人不可能完美。持續學習也是一定的,因為學無止盡,但時間是會流失的,這也是為什麼一開始需要鎖定一段時間,無論好與壞,每一段時間一定要能驗收檢討成果。

應徵和面試的技巧,網路上各企業巫醫專家實在太多,就在此省略。


(E) 檢查是否朝向目標


要給自己固定一小段時間,檢查自己所作所為是否朝著計畫前進。最好是定在每週一上午9:00~9:15 (這時間有特殊意義存在,盡量不要改變它) 

要檢查三件事情:

 * 過去一週的行動,有沒有確實提升工作績效
 * 過去一週的行動,有沒有縮短與目標距離
 * 有沒有浪費時間在其他地方

(6) 最終結果與選擇


如果在時間內,確實被錄取「目標好工作」。那麼就應該作出選擇,決定要不要去。因為也許3個月後,由於你的工作績效大幅提升,原本一定要換工作的原因已經不存在,當然就可以選擇要不要換。

如果在時間內,並沒有被錄取「目標好工作」。那麼就應該從第一步開始,檢討哪邊出了問題。並且重新再做一次3個月計畫,然後,確實再實施計畫。即便第一次計畫失敗,也會讓下一次計劃成功。

*******

每個人都有適合自己的方式。但如果你沒有好方式來換個更好的工作,參考並實行這個計畫一定能獲得好結果。


*******



註1:也有一些種情況是被動或者被迫換工作。 最糟糕的情況是因為績效不佳而遭到資遣,其他情況像是:公司倒閉,公司裁員,組織重整,健康因素,家庭因素等等。被動換工作的通常是「措手不及」的,因此要採取略微不同的方式。請參考這裡。

註2:工作了2-3年,應該可以知道,創業和換工作截然不同。創業的成功關鍵請參考這裡

註3:不過,人類有各種認知偏誤,合理化既定決定,無論決定合不合理,都有可能被自己合理化。


8/07/2017

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


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

在這世界裡,「在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: 當然如果你是想考動力小船執照,由於上課時間是固定,當然沒辦法「更快」。

3/31/2017

企業巫醫 - 向上管理的實務作為?



向上管理是個歷久不衰的名詞,它和「人格特質分析」「領導與管理」等名詞雷同,每隔一小段時間就會以各種形式,出現在企業巫醫們的討論中。

近期隨意查詢就可以找到不少相關文章: 向上管理(cheers雜誌),如何讓老闆聽我的反對老闆的六種方式向上管理的四步驟 ......

「向上管理」向來是一個譁眾取寵的話題,眾多企業巫醫仍然以泛泛之談,試圖教導並解決一個現實而又務實的問題。

企業巫醫,總是能選定看似重要的無法辯駁,共通的話題,而且此類話題完全視個人情況而有截然不同的作為。因此,企業巫醫可以提出極端空洞的說詞,卻又多少讓人覺得有趣。除了「向上管理」之外,「創業」「創意」「領導與管理」「人格特質」等等都是屬於這類。

實務上,「向上管理」不能是打算進行的行為,而是產生貢獻中的其中一個結果。換言之,追逐向上管理,等於是捨本逐末的追逐影子行為。

因此,先務實地做到基本三件事情,假如踏實的做到了,向上管理就不是問題,而是附帶的結果。

1. 真正了解關於自己的現況事實

事實現況聽起來簡單,要找到也很簡單,但是要承認自己的現況事實其實有點難。

事實必須是清楚的,不模擬兩可的。例如,假設你是NBA球員,去年平均上場25分鐘,平均得分14分,這就是事實。至於你的技術能力好不好,並不是「事實」的一部分。以資訊科技的相關工作來說:參與過專案是事實,寫過java/python程式是事實,取得JSCP證照是事實,有Scrum證照是事實,帶領過開發團隊是事實,參與open source相關研討會是事實。

然而,具有良好溝通能力不算是一種事實,喜愛資訊科技不算是一種事實,

現況也必須是清楚的,不可能模糊。例如,目前薪資是現況,工作年資是現況,是否有直接report的人(也就是是否為管理者)是現況,最近一年有沒有拿到其他公司的offer也是現況,曾經拿到比現在薪水高的offer也是現況。

然而,覺得自己薪水被低估不是現況,覺得自己不受到重要不是事實,幾乎大部分的感受也都不是現況的一部份。

請參考這裡這裡這裡


2. 讓自己的實際產出超乎期待 


二因子激勵理論,描述「保健因子」和「激勵因子」兩種個人激勵因素。而其實這也是務實的評斷自己工作的方式。請參考這裡

要確定自己的產出超過期待,必須要確定產出有「超出」。

以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內。這樣的工作內容並沒有「超乎期待」,只是滿足「現在的薪水」而已。

要超乎期待的方式有很多。最容易的方式,是在目前工作範圍之外,「額外」並且「主動」完成有意義的事。例如,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,主動地在額外的時間舉辦小規模研討會,分享工作上技術的進展。另一個例子,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,由於主動學習其他程式語言,因此在其他專案上也能做額外貢獻。


3. 建立短中期職涯計畫並確實執行


在資訊科技產業中,實踐長期職涯規劃幾乎是不可能(註1)。

然而這並不代表自己現在就應該隨波逐流,看主管決定什麼就做什麼。個人應該要維持短中期的職涯規劃。特別是短期規劃。

短期規劃,必須要和技術能力以及現在工作有密切相關。

例如:

「作為一個程式設計師,未來8個禮拜,要能學會Scala基本用法,並且提出現在產品裡用Scala做分析的計畫」

「作為一個QA新鮮人,未來4周,要能將現在100個手動測試的case,至少其中20個變成自動化測試。同時,原本的工作也不會拖延」

中期計畫乃是半年到2年左右。必須要是「可以明白斷定達到與否」的目標。

例如:

「作為一個QA新鮮人,在2年內我想要變成資深QA,斷定是否為資深QA是以是否升遷或取得其他公司資深QA的offer」

當你完成數個短期計畫,通常表示你也踏實的逐步成長。即便有些短期目標沒有照時間完成,也沒關係,幾次之後,仍然是踏實往中期目標前進。

重點在於:這些目標是你自己決定的,並非主管或其他人硬塞給你。而目標既然和目前工作有關,自然就會協助你在工作上成長。


......
如果你非常非常確定已經完成以上三點,但覺得在這個組織中的成長仍有阻礙,還是很需要「向上管理」,用以獲得好的評價,獲得升遷?這基本上是不太需要,因為你應該儘速離開這樣的組織才是最好的方式。




註1: 「長期職業規劃」和「個人理想夢想」並不同。個人理想夢想可以需要很長很長時間實踐,也可能只需要很短的時間,也可能和職業無關。當然個人夢想就需要長期投入,也可以規劃,也可以不規劃。不過,不投入自己時間的夢想,通常就是空想而已。

3/23/2017

企業巫醫 - 贅字 廢話 泥巴仗




在組織中,溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單,畢竟人類是靠群體合作而存活在地球上。不過,在企業內部的有效溝通並不如想像中的容易(註1)。

某些人在對話或文字表達上,有意無意的更增加溝通的難度。如果是無心的,僅只是造成困擾而已。但如果是刻意為之,會讓溝通困難,讓事情滯礙難行。

無論有意無意,溝通上常見三個問題:「贅字」「廢話」「泥巴仗」

在這三個之中,贅字和廢話很煩人,但真正要解決的是可怕的泥巴仗。


贅字


典型的例子,像是最近淡江大學解聘兼任教師的新聞:高教工會主任:「學校也一再地向(兼任教師)表示說,也是因為今年的8月1日,勞基法要開始適用於,未具本職的兼任教師身上,學校不想負擔這樣的人事成本,所以他們才會做了一個解聘跟不續聘的動作。」

有人稱這類型的贅字為「語言癌」。(註2)

凡舉「關於XXXX這個部分」,「做一個XXX的動作」,無意義的拉長語句都是。

當然也有些人認為拉長語句是「敬語」的表達方式(註3)。

此外,狀聲詞:「嗯」「唉」「阿」因為在對話中,有實質表達情緒的功能,所以不算是贅字。

不過,贅字真正的影響其實很小,只是太多贅字會讓聽的人很不舒服而已。



廢話


在說明事情,或者文件上,用過多虛浮的形容詞,掩飾無意義的內容。或者,重複不證自明的真理,用以掩蓋無法找到重點的對話。

在政府機關的公務人員出國報告網,可以輕易地查詢到充滿廢話的報告。

例如:一個公司是多面向的結合。(簡單的說,整句都是廢話)

例如:透過本次會議實際瞭解大陸生醫相關市場現況,就本所研發之核醫藥物推廣應用極具參考價值,可納入本所未來研發方向之參酌。 (簡單的說,出國去參加這個會議,最後只是參觀看看而已,沒什麼東西是真的影響組織的研發方向!)

另一個例子:不論是什麼樣類型的數位化工具,除了便利性外,都應兼顧到安全性,日後推動電子化政府的過程中,應與各級資訊安全主管機關做密切的合作,確保資訊科技的演進不會成為資安漏洞。(資訊科技本來就不應該是資安漏洞,各級安全主管機關本來也就應該合作,哪會需要出國參加會議之後才知道這兩件重要的事?)

當然,某些企業網站資訊,也是廢話很多。不過,大部分是似是而非的術語,構築專業能力的感受。

例如:透過嚴格的專案控管與扎實的系統建置專業能力,我們有信心提供客戶最安心、最可靠的大數據優質服務。(如果把形容詞拿掉,這句話其實很短:我們提供專案控制和系統建置的大數據服務。但更具體一點,就是:其實有案子我們就可以接來做,大數據只是個行銷名詞)

有時候廢話很煩人,因為要花些力氣才能抵達事實真相。廢話浪費的很多時間,不過如果採用Scrum方法論,在會議上只專注於現況和事實,應該不太可能會有廢話太多的問題。至於網頁資訊和技術文件,就應該盡可能去除廢話。

泥巴仗


最高級,並且更難應對的是泥巴仗。

特別是在中大型組織,中階主管通常都位於關鍵職位。而好的中階主管,仍具備本職學能(註3),會根據事實來溝通。也因此,優秀的中階主管通常會強調技術事實,產業事實,專案事實,資源分配事實...等等諸多事實根據,作為溝通以及決策的基礎。因此,反倒不會強調本身的溝通協調能力。因為這樣的能力,如同影子一般隨附在工作之中。

然而糟糕的中階主管,由於已喪失本職學能(註4),就會強調其「協調溝通」成為其最重要的工作。然而,不基於事實和邏輯的溝通,會變得混亂不堪。某些糟糕的中階主管,在遇到爭議性問題時,會用打模糊的方式,試圖讓大家在泥巴仗中度過。而最高階的泥巴仗,會用看似合理的邏輯,但展示對技術完完全全無法掌握的事實。

例如:這個影片,非常經典,看似誇張,但在資訊科技產業其實常常發生。在該影片中,真正做事情只有一個人,而中階主管遇到技術難度的問題會省略甚至推諉,不能體會真正的重點而死咬不重要的細節,而技術人員要探索細節又會說這是專家的工作範圍。當然該影片是太誇張了一點,但其實在中大型組織時常發生類似的事情。

另一個例子:在老大靠邊閃中的有名片段,first thing or second thing。主角完全是用打泥巴仗的方式,在黑幫大老會議裡,刻意激怒某老大。而其他大老反倒會覺得生氣的老大很沒風度,一開始沒發現主角在打泥巴仗。

在此徵求案例:徵求在資訊科技中,重要會議裡打泥巴仗的案例。 


混亂泥巴仗是很可怕,要對應泥巴仗有先決條件,就是這不能是在「只有兩個人」的情況下。換言之,會議或者文件,至少要有三個人在場才有機會擺脫泥巴仗。

只有兩個人的情況下,只要有一人刻意打泥巴仗互相把對方弄的髒兮兮的,而且這個人還是中高階經理,另一個人根本不可能解決。唯一的方式是,儘速逃離現場,在下次確保有第三人以上在場。

在有起碼三人的情況下,以下方式可以解決泥巴仗問題。


1. 不隨之起舞


泥巴仗成立的條件是互抹泥巴。例如,在軟體專案中,當大家在解決A模組為何落後時,如果有人反覆提及一些沒有直接關連的事情:也許是另一個專案也落後了,也許是某RD的溝通態度不好。這些都是泥巴仗的徵兆。


2. 以白板展現事實


人的思考和言語是線性,因此在看穿複雜問題時,光是在腦中想是很容易被泥巴仗牽著走。

最好的方式是,一旦發現「同時」討論兩件以上的事情,就應該在白板畫圖或者條列。

畫圖是最好的選擇,最簡單的可以考慮心智圖或者魚骨圖。一旦有人試圖混淆事情,只要指一指說明我們現在在討論這個點,等討論完有決定之後,再往下一個點前進。而如果兩件事情有關連,就用線條與另一個點來說明此關連。

這也是為什麼,幾乎所有優秀的資訊從業人員(無論是低階還是高階)在會議中都喜歡坐在白板附近。


3. 耐心


簡單的說,就是有耐心的條理事情。透過工具(白板或紙)讓事情呈現。當知道對方採用泥巴仗手法-無論他是不是故意,就表示事情不會很快結束,因此要秉持著耐心條理問題。更重要的是,把這件事情當做類似刷牙洗臉的小事,在處理過程中沒有心情起伏 - 當然就不憤怒生氣)。






註1:特別是為求避免衝突,每人的說的話和實際心裡想的都有差距(參考left hand column),這讓組織 - 特別是資訊科技組織 - 運作上增加不必要的難度。

註2:  並不是去除重複字眼,極端簡潔就是好事。在文學作品中,言詞的優美有時候會透過層層疊疊的語句產生,請參考這裡。不過單就企業組織的溝通 - 例如開會 - 應該和寫小說是不一樣的。

註3: 參考這裡

註4: 以資訊科技來說,最基本的本職學能是寫程式,其他可以參考這裡這裡