顯示具有 顧問 標籤的文章。 顯示所有文章
顯示具有 顧問 標籤的文章。 顯示所有文章

8/04/2017

不玩一樣的遊戲 - 準備面試的真正技術


程式設計師如何在面試中展現真正價值:最好的方式當然是不要跟其他人玩一樣的遊戲,也就是在面試中,找出幾個能突顯自己技術能力的要點。針對這些要點,做延伸性的準備。




不管什麼原因,當一個軟體工程師下定決心要換工作時(註1 ),面試通常是免不了的。

作為軟體工程師,鐵定會上網搜尋各種「面試技巧」文章。

例如:常見面試問題的最佳回答:這篇或者這篇。也有些人會說,面試除了回答問題,更重要的還是會問對問題,例如這篇

但是,人資與主管,通常比面試者更知道這些所謂「標準問題」。也很清楚面試者可能會去找的「標準答案」。這些面試技巧文章只是一再重複大家都知道的常識,多複習這些常識是有很大的好處,至少可以避免緊張或者不必要的誤解。

但常識不會是關鍵。


在面試的時候,除了回答標準問題之外,最重要的是「確實展示自己的價值」才是關鍵。

軟體工程師/程式設計師的價值展現,其實第一時間點是在「看履歷表」的時候。短暫的面試時間是在「檢查履歷的正確性」。假設面試者的履歷寫的中規中矩,沒有什麼誇大,也沒有過度謙虛(註2),會讓你進入面試階段,就表示在履歷表上展示的技術能力是公司願意接受的。

面試展示自己的價值,通常是在幾個關鍵點。而這些關鍵點,都是「面試之前」可以先做好準備的。

(1) 應答技術問題
(2) 解釋過去做的事跡
(3) 詢問技術相關的問題


(1)  應答技術問題


大部份的軟體工程師工作,通常都會有程式考試題目。只要你在Leetcode, topcoder之類的網站,用你本來就熟悉的程式語言,多練習幾次,應該就不會太離譜。事實上,技術問題不可能考得過於艱澀 - 因為公司組織通常沒這麼多閒功夫在一個面試者身上。

其他的技術問題應該要根據你在履歷表上的專長做「延伸性」的準備。延伸性準備,才是展現價值的最好方式。

例如,倘若履歷表上你的專長是WebUI,那麼你就得延伸準備到HTTP:至少了解一些重要的header。如果你的專長上有寫Linux,那麼就必須準備回答曾經使用linux做過什麼事情?

如果曾經在linux上架設web server (nginx, apache...),至少也得知道設定檔在哪裡,如何開始停止服務,如何列出執行的行程(process),如何在不得已的時候強迫結束服務。當然,如果你會回答kill -9,最好確實知道為什麼是-9。

應答技術問題的不僅只是「防禦性」告訴面試者你的能力。而透過簡要地回答,「順便」展示自己對技術能力掌握的額外價值。就以上述kill -9為例,以筆者過去15年,面試超過400個人經驗,在履歷表上寫「熟linux」的起碼也有150人。這些面試者,八成都知道kill指令。然而,僅有不到10個人,知道為什麼要用kill -9,並能說明kill預設single 15是比較好的選擇。

在回答簡要技術問題,只要能有正確延伸性的回答,就能展現與他人不同的價值。而這絕對事是先可以準備的。


(2) 解釋過去做的事蹟


只要有2-3年工作經驗,面試時,一定會被詢問過去做了什麼。

因為,要了解未來一個人在組織的貢獻,最好的方式是看他「過去貢獻了什麼」。以下是一些解釋過去事蹟的要點。

** 妥善呈現事實而非感受。


當你已經離職時,過去的事蹟就已經成為「歷史」,而你可以準備的是「妥善呈現歷史的事實」,切勿扭曲或用「感受」呈現。

例如:「在那個專案裡面,幾乎事情都是我在做」。這其實是你的個人感受而非事實。事實必須要用無可扭曲的方式呈現。

又例如:「這個專案扣除html/css之外,前端javascript在git上大約有3萬行左右,其中兩萬五千行是我commit而且到專案結束也都是我負責維護」。這只是說明在程式碼上的「事實」,你並沒有貶低別人的貢獻,因為也許那其他5千行極端重要也說不定,但你也呈現了以code base而言,你的貢獻在事實上絕對不低。

**過去事蹟,絕對可以,而且也絕對需要在面試前妥善準備。


因為,你對過去自己真實貢獻越了解,就越能掌握過去事實。越能掌握過去的事實,就越能表示自己在技術上更有未來潛力。

例如,假設你是IT部門員工,過去都是協助內部系統上線,這些系統其實也是外包商提供。在面試時,被詢問做的內容,如果只是簡短回答「將公司委外開發的系統上線」當然也是可以。

但如果你在事實上,也會做「自動化檢測系統」「建構上線風險評估」「上線後的使用分析」「成本分析」以及「有沒有達到預期目的評估」,這些才是IT真正產生價值,並且與眾不同的地方。

最好的情況會是,公司之前並沒有此做法,而是你主動完成這些有價值的事,讓公司變得更好。可是,如果你已經離職,來不及產生事實 (當然也不可能去捏造說謊)。那麼,至少還是可以說「當時其實應做自動化檢測系統」,雖然那時候沒有完成,但你也可以在面試自己做一個小規模的自動化檢測系統,而在面試的時候就可以大大方方的說,當時雖然沒做,但是自己覺得應該要做,所以主動在事後做了。

當然這表示你需要在面試前付出時間準備。這樣的付出不會是沒有代價的。即便這次面試沒用到,你所做的事情是不會消失不見,只要是你做的「技術上正確」的事情,未來一定會對你的職業生涯有所助益。



(3) 詢問確實的問題


通常面試的最後,都會給面試者問問題的機會。

許多文章中,的確會說明問問題的重要,例如這篇。有上網查過的面試者,也了解不該問一些瑣碎小事,上下班時間,或者公司基本福利,因為這些問題只是等於打發時間。雖然沒有害處,但是也沒有價值。

軟體工程師最適合的就是詢問有價值的技術相關問題(註3) 。而這些問題也可以讓你稍微判斷此公司的狀況。

基本問題

一些很基本的問題,可以簡單展示你對軟體專案成熟度,也可以讓你了解這個公司的狀況:

* 請問目前是用什麼樣的版本控制系統,管理程式碼?

    該組織用什麼樣的版本控制系統不重要,無論是git, svn, cvs, p4...都可以。重點在於,的確還有些組織連版本控制系統都沒有。

* 請問目前組織是使用哪種專案管理方式?

    最近幾年是流行Agile/Scrum,

* 假如我有幸錄取,前三個月你希望我能完成哪些事情?

    這個問題代表自己的積極程度。主官如果對這個問題講得過於籠統抽象,很有可能該面試官(主管)並非實際的技術管理者。

* 團隊最近一次做code review是什麼時候?
* 團隊的bug追蹤流程目前大概是怎麼做的?
* 目前自動化測試的涵蓋率大約是多少?

    這些問題是展現自己對軟體開發的成熟度。特別注意的是,如果這些問題被籠統的回答,也不需要追根究底找別人麻煩。


進階問題

可能會引發進一步討論,也可能被反問,所以要事先準備被反問時的技術回答。

例如:

* 就現在的資料和面試的情況,您個人覺得會錄取我嗎?

* 最近一次在團隊裡面遇到最大的技術困難是什麼?

* 組織如何判斷成員的技術產出?




高級問題,


很有可能被認為是反過來刁難面試主管的問題。必須斟酌採用。例如: 

* 目前軟體專案程式碼的entropy有多高?

* 目前自動化建構和測試是採用哪些工具,涵蓋率有多高?

* 就您個人而言,最近在組織內學到新的技術是什麼樣的技術?新的程式語言或者新的工具?







面試是可以事先作準備地,軟體工程師的面試準備,應該花時間以事實展現價值作為準備方向,而非準備一些大家都知道的常識或者花時間準備外在行頭口語表達...等等。當成功地完成許多面試,就可以在工作機會上有所「選擇」。


參考文章:
(1) Scrum認證!不要再浪費你的時間了
(2) 如何充實自己
(3) 畢業前六個月 建構職業生涯
(4) 年底才績效評估或考慮轉職 已經太遲了
(5) 因為沒挑戰想轉換跑道,先檢討自己吧


註1:要轉職換工作區分成「主動」與「不得已」兩種。不得已:例如公司倒閉之類,當然就不用討論。但是如果是「主動」,就要先想清楚「真正的原因」。因為這個原因,可能不會因為你換工作而消失。

註2:剛畢業的學生可能是怕履歷表太空洞,通常都有誇大的傾向。而在業界打滾數十年的老鳥,有時候會有過度謙虛的可能。

註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:然而,有許多研究顯示太多選擇也反而造成壓力,請參考這裡

5/22/2017

企業巫醫 - 講重點!




在許多企業巫醫的書籍文章演講中,都繪聲繪影的描述「講重點」是極端重要。但也僅只是說它很重要,卻擺明著忽略這件事的真正重點:「關鍵重點難以找到」,或者更直接的「怎樣找到重點」。


就只是像提醒健康很重要的提醒「講重點」的文章像是:這裡這裡

另一些文章,表面上提出一些找到重點的方式,但是壓根也是一堆廢話。例如:從對方觀點找到真正價值。聽起來很有道理,但就像部落巫醫說:「得罪了祖靈,所以你生病了」,看似有理,但是到底做了什麼得罪了祖靈才是重點吧。「如何」知道對方的觀點,才是找到重點的重點。這類型的文章例如:這裡這裡這裡

只而更有些文章,提出了似乎務實的步驟,但都是太過一般化的案例,不是類似秘書處理好老闆的行程,就是與別人討論時的對話重點。這些在技術為主體的組織裡也根本派不上用場,例如:這裡這裡


絕大部分的人在工作上,並非不講重點,而是講不出來或找不到。而很遺憾的是,複雜環境(參考Cynefin架構)下的關鍵重點,並沒有簡單的三步驟,也沒有五個必備SOP之類的方式就可以取得。

關鍵因素的掌握,需要知識與經驗的累積。

知識的累積會堆積成智慧,經驗的累積會變成靈感,而智慧與靈感綜合起來,就能在複雜事物上以很短的時間將其抽象簡化,而抽象簡化的事物就容易看出重點。

雖然沒有捷徑,但就像是健身減肥一樣,從任何時間開始都不嫌晚。而且從任何時間點開始,都可以在比自己想像的時間內還早獲得效果。

知識的累積


只要抱著開放的心態,多閱讀,多請益,大概就很容易做到知識的累積。(知識快速累積可參考這裡)

值得注意的是,知識也有分軟硬兩種類型(註1)。

軟知識:談判技巧,溝通技巧,專案管理,人際關係,等等都屬於軟知識。換言之,軟知識可能會隨著文化背景改變而有截然不同的結果。

軟知識,容易落入「嘴砲唬爛」的範圍。軟知識的累積因為太多太多地方可取得,就不在這裡討論。要稍微注意的是,無論是什麼樣的人對「軟知識」都有自己的一套煞有其事的說法,要注意不要落入「純唬爛嘴砲」的範圍之中。

硬知識:數學,工程,程式設計,等等都屬於知識。換言之,硬知識不會隨環境的改變而改變,但它會隨時代的進步而進步,容易站在巨人的肩膀上前進。

硬知識,容易變得「極端」,不是容易被忽略,就是容易被過度強化。

絕大部分在組織工作的人,只要有數年以上工作經驗,都知道軟知識的重要。而各類型心靈成長,溝通協調,領導管理的書籍課程就孕育而生。在組織中,最極端的中階主管就會有意無意透露出「軟知識」遠比「硬知識」來得重要的許多(註2)。

最佳的情況是:硬知識和軟知識必須要互為成長基柱。兩者兼具的成長。

硬知識的累積:非常簡單,(1) 先設定知識累積範圍,例如設定為軟體品質改善 (2) 利用mindmap圖,整理自己已經在腦海的知識 (3)去圖書館至少借7本相關書籍,(4)上網尋找相關知識 (5) 閱讀並且搜尋完之後,僅憑自己的記憶和腦中統整結果,再次畫出mindmap圖,有必要的時候進行實作(例如寫程式)


經驗的累積


經驗可以解決在Cynefin framework中,「複雜」與「渾沌」這兩個象限的問題。(關於Cynefin請參考這篇)

不過,經驗的累積方式是經驗是否能「持續累積」的關鍵。

同樣一件事情做20年,有些人會取得20年的寶貴經驗,有些人卻是像是只做了1年一樣:只是做了20次一年。

以軟體開發為例:

1. 在SAP的ERP環境下,撰寫相關模組20年,如果沒有產業相關知識的成長,只負責出各種報表,那麼和2年經驗也差不多

2. 做為專案經理超過20年,如果遇到事情只會加班解決,那麼和1年經驗也差不多(參考這裡)。

3. 做為有10年開發經驗的java程式設計師,如果遇到組織調整,需要使用其他程式語言,但用各種方式拒絕推託,那麼未來可能就變成只有數年經驗值的程式設計師。因為推託學習不但會讓技術停滯不前,還會退後。

經驗的持續累積也很簡單。重點在於「持續」:每隔一段時間檢視自己的工作筆記,看看自己是否做了任何改善現在工作的技術的事情。如果沒有,就表示沒有持續累積經驗,經驗僅只是停滯而已。

沒有工作筆記?趕快去買一本吧,筆記本太便宜好用了。







註1:當然有些知識很難分軟硬,這裡只是概述而已。
註2:例如,軟體開發有個傳言:「coding co的好,要飯要到老。」

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: 以資訊科技來說,最基本的本職學能是寫程式,其他可以參考這裡這裡


3/07/2017

畢業前六個月 - 建構職業生涯



在台灣的碩士生,畢業前六個月通常忙於論文。如果不考慮繼續就讀博士,畢業前六個月其實是建構職業生涯的最佳機會。

更確切的說:畢業前六個月是讓你日後容易取得理想工作的最佳準備期間!

為什麼需要強調在6個月前建構職涯規劃?

環境上有許多現實的情況,例如,大部分好工作機會,其主管都傾向雇用有經驗的程式設計師。然而,絕大部分剛畢業學生並沒有實際軟體開發經驗。

因此,剛畢業的學生如果剛好獲得一個適合自己,能夠成長,能夠有所貢獻的工作,那麼就會進入良性循環。這個工作會讓這個學生更容易找到下一個好工作,或者即便不換工作,也能在目前的組織中成長。


反之,剛畢業的學生如果找到一個不適合自己,到處瞎忙,只是以時間換取薪資的工作,那麼就進入惡性循環。這個工作會讓該學生不容易找到比較好的工作,即便勉強換工作,也得靠運氣。

如果不想靠運氣,也沒有富爸爸,也不想自行創業(註1),則要做的事情很簡單:

(1) 考慮現況
(2) 設定短中期目標
(3) 建立事實


考慮現況


首先,最重要的是,取得一些關於自己的事實。是不是想要做關於軟體開發相關工作?想要做哪一類型的相關工作?是否知道自己還缺乏哪些能力?哪些地方的工作,可在短時間有巨幅成長?

如果想要當個程式設計師,要考慮的現況:

1. 能使用哪些程式語言:是真的會,而不是只寫過hello world和學校作業。並且有「事實」可以佐證。例如在github上的project,或者工讀經驗。

2. 能掌握資訊技術工具:是真的能掌握,而不是用過一兩次或者學校作業。並且有「事實」可以佐證。例如:工讀經驗,利用資訊工具做的個人專案等等。

3. 能掌握團隊專案合作方式:例如是否有Scrum相關證照(註2)。

4.....<其他還有很多請自行想像>

如果想要從事資訊業,但是一開始就做SA/PM類型的工作,在軟體開發職涯裡其實不太腳踏實地,不過,真不得已可以參考這篇:資訊科技學生畢業後只想當SA/PM (三個創意作法)



設定短中期目標


某些職涯教練,或許會建議新鮮人設定長期目標。甚且透過各種神奇的方式推展或瞭解自己的熱情(passion)所在:例如希望自己五年之後賺10億之類的。

大部分的長期目標雖然有趣,但是用處不大。設定可預計的中短期目標更為重要。

以6-12個月為期,讓自己在畢業前達某些技術性和非技術性目標,對未來職業生涯非常有幫助。以未來想要當程式設計師的學生為例,在畢業前六個月可以訂立以下目標:

* 開發並且將一個Android APP放在googlestore上:熟悉在android平台上開發APP,因此需要熟悉Java。

* 取得Scrum Master證照

* 閱讀3-4本關於軟體QA的書籍,並且運用在現在的專案上。(含建構測試案例,執行測試,系統化記錄錯誤,...)

訂立目標必須要是

(1) 有非常清楚的結果。如果目標是「熟悉java」,則最後有沒有達到此目標是非常模糊的,但是目標是開發android APP並且上架,就表示必須要寫java到某個程度才行(註3)。

(2) 可以在6個月之內達到。不要設定一個花10年才會達到的目標。如果真的有長期目標,當然可以設定長期目標,但是需要伴隨可以逐步前進的短期目標。例如,或許你想要成為java大師中的大師,這可能要花上數年,但必定可以有個6個月能達到的前期階段,例如:「不靠任何補習方式,就取得SCJP」

(3) 其結果會伴隨建立事實。請參考下一段


建立事實

在畢業前六個月,是最適合建立「事實」的時候。

建立事實,和畢業前花時間美化履歷表有很大的不同。

美化履歷表,是可以靠一兩個禮拜,找一些專業人士協助就可以很輕易的達到。但如果自己的「事實」不夠充分,再怎麼美化也沒有意義。

前一段關於短中期目標,只要你的短中期目標定義夠清晰。這些就是你要建立的事實。

如果你是在未來6個月即將畢業的學生,對自己的技術能力非常沒有自信,然而又想從事軟體工程師的工作,可以考慮建立以下三個事實:


* 透過自己決定的開發專案(例如Android APP),徹底實踐品質管理(QA) 

     (a) 找一個不用錢的QT工具:可以參考這裡
     (b) 在開發專案的過程中,徹底運用此工具,確保自己的專案品質。
     (c) 將結果詳盡記錄,就成為自己能當QA的事實


* 透過自己決定的開發專案(例如Android APP),徹底理解並且妥善運用git(或任何版本控制工具)

      (a) 版本控制是軟體專案的基礎中的基礎
      (b) 需要徹底了解如何branch,如何merge,如何處理conflict
      (c) 其結果構成了解專案開發的基礎事實

取得Scrum Master證照

     (a) 參考這裡
     (b) 雖然大部分的管理類型的證照意義都不大,但是取得成本不高的情況下,展現了你至少是瞭解Scrum。






註1: 想要自行創業的準備不太一樣,首先要了解創業如何必然成功,再參考其他相關資料

註2: 花大錢考管理類型證照其實不划算,但是可以考慮花小錢,請參考這裡

註3: 對,我們知道React Native可以讓你不需要寫java,但是這裡只是舉例而已。


2/06/2017

Scrum - 團隊中永遠的反對黨



最近被問到的幾個問題:

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

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


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


....


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

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

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

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

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

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

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


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

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

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


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

雞:所有其他人(當然必須是和這個專案有關的人)

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

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

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

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

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


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


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

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

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

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

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



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


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

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

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

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





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

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

那麼可能的解決方法有:


(1) 自己的問題?


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

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

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

問題的產生點可能是:

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


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

(c) 其他,請參考:作為技術領導者的方式



(2) 解決老鼠屎


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

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

這類型人有幾種表徵:

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

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

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

(3) 縮小範圍


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

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

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

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

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

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

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





1/11/2017

企業巫醫 - 統計與謠言



In god we trust all others bring data 

  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低,同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會,例如:十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪,例如:誠品可怕迷魂盜泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇,例如:裝翅膀飛起來

最糟糕的類型,莫過於以「統計數字」造出看似符合邏輯的謠言。並且,從這樣的謠言中獲得利益。

許多時候,數據本身難以查詢正確性。而且由數字導引出的邏輯,更容易因人而異,因地制宜。從數字所引導的偏誤,有時候甚至比單純的謠言還可怕,因為它可能會在網路上留存多年,難以辯證。如果只是單純搞笑也就罷了,如果個人或者組織,以這類型的資料來作為決策的判斷依據,那下場可能非常慘。錯誤的資料,比沒有資料更糟。


不過,只要稍微留意,加上合理的好奇心,統計謠言是有機會判斷其可能性:


(1) 不解釋的數字


在各類文章或研究報告中,為求精簡,只會根據重要數字做衍生推論。然而,數字背後通常還有「未解釋」的數字,而這個數字可能更為重要。

企業僅21%的需要大學以上學歷為例。這篇文章,簡單說明勞動部的調查,僅有21%的企業需要大學以上的學歷。然而,這個數字有很大的問題。

也許,該調查隨機抽了100個企業主,其中只有21個企業主宣稱需要大學以上學歷的員工。

也許,該調查抽樣了企業主的「100個正在招募工作職缺總數」,這100個職缺中,只有21個是需要大學學歷。

這兩者有極大的差距。前者,可能這21個企業主,所需要員工數量高達2萬人,而另外79個企業主,所需員工只要79個人也說不定。而後者,正在招募的職缺,和「已經在職」的學歷也並未顯示。而單就此推論,僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化,而沒有附上數據的真實來源的推測,其解釋很容易被扭曲。然而,被扭曲的解釋,當然比較有戲劇性,比較容易被注意。

勞動部網站根本也找不到這份調查。

此外,很多政治性民調也是屬於此類,涵蓋許多不解釋的數字。



(2) 接近完美的不可能


網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示,越早退休壽命越長。(參考這裡這裡這裡)  

這份數據流傳非常之廣,被引用次數非常多,每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字,是退休年齡跟「壽命」的對照表如下。


retirelife
49.986
51.285.3
52.584.6
53.883.9
55.183.2
56.482.5
57.281.4
58.380
59.278.5
60.176.8
6174.5
62.171.8
63.169.3
64.167.9
65.266.8

不會統計的人也可以看出,在這個表中,越早退休,壽命越長。如果49.9歲就退休,那麼可以活到86歲。65.2歲才退休,就只能活到66.8歲。

以相關係數簡單計算,他的相關程度高達-0.96,換言之,這是一份極為完美的負相關數字。

這種過度完美個數字,應該要看研究論文的細節加以瞭解。例如他的樣本有多大?是什麼時候做的研究。就可取得的事實來看,他的樣本很小,並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲,所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是,這些數字並非真實研究論文,卻在很多人的轉貼中,莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因,是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷,財務規劃,人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外,別無他因。雖然已經有些人發現不對勁,例如這裡。但是許多第一次看到此研究的人,仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究:請參考這篇研究。該篇的結論就交由各位判斷,但至少它的研究方式,數字細節,都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng,懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者?)。至今2017/Jan/11尚未收到回覆。


(3) 邏輯上的不可能


邏輯上不可能,或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來,竟然遠超過全國GDP,而且高過很多。這在邏輯上是不可能的事情,因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查,而且其實也不打算認真做統計的相關文章上,例如這裡。因為在許多時候,謠言只是想要造成吸引人的目的,其真實性不重要,當然就也不特別檢查數據。所以自己造成自己數據兜不攏,邏輯上不可能的情況並不少見。

這和前兩者不同,邏輯上的不可能,可以單就資訊本身的內容加以探索,或者是再加上一些事實根據來檢視。因此,比較容易看出謠言的真實性。




最後,稍微提醒一下:廣告的統計宣稱,其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證,一般市井小民根本無法查證屬實與否。





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



12/10/2016

企業巫醫 - 提昇效率的秘方



這裡有幾本書...


- The Productivity Project 最有生產力的一年
- Four hours work week 一週工作四小時
- The Art of Non-Conformity不服從的創新
- THE $100 STARTUP三千元開始的自主人生
- Do over(不確定是否有中文翻譯)
- Nomad Life遊牧生活


這些書籍有很直接的共通點:


(1) 個人經驗


和一般以二手資料的企業巫醫的書不同,這些書籍都是以「個人實際經歷」為主要組成。可能沒有精湛繁複的巫醫術語,但是「因為自己有做過」也比較容易說服別人。


(2) 專注,效率,生產力


這些書籍或多或少都強調個人效率的重要。基本上不外乎討論80/20法則,生理因素,心靈意志,工具方法等等。


(3) 個人品牌創業


這些書籍的作者,其實都是「個人品牌創業家」。個人品牌創業大約在2006-2008年之後,在網路上蔚為風潮。特別是在北美,這些個人品牌創業家通常都會有(a)自己的blog (b)自己的書籍 (c) 一個看似專精的知識領域...接下來通常就組合優勢開始以自己的名聲盈利。




為何強調效率與生產力的重要?


合理的推測,這類型的書慢慢也會在亞洲流行起來。雖然僅只以個人經驗與觀點來詮釋某個複雜的龐大主題,可能失於偏頗。但相較於純以「個人想像」和「無根據的推理」的企業巫醫書籍比較起來,還是踏實的多。


其中,「專注,效率,生產力」是三位一體的永不衰退話題。自從有工業革命開始,效率/生產力便是工業界主要獲利來源。在1995之後的網路時代,雖然「創意」與「變革」突然成為顯學,但究竟沒有效率,無法被執行的創意,等於是一種空想。創意變為有效可執行的事項,才有實務上的意義(參考這裡)



因此,能否有專注,高效率,高生產力的產出,變成知識工作者必備的能力。而也是「缺乏資源」創業者成功的關鍵之一(參考這裡)。

而也正是因此,「提高生產力的祕方」,在近年來變成出書的顯學,甚至也成為「被創業」的利基來源(註1)。


個人提升效率生產力的祕方


很遺憾,並沒有什麼祕方可以「簡單而且戲劇性」的提高個人效率或者生產力。至少,沒有不需要努力的祕方。

在業界確實有各種「顧問」,可以針對特定的個人,特定的案例,提供收費的咨詢服務(註2)。但最終,教練顧問只能提供指引,還是只有自己幫助自己。


先考慮以下低成本的「尋找自己的祕方」的三步驟,大概只要花2天:


(1)  4小時閱讀



花四小時專心看完以下五本書就好,應該都有中文版。

- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over


這些書所提的做法都比較務實,然而,不見得適合每個人。單看一本書,也會讓你的視野受到侷限。花時間去找一堆書來選,也太浪費。請先看上述幾本即可。看書並將自己覺得有用的地方做些記錄即可。

其中一本看起來是在講創業?即便你一點都不想創業,它提供的方式仍然對一般工作很有幫助!


(2) 停止接受資訊一天


如果你花了4小時看完那五本書,應該可以體驗到讓腦袋休息的重要。找一個假日,無論採用什麼方式,停止接收資訊一天 - 電腦,手機,書籍等等一概停用。隨便去做點跟工作無關的事情。


(3) 檢視並決定提升效率生產力的做法


經過了4小時學習,又經過了1天的沈澱。是時候可以決定哪一些「做法」,是最適合自己。只要是最適合自己的做法,就是自己的祕方。

如果還是想不到好方法,可以參考這篇。這是經過看了那五本書之後,經過一天的沈澱,個人認為最簡單適合自己的方式。也許對讀者也是個好的參考。







註1:例如,隔一陣子就會冒出來的「增加記憶力補習班」「全腦潛力開發課程」「超級記憶力」.....不過最終的結果,通常是這些提供祕方的企業巫醫們,口袋裝滿無知大眾的錢,而這些花大錢上課的群眾,其生產力與效率卻鮮少聽過提升的例子.....至少從來沒聽過任何創業有成的人曾經說:「喔!對了我創業成功的祕方,就是上了XX人的腦部開發課程,讓我記憶力變得過目不忘喔」

註2:在台灣大多以企業開班的方式存在,但這種效果極端有限。而美國英國兩地,都有針對個人的「導師服務」。但其收費都很驚人,而且大概也無法遠端服務。例如這家seven coach。也有很多個體戶,例如這位John Spence