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

2/24/2019

主管的責任:三件不能做的事情 (軟體主管的31堂課)


作為用人主管,是帶領團隊前進的最重要的人。無論團隊是2個人還是200個人,主管應該對團隊的成敗擔負最大的責任。

企業內用人主管(people manager)是指的要直接負責員工的招募,任用,考核,薪資,工作指派,管理,領導,培訓以及資遣。

而現代化企業團隊本身的績效,最大影響因素其實不是某個別員工的能力與態度,團隊主管(領導者)才是最大影響。

無論團隊大或者小,也無論是什麼樣的團隊。團隊主管會大幅影響團隊合作(參考這裡),也會大幅影響員工對團隊的參與感(參考這裡),也會大幅影響個別員工的績效(參考這裡)。

簡而言之,團隊主管承擔大部分一半以上的成敗責任,如果是小規模的團隊,也就是團隊加主管成員為五人以下,團隊主管會承擔100%成敗責任。(參見這裡,這裡,這裡)

當然根據組織和工作任務的不同,主管有不同的事情該做。不過,有三件事情是管理上,一個現代企業的好主管,不能也不會做的事情:

(1) 將個人與團隊績效不好,歸為外在因素 
(2) 以情緒感受為先,事實為後
(3) 無法修正自己溝通方式,認為部屬難以溝通

1. 將個人與團隊績效不好,僅歸為外在因素或歸責於部分團隊成員 


當主管個人或者團隊績效不好,無論是業績數字不好,或者專案延誤,或者原定目標沒達成,當然是很多不同的原因導致。

然而,作為主管應該知道績效的大部分來源是「主管與主管的領導管理」,因此,績效不好,當然要先「檢討自己,以及自己管理與領導的方式」。

這並不是說,外在因素沒有影響。當然許許多多因素都會影響成效。然而,如果不是先檢討以及改變自己,作為用人主管,最容易落於「怪罪」

2. 以情緒感受為先,事實為後


某些主管大概參考了許多以「權力」為中心的書籍,例如:這本或者這本。又或許根據個人經驗,知道要說服別人,情感優先是非常重要的。因而在優通重要事情,或處理意外時,常常會以「情緒早於/優於事實」的方式進行。

最明顯的例子就是,團隊某些成員犯了錯,主管可能在第一時間會是說:「我很生氣,因為你做了某某某事情,後來某某結果發生」。

但合理的情況,應該是「某某結果發生了,是因為你做了某某某事情,因而我很生氣」

這並非在字句上的咬文嚼字,也不是探討主管的講話藝術。問題是在於主管本人內心深處事實的重視表達。

前者主管先重視的是「自己個人心情好惡」,其次是「團隊成員怎麼做事」,最後才是「那件事情的結果」。

只要幾次之後,團隊成員在工作進行上就有兩種可能。(a)成員在潛意識中,自然會認定主管是以情緒優先,知道自己無論績效能力好壞,最重要的是討老闆開心,對自己職涯不利,若有機會自然會儘速離開。(b) 成員不知道產出的標準為何,只知道主管的情緒標準。然而,情緒標準在現代化企業中難以作為成效指標,因而難以在結果上確切達到組織要的效果。 



(3) 無法修正自己溝通方式,認為部屬難以溝通


特別是在小團隊(少於五人),主管與團隊成員的溝通好壞,並非取決於團隊成員,而是取決於主管本人。

主管認為某團隊成員難以溝通有幾種可能,但這些可能性都不是「難溝通」的理由,主管應該都能和任何部屬達到「工作期望的有效溝通」 

(a):某成員是我招募進來,但怎麼講都很溝通:如果他真的這麼難溝通,表示招募選用對該主管來說是失敗的,換言之,責任仍然在主管身上。

(b): 某成員不是我招募進來,怎麼講都很難溝通:主管擁有考核和解雇的權利。難以溝通的時候,應該以事實溝通成效,如果主管對自己有權限的屬下都難以溝通,更別說沒有權限的橫向單位。

當主管認為某屬下難溝通,最糟糕的做法恐怕就是在一對一面談時,坦然的溝通說:「我覺得你很難溝通」。因為這表示,主管在內心深處不能理解「溝通是雙向」的簡單事實。因而,很難溝通只能見裡在於「我們兩個很難互相溝通」的事情上。根本不可能建立在「我個人沒問題,是你很難溝通」的事實上。

和前段相同,這並非咬文嚼字,也不是認為用人主管是不會犯錯的聖人。而僅只是要說明,特別是擔任主管的時候,溝通絕非單向問題。必須要先認定問題所在,才能找到正確解答。

當主管認定溝通問題單存於對方,那麼問題鐵定無解,因為問題鎖定方式已經不正確。單只要求對方「改善溝通方式」,最好情況是對方改善了,但是自己沒改善,此問題還是會出現在其他部屬身上。造成主管認為自己的屬下統統難溝通,這種主管應該儘速被開除才是對組織最有貢獻的時候。

當主管認定溝通問題在於雙向,解答方法自然呼之欲出。有幾個方式可供參考:(a) 密集但是以事實為基礎的短溝通 (b) 盡可能使用精確直接而且短的溝通方式 (c) 建立互信關係用以輔佐溝通。 最近沒麼時間所以上述方式會在之後文章再說。

參考資料
(1) 自我感覺良好的認知能力不足

2/08/2019

如何在工作中成長


過去招募時,常聽到軟體工程師的離職原因,是因為在公司已經沒發展空間,無法成長。在某些情況下的確有可能,但更多情況下是工程師限制了自己成長,並非公司已經沒有成長空間。

每個人所謂的成長有很多種類,有些人追求的是技術的成長,有些人則是職位的成長,當然每個人多少都會追求薪資的成長。無論如何,環境確實是職涯成長的重要因素,只是工作環境的選擇,通常只決定了個人成長的一部分,而非全部!

如何在工作中成長有幾個要點:

(1) 培養成長心態


成長心態與固定心態在過去幾年中常被討論,無論是ted還是書籍皆如此。

簡單的說,擁有成長心態的人會視問題與困難為自己的挑戰,知道克服了挑戰之後,自己會成功並且有所成長。並且,擁有成長心態的人,會審慎看到自己以及環境的問題,不會一昧地把問題歸咎於外在因素。並且,擁有成長心態的人比較容易知道努力不見得會成功,但是不努力鐵定不行。

關於成長心態還有很多常見故事,請自行上網搜尋。但在此舉個反面的例子:完全不具備成長心態的人,會將自己的問題歸咎於環境問題,直接的表現在職場上就容易極短時間換了許多工作,詢問過去做得不好的事情時常歸咎於環境等等。


(2) 建立能和現在環境結合的學習清單


只要是正常合理的公司,通常都有值得學習的地方。有時候,光是公司仍然還能賺錢這點,就已經值得學習。

然而,軟體工程師的天性就是學習「新事物」。對於已經熟練的技術和事物,久了總是會覺得厭倦。厭倦倒是無所謂,重點是厭倦之後怎麼辦?成熟的軟體工程師通常會了解,真實的環境需要的是「能正確無誤並且低成本有效率的工具與環境」,而非需要「最近好像很熱門的嶄新技術」

成熟的軟體工程師能找到環境與自己的平衡,如果要學習新事物,就應該建立學習的方向,最簡單的方式不外乎就是建立學習清單。

技術上的學習清單容易取得,但是,能和個人現在身處的環境結合就需要認真的想一下。

(3) 主動執行

執行自己的計畫聽起來容易做起來難。大部分的情況下,軟體工程師(特別是處於大公司中)都會認為自己在為別人工作。

事實上,至少在台灣就業市場上的勞工都是在「為別人工作的情況下為了自己而工作」。因為現行的台灣就業市場,已經非常接近自由透明的市場,只要「有能力」通常都可以有非常大的選擇。

執行各種學習計畫的要點在於「這是為自己而做」而非為了別人。



一個考慮離開目前環境的軟體工程師,通常會將「能在工作中成長列為尋找新公司的重要條件」。但其實更重要的是要讓自己有能力「無論在任何環境中成長」是為更重要要做的事情。





1/02/2019

Scrum的缺點



當手上有榔頭,看到任何東西都像釘子 -- Abraham Maslow 1966
------

過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。

當然也有不少文章討論scrum的缺點(請參考這裡)。然而,Scrum是個在agile development範疇內的方法論,它是個很好的參考軟體開發流程的工具,而這工具有其「特性」,無所謂好與壞,當然就無所謂優點與缺點。

然而,這些特性不可否認,需要對該工具有一定的認知,特別是一些「預設要知道的事情」,以免誤用。舉例來說,當你使用榔頭的時候,大概會知道它是用來釘釘子,而不是拿來釘螺絲。此外,你也會大概猜到,右手拿榔頭左手扶著釘子時,要記得不要敲到自己的手指。

以下Scrum缺點(特性),也是常見的陷阱僅供參考。


(1) 團隊成員對Scrum的了解必須一致,工作能力最好也要差不多。


Scrum的運作中,高度依賴成員的自主性。Scrum Master雖然很重要,但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質,還是靠所有成員的能力。

換言之,如果有人技術能力特別糟糕,或者技術能力雖好,但對於Scrum的運用與瞭解和大家都不一樣,那麼有可能會有意想不到的長時間磨合期。


(2) Scrum並不會真正加快速度,只是讓速度透明,讓大家專注重要的事情。

許多企業導入scrum的目的是為了加速產出。事實上,Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明,同時也讓團隊進行的速度變透明,讓大家更容易專注於正確的事情上。

整體來說,Scrum會減少各種不必要的浪費,讓整個專案效率提升,但就個別事情的速度而言,Scrum並不會提升。換言之,軟體工程師仍然需要有自己的方式來提升個人效率。


(3) Scrum並不會解決工作內容的相依性 


傳統的專案管理方法論,常常會提供類似甘特圖的工具。然而,Scrum方法論專注於某件任務(story)的完成,而隱含著希望每個任務的相依性,會在團隊成員的「成熟考慮」下被處理完成。

換言之,有相依性的工作就是有相依性的工作,軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失,也並不表示當有個寫得很獨立的story產出時,就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具,都應該有自己的處理相依性的方式。


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/28/2018

企業巫醫:手寫的工作筆記,讓你跨越困難



筆記本加上一支筆,大概是最便宜,最容易改善工作的工具。

網路上有非常多「如何做筆記」的相關文章,特別是如何做學習筆記(例如這裡,這裡,這裡)。在職場上,特別是知識工作者,幾乎都有做記錄的必要,然而由於資訊工具的改良,許多人會改用手機,平板,電腦來做筆記。畢竟數位化還是資訊快速膨脹的主流。

在此並非建議走回頭路。數位化記錄,絕對是必要而且有幫助。企業裡面的知識庫,wiki以及追蹤工作工具(jira, redmine, trello等等),絕對是讓組織整體提高做事的透明度,持續傳遞經驗知識的最好方式。

然而,對於個人職涯發展而言,還是建議要透過工作筆記,來提升職涯發展,增加自己的能力與視野的人,最好還是擁有一套自己手寫記錄的方式。

原因如下:


(1) 手寫的學習效果遠遠超過打字


有太多太多研究顯示,手寫的理解與記憶效果,遠遠超過打字。請參考:這篇這篇這篇這篇。或許有人會說,工作筆記又不是學校筆記,但如果深究這些研究會發現,其實概念相當一致,也就說,手寫某件事情,會增強對這件事情的「理解力」,「創造力」與「想像力」,然而打字卻不會!而廣泛知識類型的工作也是,職場上對事情的理解和掌握越高,越有想像空間,當然工作本身做得越好。


(2) 成本低

當然,現在平板也可以手寫,所以廣義地說,如果習慣的話,平板也是可以。然而,再貴的筆記本,其運用成本,仍然比平板低。除了價格之外,運用成本包含環境限制(例如要充電)。


(3) 手寫讓思考聚焦


無論是用哪種輸入法,即便是最簡單的注音,只要一段時間,每個人的打字數度都會遠超過手寫速度。然而,正因為如此,手寫可以讓頭腦有思考聚焦的功能。腦中會自己思索,應該聚焦的關鍵,進而思考關鍵的意義,這對掌握工作的要點,並且讓一個人在繁忙工作中,找出一條正確的道路有絕大的幫助。請參考這篇


那麼,要如何做工作筆記?


(1) 立刻買一本


假設你沒有筆記本,也沒有做工作筆記的習慣,那麼就「現在馬上去買一本」。習慣的建立是需要時間。不建議去買很貴的Moleskine筆記本,即使是代購團購的Moleskine也是頗貴。當然它的質感,可長期保存,書寫良好,硬殼和收納設計都首屈一指。不過其實隨便到文具店買不到一百元的即可。



(2) 上班中隨身攜帶,隨時紀錄



聽起來簡單,但要養成比帶手機更隨身的攜帶是有點難。無論是開會,還是座位自己位子上,確保重要的事情,都應該即時簡單的紀錄。筆記本應該是隨著時間紀錄。而且,並不限制記錄內容。如果是開會,建議使用心智圖的方式記錄。
提醒一下,筆記本並不僅止手寫手畫,也可以將重要的檔案email,直接列印貼在筆記本上。未來當重新檢視工作時,有莫大的幫助。

紀錄的內容以「事實」為優先,同時當然要記錄時間。工作記錄並非你自己的日記。雖然,這是自己私人的紀錄,但最好不要紀錄感想或情緒;而是確切記錄事實,因果,困難,解決方案,效果等等。

除了記錄之外,筆記可涵蓋「簡單計畫」,也就是「本來打算如何做」。例如,在工作中發現你對某技術不了解,於是你就在筆記本中草草紀錄一行「學習某技術」。隨即在這行字下面,就可以做得簡單的計畫,例如:1. 10分鐘上網查詢。 2.問一下某某同事。 3.在本週末練習此技術。

當你有任何打算做的事情,拆解成為執行的行動,簡單紀錄,日後就很快可以檢查這些行動是否完成,或者計畫是否要改變。

要注意!工作筆記是幫助你「動起來」的最好方式!


(3) 每月摘要,自我檢討


工作筆記,最最最重要的功能就是,每個月找個20分鐘的時間,將過去一個月自己做的筆記認真看過。然而透過紀錄,回答自己以下問題:(a) 這個月我有做幫助公司組織哪些重要事情 (b) 這些事情做完了沒 (c)隨便換個人也能做這些事嗎? (d) 過去一個月我有沒有學到新事物(e) 有沒有遺漏重要的事情還沒進行。將這些問題,自我回答到筆記本中。
這種檢討方式,特別適合在坐捷運的時候進行。


筆記本加上一支筆,大概是最便宜,最容易改善工作的工具。如果你認為自己的職涯發展受到侷限,或者遇到困難,而你又沒有做筆記的習慣的話,那麼其實不妨一試,只要長期累積必有成效。





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/19/2018

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


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

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

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

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


(1) 個人永遠都有選擇



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

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

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

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

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

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

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




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

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


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

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

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

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

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

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

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



10/14/2018

企業巫醫:20分鐘搞定「工作做不完」的問題?



上班族常會遇到的老問題是:「工作做不完怎麼辦」

工作做不完是個老問題,解決問題的方法也很簡單,然而簡單事情不見得容易做。更重要的事情是:你需要正確的檢視現況,才能真正解決問題。因為每個人的「工作做不完」的實際情況都不同。舉例來說,假設你是在無良的黑心老闆血汗工廠,那麼你的工作做不完的解決方式應該是儘早辭職,而非增加效率。

以下步驟確保可以幫助你解決這個問題:


步驟一:暫停!休息5分鐘! 利用15分鐘進行計畫



1. 休息5分鐘


除非你的工作是急診室或者核電廠這類人命關天的地方,一般的上班族,一旦遇到工作做不完,慌慌亂亂急急忙忙的時候,其實第一件事情應該先放空自己。找個安靜的地方(萬一真找不到可以藉故離開辦公室幾分鐘),先盡量將自己的思緒清空,沒辦法放空冥想的話,打個手遊也可以。當你的思緒紊亂,壓力暴增,往往會使用直覺處理事情,使用直覺處理並沒有錯,但如果「只靠」直覺處理,就會失去成長和學習的機會,更糟的是,直覺處理事情通常和情緒結合在一起,關於這點請參考腦的結構杏仁核

所以讓自己休息五分鐘!


2. 計畫15分鐘


休息之後,拿出紙筆,先對現況做計畫。
列出事情的四個象限:重要/緊急矩陣(參考這裡) 。
如果你已經熟知這個事物分類方式,那就可以直接挑過這段,並思考自己為什麼不做這件事?

 2.1 重要且緊急:

 就是要專注處理的部份

 2.2 不重要但是緊急:

 要犧牲,或者交給別人,或者是忙碌狀況。但通常這種事情都是工作做不完的主要來源。最好的方式是縮小事情的影響。常見不重要但緊急的事情,不外乎老闆索取各種資料,感覺很急,

 2.3 不重要且不緊急:
  千萬不要去做它!普通上班族通常不小心會落入去做不重要且不緊急的事情,而且還不自知。最常遇到的事情是:對小事情花時間做無謂的討論。

 2.4 重要但是不緊急:

  千萬不要忽略他!忽略這裡,就無法徹底解決工作做不完的問題!



步驟二:按照計劃:逐一解決重要緊急的事


在計畫中,條列的重要與緊急的事情,要「逐一」處理。先不要想要同時處理,做個清單,搞定一個事情打個勾。

這聽起來簡單做起來很難。

有幾個簡單的執行要點可供參考:

(a) 自己找到專注工作的場地。很多工作其實不限定工作場合,只要你事先跟老闆講好,其實是可以嘗試找不會被打擾的地方好好專心把事情搞定。例如,在主管同意之下,中午三小時在公司附近某咖啡廳寫程式。在近年來開放式空間流行的狀況下,這點相對重要!

(b) 不要隨時檢查email與短訊。除非你的工作是急診室醫生或者某些人命關天的意外處理者,否則不應該時時檢查聯絡工具,你應該是控制工具的人,而非被工具控制的人

(c) 設定解決的定義。緊急而重要的事情的「回應」不代表解決。解決事情要像是恐怖片裡的殭屍,當你沒有徹底將它打爆頭,它很有可能會再爬起來咬你一口。


步驟三:重新檢討計畫,找到提高效率的方式,專注於重要但不緊急的事情規劃和執行


為什麼要專注於重要但不緊急的事?因為重要的事情如果都先處理好,可以大幅改善「未來還會有工作做不完的問題」 而且同時減少重要且緊急的事情發生。畢竟很多重要緊急的事情,就是當初重要但不緊急的事情一路拖延導致後來變緊急。

因此,這步驟用以確保可以有計劃地執行「重要但不緊急」

有幾個方式可以確保自己不遺漏「重要但不緊急」的事情

(a) 隨時檢查中期目標:組織通常有偉大的長期目標(例如登陸火星),但也由於通常太偉大,所以必須要逐步以中期目標達成。個人應該將中期(3~18個月)目標當作為重要的事情,而非最近短期目標。因為,短期事物常常會被迫打斷修改,就會容易淪落於被時間追趕而非控制時間。

(b) 每天排定固定時間處理「重要但不緊急」 即便是1小時,長期下來也會有效果。萬一不得已要加班,應該要加班處理的並非緊急的事,而是重要的事!

(c) 其他 (有空再說明此處)




步驟四:按照計劃,完成重要的事 ,並執行提高效率的方式


倘若已經執行到此。就可以考慮提高效率的方式。
其中最重要的方式就是「提高本身知識與能力」

提高工作效率有很多種方式,請參考這裡,或者這裡


步驟五:檢討成效,修改計畫


每個計畫都應該確實被檢討,自我檢討當然很好,不過,秘訣是請你認為做得比你更好的人幫你檢討計畫。

倘若這篇文章有某件100%保證有用的方式,那麼「請一個你認為比你厲害的人幫你檢討你的計畫和成效」是最最有用的一點。

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/19/2018

企業巫醫:創業初沒準備好 就先別找工程師(讀書心得)


Don't hire a software developer until you read this book是一本有趣的書,它的副標題是:學習如何管理應用程式的開發流程,確保你的手機程式,網站,網路應用的產品會成功做出來。

這本書和一般的企業巫醫做法略有不同,它只專注在一個單純面向,就是「非軟體人員如何建構軟體開發團隊,並且做出自己要的產品」。實務上,它是一本工具書。裡面的Pro Tips直接而且不廢話的指出應該要的做法。

這本書花了好幾個章節,大致闡述了近年來軟體開發的相關技術與運用,並把重點放在非技術背景的創業者,如何組織建立軟體開發團隊,並且讓團隊往期待的方向前進。

做得到書上的內容的人,大概就是程式設計師心中的好老闆,或者是好PM。

然而,這本書其實也非常適合給「程式設計師」閱讀

它展示非技術人員領導軟體產品開發「真正關心」的地方:也就是實際產出。至於開發人員使用的程式語言,使用的軟體工具,甚至想要把產品做的完美...這些都是不是考慮的要務。

例如,在書中說明新創產品開發常犯錯誤的幾條

(1) 為求完美把錢燒光了:

MVP需要的是最小規模的產品以及最好的品質。但太追求完美因而增加太多附屬功能,在作者來說是一種無法控制的浪費

(2) 輕忽看似很小的需求規格改變


例如某些開發人員會說「這不會花太長時間,只是把按鈕從這邊移到那邊」。開發人員當然會負責搞定,但是要求預估時間是創業家一定要做的事情

(3) 忽略測試


測試的重要性應該不用多提。然而非技術人員很容易忽略測試的重要。

(4) 即將上線前做需求改變


對作者來說,這等同於自殺任務。其實資深的軟體工程師在內心深處都很清楚這點,但是創業者或PM想要自我毀滅的時候,又有多少人可以阻止?

(5) 開發中後期增加人力以加速開發

在人月神話這本書中有很長的篇幅描述,很多時候增加程式設計師只會讓專案速度更慢。



此外,一般開發人員也可以透過這本書獲得Lean-Startup的精神概念與實務上Agile開發的整合。
舉例來說:它說明了Agile原則,以創業者的角度,來看agile的各種方法論對軟體開發的好處。並且也拿實際工具(Trello),展示一個創業者實際對開發團隊該做的動作,連同移動Task Card都說明很清楚。MVP,如何做出最小可行規模的產品。從創業者的角度,來看這些工具,其實更可以讓軟體工程師知道專注於最小變動需求的好處。

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個工作並沒有「留才」的意願。兩年半是最低限度檢驗一個工程師,在技術上能取得「市場驗證」的時間,兩年半表示工程師至少經過兩次以上的績效考核,並且其工作的正面負面評價也容易以事實檢驗。

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

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

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

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


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






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在新創和有對消費性市場服務的公司就是個很大的缺口,此外,大數據在銀行產業似乎也是同樣缺口。



6/23/2018

The history and talent market of crawler for online-store


This article contains a brief of history of product comparison of online-store and short survey of 8 TW’s organization
Crawler and full indexing of web for online store became a pretty mature technology in Taiwan. There are not much technical difficulties to build a decent crawler. The real key points are (1) patient (2) patient and mature engineer mindset (3) patient and customization on specific needs.
Almost every local companies leverage the same technology stack.

History


Price comparison requires web crawler and full text indexing search engine as foundation. Therefore, this brief of history shows not only the evolution of technology in past 23 years (#1) but also the overview of talent market in Taiwan.
Taiwanese started to build web crawler since 1995, the earliest local crawler is yam (1995) and kimo (1997). Kimo was acquired by yahoo in 2001. During 1995~2001, the technology of crawler was limited by environment itself. Meaning, network bandwidth and data-center cost were the main reason to limit crawler. Full index search engine was still task which need sophisticated knowledge in both data structure and file structure. Talents at early internet stage sometime worked more on infrastructure and basic implement of algorithm. For example, almost all EC need to host their own email server (#2) In university, the algorithm, math, protocol or conceptual classes were major thing students need to learn.
After 2000 dot-com Bubble, crawler and product listing in Taiwan grow slowly. However, many tools and platform emerged during 2000 to 2010. Firstly, stable version Python 2.0 released at 2000, Lucene (search engine) became top leave Apache project at 2005. However, the most critical service should be “google” in this period of time. Soon google’s service started to impact Taiwan, just a few years google became the most biggest crawler and web indexing around the world. It is still the best crawler and indexing service at this moment. Gradually PChome, yahoo store grows their own store-hosting during 2000~2008. Talents in this stage had more changes to focus on business requirement. There were more and more students in University learned application development, software engineering and software project management, those are the keys in eBiz to make things happened. Google, FB and AWS started impact the web development world since 2005, there were some interesting free service opened for example google shopping API(#3) In 2010, the elasticsearch’s first release created a whole new world. Although elasticsearch was just leverage Lucene as search engine and focus only on how to make this engine scalable and easy to use, it did help all engineers to focus only in building application, instead of reinvent the wheel. So does other big-data platform/tools, for example hadoop. The talent markets of software engineers also changed in Taiwan after 2010. There were more and more open positions purely looked for software engineers. Most engineers could easily implement their idea and to test their idea toward real world in an amazingly short of time. This also drive eBiz startups. Since there are useful and dedicate tools which make internet technology not rocket science anymore. The only drawback here was that some talents engineers will look for “more interesting” job in commercial world for example machine learn or AI. However, only very few engineers will do the cutting edge task, most of them on those “more interesting” job are actually try to invent the wheel not the business focus.

Talent position in history


Nevertheless, engineers’ skill set and how to be handy with tools and not limited in tools are the major difference between talent and normal engineer. It is also critical to have a few engineers’ leader who had went through different stage of internet and also some young talents who can make things from existing tool soon. It seems a 3-4 engineers team size could fit our target. One is pretty senior and lead 2-3 young talent or even just graduated. Companies in Product-Listing

The 8 organization


The 8 companies we survey shows to build a fair product comparison website is not secret anymore. However, to build a good one still require patient and fine tune on every detail. Feebee has more engineer resources, however, the visits numbers is not a target which NO2 to NO3 can’t reach. After interviewed with ezprice engineers and also gather information from Linkedin. We could easily understood that current crawler (python), full-indexing (elasticsearch) and NLP (jieba or others) are pretty mature. A team with 2-3 mature engineers and has 2-3 months to leverage tools could build a decent product.


URL
Visits (4month)
Names
38M
firstweb 第一網站股份有限公司 ( http://sitetag.us)
20.8M
樂方股份有限公司
Funmula
17.2M
ShineWant Tech. Co., Ltd. 嚮網科技股份有限公司
11.2M
環通資訊股份有限公司
UCS Inc.
9.2M
億普媒體股份有限公司Eprice Media,Inc
2.4M
EZpriceCo.,Ltd. Taichung
2.38M
Personal website
0.5M
Reddoor Media Group Co. 紅門互動股份有限公司 (dotmore.com.tw)


Comments 


#1. 23 years is from 1995 to 2018. 1995 was the year which first “easy to get” consumer OS (Windows95) released.

#2. Email server hosting was never easy and it did make trouble for EC in early internet age. However, that also created opportunities for mail hosting service around the world. Gmail should be one of the best but mail.com and zoho.com were also good.

#3. https://www.programmableweb.com/api/google-shopping-search

#4. at 2005, Apache Lucene became a top-level apache project and latter on it almost become a core of all free full-index engine.