技術領導力：程序員如何才能帶團隊

2020030 目前面臨着轉型，這個是我的又一次重大轉型，由技術向技術管理方向靠，所以這本書對我來說是相當鍥合，覆蓋面很廣，很多內容都可以作爲工具書了。 對於技術，我感覺自我學習能力足夠應對各種新技術。但是對於管理，真是心有忐忑，不知道自己能不能真的做好~ 書中很多話都對我有着指導意義： 1. 有的人喜歡多鼓勵，少批評。在平時的交流和會議中，多給予鼓勵和表揚，效果有時候比正式會議的褒獎更讓人感覺舒適。少批評，但批評的時候一定是聲色俱厲、毫不留情。 2. 你的工作是什麼呢，除了技術，還需要保護團隊中的工程師不被打擾，在各方面給他們支持，幫助他們能順利完成任務。同時你還需要在重大的方向上輸出影響力，做決策，定計劃，這也意味着，如果決策是錯誤的，需要你來承擔責任。而有了榮譽的時候，你要退下來，讓給團隊裏那些優秀的人。 作爲團隊負責人，我們也應該有硬漢本色，不能懼怕外在的威脅。團隊成員都在看着你，你決不能懦弱，要勇敢。 在領導層不明確哪個團隊做的前提下，對內組織團隊盡全力做下去，而且要做好，對外則勇於承擔責任，敢於接受挑戰。 在電視劇《長沙保衛戰》中有一段對話，參謀長對薛嶽將軍說：“你若下地獄，我絕不上天堂。”這也是我在團隊遇到嚴重挑戰的時候，對所有成員說的第一句話。想做成事情，你或者你的核心下屬，必須勇於站出來。 3. 被管理者（工程師們）逐漸從單純爲了解決物質矛盾轉化爲追求工作的歸屬感、參與感、技術尊重感，他們逐漸對跟着誰一起工作、採用哪種工作方式、解決了什麼樣的技術問題、做出了什麼樣的產品感興趣，而不是僅僅滿足於金錢的多少。  4. 作爲一名技術團隊管理者，你要做的是比別人更早接觸新技術，更深入地理解系統架構，全面提高管理團隊所需的方方面面的能力，而所有這些都需要勤奮。 ❑ 深入理解一門或多門編程語言❑ 深入理解多種流行的框架❑ 系統架構能力強，擁有複雜系統的設計經驗❑ 積極跟隨開源社區❑ 積極瞭解業界技術發展❑ 溝通能力強、情商高❑ 有產品意識，不是技術迷❑ 會帶人，服從領導，責任心強❑ 會寫專利❑ 再會點別的更好❑ 隨叫隨到、工資不高。 5. 從技術轉管理本身就是一個很大的轉變，一旦跳進去，就很難爬出來了。我認爲最大的差異就是，技術面對的是系統性問題，需要的是邏輯思維能力，是智商，而管理需要面對的很多是非邏輯思維能力，是情商。系統問題需要智商，而人是活的，你要理解人，就需要情商，情商是什麼？我個人理解，情商就是如何站在別人的角度看問題。 6. 在企業裏面成功，不可否認仍依仗兩個方面：要麼你聰明，會交際，懂政治，被人認可；要麼你做出成績，貢獻巨大，被認可。  7. 最好的領導，思路敏捷而清晰，做事務實而高效，永遠沒有廢話，永遠雷厲風行。和他共事，絕對不會輕鬆。他不會講段子哄你幹活，他也不會笑眯眯地安撫你的情緒。 8. 不要讓你的下屬陷入困境，不要讓你的同事陷入困境，尤其是在任何情況下，都不要讓你的上級陷入困境。 9. 你還需要弄清楚如何彙報、如何溝通，以及要採取什麼樣的行動，才能讓你的老闆認爲你是一個高效而成功的員工。 10. 你老闆的級別越高，你的報告就越要精簡，越要注重大局，細節更少、局面更大、文字更少、項目符號更多。 11. 不要把每一個問題都帶到你老闆那裏尋求解決方案。仔細地挑選你的問題，只拿那些真正重要的問題去尋求你老闆的幫助。 12. 你還要避免只把問題帶給領導的情況，最好是拿着幾套潛在的解決方案和問題一起交給他。 13. 即使你沒有特別好的解決方案，或者沒有找到最好的解決方案，也會讓領導覺得你已經做好了自己的功課，過來找他是爲了尋求他的建議和忠告，而不是直接把問題拋給他。 14. 學會給人驚喜與歡樂。瞭解哪些事情會讓你老闆時刻關注，並找到辦法超水平完成任務，最好是超過他的預期。有時候其實並不是做得越多越好，而是處理較多複雜問題。 15. 你可以非常好地管理團隊並完成項目，但如果沒有你老闆爲你護航，你的職業前途必然坎坷。 16. 爲了有效控制進度，開發經理需要請各個小組每天召開“晨會”以檢查昨天工作進展，並且佈置當天工作；另外，每週五下午召開周例會，項目組全體成員都要參加。

從程序員到初級技術管理者之路，確實是一次角色的轉變，關注點的變換會讓很多人不適應，似乎就是被彼得定理限制了。 必須以成長型思維來對待技術管理者的日常，畢竟從局部提升到了整體，格局要大才能持久。 本書從團隊組建、團隊建設、技術研究、技術管理、過程管理、系統架構等方面做了深入交流，很適合第一次轉型的程序員同學閱讀。

非常好的一本書，能結合實際一步一步走下去，最大的收益是當項目啓動或者新業務開始時不要過度設計，不要想太多，先讓業務跑起來。在合適的階段做合適的事情。

當團隊中每個人的潛力都被髮掘出來，能力的集合纔是巨大的，才能所向披靡。技術管理就是這麼一種組織團隊共同進行研發的工作，它是一門細分工種，隨着社會的進步、人類思維的開放、經濟水平的提升，被管理者（工程師們）逐漸從單純爲了解決物質矛盾轉化爲追求工作的歸屬感、參與感、技術尊重感，他們逐漸對跟着誰一起工作、採用哪種工作方式、解決了什麼樣的技術問題、做出了什麼樣的產品感興趣，而不是僅僅滿足於金錢的多少。同時，被管理者之間還存在緊密的社交關係，能夠隨時保持溝通，分享對在該公司或組織工作的切身感受，分享對於管理者個人能力、品德的認識。每位技術團隊管理者，也正在像書一樣被擺放在被管理者面前，如果別人懶得翻你，就證明你不能給予他們指導，他們沒有歸屬感，最終都會匆匆離職。

對技術領導力技術管理架構師剖析全面的一本書，個別章節囉嗦低價值扣掉一分。要做技術領導必須技術先行於管理，技術領導最好能在技術團隊中起到架構師的作用，對新技術持續的熱情，業務中不過度設計又考慮橫向縱向的業務拓展後的技術升級或架構鋪墊，總之技術的落地要基於業務，業務需求是技術驅動力，不能解決業務問題的技術是無源之水。技術管理人員值得一看的一本書。

技術領導的核心競爭力可以總結爲把控技術、組織協調能力、主觀能動性、推動項目組成員一起成長，保證團隊的穩定性。 技術管理者的發展方向 某一領域的技術深度，擁有技術廣度，通過自己的技術能力帶領更多隊員一起進步，目前都會遇到這幾個情況 1）隊員工作沒有自己做得好，花時間去溝通還不如自己去做。 2）感覺自己的技術在退化，長期不寫代碼覺得自己沒有價值。 3）發現自己不懂的東西越來越多，覺得把管理做好不太容易。 4）上面有領導催活要項目進度，下面有開發要方案提供技術支持，需要評估客戶的項目難度和耗時，並對需求進行扯皮，夾在中間心累。 需要提升溝通能力，個人定位能力（是否需要分配代碼量給自己，或者充電），技術+管理雙向充電。 技術還是王道 爲什麼對自己沒有信心和一丟丟害怕，究其根本就是不瞭解，對技術、人員、項目的不瞭解，其中技術佔有很大部分。只有擁有了相當的技術廣度和深度才能給團隊的技術指明方向，在團隊成員遇到難題時能加以引導。 工作品質 從說話做事就能看得出工作品質如何，要透露出工作的專業性。分析->執行->總結。纔會讓大家覺得這這個人很專業，分析、執行力一氣呵成。 1、成熟 重視承諾，不拍腦袋，懂得爲人處世。任何不清楚的事情不能拍板太快。比如評估工作量和項目進度，若有未知風險或者模糊之處不要馬上評估，彙報時要加上如果xx是用xxx方法來做的前提。 2、勇敢 作爲團隊負責人，遇到困難時，不必要懼怕外在的威脅，團隊成員都在看着你，不能懦弱要勇敢。當團隊遇到問題了要主動站出來承擔責任勇於接受挑戰。你就是成員的門面一堵牆，要自信，一旦有了決策，就要落實，不必要拖泥帶水（如果自己都不確定，成員就會覺得這次做了會白做？所以決策時要再三確認，一旦確認就去做） 3、勤奮 在軟件行業。沒有在專業上的持續學習和成長是不會成功的。技術變革如此迅速，如果不堅持學習很快就會被淘汰。 4 邏輯能力 爲什麼有的程序員能夠很快解決Bug，有的則不能？首先，你需要對整個事情的全局情況有深入的瞭解。知識儲備夠了才能迅速找到問題所在。有時評審方案時，可能稍不注意就被下屬的錯誤邏輯給“忽悠”了。一個人的邏輯能力屬於軟實力，它是決定你是否可以承擔團隊領導職責的關鍵因素。 5 一線作戰能力 無論多麼忙，都要不斷地抽時間和大家一起討論架構、業務流程、技術難點、技術方向，這是你的職責，而不是讓團隊處於流浪狀態。簡而言之，既然你直接管理團隊，就要以身作則，讓大家看到這個團隊和項目是有人在積極推進的。 管理人才的決策能力 1 會議能力 抓住會議主幹線，推動項目進程，解決項目堵塞點，報出項目風險。當下屬討論的細節層次不在議題範圍內時，要及時打斷，會後在談。並總結會議的重點，指定推進。時刻抓住會議的目的，保證高效。如果是和業務開會則應在會後發出紀要避免扯皮。 2 判斷能力 方案需要決策時，要克服從衆心理，要有自己的底線（比如編碼規範）。快速的決策通常錯誤率較高。決策的目標應該是明確的，決策的結論應該是簡單而清晰的。 3 自信心 面對困難，不要去逃避，方法總比困難多。培養自己的責任感和義務感，跳出個人的小天地，如此你的自信才能堅實可靠。另外平時交往注意要選擇那些有自信心、敢作敢爲的人，時間長了，看得多了，你必然會受到積極的影響。 技術調研 1）這些技術分別是什麼？ 2）技術調研方案、用例分別是什麼？ 3）各個技術或框架之間的區別是什麼？ 4）各個技術在通用場景下的優缺點是什麼？ 5）各個技術在用戶提出的特定業務場景下的優缺點是什麼？ 6）根據得出的測試數據，爲什麼會有這樣的結果？ 介入新團隊項目開發 人員組成，開發能力，週期評估 核心功能流程圖理解 瞭解歷史來源，上下游影響，各個模塊的關聯關係 需要定位增加的需求風險點，提前調研關聯影響 項目核心價值，定位。走什麼方向能體現出的團隊的價值（繼續做業務需求或者提升現有性能），業務提的需求的實際應用型 不合理的設計能否在版本內進行重構 版本約定 1）每個項目都應該有自己的版本和時間點，這樣對於團隊每個人來說纔會有個標杆是否需要加班完成。 2）開發、測試、SIT、UAT、生產演練都需要明確。火車一旦啓動，就不給插隊。 架構約定 這個又是一件費腦袋的事情，我們需要架構師來回答以下問題，當我們啓動項目時都應該明確。 ❑ 我們這個系統的邊界是什麼？ ❑ 我們系統由哪幾部分組成？ ❑ 各模塊之間怎麼通信？ ❑ 選擇什麼樣的基礎技術？ ❑ 爲什麼要這樣選擇？ ❑ 技術方案未來會遭遇哪些坑？ ❑ 我們的備選方案有哪些？ ❑從技術角度這個應用將來如何持續擴展功能？

粗略看完第一章就看不下去了。提的要做好技術管理的點太寬泛太抽象，實際上這些點不做技術管理一樣也有收益（所以感覺是在說一些正確的廢話），那麼我幹嘛來看這本關於技術管理的書呢？我直接看個人成長之類的不就行了？

從目前的程序員角度不錯，介紹了技術的方方面面。但是從一個 CTO 的角度來說這本書就差了那麼一點。 關於產品研發，這個產品作用是什麼？目標是什麼？戰略意義？優先級如何？ 之類的問題綜合分析了之後，才能決定研發資源，研發週期，技術選型等等。 另外本書本質上沒有解決技術管理頭上的最大問題：在技術和管理之間應該如何去平衡。 這方面將目前中美是如何做的，差異在哪裏？美國之前怎麼做的，現在爲什麼演變成現在的模式了。中國處於哪一個階段？最終給出技術管理崗未來的演進方向並給出目前的最優策略。 作爲一個技術管理人員，甚至CTO不應該只拘泥於代碼如何寫，而是應該現在公司戰略的解角度，行業發展的大背景下分析問題，最終落到技術上才更加的現實。

看完這本書，領導力沒學到啥，倒是幫我好好回顧了一下自己職業生涯。 畢業幾年，換了好幾任leader。一開始覺得leader像導師，幫我成長。後來覺得leader是老頑固，阻礙我引入新技術。再後來覺得leader其實也是夥伴，大家互相成就。 仔細想想，幾任leader其實沒有本質的差別，只是自己的心態在不斷變化。在不斷地成長中，我也逐漸明白一個leader的思考方式，和各種迫於業務的無奈。畢竟每個人都有成長過程，leader也一樣。 在此感謝我一路走來遇到leader們，謝謝啦！

看了本書之後，真正理解到了技術領悟的管理，真的不同於非技術爲主導領悟的管理。作者結合自己多年的管理經驗，以圖文結合，敘事，心理暗示，的方式向我們解析了互聯網行業什麼叫管理，什麼叫自我管理與向上管理，管理的目的是什麼，技術架構師這個站在技術領悟金字塔擁有技術決策權與人員分配使用權的角色該承擔哪些崗位職責與做哪些前期的風險評估，通過本書可以瞭解到互聯網公司的架構師與高級管理員這個可以雙重合並也可以單獨平行的職位如何以自我約束，自我修煉的形式陪伴團隊成長，指導團隊協作，引領團隊技術潮流的形式使得最終的結果是趨向於事情完成得很漂亮，然後團隊的技術也更進一步了，團隊之間的化學反應也更好了！特寫大讚的一本書！