Re: [討論] 想請問當技術主管該做的事

恭喜你升任主管，也對於你願意認真帶領團隊，甚至不惜直接上來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

--

有空會再繼續寫下去，希望有更多人來一起分享

沒錯啊，因為原文看起來是比較貼近技術主管擔任scrum master的狀況，task managemen t 比較多與scrum master/coach相關，所以本文內容的確很像scrum master經驗。而技術 主管還有更多事情要做（尤其我們不知道原po是掛什麼title，上面是不是有CTO還是哪一 級主管）。 這也是為什麼我說該寫的其實很多。像規劃架構演化方向、建立技術門檻、向上/向下管 理、維運、危機處理&風險管控等等的，每一篇都可能是技術主管該參與或直接主導的。 每一個也都要不小篇幅寫。 另外，原po狀況應該也可以招聘一些這樣角色的人（像是Scrum master、架構師、DevOps 、Security)來專門負責執行上述的議題，但這背後的目標與過程技術主管應該也要知道 。