恭喜你升任主管，也對於你願意認真帶領團隊，甚至不惜直接上來Po文討論，感到尊敬。 畢竟在這位置要打混裝死，也是挺容易的。 因此也分享一些經驗； 首先這個位置主要是重建/維護/改善一套軟體生產系統，這系統關聯的當然有產品、人、 工具。所以所有你執行的內容，背後也是考慮這樣的大前提去運作。 換句話說一個好的主管，每一個導入的政策、計畫、管理工具等等時，應該都確立出這系 統局部目標，並且應該可以量化執行的結果方便分析跟稽核效果是否預期。 ※ 引述《imasaka1117 (Teddy)》之銘言： : 大家好@@ : 因為小弟去年被升為技術主管(小公司) : 一開始底下只有一個人 : 到現在已經有四個人了 : 因為剛升的時候 : 專案的量還很重 : 所以其實沒做什麼主管該做的事 : 頂多只有幫忙看其他人遇到奇怪的Bug或是技術上問題的討論而已 : 一直到最近老闆說要再招募一人減少我的loading : 讓我有時間去做主管該做的事 : 剛升主管的時候老闆有提點我一些主管該做的事 : 像是 : 1.task review : 我的想法是每週開例會來讓大家報告做的事項 : 但又覺得好像沒必要，因為PM都會知道RD們做的事情 雖然單純是執行task review，但根據背後確立的局部目標不同，會直接影響進行方法跟 思考方向。因為你預設了PM知道即可，那麼這好像沒必要。 事實上哪些人需要task review 以及頻率該多久一次的才是真正命題；從我過去經驗是PM 外，技術主管也該知道，每一個工程師也該知道。然後其他越多人知道越好。最後我建議 是每天進行，而且10分鐘內搞定。 PM的目的顯然是為了方便產品與市場或客戶銜接。 而技術主管的目的應該是「產品開發的順利運作，維持產值的穩定性」。所以review 必 須除了讓你知道生產中細節，進而快速排除開發障礙外，還必須量化產能。量化非常重要 ，因為他是發現異常的依據，更是你跟其它部門談判的工具。千萬記得，不是壓開發時程 的工具。壓開發時程這種事情應該是PM做。然後你來擋。 舉個例子來說，一個做完量化開發產值的team，應該可以知道該排入多少的工作量。而當 有突發狀況，像要hotfix時，外部串連服務掛掉、突然改版等等時 1. 由於每天都知道各自進程狀況，會更容易找到適合的人來負責突發狀況，也更容易預 估會減少的開發產值。 2. 由於工程師都知道各自每天的進程，所以也更容易提供你適時的建議。 3. 由於增減的產能都有紀錄及量化，也更好有依據去抵擋PM的不適合的壓時程問題。PM 一週一次檢視很容易忽略掉或錯估處理一些突發狀況的時程。 其他： 1. 透過每一天自我檢視，再加上PM不會無理壓時程，讓工程師可以專心每一天的工作內 容。因為你知道工程師都要熱機的麻。 以上目標都是「產品開發的順利運作，維持產值的穩定性」 另外有量化數據讓你爭取資源更容易，比如招聘、添購硬體設備、外部服務或開發套件。 只要有數據，談判就順利。實行後也可以有數據分析跟稽核，再來就可以邀功。記得一定 要邀功，你越紅才有機會把更多想做的導入。 還有一個重點是，每個開發團隊適合的作法不一樣，比如也有可能每天對你們沒什麼增益 ，但透過量化分析持續修正，適時回想目標，找到你們團隊的最佳解，這是技術主管必須 做的。 PS. 該寫內容的實在太多，但是真的要都寫完太長，最後會導致我直接不發。希望短短的 內容有幫到你。 : 2.公司未來技術方向 : 因為程式人生是需要不斷學習的 : 公司也是，不然也會被業界淘汰 : 我是希望可以帶著每個RD成長 : 這個倒是沒有什麼異議 : 但如果決定了某個方向也是會和RD們討論 : 看是不是有盲點 : 3.提升RD工作效率 : 這點應該就是會想破頭的XD : 因為公司的PM有些是非本科的 : 客戶如果發問，他們不懂的話就會pass給RD : 有時候就是一些基本問題，然後RD工作就會被打斷 : 所以我是想說給PM教學一些資訊業相關基本知識或術語 : 另外就是觀察RD們的IDE操作或是找解答的方式，並給予更好的建議 : 例如滑鼠點兩下可以直接反白該單詞，而不用滑鼠拖拉之類的 : 當然有時候反而是我看到他們更好的操作是我該學的，也要記下來給大家知道 : 4.統一coding style : 這點主要是防止人員臨時請假或是離職，交接時痛苦指數會比較低 : 當然還有如果多人合作時就較不會有違和感 : 以上是目前覺得該做的事@@ : 另外還想問各位是否還有哪些是我沒想到且建議的嗎? : 先謝謝大家QQ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.163.131.8 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1588430287.A.DFE.html 有空會再繼續寫下去，希望有更多人來一起分享 沒錯啊，因為原文看起來是比較貼近技術主管擔任scrum master的狀況，task managemen t 比較多與scrum master/coach相關，所以本文內容的確很像scrum master經驗。而技術 主管還有更多事情要做（尤其我們不知道原po是掛什麼title，上面是不是有CTO還是哪一 級主管）。 這也是為什麼我說該寫的其實很多。像規劃架構演化方向、建立技術門檻、向上/向下管 理、維運、危機處理&風險管控等等的，每一篇都可能是技術主管該參與或直接主導的。 每一個也都要不小篇幅寫。 另外，原po狀況應該也可以招聘一些這樣角色的人（像是Scrum master、架構師、DevOps 、Security)來專門負責執行上述的議題，但這背後的目標與過程技術主管應該也要知道 。 ※ 編輯: Masakiad (1.163.131.8 臺灣), 05/03/2020 13:00:19 ※ 編輯: Masakiad (101.12.51.98 臺灣), 05/03/2020 13:26:58