[[196875]]

【51CTO.com原創稿件】現在業內有太多的技術分享大會了。我們經常會看到來自各界的高手，從 VP、總監、架構師到高級工程師，他們站到臺上講各種漂亮的基本架構，或者講一些很成功的案例，講怎么管理團隊，講成功學，講如何帶隊伍等。

[[196876]]

為什么要講研發管理中的坑

一個貌似完美的技術解決方案或先進的方法論，往往看不到落地時的慘痛失敗。這種案例很少有人講。但失敗的經驗教訓對于我們卻是極其重要的參考。

我提出的第一個問題就是：別人成功的“術”，很可能不是我們的成功術。比如，我們看到 BAT 的敏捷教練講研發經驗談的各種迭代，各種訓練的方法，然而到自己嘗試時，為什么行不通呢?

BAT 校招的工程師都是 15K 以上的研究生，是全國的尖子生，而我們自己的團隊成員呢?我們只看到了“術”的表面，卻很容易忽略“術”背后的因素，比如工程師的水平。

近兩年，我們看到業內有越來越多的人分享“踩坑”的經歷。有的踩坑經歷會分享技術的演化路徑，不再是技術呈現的最終結果，而是分享整個演化過程。從一開始的弱小，中間遇到哪些挫折，遇到問題之后是怎么解決的。這是很好的一個趨勢。

再舉一個“別人的成功術”的例子，比如“賽馬理論”。所謂賽馬理論，偏激一些地講就是一個業務，多個團隊并行做，誰做的最好誰就能留下。能承擔地起“賽馬”的一般只有超大規模的互聯網公司。

一般的中小型公司，一個技術團隊就幾百人，哪有這個資源。“別人的成功術”往往是在特定的場景下、特定條件下的經驗，所以脫離了背景信息，借鑒起來就會很有難度。

[[196877]]

為什么還要講“踩坑”這件事情?因為中小型公司研發團隊或者大公司里面的小團隊最稀缺的是資源和時間。為了追求更有效地達成業績目標，團隊避免踩坑越來越成為大家的剛需。

還有個有趣的說法，解釋為什么管理崗的薪資會更貴。專業人員因為踩坑而沒有業績產出，大不了一個高T的100萬年薪浪費了;而如果一個管理崗做出失誤決策，那么就會帶著幾十、幾百個兄弟集體跳坑。

管理崗的經驗主要是靠帶年薪幾百萬甚至幾千萬的隊伍做千萬甚至上億的項目訓練出來的。也可以說管理崗的經驗主要是通過踩坑踩出來的。管理崗有多貴，主要看踩坑的代價。

一般來講，踩坑分為兩類：

• 研發管理人員自己踩的坑。
• 研發管理人員帶領團隊踩的坑。

我們從管理幅度的角度來給大家聊一聊研發管理人員自己踩的坑。

如何避開研發管理人員自己踩的坑

一線管理崗，帶領團隊規模在 10 人左右

當我們從團隊領導晉升到一線管理崗的時候遇到非常核心的兩個問題，一個是時間特別碎片化，第二個是不滿意團隊成員的業務能力，自己卻身先士卒地沖上去了。

時間特別碎片化

時間碎片化在這個階段最為嚴重，被開會、被溝通、匯報工作、指導下屬、寫文檔、以及一點自己專業上的事兒。而且在這個階段的一線管理崗還很難對“被打斷”說“不”。

面對時間碎片化該怎么辦?當我們在這個崗位的時候，我們所有的精力都在做什么呢?就是一件事——執行。一線管理崗不需要談公司藍圖，不需要談公司戰略，就是踏踏實實地把手里的業務完成。

執行的過程，又可以拆成若干個關鍵事項。抓住了關鍵事項，執行結果就很有保障了。我的習慣是每周把正在跟進的一大堆事情記在一個文檔中，每個事項的進度在一周內實時更新，有點像自己寫給自己的工作周報。

比如，績效考核我要跟誰去溝通，運維的事情怎么樣，團隊有幾個重點，不同的團隊做什么事，誰具體負責什么，我本人需要在哪一個時間點跟進。這張簡單的表格對我的幫助很大，幫助我把自己的時間管理好，把關鍵事項管住。

當管理者把自己的時間和精力管住之后，會驚喜地發現整個團隊業績也會同步提升。

所以一線管理崗在應對時間碎片化的時候，核心原則是，時間可以被碎片化，但關鍵的事兒要保證能抓得住，并根據每周關鍵事項列表來 review 自己的精力投入。

自己身先士卒

反而容易使團隊成長緩慢。我們常常看到這樣的現象，老板給的指標重，一線管理崗總覺得自己的兄弟短期內能力提升太慢，為確保項目目標，管理崗自己身先士卒。

結果幾個月高強度 996，自己寫代碼的時間超過 50% 甚至 60%，管團隊的精力越來越少，忽然發現這幾個月中團隊的小兄弟們還是沒什么成長。

而團隊小兄弟面對外面大把的機會，感覺自己長期得不到指導，技術沒提升，這時候團隊人員流失風險就大了。

遇到這種情況怎么解決?我建議業績壓力再大，管理崗也該為招聘留時間。2014 年，我帶的團隊壓力非常大，一邊扛著非常重的業績壓力，兄弟們 996，另一邊使勁招聘。

那一年，我面試的技術高手有 60 人，前面還有 3 輪技術面試，每一輪面試不低于 1 小時，可以粗算一下當時為招聘這件事是下足了時間成本的。但只要真進來幾個靠譜的人就值了，之前團隊為招聘付出的精力很快可以找回來。

保證項目目標時，還很考驗管理崗的跨部門協調資源的能力，以及將客觀困難給老板們表達清楚的能力，從而爭取合理地調整任務目標或者引入跨部門的資源來降低團隊成員流失的風險。

老板們都會算一筆賬，對一支團隊的業績壓力過大，把團隊壓垮了，人員流失了，團隊重建的成本會更大。

在這個階段，對于一線管理崗，我推薦一本書《卓有成效的管理者》，這本書的作者德魯克開篇就講時間管理。

二線管理，團隊規模 30-60 人

這個階段常見的幾個問題有：原來帶 10 人的時候精力還覺得不足，現在帶 30-60 人，精力就更不夠用了;通過其他的管理者管理團隊，隔層管人，很容易執行不到位。

到這個階段之后，每天就是開會，寫文檔，我們會發現技術高手出身的管理崗，專業能力很可能會退化。最大的挑戰就是我們這層管理崗幾乎決定了整個團隊的水平和高度，所以壓力很大。

先說精力不足的應對方法

第一，我們只能夠做重要且只有我能做的事，那么其他事情盡量授權。

第二，開始保護我自己的精力，因為每個人的精力有限，對沒必要的事說不。甚至只要不是需要“我”去做決策的會議，統統說不。

第三，就是整塊地使用個人的時間，我覺得這個對提升工作效率幫助非常大。

舉一個例子，2012 年有一段時間，我感到自己瑣事非常多，其中 IM 類溝通工具經常打斷我的連續工作，而工作場景切換代價又很大，于是我就把 QQ/MSN 全部關掉了，只保留郵件，還關掉郵件標題的提醒。

有一些同學說，把聊天的工具關掉了，還不實時回復郵件，別人找不到我的時候得多著急啊。請放心，你才帶幾十個人，如果真有火燒眉毛的事情發生，一定會有人打電話催你的。

這是我覺得提升工作效率特別有效的一招。給大家一個建議，最好把我們的時間變成整塊的，20 分鐘也好，30 分鐘也好，這在時間利用效率方面會提升很多。

第四，我以我的時間安排為準，調整了整個團隊的工作時間和優先級。

背后的思考是這樣，在一個 60-100 人的團隊中，信息量最大的人不可能是小朋友，一定是團隊的管理崗。

這位管理崗擁有這團隊中所有重要的信息，比如重要項目的業務價值，每個項目關系到自己團隊、關系到跨部門團隊的利益，甚至關系到公司層面的戰略意義等等。

不是說團隊管理崗的時間比一線員工的時間更寶貴，而是團隊管理崗的時間安排，本質上代表了我們這支百人團隊所負責項目在執行層面的優先級。

如果管理崗變成救火隊員，那么這個團隊的狀態一定出了問題。如果我們看到老板時間安排的井井有條，那么他所帶的團隊狀態往往是不錯的。

通過其他管理者來管理團隊

容易出現執行不到位。從二線管理崗的角度看一線管理崗，可以清楚看到他們常常出現時間碎片化和關鍵事項抓不住的問題。

我們曾經實踐過一個有效的管理辦法，對初級管理崗推行“標準管理動作”。

2012 年，我們給新晉升的開發經理推行“新晉升開發經理的標準管理模板”，內容包括技術架構方面做哪些事、每件事的達成標準、技術團隊管理和技術產品運營的具體產出物，再比如開發質量要管住哪些事，團隊開發資源使用效率的衡量指標。

我把這個標準管理動作模板放在那，每周定一個時間點，照著標準管他們要結果。在新晉開發經理剛走上管理崗的時候，不求他們應用所謂藝術的管理手法，先要求他們把標準管理動作統統執行到位。

個人的專業技能成長放緩，甚至負成長

解決的辦法，管理者首先要確定自己的專業方向是什么，比如有人追求不斷提升對業務、對行業的理解，或者有人追求對技術解決方案的認識廣度。

確定自己的專業方向之后，保持與行業內朋友們的交流和互動。建立工作機制，每周留出一定精力，參與一線專業討論，甚至一線指揮一些小項目，讓自己保持專業的敏感度。

最大的困惑來自：團隊的管理者決定了這支團隊的高度。

• 第一個維度，從公司的角度算人力成本，少則這個團隊年薪總和幾百萬，多則上千萬。
• 第二個維度是團隊的兄弟，這一年下來，幾十位兄弟拿出風華正茂的時光跟著我們干了一年，到年底，我們能拿出什么樣的團隊業績給兄弟們作為交代呢。
• 第三個維度是我們自己，我們在全行業排名什么樣，我們做的產品在業內被不被認可。

綜上幾方面，來自公司的壓力、兄弟們的付出、自己的期望，很大層面取決于團隊管理者的水平。

我覺得這里面沒有具體的辦法，就是不斷學習，不斷地進取，UP or OUT。如果你在這個階段，那么《明茨伯格·管理進行時》這本書很適合你。

管理層級再增加，團隊規模百人以上

第一個挑戰

保證團隊工作質量難度越來越大。管理層級增加以后，團隊的工作質量就越來越難保證了，這個時期首先梳理工作流程、工作制度、崗位職責，構建管理儀表盤，并且不斷更新優化。

管理儀表盤本質上是我們的管理抓手，我們該看什么數字，不看什么數字，以及對每個數字的解讀，這體現了我們帶團隊的功力和對業務的深刻理解能力。

第二個挑戰

保證團隊氛圍一致性越來越難，保證整個團隊對目標認識一致越來越難。當你發現團隊達到幾百人的時候，最容易出現這樣三個現象。

• 當我們明確了團隊目標之后，團隊目標再被層層拆解 KPI，到團隊每位成員落地執行的時候，對這個事的理解和執行不一致，甚至出現本位主義。
• 信息下達時被層層衰減，事情在傳達幾個階段之后，可能與之前的事情描述就完全不一樣了。
• 團隊氛圍和風格不同，有一個團隊特別的主動，有的團隊按部就班，有的團隊執行力非常強，有的團隊不作為還找借口。

分析以上現象，診斷問題出在這里：團隊成員在信息量上和對信息的理解上出了問題，以及團隊成員在團隊目標、文化、氛圍方面的認同不一致，管理標準不一致。

分享我實踐過的有效解決辦法：

• 保障信息上傳下達的通道能通暢，盡量降低信息損失。
• 管理力下沉，二級匯報定期參加管理例會，不說項目，只談團隊管理，保證信息下達的深度，不斷強化團隊目標，統一團隊管理者的價值觀和方法論。

第三個挑戰

在這個階段的時候，公司層面業績壓力巨大，團隊層面的高期望，自己的家人也需要我們陪伴，自己身體健康問題等，我們在這幾者之間找不到平衡。

我本人在這個挑戰方面，現在還沒找到一個很好的辦法。

如何避開研發管理人員帶團隊踩的坑

重構：開發工程師們的好勝心

開發工程師往往會主動發起一些重構項目，尤其在他們接管了別人的代碼以后。還有某個技術流行了，什么東西火了，什么時候重構項目就冒出來了。

工程師特別喜歡把一個簡單的事兒搞的特別復雜，僅僅是因為可以用上更牛的技術。這是他們的驅動力。

然后為此找一堆理由，如代碼可讀性差、業務可維護性差、結構可擴展性差、甚至原來的代碼風格很難看、維護成本太高、原來的架構不能支持多人開發，然后再給管理崗秀一個特別棒的技術重構方案。

這是工程師們的情懷，情懷這個東西是擋不住的，是剛需。我講一些我沒有管住他們情懷時發生的各種案例。

[[196878]]

重構失控，最小的代價是延期，有的工程師在做小項目時，他順手重構了部分代碼;你去問項目為什么延期，他告訴你原來架構不行，給它重構了，所以項目延期了。這是小的損失。

某些關鍵代碼在重構過程中，某一個骨干工程師突然拿到了一個無法拒絕的 Offer，然后就慘了，項目遭受中型損失。

重構項目啟動了，但深陷其中，出不來了，這是大型損失。

還有超大型損失，那就更慘了，弄了一個幾百人上千人的項目，突然組織調整了，或預算調整了，或競爭對手上一個新功能，我們不得不停掉手里所有項目跟上去開發新功能等等。

這么多失控的項目，它的損失都是在重構的過程中導致的。

怎么來平衡這種情懷和項目失控的風險呢?

理想的情況下，我們一般都會把開發資源預留出 20%，這部分資源是技術團隊做重構、架構優化或者探索創新性的項目，并把這個事情制度化。

第二件事情，專門為重構設定一個立項流程，工程師們可以重構，但一定要將重構正式引入項目流程，并做好評估，無論重構項目的大小。

第三個，針對重構項目的風險，我們要準備好風險預案。像超大型的重構，要慎之再慎。

工程師“我有一把錘子”的慣性思維

名字聽起來就挺有意思，但這把錘子砸了我們自己很多次。

我們經常會看到這樣的情況，算法工程師看到什么論文了，或者是開發工程師們學了新語言或者新類庫，比如學了 spark，看哪都想并行計算一下。

這個階段還不叫我有一把錘子，這個階段叫“我得到了一把錘子，想找個釘子敲敲”。這個階段你是管不住的，他一定會找一個大家看不見的地方練練大招，等他練嫻熟了，就會出現“我有一把錘子，看哪都是釘子”的現象。

我們發現“我有一把錘子”這個事兒是非常典型的工程師慣性思維。工程師往往會從最熟悉的角度看問題，用自己最熟悉的辦法解決問題。

從熟悉的角度出發，他們常常可以一下子想到各種各樣的招兒，但也往往是問題還沒完全看清楚，“招兒”就出來了。

真正落地執行遇到困難之后，猛然發現這把熟悉的錘子根本不是合理的解決方案，但時間精力已經消耗很多了。這是工程師們經常出的問題。

如何解決工程師“我有一把錘子”的慣性思維?

最重要的事情是需要管理崗抓的足夠細，越早發現問題越好。

為什么說管理崗一天 12 小時都不夠就是這個意思。你要挑戰工程師直到完全搞清楚，從現象是什么，到問題分析，問題到底是什么，為什么采用這個解決方案，這個方案的特點是什么，怎么解決等等。

“我有一把錘子”這樣的問題在產品團隊很少出現，他們往往跟業務人員思考模式類似，會將要解決業務事情的周邊情況仔細盤問一遍，他們會做預研，會做推演。

開發的同學們在研究問題時往往“跳步”，特別容易掉進去。開發的負責人要抓得細，抓的早，聽方案匯報的時候要聽的深。

重構的美好理想與殘酷現實的差距

前面說工程師們會把重構想的比較美好。其實公司高管，CEO/CTO/技術總監們也常常寄希望于重構，主動發起重構。

似乎覺得可以通過一次重構，解決技術上的所有問題。非常遺憾，真正按我們的標準實際達成的幾率極低。

有三個原因：

• 預期過高。因為任何一個東西沒出來之前，在你腦海里面都特別美。
• 理想與實際之間的達成路徑沒有規劃清楚。比如團隊中有足夠的工程師資源嗎?如果出問題的話，哪一塊能夠出問題，預案是什么?會用到哪些關鍵技術，預研過嗎?
• 還是人的原因。團隊中是否存在一位能將整個項目方方面面思考清楚，從業務到產品，再到架構和研發，從最前端到最底層都能串起來的人才。如果沒有上面三點的保證，全憑一腔熱情，項目失敗率豈能不高?

針對以上問題

首先要解決的是預期過高的問題，跟老板在預期目標方面達成一致，比如按照老板的想法，先產出一個高保真產品原型做確認。

這就相當于把天上的小龍女變成地上的小龍女。接下來找到靠譜兒的人，規劃達成路徑。

無論是人還是達成路徑不到位，都不要隨意“拍胸脯”。“拍胸脯”是職場大忌。承諾無法兌現，會讓信任指數大打折扣。

要當心漂亮的嘴巴

大多數開發出身的或者典型的開發給人的印象是這樣的：嚴謹、負責、內斂、謙遜、扎實、上進，這是典型的工程師的形象。

[[196879]]

當我們遇到這樣一個工程師：不僅追求技術，還能把技術架構講的特別清楚，而且還能給你講業務，搞得定產品經理，哄得了測試的妹子，可以解決團隊當中跨部門協調的問題。

這樣的員工，一定要當成大熊貓一樣保護起來，這是未來的干部，要重點培養。為什么他們要重點培養呢?因為他們有一張漂亮的嘴巴。

據我個人的“不完全統計”，“說得比做得好”的人往往是“漂亮的嘴巴”。

• 第一個觀察，大多數工程師內斂、謹慎，那么他預估項目的工期會怎么樣呢?當然也是偏保守了。而這些嘴巴很漂亮的工程師，他們的性格往往比較樂觀，在預估工期方面表現得樂觀而激進。
• 第二個觀察，漂亮的嘴巴對事物描述能力往往也強于普通青年，他們會描述的很鮮活，讓我們在腦子里有一個過高的預期。
• 第三個觀察，我們會發現這些人大多數成長路徑比較順。比如很小的時候，陽光外向的小孩子往往就是老師們和同學們的寵兒，在這種馬太效應的正循環下，漂亮的嘴巴得到正面的激勵比普通青年多的多，于是進一步在表現能力方面與普通人越拉越遠。

我認為漂亮的嘴巴是典型的“謀士”，而不是“將軍”，是不能帶兵打仗，尤其是打硬仗;若委以重任，項目風險很大。

那么漂亮的嘴巴是該被棄用，還是該被培養呢?我堅持認為，他們仍然是培養的好苗子，只不過這些小伙伴們需要一個沉淀過程，一個將說的標準和做的標準統一起來的沉淀過程。

同時，管理崗沒必要把溝通能力作為核心的考察能力，反倒是在團隊工程師們不善于表達成果的時候，管理者要做到心知肚明。

對于每位員工的貢獻有所了解，讓員工們不要糾結于向上匯報，而是專注在工作本身，同時在獎勵、晉升、項目方面給予公平的回饋，這才是管理者的硬本事。

[[196880]]

傅強

九枝蘭合伙人和CTO

為企業提供在線營銷的整合投放服務。2006 年-2015 年任職當當，從工程師、架構師、高級總監到技術副總裁，見證了中國電商時代的風起云涌，先后研發了當當網站內搜索引擎、個性化推薦引擎等高實時性高可靠性服務，2011 年/2012 年推動大數據技術應用，大幅提升數據挖掘能力，崇尚“讓技術創造價值”的理念，2014 年升級大數據計算能力，結合算法尤其是機器學習的能力，通過推薦系統和廣告系統創造數億的增量商業價值。

 以上內容節選自 CTO 訓練營出版圖書《CTO說》，根據 30 多位CTO訓練營導師的課堂分享內容整理、改編，包括樂視網 CTO 楊永強、360 副總裁譚曉生、跟誰學 CTO 李鋼江、花蝦金融 CEO 段念、極客邦科技總裁池建強等。

更多內容查看：https://item.jd.com/12065279.html

CTO 訓練營為 51CTO 推出的面向中高端技術管理者的學習及社交平臺，16 年推出以來受到了行業里的中堅技術力量的歡迎，邀請了行業里資深的技術高管、技術類型的投資人以及技術創業者，打造技術管理者的 MBA，幫助中國最具潛力的技術管理者成長為未來技術領域的領袖。CTO 訓練營第四季正在招募中，愿意加入我們嗎?

http://x.51cto.com/?51cto

[[196881]]

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】