大綱

3/25/2016

資深與中高階人才選用:三個要點





在資訊科技領域裡,資深或中高階人才選用遠比找到剛畢業很有潛力的人來的困難重重。

詭異的是,幾乎所有已經在資訊科技領域工作7年以上的資深專家,通常多少都會遇到獵人頭(hunter)的引誘。事實上,中高階的職缺其實很少,由組織內部升遷的機會很大。然而,如果真的從組織外部尋找,雖然看似符合條件者眾多,但能有效媒合卻是難上加難。




要點一:情境實例面談


絕大部份的中高階人才之所以是「人才」,乃是根據其真實的過去事蹟。而非未來想像。

在書面篩選階段,通常是根據過去工作經歷,決定要不要請來進一步面談。

而在面試階段,卻常落在討論未來的理想和展望。的確,未來的理想跟展望,的確很重要。不過,在面試階段,要判斷此人能否實現理想和展望,應該是根據其過去的「理想與展望的實際產出」。

一般外商HR的實務操作方式為:面談時著重於情境「實例」。(SAR: Situation Action Result) 

例如,有個軟體研發部門RD主管的履歷表中,表示有帶領軟體開發團隊開發軟體。此時開放性問題無法真正展現該主管的經歷,應該採用情境實例問題,了解過去的「真實例子」。


-- 爛問題範例 --


未來取向的開放性問題:「未來你如何帶領開發團隊?」「你覺得RD團隊應該如何與業務團隊溝通?」....這種問題的回答必定是十分鐘不著邊際的長篇大論。



-- 好問題範例 -- 

初級情境實例問題:「目前你的團隊共多少人,其中有直接report給你?」「此專案你本人有參與寫程式嗎?」「此專案你本人有執行code review嗎?」「這個專案一共大約產生多少行程式碼?」

......初級問題著重能取得簡單而無可偏頗的答案,答案可能為「是或否」,可能是「數字」。回答應該是在10秒內。




中級情境實例問題:「在帶領N個人的團隊裡,你個人做過哪一件事情對團隊合作最有幫助?你怎麼做的?結果是什麼?」「在之前的工作裡,你做過最糟糕的決定是什麼?為什麼此決定是最糟糕?」

......中級問題著重於過去的某單一事實,必須引導回答針對這個人的實際作為,以及產生的結果。如果詢問的問題是負面資訊,例如犯下的錯誤。必須確定是問到犯下「最大的錯誤」。在面談過程,如果一個中高階主管,在過去7年的職業生涯沒犯任何錯誤(或者拿一些小小的失誤當作談話材料),很可能是隱藏事實,但更糟糕的是,他不覺得自己有任何錯誤的地方。


高級情境實例問題會和另外兩個要點:「本職學能」以及「獨立執行單位有關」請參考以下兩節。


簡而言之,SAR的基本概念很簡單:找出事實,而非空想;討論實際,而非理想;了解過去,而非未來。這部不代表理想與未來不重要,而是要判斷中高階人才的理想與未來,應該是看他「過去實踐過多少」,而非不是他「打算未來實踐多少」。


參考資料:(Careerly, SAR)





要點二:本職學能


已經位於組織中高階,很有可能早已不具備,或者喪失本職學能。因此,正確判斷是否具有合適的本職學能極端重要。

然而,中高階位階的人,其本職學能比較抽象,需要有方法加以判斷。

資訊科技領域的判斷方式有:(1) 基礎經歷 (2) T型延伸 (3)培育人才


(1) 基礎經歷:

以職業籃球為例,目前NBA的總教練,必然曾經在他人生的某個時期是「頂尖球員」,也許只是在NBA眾多明星中的候補球員,但也至少是NCAA某個第一級學校的球星。縱使不是,至少也是在高中時期,某一個州的的MVP等級球員。總而之之,他必然曾經當過明星球員,因此在當總教練的時候,能夠了解一整隊明星球員的思維,球員在比賽時的「真正作為」

同樣的,假設在軟體開發,找尋中高階的帶人主管,他本人必須「曾經是軟體開發人員」,最最最起碼也需要有3年以上實務寫程式的經驗。一個的SA或PM,也許工作的經歷還不錯,但如果沒有務實的寫程式經驗就來帶領開發團隊,就好像一個資深的球隊經理,看過很多比賽,卻沒有實際上打過球,就來當總教練一樣的危險。

或許有人會說,有些人屬於「將將之才」,他當將軍比當士兵還適合,不應該以過去的基礎經歷來斷定。在其他領域,或許是,但在資訊科技領域,「沒寫過程式」就是「沒寫過程式」。


其他的基礎經歷,必須有「清楚的事實」的佐證。例如,在履歷表上有AWS的使用經驗,就必須要清楚地知道何謂使用經驗?是用過EC2/S3/Route53,還是用過那數十個服務的哪些服務?是自己親自使用還是「指揮」別人使用?使用的規模有多大?等等


(2)  T型延伸

T型延伸的基礎是先有「基礎」,因知識與職責擴展的關係,延伸到其他相關領域。例如,在已經有智慧型手機應用程式開發的「基礎之上」,延伸到線上行銷,社群開發等等。

誠如前一節所述,沒有基礎,延伸不具意義。

關於T型人才,請參考這裏這裏

(3) 培育人才 

並不是每個人都會是好老師,不過如果中高階人才承擔的任務與管理有相關時,能否「培育人才」將會是團隊成功的關鍵。在SAR的方式裡要找到培育人才的方式很簡單。初級問題像是「你個人過去六個月以內,做了哪一件事情最能幫助團隊培育人才?」。中級問題像是「」




要點三:獨立執行單位


資深的工程師和初入社會的新鮮人最大的差別之一,應該是能夠自我成為一個執行單位。判斷是否已經成為獨立執行單位,是選才關鍵要點。


判斷的基礎方式有:(1)自我培養,(2) 計劃未知,(3) 人才培育。



(1) 自我培養

可以在組織裡,自行培養自己,發起並參與適當的事件。在中高階人才中,不存在「組織要協助培養能力」的情況。

這並不代表不用學習,只是不應該透過組織來建構自己的職業生涯和學習計畫。資深與中高階人才,應該要能自己規劃學習計畫,主動學習,並且「主動」將自我成長與組織成長「整併」。

僅專注在自我成長,對組織沒任何好處。努力使組織成長,放棄自己的成長,對組織也沒有好處。雙贏才是長久之計。



(2) 計劃未知

沒有人能預測未來。但資深中高階人才,應該能透過本身的技術能力,工作經驗,長久累積的直覺,有效看出至少數個月後的可能發展,並能有效制定計劃。

計劃(plan)本身並不重要,重要的是做計畫(planning)。中高階人才應該能在有限的已知情況中,盡可能計劃未來,建構真正的目標,評估控制風險。

而這計劃並不是為了展示,也不是文書作業,也不一定需要900頁巨作。關於計畫,請參考這裏


(3)人才培育:

請參閱前一節的培育人才。






3/17/2016

工作學不到東西:三個自立的方法



在資訊科技的公司裡工作的人,無論年資,大概常會聽到有人提到「在這裡學不到東西」「這個team沒有給足夠的訓練」「在這裡的發展有限」等等的牢騷抱怨。抱怨自然是人之常情,不過,個人職涯最終還是決定於自己。換言之,大部分的情況下:公司,環境,同事,工作內容...等等大概都不是「學不到東西」的主因。

任何情況下,都有以下三個實質的方式可以嘗試。


方法一:理解事實


任何事情,一開始都應該理解事實。

先確定是組織或者公司無法給予足夠的學習機會,還是自己沒辦法自我學習?假設沒辦法判斷,99%大概是屬於沒辦法自我學習的情況。

事實無好壞之分,事實只是單純的事實而已。然而,試圖了解事實有時候並不簡單。

一個剛畢業的學生,除非是高斯埃爾米特之類的天才,否則幾乎在任何組織裡,都有可以學習的事物。特別是在資訊科技領域裡,無論是正面學習,側面學習,甚至負面學習,在一段不長時間內(1-3個月)一定可以學到某些新技術,某些新觀念,某些應該避免的不正確的事情。

如何了解事實?可以試著問自己以下問題:

(假設處在一個軟體開發的組織中)

* 在這個組織裡面,所有相關技術你都能有效掌握?

* 組織中沒有人比你資深?

* 組織中比較資深的人,你都了解他過去的工作經歷?

* 目前組織中使用的程式語言,開發工具,你都已經徹底瞭解其優缺點?

* 目前整體開發過程的技術問題,都已經了解真正原因,並能務實地加以改善?

* 對於類似的軟體開發專案,類似功能的產品,都已經了解相較於自己團隊的優缺點,以及技術差異?

如果以上回答都是YES。事實就是這個組織真的無法讓你學到東西。不過如果有回答是NO,事實可能是你需要知道怎麼學習。




方式二:學習如何學習


請參考如何充實自己篇。

學習的本身是需要學習的。雖然每個人的學習方式略有不同,但提昇自己如何學習的能力,遠比把自己放在「可被教學」的環境來的重要。

簡而言之:花錢去上教學課程,在工作中有資深同仁可以帶領,參加各類型研討會...等等,這些雖然絕對益於個人成長。但是,「靠自己獨立學習」卻是一個難能可貴的技能。

而這項自我學習的技能也是需要學習。這衍生出看似複雜的問題:個人能否自我學到自我學習的技能?

撇除邏輯上的矛盾,找到適合自己的方式最為重要。若還沒有找到,可以參考如何充實自己篇。

舉個實際一點例子,假如你想學習作為一個好的軟體團隊中的QA,隨便在google或者youtube搜尋一下相關字眼,起碼可以找到數十個相關的教學文件甚至錄影。

認真花上幾個小時看完以下網頁以及教學錄影,相信你對這個主題肯定有某程度的瞭解。這都是僅透過"how to be a good software QA" 以及相關關鍵字搜尋得來:
1 http://www.guru99.com/software-testing.html
2 https://www.youtube.com/watch?v=sab0dblUpIE
3 https://www.youtube.com/watch?v=G5RpYi2dT04
4 https://www.youtube.com/watch?v=j8kY9txH2bc
5 https://www.youtube.com/watch?v=xCwkjZcEK6w&list=PLXXvO4OXeJrfbPrI0CV-re2VkdiV1dC7X 
6 https://www.youtube.com/watch?v=vimfiZZ4NI0&list=PLZTe0pWS8OYv3KYWJTZT_3chbtpXBoiOz&index=6
7 https://www.youtube.com/watch?v=OLayCNOPWIo

8 https://www.youtube.com/watch?v=hMfPCdF07hA






方式三:做出結果


資訊科技相關工作,特別是和軟體開發有關的工作,「學習」是很重要,但是「產出」卻更為重要。而產出就表示有具體的結果出現。

例如:這幾年data scientist相關話題非常熱門,有許多已經在職場2-3年的軟體工程師,常常會以這工作能否讓他有「data scientist經驗」為學不學到東西的考慮因素。

然而,其實特定技術領域,學東西最正確的方式,應該是自己能做出「某種結果」。

如果想要有data scientist工作經驗?有太多現成的「真實」工作經驗可以自行取得。

在大部份組織內部,都有很多無形產生的資料。這些資料,絕對足夠一個程式設計師學習以及做出學習的結果。

例如:

  •  程式碼版本控制系統(git, subversion, svs)。含有整個專案開發過程的「實質進展」資料,可利用他做時間序列分析,程式設計師個人績效分析。目前早有許多專案提供工具。
  • 組織的AD資料。正常情況下含有可供內部公開使用的資料,例如組織架構,人員變更。
  • Web Log。現在大部份的專案多少都使用HTTP,他必然會產生足夠大量的Log。一般Log分析工具(例如AWStats)已經可以做基本的資料分析,再配合machine learninig就可以做出各種有趣的結果



至於在組織外部,機會更幾乎是無窮盡的,也可以透過某些網站取得真實的資料,做真實的工作。例如:kaggle :在此有真實的專案,任何人都可以取得資料,透過自己的能力,完成資料分析專案。其他像是一般外包的網站:upwork.com也會有類似的工作,但可能不見得可以取得真實資料。

以結果為導向的學習,會比較腳踏實地,並且容易達到想要的效果。然而需要個人的興趣以及決心來支持。




參考:努力的三個迷思


3/13/2016

如何組成團隊:三個步驟





分工合作,是人類社會進步的主要原因之一,也是幾乎所有人類活動的基礎(參見國富論:第一篇第一章論分工)

新創公司,資訊產業也不例外,建立一個好的團隊,是擴展未來的主要關鍵。雖然好的團隊沒辦法保證生意蒸蒸日上,一切順心如意。但是一個糟糕的團隊,卻是可以保證企業和組織的失敗指日可待。


市面上團隊合作的企管叢書,方法論,激勵理論,顧問大師...很多。但就和所有的事情一樣,越是很多人在談論的事情,越是困難。成功的團隊真實例子極為罕見。

萬事起頭難,「組織並成立團隊」是達到成功團隊的第一要務。許多人常依賴運氣,或者隨遇而安的隨意組成團隊,但其實組織團隊是一種可以學習的艱深技術能力。

資訊相關工作的人,如果有機會能扮演組成團隊的角色,並有意識的學習其中,將會是個人成長的重要關鍵。(無論未來是朝純技術領導方向前進,抑或管理方向前進)


有很多原因,會讓一個人扮演組織團隊的角色。也許是一個新的專案,讓你來領導專案,而恰巧專案開始的時候沒有既定的人。也許你是新創企業的創始人,你打算聚集一些人來開發創新事業。也許你是資訊相關科系的學生,因為課程需要必須組織團隊完成專案。

不管如何,如果你有「從頭開始找人選人,組織團隊,完成某件事情的機會」,請衷心的痛哭流涕的感謝上帝,這樣的經驗,在資訊科技領域裡是十分難得。

通常,由於各種背景壓力,組成團隊的方式通常就是先根據需要N個人,然後「儘速」透過各種管道,找到可能的人選,經過正式面試,或者非正式的聊天,就逐一邀入加入此團隊。這種方式沒有不妥,只是這樣的方式(如果算是一種方式的話)有很大的成分依賴運氣。如果不想依賴運氣,其實需要考慮的實務步驟也不多。


以資訊相關工作為例,組成團隊必須要有以下三個步驟:


步驟一:定義目標

--- Your goal shouldn't be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs.   (MoneyBall)

定義目標,必須要在團隊開始組成之前,就先找到並且定義完成...最起碼是團隊差不多組成的時候就應該決定。

定義目標並不容易。

例如,以類似的資訊系統外包案而言,有些明顯的目標是「在成本內完成專案並驗收通過」或者「在期限內通過驗收」。但是,倘若一開始的合約是低價得標,而且還是業務亂搶合約,那麼一開始就已經知道不可能在時間成本內驗收通過。則團隊目標必須要轉換,例如「完成專案過程可順便完成重複利用的元件讓未來標案能大幅降低成本」。

大部分的資訊團隊真正的目標並非「技術達成」。例如,「完成iOS APP線上購物」這通常不是真正目標,真正目標通常是「在某移動通訊市場上,讓使用者可以線上購物」。

在營利企業裡,大部分的真正目標通常關聯到增加收入或者降低成本。而在非營利企業(例如研究單位)團隊的目標有可能非常模糊。例如,一個碩士班的實驗室團隊,他的目標可能是「培養人才」,也可能是「讓主持的教授獲得升遷的點數」。

定義目標雖然不容易,但掌握以下三點可以除去大部分的誤差:

(1) 定義目標後,審視檢查這個目標背後是否還有目標。例如,籃球比賽目標,某球員目標是得30分。但其背後還有個目標就是球隊要贏球。在球隊沒贏球的情況下得30分可能沒有意義。

(2) 定義目標後,檢視此目標是否只是某個大目標的一小部分。例如,某些NBA的球隊,會談論是進入季後賽的目標,然而背後的大目標其實應該是拿到總冠軍 - 無論有多艱難。

(3) 定義目標後,檢視此目標是否因為其他條件未達成就失去意義?這時候所謂「其他條件」或許可能是目標。例如,一個團隊負責營運線上購物網站,其目標是「網站每分鐘必須可以提供10萬個使用者同時進行交易,7x24服務不中斷不當機」。然而,若此線上交易網站平均上線交易人數每分鐘才1人,即便營運團隊達到技術目標,商業目標肯定無法達成,則此團隊目標也沒有太大意義。不如改成「與業務團隊合作線上行銷活動,讓每分鐘平均交易人數成長XX%」



步驟二:組合優勢


--- The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour. - (Adam Smith)

無論用什麼方式找到團隊成員,資訊相關的團隊必然有分工,而分工必須要能讓成員發揮相對優勢。而每個相對優勢,都可以達到步驟一的目標之一。

構成團隊過程可能很多,但無非是找到某人,詢問意見,在某時間此人加入。然而,「加入之後做什麼」著重於考慮組合優勢。

台灣經濟學的入門書通常會用蓋木屋與磚屋的例子(參見這裡)簡單的說,組織團隊時,把成員的時間投入在相對優勢的工作上,可以達到1+1>2的效果。

實務上,分工時請考慮一下三點:

(1) 根據相對優勢來分工:盡量只考慮優勢,而不是先考慮缺點。

(2) 分工的結果,還是必須朝「真正目標」前進

(3) 整個團隊需要了解分工與分派任務的原因 



步驟三:產生運轉動能

--- All things are difficult before they are easy.


團隊組織完成,要開始運作,不會像籃球比賽一樣,十個人在場上,裁判吹哨跳球就開始。

團隊前進需要累積動能。就像騎腳踏車一樣,從靜止到穩定前進,會花比較多力氣,然而一旦穩定前進,就很輕鬆。

產生動能指的是團隊成員已經彼此合作,彼此鏈結工作,發生問題也可以彼此協調解決。

以資訊科技為例:

最常見也是最糟糕的產生動能方法是由專案經理透過一連串的方式 - 通常就是開會 - 持續讓事情前進。團隊成員花在正式會議上的時間比例只要超過10%(也就是每週超過4小時)就屬於這種類型。


最佳,但是最罕見的產生動能的方式是由每個團隊成員,透過自身的判斷,做會讓事情前進的動作。類似足球或者美式足球的比賽。在資訊科技團隊中,這種組合需要時間磨合成員,而且也須一點點運氣,讓團隊的成員大部分的能力都可以足以某種程度的獨當一面。

如果你剛好是資訊科技/軟體開發的團隊領導者,至少要先避免最差方式,並且透過你的領導能力,讓團隊慢慢的朝向最佳的方式前進。

實務上有三個重點方式:

(1) 資訊透明:讓所有進行的事情透明的讓所有人取得。要注意,資訊透明指的是針對確定的事實透明。非確定的事實就是所謂謠言,要緊記:謠言止於智者,起於智障!

(2) Scrum中的豬雞原則:請參考這裡。在組織產生動能過程,豬負責的事情就由豬來決定,雞只是提供參考意見。

(3) 檢討 retrospective:需要團隊自我檢討任何不正確或可以強化的地方,檢討並非開批鬥大會,目的在於讓團隊能更有效率的,以及確保團隊真的朝向目標前進。