顯示具有 職業生涯 標籤的文章。 顯示所有文章
顯示具有 職業生涯 標籤的文章。 顯示所有文章

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年,應該是要檢討自己,而非檢討環境。





9/08/2019

如何指派工作 (軟體主管的31堂課)


作為團隊領導者,自然會遇到任務分配,指派工作任務的情況。軟體開發團隊也不例外,雖然敏捷式開發方式中的Scrum方法論,是希望在每個Sprint中採取「自己認領」工作,但其實極少有團隊可以完全做到這點。

指派工作任務最完美狀況是:團隊成員對主管有100%的信任,同時對組織中短期目標也有深切體會;並且都有完整的技術能力可以達成任務;而且所有人對於專案與時間管理都有經驗;而更重要的是,每個人都士氣高昂,迫不及待地完成任務。很遺憾的是,這種情況幾乎不會存在,好的軟體主管必然認知到的是,自己的任務必然是在於讓團隊成長前進,往好的地方邁進,而非期待自己「已經處於」一個完美的團隊。

如果你是個軟體團隊的主管,常常在夜深人靜時自己抱怨自己的環境與團隊,並且自認為委屈,那麼你就是屬於「期待自己已經處於完美團隊的主管」,這通常不會是讓事情變好的心態。

指派工作的方式看似很多,但重點只有幾個:

(一) 指定清楚的目標


指定清楚目標表面上很簡單,但主管自己其實需要考慮是這件事的真正目標,和指定任務的項目。

舉例來說,如果軟體主管指定任務目標為:「A工程師,請把某個AWS的一組VM,從micro升級到xlarge。」這看似清楚目標,但升級機器,必然不是目標,升級機器要達到的結果才有可能是目標,更有可能的是結果後的結果才是目標。

例如,稍微清楚描述目標:「A工程師,我剛收到通知明天由於行銷活動,我們網站流量應該會暴增,為了讓我們能處理高流量,請把某個AWS的一組VM,從micro升級到xlarge。」

但是,更好的方式其實是,清楚目標先指定,然後再討論出來。例如:「A工程師,我剛收到通知明天由於行銷活動,我們網站流量應該會暴增,為了讓我們能處理高流量,我們在AWS上的各種VM和使用的服務,有需要做哪些改變呢?」

當然,目標本身一定要涵蓋作法/行動。沒有具體行動的目標也沒有意義。

(二) 時間視為最重要衡量方式


時間是衡量所有事情的最重要的方式,在清楚指定或者討論目標作法之後,所有的行動必須以時間為衡量方式。而時間除了長度,還有實際完成時間。

例如:「A工程師,根據我們剛才討論結果,我們需要升級所有120個VM,這需要2小時,並且是在後天早上10:30am之前完成」

(三) 寫下來!


指派工作的另一個重點在於,所有任務指派一定要文字化或者圖形化,即便是很簡單的瑣碎小任務,也應該用一張紙寫下來。現在專案管理工具其實很多,例如JIRA。當然也可以用它來指定所有任務。


9/06/2019

如何建立信任關係 (軟體主管的31堂課)


一個好的主管,會讓其團隊成員高度信任,在軟體開發團隊中,如果主管可以有效地和團隊成員建立健康的信任關係,就容易達成三贏效果:對企業有利,對團隊有利,也對個人有利。相反的,如果團隊主管不受信任,那麼組織內部就容易內耗,很容易就形成三輸的情況。普通的團隊則是部分成員信任團隊主管,部分則不太信任,主管意識到這點,其實是很有改善的機會。


何謂信任?


信任並不是說團隊成員要變成主管的莫逆之交,在危急的時候就算赴湯蹈火也都在所不辭。當然可以達到這點很好,但在企業團隊內是不太可能。所謂信任是指,團隊成員對主管決策方式以及最做事方式,有預期感,並能相信這樣的決策和做事方式,即便自己不了解,甚至不完全贊同,也願意有效的合作。

如何建立信任。有些事情對於建立信任的雖然有一點點幫助,但效果有限,例如典型的團康活動。有些事情則是對建立信任有決定的影響:


(一) 傾聽了解個別成員:


信任是「個人」心理狀態,因此,有效地傾聽個別成員在組織的需求,針對個別成員的需求,量身定做互動的方式。

傾聽的重點在於「傾聽」,中途插話,表達太多意見都不是傾聽的要訣。



(二) 共同接受並完成工作上的挑戰:


這和傳統軍隊建構團隊的方式雷同。一小組人一旦一起面對挑戰,並且度過挑戰,就容易互相信任。在經歷生死戰場的退伍軍人戰友,特別容易建立長期的信任關係,就是因為如此。
當然在企業環境大概不會有生死攸關的情況,但仍然有許多挑戰。好主管的要務在於對挑戰的本身必須要是正面看待,

例如:在跨國企業中研發團隊總是對某國家的另一些工程師作法相當不認同,並常在討論中發生意見衝突。團隊常常對主管抱怨狀況。不適任的主管在此最容易做的事,就是一起跟著抱怨,並且將責任歸於其他人,試圖在團隊塑造共同敵人,這樣短期團隊成員或許會開心,但是衝突並不會因此解決。一個好的主管,會將這狀況是為共同挑戰,讓團隊成員明白如果我們可以一起解決這樣的衝突,不但對組織有好處 - 可以讓跨國團隊更有效工作,對自己也有好處 - 在履歷表中就可以多一項很難得的成功經歷。


(三) 建立一致性:無論任何事情的好壞


建立一致性是在不公平的社會環境中,讓團隊成員認為主管會公平處理事情的最有效方式。所謂的一致性,倒不是指不能改變作法,而是指作法本身有可預期的一致性。

例如,在營運團隊中常常有假日需要輪值的情況,最簡單的方式是直接按照姓名或者到職日期,輪流安排成員在假日值班。表面上看起來是最最公平,實際上有可能是公平,但也有可能不公平,因為每個人上班期間的工作內容可能不同。一致性並不是說不應該輪流值班,而是指輪流值班的班表如何取得共識。例如,每次班表都是每3個月前產生,產生之後,會在兩週內先逐一詢問個別的需要,個人的需求被滿足後之後,在隨即email公布並詢問有沒有需要調整,並且在一週後正式啟用此輪班表。幾次之後,團隊成員對主管的做事方法就有一致性,知道主管在困難事項一定會先詢問個人,調整每個人狀況,還會在所有人面前再度公佈一次,然後再做最後調整。

這樣一次一次建立一致性,無論事情的好與壞,也無論主管個性,就容易建構工作上的信任關係。




9/04/2019

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


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

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

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

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


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


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

困難點在於每個人的激勵因素都不同,一般認為,軟體工程師會持續激勵有高績效產出「可能是」因為:
(a) 完成程式執行順利時候有種滿足感
(b) 自己也能夠學習成長
(c) 團隊溝通順暢協作愉快
(d) 強烈認同組織目標
(e) 對團隊有影響力 能夠被人認可
(f)  ....其他...(家庭之類)

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

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

二:根據需要,量身訂做能做的事情

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

這點有空會再說明一些實質作法。

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


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

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



9/03/2019

如何提昇士氣激勵團隊成員 - part1 - 幾件千萬別做的事 (軟體主管的31堂課)


幾乎所有主管都知道,一個技術能力不錯,且士氣高昂,充滿鬥志希望,正面能量強的團隊成員,幾乎必然帶來高績效的結果。並且,他對團隊的貢獻,鐵定遠遠大於一個技術能力超強,但是士氣低落,充滿抱怨失落,厭世能量強的人。

軟體開發主管最難的地方莫過於激勵團隊成員。因而,能否再困難的情況下激勵團隊成員,就是優秀主管和普通主管的最大差異。

有幾件千萬不能做的事情:

(1) 單純使用薪資福利激勵團隊成員


只要是人都喜歡越來越高的薪資,越來越好的福利。但薪資福利是典型的「保健因素」,利用薪資福利短期或許有些微效果,但長期一定沒用。最糟糕的情況下,高薪資福利會留住成員的身體,但靈魂早就不再貢獻於組織。對團隊其實有更大的傷害,因為如果單純只為了錢留下來,就一定會精算如何在最最少的貢獻下,拿到最最多的利益(參見:公務員官僚體系)

合理或者略高的薪資福利當然是最好的。並且也是不可或缺,然而它只會是保健因素,絕不能當作激勵因素。

(2) 樹立共同敵人


有些主管會試圖建立共同敵人,或許是其他部門的人,有些甚至是同個部門的其他同事。主管透過和低落的團隊成員,一起批判別人一起抱怨,表面上看似同仇敵愾,其實是飲鴆止渴的做法。

這聽起來非常普通,但是,在企業組織卻很常看到主管無意中做出「樹立共同敵人」的事情。主要起因於人類一開始作為群居動物,對抗共同敵人就是群居動物的本能,原始人群居成為小部落,分工合作對抗毒蛇猛獸與惡劣環境,會讓所有人的生存機率大幅提升。現代商業社會發展不過也才不到兩百年,要抗衡超過10萬年的人類演化習慣是需要一定的主管個人知覺和意志力。

(3) 瑣碎的微觀管理


所謂micro management (微觀管理) 是指主管重視各種支微末節,會透過枝微末節的檢核來判斷與採取行動 - 而這個檢核可能和工作本身無關。最最簡單的例子就是組織規定早上9點上班,主管一看到有人9:10才出現,就會主動前往詢問。

根據工作的形態不同,微觀管理其實在某些情況下非常適用,典型的例子是傳統軍隊,或者勞力密集度高的產業。

然而,軟體產業鐵定不能使用微觀管理,軟體開發相關工作,其實有極強的自主性,每個人的產出不可能像生產手機一樣在最末端測試所有該有的東西,這些自主性,會決定整體團隊績效的好壞,主管即便不能提高自主性,也千萬別降低高績效人人自主性。

要注意的事,作為主管其實應該能清楚理解code review並不是一種微觀管理,優秀且高績效的人才通常喜歡「被code review」同時也喜觀「review別人的code」。如果你不能理解這件事情,表示你大概不適合擔任軟體研發的主管。




8/27/2019

如何處理員工離職 (軟體主管的31堂課)


無論如何,主管一定會遇到離職的情況,因此,事先計畫離職處理是軟體主管必定要做的事情。執行上大致上分為三個階段:一:慰留決策,二:離職程序,三:事後檢討。


案例:B是一個資深的QA,在開發團隊裡擔任許多重要任務,與此同時還負責管理在印度的測試外包團隊。某日B突然告知,有個新創團隊找他擔任QA主管一職。由於B的職涯規劃是希望朝主管職前進,因此對他而言此機會非常難得,錯過這次也不知道何時能再有這機會,因而提出辭呈,離職時間希望是三週後。


一:慰留決策


當接收到離職訊息,第一件事情其實是評估現況。這位成員現今是否適合團隊,並且有很大貢獻?如果是的話,那麼就應該慰留,如果不是,則應該迅速答應並且直接進入離職程序。

請謹記,考慮是否慰留,僅只需要考慮此人適合團隊與否,及是否有很大貢獻。並不是要考慮「他現在手上工作很多」,也不是要考慮「沒人交接很麻煩」,也不是要考慮「現在A專案要是有人走,會對進度造成影響」。倒不是說這些不重要,而是短期因素不能影響長期決策,如果他沒有要走也就罷了,但是一個剛好不那麼適任的人要自己離開,等於是天上掉下來的禮物。

案例中的B明顯是屬於需要慰留的情況。

慰留可以做的事情是:提供主管權限可以提供的任何方案,特別是應該要和B一起討論「如果有什麼事情發生,你就會打消辭意」。討論的本身必須針對「能近期發生的事情」,就事論事才有機會。

慰留不能做的事:不能答應任何自己也做不到的事情。以案例中B的情況,他想要往管理職方向前進是非常好的事情,但公司如果很明顯在未來6個月不可能有此機會,則就不應該答應升遷的可能。慰留也不能當作「拖延離職時間」,任何拖延對大家都不利,因此設定慰留期限是很重要的,頂多2-3工作天已經綽綽有餘。

大部分高績效人才的慰留機會其實相當低。主要原因是高績效的人才通常對事情想得夠清楚才會提離職。


二:離職程序


當提出離職無法慰留後,當下就進入離職程序。主管無論對團隊有多麼強的信心,都應該在建立團隊的時候,先行建立離職程序有備無患。要謹記的是:這裡所謂離職程序,並非HR的離職手續,離職手續僅為文書作業,只要遵循HR的規範即可,但離職程序是要確保對組織的衝擊最小,對現存專案的影響最低,並且讓團隊更能成長。這只能由主管來設計進行。

離職程序最重要先有的事情是最後上班日。雖然說勞基法對最後上班日有規定,但仍然可以和離職的人討論。

以人才為主的軟體公司,其離職程序的管理與執行,絕對不能由「要走的人」執行,而是由「要交接的人」執行。即便我們已經知道要離職的人是個好人,也知道交接的重要性,樂於幫忙任何事情也一樣。主要原因是事情的目的必須要和個人方向一致,即將離職人的方向絕對和現存的人「不一致」。

如果你作為主管還沒設定離職程序,可考慮如下步驟

(1) 確定離職時間 例如3周後
(2) 列出目前工作清單, 列出目前擁有系統權限清單, 列出目前硬體資產清單 電腦等等
(3) 與團隊討論出負責交接的主要負責人,有時候也需要特定工作交接負責人
(4) 設定hands-off day (預計是離職前一週) :在這天之後,離職人仍然要上班,但只需作為顧問任務,工作都是交接人來進行
(5) 設定交接目標與時間,直接約好交接的教學會議:交接必須是交接工作內容,而非交接技術知識。交接會議必須要專注於現況,而非未來。
(6) 每週至少設定兩次檢查會議,檢查會議只需要10分鐘檢查交接現況。但要注意的是hands-off day之後檢查會議就不應該讓離職人參加
(7) 設定離職人的文件轉移,必要時需要繼續撰寫文件
(8) 倒數第一天:將硬體資產點交
(9) 最後一天:取消系統權限,歡送會
(10) 離職後2周內:事後檢討


三:事後檢討


是否有效的進行事後檢討,是好主管跟普通主管在處理離職的「最大差異」。

高績效人才通常也是重視溝通合作與人際關係的人才,因此不見得會在離職理由上說出實情。然而,探索實情,「正確」調整領導管理方式,以及「正確」調整組織結構會是事後檢討的重點。

(1) 探索實情

統計數字不會騙人,請自己google看看「離職原因統計」,可以看到許多統計數字都指出,離職理由和主管有很大的關係。如果你是主管,對於高績效員工離職,切勿以其他的方式糖塞欺騙自己。要能夠避免這件事情,在探索實情時,必須直接假設「自己就是問題的一部份」:無論你覺得自己有多好。

常見的藉口有:

* 外部拉力:他找到更好的發展機會 我們無法提供
* 有限資源:我們公司資源有限 已經給他很好的薪資福利但他還是不滿
* 內外部歸因:我覺得他自己個性有問題
* 往上推責:最上層主管做事風格讓我難以處理

(2) 調整領導管理方式

檢討大部分的時候結果是都要調整領導管理方式。不見得是大幅度改變,可能只是些微做法調整。但簡要的說,高績效的離職如果不做任何調整就幾乎等同自己騙自己。

關於調整方式有空會再多解釋一點。

(3) 正確調整組織結構

有空再針對這問題解釋多一點。簡要的說,以案例B而言,他想要往主管職前進,並不代表公司應該要產生很多「主管職位」來應變未來眾多人想要擔任主管職的情況,正確調整組織結構並不是直接反映離職人的期待。




8/25/2019

如何讓一對一面談變得有用! (軟體主管的31堂課)


做為軟體相關工作的主管,固定和自己的團隊夥伴一對一面談,在外商俗稱 one-on-one:是絕對不能省略的事情!如果無法和自己直屬部屬(direct report)每個月至少一小時的懇談,那麼絕對無法有效的激勵與維持團隊。


案例:C是在大公司的資深工程師,他常常跟我抱怨他的主管不了解情況。而由於該公司是有規定主管需要跟團隊成員固定one-on-one,所以我自然就問「你不是有跟他固定one-on-one嗎?」,C則回答「是啊,但是那也是聊聊天而已,改覺反應什麼也不會改變」


作為主管,要避免上述案例發生,一定要知道如何有效率的進行one-on-one並且讓他變得有用!

如果你的直屬成員超過10人,一對一面談反而更不能忽略或省略。如果你的直屬成員超過15人,那麼你的現行組織必須分層或者分開,除非你的組織是「人力導向」而非「人才導向」否則,超過10人的直接管理已經是極端困難,超過15個人是幾乎不可行。有些主管會驕傲地說,我的直接report-line有35個人,通常這樣的主管已經默默地分出階層,會找尋team leader來取代主管的工作,而大部分的時候team leader才是真正的主管。

一對一面談(one-on-one, 以下簡稱1-on-1)主要的目的有幾個:
1. 了解該成員的士氣情況
2. 了解該成員工作上是否遇到困難
3. 了解是否有需要處理的人際問題
4. 給與成員過去工作表現的精簡摘要:做的很好,或者做得還好,或者做得不好
5. 讓成員給自己回饋


一般來說,1-on-1不應該用來解決「技術問題」,技術問題應該是透明解決,而非兩個人私下解決。除非團隊人數剛好就是兩個人。

1-on-1的推薦作法:


一:固定架構與取得事實優先


當談話有固定架構時,部屬在每一次談話自然就有期待,以及自然地提供所需要的資訊,而這些事實資訊就反映到一對一談話的目的。

所謂固定架構很簡單,就是鎖定2到5個基本問題,這些問題是取得事實,並且應該很快可以回答。舉例來說:

(a) 請問你上次1-on-1到今天為止,有沒有遇到讓你很生氣的事情
(b) 從現在到未來2個月內,你有離職的「打算」嗎
(c) 今天有什麼事情,是你認為我要馬上去做的
(d) 從上次1-on-1到今天為止,你覺得工作開心嗎

這些問題都可以簡要的了解此成員的現況。重點是要用張簡單的紙長期追蹤這些問題。

二:自由討論時間以傾聽為主,下次必定追蹤!


固定問題需要紀錄,自由討論時間更是需要傾聽紀錄和追蹤!

自由討論當然以傾聽為主,在團隊成員還沒徹底講完,只做記錄千萬不要打斷。在結尾時,要說明你記錄了什麼。如果是組織做的事情好壞,公司目前現況,專案進度等等相關的,不用在1-on-1之間有結論,但一定要能夠紀錄,並且承諾會重視他講的所有事情。

重點在此!下一次1-on-1必定要重述他曾經重視的事情。並且,說明這些事情目前的現況,同時也和他討論這些事情對他現在還重要嗎?畢竟很多時候團隊成員只是需要抒發心情,並不真的重視這些,他們可能更重視的是「主管有重視」而已。

三:陷阱!不要做這些事情!


請注意以下陷阱!

1. 千萬不要和團隊成員一起抱怨公司政策,或者一起抱怨某個公司員工或主管
2. 絕對不能承諾無法100%達到的事情
3. 傾聽抱怨是應該的,但導向抱怨成為可執行的行動是最重要的一步
4. 切勿打聽A成員對B成員的個人看法!但可以詢問A成員關於其他員工某個特定時間點做的某件特定事情。
5. 1-on-1必須要有自己的筆記,千萬不要忽略紀錄


8/24/2019

加入新創後 如何建立團隊 (軟體主管的31堂課)



當你有機會加入一個新創公司,並負責建立某個軟體開發團隊,無論是哪種類型的團隊:QA,手機研發,維運,前後端... 你會面臨比想像中還要困難,但其實更有趣的挑戰。要達成這個任務,首要(一)先了解現況,其次(二) 對現況做短中期規劃,並且(三)依照情況定時調整方向。要注意的陷阱是:(a) 建立團隊不是憑感覺或過去經驗,而是憑計畫與努力 (b) 計畫和努力的投入是必然的,無論是2個人的小團隊或者39個人的組織 (c) 在不必要的壓力下更換人才選用策略


案例:

S是有10年工作經驗的QA,有1.5年的QA manager經驗和3年的QA lead經驗,曾經在兩個小型新創公司工作。因朋友介紹加入一個香港商新創公司,負責在台灣建立專門針對手機應用程式的QA團隊,這個團隊已經有2個不同經驗的QA。



一:了解現況


S應該要做的第一件事情是了解現況。
在還沒加入團隊之前,應該盡其可能列出各種大小不同的現況事實,並且針對事實在「還沒加入」之前釐清未知的現況。如果你無法在這階段列出20個關鍵問題,很有可能表示你對建立團隊的本質不夠瞭解。當然並不代表一定會失敗,只是代表成功與失敗本身有極大可能是靠運氣。

典型一定要知道的事實:

1. 這個職位是新開設,或者因前任離職而在找尋找替代者?
2. QA團隊預計在3-6個月內的團隊大小為何?
3. 其他團隊規模多大,公司規模目前多大
4. 直接主管的管理方式如何?
5. 直接主管本人最近3個月的加班情況
6. QA主管在未來3個月要達到的目標,未來6個月要達到的目標

常被遺漏的事實:

1. 權限:在招募QA上,能擁有多少權限?能決定薪資嗎?薪資上限為何?
2. 獲利容忍時間:新創團隊一般都有資源壓力,在未來6個月,如果沒有損益兩平,投資人仍然會持續投資?
3. 現有兩位QA團隊成員無法升任QA主管的原因為何
4. 公司對技術人員的選用是否有成本考量 :如果現存軟體開發人員與QA人員大部分都是5年以下工作經驗,絕大多數情況是有很嚴峻的成本考量。
5. 公司對技術人才的選用以「先趕快進來,有人再說」,還是「選到適合的人才比較重要,願意等」。要謹記的是,這兩者在新創公司是無法並存。
6. 技術團隊過去6個月的離職率,過去12個月的離職率

類似上述的事實起碼可以在列出另外10個。而在面試階段,如果公司無法全部清晰正面的回答所有問題,並不代表這公司不好,只是代表變數和意外很多,在你的計畫中,需要控制與應變這些變數。然而,如果這些問題,有50%以上或者更多事實是模糊回答,那麼非常有可能新創公司的管理階層也都是沒啥經驗的人,加入這樣的團隊不見得讓你的管理經驗和知識能夠持續成長。

要記得,在這個階段是考慮事實回答,而不是事實的好與壞。舉例來說,如果有事實回答是:「未來6個月損益沒有兩平,投資人就失去耐心公司會倒閉」。那並不代表這不是好公司,而是代表6個月損益兩平是目標,所以這其實是好回答。但如果你獲得的答案是「只要我們大家都會努力做好自己的事情,未來六個月就一定會賺大錢」這是危險的模糊回答。

針對還不知道的事實,最好建立「無知清單」,也就是Known Unknows 而在加入的前期自然會對這些無知項目有心理準備。

(二) 對現況做短中期規劃


如果已經了解事實現況,就應該進行短中期規劃(0-3個月,以及3~6個月)。

短期規劃必須清楚具體。主要目的是確保與組織方向一致。並且列出還不清楚的事實,確保在到職的前三個月可以弄清楚。

舉例而言,該QA Manager的短期前4週計畫如下:

第1週:透過確定下列問題來瞭解公司環境:(1)確定未來三個月可招募的QA人數和經費,(2)(2)確定自己是否能確定薪資 (3) 確定能否招募比自己薪水高的QA (4)可否透過獵人頭 (5)是否有招募經費。透過與現有成員一對一面談了解目前個別成員最大的問題。透過和自己的老闆一對一面談確保期望一致。

第2-3週:建立面試流程。透過與開發人員面談,了解現在QA與RD的合作方式。了解目前品質管理相關系統(例如JIRA, testrail)。固定與主管至少每週一次面談。不管現存的測試方式好與壞,都先確定自己可以執行現有的測試案例。

第4週:透過直接與主管的檢討會議,確定自己的成效和主管期待一致。預測可招募到的新人到職時間。

計畫的本身最好不是用像上述的文字描述,使用mindmap展開概要是最好的方式。

(三)依照情況定時調整方向


加入之後,每週應該檢討計劃是否能被執行。

檢討是為了自己的計畫,可以自己檢討自己就好。檢討的方向有兩種。計劃不如預期,以及發生或者知道額外事實需要修正計畫。

(1) 計劃不如預期

例如,預期在第3周能夠執行現存的測試案例,但是到了第3周仍然無法達到。自己一定知道原因,就要針對原因來處理。是因為自己對產品不了解,抑或這些測試本身就過於複雜?

(2) 發生額外事實,需要修正計畫

這其實是最常發生的情況,也是最能考驗到創新公司的新主管的情況。如果在到職之前能羅列的問題越多,發生不受控制的「額外事實」就越低。因為你既然事先知道了,就能有所防範與準備。

舉例而言,事先如果知道你無法決定新招募的QA的薪水,則招募流程就必然要讓「能決定薪水的人」參與。換言之,作為招募你的意見主要是決定NO,而非決定YES。既然事先已經知道了,就容易建構適合的流程。然而如果事先並不知道,而且也不再你的無知清單中,一旦發現你無法決定薪水,除了心理會略有不爽之外,你能夠調整適應的時間也大幅縮短。

因此,這階段是要處理不預期的未知(Unknow unknows)。一旦不預期的未知發生,必須要先分類嚴重程度,然後確實處理「嚴重的」,不應該是處理「容易的」。舉例來說,如果不預期公司其實是要快速有便宜的QA人力,大量手動測試就好,如果你覺得這不是正確的方式,就應該優先處理此事。

避免陷阱?


有興趣知道如何避免以下陷阱?還請留言或email (support@talent-service.com): 

(a) 建立團隊不是憑感覺或過去經驗,而是憑計畫與努力 
(b) 計畫和努力的投入是必然的,無論是2個人的小團隊或者39個人的組織 
(c)在不必要的壓力下更換人才選用策略(例如CEO說要不要早點有人進來)


3/17/2019

自我感覺良好的能力不足: 預防與解決之道



在軟體開發團隊的招募中,技術能力當然是不可或缺的一環。候選者如何自己評斷技術能力,也許和如何評估候選者的技術能力一樣重要!

換言之,謙虛的人比自我感覺良好的人,可能實質上的能力更好。這在「達克效應」中說明得十分清楚。

達克效應簡單的說:是指能力不足的人通常會高估自己的能力 無法正確判斷自己能力的不足。不過經過提高能力之後,是可以認知到過去能力不足的事實。
這個理論雖然廣為人知,但真正去證實的人很少,因為大家總是覺得很合理,

該論文研究分為四例,無論是哪個例子,結果都類似下圖(註1)
本圖取自論文:Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments
該圖是取自研究案例二,研究者讓所有受測者考一個邏輯考試,這邏輯考試取自於美國的法律學校入學考(LSAT),主要看一個人的邏輯思考是否完整,有興趣可以參看這個網站

當然考試不是重點,考完試之後,將結果分成四組人,最差的就是bottom,最好的是Top。所以在上圖中,很明顯bottom組的結果當然是在最下方。但有趣的是在於,最爛的一組,在預測自己的成績與能力,卻是和實際上差距很大!次佳組(3rd)其實實際成績和自我預測最接近。而成績最好的那組,反而感覺非常「謙虛」!?是唯一反而預測自己考得不好,同時也自覺的不好的一組。但實際上考的成績卻是最好的。

研究有四個案例,考試的範圍跟內容各有不同但結果很一致。

這篇論文,雖然很直觀,但寫得有點幽默,所以竟然還得了搞笑諾貝爾獎,細想其實很有啟發性。尤其在組織中,員工的自我感覺良好是績效評估產生問題的最大因素之一,那麼在組織中有什麼樣的解決方式呢?

預防的方式:招募時的預防


尤其是軟體開發團隊,招募一個謙虛的人,比招募一個很有自信的人更容易找到真正有能力的人。倒不是說有自信是不對的,但自信心往往容易落入低能力的範圍(請參見上圖)。

要判斷自信與能力最簡單的方式有兩種:一者,就是根據過去實際的產出內容來衡量,例如詢問他過去工作中,實際上做了什麼事情,導致於貢獻的產生,而不是只問了貢獻的結果。其二,設定簡單的測試環境,例如直接在白板上討論演算法問題。

解決的方式:衡量產出而非能力

絕大部分的企業組織都知道,衡量員工的績效乃是基於產出,並非能力。當然,能力好的人自然有機會有更高的產出。

在軟體開發團隊中,衡量產出極其困難。每個團隊幾乎都因人而異。有幾個方式倒是可以適用於大部分的狀況 
(1) 員工自評,並且加上3位以上的同僚互評。
(2) code review
(3) quality

由於最近比較忙,關於產出的衡量有機會再寫。:)



------
註一:本圖擷取自該論文本身:https://pdfs.semanticscholar.org/e320/9ca64cbed9a441e55568797cbd3683cf7f8c.pdf

12/23/2018

軟體工程師的職稱頭銜重要嗎?



軟體工程師根據所在的環境不同,通常有不同的職稱頭銜。例如:程式設計師,工程師,技術經理,架構師,策劃工程師,平台工程師等等。對應於英文可能會有:programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中,升遷可能是職稱上的轉換,例如在前面加個「資深」,大家就都知道你被升遷了。

對於轉換新的工作來說,職稱頭銜是否重要呢?

1.以工作的本質來說不重要


就技術為主的軟體工程師來說,(假設並沒有直接負責管理員工),職稱頭銜幾乎不重要,更重要的是做事情的內容和能力的展現。

假如在一個組織裡,一位新進員工的職稱是「sr architect資深架構師」,但他的工作內容實質上是對客戶提案,撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作,通常還是評估實際做的事情為主,並非職稱。

2.以團隊角度來說可能很重要


職稱是公開的,一個團隊組織裡如果有工程師,資深工程師,資深架構師這三種不同職稱的人:一般來說,大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟,職稱的功能有時候類似制服,當你在路上看到穿著警察制服的人,在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而,就軟體開發組織成長來說,職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係:團隊貢獻中,絕大部分的人會認為自己佔比重比較大,因而,在決定升遷或者其他公開獎勵時,一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中,大部分的人會認為自己佔比重比較大:許多實驗(參考這裡)都說明,假設一個團隊的總貢獻是100分,有10個人自己評估自己佔的比重,並且加總起來,很容易就超過150甚至250,但這實際上是不可能的。

也因為大部分的人都有這種偏誤,導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會,可以採用「無職稱」或者「自選職稱」的方式。


3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時,無論是中期還是短期發展,組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織,對團隊成員,甚至對組織外的人都有好處:

- 對組織的優勢


在組織內,成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」,而非「職稱頭銜」決定自己「做出的事情」。自然而言,團隊成員就會以提高自己的能力和對組織的影響力,並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密,再也不會影響其他人的心情。

當組織要招募人才時,組織會更專注於了解應徵者「過去做的事情」,而不是過去有的頭銜職稱。過去我們面試的時候,常常在履歷表中看到非常驚人的頭銜,但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高,錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時,在他對外面試的時候,很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明,團隊成員專注於工作的本身而非頭銜的表面公平性不足時,更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時,更容易專注於尋找人才得要件。換言之,本來評估能力和是不是適合,本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試,就更容易避免錯誤。









10/19/2018

企業巫醫:就業大環境不好的問題該如何解決?


曾有一次面試某碩士畢業社會新鮮人,他說:「許多企業找碩士實習生,都是讓他做高中生能做的事情」。

然後詢問說那麼為什麼大學或碩士在學的學生,願意去做這種高中生會做的事情的。畢竟,在台灣決定選擇實習也是學生的選擇,並非被強迫的。他的回答是:「大環境的問題,市場情況,不能怪學生,他們很多都涉世未深,不知道這些工作沒學習成長。既然是實習,企業就應該有"習"的部分。現在大環境是這樣,並不代表這樣是對的。」

接下來又再請教他,如果你是企業主,這些實習生比較無趣的工作,如果不找碩士實習生,應該找誰來做,他回答是:「可以找私立大學的學生」

其實觀念無所謂對錯,對於這位新鮮人的想法,每個人大概都有不同的解釋。然而有件事情倒是很重要,當環境不好的時候?應該要什麼方式解決?


(1) 個人永遠都有選擇



相較於生在阿富汗,敘利亞,烏干達之類的戰亂地區,大部分的台灣人都有選擇。特別是如果你上網看到這篇文章,就表示你能上網,同時也就表示你可以取得的資訊知識範圍遠比任何30年前的人多幾億倍。

當然,選擇多寡因人而異,但是當你心裡想著:「好像只能這樣」或者是「我這樣的背景就很找到更好的」或者是「不知道該怎麼辦」的時候,也許應該更廣泛的思考有哪些選擇。

有經濟壓力(貸款,家人等等)的時候選擇是比較少。大概不可能離開一個自己很不開心的工作,畢竟還是需要收入。但你仍然可以選擇「自我學習」。

為什麼要「學習」?很簡單就是因為要增加選項

(2) 如何增加自己的選項

不可否認的是,祖上積德的人,一出生選項就比較多。然而,選項少的人也不應該因此唉聲嘆氣。與其花時間抱怨大環境,不如花時間增加自己的選項。

最簡單,而且最沒有成本的是:到公立的圖書館借書,透過閱讀來增加知識。擺脫經濟壓力的最重要的關鍵,而且增加選項的關鍵應該是自己的知識和技能。




不過,學習知識技能也有不同的方式。有些學習時間長,有些較短。舉例來說,如果你突然之間想變成醫生,那麼至少也得花上7年,而且重讀醫學院幾乎是唯一可能。但如果你想成為一個手機遊戲專案經理,卻是有可能從零開始:先主動自願參與手機遊戲測試,再主動閱讀和QA有關的書籍,並開始投遞遊戲測試工作,例如這裡。透過變成遊戲產業的一份子,逐漸增加自己的知識能力...這樣確實是可讓沒有相關技術背景的人,進入遊戲開發的世界。

其他自我學習的議題可以參考這裡


(3) 不要自我設限的方式

許多人會自我設限,而自己限制自己,是無法面對大環境的其中最最最大的原因。
自我設限的情況例如:

「這個是某部門的人負責的,所以我就不想碰」
「我英文不好啊,所以就不考慮外商的工作」
「家裡有固定開銷,所以沒辦法亂換工作」
「我本來就不會讀書,不喜歡讀書,看到書就想睡覺」
「不知道怎麼開始」
「我就只能先這樣,不然也不能怎樣...」

這些即便都是事實,也對自己沒啥幫助。

然而,想要突破自我設限,最根本的方式是從累積「短期,有成效的事情」開始。例如,英文不好,就買本哈利波特1的英文版,每天花15分鐘讀一頁。累積習慣之後,再開始增強聽力。重點在於「每天只有15分鐘」,一次投入太多,非常容易放棄。

其次,找同伴一起。這就像是慢跑或健身活動,總是一群人比較有效果。人類畢竟是群居動物,在群體中容易自我約束自我成長。

最後,尋求資深的人意見。這也是為什麼網路上,常常有匿名發問,查詢資訊的原因啊。



7/20/2018

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



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

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

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

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

大部分的情況是:

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

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

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

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

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


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






6/24/2018

軟體工程師:換工作時如何談判薪資



是故勝兵先勝而後求戰,敗兵先戰而後求勝 - 孫子兵法

軟體工程師:換工作時如何談判薪資


已經拿到Offer就沒啥好談了

軟體工程師在經過繁瑣面試之後,一旦從某公司HR(人資)拿到offer,其實薪資談判已經結束。在台灣,無論是本土還是外商,大多數都會由既有資訊:也就是履歷,面試評核,薪資市場參考,工作本身價值等等,給出一個數字,這個數字在給出之後,就表示此公司認定的市場價值。

薪資福利經過「談判爭取」有可能改變嗎?當然有,也因此許多企業巫醫,都會提供一些意見,例如包裝。但以軟體工程師而言,頂多是幾個%的差距,這樣的差距,遠不如這工作本身的意義來得重要。

另外一方面,倘若拿到offer時,無論經過什麼方式爭取,竟然可以取得15%以上的薪資差距,通常表示這個組織並不確定這職位應該帶給組織什麼樣程度的「價值」,換言之,組織裡面很可能因人設事。如果是在研究機構,這可能是一件好事。但如果是在盈利企業,可能是個警訊,表示用人主管與人資並不確定公司政策,更有甚者,公司其實沒有政策!

談判薪資的兩方向


因此,所謂談判薪資,其根本在於:在還沒談之前,就已經站在談判成功的立場。


方向一:人才市場。


同樣是軟體工程師,即便在同個城市,也因不同產業有極大的差別。在台北,如果求職的方向是傳統產業的IT部門,其薪資就大概不如銀行業的IT部門。

同樣的產業,在不同的地理環境也有極大的差別。同樣是智慧手機應用程式開發,在印度外包城市班加羅爾,其薪資就遠不如新加坡。

同樣的產業,同樣的城市,同樣類型的工作,也會因為企業組織的市場定位而有所不同。組織急於擴張,自然就會提出高於市場的薪資水準。

方向二:個人價值

所有人都知道,「自己很厲害的話,薪水自然就會高,就容易找到薪資高的工作」。然而,許多軟體工程師常忽略價值的兩個重點:

(a) 其他人所認定的價值才是個人價值

自己認為自己很有價值,不見得是真的,很有可能是自我感覺良好。根據其他人所「實質認定」的價值才是真的。舉例來說,一個有N年工作經驗的軟體工程師,過去9個月,都只能找到月薪3.5萬的工作,那麼他在市場上實質價值就是月薪3.5萬。反過來說,如果一個有N年工作經驗的軟體工程師,他已經在目前的公司服務N年,最近的薪水是月薪10萬,然而,過去9個月他四處尋找更好的機會時,始終都沒拿到offer,或者拿到offer但是遠少於月薪10萬。這就表示他很有可能在現在的工作薪資是overpay,也就是目前企業可能高估其價值。

(b) 對組織有意義之產出才是個人價值

在徵才的過程中,偶有軟體工程師會覺得「自已都做一些沒有成長性的工作」或者透露「這工作無法讓自己持續成長發展」

這當然表示龍游淺池,組織可能受限於先天環境,沒辦法給這個軟體工程師更大空間。然而,這必須是此軟體工程師對組織已經有「大幅超乎期待」的產出,並且有「實質事實」才行。


建議的行動


作為軟體工程師,如果對你現有的薪資不滿,或者在目前工作領域上做得極度不開心。建議有以下實質行動

(A)  面試自己想去的公司

面試會讓你有機會知道「其他人」對你的價值判斷

(B)  把現在的工作做到超乎所有人的期待

如果無法做到這點,怎麼會知道自己的價值是提升的?又怎麼會知道下次換工作時,薪資談判已經處於不敗之地?

(C)  找到自己喜歡的市場缺口

這幾年來許多軟體工程師會前往中國,或其他成長中市場。這當然也是一種薪資成長的方式。然而,市場的缺口不見得只有成長中市場,即便在台北,也有許多職位和產業有明顯的軟體人才缺口。

找到自己喜歡的市場缺口,或許是個突破的行動。

舉例來說:過去半年來,DevOps在新創和有對消費性市場服務的公司就是個很大的缺口,此外,大數據在銀行產業似乎也是同樣缺口。



3/06/2018

何謂:資深工程師


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

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

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

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

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

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

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

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

技術能力


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

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

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

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

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

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

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

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


實質經驗

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

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

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

團隊合作

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

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

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

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




1/18/2018

企業巫醫:強人不受環境影響,很遺憾大部分的人不是


TED眾多演講中,有位經濟專欄作家Tim Harford講了因挫折而成長的主題

他用著名的科隆演奏會為例,告訴聽眾,一位爵士樂大師Keith Jarrett如何在一台誤送來的沒調音半殘鋼琴上,彈奏出驚艷的效果。科隆演奏會(1975)的錄音,甚至成為史上最暢銷的個人即興爵士鋼琴專輯。實際故事可以參考這裡

演講者,接下來也提出在稍微困難的環境下:例如英文書本的字型都是粗體大寫,會讓學生為了解內容,刻意「用力」讀文字,讓文字內容更容易被思考和記憶。

些微困難的環境,可以讓大多數的人獲得進步,但極端的環境只有極端少數擁有高強度的技術能力和意志的人,才比較有機會不受環境影響,進一步從極端環境中創造更大價值。

以科隆演奏會為例,Jarrett大師是因為已經熟記樂譜到閉著眼睛都能彈,每個音調和效果對他來說都已經是無意識的動作。因而,演奏遇到即時問題時,他才有「閒暇」的即興創意產生,並實踐出來。一般演奏者,遇到半殘的鋼琴,鐵定是難以完全發揮能力。

在職業生涯中,每個人勢必都有自己擅長的領域,然而,實務上環境造就的問題,在大部分普通厲害的人,會產生難以克服的影響。而僅有在一些特定領域的強人,才能改變環境。

因此,在企業組織中,人通常會去「適應環境」和「控制環境」。就好像Jarrett試著去適應半殘的鋼琴,並且透過自己的能力,進一步控制它,讓它不成為發揮自己能力的阻礙。

幾乎所有的創業者,都是透過創造新的企業,來達到控制環境的結果。不過創業成功的機率相當低

而在企業組織內工作的人,都需要適應環境,然而,適應了之後,鮮少有人不受環境影響。如果組織內部的氛圍是「保守」「部門壁壘明顯」「官僚」的話會更嚴重,這樣的環境,可能會直接影響一個人對工作的認知與態度 -  特別是剛畢業出來工作的人。最糟糕的是,即便這位新鮮人換了環境,可能還受前一個比較糟糕的工作環境影響。

要能不受環境影響,適應環境,進而控制環境的方式有許多種,但最有效的恐怕是「變成強人」,在專業工作領域上,要變成「強人」,遠比鋼琴大師容易許多。

在專業領域上,如何變成強人?


(1) 特定主題的實質經驗(深度)


無論是nodejs,VBA,還是對excel有非常深入的了解,都是一種特定主題。盡可能探究深入某個主題,當你認為這我已經會了,要試著問一下自己,「全部都很瞭解?」還是「我會用它做某些事情」。以簡單的excel為例,大部分的學生都會說自己「會」excel,但是大部分的剛畢業的學生恐怕連pivot table都不曾使用過。


(2) 和工作領域相關的學習(廣度)


在工作上,必然會遇到和自己工作相關,但可能是其他人負責的事情。這些工作領域,會逐步造就自己對工作上的廣度的了解。以程式設計為例,許多人都對SQL有使用上的了解,特別是由於MySQL, Oracle, MSSQL歷久不衰,程式設計師多多少少都知道SQL。然而,把SQL寫在履歷表上的程式設計師,其實有一半以上的人不了解OUTER JOIN。傳統上SQL的管理是屬於DBA的任務,但現在的程式設計師,越來越多會涉獵devops的領域,對SQL了解就是一個增加廣度的例子。


(3) 在目前工作貢獻


就像鋼琴大師一樣,必須要有「在目前工作上的產出」才是真正的貢獻。貢獻和能力並不見得有直接相關,但是,當具有深度與廣度的知識經驗之後,當然容易對組織有更大的貢獻。


簡而言之,持續學習,就是成為不受環境影響的強人的唯一途徑。






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.



11/10/2017

技術迷思:是人類使用工具還是工具使用人類?



在知識頻道和各類文章中,都有對於到底是「人類馴化狗,還是狗透過改變自己馴化人類?」有些有趣的討論。也是因為太多先進國家裡,家庭中的狗,實在過得太幸福,以至於太多其他人類質疑自已,該不會是因為狗的訓練人而進化?

資訊科技工具 - 特別是近年來手機和網路 - 也會讓人有此錯覺。

人類創造手機與網路,但是從小活在資訊世代的人,在成長過程中,很大的情況是被「手機」所馴化。和同學朋友聚餐的時候,大家拿起手機拍照推文的情況屢見不鮮。隨時隨地都要看一下手機的,遠比當它響的時候才看得人多。隨著手機功能越來越強悍,壽命卻越來越短。....手機已變成超越原本功能,超越一切的存在。製造商推銷手機的方式,幾乎已經和手機原本的功能 - 也就是和其他人聯絡 - 無關了。

事實上,手機的功能密集高,導致於在地球上任何一支智慧型手機製作,都牽涉到上百萬人的投入。沒有任何單一企業,組織,能「自己從原物料開始,從頭到尾搞出一台手機」。(註:不過倒是有人可以從頭到尾搞出一台烤麵包機)

手機與網路,既然已經成為超過創造者的存在,就與時俱進的,造就類似宗教信仰般的崇拜,終極果粉(apple手機的愛好者)就是明顯的例子。

不過,並不推薦極端的阿米希式的全然拒絕方式,畢竟,現在沒有手機號碼只會造成自己的痛苦。避免工具反客為主,有幾個合理方式。

(1) 偶爾換方式或者不用它。


要證明自己戒酒的方式,就是確保自己有夠長的時間不喝酒。同樣的,要證明自己沒有手機資訊焦慮症的方式,就是一段時間(3天)完全不使用它,或者是一段時間(7天)只能每天用一次。推薦最好是去日本度假,雖然帶著手機,但是限制僅作為緊急聯繫用途。不但可以徹底放鬆身心,也可以去除資訊焦慮憂慮。

(2) 優先改變工具配合生活,不改變生活配合工具。


人類的高度適應力,讓人「本來」就會配合工具而生活。火車飛機的乘坐方式就是很典型的例子。認知到工具會改變生活,然而人類卻也能改變工具,讓工具適應自己。
古早之前,還是底片相機的時候,旅行者通常會以「親身感受」風景為優先,然後有空的時候才照相。在數位時代成長的人,旅行的時候很可能是以「數位相機的鏡頭感受」為優先,也就是說,看到美景先照相,看到美食先照相。反而讓自己的視覺和味覺的優先順序,讓給沒有感覺的擁有高檔鏡頭的手機。在你手上的手機是不會不見的,可是對於旅行的體驗和感受,一旦由「你的手機」先做第一時間的感受,旅行的意義就大幅降低。以後或許看別人的部落格文章也就夠了?


(3) 成為什麼樣的人,遠比擁有什麼樣的東西來得重要。


生活圈的朋友親戚同事,必然的會互相影響,包含購買的最新手機等等。這些都無可厚非,不過,只要記得單純可以用錢買的東西,都很容易單純而且簡單地失去。然而,需要努力學習得來的:例如知識技能經驗,卻幾乎會跟著一輩子。






9/19/2017

如何建立一個還不錯的部落格(blog)



The only thing you really have in your life is time. And if you invest that time in yourself, to have great experiences that are going to enrich you, then you can’t possibly lose.  (Steve Jobs, Entrepreneur)

你真正擁有的其實只有時間,如果你把時間用在投資自己,得到很棒且能豐富你人生的經驗,你不可能會失去什麼。」 史蒂夫‧賈伯斯


部落格和Facebook(臉書), twitter, instagram有根本上的不同。相較於快速的互動,部落格更具有長期性,也因為長期性,讓近年來的知識型部落格(註1),成為一個需要長時間投入,也可能會長時間回收的事情。就短期行銷而言,部落格或自己的網頁,遠不如fb的粉絲團或twitter的密集短暫貼文。然而,就長期內容累積,擁有比較完整的表達敘述來說,自有網頁或者部落格仍然比較適合...只是要投入比較長的時間。


關於生活類型的部落格可以參考註2,在此謹分享專業類型的部落格。

專業人士為什麼需要有自己的部落格

這裡的專業人士是指:工程師,程式設計師,法務專家,行銷人員,心理諮詢,作者...等等。和一般生活類型:旅遊,吃喝玩樂...的訊息傳遞有很大的不同。

很有可能專業類型的部落格,僅在特殊情況下會被陌生人看到,大部分是「為了自己而寫」,而長期累積之下有很多好處:

1.  提升與反思


教學相長,當你能把一件事情表達清楚,表示你對這件事情了解得更清楚。在寫作的同時也更容易發掘自我問題。

2. 資訊傳遞


某些專業領域有自己的知識瓶頸,或者想要傳遞和其他人略有不同的觀念。一篇簡單清晰的部落格文章,就可能會達到效果。例如:Scrum認證,不要再浪費錢了。這篇是對於Scrum認證的反思,在google search "scrum認證"的時候已經會出現在第一頁,讓想要考Scrum認證的人,可以多一個參考觀點。


3. 專業行銷


由於退休新制的實施,現在換工作的門檻越來越低,而專業人士必須要能展現與行銷自己的能力。履歷表或者linkedin固然是好方法,但是有效的,長期的分享自己的能力與觀點,更能展現自己與他人的不同。請參考這裡,與這裡


但請切記,部落格只是「額外」產生上述三個好處,自己寫的愉快才是重點。


工具選擇

如果你還沒有自己的網頁,部落格。想要開始,自然要先選用平台/工具。當然,已有許多部落格文章在討論「部落格」工具的選擇。

例如:

* 2017部落格平台調查報告 :這篇主要是討論收費的平台

* Blogger 和 wordpress的比較 :如果懶得研究太多免費平台,考慮這兩個就好。

假如你是資訊專業者(程式設計師等等),自己搞台電腦或者VM,自建網站,也是個好玩的方式。但如果不是為了好玩或者學到網站營運的技術,就專業分工的角度來看,採用成熟的平台或許更好。例如:你也不會自己host email server對吧?

不過其他類型的專業人士(心理諮詢,牙醫,法務人員,行銷,業務,作家,顧問等等),採用現有的平台是最簡單,效果穩定,而且不用花太多時間處理雜務。

在還沒有決定怎麼做之前,有幾個建議:

1. 如果你不想要廣告,未來也不打算透過部落格廣告賺錢,不建議用痞客邦這類型預設有廣告的平台。

2. 網址名稱很重要。現行第一層網址,例如.com,已經有超過1000個可以選。也表示不要太特殊的網址也並不貴。以你現在看到的這個blog網址:5233.space,一年也不到300台幣,第一年還是特價70元台幣而已。

BestProgrammerInTaiwan.com 五年,2242台幣


3. 如果你的讀者群,不包含中國大陸(註3),那麼免費的google blogger會是最佳選擇。因為即便綁定「自己的網域」名稱,它仍然免費。以你現在看到的網域www.5233.space,就是在godaddy買了網址名稱之後,綁定到google blogger上。

建立的基本步驟


如果對於建立部落格還沒有計畫?可以考慮採用以下方式:

1. 決定目標


最好有個清楚的部落格專業範圍。例如:心理諮詢,程式設計,軟體工程,如何創業等等。決定目標也比較容易決定名稱和網址名稱。

範圍可大可小,而範圍大小各有優勢與缺點。

2. 建構平台環境

沒有太多考量的話,就...

(a) 直接到blogger.com建立一個自己的部落格,

(b) 到godaddy.com買個不會太貴的網址。建議直接買5年。因為部落格需要長期經營,5年的網址,通常也不過2000台幣。

(c) 綁定godaddy網誌到blogger.com,請參考這篇說明

(d) 寫2-3偏草稿

(e) 隨意試用一下Blogger.com的設定

3. 持續撰寫文章


最好能維持每週一篇,每年50篇的速度。專業部落格是不太適合一天一篇,實務上也不太可能。

要持續不間斷撰寫文章,才能迫使自己持續不斷的在專業上成長。

4. 定期檢視


定期檢視部落格文章數量與分類是否合理。更重要的是,當部落格文章達到一定數量時,可以和自己的linkedin以及履歷表連結。

5. 橫向連結


無論有意無意,橫向連結同類型文章或網站,是建立一個還不錯的部落格的要件。




如果你還沒有確實的實施計畫,可在此索取「建立部落格一頁計畫書」,可以確實並腳踏實地的建構自己的部落格網站。





註1. 這裡指的知識型部落格,是非「吃喝玩樂型」的部落格。然而,以pixnet為例,絕大部分訪客數多,能用廣告賺錢的的部落格,都是屬於「吃喝玩樂型」。請參考排名:https://blogranking.events.pixnet.net/

註2. 成為人氣部落格的方法生活部落格5步驟部落格衝人氣的方法...

註3. 因為截至目前為止,大陸長城會擋住大部分google的服務。


9/04/2017

面試的前晚準備 - 極簡計畫書



無論你是社會新鮮人,還是職場打滾了十幾年的老鳥。當你準備要去工作面試的前一天晚上,有計畫性的準備面試,絕對比沒有任何準備來的好。

職場新鮮人自然會從網路或其他地方,獲得許多面試準備的要領,試圖做到面面俱到。然而,已經到了前一天晚上的話,要抱佛腳也應該要有正確的方向。例如,努力準備英文自我介紹,大概就不是一個前一天晚上能做的好方向 (註1)。

職場老鳥,即使已經是工作N年以上,應徵的是資深技術相關職位,在前一天晚上「提升技術能力」當然是不可能的。不過,卻可以準備好自己的強項,來增加面試成功的可能性。

某些資深職場老鳥,通常有「知我者伯樂,不知我是你的問題」,「良禽擇木而棲,這塊木頭反正也不好」的想法。這些想法不見得是錯的,然而,這不應該是「不做面試準備」的藉口。因為無論該公司好或者不好,既然要前往面試,你的唯一目的應該就是「被錄取」,而錄取之後,再來考慮要不要答應還不遲。

而面試前一天的準備,對資深技術人員來說,其實更簡單,並且也很容易讓面試方看得出你的資深價值。舉例來說,準備「要問」的問題,對資深老鳥就非常重要,這些問題的重點不在於獲得「解答」,而是在於讓面試者知道你的資深程度和專業性。

「面試前一天的準備 - 極簡計畫書」


與其說是計畫書,不如說是一個檢核清單,任何人應該可以在一個半小時之內,完成清單上的項目。按此索取極簡計畫書

計畫書的目的是在面試前的晚上,約1.5小時之內,用合理的技術方式,盡可能提高自己既有能力的展現,藉此提高面試成功的可能性。 

使用步驟說明


(1):找到組織背景資料。  [15分鐘]


在組織相關資料區塊中,填入公司組織名稱,代表人,營業額,毛利率等等可以找到的資料。

如果是營利組織,幾乎一定能透過名字或者統編,找到基本資料。非營利組織或者剛起步的新創事業,可能缺乏某些資料,但是可以將難以取得的資料當作「要問的問題」。因為,專業人士,通常會問出真正關鍵性問題。


(2). 要問的問題:   [35分鐘]


要準備問對方的問題。現在的面試,幾乎都會讓被面試者發問,而這段時間難能可貴。因為,這些問題是100%可以由自己控制,也就是說自己可以決定要問什麼,也可以決定不問。因此,面試前一天,反而應該花多一點點時間在準備「要問的問題」。

要問的問題的「真正目的」是要讓面試者認定你的能力和潛力,而不是你真的想要知道問題的答案。因此,最最最愚蠢的問題,莫過於詢問公司福利,社團活動,上下班時間,哪邊可以蒸便當,之類的無聊問題,這些問題,應該是透過人資或上網搜尋取得答案,而非浪費在寶貴面試時間上。

要問的問題至少要準備7-10題,而可以視面試情況決定要不要問。

基本問題像是:
  • 如果我被錄取了,我在到職前3個月,要完成哪些具體工作內容?
  • 目前這個職位,是因為有人離職而要找取代者,還是一個新職缺?此職位已經懸缺多久?
  • 請問您如何評估一個人適不適合這個職位 
  • 面試到目前為止,你覺得我是否適合此職位

至少必需要準備2-3個進階的技術性問題,技術問題並非指「特定的技術」,而是指「讓你側面了解更多」的問題。例如:

  • 請問您會在這裡工作最主要的原因是什麼?
  • 目前這個團隊,曾經遇到最大的障礙或困難是什麼?
  • 請問您擔任這個團隊的主管已經多久了?

當然,進階技術問題通常比較敏感,在開口之前應該要客客氣氣的說「如果不方便講也沒關係」。

請在表格中,挑選要問的問題,並且在備用欄位,填入你自己想到的問題。





(3). 被問的問題:   [30分鐘]


面試者在面試的時候,手上一定會有你的履歷表。無論你之前對你的履歷表有多熟悉,在前一天晚上,應該再次看一下當初你寄出去給該公司HR的履歷表。

因為,要從中找到「以面試者的角度,認為需要在確認」的問題。並針對這些可能被問的問題,簡單準備一下解答。

技術專業性的問題,對於職場新鮮人,需要再次確認「真實性」,以免被人認為誇大能力。因為,職場新鮮人通常的確會「誇大」自己已經有的能力,例如其實只是在學校學過c語言,寫過幾個作業,通常就會把c語言當做「自己會的程式語言」,但是這和職場上的「會」可能有些差距。

而對於職場老鳥,只需要注意一下「曾經做過的事情」和「曾經有的貢獻」即可。

例如參與的研發團隊人數,自己扮演的角色等等。履歷表上的明顯缺陷,才是一定會被詢問的地方,例如某個工作僅做了6個月,或者在前一份工作到今天有3個月個空閒時間。

請根據表格,檢視履歷表,並且填入自己的模擬問題和可能的回答。


(4). 面試的時間地點交通方式與服裝。  [5分鐘]

聽起來很不可思議,不過確實有一定比例的人會過於緊張,太早或者太晚抵達。
也甚至有人壓根就忘記面試時間或地點。

前一天晚上應該確認一下面試時間或地點。

某些職位(業務單位等)可能對服裝有一定的考量,當然也得花一點點時間準備。


(5). 面試之後?


無論面試的好與壞,其結果一定要誠實的記錄在計畫書中,因為它可以作為自己下一次面試的參考。

結果只有分成兩種:錄取或者不錄取 - 無論原因為何。有些組織會考慮資深人員的面子問題,可能會用「目前組織人事凍結」等等軟性理由,不過對面試者來說,就只有錄取和不錄取兩種結果。

難以回答的問題:在這欄中,盡可能就自己的記憶,記下自己覺得難以回答的問題。如果是技術性問題,表示自己有技術需要加強。如果是其他問題,也應該記錄起來作為參考。

這個計劃書,應該自行根據面試的公司不同,做不同的調整。極簡計劃書僅是在你沒有更好的主意時,提供參考而已。


按此索取極簡計畫書


註一:英文能力確實是許多工作的加分條件,但前一天晚上,臨時抱佛腳準備英文自我介紹,對英文本來就不好的人其實一點用都沒有,而對本來英文能力就已經很好的人,也幫助不大。