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

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參與。此人並非應徵者的主管,也可能不整個甄選過程出任何意見,但卻可以說對任何應徵者說「不」。很明想的是希望企業人才越來越好,而非越來越平庸?

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

這本書的啟示?

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

10/03/2018

建立高度自我激勵之軟體開發團隊的三個方向 (軟體主管的31堂課)



1999年美國的籃球夢幻隊1992 dream team 是所有籌組團隊的人遙不可及的夢想。他們除了籃球技術精湛,經驗豐富之外,更重要的團隊都有拿到奧運金牌的唯一目標,此一目標會讓他們自我激勵,根本不需要額外的刺激。這樣的團隊組成似乎可遇而不可求,在軟體開發的世界幾乎鮮少看到例子。

無論如何,建立能高度自我激勵的團隊,是主管最重要的工作之一。如果你是團隊主管,你必須認識到這是你最重要的任務。

自我激勵會造成工程師的職涯成長,而看得到自己的職涯成長,是能驅動效率的最好的因素(註1)。

軟體開發工作,通常是需要高度的心智活動以及集中的創造力。要造就高強度心智活動,幾乎很難單純由「薪水」或者「物質獎勵」來滿足工程師。加薪獎勵與升遷固然非常重要,但它能維持的效果頂多3-6週,之後所有的工程師都會認為這樣的加薪獎勵與升遷是「理所當然」,並且很快地將獎勵拋諸腦後。這不是說工程師都不懂惜福,而是研發工作本來就很大部分的來源會來自成就的滿足感,而成就的滿足感幾乎是加薪升遷無法長期提供的(參考 1)(註2)。非營利事業有可能天生就存在這樣的激勵因素,例如,慈善組織試圖拯救世界的所有窮困兒童,研究組織試圖大幅延長人類生命到200年...然而這些組織一般都有極為獨特的目標以及具有個人魅力的領導者。

一般的營利組織以及軟體開發團隊如何建立一個能自我激勵的團隊呢?

有三個方向:(1)選對人 (2)找交集 (3)自我導航


(1) 選對人

在選用人才時,就先確定此候選人是正面思考,能自我激勵,自我成長。因為要維護一個人的正確態度,比要矯正一個人錯誤態度來得容易太多。

換言之,選擇已經能夠自我激勵,並且確定此候選人在他過去工作經驗中,已經有自我激勵的事實。

不要選擇個人技術能力很好,但卻在自我激勵上面有非常負面的紀錄。因為,要培養技術能力並不難,但要改變人類的思考模式實在難上加難。現存的coach教練式領導,不過也就只是希望透過引導,造成行為上的調整(參考富比世英文版?),要引導到行為心態的調整,教練(coach)幾乎必須要和學員長期合作才有辦法做到。

選擇的重點在於透過過去的實質發生的紀錄,而不是透過詢問未來的問題。這個做法在選人時非常重要,選擇能高度自我激勵的人才,此人必須在過去工作時,已經展現高度自我激勵的情況。例如,你可以詢問面試者:「請問你最近工作上遇到最艱難的狀況,或者壓力最大的狀況,當時你是怎麼處理的」。這個問題重點在於"最艱難"以及"當時怎麼處理"。有時候面試者可能說沒遇過太艱難的情況,那麼也可以詢問"普通難"或者"壓力普通大"的情況。一個工作超過3年以上的人,當然可能運氣超級好,從來沒遇過艱難狀況,然而絕大部分的人,都可以說出幾個艱難狀態。這時候,不需要太早評斷,也不用加入討論,而是要徹底瞭解,在這個狀態下,面試者通常會表達過去的事情和想法,暫且將其想法放在一邊,妥善記錄事實。最後再由事實來判斷。

舉例以下的對話為例:

主管:「請問你過去遇到工作壓力最大的時候,當時是怎麼處理的?」

面試者:「之前在HXC工作時常常加班到很晚,要趕專案當然覺得壓力很大。怎麼處理喔?就想說當練功啊,學到東西我就要離開了」

主管:「當時你如何判斷已經學到東西然後可以離開了」

面試者:「呃?...就那時候我負責的app都推出去了」

此例的事實是。面試者因環境工作時程長壓力大,處理的方式是轉換心態-當練功,並且設定好離開環境的方式。請記得在此並不判斷好壞,而僅是記錄而已。然而,設定好離開環境的方式並不是以學到東西為主,而是做完東西。光是這樣可能還不足盼對此人是能積極自我學習還是消極無法激勵,需要更多挖掘過去的行為的討論才會確定。



(2) 找交集

我們不可能知道別人腦袋在想什麼,每個人都有所謂 left-hand-column,即便已經選擇最能高度自我激勵,自我成長的人才進入團隊,而且他們也都是非常坦誠並努力工作的人。但我們要知道每個人都有不能說,不想說,或者不適合說的事情。 
有些領導者會試圖找出這些事情,但其實有沒有找到不重要,重要的是「重視left-hand-column的存在」。



一個好的領導者,會找出交集。確保雖然人人有不同想法,但整合個人,團隊以及組織的交集,大家可以獲得三贏狀態(win-win-win)往同一個大目標前進!

當然,一個能力好而且能自我激勵的成員,可以自己找到此交集。不過身為領導者或主管,應該要時時注意:每人對這個交集其實都不太一樣。但好的團隊的每個人,應該都有部分交集。

最底線是:一定要避免三輸的局面。聽起好像很荒謬,但軟體開發的世界偶爾常聽到雙輸或者三輸的狀況。不必要的長期加班,幾乎都會造成雙輸或者三輸。長期加班必然會造成人才的耗損,幾乎也不能避免地造成團隊無法緊密成長,所以起碼就是雙輸,最後也常常造成組織本身無法長期經營,那就變成三輸了。

要建立能自我激勵的團隊,找到每個人不同的交集點。如果真找不到,則很有可能該人才並不適合這個組織,如果一半以上的團隊成員你都找不到目標的交集點,或許你本人並不適合當領導者。

交集點的例子很多,某些有資深能力好的工程師,除了團隊環境之外,或許可兼顧家庭是職涯的重要考量。因此,彈性的工作時間,和受到控制的可在家工作,就會是這類資深工程師(註3)的「left-hand-column」而這可能是最容易取得交集的地方。做法很簡單,就是讓資深工程師自行定義產出和目標,



(3) 自我導航

自我導航(Autopilot)是指團隊成員知道自己為什麼要做,知道該做什麼,知道怎麼做,知道什麼時候做。而更有甚者,他知道自己什麼還不會,所以需要特別努力學什麼。

一個能自我導航的工程師鐵定是資深的工程師,他會自我衡量自己在團隊中的「交集」也會自己「選擇」適合成長的環境。換言之,根本不需要煩惱這樣的成員。

對與已經是自動導航的工程師,僅僅只需要「教練式引導」(coaching) 。領導者或主管,應該必須對coaching有一定程度的了解,如果還不了解,現在就是學習的好時候。

在此最底線是千萬不要micromanagement -  也就是枝微末節都要管。大部分的資訊工作都是高度腦力工作,枝微末節都要管意味兩種可能
(1) 團隊成員根本無力勝任這樣高度腦力工作,而你組出這樣的團隊表示你也不適合作為建構團隊的人
(2) 團隊成員可以勝任高度腦力工作,但你身為管理者想要插手,表示你並不了解高度腦力工作的統御管理方式,所以你大概也不適合作為建構團隊的人。

要怎麼樣知道領導者管理者是不是「微觀管理」?只要看他實際做的事情就知道,當時「實際要做的事情」超出「本身的意義」就是這類型。

舉例來說,上班有規範時間,並非微觀管理,沒有規範在大部分得時候反而浪費大家的時間。然而,毫無彈性的硬性規定人必須出現在辦公室的時間,其實就超過規定上班時間的意義。對軟體開發團隊來說,上班時間規範是為了讓團隊容易一起面對面討論,互相砥礪解決問題。例如組織定義9:30~18:30是工作時間,然而,因個人因素不在範圍之內,例如想要8:30~17:30只要該成員能確保他的scrum團隊夥伴都知道他和大家時間略有不同即可,成熟的團隊的紀律來自「自我認知和團隊合作」,並不需要管理枝微末節。同樣的,「規定現在要加班」也是某種程度的管理枝微末節,順便強調一下加班其實是解決問題最爛的方式,尤其是被規定加班


抱歉 沒有什麼神奇的快速方式!

組織理論其實並沒有捷徑,也沒有什麼神奇的快速絕招。然而只要方向正確,忍耐個幾個月都會看到成效,但是簡單的路總是難行。當然,特定快速的環境 - 例如非常新的新創產業,還不確定能否獲利 - 似乎不值得這樣長期投資?也有不少人主張時間不等人?然而,對大部分的資訊產業來說,大部分的情況是跑馬拉松而非短跑。



技能與績效的考量:


在這裡省略一件很重要的事情!
我們並沒有討論技術能力和工作績效,但其實在軟體開發團隊中個人技術能力與個人工作績效是非常非常重要的!沒有好的能力與產出,要怎麼激勵自己恐怕都沒太大用處。然而,績效和能力應該比較容易在面試與履歷表中檢核出。因此才不在這裡討論。





註1:  要使團隊有高效率,自我激勵是最好的方式 。然而其他方式也存在,例如鞭子與蘿蔔。
註2:  但是如果薪水實在太少,不能滿足基本需求,就不在此討論範圍之內。
註3: 不過要特別注意,資深和年紀沒有絕對關係。必須要是做事態度資深,而非年紀資深。

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 (獵人頭) 鑑定看看是否有效果。

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

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