顯示具有 為自己工作 標籤的文章。 顯示所有文章
顯示具有 為自己工作 標籤的文章。 顯示所有文章

4/05/2020

如何成為主管 (軟體主管的31堂課)



一般資深的軟體工程師,或多或少都會有思考過也許自己可以當領導者- team leader, manager等等。

主管people manager的定義很簡單:就是有人直接對你報告,並且你負責直接管理團隊裡的人,包含考績評估,工作指派,以及,最差的情況下要解僱某人。

沒有人生下就會寫程式,當然,也不會有人生下來就會當主管。然而,和寫程式不同,主管很難事先「練習」。所以這就變成雞生蛋,蛋生雞的問題。

在組織趨向扁平的情況下,如果有心想要往主管方向前進,最好要做到以下三件事情:

自動擴大責任:


也就是,主動做跨出自己工作範圍的事情。這裡並不是指自告奮勇擔任福委會主委,或者安排一些團康活動,雖然這些對大企業來說也很重要,但如果時間有限,應該優先考慮:跨出自己工作範圍,但仍然還是在軟體開發工作的本質上。

這件事聽起來容易,但做起來相當難。尤其是資深的工程師常常手邊已經有忙不完的任務,自請擴大任務搞不好吃力又不討好。然而,這卻是成為主管的最必要且最實際的路。

要擴大責任範圍,最簡單的做法是先了解自己的主管現在在忙什麼,可以先幫他處理必要但是瑣碎的事情:例如,撰寫例行報告,安排會議,會議結束後的記錄和執行事項的追蹤,列出現在正在進行的風險控管等等。有些事項,表面上看似秘書類型的工作,實際上對掌握大局有相當大的幫助。

其次是針對雖然不在自己任務範圍,但是是很重要的技術事項,花額外時間的主動幫忙解決。在稍具規模的企業中,這種事情多如牛毛,問題只在於有沒有人有空去解決它。

尋找業界導師:


如果你覺得目前主管是個好主管,那麼可以主動要求他擔任你的導師(mentor)。其次是尋找在同公司中的其他主管,真的找不到再去尋求其他公司的主管。你所需要的導師最最最起碼要符合這些條件: (1). 工作經驗至少比你多5年。(2).至少在同一個組織裡有2.5年以上的管理經驗,(3).必須是樂觀進取的人。以上這三個是最低門檻,最佳的情況會是7~10年差距。超過13年可能會有反效果,最好要有數個成功的軟體專案經驗,起碼有10年以上的工作經驗,並且有至少雇用10人以及解雇人的經驗。

找一個自己的導師,聽起來難做起來相當簡單。重點在於只要去做就可以了。有幾個基本的事情要注意 (1) 誠懇地請求幫忙,並約定這幫忙的時間每週1小時而已,並也約定為期僅有6~24個月 (2) 不要一次找很多導師。一段時間(6~24個月)有一個導師即可 (3) 約好固定的諮商時間:每週30分鐘,或者,每兩週1小時都可以,聚焦於過去一兩週的實質問題的建議 (4) 誠摯的感謝和長遠的關係,比實質的利益來的重要太多,強烈不建議付補習費,遇到需要索取補習費的導師就表示你可能找錯人,但是每週的諮商時間,請杯咖啡之類的小事倒是可行。(5) 如果可以的話,最好是12個月以上,但如果可以的話也不要超過24個月

在工作上遇到的問題,尋求業界導師過去的類似經驗,是最佳的參考。

留在還不錯的公司:


這個世界上沒有完美的公司,每個企業組織都有好的地方和不好的地方。只要覺得自己現在的環境沒有特別糟糕,目前所在公司仍然願意投資資源在人才培育,自己的主管是可學習的對象,那麼應該起碼考慮未來3~5年留在同個組織發展。一般而言,內部升遷的機率是大於外部空降。尤其是,如果你現在還未曾擔任過主管職,從外面招募一個沒擔任過主管的人來當主管的機率微乎其微。

大部分的人,總有看到別人碗裡面肉比較大塊的感受。然而,一旦發現自己目前的主管非常糟糕,組織文化負面而且破碎,當然要儘速離開的好。

最後,如果連續數個公司都待不到2年,應該是要檢討自己,而非檢討環境。





8/31/2019

如何處理抱怨 (軟體主管的31堂課)


只要是人都會抱怨,然而只要是有經驗的主管,一定也都知道處理抱怨的重要性。過度並且持續擴張的抱怨不但會降低士氣,而且對團隊,對個人都沒有任何好處。

抱怨有分不同的層級,如果僅只是抒發心情,發發牢騷當然無妨。其界限在於,在平常閒聊,抱怨的只會佔不到1/3的時間,而在平常正式討論事情,正式的會議上,抱怨應該只是會佔不到1/20 (5% 或2分鐘)的時間。
主管在閒聊時後聽到的抱怨,大部分應該不用特別處理,畢竟是閒聊。 然而在正式會議上的抱怨則應該妥善紀錄並處理。因為抱怨的本身可能是和工作流程有關,更有可能的是潛在的問題,必須要試圖檢討解決。


案例一:工程師E技術能力向來不錯,然而跟他一起工作的同事,總是會反應他是個悲觀的人。追究原因發現,E無論如何都在抱怨,抱怨目前的現況和組織的做法,抱怨福利薪資等等。過了一段時間之後,團隊成員有些會受到影響,跟著開始抱怨,有些則會忽視他的抱怨。

案例二:在跨國團隊中,另一個國家的工程師會抱怨無法取得某些系統權限,而本國工程師常抱怨另外一個國家的工程師常想要干涉目前自己工作的範圍。



主管處理嚴重的抱怨有幾個方式:

(1) 了解抱怨的事實,根據事實決定行動


如果軟體主管覺得這個抱怨的人其實是為了組織好,而且,大部分的時候抱怨者其實不那麼常抱怨,也不是士氣低落的人,他除了反映工作困難之外,也許也揭露了應該改善的現況。應該進一步了解實情。並且在根據事實來決定行動。

以上面的案例二,雙方雖然都有道理,但主管進一步了解事實後,會發現其實某些系統的權限並沒有分group,這會讓該系統只要有權限的人統統都是最高的管理者權限,所以表面上是合作問題,其實是個技術問題,應該讓系統有不同層級的權限,另一個國家工程師也不是真的想管理這個系統,只是為了工作必須要直接使用,透過另一組人間接使用也很麻煩。而本國工程師也不是真的不想讓其他人使用,只是考慮安全性不應該給很多人管理者權限。


(2) 擁有改變的力量,而不是擁有「叫別人改變」的力量


許多抱怨的工程師常常會忽略「在公司裡面,我是來解決問題,而不是製造問題」

對於主管來說,如果抱怨者其實績效能力都很好,那麼應該化抱怨為力量。舉例來說,當團隊成員抱怨「現在的某系統在部署常出問題,害我需要做額外的工作」。那麼就可以先就事實詢問:「你覺得這對你很重要嗎?這是不是我們應該先解決的問題?」如果是的話,進一步應該跟抱怨者溝通:「既然這樣,你現在在做的是XXX和XXX,這兩件事就先不做,先來把某系統的部署改善,這樣以後你就不用做額外的工作」

讓抱怨者擁有改變的力量 - 就是要調整工作內容和時間。這樣久了,也可以清楚地塑造團隊會往解決問題方向前進,而不會只抱怨問題。

(3) 概念性問題:先記錄並且追蹤


概念性的抱怨是指對公司政策概念的抱怨,例如:為什麼我們公司沒有work-from-home(在家工作)的政策,為什麼上下班要打卡。這類型的抱怨很多時候和「實質工作」沒有很大關係,然而,不處理或者直接用「這個是公司HR政策 我也沒辦法」這種說詞也對大家沒好處。

對於概念性抱怨,應該先行記錄,並且追蹤對團隊成員的影響。舉例來說,對於work-from-home的要求可以先了解團隊成員需要work-from-home的原因:例如需要專心工作,還是需要兼顧家人。如果是需要專心工作,可以提出會在他需要專注的時候。幫忙直接訂一個會議室,或者讓他在距離公司很近的咖啡廳工作,並且記錄一整個月,看看有沒有實質影響。也許,他以後就不想真的work-from-home,也許他會覺得在咖啡廳工作也很好。

重點在於,概念性抱怨其實應該轉為實際可追蹤執行的內容。



主管對於團隊成員的抱怨絕對不能做以下的事情:


(1) 隨意附和,隨意認同抱怨: 表面上這似乎可以拉近團隊與主管的感情,事實上,一起抱怨對大家都沒有任何實質好處。

(2) 忽略重大抱怨:如果這個抱怨是很嚴重的,忽略拖延也沒有好處

(3) 不查證事實根本原因就行動:雖然所有人都知道要查證事實,然而許多事實的根本原因其實不那麼簡單。



10/14/2018

企業巫醫:20分鐘搞定「工作做不完」的問題?



上班族常會遇到的老問題是:「工作做不完怎麼辦」

工作做不完是個老問題,解決問題的方法也很簡單,然而簡單事情不見得容易做。更重要的事情是:你需要正確的檢視現況,才能真正解決問題。因為每個人的「工作做不完」的實際情況都不同。舉例來說,假設你是在無良的黑心老闆血汗工廠,那麼你的工作做不完的解決方式應該是儘早辭職,而非增加效率。

以下步驟確保可以幫助你解決這個問題:


步驟一:暫停!休息5分鐘! 利用15分鐘進行計畫



1. 休息5分鐘


除非你的工作是急診室或者核電廠這類人命關天的地方,一般的上班族,一旦遇到工作做不完,慌慌亂亂急急忙忙的時候,其實第一件事情應該先放空自己。找個安靜的地方(萬一真找不到可以藉故離開辦公室幾分鐘),先盡量將自己的思緒清空,沒辦法放空冥想的話,打個手遊也可以。當你的思緒紊亂,壓力暴增,往往會使用直覺處理事情,使用直覺處理並沒有錯,但如果「只靠」直覺處理,就會失去成長和學習的機會,更糟的是,直覺處理事情通常和情緒結合在一起,關於這點請參考腦的結構杏仁核

所以讓自己休息五分鐘!


2. 計畫15分鐘


休息之後,拿出紙筆,先對現況做計畫。
列出事情的四個象限:重要/緊急矩陣(參考這裡) 。
如果你已經熟知這個事物分類方式,那就可以直接挑過這段,並思考自己為什麼不做這件事?

 2.1 重要且緊急:

 就是要專注處理的部份

 2.2 不重要但是緊急:

 要犧牲,或者交給別人,或者是忙碌狀況。但通常這種事情都是工作做不完的主要來源。最好的方式是縮小事情的影響。常見不重要但緊急的事情,不外乎老闆索取各種資料,感覺很急,

 2.3 不重要且不緊急:
  千萬不要去做它!普通上班族通常不小心會落入去做不重要且不緊急的事情,而且還不自知。最常遇到的事情是:對小事情花時間做無謂的討論。

 2.4 重要但是不緊急:

  千萬不要忽略他!忽略這裡,就無法徹底解決工作做不完的問題!



步驟二:按照計劃:逐一解決重要緊急的事


在計畫中,條列的重要與緊急的事情,要「逐一」處理。先不要想要同時處理,做個清單,搞定一個事情打個勾。

這聽起來簡單做起來很難。

有幾個簡單的執行要點可供參考:

(a) 自己找到專注工作的場地。很多工作其實不限定工作場合,只要你事先跟老闆講好,其實是可以嘗試找不會被打擾的地方好好專心把事情搞定。例如,在主管同意之下,中午三小時在公司附近某咖啡廳寫程式。在近年來開放式空間流行的狀況下,這點相對重要!

(b) 不要隨時檢查email與短訊。除非你的工作是急診室醫生或者某些人命關天的意外處理者,否則不應該時時檢查聯絡工具,你應該是控制工具的人,而非被工具控制的人

(c) 設定解決的定義。緊急而重要的事情的「回應」不代表解決。解決事情要像是恐怖片裡的殭屍,當你沒有徹底將它打爆頭,它很有可能會再爬起來咬你一口。


步驟三:重新檢討計畫,找到提高效率的方式,專注於重要但不緊急的事情規劃和執行


為什麼要專注於重要但不緊急的事?因為重要的事情如果都先處理好,可以大幅改善「未來還會有工作做不完的問題」 而且同時減少重要且緊急的事情發生。畢竟很多重要緊急的事情,就是當初重要但不緊急的事情一路拖延導致後來變緊急。

因此,這步驟用以確保可以有計劃地執行「重要但不緊急」

有幾個方式可以確保自己不遺漏「重要但不緊急」的事情

(a) 隨時檢查中期目標:組織通常有偉大的長期目標(例如登陸火星),但也由於通常太偉大,所以必須要逐步以中期目標達成。個人應該將中期(3~18個月)目標當作為重要的事情,而非最近短期目標。因為,短期事物常常會被迫打斷修改,就會容易淪落於被時間追趕而非控制時間。

(b) 每天排定固定時間處理「重要但不緊急」 即便是1小時,長期下來也會有效果。萬一不得已要加班,應該要加班處理的並非緊急的事,而是重要的事!

(c) 其他 (有空再說明此處)




步驟四:按照計劃,完成重要的事 ,並執行提高效率的方式


倘若已經執行到此。就可以考慮提高效率的方式。
其中最重要的方式就是「提高本身知識與能力」

提高工作效率有很多種方式,請參考這裡,或者這裡


步驟五:檢討成效,修改計畫


每個計畫都應該確實被檢討,自我檢討當然很好,不過,秘訣是請你認為做得比你更好的人幫你檢討計畫。

倘若這篇文章有某件100%保證有用的方式,那麼「請一個你認為比你厲害的人幫你檢討你的計畫和成效」是最最有用的一點。

10/03/2018

建立高度自我激勵之軟體開發團隊的三個方向 (軟體主管的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/20/2018

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



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

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

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

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

大部分的情況是:

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

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

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

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

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


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






4/30/2018

在多個工作機會中的選擇


只要有數年工作經驗,一個還不錯的軟體工程師,在轉職的時候,應該都有可以拿到3個以上的錄取通知。然後,從中選擇一個最好的工作變成另一個快樂的問題。

如何在獲得錄用的公司中選擇?

扣除掉工作距離,家庭因素,法律因素之後(註一),有以下幾個方向可供在多個工作機會中選擇的參考:

(1) 優缺點列表


將你的選擇寫在紙上,例如A,B,C三個公司。並且將你認為的優缺點條列出來。

這雖然是很基本的做法,但將腦中的思緒,用另一個方式呈現,會讓思考者以較高而且抽象的角度思考選擇性問題。

大部分的人,會列出條列項目大概是:使用的技術,工作內容是否有趣,薪資,工作時間,壓力大小,未來發展性等等。

除了薪資與目前使用技術之外,這些項目大部分都「主觀的判斷」。盡可能在優缺點列表使用客觀的資料。

以未來發展性為例,一個成立不到一年的新創公司,無論其產品有多厲害,它的未來基本上有90%的機會會在2年內倒閉,這到目前為止是鐵的事實。而上市上櫃公司,未來發展性應該優先調查過去3年的財報來判斷,而非看目前的股票價格。

再以工作內容是否有趣為例:必須要是「你到職之後會做的工作」來判斷是否有趣,而非是這公司產品很有趣。因為,即使是資深軟體工程師,到一個新地方也有可能會先做最無聊的工作。

最後,壓力其實因人而異,但客觀的判斷也不可避免,應該以「過去一年有多少比例的人離職」這類型的數字做為判斷的依據。

(2) 自身能力所帶來的影響力


除非是你自己就是這公司的老闆,否則,當你加入一個工作時,透過自己能力的產出,對公司造成正面影響力,是唯一你能做得好做的開心的原因。其他皆屬次要。

某些工作的特性,讓軟體工程師本身的影響力比較低,舉例來說,所有傳統的IT工作恐怕都是如此。即便IT工作非常重要,但通常被歸類為「保健因素」:也就是沒有會死,但太好也沒用。

某些工作看似很重要,但由於組織結構龐大,讓資深軟體工程師發揮空間較有限。例如在超大型軟體公司,有上千名員工,即便是非常厲害資深的工程師,其實對組織而言相對重要性也低。一個超過千名工程師的公司,不會有任何一個工程師特別重。

小型公司對大部分的軟體工程師來說,都比較能透過自身能力,發揮較大的影響力。這也是為什麼過去數年,新創公司能蓬勃發展的原因之一。但的確也有可能,大型公司的某些小型部門,工程師反而會發揮巨大影響力,line的故事可作為參考

(3) 未來的主管


英文俗語: people quit their bosses, not their jobs.  
在有多個工作機會選擇下,未來的主管是誰變成是重大的考量。

(a) 不知道是誰?

特別是超大型企業,新建員工會有「儲備培訓期」因此有可能在加入此公司之後一段時間,都不太能確定未來主管是誰。這在軟體開發的領域機會不大,尤其是對資深工程師來說。

(b) 考量的方式

盡可能以「事實」來考量,而非憑「感覺」。面試時通常會有問問題的機會,此時可以探究事實。基本的事實像是:團隊有多少人,最近三次加班是什麼時候,最近一次績效評估中,產出最好的員工做了哪些事情。感覺則是「這裡看起來好像很溫馨」,「面試我的主管看氣來很溫和」。

大部分的情況下應徵者期待的是「一個好主管」。然而,人非聖賢,要考量的其實是管理風格上最適合的主管。因此,詢問管理上實質作法,就是考量的最大因素。

當然,這些考量的事實,也應該呈現在比較的優缺點表格中。






註一:法律因素是指,即便有超高薪水,不合法的工作還是千萬別碰。

3/06/2018

何謂:資深工程師


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

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

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

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

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

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

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

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

技術能力


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

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

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

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

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

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

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

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


實質經驗

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

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

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

團隊合作

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

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

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

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




12/17/2017

企業巫醫:公司需要你,還是你需要公司?



每年年底照例有不少人考慮轉換跑道

換工作是很個人的考量,每個人狀況有很大的差異。然而,當生涯成長變成首要因素時,其中一個考量點是:「公司需要你,還是你需要公司」?

盈利企業當然需要各式人才,讓企業持續成長獲利。但每個人在組織中的重要性不同,特別是上千人的大企業。即便主事者真心誠意認為「每個員工都是公司寶貴資產」,但就事實來看,上千人的組織,不可能「每個人」都是寶貴資產。

因此,在想要轉換跑道之前,先衡量一下,到底公司需要你的程度如何?請記得衡量標準不是你的個人能力,而是公司需要你的程度。

了解自己被需要的程度有幾個方向:

(1) 有機因素 vs 有毒因素


有些時候,某些人以為掌握特定資訊,是被需要的因素。然而,這是屬於有毒因素。換言之,如果只靠掌握某些資訊是很危險的(註1)

舉例來說:在大企業中,專案從開始到結束有一定的流程和系統需要專案經理維護資料的正確性,例如填寫各種表格之類。然而如果專案經理「很會」填表搜集資訊,並且甚至知道很多「秘訣」,這並不是真正「被需要的」理由,而僅只是資訊掌握。將這個因素,作為被需要的原因,就是屬於有毒因素。又或者,僅只是在一個組織中待了很久,知道許多「眉角」,這並非壞事,但僅靠這點不應該被依賴的原因。

大部分的人,都能靠自己的能力產出價值,這就是有機因素。最簡單的情況就是:一個程式設計師撰寫所需要的程式,自然就產出價值。又或者一個廚師的手藝驚人,自然可以產出有價值的菜色。

有機因素和有毒因素都可以被培養,但是,培養有機因素的道路比較長遠。

(2) 換!


有些工作,天生取代性高。例如:餐飲業的員工,只要有心學習,絕大部分的人都能成為一個好的餐飲業員工。

有些工作,很具有專業性,只是在某個特定組織內,取代性很高。例如:在大型軟體組織(例如微軟)的工程師,在數萬個工程師中,其實任一工程師並沒有絕對的必要性。

屬於這類型的狀態下,要提昇被需要的程度,最快的方式其實就是「換」。

但是在「換」之前,需要確保兩件事情:

(a) 現在的工作產出已經超乎別人的預期:也就是說,別人(同事,老闆)很確定你做的非常好了 

(b) 提昇自己的個人能力:說來簡單做起來難,尤其是在大組織中。但就現有的工作範圍往外擴張是最好的方式。


(3) 避免帕金森法則


帕金森法則:請先參考wiki的說明

當在大企業做了3-5年之後,很有可能落入帕金森法則陷阱之中。也就是會盡量「擴大本來不需要的時間與資源用來完成工作」。這在過去的研究中有相當多的證實,並且全世界所有政府機關都有此現象。

一旦不自覺的落入帕金森法則,會下意識的降低自己的效率,產出和學習新技術的能力。自己的低效率,會成為成長的障礙。在員工能自我解決此問題之前,對大組織來說,都是「員工需要這個公司」而非「這個公司需要員工」。同樣的,對於小組織而言,公司需要員工的而非員工需要公司的機率會大得多。



註1:但是業務掌握客戶關係則不屬於此類,客戶關係並不是資訊,而是透過長期互動累積而來。是屬於資產的一種。
參考資料

參考資料

(1) 自我感覺良好的能力不足

12/09/2017

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.



10/01/2017

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


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


但是,簡單的路難行。


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

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


大型企業敘薪


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


小型新創企業資金不足


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

CP值的誤用

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



解決之道?


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

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

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

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



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:不過,人類有各種認知偏誤,合理化既定決定,無論決定合不合理,都有可能被自己合理化。


7/08/2017

企業巫醫 - 得罪老闆怎麼辦 (人際關係的過度重視)



得罪老闆(直屬主管)怎麼辦?

眾多企業巫醫都有不同的說法:

某一類型的企業巫醫以案例和經驗強調「如何不得罪老闆」,試圖就源頭解決問題。然而,大部分的作法,都是為了造就謹言慎行的員工。例如「得罪老闆的六宗罪」「別惹十種人」「與主管相處之道」「職場人緣學七招」。這些說的都沒錯,然而 - 除非是在超大型組織或者公家機關 - 職業生涯的發展,大部分還是取決於能力與實質貢獻,有效溝通與人際關係是其中重要的一環,而非全部。

有很多企業巫醫都會引用這段不實謠言「卡內基美隆大學曾針對畢業的 200 位傑出校友進行一份問卷調查,結果發現,成功的重要因素裡,其中85%來自一個人的態度包括自信、熱忱、領導、溝通以及人際關係的能力,另外的15%才是專業知識。」作為開場白,似乎再再強調人際關係的重要。更隱含著,只要有好的人際關係,就解決了85%的問題。

隨意引用未經實證的事情,是企業巫醫的共同特徵。就如同在部落驅邪一樣,告訴群眾,根據某某以前的巫醫說法,現在就是獻祭品用樹枝鞭打驅邪治病的好時機。

大概也是這個問題太典型,可是真實研究內容又和各企業巫醫所引用的有所出入。因而,卡內基大學的官方Q&A只列出問題,但是並沒有直接說明答案,只說這是1918年某期刊登載之研究,但是太久之前了,請自己去圖書館找(參考這裡)。

在此特別感謝google的paper search 學術搜尋,很快的根據年份跟名稱,找到該研究發表的地方(參考這裡,請直接看106至108頁) 


實際情況是:



(1) 該研究並非針對200個傑出校友,甚至根本也不是針對特定學校的校友。研究對象為美國工程師,實際樣本超過7000人。

(2) 該研究,是以問卷形式,將因素是工程師升遷的重要條件分成六組(Character, Judgment, Efficiency, Understanding of Men, Knowledge, Technique)。結果,認為Character人格特質那組條件,是升遷第一重要依據的人數,是其他組的七倍。 眾多企業巫醫所引用85%,應該引用此依據,再經過時間以訛傳訛的結果。

(3) 該研究開宗明義的指出在1900前後,美國的工程師教育問題,認為過於著重技術教育,而在工程教育體系缺乏對人格特質的強化。然而!該研究的人格特質定義乃是指

common sense, integrity, resourcefulness, initiative, tact, thoroughness, accuracy, efficiency, and understanding of men 」(註1)

光看字眼,也能夠體會到1918年 - 畢竟已經快100年前 - 和今日一般企業巫醫所指的「人際關係」有很大差異。例如:完整,正確,有效率,在現代社會通常是技術的一環,而較少列入人格特質的一環。

過度強調「職場成功85%要靠人際關係」就會讓「得罪老闆該怎麼辦」變成落在自己身上最痛苦的事情。因為,得罪老闆之後就會有「已經失敗了85%」的不實感受。

那麼,已經得罪老闆之後該怎麼辦?和處理問題的基本「事實三步驟」一樣:


(1) 確立事實



(a) 你的市場價值有多少?

必須要取得客觀的事實,而非自己心裡的感想。每個人都認為自己對組織可以產生很多價值,但事實上可能不然。最簡單的方式就是「試著去面試找工作」。在此m,並非鼓勵以換工作解決問題,而是以「測試自己的市場價值」來決定個人價值。如果在3-4個月內,無法找到比現在工作整體薪資高出10%的工作,那麼其實你現在在組織內部的價值是被高估。


其實不管有沒有得罪老闆,只要你受僱者,不是自己開公司當老闆,就應該要確定自己的市場價值。這是最重要最重要最重要,需要知道的事實。也是最大唯一根據。

(b) 得罪的原因是做了錯事,還是只是個性不合接連產生誤解,還是遇到一個糟糕的老闆?

也很有可能你永遠無法知道原因,不過如果有機會知道會比較好。

(c) 職業生涯的目標

(d) 對老闆的依賴程度

(e)...還有很多其他事實






(2) 建立選項


得罪老闆既然為既定事實,就要考慮「應該怎麼做」的選項。在完全被動情況下,人會有無限的壓力,選擇的權力讓有掌控感(不過太多選項也是壓力,參考 註2)。

無論如何,至少給自己產生3個應變選項,以下是一些選項參考。了解或者建立選項,並非一定要做,而是要給自己「清楚可見」的選擇機會。


(a) 不動作


每人都有機會得罪老闆,你不見得是唯一,也不見得是最重要的。不動作指的是不把它當一回事,繼續做好你該做的工作,繼續學習成長。


(b) 大幅提昇績效


如果你的工作績效清楚可見:要注意的是,清楚可見是指「其他人清楚可見」而非自己認為。那麼得罪老闆也並不是很重要的事情,因為你對組織的貢獻的本身,並不會得罪任何人。大幅提昇績效是可行的選項,不過前提是你「做得到才行」。既然你已經看到這篇文章,大概就隱含著這個選項短時間做不到。


(c) 組織內換部門


很多時候,你只是和老闆個性不合八字不合,在大組織內換個部門並非壞事。


(d) 換工作

換工作和內部轉移不太一樣。你必須把換工作當做「自己的選項」而非被動的選項。並且,不要欺騙自己。

有些人是在沒其他選擇的情況下,自己欺騙自己說「其實是我想換做工作」,這容易去找到一個勉強而不見得是自己喜歡的工作。換工作的選項在於,先確定自我價值,知道自己換工作可能犧牲的成本代價,然後視為眾多選項之一。當最後真的執行換工作選項時,在時間上和心態上就有很大的差距。



(e) 建立新技能範圍


自己開公司也屬於這個範圍。換言之,在維持現有工作績效的情況下,額外花時間開創可能性。

以資訊科技來說,主動舉辦workshop,參與opensource專案都可能是建立新技能範圍。然而,那怕是去取得水匠電工丙級執照也都是建立新技能範圍。(不建議直銷保險之類的工作)


(3) 執行選項


即便「不動作」,也是需要認知與執行。執行上有一些要件。

(a) 速度:除了不動作之外,其他的選項在「已經得罪老闆」的情況下,應該是要越快建立越好

越快能建立選項,表示自己掌握了「時間」。不掌握時間的人,就容易被動的被時間掌握。當你覺得每天忙碌不堪,似乎被事情追著跑的時候,表示你需要先改善自己的時間掌握能力。

(b) 建立回饋方式:任何要執行的事項,必須要有自我檢查的方式確定執行的結果是否和預期一樣。因為執行結果有差異的時候,應該「儘速修正」。

(c) 符合最終目的:當得罪老闆這件事發生的時候,你的目的到底是什麼?

你希望「已經獲得老闆原諒了?」
還是「得罪這個老闆已經沒關係了?」
還是「得罪老闆所產生的後果已經最小化」
還是「....」

執行任何解決方式,必須要符合你本來的目的。這目的當然只有你需要知道,而不需讓那些無法幫你解決任何事情的巫醫當作他的「研究個案」或者「參考範例」使用。



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


註1 :節錄原文描述人格特質的「項目」,徵求比較好的翻譯
註2:然而,有許多研究顯示太多選擇也反而造成壓力,請參考這裡

12/31/2016

企業巫醫 - 誰掌握你的升遷?



只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷,沒有別人。

大部分無法獲得升遷的理由,都只是自己的藉口而已。常見藉口(註2)如下:

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了,還在裁員
- 比我資深的還很多,很難輪到我


在大組織裡,個人升遷(promotion)仍然是職業生涯重要考量。因而,企業巫醫們的一些闡釋也頗有道理,例如這篇,或者這篇。但有些過於偏激,而且會舉一些憑自己想像的例子。這類型的巫醫頗多,在google上搜尋"升遷"就可以找到不少。


那麼,自己要如何掌握自己的升遷?


超乎期待:做出超越目前工作職掌的成績


升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織,或者主管,要認定你可以承擔更大的工作範圍,最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種,這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。


方向一:保健因素


保健因素指的是,沒達成會有負面影響,但是有達成,且做得再好也不會是超越工作職掌的事情。換言之,有絕對的必要性,但是超過也沒有意義。

例如:

作為員工,準時參與會議,準時上班,按組織規定請假。
作為一個程式設計師,準時交付符合品質的程式碼。
作為客服人員,在時間內回復顧客問題。
作為專案主管,讓控制並管理團隊時程,沒有延誤

有些是屬於規定類型,有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的!非但不用考慮升遷,甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解:


(a) 誤解一:消極應對


既然這並非升遷,或者有額外價值的項目,那麼也許我就做的勉強符合,60分就好。這樣的心態會讓這些的保健因素,很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化,(或自動化)的方式處理。

消極應對,只會讓保健因素變得個人缺點,得不償失!


(b) 誤解二:這不是保健因素


在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素,我做到這件事情就是超乎期待」。

事實上,絕大部分的由上而下指派的任務,幾乎都屬於保健因素任務。

例如,你負責撰寫android app任務,根據自己的努力,確實在規範的時程內,以規範的品質上架完成。這「本來就是」你的任務。完成這件任務,的確是好事,但如果沒有做出超越任務的範圍,那就是預期內的職掌。既然是預期內的職掌,當然會取得預期內的「報酬」,例如薪水。自然也不會取得「額外」的報酬,例如鉅額加薪或升遷。

試想,你搭計程車,司機在合理的時間內,安全的把你載送到你要求的地點。你自然會付出正確的車資,不太可能付出「額外」的費用吧。



方向二:激勵因素


如果有做到,會讓人感到「很滿意」。

這個方向並不容易,但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例,如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務,並且未要求額外收費,在你開心的抵達要求的地點時,非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考:


(a) 參考方式一:擴增保健因素


這個方式比較基本。例如:一個app的程式設計師,被要求在6個月內完成app並上架,結果在5個月就完成,並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」


(b) 參考方式二:額外的相關支援


類似計程車卡拉ok。例如:android app程式設計師,被要求在6個月內完成app上架。結果的確在時間內完成。並且,由於他採用react native,竟然也順便完成了iOS app。這就是額外的支援項目。


(c) 參考方式三:擴大 


主動執行擴大職掌範圍的任務。例如app程式設計師,其任務是開發app並上架,如果主動協助開發伺服器端,或其他功能模組,就算是擴大範圍。

更顯著的例子是:app程式設計師,其任務是開發app並上架,但主動組織團隊,做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。




其他:


離開組織,以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然,離開組織之前,要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方,也不可能解決問題,只是碰運氣而已。參考這篇,或者這篇,或者這篇

創業是自己造成升遷的最簡單方式。在那一夕之間,你就變成董事長兼CEO了。然而,能不能生存並獲利,又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易,參考這裡,與這裡







註1:在某些地區,某些情況下,當然有不得已的時候。例如,如果你是生在阿富汗,伊拉克,索馬利亞等國家,確實很難掌握自己的命運。所以,本篇指的是一般在台灣的普通上班族。

註2:為什麼這些是藉口?請參考說明如下:

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現,甚至可能被瓢竊或者搶功勞。但長時間不可能!而且事實上,如果你真的能力極佳努力也夠,僅只是沒被看到而已?那你應該很容易可以找到更好,並且更容易看到你的能力和產出的地方!

(b) 爛主管的確有可能打壓好員工,但沒有人強迫你為某個主管工作,你當然可以離開。但是在離開之前,請先參考這本書(我愛白痴老闆)。也可以參考(得罪老闆怎麼辦


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美,因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且,適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作,那不升遷的確是合理
(b) 如果工作真的太難,那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的,資源缺乏不是問題,只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單,可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單,但是對主管來說你沒把簡單的工作做好,以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了,還在裁員
-- 比我資深的還很多,很難輪到我

(a) 如果升遷是你最重要的考量,應該離開這類型的工作環境


12/22/2016

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



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

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

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


為什麼?


績效評估要及時


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

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

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

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

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

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

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

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

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

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



轉職衡量要完整


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

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

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

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



那麼,年末可以做什麼?


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



1. 不設定一年為單位


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

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

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

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

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



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


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

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

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

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



3. 不等候重要的事情


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

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

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





參考:

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間?

職業生涯的突破

成長的最好方式:檢討


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

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

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