技術不懂業務不精人員不熟悉的情況下如何融入一個團隊做管理？

01-04

這次機會算是完全一個新的工作內容，單位做了一個內部人事調整，新項目的技術和我之前做的技術不同，所以不是很專業，新的業務之前也沒了解過，不過這段時間自己看書和查資料有了不少了解，但是要說精通肯定不敢說，新的項目組是已經存在一兩年的組，裡面的人員我都不熟悉。帶過一些小項目，但是並不是特別擅長和人打交道。
這種情況下如何快速融入團隊，並管理好這個團隊呢。
前輩們有什麼指導

我有多次類似經驗，就當是自我總結一下。

第一條、最重要的一條、切記的一條：千萬不要新官上任三把火！！！

很多剛提拔上來的小leader，或者剛轉到一個團隊的leader，急於「快速融入」團隊，急於快速樹立權威，急於快速證明自己，加上又有了一點權力，會情不自禁的想來個大刀闊斧的改革，參考自己以往成功的經驗，這裡覺得不爽，那裡覺得做得垃圾，碰到一點問題就覺得團隊個個都很菜，於是引進這個、改進那個、調整流程、改變規範、樹立典型。。。。。。搞得原本穩定的團隊雞飛狗跳，人心惶惶，如果此時業務發展還可以，可能大家忍忍也就過去了；如果正好運氣不好碰到業務發展一般，嘿嘿，小心小報告和怨言到處飛，三個月後背鍋的就是你！

如何面對這種技術不熟、業務不熟、團隊不熟，又不能新官上任三把火的情況呢？我總結為「了解現狀、循序漸進、逐步優化、證明自己」幾個步驟。

【1 - 了解現狀】

新leader的一個典型錯誤做法就是將老的經驗直接搬過來，或者就是按照自己的喜好來管，而不是根據團隊和業務的實際情況來管理，這樣做輕則被團隊認為瞎指揮，重則成為背鍋俠。

為了了解業務、技術、團隊的現狀，第一件事就是「拜碼頭」，也就是找相關人的人全部聊一遍，包括：你的BOSS、產品經理、項目經理、測試人員、組內所有開發人員、配合的項目組、運營人員。。。。。。等等，主要了解如下信息：

業務的介紹：這個業務規模多大，收入多少，在整個部門的業務中什麼地位，老大們怎麼看，各個利益干係人怎麼評價這個業務，業務現在是停滯還是發展，是問題多多還是表現良好，後面會加大投入嗎。。。。。。
團隊的評價：團隊氛圍好么？技術能力如何？是不是經常出問題？與產品配合如何？經常和產品吵架么？研發和測試配合怎麼樣？。。。。。。
人物的評價：誰是技術最好的，誰是業務最牛的，誰脾氣比較大，誰性格比較好，誰比較拚命，誰表現一般，每個人自己如何評價自己，如何評價團隊其它人。。。。。。
各方期望：BOSS為什麼派你去？產品經理希望你做什麼？項目經理給你的建議？團隊成員的訴求？配合方的建議？。。。。。。

拜碼頭大概需要一周時間甚至兩周時間，不要急，跟一個人聊完後，消化一下，別一天跟10個人聊，信息量太大你也吸收不了。

第二件事就是「用產品」，不管什麼業務或者系統，你至少要簡單的用一下，體會一下。是Web還是App ？用戶在什麼時候用你的產品？主流程是怎麼樣的？全流程跑一遍有多少步驟？系統包含哪些基本功能？當然，用產品的事情並不一定要等拜完所有碼頭後才做，而是可以穿插進行的，你跟產品A聊了一下，然後體驗了一下業務，理解會深一些；你再跟運營B聊一下，再體驗一下，理解又會更深一些。

第三件事就是「看文檔」，把這個業務和團隊積累的文檔都大概的掃一遍，了解更多歷史和細節信息，能夠更好的熟悉業務和熟悉人。比如說有的人寫的文檔很好，有的人寫的文檔很一般，有的人一篇文檔都沒有。

整個了解現狀的時間短則一兩周，長則一兩個月也是可能的，看業務和團隊的規模而定。

【2 - 循序漸進】

拜完碼頭，體驗了業務，看完了文檔，你以為你就很熟悉團隊、業務了？圖樣圖森破，有事拿衣服，其實還差得遠呢！第一階段你能獲取到的信息有30%就不錯了，更多的細節信息需要在工作中持續觀察和體驗。

比如，產品說系統不太穩定，經常出bug，但到底「出bug」是什麼意思呢？頁面經常掛掉？系統經常宕機？用戶投訴很多？還是出了bug處理很慢？。。。。。。

比如，項目經理說版本開發效率一般，那什麼是「一般」呢？是bug太多導致測試周期長？是進度不合理導致總是延遲？是突發需求多導致版本經常變更？是產品經常在測試階段改需求？還是測試環境不足導致版本沒法測試？。。。。。。

比如，A同學技術很厲害，到底是哪裡厲害？線上問題定位很快？開發語言很熟悉？資料庫高手？還是代碼bug很少？

以上種種細節信息，需要你和團隊一起開發、一起處理問題、一起討論需求、一起和產品撕逼、一起和項目吵架。。。。。。等等各種事件中去體會。

這個周期大約持續1 ~ 2個月。

即使你是技術總監、架構師，這個步驟也是必須的，只是具體做的事情可能有所差異。比如對技術總監來說，就需要了解各個團隊用了什麼技術，技術牛人都有哪些，整個團隊的流程和規範是如何的，執行過程中有什麼差別等等。

【3 - 逐步優化】

經過前兩個階段，你對現狀已經非常了解，此時團隊和業務是否有問題，問題在哪裡你都已經比較清楚了，是不是有了想大幹一場的衝動？畢竟都憋了幾個月了。

別急，對於一個已經運作了2年的團隊來說，改革都是讓大家改變習慣，總有人會反對和不習慣的，即使你已經熟悉團隊和業務，也不要來猛烈的改革，這樣會給團隊帶來較大的震動和不穩定因素的。即使你覺得這是一個爛透了團隊，你也不可能把人全部開除然後自己重新組建，因為招人不像開人那麼容易，從零開始組織一個10人的團隊，靠招聘至少6個月，而且新人技術不熟，業務不熟，那這段時間你的業務完全處於停擺狀態，BOSS受不了吧？

但也不能什麼都不做，畢竟對於一個新安排的leader，不管是團隊還是BOSS，都是有所期待的，期待帶來一些正向的改變，啥都不做就是辜負了各方的期望。

所以我推薦逐步優化，技巧就是先挑一些簡單的優化推行，讓大家看到一些變化但又不會特別抵觸，對團隊影響也不大，這周優化流程，下周引入一個技術，3個月後架構重構，潤物細無聲的慢慢就把團隊的不好地方改過來了，你也展現了自己的能力，團隊成員也欣然接受，業務表現也不錯，各方評價更高了，BOSS也開心，這是最好的多贏局面。

那如果團隊已經很不錯呢？首先恭喜你，因為你不需要做太多的優化；其次提醒你，沒有完美的團隊，沒有完美的業務，沒有完美的技術，如果你認為啥都不需要做，首先想想是不是自己水平還不夠，看不出問題和找不到提升的空間。

【4 - 證明自己】

經過前面大約半年到一年的時間，業務你也熟悉了，團隊也熟悉了，各方都認可你了，此時可以做一些比較大的動作來證明自己了。但我不建議為了證明自己而憑空想出一些大動作，例如業務完全不需要你卻要引入docker和大數據這類。關鍵還是要結合業務、團隊、技術，來找一些關鍵事件。

比如，我接手A項目（後台系統）的時候，做了系統拆分，減少了90%的線上數據問題；

比如，我接手B項目（遊戲接入）的時候，做了雙中心，解決了機房故障導致業務損失的問題；

比如，我接手C項目（手游交易）的時候，做了架構重構，引入很多組件和拆分系統，降低整站故障的次數和影響。

特別申明：以上內容僅適合於技術leader、技術經理，最多到技術總監，如果阿里的CTO換到滴滴，千萬別這麼做，當然，具體怎麼做我也不知道：）

如果我們公司有這種領導下來，我們腦袋靈光的都知道你就是神兵天降，不跟你跟誰，早就跟你表忠心，重新分配權利了。

一般，表面上看越是不可能的事情成真了，我們都懂，這職位非您不可了。

您需要做的就是，挑你對胃口的骨幹，分配利益，別的照舊。

管理主要的兩件事：管人，理事。

管人就是讓你手底下的每個員工發揮出自己的最大價值，細說起來可能要寫好幾本書，關於領導力知乎上有篇文章如何培養自己的領導力？ - 知乎可以看看。

理事就是把事情理順，使得整個流程暢通無阻自然水到渠成。在這個過程中你自己也會發現存在的短板和不足，以後加以優化改進。

關於自身的修鍊，我比較喜歡推薦的是《麥肯錫方法》，其他還有兩本和這個同意系列的也可以看看。關於管理更多的還是要考自己的領悟，別人永遠無法給你合適的方法，只能自己結合自身的優點去琢磨適合自己的方式方法。

外行管內行是瞎搞

這是不以人的意志為轉移的

delegate. 帶團隊會用人用好人比懂技術業務精通重要。

收買你團隊中有影響力的傢伙

很簡單，不要搞新官上任三把火那套，前三個月就按照原來的團隊管理模式先做一段時間，然後發現問題逐步改進，當然你是大牛的話可以弄點改革啥的。

其實和技術關係真的是特別大，不需要精通，精通了用處也不大，因為技術方面不需要你去指教，如果你精通了這個方面的技術，我估計老闆應該派你直接做技術了，管理方面給別人。你要做的是了解下你們的相關知識，多學習管理理念，多和團隊溝通儘快融入進去，這才是目前的重點。

技術不懂 業務不精 人員不熟悉的情況下如何融入一個團隊做管理？

技術不懂業務不精人員不熟悉的情況下如何融入一個團隊做管理？