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

看板Soft_Job作者kenshin528 (幾分之幾)時間4年前 (2020/05/04 00:14)推噓12(12推 0噓 1→)

留言13則, 12人參與討論串4/4 (看更多)

恭喜升職，也恭喜你遇到一個好老闆，願意多找人來分擔你的工作讓你可以專心管理。最近剛好從 github 看到一篇分享管理原則的文章（https://github.com/ksindi/managers-playbook/），以下的文章是從上面這篇的原則再加上一些個人的經驗心得分享，希望有參考價值。網誌好讀版(抱歉 medium 網址太長只能用縮網址，https://tinyurl.com/yc73rc6t) 1. Always be aware of what’s going on in your team and product. 比起動手實作，主管一定要搞清楚目前團隊的狀況和所有任務。特別是當團隊越來越大，任務越來越複雜時，不同專案之間的重要性和依賴程度不同，而主管需要分配資源到那些該做的事情上。 2. Know the architecture just as well as anyone else — and stay current with the tech stack. 我覺得這點不容易做到，特別是當分工很細的時候。但是技術主管一定要能問出一些基本的好問題。像是在設計上有哪些該注意的原則、技術到底要摸深到什麼程度才夠用、或是配合不同情境決定不同的設計重點等等。技術一直在改進，但很多基本面對的問題不會差太多（像是 security, throughput, latency, cost 這些） 3. Schedule 1–1s with your direct reports on a weekly basis. Schedule skip-levels on a monthly basis. 溝通可以說是管理者的基本任務了。每週的 one-on-one 重點不是確認工作進度，而是更關注成員/或主管在目標理解上的一致以及工作中遇到的困難。如果團隊有好好執行 Scrum 的 retrospective meeting 話， One-on-one 可以更關注成員本身的狀況。如果覺得 ono-on-one 會議太制式的話，午餐或下午茶的閒聊也是不錯的方法。 4. Be customer-focused. Understand how your products are used in the wild. 在分工分明的大公司這點可能比較不適用。但是在小公司中，客戶就是公司的一切，了解客戶需求和狀況有助於設計更好的軟體架構或架構選型，讓當前的設計可以滿足短期甚至中期需求我覺得是很有幫助的。（這些需求可能不是 PM 一開始想到或提出的） 5. Set aggressive but achievable goals. Work backward by focusing on the outcomes you want to achieve. 不管是對上還是對下，設立目標都很重要。立下明顯達不到的目標會讓執行者無所適從壓力山大，也會讓上層對於公司未來建立錯誤的認知。並要將焦點放在 outcome (成果)上，而不是單純的 output（產出）。 https://www.thebalancesmb.com/inputs-outputs-outcomes-impact-what-s-the-difference-2502227 這邊有提到 output、outcome、和 impact 的差異。例如 tune 好的 model 是 outpout，但實際上我們關注的是模型上線之後帶來的轉換（outcome），以及長期來說，客戶是否能在我們平台上停留得更久（impact）。 6. When giving advice or feedback, encourage ownership by asking open questions. 我不太確定要如何利用開放問題給予鼓勵，但是給予建議以及回饋是非常重要的。建議和回饋是讓別人瞭解自己/團隊價值觀的最好方式。每一次 code review、或是成果的檢視，都是讓團隊成員與團隊目標校準最好的方式。我反倒是覺得當成員產出與目標偏離的時候，可以多利用開放式問題讓成員思考其中差異。 7. Be the team coach and cheerleader. Celebrate success often and reinforce positive behavior. Coach 和 cheerleader 的角色同等重要。大家來工作除了領薪水之外，也是希望有成就感和自我成長的。如果你不太確定 coach 要幹什麼，可以參考 NBA 或棒球場上的教練都在做什麼就會有比較明確的概念。 8. Know how to differentiate between reversible and irreversible decisions. 管理者第二個任務就是做決策。小至 coding style 、要不要寫註解、座位怎麼分配，到技術選型、架構設計、產品方向等等。別用戰術上的勤奮，掩蓋戰略上的懶惰。縱然好的戰略也需要好得執行者，但是失敗的戰略，再努力可能都是徒勞。 9. Ensure every report is aware of the top priorities of the team, organization, and company. 呈上，做決策中很重要的一件事就是決定優先順序。確保大家不是瞎忙或內耗。 10. Be the example. Only preach what you practice. 縱使管理者可能不會做每一個技術細節，但是價值觀唯有靠自己實踐才能傳遞。如果不是一個正直的管理者，團隊也不會是一個正直的團隊。堅守原則最簡單的方法就是一次都不要違反。如果你違反了一次，那就會多出一條原則的額外規則，以及更多違反原則的機會。 11. Get your hands dirty even if it’s not coding. 就算沒有寫扣，還是有很多方式可以幫助團隊，像是寫文件、未來規劃、新知識的分享、找問題、提升成員技能等管理上能討論的細節和狀況真的太多，而且也需要反覆嘗試和練習才能找到適合自己和團隊的方法，希望你一切順利。 ※ 引述《Masakiad (Masaki)》之銘言： : 恭喜你升任主管，也對於你願意認真帶領團隊，甚至不惜直接上來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), 來自: 122.116.21.29 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1588522460.A.C2B.html

推

fantasycloud

05/04 00:22, 4年前 , 1^F

05/04 00:22, 1^F

推

w4a2y4

05/04 01:54, 4年前 , 2^F

05/04 01:54, 2^F

推

Masakiad

05/04 01:54, 4年前 , 3^F

05/04 01:54, 3^F