顯示具有 企業巫醫 標籤的文章。 顯示所有文章
顯示具有 企業巫醫 標籤的文章。 顯示所有文章

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


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


11/24/2016

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




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

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


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

首先,需求(requirement)本身是很難被界定清楚,因為客戶也許也不能清楚的界定需求。Henry Ford 福特 - 福特汽車的創辦人,現代化造車的始祖 - 早在一百年前的名言,至今仍難屹立不搖:
--------------
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼,他們會希望跑得更快的馬"
--------------


然而,「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象,問了正確的問題,正確地理解回答。透徹的了解問題,才能知道客戶的需求是不是真的不合理,抑或,其需求背後有另外的需求。接下來才能知道怎麼反應。

還沒經過深思熟慮就直接拒絕,很有可能是自己故作姿態,甚至是知識技能不足的表徵。(註一) 

反過來說,隨意「答應」客戶,風險也很驚人。因為也許答應了一件根本不應該做的事情,或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸:客戶與企業都受害,甚至三輸:客戶企業與社會三者都受害。

而這聽起來極端荒謬的事情,卻一直在企業界發生。


因為誤解客戶需求,或者不夠及時調整需求導致於雙輸的例子,在近20年內的有很多,隨便找一些範例如下:

* FoxMeyer的SAP引入案例(1,2)

* Waste的SAP引入案例

* 台灣戶政系統當機事件(1,2,3)




那到底要怎麼做?


1. 根據事實的正確溝通


抽象化的形容詞,對溝通不會有助益。

例如:「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」

抽象化的言語,在務實的書面報告中越少越好。當然某些摘要形式的報告,會很抽象,但隨後必定附上務實的參考依據。

例如:

「高可靠度系統」:已兩台伺服器互為備援的方式,達到高可靠度

「網路速度很快」:過去對外連線的速度是1MB,現在提高到1TB,因此網路速度很快。

「網站介面很好用」:過去每個月平均有150次客服電話,是在詢問網站某些功能要怎麼使用,現在每個月僅有10次。並且,每個月平均使用人數並沒有減少。


2. 透過具體內容決定接下來的執行事項



互相理解現在的情況是第一步。接下來要做什麼是第二步。

為什麼決定接下來要做什麼和「客戶不合理的需求」有關?

首先,合不合理的判斷本身就很難客觀。對某人來說不合理的事情,對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見,只要接下來的執行「事項」,確實都是雙方認為最重要的事項即可。

和第一段相同,具體內容必須是清晰可見的動作(action)

例如:

* 將第一批手機抽15%樣本共150隻,進行電池過度充電放電測試。並在N月N號之前,給出測試結果報告。

* 將iOS app送到apple-store進行上架審核。

* 在使用者帳號管理系統上,增加可以使用fb帳號登入的功能,在N月N號之前,給出設計文件。

不是清晰可見的動作,會造成很多不必要的誤解,而誤解就會產生不合理的需求。


不清晰的動作例子如下:

* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試,一隻也可以嗎?要測試哪種類型的爆炸?太陽曬到玻璃破碎也算嗎?)

* 我們的iphone app要趕快上架了 -- (?是要上架到哪邊)

* 讓fb帳號也能登入系統  -- (是什麼時候要完成?只要登入就可以,細節我們自己決定就好了嗎?還是要先看一下設計文件)






3. 務實的密集檢討事實



這可能是最重要,但最被台灣企業所忽略,也最容易被企業巫醫上下其手的地方。

可參考這幾個地方:(a) 錯誤檢討,(b) 自我反省,(c) Scrum檢討


「務實」:指的是根據事實來檢討,而非根據感覺。即便是需求檢討也是。

例如:某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊,這樣的要求讓專案經理非常不高興,覺得根本不合理也太不可思議。

如果不務實檢討,那麼每次與客戶的會議,大概就在針鋒相對中度過。但是探究事實,其實是因為該企業內部系統無法擺脫WinXP,而又因為WinXP能使用的IE就是IE8,導致客戶有此需求。就網站廠商來說,當然不可能協助內部全面升級為Win10,但卻可以提供其他在WinXP上,仍然持續更新的瀏覽器(firefox)。


「密集」:指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到,並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤,也會在一定時間內被發現。

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

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

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





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

11/14/2016

台灣博士生與大數據分析:如何評估對大數據分析的本職學能?



最近有個真實故事:



(為保護當事人,內容與細節均有所改變) 

台灣人F,目前就讀於某知名國立大學,已經是博士候選人。

最近為要爭取某一私立學校E的教職。在其履歷表上是以雲端計算大數據專家自稱。而E校的某系評會要求他面試15分鐘,用以評估他的能力。試教主題不限。

然而,F其實對大數據除了看過一些商管叢書之外,其實根本一竅不通。因此,他找了以前大學時候已經在業界工作的好友J,問了一些「技術問題」如下:

F:我聽說過spark,是不是大數據分析都用它啊?spark是不是個作業系統?

J:如果這是你的問題,那你壓根離spark太遠。後面就不要再談了。

F:哎喔,我覺得教學只是個演出啦,看表面而已。以你在業界打滾多年,就幫我個忙。couchbase是什麼?有什麼如果講出來會讓大家知道我很厲害的地方?

J:如果這真的是你的問題,你真的什麼都不懂啊,就算你去E校當教授,也是害了別人。

F:....



這個真實故事乍看之下太過駭人!但或許反映了學術與實務之間的鴻溝。

其實,台灣有許多學術界的人才,不但學術淵博,技術根底也厚。從數十年前的硬體產業蓬勃發展就可見一般。近幾年的軟體也是,許多教授幫業界「產出」能產生價值的知識性員工,並且也讓業界的知識持續推進。

然而,M型社會反映的層面,不指是一般在職場工作的人,在學術界中也越趨嚴重。

也有不少學術蟑螂。他們靠著極致的生存能力和夠厚的臉皮,穿梭在三流研討會,大企業策略部門,顧問性質演講,以及不在乎學生品質的大學院校中。

這些學術蟑螂做的事情,大概也不會真正傷害到誰,只是,也不會對任何人有好處。只要不是在「自己家裡」,一般人在路上看到蟑螂只會視而不見,也不太會去追打。

但是,如果是在自己家裡呢?

評估對大數據的本職學能,才能判斷來者是學術淵博的長者,還是費力在夾縫生存的蟑螂。如果是像E校一樣,原本的教授群並沒有這方面的背景,要如何在沒有足夠的知識情況下,判斷對方有沒有知識?這雖然有點難,但是,透過一些方式還是可以把誤判機會降低。



(1) 實際經歷探詢(情境實例面試法)


情境實例面試法很基本,但是事先有所準備。做法很簡單,只詢問「過去實際上」發生的事情,用以判斷被面試者現在的情況。而且絕對不詢問開放性問題!!

對於couchbase而言,就不會問「你對couchbase瞭解程度如何」或者「分散式資料庫你有哪方面研究」。因為這類型開放性問題,會浪費大家的時間。也會讓學術蟑螂有機會以混淆視聽的長篇大論,大打模糊仗來損耗面試者的判斷精力。


簡單問題像是:


* 請用1分鐘定義何謂nosql

* nosql的實作有很多,請舉一個你最熟悉的nosql平台工具,一個你實際最常用,最熟悉的就好(在此假設他回答couchbase)。

* 請問你實際接觸couchbase多久了?  (用判斷他最熟悉的工具有可能有多熟,如果少於6個月大概也等於是不太熟)

* 你利用couchbase為平台,撰寫並發表過哪篇論文?(學術界而言,沒有發表相關論文等於是沒有相關方面的研究)


稍微麻煩的問題像是:


* 你有沒有加入couchbase的任何相關的mail-list? (沒有加入mail list也沒關係,但表示其實只是單純的使用者,不會有太多深入的了解)

你利用couchbase為平台,撰寫並發表過哪篇論文中,所使用的研究資料量有多大?100G?10T?(資料量極小的nosql,並不代表不正確,只是代表不是大數據而已)

* 你用過哪些版本的couchbase(起碼要記得大版本編號吧)

* 你最近讀了哪一篇論文是以couchbase實作其研究?是大概什麼時候讀的,內容是什麼?


總之,事先準備好不能模稜兩可的問題,並且也定義好不能模稜兩可的期望回答。事先準備的問題也不需要太多,只要7-10提及可。這樣,比較不容易被蟑螂溜進來。並且,在準備的過程中,其實也會讓團隊(無論是學術還是技術團隊)對這方面的知識有基本的增長。


(2) 真實展示


簡單的說,就是請他拿一台電腦,展示一下他對大數據分析中最會「做」的事情。無論是撰寫程式碼,還是建立模型都可以。

真實展示其實很容易騙得過沒有相關知識的人。但是,如果事先已經提醒會有真實展示,可以簡單篩選掉連打開電腦都不敢的小蟑螂。

E校要求試教15分鐘,其實是真實展示的好方法。然而,盡可能展示「動手」而不僅只是「動口」。雖然君子動口不動手,但是蟑螂恐怕也是。


(3) 自我反省

當在一個地方看到蟑螂的時候,通常表示附近還有另外10隻蟑螂(也有人說是數百隻),只是沒看到而已。會有蟑螂來面試 - 無論是工作還是教職 - 是不是這組織已經有很多蟑螂。更重要的是,自己是不是其中一部分。

自我反省是極端困難的工作,對生活優越的自己,在心理上也不見得好過。但是,在陰暗狹小的地方求生存,總是比不上光明正大的貢獻自己的能力。

請謹記,「自信心」和「自我感覺良好」只有一線之隔。或許,透過實際經驗探詢,先自我檢查自己,才是去評估別人之前,真正自己應該做的事。