8/31/2019

如何處理抱怨 (成為主管的31堂課)


只要是人都會抱怨,然而只要是有經驗的主管,一定也都知道處理抱怨的重要性。過度並且持續擴張的抱怨不但會降低士氣,而且對團隊,對個人都沒有任何好處。

抱怨有分不同的層級,如果僅只是抒發心情,發發牢騷當然無妨。其界限在於,在平常閒聊,抱怨的只會佔不到1/3的時間,而在平常正式討論事情,正式的會議上,抱怨應該只是會佔不到1/20 (5% 或2分鐘)的時間。
主管在閒聊時後聽到的抱怨,大部分應該不用特別處理,畢竟是閒聊。 然而在正式會議上的抱怨則應該妥善紀錄並處理。因為抱怨的本身可能是和工作流程有關,更有可能的是潛在的問題,必須要試圖檢討解決。


案例一:工程師E技術能力向來不錯,然而跟他一起工作的同事,總是會反應他是個悲觀的人。追究原因發現,E無論如何都在抱怨,抱怨目前的現況和組織的做法,抱怨福利薪資等等。過了一段時間之後,團隊成員有些會受到影響,跟著開始抱怨,有些則會忽視他的抱怨。

案例二:在跨國團隊中,另一個國家的工程師會抱怨無法取得某些系統權限,而本國工程師常抱怨另外一個國家的工程師常想要干涉目前自己工作的範圍。



主管處理嚴重的抱怨有幾個方式:

(1) 了解抱怨的事實,根據事實決定行動


如果軟體主管覺得這個抱怨的人其實是為了組織好,而且,大部分的時候抱怨者其實不那麼常抱怨,也不是士氣低落的人,他除了反映工作困難之外,也許也揭露了應該改善的現況。應該進一步了解實情。並且在根據事實來決定行動。

以上面的案例二,雙方雖然都有道理,但主管進一步了解事實後,會發現其實某些系統的權限並沒有分group,這會讓該系統只要有權限的人統統都是最高的管理者權限,所以表面上是合作問題,其實是個技術問題,應該讓系統有不同層級的權限,另一個國家工程師也不是真的想管理這個系統,只是為了工作必須要直接使用,透過另一組人間接使用也很麻煩。而本國工程師也不是真的不想讓其他人使用,只是考慮安全性不應該給很多人管理者權限。


(2) 擁有改變的力量,而不是擁有「叫別人改變」的力量


許多抱怨的工程師常常會忽略「在公司裡面,我是來解決問題,而不是製造問題」

對於主管來說,如果抱怨者其實績效能力都很好,那麼應該化抱怨為力量。舉例來說,當團隊成員抱怨「現在的某系統在部署常出問題,害我需要做額外的工作」。那麼就可以先就事實詢問:「你覺得這對你很重要嗎?這是不是我們應該先解決的問題?」如果是的話,進一步應該跟抱怨者溝通:「既然這樣,你現在在做的是XXX和XXX,這兩件事就先不做,先來把某系統的部署改善,這樣以後你就不用做額外的工作」

讓抱怨者擁有改變的力量 - 就是要調整工作內容和時間。這樣久了,也可以清楚地塑造團隊會往解決問題方向前進,而不會只抱怨問題。

(3) 概念性問題:先記錄並且追蹤


概念性的抱怨是指對公司政策概念的抱怨,例如:為什麼我們公司沒有work-from-home(在家工作)的政策,為什麼上下班要打卡。這類型的抱怨很多時候和「實質工作」沒有很大關係,然而,不處理或者直接用「這個是公司HR政策 我也沒辦法」這種說詞也對大家沒好處。

對於概念性抱怨,應該先行記錄,並且追蹤對團隊成員的影響。舉例來說,對於work-from-home的要求可以先了解團隊成員需要work-from-home的原因:例如需要專心工作,還是需要兼顧家人。如果是需要專心工作,可以提出會在他需要專注的時候。幫忙直接訂一個會議室,或者讓他在距離公司很近的咖啡廳工作,並且記錄一整個月,看看有沒有實質影響。也許,他以後就不想真的work-from-home,也許他會覺得在咖啡廳工作也很好。

重點在於,概念性抱怨其實應該轉為實際可追蹤執行的內容。



主管對於團隊成員的抱怨絕對不能做以下的事情:


(1) 隨意附和,隨意認同抱怨: 表面上這似乎可以拉近團隊與主管的感情,事實上,一起抱怨對大家都沒有任何實質好處。

(2) 忽略重大抱怨:如果這個抱怨是很嚴重的,忽略拖延也沒有好處

(3) 不查證事實根本原因就行動:雖然所有人都知道要查證事實,然而許多事實的根本原因其實不那麼簡單。



8/29/2019

節省招募時間 - 電話面試的技巧 (成為主管的31堂課)


在軟體「人才」的招募上,通常會花上比預期還要多時間,人才難尋是軟體產業其中最困難的問題。自招募流程上,各種審慎的過程當然不能省略,例如技術評估,面談等等。然而,整個過程可以透過各種方式,提前篩選適任或者不適任的人。其中,電話面試在台灣是最被忽視的一項。大概也是因為台灣交通十分方便,特別是大台北地區,面試者一般都不會因為「太遠」而放棄,但交通因素並不是電話面試最大的好處,電話面試最大的好處是可以低成本有效地去除偏誤,有效增加後續篩檢的正確率,並節省時間。


案例:在某次研討會中,軟體研發團隊主管K說,我從來不做電話面試,因為我想要看到應徵者的臉孔跟肢體反應,這樣我比較容易判斷個性。


電話面試有幾個好處:
(1) 去除偏誤:尤其是對外表的偏誤。已經有太多研究證實,沒有人能夠避免對外表的偏見,只是多或者少而已。也因此許多研究指出,履歷表不放照片才是最好的方法。當然也有人持反對意見,不過整體來說,雖然遲早會見到本人,但電話面試的確可以去除主管對外表的偏誤。案例中的主管K試圖去判斷個性,但容易流於自我偏誤。

(2) 節省彼此時間:一般面談起碼也要花2個小時,而電話面試至少可以先過濾掉10~15%的明顯不適合的應徵者。許多資深的軟體職位起碼要收20個履歷表才能找到1個人。換言之,電話面試,在表面上起碼可以少讓2個人來辦公室,但其實背後意義不僅於此,操作得當可以讓另外18個人對你的組織更有興趣更能在面試中努力表現,而非因為獵人頭介紹隨便來試看看。

(3) 其他:其實還有很多好處,例如再度驗證履歷表的真實性等等。

電話面試的技巧:

一:結構性問答而非開放性討論


電話面試必須要「固定詢問有意義的結構性問題」,而不是開放性討論。透過結構性問題收集了解事實。

結構性問題例如:
* 你為何想要離開現在的公司
* 是從什麼管道知道我們有在找軟體開發人才
* 你最近一次跟主管起衝突的時候,當時你做了什麼
* 最近三個月,你學了什麼新的資訊技術是跟工作無關的
* 你最近一次code review是什麼時候

這些問題回答不要評論好壞,只是記錄最為後續判斷。

不要問開放性的問題,除非你要找的是很會唬爛的人,開放性的問題通常都是假設性的問題,例如:

* 如果你跟老闆吵架了你會怎麼做
* 要是你加入一個有大流量的公司,你要怎麼做分散式系統設計

二:基本的事實查核


事實查核比想像中重要,倒不是因為履歷表造假的問題,而是在看履歷表的時候可能會有自已的假設,這些假設可能會有認知偏誤。

簡單的事實查核問題
* 請問你想要離開現在公司的原因
* 請問你當初加入這個公司的原因
* 在2013/3~2014/10年這段期間,你履歷表中似乎沒有在任何地方就業,請問是什麼原因呢
* 您在2012年某公司A的離職原因是什麼

進階的事實查核
* 在履歷表中,您有描述溝通是你的強項,請舉一個最近一次你解決非常困難溝通狀況的例子好嗎?
* 您剛才說在某公司A的離職原因是公司內部高層政治鬥爭很嚴重,可以舉一個政治鬥爭的然後影響到你的工作的實例嗎?

三:回答面試者對公司以及團隊所有問題


優秀的人才鐵定會想要再加入一個團隊時,了解一些事情。讓面試者詢問問題,不對問題做衍生性的回答,也不做假設,只是誠懇地回答問題。並且在最後再詢問「請問你還有任何想要了解的問題嗎?任何問題都可以現在詢問」

當面試者問了廣泛性的問題,請必定要他縮小範圍。否則,廣泛地回答對他也沒有好處。舉例來說:常遇到面試者問「呃 ...我很重視軟體工程文化,請問一下貴公司的文化是怎樣」這種問題太過空洞,可以直接告訴面試者「我們也很重視工程文化,但你的問題太過籠統廣泛,這樣我也會回答的籠統廣泛對你也不好,可否你縮小問題範圍,或者問實際的某件事情,透過實際上事情你就可以判對我們的文化對你來說好還是不好」。如果是容易溝通優秀的人才,很快能了解,因而他們就會問類似這樣的問題:「喔 我了解,那我想問,請問你會進行code review嗎」這樣彼此就可以針對事實討論。

更重要是這樣的事實討論,可以讓他了解優秀主管通常是實事求是,而主管也可以了解他能不能馬上抓到重點。



藉由這三個項目,一個好的主管可以初步篩檢適合或者不適合的人。另外一個值得一提的是:電話面試中間盡可能不要提早判斷面試者適不適合,盡可能是電話之後才根據筆記來判斷是否要邀請來面試。

8/28/2019

人手不足?資源永遠都是不夠的 (成為主管的31堂課)



大部分的情況下,所有研發與軟體主管都會面臨到人手不足的情況,特別是新創企業和快速發展的公司。資源有限,人手不足是必然的「現實」,能夠有效解決此問題也是普通主管和好主管最大的差異之一。解決的方向有三個:(一) 事實是事太多而非人太少。(二) 突破性思考,至少想出解決方案。(三) 必要的犧牲 


案例:主管V負責一個長期專案,已經有接近30個工程師是直接由V管理。然而,最近一段期間由於主要客戶的變更,加上CEO的臨時任務,讓這部門的員工疲於奔命。主管V也沒有什麼對策,只好和業務盡量模糊客戶需求以及驗收方式,看能不能減少工程師的工作量。


一:真正的事實是:事太多而非人太少


人手不足的真正意涵是「事情太多」。在以人才導向為主的組織裡,人力不足採取的短期策略如果是「增加人力」通常也不會真正解決問題。但如果短期採取「調配人力」也就是說某些事情先不做,有些事情先做,的確是可行的做法。

作為主管的你可能會說:我這些事情都很重要,每一件事情都要做。在營利組織裡,所有事情都很重要根本不可能發生。絕大部分的情況是:主管無法針對事情的優先順序做必要的排序。除非你管理的組織是急診室或者核電廠,不然不可能什麼事都很重要。要做必要的排序表面上很簡單,將事情列一個「優先順序的清單」,從1排到N,數字都不能重複,1就是最重要的事情。實務上,需要主管本身的本職學能判斷以及個人意志力。

二:突破性思考,至少想出幾個不同的解決方案


關於思考問題的框架,請參考這裡和這裡。在此就不重複。

但要提醒的事,在盈利企業裡面,不可能有什麼事情是「只能」這麼做的,一定會有不同的解決方式。問題只在於有沒有想到,還有這樣做效果好不好而已。

三:必要的犧牲 

必要的犧牲並不是指長期加班。長期加班最後通常也是三輸。必要的犧牲指的是幾種可能:
(1) 犧牲不必要的事情,請參見第一段
(2) 極短暫的加班,和長期加班不同,短暫加班是為了解決特定問題,並且要確定能盡快補假,讓團隊成員合理的休息
(3) 縮小範圍,犧牲部分功能
(4) 延長時程,犧牲時間 

然而請謹記,不能犧牲組織重要的長期目標的前進,以及不能犧牲組織文化價值。主管一旦犧牲不該犧牲的事務 (即便是無意間),就表示其領導方式有極大的問題。


陷阱


案例中的主管採取的作法非常糟。會直接踩到許多陷阱。要注意的陷阱是:
(1) 任何情況下降低品質都是飲鴆止渴,很少看到好下場。然而縮小功能範圍(例如MVP的概念)卻常常能夠成功
(2) 滿足政治因素(要和CEO打好關係)而非滿足實際困難,短期雖然可能有效果,但長期通常也不會有好下場
(3) 任何變化仍然要滿足組織整體方向,以此案例來說,必須要了解CEO這些臨時任務和目前專案比較起來何者重要

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/26/2019

系統化思考的秘訣 (成為主管的31堂課)


系統化思考 Systems Thinking 是解決複雜困難問題的科學方式。而作為主管的工作,時常遇到困難的狀況,如果身為主管的你沒有一個科學性的方式來分析與處理困難狀況,自認可以依賴直覺和經驗,那麼很有可能你依賴的是運氣而已。


案例一:有位資深的HR M,憂心忡忡的問說,過去三個月我們的資深工程師招募好像不順利,快要一百人無法通過我們的評估,Hunter看到我們這樣都不太願意再送履歷表來了。我們是不是標準太高?要不要降低標準。

案例二:某主管A被要求和直屬於CEO辦公室的專案經理D合作進行系統整合,然而專案經理D常常會有不合理的要求 ,並常在會議中酸言酸語,讓A在系統整合上花了很多人力時間,但又打不到D的要求,而D又有CEO作為後盾。


上述案例都很複雜,牽涉的範圍廣泛。為了解決複雜問題,系統化思考會牽涉到各式各樣圖形工具,例如這個,或者這個。這些圖形工具其實都是為了簡化問題。系統化思考的理論與應用廣泛,但是針對軟體主管的工作特性,有幾個祕訣(捷徑)可以先試看看

(1) 無論如何,先畫張心智圖或者魚骨圖


心智圖可以拓展思考,魚骨圖可以先探索遺漏因素。更重要的是,圖形可以將你的思考模式放在紙面上,讓你用鳥勘的方向,有機會重新思考問題。並且,這圖型還可以留供未來檢討使用。

(2) 無論如何,先透過5Why找到真正的目的或原因。


以上述案例一,當我們先從一個方向使用5why探究原因,可能如下:

為什麼HR會覺得不順利?是因為招募人數不足。為什麼招募人數不足?是因為hunter不願意積極尋訪多送履歷表。為什麼hunter不積極?是因為我們篩選比較嚴格。為什麼篩選比較嚴格?是因為....

但是,從另一個方向使用5why可能如下:

為什麼HR會覺得不順利?是因為面試的多但都沒錄取。為什麼面試多但都沒錄取?是因為hunter送來的履歷不符合我們徵才的要件。為什麼不符合?是因為hunter不了解我們要什麼樣的人才。為什麼不了解?是因為....

找到事情的真正源頭,或者自己想達成的真正目的會是系統化思考要達成的第一個目標。

(3) 實驗性質的行動!兵聞拙速 未睹巧之久也


任何形式的研究調查,都可以無限期地進行下去,可能永遠都不會有結果。然而作為主管,透過行為有效的將事情推進下去才是重點。

案例二:當展開5why與心智圖,了解CEO的辦公室經理D其壓力來自CEO對他有時間限制時,而D由於無真正的技術能力,導致會將各種事情盡量轉交給主管A,探究其目的在於,萬一整合失敗,不會被歸咎責任。而A的做法就是互相對抗,兵來將擋。這樣的情況,可以持續下去永遠沒有結果。而後改變的做法是,先實驗性透過提供各式各樣教育課程給D的部屬,讓其部屬更了解系統如何運作,並且在各種會議中提及教育訓練一事,讓CEO理解其直屬的團隊的能力不足,因而會讓系統整合的設計本身交由A來進行,自然系統整合的最後結果就會順利達到CEO要求,也讓A與D之間的關係不會永遠惡化。

案例二看似政治問題,但其實透過實驗性質的活動(提供教育訓練)可以讓A快速證實D的團隊能力不足,即便教育順練活動辦得很粗糙簡陋也可以。


提醒一下,無法進行系統化思考的主管,最後更容易透過「恐懼」「運氣」「政治手段」等方式來管理團隊,至於能否達到目的就很難說。








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