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