顯示具有 培育人才 標籤的文章。 顯示所有文章
顯示具有 培育人才 標籤的文章。 顯示所有文章

7/19/2020

新手主管的準備 - 2 (成為主管的31堂課)


當新手主管認知到改變之後,更重要的當然就是準備應對改變。每個組織可以承受的改變時間長度不同,但越快能夠自主地以透明的時程提出改變計劃越好。計劃本身是可以隨著間改變的,因此,做這件事情的重點在於讓自己以及相關人等,對未來你打算要做的事情能有一致性以及能有差不多同樣的期望!

(1) 在幾小時之內,建立三個月時程表

當確定你會變成新手主管,假如你的主管已經幫你擬定好一個轉換計畫,那恭喜你,你自己遇到一個非常好的主管。應該詳細看過他的計畫,並且延伸出自己覺得該做的事情或者細節。
如果你手邊沒這樣的計畫,那麼最好在幾小時之內,趕快做出一份三個月的時程計畫,並且和你的主管討論計畫可行性。

為什麼需要在最短時間有三個月時程計畫?因為一旦你轉換了角色,你勢必會遇到很多新的事情,新的優先順序,而你的時間很快就會被佔滿。如果不能在一開始先有所規劃,一旦事情接踵而至,很容易就會落入被事情追趕的情況,屆時要重新調整只會事半功倍。

計畫內容至少要涵蓋:

a. 確切的轉換職稱的時間點,會用哪種方式公告。

b. 未來幾週內的哪些時間點約好和團隊成員1vs1會談,以及會談的基本內容。基本內容至少會有涵蓋,當你作為主管的時候,他們對你的期待,以及你對他們的期待。哪些具體事情是他們需要你馬上去做,哪些事情他們希望你不要做等等。

c. 跟自己的主管(無論自己會不會換主管):至少每兩週約一個小時的時間討論你擔任新主管的後的進度 

d. 建構利害關係人的溝通方式(參見下一節)

e. 建立衡量團隊成員期待的方式(參見下下一節)

f. 列出在領導與管理層面上,自己還需要學習的地方。並且自主安排時間學習。如果列出不來,必須要和自己主管討論學習清單。

g. 固定時間檢討本計畫內容


(2) 建立利害關係人溝通方式


所謂利害關係人(stakeholder)就是跟自己成功息息相關的人,自己的主管和團隊成員,必然是在其中。但還有其他重要的人,例如主管的主管,產品經理(PM)或專案經理(PM),其他研發或工程團隊的主管,公司其他部門,甚至客戶都有可能是利害關係人。

當然根據公司規模大小不同,利害關係人數量可能不太一樣。然而,就像所以事情都有重要/緊急程度不同,應該有不同方式以及不同時間順序處理。
利害關係人也一樣。請參見下圖:


簡單的說,互相之間工作決策影響程度,就是利害關係人彼此應該合作的方式。以第一型為例,如果互相都有巨幅影響,那麼互相參與實質工作就是你的第一要務。舉例來說,如果QA和RD分屬不同主管,你扮演QA主管的角色,那麼在同一個專案中,讓RD主管某種程度參與你的工作就會是你的管理利害關係人的成功因素。

又例如第二型,最常見的就是大公司的主管的主管,或者CEO,其實你現在的工作對他影響不大,但是他的任何決定,可能突然之間會對你的工作有巨幅影響。然而,花很多精神和時間去影響他也是不智的選擇,因為你也很有可能反而浪費時間沒有將精神和時間投入在工作本身。因此,定時通報現況,並用最短最少的時間讓他滿意你的現況,就是最好的管理方式

(3) 建立衡量團隊成員期待的方式


團隊成員都對新主管有不同的期待。這件事情比,實際上比看起來還要麻煩。因為每個團隊成員對你的期待不同,會導致於,你很難有同一個方式對待所有人,如果不小心拿捏不同的方式,就會讓別人「覺得」你不公平。

最簡單的建立方式,就是透過1 on 1,直接詢問團隊成員對自己的期待,並且在每次1vs1的時候,了解自己有沒有達到他的期待。

但這個方法不保證有效,因為團隊組成的方式,團隊成員個別成熟度,以及新手主管對他們的了解程度,有很大的差異時,1 on 1需要一段時間才有效果。

很遺憾的是,這一點沒有最佳做法,只能根據團隊的不同來建立。


(4) 建立一致性

所謂的一致性,指的是其他人對你做事的理念有一致的感受。無論好或者壞。
嚴格上來說,人類自己會建立自己的一致性。說得更直白的就是人的個性和價值觀其實很難改變,然而,作為軟體主管卻要特別花心思,刻意建立某些事情的一致性。並以此為基礎,溝通許多困難的問題。

舉例來說,假設團隊都是資深工程師,也許你會想建立管理的一致性叫做「自主性透明,團隊合作優先」。

透明可以是:所有人寫的code都應該送出給大家review,所有技術性質的內容,都需要放在組織的wiki上或者是公開的文件管理中。任何非技術的討論當然可以私下進行,但是最終結果,和決定最終結果的方式,一定會放在公開的地方。

自主可以是:當任何人來詢問你問題,在你回答之前,你一定會詢問「那你覺得應該如何處理?」無論事情簡單與否。同時也可以是,交付任務會盡量以自願者優先。

團隊合作優先可以是:任何產出必須優先考慮可維護性,在任何時間點都要考慮一件事情是不是只有一個人會做。

簡單的說,只要對事情有一致性,你未來在複雜事情上就有一致性,這樣的一致性會讓所有人都覺得你容易合作並且也容易讓事情完成。

(5) 建立成功策略


最後,在這個新主管準備計畫中,會被歸納成幾個成功策略,並且在未來幾個月檢討策略執行情況,如果只是執行問題必須要堅守策略。如果策略不行,也要知道改換的方式。

每個人的成功策略不同,可能只是幾句話,也可能很複雜。無論如何,有策略不見得會成功,但沒策略幾乎保證會失敗。

例如,打算打造新團隊的策略可以是如下:

「打算招募已經有豐富經驗的人才加入團隊,希望團隊成員一開始就是會自動自發地搞定任務,並且也都容易合作,會自我學習。預期這樣的人可能是工作7年以上,並且招募的速度會拖慢很多,不過一旦找到適合的人,離職率也不會高。建構團隊我們打算不計成本得找到最好的人才,專案甚至為此延後6個月也在所不惜,因為一年之後,團隊會非常穩定而且也少有問題」

也可以是如下:

「打算自行培育人才,希望找有熱情,會自我學習,對軟體開發有基本知識的人。預計這樣的人可能剛畢業或者工作一兩年,招募速度應該蠻快的,只是新鮮人遇到挑戰可能離職率會很高,另外我們知道要預留學習時間,因此不會馬上上手。專案可能可以很快開始,但是中間的產出可能要看找人的運氣,6個月之後是能否穩定的關鍵期,一年之後預計會有個還可以合作的團隊,但可能會有管理上問題,成本可以控制在XXX萬元之內」

如果已有現成團隊,新手主管不需要建構團隊策略的話,還得建立自己的執行任務的成功策略。重點永遠在於,有計劃/策略會比沒有好太多!



6/20/2020

新手主管的準備 - 1 (成為主管的31堂課)

沒有時間嗎?可以直接看這個清單

沒有人生下來就知道如何作為一個領導者,軟體開發的主管也不例外,即便是資深厲害的主管也都會遇到第一次當主管的困難。

無論是什麼原因,當你有機會變成主管時,需要有意識的認知到,主管的責任和義務會跟你過去的工作截然不同。越快有這樣的認知,並且越快做好準備,你就越有機會成為一個好主管。反之,沒有這樣的認知並且也不做準備,就會有很大可能變成傳說中的壞老闆。

工作本質上的改變


以軟體開發的主管為例,在你變成主管的那一天開始,工作就有本質上的不同。無論之前是不是擔任團隊領導(team leader)的角色,作為主管之後,你的責任範圍就會自己擴大為「團隊」,並且近一步擴大到「其他團隊的互動」。
根據團隊的規模大小,在人數很少的團隊,主管也會進行實質工作,例如撰寫程式,測試等等。然而,工作本質上會讓主管必須要更關注「團隊其他成員」如何完成自己的工作。表面上,簡單的方法,是透過code review。實際上,更推薦新手主管至少每週要找一小段時間,直接坐在某些團隊成員的旁邊,和他一起pair programming。這並不只是兩個人一起看著同一個螢幕寫程式,同時也代表可以了解團隊成員是怎麼完成周邊任務,例如撰寫文件,撰寫測試,執行測試,檢查是否符合規格等等。

工作本質上的改變必須要真正被「實踐」。實踐的方式就是必須要認知時間的重新分配。


工作時間的分配

大部分的人會傾向做自己「喜歡」做的事情。很遺憾的是,如果新手主管只做自己喜歡的事情,那有很大的機會會造成團隊的失敗。

一般來說,新手主管至少每個月都要和團隊成員進行一次1vs1的懇談至少每週要花1小時,重新檢查一次目前重要事項的進度,以及風險評估。至少每週要花一小時,和重要相關的其他團隊主管溝通。至少每週花一小時,和自己的主管溝通......這些零零總總之的「至少項目」,如果沒辦法有效進行,那麼會花上起碼1/3的工作時間,而且可能也達不到該有的較果。這也是為什麼許多新手主管看似忙得要死,但卻常有溝通問題。

時間,是軟體開發裡面,最需要被控制的資源,但也是最不容易被控制的。主管會比工程師更需要知道怎樣有效分配時間。


衡量成果的改變


作為新手主管,必須要認知到衡量自我成功的要素,會是團隊的成功。換言之,任何團隊的問題,無論是不是自己造成的,都會是自己的問題。誠所謂權力越大,責任也越大。

認知到衡量成果的改變,也代表你需要追蹤和關注的,不只是個人的產出,還會是團隊整體的產出。並且,規模團隊越大,個人產出會變得越不重要。舉個極端的例子:假設一個大型軟體產品開發團隊裡面,有前端工程師,後端工程師,手機app工程師,維運工程師等等,每個工程師小組表面上都按照標準完成任務,但是整合起來就是會有各種問題,那麼這仍然是個失敗的狀態,而軟體主管是這個失敗狀態的主要負責的人。


要做好資訊相關的主管任務,其實相當不容易,當至少有認知到以上的改變時,就可以開始進行準備工作(參見 新手主管的準備 - 2)。



9/06/2019

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



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


何謂信任?


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

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


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


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

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



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


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

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



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


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

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

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






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說要不要早點有人進來)


10/21/2018

企業巫醫:電商發展史代表人物貝佐斯(書摘)




中文譯名貝佐斯傳,第一次出版於2014年,在此前2年2012正是AWS成長最快速的驚人階段。許多台灣的軟體工程師認識亞馬遜(amazon)並非從零售業開始,而是從雲端服務開始。然而要瞭解自1995開始的網路電商發展,就不能不認識亞馬遜這家公司,而要認識亞馬遜(amazon)就不能不了解貝佐斯此人。因此,原書名The Everything Store(直譯為什麼都賣的商店)翻譯成貝佐斯傳,還頗為適切。

作者是商業週刊的記者(Brad Stone),但此書很明顯的並非歌功頌德的講述一個厲害的人的生平。書裡穿插了貝佐斯Bezos的生平,和亞馬遜本身的起伏歷史。作者認真的考究當時發生的事情,留給讀者事實,但也不會一昧的鄉愿,冷冰冰的陳述數字,作者也會事實比較,不帶太多評論的給讀者參考。

Amazon發展歷史:亞馬遜成立於1994年,但是網站正式上線於1995年7月16日。並在1997年五月正式成為股票上市公司,當時股價18美金,在這快速成長階段,貝佐斯從各產業挖來各種空降人才,特殊的高選人標準蔚為趣談。1999年到2001年之間的網路泡沫化確實讓亞馬遜受到挫折,裁員與關掉物流中心都在此階段發生。然而,熬過第一次網路泡沫之後,亞馬訓似乎已經知道如何在複雜龐大的電商世界成長,透過併購可能的競爭對手(並購清單請參考這裡),堅持「最低價策略」,研發Kindle電子書,讓亞馬遜在2008年金融危機時幾乎不受太大影響。2011年員工人數達到3萬人,然而2016年底已經成長到56萬人!

亞馬遜的經營策略是堅持給顧客最低價,換言之,犧牲供應商的利潤,打破任何約定成俗的現狀,是一直以來為人詬病之處。在書中講述很多和供應商衝突的例子很值得讀者細細參考。不過,在此更想探討的是其選人用人與組織管理的

特殊的人才選取與工作價值:

無論是前員工還是現在的員工,都會認為貝佐斯本人,幾乎代表了整個亞馬遜的意志,曾經在1999年找另一位執行長,然而隔年七月就離職,除那段時間之外,這24年來貝佐斯本人就等於是亞馬遜。

而他的做事風格極度鮮明,最著名的例子是,他認為「亞馬遜的員工必須要努力工作,聰明工作,長時間工作,而且不能三個只挑兩個」(You can work long, hard, or smart, but at Amazon, you can't choose two out of three) 這看似不合理的宣稱其實是在1997年才開始,在此之前,早期員工記得他說可以三選二。

他要的都是即時高手,而不要近來學習的人。然而,他選擇的人才,卻又通常不單只是該領域的人,而是他認為有突破性想法與實踐性的人!

此外,「勤儉」也是亞馬遜強調的守則。相較於矽谷其他公司,總部位於西雅圖的亞馬遜員工福利相對少很多。對員工錙銖必較的例子很多,例如:到職的時候發給一個背包,一台筆電,一些資料,然而離職的時候這些統統都要繳回,連同那個背包!

在2014年之前,溫良恭儉讓不存在於貝佐斯心裏,透過酸溜溜的語言咒罵員工是常有的事情。經典語錄有「你這個人到底是懶惰還是無能」「你為什麼要破壞我的人生」「對不起我今天沒吃傻瓜藥丸」「你自己講出這種話,自己不會驚訝嗎」等等。然而絕大部分的員工,無論離職於否,也無論喜不喜歡貝佐斯,都同意一件事:那就是貝佐斯的確很聰明。並且在2014年之後,由於企業變大,這類型不尊重人的對話也減少。

對於重要職位的僱用,貝佐斯會特別設立一個角色參與面試「bar raiser」直接中文翻譯是:提高標準者,基本上這個角色是用來提高進入標準。換言之,希望所有參與面試的面試官,都應該找應徵者是「比自己好的人」。但這個bar raiser本人是經過挑選,並不是每個人都可以擔任,而每個重要的職位,都需要有一個bar raiser參與。此人並非應徵者的主管,也可能不整個甄選過程出任何意見,但卻可以說對任何應徵者說「不」。很明想的是希望企業人才越來越好,而非越來越平庸?

然而,這樣的選人標準卻和福利相違背,在過去,普遍認為貝佐斯是所謂「傳福音」的角色,信他者就會加入,並且做牛做馬,不信者最好遠離這個環境。當然最近數年由於亞馬遜膨脹很快,這樣的標準不見得能在持續下去。

這本書的啟示?

購買在此。從有網際網路以來,貝佐斯幾乎是網路零售發展的最佳討論對象。他確實有遠見,也願意打破既有框架。然而,他也和越王勾踐一樣,可以共患難,難以共享福。不見得每個人才都適合這樣的環境,不過,不浪費時間的投入,根據事實來做判斷,不讓自己做限制的精神,才是這本書為何值得一讀的原因。

8/15/2018

Scrum: 三件不能少的事



Scrum是敏捷開發原則下,目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論,並沒有所謂的標準,各個組織的應用方式皆有不同。常見的應用(practice),例如:spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。

零零總總的practice中,哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神,以下三件事情是「最基本要有的」。也就說,如果這三件事情做不到,那麼其他事情做到也沒有用。


(1) 每個Sprint有交付具體產出


Scrum的Sprint都要有具體「可交付」的產出。sprint的開始,就應該以「結果」為計畫的導向,而此結果必須要是可交付的產出。

有些團隊會以Sprint長度不夠為理由,設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題:(1) sprint結束的檢討,並不基於產出的事實 (2) kick-off下一個sprint的意義不大,因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off,畢竟這個sprint沒有有意義的產出,而如此一來PO就很容易不真正加入團隊。

Sprint不見得要固定長度,請參考這裡。 


(2) PO有確實加入Scrum團隊


Scrum團隊成員有三個角色,team member, scrum master, product owner。其中最容易不在的人,就是product owner。許多軟體開發團隊,product owner就是PM。但無論如何,Product owner必須要真實參與團隊。

所謂真實,指的是所有standup應該參加,在團隊運作過程,能夠回答該sprint的需求問題,並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」

更重要的是PO加入團隊之後,DOD(definition of done)的標準才會具有「市場一致性」。舉例來說,不成熟的軟體研發人員常會對事情做完有不同的定義:
「程式寫完只是還沒review,所以還沒merge」
「程式寫完測試也沒問題,只是QA還沒通過」
「功能搞定了,QA也沒問題,只是還沒...」

PO確實加入後,可以讓事情做完的定義,統一在於「可準備交付到市場」。換言之,所有和程式設計相關的工作:測試,相關文件,環境設定,certificate等等都會以「可準備交付到市場」為原則。沒有這個原則,跑Scrum很難達到預計效果,要達到這個原則,最基本的就是PO需要確實投入團隊。


(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)


這世界上沒有完美的團隊,也沒有不用修正的軟體開發方法論。每個sprint的確實檢討,是修正團隊,讓團隊趨於一致的唯一方式,而非強加訴諸任何規矩。請參考這裡

確實的檢討並不容易,要做到兩件事情:
(a) 基於事實檢討   
(b) 不檢討不在場的人事物 


基於事實的檢討


檢討的內容必須基於事實,不是基於感覺與想像。感覺和想像的情況如下:
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」

事實的情況舉例如下:
「這個sprint我們沒有按照當時說好的DOD的定義,所以有XX與XX項目,本來說完成了,後來隔幾天又說沒完成」


不檢討不在場的人事物 


檢討確實是對事不對人,然而,事情都是人做的,不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。

不過,要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確,導致我們要重做某些事情」如果UI/UX是同一個scrum團隊,那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為,Scrum的檢討會議目的是產生「團隊要改善的項目」,而不是去讓非團隊的人改善。

Scrum的學習必然是從實際的經驗獲得,但經驗的獲得又必須從知識學習的取得為基礎,要成為看似不錯的Scrum專家不難,但要實際應用於專案中,並取得可重複成功的結果就不這麼容易了。





7/20/2018

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



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

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

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

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

大部分的情況是:

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

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

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

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

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


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






3/06/2018

何謂:資深工程師


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

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

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

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

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

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

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

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

技術能力


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

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

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

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

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

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

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

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


實質經驗

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

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

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

團隊合作

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

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

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

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




11/13/2017

在台灣建立研發中心?


現代經濟學鼻祖:亞當斯密的國富論中,描述產品價值有三個主要來源:「土地」,「資本」與「勞動」。其中土地泛指自然資源,勞動在現代社會不僅僅指人力,更重要的有執行力和創意的人才。

而今資訊社會中,因為交通和電信費用降低,以至於人才流動成本也跟著巨幅地降低(註1)。資本主義當然會讓「看不見的手」運作,而讓企業組織的經營,朝向最低成本最高效率方向前進。人才的取得也不例外。

最近一兩年已經有太多企業巫醫在討論「台灣人才外流」的問題。其中不外乎以聳動的標題。例如:

*「我在台灣看不到工作的未來」... 或許只有你看不到也說不定?
*「低薪惹禍誰想待在鬼島」... 低薪是一回事,但是台灣在所有地球上居住人口超過1萬個人的島嶼裡面,絕對排不到鬼島行列,請想一下菲律賓印尼加勒比海這些島國。
*「台灣小而亂普遍又低薪」...的確台灣不大,但是普遍低薪和亂這兩個形容詞,卻在該文中沒有任何支持的數據和研究,只是個人感想當作新聞來操弄。

有時候,單看客觀事實並不有趣,不太能成為焦點,然而客觀事實卻是,想確實進展的最佳依據。所以,我們應試著了解,就經濟學的角度而言,企業組織應該「移動台灣人才」還是「在台灣建立研發中心」比較適合呢?(註2)

首先,要簡單區分「人才」,「員工」和「人力」。人力泛指勞動力,在最基本的教育水準下,就可學習工作得稱為人力,資本主義天生會使用最低薪資,在當地合法的範圍內榨取人力。員工指的是企業內受雇的所有人,可能需要某種訓練過的技能,但其學習能在短時間達成。人才比較難定義,在此暫時指需要長期間的教育培養,並且已經有7年以上的實務工作經驗的專業人士。而在此要討論的,就是「人才」的移動,而非人力或者員工的移動。

最簡單衡量人才流動應該是看「實際獲利」,包含薪資,居住成本等等。衡量一個國家的薪資有很多方式,雖然沒有最好的方式,但是觀察GDP和NNI都可以考慮。

可是,更有趣的數字在於GDP和PPP的差距。

最最粗淺的說,人均GDP表示此國家平均每人在該年生產的價值。三大組織:聯合國,世界銀行,國際貨幣組織:每年都會公布此數字。彼此間資料收集方法略有不同,數字彼此有一點點差距。

讓我們專門看五個國家的2016 GDP:台灣,中國,日本,韓國,新加坡。


   GDP美金
台灣 22,453
中國 8,133
日本 38,917
韓國 27,632
新加坡 52,961

這和我們內心理解差不多,台灣似乎遠不如其他先進國家,不過大陸的「平均值」仍然很低(當然比較特定區域:例如上海,那結果可能不太一樣)

然而,更有趣的數字是PPP:平均購買力。PPP其實和GDP的計算方式雷同,只是將匯率和物價也考慮進去。而PPP才是在該國家裡面的人,實際上消費真實情況。將GDP和PPP之間的差距,除以GDP就是「購買力相對於生產力的增額」。參見下表:

(本文的數字都是美金計價,並由wiki節錄國際貨幣基金會取得)


  GDP(美金) PPP(美金) 購買力相對於生產力的增額
台灣 22,453 48,095 114%
中國 8,133 15,399 89%
日本 38,917 41,275 6%
韓國 27,632 37,947 37%
新加坡 52,961 87,855 66%


這個表顯示幾個事實:

(1) 在這五個國家內,日本的GDP和PPP最接近,而台灣差距最大。

(2) 單純看GDP,台灣遠不如日本韓國。然而,單純看購買力,2016年台灣比日本韓國都要來得高。

(3) 假設這五個國家的人才能力差不多,則在台灣建立以人才為主的研發中心是「最划算」的選擇。因為同樣價格的人才,在台灣實質獲利是最佳的。同樣100單位的錢,在這五個國家中,台灣實質可花費214, 日本是106, 中國目前是189,韓國為137,新加坡是166。(註3)

(4) 購買力和物價很大的關係,然而購買力要和GDP同時考量,因為就算有極低的物價,GDP不高也是沒有意義。

(5) 絕大部分先進國家這兩個數字都很接近,某些國家(例如GDP一直都排名前三名的盧森堡)甚至購買力增加率是負的!


然而,單就這兩個數字,很容易看出缺陷。例如把菲律賓加入之後變成下表:



  GDP(美金) PPP(美金)  
台灣 22,453 48,095 114%
中國 8,133 15,399 89%
日本 38,917 41,275 6%
韓國 27,632 37,947 37%
新加坡 52,961 87,855 66%
菲律賓 2,991 7,696 157%

難道字面上的解釋,菲律賓比台灣更適合建立研發中心?吸引更多人才。這張表可以解釋菲律賓可以找到更多「人力」。無法解釋為什麼沒有更多人才。因此,需要再加上另一個指數:HDI 人類發展指數。

人類發展指數計算很繁雜,最粗淺的說,指數越接近1表示這個國家越先進,先進包含基礎建設,教育等等。(註4)


  GDP(美金) PPP(美金) 購買力相對於
生產力的增額
HDI HDI權重之PPP 人才庫
划算指數
台灣 22,453 48,095 114% 0.885 42564.075 90%
中國 8,133 15,399 89% 0.738 11364.462 40%
日本 38,917 41,275 6% 0.903 37271.325 -4%
韓國 27,632 37,947 37% 0.901 34190.247 24%
新加坡 52,961 87,855 66% 0.925 81265.875 53%
菲律賓 2,991 7,696 157% 0.68 5233.28 75%


將HDI的權重考慮進PPP中,並按照購買力對比於生產力的增加,計算出「人才庫划算指數」。在此指數很簡單的看得出來,建立以人才為主的研發中心,還是台灣最划算。(註5)

當然這個模型有很多缺陷和假設,但是起碼它是以確切的事實作為考量,並且可以具體的討論和修改。相較於譁眾取寵的喊叫人才外移的嚴重性,相信來得有用。


NNI, GDP, PPP三者的細節,請自行參考wiki

(1) NNI (國民收入)
(2) GDP(國內生產總值)
(3) PPP(購買力平價) :要注意的是,購買力評價,並不是很好衡量生活水準的方式。此方式較適合用於國家間互相比較,不太適合同一國家不同時間內比較。
(4) HDI 人類發展指數 
(5) 人才庫划算指數:=((PPP*HDI)-GDP) / GDP





註1:就在不遠的15年前(2003),當時出差到歐洲每個月要額外花上5千元台幣左右的電話費網路費,用以和家人聯繫。如今出差到歐洲每個月頂多花1千五百台幣元,就可以獲得比15年前更高品質的視訊通話。

註2:這裡有很多假設,假設國際企業需要的是人力而非人才,假設企業組織是理性的,假設台灣人才也是理性的。

註3:這裡的增額,和個人在單一國家內花費的感受會有所差異。換言之,要有所感受,必須要在差不多時間,同時在日本和台灣取得相同工作的類似薪資才能做比較。

註4:也因為HDI指數很大一部分涵蓋教育,因此數值越接近1,國民教育水準會越高。

註5:沒錯 人才庫划算指數 是自己的推測 並沒有什麼研究根據...XD

11/12/2017

中高階人才選用:成長心態鑒別的技巧




或許Carol Dweck這名字有點陌生,但是這位1946年出生的教授與她指導的學生(Lisa S. Blackwell, Kali H. Trzesniewski 這兩位才是研究作者,教授是列為共同作者) ,闡述的學習成長理論,卻經常的出現在教育界與職場上。

簡單的說,根據對美國小朋友的實驗,鼓勵「成長作為」比鼓勵「天賦能力」更能讓小朋友學習快,解決問題更有彈性,獲得更好學習效果。說的更直白一點,要多對小朋友說:「你做的很努力唷,好棒棒」「你做的方式很有創意耶,好棒棒」,千萬不要對小朋友說:「你好聰明唷,好棒棒」「你好厲害喔,好棒棒」。研究者把小朋友的內心,分成兩種心態(mindset):成長心態growth mindet,以及,固定心態fixed mindset。說的更直白一點,這些研究認為擁有成長心態的小朋友,未來的發展無限,人生就是彩色的。由於這個研究,引發了之後的更多類似相關研究,對於教育者而言,某些過去鼓勵方式,反而可能對小孩子有錯,而後,這些研究者,成立了 Mindset Works公司,開始賣服務與各類教材。

各企業巫醫們,自然能從中獲得啟發。比較好的像是lifehack,所做的此圖也還真的有啟發性。

對於企業組織要選用中高階人才,自然會希望找到「具有成長心態」的而且「很有能力」的人。換言之,就是要找在龜兔賽跑中,早就已經跑很快,而且也謙虛向學的兔子!對於已經具有十多年工作經驗的老江湖,確蠻有可能在面試過程中,不著痕跡的隱藏自己。那麼企業要如何找到具有「成長心態」的人才,而非找到「很會面試隱惡揚善」的人才?

當然企業不可能重複一次Dr Dweck的實驗,不過確可以用情境實例面試精神,找到簡單的三個「事實」來鑒別人才。

請緊記情境實例面試的原則:了解此人過去的經驗與能力,而非此人「對未來的憧憬與幻想」。換言之,企業組織雖然是為了未來,才需要雇用人才。但是,鑒別人才確必須要依賴了解這位候選人「過去的事實」。


1. 困難問題實例:最近2,3年來,解決最艱困的工作方面問題是什麼,自己如何解決?


這個問題必須要問的簡單清晰。畢竟一個有10多年工作經驗者,必然會遇到困難問題,而既然是最艱難的問題,必然有下列幾種狀態,確實問出幾種客觀狀態,來鑒別此候選者的成長心態。

(a) 問題的艱難程度:不能太過簡單無聊的問題
(b) 此人對此問題的獨立貢獻程度:也就是是這個人「做」的,而不是他「叫別人做」。
(c) 問題解決方式的創意:這和下一題可能有關,但艱難的問題不見得要用創意的方式解決。

如果是資訊科技產業,這個問題要修改為「技術相關的艱困問題」。




2. 創意問題實例:最近5年內,對組織做出最有創意的貢獻是什麼?


此問題的基本精神在於,一個具有成長心態的人才,一定是會做出有創意的貢獻。當然也不可能每天都有創意,把時間放長為五年,應該已經很寬鬆。必然要透過這個問題,以及接下來的對話,確實問出以下客觀狀態:

(a) 這個創意,是此候選人「做」的,而不是他「叫」屬下做,或者是「建議」別人做的。
(b) 這個創意,範圍夠大,確實有所貢獻。
(c) 這個創意貢獻是否能有實質證明。


3. 失敗問題實例: 在工作上,做過最爛最失敗的事情是什麼。


雖然這是面試的老問題,但此問題必須按照事實,看出是否有「避重就輕」。特別是,許多工作十幾年的人,在職場都可以歷練出舌燦蓮花的本領。因此要檢查幾個事實狀態:

(a) 問題的嚴重性:確實有些人運氣特別好,工作十幾年都沒犯錯過。但這個機率實在太低,當一個候選人簡單的講一些根本不是失敗的例子,大概就只是避重就輕。面試時,可以簡單值說:說這些失敗其實根本不重要,能否在舉一個「嚴重犯錯失敗」的例子。另外也有可能是,其過去十幾年來工作內容太不重要,以至於沒有嚴重失敗的經驗。

(b) 失敗的歸咎責任:詢問問題時,一開始請讓候選人自行暢所欲言,許多固定心態(fixed mindset)的人,在能夠暢所欲言的時候,自然而然的會把責任轉移到非自我本身。例如:「那時候我們的QA根本沒找到問題,所以後來系統出錯的時候...」或者是「當時我們的人力不夠,所以就只能拖延...」

(c) 事後的影響:成長心態的人,對於重大失敗會有決定性的影響,因此,這個失敗事件,能否對他後來的「行為」「想法」有改變才是重點。

固定心態的人,很有可能會說「以後運氣還不錯 就沒發生同樣的事情了」或者「也就是因為如此 所以我才想離職」,更慘的是,規避了解失敗的真正原因,特別是曾經當過主管的失敗例子:「因為之前的屬下太過自由導致出問題,所以我現在就很嚴格管理所有細節」「那時候跑scrum有很多問題,所以現在都不用scrum了」。

成長心態的人,則比較傾向找到失敗的真正因素,改善真正因素:「那時候跑scrum有某某問題,所以我們現在scrum會做XX調整」。而重大失敗,更是會變成具有成長心態的人,隱含的內心記錄的一部分。




8/14/2017

工作3年後 - 如何主動換個好工作

工作3年後 - 如何主動換個好工作

畢業開始工作2到3年後,是個轉捩點。許多專業工作者(例如工程師)都在剛畢業後2-3年就會主動考慮換工作。

要隨便換個工作不難,但是要換個「好工作」其實非常非常難。

最踏實的作法是對「換好工作」這件事情有具體的目標和可行的作法。雖然這和每個人的職業和背景的不同,而有差距,不過計畫的步驟其實差不多。

想要跳過說明,可在此取得「TS 換個好工作 計劃表」。

有很多原因,會讓工作2-3年的人想主動換工作(註1),以下是幾個常見原因:

(一) 未來發展:覺得現在組織沒辦法讓自己升遷,增加責任範圍,學不到技術等等。

(二) 生活品質:薪水不夠,加薪幅度不夠,工作時間過長等等。

(三) 組織狀況:大組織內政治因素過大,小公司極端不穩定,產業外移等等。

(四) 興趣:現在工作內容沒有興趣,感到厭倦無聊,或者發掘自己的興趣在一個截然不同的產業等等。

(五) 想創業:這不在本文討論範圍之內。(註2)


除了以上原因之外,「最爛情況」也可能是換工作的原因。所謂最爛的情況,是指「非理性行為」:年輕人畢竟容易血氣方剛,容易產生各種憤怒:「對微妙小事看不順眼而憤怒」,「因為覺得老闆好爛而憤怒」「覺得不被重視而憤怒」,甚至,「我的老闆沒被大老闆重視」也可能是原因。

但其實,企業組織只要沒有違反法律,這些爛原因,絕大多數都是無聊而且不必要的。因此也不在討論的範圍之內(註3)


要找工作很容易,要找到好工作很難

再次強調,換工作很簡單,但是要換到好工作很難。對於困難的事情必須要有計畫的完成它。

計畫如下:


(1) 了解自我原因


了解自己為什麼想主動換工作的原因,是最基本,但是卻最容易被自我扭曲誤解的第一步。

有個簡單的方式可以讓自己對自己「誠實一點」:將自己為什麼要換工作的三個最主要原因,依優先順序寫下來。根據80/20法則,第一個原因約佔80%,第二個原因是16%,第三個原因最多是4%。舉例如下:

80%:因為學不到新技術
16%:因為加薪幅度不到10%
4%:覺得厭倦無聊

先把80%的原因遮起來,模擬假設解決了80%的原因,只剩下另外兩個原因,還很想主動換工作嗎?如果不太想換了,才表示你誠實的面對了自己。如果還很想換,就表示那80%的原因根本不是主要原因,請換個主要原因再試一次。這步驟是要迫使自己誠實面對自己,了解自己真正想換工作的原因。當然,想要換工作的原因可能更複雜,但一定要先認知問題的存在。

因為「解決問題的第一步是認知問題的存在」。而如果不先了解自己真正想換工作的原因,那就很難了解自己認為「好工作」的定義。

當然在這個時候,很有可能會覺得不想換工作,或者想創業為自己工作,那也很好,重點在於找到自己心裡真正的原因。


(2) 足夠計劃實施時間


在台灣,知識類型的工作者,最好要有3到5個月的準備時間。以下的計畫就是以3個月的準備時間為準。

3個月看起來是個冗長的時間,但如果你只有2-3年工作經驗,只準備了3個月就換到適合自己的好工作,其實是極端快速的。要達到極端快速,需要妥善計劃。

如同精實創業和敏捷開發的「時間控制」原則,這3-5個月時間是固定的,如果期限內沒達到效果,應該重新檢討,重頭開始。


(3) 定義目標


當準備換工作,目標必須是要換個好工作。而定義「好工作」就顯得很重要。每個人的好工作定義都不同,但該目標必須要「解決當初最重要的換工作原因」。

目標的需求描述,可以是4至8個項目。描述的內容要和換工作的三大原因有所關連,但不見得要一比一對應。也可以加入額外條件,像是地點之類。最後,描述的目標一定要有幾個「參考公司名稱」,因為畢竟換工作,最終還是換到某個公司,目標公司並非表示你非他不可,而是有個顯著的參考值。

例如:

 * 要學到比較完整的軟體開發流程
 * 透過轉職加薪,要比現在多15%
 * 工作內容聽起來要有趣
 * 工作地點在大台北地區
 * 加班頻率不高
 * 有國外出差的機會
 * 目標公司:四零四科技,趨勢科技,LINE台灣


(4) 瞭解與目標的距離


了解與目標的差距,最簡單的做法就是「馬上去面試一次看看」。但這樣做是有點風險,因為許多外商,通常在拒絕應徵者之後,可能3-6個月都不太會讓這個應徵者再來面試一次。

其次,花半天的時間,上網搜尋相關資料,特別是在104, linkedin上的公開資訊。可以看出這些公司最近需要的人才的技術能力為何。通常比較大公司很容易找得到「面試經驗談」可作為參考:要記得只是參考而已。

另外,也可以透過linkedin找到該公司的HR或者主管,虛心請教哪些技術能力及程度,是必備條件。有兩點要稍微注意的是:(I) 目標應該放在知識與技術能力,暫時先不要考慮「軟技能」像是人際關係之類的。(II) 英語能力是屬於技術能力的一種,並非軟技能

列出此時此刻,自己和目標最大的3-5項差距:

 * 對比較嚴謹的開發流程沒經驗
 * 對Linux不熟悉
 * 英文溝通能力不太好
 * 線上程式測驗比較難 
 * 沒有大數據相關工作經驗


注意!如果在這個階段,你認為沒有差距了,就勇敢地去面試。一旦被綠取,那麼你也已經達到計畫的目的。然而,要是沒被錄取,就表示「實際上」的確有差距,必須要回憶面試過程,找到其中差距,然後用下一段(5)行動,來補足差距。


Action speaks louder than words


(5) 行動


計畫最重要的部分就是行動,沒有行動的計畫是死的。不過,好計畫也是行動的關鍵。不知道怎麼行動比較好?可在此免費取得通用版本的「TS 換個好工作 計劃表」作為參考。

換個好工作的主要行動有五項:

(A) 急速提升目前工作績效


快速且大幅提升目前工作的產出效率和在組織內評價,是縮短與好工作距離的「最佳做法」。絕大部分的用人主管與人資主管,判斷應徵者的未來潛力,是透過他「過去工作績效」。

換言之,要換個好工作,關鍵成功因素是把現在的工作做到最好!而且是「以別人的角度」認為你做得最好,而非從自己的角度。

實際做法是:

首先,列出三項在1-2個月內可以達到的「額外」工作目標。並確定達到之後,現在的主管「鐵定」會非常滿意。可以主動和現在主管確認,這些額外的目標確實有很大意義。當然在這個時刻,不需要跟他說你有換工作的打算。

接下來,用盡「所有能力」,去達成這些目標。所有能力包含以下各種可能:

 * 厚著臉皮請教同事應該怎麼做比較快
 * 快速學習新技能以達成目標 (參考下一段)
 * 在做的過程中虛心向老闆求教
 * 每天提早40分鐘抵達辦公室做這三項額外目標
 * 用80/20法則,找到目標的關鍵任務先行完成

絕大部分的人,無論是什麼樣的工作,都能透過這個方式,在1-2個月內,展示出「大幅提升績效」的結果。並且是會獲得「外界肯定」,而非自我感覺良好,自覺大幅提升。


(B) 急速學習技能 


在瞭解與目標差距中,已經列出數個技術差距,而每個技術差距,都應該可以用學習技能來補足。

快速學習的本身,也有一定技術可依循,請參考這篇:快速學習解決職場困境

每個技術差距該做的事情都不一樣。不管列出幾項差距,最好是「一項一項」逐一解決,盡可能不要同時解決。考慮現實,3-5個月最多也只能增加3個技能。而每個要解決的技能,必須有極為明確的目標。這也是極速學習的關鍵:清楚定義目標,在大目標下逐一達成每個小目標。例如:

 * 對Linux不熟悉:熟悉LPI-201, LPI-202,通過線上測驗
 * 英文溝通能力不太好:考TOEIC目標成績850
 * 線上程式測驗比較難:每天花10分鐘,到Leetcode或topcoder上找中難度的題目練習



(C) 急速打造通路


通路(Channel)是在商務上,將產品送至客戶面前的方式。

對於知識工作者來說,「你自己」就是產品。而企業組織,就是客戶,企業組織雇用員工也是一個「市場」,而市場,常常是被通路所控制。既然你是產品,就應該要妥善處理你的通路,而非讓客戶來決定通路。

最基本的通路,可能也是最差的,是所謂求職網站104, 1111之類,當然,有3年工作經驗,也可以用求職網站。但它恐怕不是最好的方式。

另一種通路是linkedin,和求職網站稍有不同,linkedin需要更大的主動性去維護 履歷表。

再者是獵人頭公司(headhunter),大部分的情況下,獵人頭公司對3年工作經驗者不會有興趣,當你只有三年工作經驗,獵人頭可能只會對你的聯絡方式有興趣,等你「長大一點」再跟你聯繫還不遲。然而,有些做法可以讓獵人頭提早對你有興趣。其中一個做法就是透過業界導師推薦。

最佳的通路是「內部推薦」。如果剛好有認識的同學朋友在該公司內部,那你的運氣就實在太好。但是如果沒有任何認識的人?創造認識的人就是最好的方式。

如何創造認識的人?透過linkedin或者其他社群網站了解內部員工都參加哪些活動,或者研討會。主動參加那些活動和研討會,就會自動認識內部的人。稍微熟悉一點之後,就可以厚著臉皮懇求幫忙送履歷表。幫忙送履歷通常不是問題,問題在於「是否真心推薦」才是重點。技術類型的工作,參與相關的研討會,參與比賽,參與開源開發專案等等,絕對是能獲得真心推薦的方式。


(D) 應徵/面試


當準備到一個程度的時候,就應該去應徵面試。何謂「到一個程度」,只要你按照原定計畫,2-3的月就一定會到某個程度。你就應該「驗收」努力的成果,而非覺得「不夠完美」所以想持續學習。

不夠完美是一定的,因為人不可能完美。持續學習也是一定的,因為學無止盡,但時間是會流失的,這也是為什麼一開始需要鎖定一段時間,無論好與壞,每一段時間一定要能驗收檢討成果。

應徵和面試的技巧,網路上各企業巫醫專家實在太多,就在此省略。


(E) 檢查是否朝向目標


要給自己固定一小段時間,檢查自己所作所為是否朝著計畫前進。最好是定在每週一上午9:00~9:15 (這時間有特殊意義存在,盡量不要改變它) 

要檢查三件事情:

 * 過去一週的行動,有沒有確實提升工作績效
 * 過去一週的行動,有沒有縮短與目標距離
 * 有沒有浪費時間在其他地方

(6) 最終結果與選擇


如果在時間內,確實被錄取「目標好工作」。那麼就應該作出選擇,決定要不要去。因為也許3個月後,由於你的工作績效大幅提升,原本一定要換工作的原因已經不存在,當然就可以選擇要不要換。

如果在時間內,並沒有被錄取「目標好工作」。那麼就應該從第一步開始,檢討哪邊出了問題。並且重新再做一次3個月計畫,然後,確實再實施計畫。即便第一次計畫失敗,也會讓下一次計劃成功。

*******

每個人都有適合自己的方式。但如果你沒有好方式來換個更好的工作,參考並實行這個計畫一定能獲得好結果。


*******



註1:也有一些種情況是被動或者被迫換工作。 最糟糕的情況是因為績效不佳而遭到資遣,其他情況像是:公司倒閉,公司裁員,組織重整,健康因素,家庭因素等等。被動換工作的通常是「措手不及」的,因此要採取略微不同的方式。請參考這裡。

註2:工作了2-3年,應該可以知道,創業和換工作截然不同。創業的成功關鍵請參考這裡

註3:不過,人類有各種認知偏誤,合理化既定決定,無論決定合不合理,都有可能被自己合理化。


4/20/2017

數據分析 - 獵人頭如何從Github尋找人才?


前陣子遇到某特殊的獵人頭hunter公司(參考:這裡),竟然是透過分析統計在github, gitbucket的程式庫,來找到軟體人才。

目前,github使用者數量仍屬商業機密,但估計約在2千萬左右(參考:這裡)。當然,使用者大部分從事軟體相關的行業。

資訊科技,特別是軟體的實際成果,容易在網路上展示。因此,如果要找到「軟體開發人才」,github是一個很好切入的地方。一般獵人頭可能會人工搜尋,但身為工程師,當然是寫程式找到大量資料。

從github找人,這做法有一些顯而意見的好處:

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點:

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力,非技術能力仍然需要其他佐證
4. 資料範圍過大,很難逐一肉眼看完

雖然我不是獵人頭,但基於工程師的精神,就嘗試一下解決「資料範圍過大,很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料,找到潛在挖角對象清單。

實際上做的步驟如下:

1. 了解gitbub資料如何取得:


github提供api可供程式使用。和許多Web Service一樣,也有完整的文件,請參考這裡


2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說,如果你已經登入github,用以下這個URL request就可以找到,以javascript與nodejs為關鍵字的所有程式庫:

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然,他的回應是json格式,需要簡單地用程式轉換。例如下圖,乃是搜尋和javascript相關,並且其位置在台灣的使用者:



測試資料回傳乃是json,調整格式成為csv,以便於日後在excel做簡單分析。


3. 了解測試資料內容


如果已經有在使用github,那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github,就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例:「搜尋和javascript相關,並且其位置在台灣的使用者」來說,程式會刻意收集following(有多少人在跟隨這個人的更新),follower(這個人跟隨了多少其他人)。此外,程式會額外計算push和javascript相關的程式庫的次數,取名為work,表示和javascript的相關工作在過去一段時間的次數。


4. 撰寫簡單統計程式,大量取得資料


當然,這個程式就放在github上。請參考這裡

程式本身是python撰寫,需要有github帳號密碼才能使用。


5. 結果


以上述範例:「搜尋和javascript相關,並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆,給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。