謝邀。
管得不多，寫得不少。。。
總體來說，從管理的scope來看，從小到大，對人的管理始終是最重要的環節。但隨著規模變大，對人的管理，越來越多要用目標牽引，而非具體指示。因為宏觀戰略才是最重要的，微操作只是戰術，管理的帶寬是不夠對全局進行微操作的。
後面有些散亂的觀點，基本都摘自過往寫過的文章。大致按管理規模來排序。
先看看主 程式的自我修養：
他應該是團隊最後的保險，承擔救火隊員的職責，出現在每一個最需要他的技術領域，前期新產品孵化，哪裡缺人去哪裡，後期debug，什麼bug難調就由他去搞定；
他應該是團隊的先知，了解技術趨勢，關注兄弟項目或是業界發展，能隨時找到適合自己的方案或者找來能幫助自己的外援；
他應該承擔起溝通職責，是團隊和外界的一個技術介面，既能在外部把整個引擎和邏輯底層變成一個其他人能輕易了解的黑盒，又能在內部理解白盒的每一個技術細節，和開發組員溝通具體實現；
他應該在衝刺milestone的時候戰鬥在一線，和兄弟們一起熬夜，提供最堅實的技術支持；
他應該在衝刺完milestone后，思考後續節點技術方向如何改進，是不是要重構，有什麼重點技術方向需要突破，還有哪些明顯的技術短板需要彌補；
他需要有common sense，了解一個技術的生命周期和開發難度，不會盲目樂觀也不消極悲觀；
他要為組員發展盡心儘力，讓大家有一個好的個人發展，儘力做到項目好、大家好。
顧煜：What makes a good lead programmer345 讚同 · 30 評論文章
再看看初管團隊的困惑和關注點
對於一個新的團隊，往往會面臨有很多新人，不了解能力。
可以小步疊代，逐步了解團隊成員的能力。對不熟悉的同事，分配一點簡單的工作，了解能力的同事，可以領一點更困難的工作。然後定期跟進後續的，過一段時間差別就很明顯了。如果把開發者能力作為Y軸，把積極性作為X軸的話，我們就可以建構四個象限，把開發者們一一對號入座：
積極且能力強的，明顯學有餘力，保質保量完成工作，而且非常積極，主動來要新的任務
積極但能力弱的，做得很努力，不是很能跟得上節奏，但也是非常投入
不積極但能力強的，能比較快做完安排的任務，然後也不幫別人，也不來彙報，自己在角落happy
有不積極且能力弱的，組裡倒是沒發現，也是萬幸
了解了幾類人，就可以分別用不同的形式管理。
積極且能力強的，可以給更難的任務，讓他放手去做，然後主動彙報進展即可，平時也不用太多催他，能搞定的自然能搞定，不能搞定的他也會提前彙報
積極但能力弱的，給一些稍簡單的任務，同時加強輔導，幫助他在技術上能提高，多回答他的問題，給他更好的個人發展方向。
不積極但能力強的，是比較難處理的。任務可安排稍難的，但要特別注意迴避那些需要多方溝通、模糊地帶的任務，這類同學往往比較懶，不善於或者不願意推動事情，經常會卡住。然後要多跟進，除了正常的daily/weekly的彙報，還要常常關心一下他的進展，讓他了解到，Big brother is watching you
不積極且能力弱的，試試能不能挽救，不行也只能放棄了
那怎麼能準確的判斷員工是哪種屬性呢？新團隊的磨合，其實就是一個彼此試探的過程。你做得好，就領更多的任務，我對你信任+1；你做砸了，我就給你更簡單的任務，信任-1。主動積極彙報和領任務有印象分+1，看見你偷懶進度慢就印象分-1。細心觀察一陣子，就很快有準確結論了。而且猜錯也沒有關係，這是一個持續調整和逼近的過程，這次錯了，下次改回來就好了。
大局觀也是一個很重要的因素：
第一個和大局觀有關的是跨團隊協作。項目中不只有你一個團隊，AI邏輯團隊作為一個中央樞紐，要把關卡策劃服務好，對接UI美術，把引擎功能包裝整合，配合online組開發Matchmaking，和每個組都有或多或少的聯繫。很多時候，本團隊工作安排最優不代表全項目工作安排最優，跨團隊的合作，該強硬的時候要強硬，該讓步的時候要讓步，一切以項目利益最大化為目的。由於Leader們私交都不錯，合作多年，相對來說跨團隊合作都還好，沒有太大的問題。
第二個和大局觀有關的問題是對自己團隊工作的把握。什麼時候該鼓勵團隊探索一些先進技術，並且在研究不順利的時候決定繼續還是喊停，什麼時候應該保守一點，收斂需求，確保能完成相關特性，這就是一個典型的例子。這方面要做好，需要有廣泛的領域知識，也需要一些跨界知識，更需要多個項目的經驗。因為做決定的時候，也是在資訊不完備的情況下，一個好的決定也需要一點點運氣。
第三個和大局觀有關的問題是控制團隊工作節奏。要試圖理解整個項目階段，我們團隊的工作對項目交付有什麼影響，什麼時候我們是瓶頸，要加速做，什麼時候我們有閑暇，可以放鬆一下，做點長遠技術投資或是清償一下技術債。當然，AI和邏輯團隊永遠都是瓶頸，所以也不用想太多，努力工作就是了。
第四個和大局觀有關的問題是組內的工作交付問題。有些同事雖然很努力，但總不能交付理想的成果，是換人來做，還是只好選擇原諒他？換人來做意味著新同事要重新熟悉這一塊的工作，老同事會覺得很沮喪，不被組織信任。換了新人如果搞不定怎麼辦？有幾種可能，要麼這件事就是不容易搞定，要麼第二個同事還是不給力。所以換人做的話，一定要確保新接手的同事是信得過的，避免再次出現換人。只要新接手同事沒做成，就告訴自己此路不通，我們想辦法繞路。
第五個和大局觀有關的問題是李要控計李計幾。Leader相對來說總是一個團隊技術最好的，看見大家搞不定事情總想著要衝上去幫忙，找一下智商優越感。也很正常，人總是希望做自己擅長的事情。一起幹活本沒有錯，也能很好提高團隊士氣，但是時機和工作內容要選好。千萬不要選擇在關鍵路徑上的任務，如果搞不定會影響整個項目進展。因為leader在中前期總有各種重要的技術選型和決策要做，在中後期總是陪加班和調配資源，應付突發事件，哪件事都比上去搞定幾個任務重要。如果手頭有關鍵路徑任務，往往都是最難的，工作中又無法抽出整段時間專心做，很可能會拖累整個項目。找點可以獨立的事情，可以是比較難的長線任務，也可以是沒有太多依賴的疑難問題debug，或者是做做優化，這些事情既能找到滿足感，沒時間搞定，也不會對項目有太大衝擊。
顧煜：遊戲 程式員成長編年史(5)143 讚同 · 18 評論文章
但管理不意味著放棄專業，專業能力還是立身的根本，特別是小團隊，很難接受*純*管理工作。
如何在在管理同時提升專業能力呢？
在這麼多年的個人發展中，總在那些關鍵時刻，有一些不能勝任感，然後奮起直追，讓自己慢慢勝任。直到前些年在騰訊的經歷，才讓我意識到這適度的焦慮給我帶來的幫助，我也開始更刻意的讓自己常常有一些不能勝任感，以便避免自己過於安逸。這個不能勝任感，換另一個說法可能更能被人接受，叫做走出自己的舒適區。
為了緩解焦慮，開始了瘋狂的學習。那兩、三年的閱讀量非常大，每天都有3-4小時在看技術資料，做筆記，分析和思考。先要補上自己的短板，把自己不熟悉的領域熟悉起來。好在孩子還沒有讀書，也有足夠精力，我每天早上提前一個多小時就到單位晨讀，晚上回家還會抽出很多時間閱讀。出差時，晚上或者周末也在酒店閱讀。
幾年的高強度學習，逐漸緩解了我的焦慮，系統的閱讀了大量主題書籍、Gems類型書籍和會議ppt等，大致找到了感覺。可以和別人侃侃而談，不再會在拿出名片的時候臉紅于架構師的Title了。
從一個技術指導（Tech director）的角度上，我不需要事事都會做，自有優秀的同事來搞定，我只是偶爾需要在必要時刻，保持一定的突擊能力，可以沖在一線解決困難的問題。但我必須事事了解，知道技術大致的Trade off，知道複雜度，知道和其他系統的關係。換句話說，這個時刻，技術廣度對我來說，比深度更重要。
技術深度的方法可以通過突擊學習，廣度積累當然也可以，但還有其他方法可以做到。畢竟這時候我也工作了十幾年了，不如剛畢業的時候精力旺盛，孩子也是一個精力黑洞，如何多快好省的培養自己能力，提高效率，變得更重要了。
介紹一些有趣的實踐方法，可以幫助積累技術廣度：
面試學習法：我常年負責遊戲客戶端領域的技術通道面試，技術通道面試可以簡單理解成對面試者定級別的複試。同時我自己的團隊也招了很多人，面試非常多。從HR的回饋來看，被面試的人，表示我面試時候領域知識問得深入，且範圍很廣。其實在面試時，面試官有巨大的優勢，面試者的經歷簡單掃一遍后，就可以隨意發問。我有主動權，可以聲東擊西，選擅長的深入問，不懂的可以簡單帶過，保證不露怯。也可以長驅直入，對自己感興趣的領域，讓面試者深入講講，聽個大概，成為自己事後了解這個領域的入門材料。可以左右互搏，對於一些面試者的有趣觀點，隨手記下，下次可以問另一個面試者怎麼看這個問題，讓他們的觀點彼此PK。可以溫故知新，順便和面試者討論討論一些主題問題，把平時學習的新技術用上，如果他回答不出來，正好複述一遍，既幫他開拓眼界，也可以加深自己對這個技術的印象。面試時學習法很適合快速拓展知識面，每次面試都是一次技術切磋，如果有機會面試級別高的開發者，更是一個很好的成長經歷。
項目評審學習法：公司內部的項目評審技術評審，也是一個不錯的學習途徑。騰訊的內部遊戲開發，有較完善的流程，除了產品評審環節，也有技術評審環節。我做了幾年技術評委，通過參加評審，我有機會了解每個項目大致面臨的技術難題，也經常能看見一些閃光點。比起面試學習法，技術評審接觸的都是公司內部同事，即使有什麼東西當時沒有理解正確，或是過了很久想到這個技術，細節都忘了，也可以找到當時的同事請教。
職級晉陞學習法：公司內部對 程式員的技術能力升級，有一整套考核，到了一定的職級，就需要有正式的答辯環節。我常年負責技術評審，申請晉級的同事們會準備自己的工作成果展示，我能看見大量技術問題的分析和解決方案。和項目評審中的學習有所不同，項目評審時角度更宏觀，具體技術細節不會涉及太多，而自己職級評審中，每個同學都是竭盡所能，從各個角度介紹自己的技術，有問必答，還有事後給面試官送補充說明材料的。剛參與技術評審的時候，兩天評審中，往往能有2-3個技術點讓我眼前一亮。當然這個學習的衰減速度非常快，前幾年的評審，往往兩天聽完，也沒有什麼有趣的技術點了。
業界會議學習：遊戲圈子比較開放，每年的GDC或者其他開發大會，都會有開發者無償公布很多新的技術，或者總結自己項目的得失，介紹好的實踐。參與這些會議，是最好的手段，可以快速和國際頂尖水平開發者對齊。你需要的只是一張來回機票，幾天住宿，一張門票，和英語聽力。每次參加完會議，總是特別興奮，有很多好想法想和團隊分享，有很多改進可以做進我們自己的引擎。如果沒有那麼好的條件可以去現場參加會議，也可以關注會後放出來的免費材料，或是購買付費會員賬號。
上述的學習實踐，本質上就是多聽多看多聊，和其他項目多社交，多聊聊技術，出去多看看其他公司怎麼做項目，堅持做一陣子，自然就有了技術廣度理解。
顧煜：遊戲 程式員成長編年史(6)208 讚同 · 23 評論文章
團隊學習，也可以幫助提升能力
我們的學習方法，還差一個環節。進一步可以做的，是群體學習。發動團隊的力量，大家一起來學習，補足自己精力的缺失，也幫助團隊提高能力。
以前在項目組，會做一個每周分享的活動。不管senior還是junior，按照姓名排序，輪流來做一個30分鐘的分享，涉及主題可以是新技術，可以是工作中解決的重要問題，可以是外部的有趣技術分享，可以是展會、讀書心得，找自己擅長的就可以。每周兩個同事分享，佔用整個團隊1小時左右，因為團隊人比較多，輪一遍要好幾個月，所以這個活動對聽眾是一個很好的放鬆，也不會對分享人造成非常大的壓力。
做這件事，無論是對個人，還是對團隊，都有很大的意義：
擴展廣度：可以充分發揮團隊力量，開拓視野，經常能看見一些讓人眼前一亮，但自己掃描的時候被疏漏的技術點。
提高學習質量：逼著大家在閱讀之餘做總結歸納。一個知識如果看完了只是模模糊糊有所了解，那麼說明你對它的了解還不夠深刻。如果能總結出來，分享給別人，那你肯定就能深入了解它了。最好的學習，就是把這個知識教給別人。
鍛煉表達能力： 程式員往往內向不善表達，促進大家分享，也是一個好機會可以教大家怎麼和人溝通，怎麼把知識點更好的表達出來。軟性技能在個人發展的中後期非常重要，但卻往往被人疏忽。
促進團隊交流：促進團隊間互相了解，比起吃喝類型的團建，這類活動更能讓大家在工作上達成默契。有時候工作中碰到某個技術，想起前段時間有別的同事分享過，就可以翻出ppt再看看，看不懂也可以直接和這位同事溝通，得到進一步的幫助。
減少團隊流失：促進學習氛圍建設，也能穩定團隊。遊戲開發總是很忙，如果沒有機會讓大家有所提升，做幾年技術人員很容易荒廢。
看上去很美的團隊學習，實行一段時間以後，也發現了不少問題：
能力不匹配：團隊能力和精通領域參差不齊，導致很多話題，一些人聊得津津有味，另一些人完全聽不懂；或是senior對很多初階主題明顯不感興趣，給junior 程式員很大的心理壓力。
有些員工分享能力實在不行，很好的選題，但講的時候就是平鋪直敘，不考慮目標聽眾的理解。
工作進度有壓力，不能一直堅持。輪到某個裡程碑版本要衝刺，就很難保證分享活動持續進行了。
大家隨意分享，廣度有了，系統性不足。
針對這些問題也可以做一些改進，能力不匹配，則可以想辦法通過提前審核選題，來確保題目是多數人感興趣的，也可以通過小範圍組織分享，找更合適的小團隊來群體學習。分享能力不夠，可以通過更多的輔導，幫助串起技術、提煉分享線索、考慮受眾接受度、提前準備逐字稿等方法提高質量。工作進度壓力客觀存在，真堅持不了分享，就暫停一陣子，等忙完再恢復好了，對學習來說，來日方長，不爭朝夕。系統性不足，可以通過組織主題學習的方法，或者有專人掃描某一次會議所有議題，或者一起深入讀一本好書，輪流分享其中章節，或者針對某一技術領域，遍讀相關文章，做全面介紹。
堅持團隊學習大原則的前提下，細節上可以靈活把握，變著花樣，讓大家有新鮮感，養成良好的學習習慣，也能從隊友的進步上有所收穫。另一個容易被忽視的地方，是整個流程一定要足夠的輕，越輕，越容易推動，太重的流程，容易胎死腹中。
工作時間不可避免會被碎片化，怎麼辦？
碎片化是首當其衝的問題。在新的崗位上，業務複雜性大大增加，精力會被極大地碎片化。大公司的流程本來就複雜，除了項目，還會有各種其他部門和外部公司，為了滿足他們的KPI，來佔用你」一點點」的時間。每個團隊真的只會佔用你一點點的時間，但架不住團隊多。這是外部複雜性，如果咬咬牙還能避免困擾，大不了在最忙的時候，就拉下面子全推掉所有的邀約，也能有個清靜。
外部複雜性可以翻臉，但是內部複雜性是無可避免的。做組員的時候，會覺得項目開發是有周期的，有忙有閑，除了最終版本是持續衝刺，其他時候很明顯會有段落節奏感。但在新的崗位上，再也沒找到過節奏感。我當時主崗不在項目，天涯明月刀項目是兼崗。往往是項目衝刺的時候一起熬夜，搞完一陣子大家放鬆了，我開始處理主崗的積壓工作，差旅奔波。組員回血的時候，我在回顧上一階段得失，在制定一下階段規劃，接下來該做什麼，該怎麼做，如何動員內部資源，是不是要引入外部資源協助。組員加班衝刺的時候，也要跟著一起往前跑。而且大項目，總有這樣那樣的問題，天天忙著救火，這裡消停了，那裡又出問題了，要輪流去關注，經常去支持。更多細節可以參看What makes a good lead programmer。
工作中對碎片化問題需要特別警惕。技術學習需要不被打擾的unbroken time，技術管理和決策更需要unbroken time。但在工作中，技術管理者是很難享受到不被打擾的時間。在開放的辦公環境，人來人往，大家向著你的工位，帶著他的疑問和訴求，希望能分享你的一點點時間，來讓整個項目變得更美好。你又怎麼忍心拒絕他們，關閉心門？最常見的做法，當然就是割下你的一小片時間，分給你的隊友，換取和諧和共同進步。
> 悄悄的他走了，正如他悄悄的來
> 他揮一揮衣袖，留下了一隻猴子（注1）
但當你的時間支離破碎，你就沒有辦法去做高質量的技術決策，沒時間思考項目方向，沒精力考慮團隊管理。那些才是你更重要的職責，對團隊會產生更長遠的影響。
> 工作中的幸福程度，和你同時需要關注的事情成反比，
> by 某總監
讓我們一起來做些什麼，打響反碎片化的第一槍：
帶上筆記本電腦，從工位上消失。寫報告、做ppt、做規劃的時候，這一招最有效。相當於你有一個虛擬的會議，這個會議就是你和自己的約定，說好了這次一定要搞定的呢，別給別人打斷你的機會。
和大家溝通，說明自己的情況，然後約定溝通的方式和時間段，把同步的溝通變為非同步的溝通，小事留言，大事發郵件，天塌下來才可以找我。當然本質上這是影響其他人效率的，所以適可而止，只在最需要的時候才用這招。
每周空出一段固定的時間思考，不約會議，不排任務，身體和靈魂，總要有一個在思考，如果不是兩個都在思考的話。時間是有彈性的，每次面臨出差或是休假，總能在最後幾天把任務全部close掉，效率會得到提高，同理，如果每周預留出一個時間段給自己來思考，那剩下的時間無疑會更高效。當然實際沒有那麼理想化，總有這樣那樣的例外，總有不合適的時機。但只要有這個意識，試圖給自己留出一些高質量的思考時間，就會有幫助。
當然，管理大團隊，不可避免會有焦慮：
碎片化不可避免帶來了焦慮和壓力。專業能力上我逐漸找到了感覺，但在面對壓力時，還是會恐慌。
本質上來說，壓力來源於目前的能力不足以支撐你的野心。無論是我早期的引擎移植中遇到的專業能力，還是做這個項目遇到的管理壓力，都來自己能力的不足。
> 治大國若烹小鮮(肉)
> by 老子，道德經
沒有太好的手段來解決壓力和焦慮，舉重若輕的自信，來自於更高維度的能力。對我而言，第一次成功的引擎跨平台移植后，面對新的類似任務，壓力就小很多。管理過30人以上的 程式團隊，回頭再管理10人團隊，也不會有什麼焦慮。沒有捷徑可以不焦慮，但有一些簡單的方法緩解焦慮：
短期來看，良好的作息習慣。如果天天加班，回家就好好休息吧。別總是覺得公司加班的時間是留給公司的，晚上回家一定要給自己留點時間，熬夜玩一下。沒什麼是晚上早早睡覺不能解決的，如果有，那就再補一個午睡。中期來看，搞點體育鍛煉，**據說**能很好改善精力，且有巨大快感。這一點我深表懷疑，因為從我有限的運動經歷來看，每次運動完，我都沒有那種酣暢淋漓的感覺，一般的感覺都是更累了… 考慮到時代在變，白領們裝的方式也在變，現在就是流行說自己愛鍛煉，鍛煉包治百病，想來體育運動對緩解焦慮應該也有一定的幫助吧。
長期來看，當然就是提高自己的能力，讓自己配得上這個崗位。至於怎麼做，這個系列你都看快看完了，還要問我這個問題？
顧煜：遊戲 程式員成長編年史(7)116 讚同 · 20 評論文章
說完人，再來說事。
天涯明月刀開發幕後，聊了很多大項目開發幕後的選擇和糾結，也有一些強行拔高的理論，比如這個：Surprising-driven development
共同的願景，是吸引大家走到一起來的重要因素。
軟體工程這門學科，發展多年，留下了好多術語。眾多術語中，Test-Driven Development深得我心，測試驅動開發的理念本就不錯，更好的是這種英文表達方式，特別軟體工程。隨便什麼事情，拿這個語法一套，就是濃濃的專業范，比如咱們日常開的小車，就是一種Human-Driven Car。
天刀項目的前期，應用的最重要的軟體工程實踐，是Old Yu Driven Development。而Old Yu驅動的力量過猛，Leader們的短線撫慰不足以平複員工心頭的傷痕。我們還需要更長線的凝聚力。
項目長線的凝聚力，來自於Surprising Driven Development，我所謂的驚喜驅動。Surprising Driven Development有兩層含義，一個含義是對內的驅動力，指團隊的自我激勵，我們在這篇文章講，還有一個含義是指版本對外的目標設定，下一篇再談。
做項目不是談戀愛，團隊並不因為情投意合而相遇，也不會因為各執一詞而散夥。成年人看利益，一時的榮辱那都不是事兒，團隊只會為了碌碌無為而恐慌。
> 當他回首往事時，不因虛度年華而悔恨，也不因碌碌無為而羞恥。
> 《科學煉鋼指南》天刀在漫長的開發過程中，充滿了觀念衝突、前途黯淡、方向不定，引導大家走出黑暗的，是一次又一次的版本。麵包會說話(breadtalk)，產品也會，Product talk，讓版本證明自己，給大家注入雞血。很多次都懷疑這條路是不是能走通，很多次都感覺進度來不及了，整合完不成了，Bug太多了，做得不爽不想幹了，但最終版本出來的時候，大家會由衷覺得，這一切苦難都是值得的。
半年後的第一次內部Demo就是一個很好的例子。Demo之前，團隊疲憊而絕望，老於指揮了這麼久，一地雞毛，做了很多片段，但所有的片段都沒有拼接起來，大家有質疑，有不滿。整合Demo時，團隊一起crunch，拼起每一個碎片，發現所有的努力都沒有白費。一直低頭蹣跚前行，戰爭迷霧遮住歸途，轉過山頭，前方是不曾看見的風景，謝謝你帶我們來這裡，這裡有山花在爛漫，有老於在歌唱，畫面美得不可言述。
一個又一個驚喜，先激勵了自己，讓大家有勇氣繼續前行。成功的團隊，不是因為彼此沒有矛盾，而是業績的快速進步，緩解了問題。
媽媽說，只要你跑得足夠快，問題就追不上你。