顯示具有 第一次當主管 標籤的文章。 顯示所有文章
顯示具有 第一次當主管 標籤的文章。 顯示所有文章

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)。