沒有人會認為自己是一個主次不分的笨蛋，但實際上，團隊合作過程中表現出來的綜合智商就是低于個體智商的。 再加上，團隊中，總是會摻雜一些“不知道自己不知道”的盲目者，最終會把團隊帶向歧途。

舉一個在騰訊內，很典型很常見的例子。

本來有一個團隊，可能原本他們是負責一款軟件 App 的研發，在執行工作的過程中，發現自己缺少了一個基礎組件。這個組件可能是一個 crash 率的監控組件，也可能是一個為了解決性能問題而誕生的性能監控組件，還可能是性能輔助工具或者日志工具組件，等等。所以他們就會安排員工自己去做這樣一套工具組件出來。

當工具組件開發完成，也能夠滿足自己使用的同時，他們就會誕生一個想法，就是這個工具組件，在旁的團隊是不是也需要？這樣常見的工具，很大概率大家都會需要吧？如果我們把這個組件推廣出去，我們的技術價值是不是就會擴大？研發同事是不是就有更多的晉升素材？大家似乎能從中撈到好處，而且是以技術的名義，看起來還很正義。這樣的想法，大概率都是一拍即合的。

這個想法本身沒有錯，如果說我們有充分的時間精力，或者說我們確實做出了一個通用化的工具，且通用的價值也足夠大的話，是可以去做這個事情，但是現實往往很復雜。有可能他的主項目處于人力緊缺的一個狀態，有可能他們的業務正在生死邊緣，都快做不下去了，有可能主業務那邊還在拼命招人，卻招不夠，找不到合適的人才。但是，這邊卻又拎著一支技術隊伍去做以通用化為目的的技術工具。那么最后的結果是什么呢？那就是浪費了更多的人力和時間。 

那這件事能不能夠成功呢？

首先他還不一定能夠成功，對吧？即便他能夠成功，它也僅僅只是給別的團隊提供了一個不一定很適用的工具。別的產品團隊拿過去用，可能還會抱怨說這個工具不太好用。自己還得持續投入人力去不斷完善。因為每個團隊有自己軟件架構的一些特色特點，用法特征，你做成通用化的，別人拿去不一定是最好用的，原本只做給自己用，完全以自己的使用方法習慣和團隊的成員的特色去結合，是很好用的。但是他把它通用化之后，有可能自己也不一定好用了，別人也不一定是最適用的，雖然它可能有一定用途。即便最終有人用了，那旁的團隊能給到他什么呢？能支持他的業務成功么？顯然不太可能。

所以，我們要思考一下，我們在一家大公司里，做這樣的一些小的基礎工具產生的價值，和我們做出一個真正意義成功的產品的價值的對比，差異有多大？完全不在一個量級吧，一款產品的大成功是決定性的價值，而一個或者好多個通用的小工具，其價值能與之相提并論么？

還有一個誤區就是來自于規范化，為什么規范化也會形成干擾呢？規范化不是好事么？如果一個事情是很容易能看出來問題的，就不會叫做誤區了。我們都能明白，日常生活中，最可怕的人就是面像和善的斯文敗類了，對吧？因為你被表象迷惑了。

繼續舉一個例子：比如某個團隊復盤研發效率低下的問題，復盤的過程，會去追究為什么研發效率低？原因是他們的團隊的同事在這些模塊接口的調用用法之間老是搞錯，或者找不到正確的用法，于是又另起爐灶開新的接口，形成各種垃圾代碼山。或者說把接口用錯，模塊重度耦合，牽一發動全身，等等。這些都會制造很多的時間成本，而且還必然會導致一些質量問題。

所以，面對這種情況，如果技術管理的主導者，自己的技術能力不夠強悍而又厭倦了無休止的討論后，會很容易能夠想到的，不需要太動腦子的方法就是：“我們要增加注釋，把接口的規范統一整理，把架構和目錄統一整理，要讓軟件變得更加易讀，架構更加清晰”。當然，這個內容本身是很正義的，聽起來也貌似很美好。【注：他們大概率沒有能力去想到，員工能力培養的方法問題，技術骨干的甄別技巧問題，以及，其實應該由技術總負責人自己親自設計架構等核心因素。】

一個聽起來很正義的事情要推行下去的話，是容易得到大家的支持的。但是真是去推行的時候就會發現問題了，因為沒有去定義注釋寫到什么程度是合格的，架構清晰到什么程度是合格的，于是就需要有專人來做這樣的規范。

這個時候團隊里面就會開始形成了分工，會有專人來負責這些規范化的事情，而負責規范化事情的同時，他的 KPI 和他的核心職責就是讓規范足夠的極致。這一下就開始完蛋了。

大家可以想象到一定會有過度的規范制定出來。因為既然有專人來干這個事情，就會有人把這種事情當做 KPI 或者 OKR。這種規則，即便嚴苛，但因為一開始這個是所有人都舉手所贊成支持的事情，后面怎么可能自己又跳出來反對呢？所以，反對的聲音都是很渺小的，于是他們的團隊的成員就會形成一種：”我感覺這件事情有點不對，但是我又說不上來哪里不對“ 的感受。

最后的結果是什么？就是會開始形成一些有意或無意的抗爭，或者是執行怠慢。

那么負責執行規范的人就會發現規范大家都很支持，卻很難執行，因為大家有反抗情緒。他們的領導層往往會在事后，收到執行上出現困難的一些聲音之后，開始舉行一個反思會，或者說復盤會，去思考他們這么做是對的嗎？

他們很快會發現這件事情上，單就規則本身來討論，它一定是一個正確的事情，所以他們沒有辦法去把復盤出來“這個事不需要繼續進行”的結論。而且大概率會復盤出另一個結論，就是：“這件事情要繼續做，而且是堅決的做，沒有執行好是因為不夠嚴格，規則還不夠明細，獎懲措施沒有落實到人。做得好的應當獎勵，樹立標桿，執行不好的人要有懲罰！”

接下來，他們就會開始細化如何用更強制的措施讓這個事情能夠執行得更好，怎樣甑別那些干擾的人，不愿意嚴格執行的人。而強制的措施最容易想到不太用動腦子就能想到的解決方法就是打分，打分就可以量化，就不用去個例化分析了，因為個例化分析太難了，團隊的人那么多，情況那么多對吧？

他們急切地希望制定很多的一刀切的規則標準，拿著這些一刀切的規則和標準去要求大家，這樣才不會老是遇到爭議。

根據這些標準來量化大家做的事情，這個時候團隊的失敗就進入到中后期了，因為他們所有的時間和精力就開始圍繞著分數去進行工作了。團隊成員的目標倒是很明確了，把分數做高就對了。但是，這是整個團隊的最終目標么？

監管團隊的人在制定規則，他的 KPI 他的思考變成了思考規則，而做事情的人變成了圍繞分數去進行工作。

本來我們是應該圍繞著產品的成功去工作的，但是，這個產品如何才能成功這件事，是誰在負責？這個時候，已經幾乎沒有人負責了，只有領導大老板自己一個人在負責。但是他又想不明白有什么不對勁？因為他安排下去做的事情都是圍繞著他的目標想要做好而推導出來的事情，最后卻做得一團糟，所有人都在努力，卻都沒有圍繞最終目標去做。

其實背后的原理就來自于一個偷懶的行為：就是他們不想具體案例具體分析了，他們希望制定統一標準之后，大家統一地來套這個標準就好了，不要有誰去挑戰規則。這個才是問題的癥結。

當然，實用主義也不是說我們就不要規則了。因為有些事情它的量級很高，量級很大，如果每一個問題都要具體案例具體分析，大家也累不過來。這種時候，是需要真正的技術領導者來統籌全局的，對問題的洞悉不應該來自于層層傳遞，而是本身的深度理解。

例如大部分軟件足夠龐大后，會碰到多線程帶來的穩定性問題，會引入層層疊疊的規范和規則，以及層層疊疊的架構保護措施。幾乎無窮無盡，最后還是解決不干凈線程問題。而我會要求企業微信的線程數量嚴格控制，io 都是一個線程，網絡也都是一個線程，再加上 UI 主線程，常規情況下只有互不干擾的3個線程。當然，也允許特例，但是非常有限，都需要懂這套規則背后原理的人來審核。幾年下來，企業微信這樣一個幾千萬行的超大型軟件系統，幾乎不會遇到任何線程上的質量問題。這為我們的快速迭代提供了極大的助力。當然，這個只是無數措施中不起眼的一小條而已。最關鍵的是，主負責人，自己理解是否對。

當然，團隊里的核心人物數量有限，當事情的量級達到一定程度的時候，我們一定會迫不得已會用一些自動化的或者說一刀切的規則化的方式去做事情，這些規則化實施的時候，一定要遵循一個原則：就是這個規則面對一些個例的時候，要有一個方法去衡量邊界，越界的，就必須有足夠能力的技術 leader 來獨立分析解決問題。要不然技術 leader 干什么呢？只管人不管技術就不是合格的技術 leader 了。

規則不能貪多，不能一開始就妄圖制定涵蓋一切的規則。規則太多就沒有辦法做到每一條規則都完美化了。當我們定規則定得太快太多，又長時間不更新不回溯，它們就會形成我們前面講的失敗的案例的結果。