技術管理雜談

主動管理

人非機器。

我們可以編寫一段程式，讓機器嚴格按照我們的預期執行，程式寫得好的機器夠牛逼的話，能保它跑個幾十年無需干預。

但是人不行。

人有別於機器在於他的感性以及模糊的理性。

人會懶惰，會自私；也會追求，會奉獻——但這不是無條件的，需要誘因。

人們匯聚到一起，形成了一個截然不同的實體：群眾。管理本質是對群眾的組織——有組織的群眾才叫團隊。

未經組織的群眾如一盤散沙，雖持有滿腔熱情，也不過是曇花一現。

就如流水總是落向地面，人在本能上趨於惰性（可能是出於機體的節能訴求），在處理問題上趨向於」活在當下，避重就輕「。想想自己團隊中有多少問題是重複出現的，大家黑著眼圈在那日復一日地解決同一個問題。

在團體溝通中，人總是傾向於自我為中心，往往從自身的利益和視角看待問題，加之語言這種天生的模糊理性工具，使得團體的溝通效率是總是那麼低下，有時會嚴重阻礙專案進展。想想自己團隊中有多少會議是超過兩小時的。

人天生健忘，團體甚是如此。團體進行的專案除非有專人/組織持續推進，否則總會一籌莫展。團體的熱情總是超不過三分鐘。今天日本首相去祭鬼，我們氣得砸豐田車，明天就忘了；這次會議我們說要對X系統重構，明天便再沒人提起。

管理主要解決團隊的效率問題：當前的效率和未來的效率。

技術管理真正的挑戰在於，雖然」人非機器「是管理的因，但管理的果卻不是把人變成機器（流水線生產）。在技術管理領域，機器化管理或許能提升當前的效能，卻不利於未來的產出。

KPI

我們要不要做 KPI 考核？

之所以問這個問題的原因在於軟體技術管理的 KPI 考核很難做。

就目前而言，軟體仍然是個「非標準化」產品——它的每次產出都是創造而非複製，無法像螺絲釘那樣通過標準化的生產和檢測機制來衡量效益。

進一步說，軟體的效益是置後的。軟體剛上線的時候並不能體現其價值，其價值是在使用過程中逐漸兌現的。

所以我們無法簡單地通過當期產品的產出速度來衡量效益：有可能這個所謂的「高效」是用犧牲未來的穩定性和可延伸性換來的，就像一些公司的「繁榮」是建立在鉅額債務上的。

一些公司採用程式碼行數、千行 bug 率、單元測試覆蓋率、線上 bug 數等資料來作為KPI指標。不是不行，但不理想，容易被形式化，而且很容易被鑽空子。

KPI 考核的目的是什麼？末位淘汰？升職加薪？是，但不全是。

Leader 腦袋裡面不能只有」考核「——這是懶政的表現。

最好是將「考核」二字徹底從你的腦海裡去掉。然後將 KPI 換成 OKR。OKR 關鍵是他這裡強調了個 O，也就是目標——這是關鍵。

很多團隊沒有目標。

「怎麼可能？我們每個月都加班加點做了那麼多需求啊！」

那是任務，不是目標。

任務是公司或上級下達的剛性需求，是對公司業務的支撐要素，完成這些任務是每個團隊的本分——但這是公司的目標，不能算是你這個技術團隊的目標。

比如公司（或事業部）今年一季度的目標是開發一個大客戶，且大客戶開發屬於今年的戰略目標。那具體到你這個技術團隊，一個硬性任務就是為至少一個大客戶完成私有化服務部署和客製化開發——但這隻能算你這個技術團隊的任務（放入KPI中）——作為一個技術團隊，不能將這個作為目標。

技術團隊的目標要從技術角度去制定——這不是說技術團隊的目標就能不顧公司目標而異想天開地定，相反，技術團隊的目標要從技術的角度去支撐公司的目標。

比如公司做大客戶開發在技術上有什麼難題、有什麼提高效能的地方，這是技術團隊需要著重考慮的東西。大客戶需要做私有化部署甚至要使用他們自己的私有云，那我們能否在技術上支援一鍵私有化？大客戶都有很強的客製化化訴求，那我們的基礎平臺能否支援快速客製化化？

這些目標看似跟具體某個月的任務無關，但對於專案的成功以及長久效能提升是關鍵。

從技術的角度支撐公司的業務，提升工作效能，這才是技術團隊存在的價值。

然而，理想很豐滿，現實很骨感。大部分中小型公司，迫於生存壓力，不得不瘋狂地開拓和迭代產品，卻又沒有足夠的資金養活龐大的技術團隊，結果是寥寥的幾個技術人員所有的時間都被剛性任務佔據，除了搬磚，一無是處——但這也不排除另一種情況，即技術團隊自己（團隊 Leader）把自己定位在搬磚工的角色上了，主動放棄思考。

團隊從 KPI 轉向 OKR 需要勇氣——特別在小型公司人力資源不足的情況下。目標的制定本身就是一項挑戰，需要經過深入的思考，對團隊、系統以及未來業務的綜合考量，還可能涉及到其他團隊的配合，需要說服上級以及其它團隊支援你的工作（對於不善溝通技巧的技術管理者來說是個不小的挑戰），以及承擔不確定性帶來的失敗——相較於這些挑戰，上級說 1 就做 1 的策略明顯舒服得多。

技術性目標的另一個挑戰是其實現過程是探索式的。比如我們的目標是讓服務 X 達到 4 個 9 的可用性，為此我們需要實現自動化部署與自我恢復、負載均衡、熔斷、限流、健康檢測（也就是現在火熱的雲原生裡面的一大籮筐東西）等，這些技術好像都已經有標準化實現方案了，但在實際專案使用中仍然會挫折不斷（而不像生產螺絲釘那樣讓生產十字槽就絕不會生產出一字槽的）。那麼在這種探索過程中，如果你用」考核「的思維來管理團隊，你會發現要麼 KPI 沒法設定，要麼貢獻最大的人卻得了最低分。探索的性質決定了 KPI 本身的主觀性。

主觀的 KPI 會帶來一系列問題，如不公平、缺乏說服力、鑽空子。

不過，主觀不確定性確是人類天生特質。人因理性而別於其它動物，因感性（主觀性）而別於機器。

我們一心想用理性框架去框定團隊的行為，殊不知真正讓團隊保有戰鬥力的卻是感性。真正讓紅軍戰士忘我拼命的是對他們眼前黑暗社會的仇恨和對那個他們自己看不到的光明未來的嚮往。

OKR 的目的在於讓團隊清楚自己的目標（O）以及屆時如何評估該目標是否達成（KR）。

一些管理者掛在嘴邊的一句話是：」我不要看你加班的過程，我只要看結果！「雖然這句話有幾份道理，卻不能作為中層管理者的座右銘——如果一個團隊只有過程卻沒有結果，那要麼是過程和目標南轅北轍了，要麼是遇到重大阻礙卻得不到支援，這是重大的管理事故。

技術管理的主觀性可以通過諸如計分卡的形式作為 KPI 補充，計分卡的設計主要記錄考察成員的主觀能動性方面的表現（需要有事件支撐），作為後面績效評估的一種補充。另外如果做KPI考核，建議時間維度在季度或半年度，而不是每個月或者一年——季度或者半年一般能完成若干個中小型專案，一些大型專案也能達成階段目標，比較容易對成員作出較全面的評估。

如果必須進行 KPI 考核，建議考核粒度只到團隊不到個人，個人層面由團隊Leader自主把握。

技術團隊的 KPI 考核不但很難做，而且討論之多、爭議之廣在傳統行業也是不多見的。每個公司有自己的文化和價值觀（對於中小型公司往往就是老版自己的價值觀），技術團隊做不做 KPI 考核（甚至怎樣做）往往不是技術團隊自己說了算的。就個人觀點來說，KPI 並不能給團隊帶來多大的效率和質量提升。就技術團隊的效能和質量來說，有兩點最為關鍵：1. 整體寬鬆度（自由度）；2. 團隊 Leader 和一兩個骨幹人員的個人魅力。

過於嚴苛和死板的 KPI 往往適得其反，特別是跟當月工資掛鉤的做法最讓技術人員反感，很可能造成人員離職。一些高層管理者（非技術部門）可能覺得這正是他們想要的：通過跟工資掛鉤的做法激勵那些骨幹人員，並淘汰混日子的。實踐中這會導致三個嚴重問題：

1. 這種機制一方面會造成整個團隊緊張壓抑的氛圍，這種氛圍會導致團隊整體效率低下；

2. 一旦直接涉及到工資，無論團隊內成員還是團隊 Leader 都會極力去規避這種風險——對於 Leader 來說，他寧願團隊內無人能拿到額外工資，也不願某些人被剋扣工資。結果就是，每個團隊都在絞盡腦汁鑽空子，要麼 KPI 設定上趨利避害，要麼在工作質量上參入豆腐渣，沒人願意去承擔高難度且不確定性很大的專案——人的本性首先是規避風險，而不是追求額外回報；

3. 處於頭部（獲得額外工資獎勵）的人員畢竟是少數，而且每個月基本都是那固定的一兩個死忠（或工作狂），結果就是這固定的一兩個人覺得很爽，往往會更加賣命，而其他（大部分）人不但不那麼賣命，往往還會站到對立面，造成團隊分裂。

民主還是專制

一個高效團隊的管理者需要進行一定程度的專制。

大家都喜歡談」民主「，反感」專制「——但這不過是語言的把戲，是為了滿足大眾的心理需求。

中國自古至今都是專制政體。今天我們叫」人民民主專制「，這是多數人對少數人的專制——如果沒了這層專制政體，就會立馬變成少數人對多數人的專制。

適當的專制能提高團隊的協同性和生產效率，只談民主沒有專制的團隊幾乎什麼事也做不成（印度式的民主）。

但是反過來，過度的專制會導致團隊僵化，Leader 說一，沒人敢說二，成員的極度無權感會導致其沒有歸屬感——團隊是 Leader 的，不是他們的。

比如團隊要有規章制度，這些規章制度一般是 Leader 起草的。

如果 Leader 自己默默寫了一份規範，丟給團隊說，以後我們就這麼辦；或者丟給團隊去討論，結果討論來討論去，不同的聲音全部被 Leader 一一駁回，最終還是按照 Leader 一心想出來的制度執行，這就屬於過渡專制。這種軍事化管理風格並不適合技術管理這種創造型勞動組織。

經過大家討論認同並定稿後，規範就成了團隊的規範，是必須以專制的態度去執行的。假如規範要求需求上線必須經過幾道測試流程，並經過哪些人審批，結果張三的某個小需求沒有經過必要的測試環節就上線了，這種對規範的破壞必須得到相應懲罰（如通報批評），否則規範就會逐漸被所有人無視，團隊也就進入了碌碌無為的民主態。

架構師也要進行一定程度的專制，否則其架構設計便很難得到實現。不過在很多公司架構師並沒有足夠的權利要求各系統嚴格實現其架構設計（特別是跨團隊時），所以一般只有個性較強勢且執著的架構師才能完成其夙願（或者該架構師善於向上管理，利用上級的權利來行事）。

優秀的Leader能夠較好地把握專制與民主的尺度，即讓團隊保持較高的執行效率，又不扼殺成員的主觀能動性。「人民民主專政」是個偉大的制度創新，是一種在民主和專制之間尋求平衡的政體，在做團隊管理上應多多借鑑。

團隊間也存在民主與專制的問題。我們現在講敏捷，喜歡搞一個個」自管理「的敏捷團隊，但現實中的一個問題是這些團隊過於強調團隊自身的獨立性，不但不服其他團隊管，也不服上級管（往往是這些團隊的上級也不怎麼管他們），這就導致團隊間的溝通共同作業成本過高，過高的溝通成本反過來導致團隊間不願意溝通，所以你往往發現這些團隊間大家都做了許多一樣的基礎功能。

我曾經呆過的一家公司曾組建了一個專門的架構組（或者叫基礎設施組）來解決該問題，但失敗了。問題出在這個架構組成員和其他敏捷團隊之間沒有任何有效交集，他們也沒有什麼權利去管轄其他團隊，這個架構組做出來的架構設計有些團隊遵守了，有些沒有；做出來的基礎設施也鮮有其他團隊用——因為這幫人只是為了做基礎設施而做基礎設施，做出來的東西往往不符合業務需求。

一個更可取的方式是從各團隊抽調一些技術骨幹（或者技術經理，抽調的人要在其團隊內部有相當的話語權）組建一個虛擬的架構師團隊，這些人在技術上代表了公司的核心，在利益上代表了各個業務團隊。這個虛擬團隊需由這些團隊的直接上級領導。這樣一個團隊既擁有相當的權利，也代表了實際業務團隊的利益，他們做出來的架構設計和基礎設施能更符合實際需要。
想想你所在公司的團隊間，是不是在實行希臘城邦式的民主？

虛擬團隊

團隊之間存在溝通壁壘。

如果你參與過跨團隊專案，就會發現團隊之間的溝通協調是件多麼麻煩的事情，特別當幾個團隊不在一個辦公地點時。

往往的情況是，團隊 A 的張三需要和團隊 B 的李四聯調某個功能，但李四卻被調去做別的事情了，無奈，張三這塊得等著李四，而王五又得等著張三。

團隊 A 的張三做了個功能模組，而團隊 B 的李四也做了個差不多的功能模組。

團隊 A 的張三對某數值四捨五入取小數後兩位，而團隊 B 的李四則是取的後四位，最終導致報表出了一分錢的誤差。

......

對於跨多個團隊的大型專案，需要成立專題專案組，從各團隊抽調人員組成臨時的、專案制的虛擬團隊——否則這個專案往往會變成無頭專案，沒有全程跟進的總負責人。

虛擬團隊由專案經理負責（可能不是全職的，比如由技術負責人或產品負責人兼職，但他需要對整個專案負全責）。另外兩個重要的角色是產品經理和架構師（架構師也不一定是全職的，比如可能有某個主模組的主程兼職）——這兩個角色需要對專案的業務和技術正確性負責。

由於虛擬團隊是臨時組建的，裡面一些角色是兼職的，有些人意識不到自己所承擔的角色（比如產品經理承擔專案經理角色卻意識不到自己應及時覆盤專案進度以及潛在的資源設定問題），同樣會導致無頭專案風險。沒有清晰角色定位的團體不叫團隊，團隊組建者（一般是上級領導或上級領導授權的某人）在組建團隊時一定要公開宣告裡面關鍵角色人選以及（更重要的）其職責範圍。

正是因這些全域性性的關鍵角色存在，虛擬團隊才能打破團隊溝通壁壘，使得專案組成員之間達成整體的認知和一致的步調。

虛擬團隊中的成員處於不穩定態：一方面需要關注本專案組的事項，另一方面又要關注原物理團隊的事項，經常會出現工作穿插（在人力資源緊張的小公司尤其如此），這種穿插經常讓人無所適從，使得團隊成員怨聲怨氣。另外由於在歸屬感上虛擬團隊存在先天劣勢，這使得虛擬團隊的管理人員必須更加強勢才能維持這個團隊的團結態。為了使虛擬團隊」實體化「，也為了有意讓成員從原物理團隊隔離開，虛擬團隊經常會閉關到」小黑屋「裡（特別是在專案衝刺階段）——這種隔離使得虛擬團隊成員間的溝通成本降到最低，也使得他們和原團隊間的溝通成本大大提高。

工蜂式的 Leader

有那麼一群技術管理者，他們總是團隊中」最忙「的那位，每天加班到最晚，線上出問題永遠是他們在處理，每個月的任務項也是他們最多——總之，事無鉅細，能他們自己乾的就絕不讓其他人幹。奇怪的是，他們的團隊總給人雜亂無章感，事故頻出，每次績效也並不高。

很多技術管理者並沒有完成身份轉換，所有的時間都花在具體任務執行上而缺乏思考，對團隊缺乏組織，團隊的各項事務也沒有人去跟進，團隊成員遇到了阻礙也沒人去協調，系統的頑固性 bug 也沒人去思考去重構。

他們認為只有敲程式碼才是實在的工作，其他都是虛的。

有兩件事情值得我們去思考：重要而不緊急的事和緊急而不重要的事。團隊 Leader 一定要花很大一部分時間去思考和處理重要而不緊急的事情，而不是整天在那救火。

其他人關注當前的效率，Leader 要更關注未來的效率。

團隊中每個人的特性是什麼，需要將哪些人培養成團隊骨幹和接班人？

當前的系統存在什麼樣的問題，為什麼會存在這些問題，得安排在什麼時間怎麼處理這些問題？

之前的迭代暴露了什麼樣的問題，當前的流程規範是否要做改進，怎麼改進？

就未來公司發展來說，我們團隊需要提前做哪些準備？

上午張三抱怨說團隊 A 的那個李四負責的模組毫無進展，他推不動了，我是不是得去看看？

王五的程式碼水平怎麼樣，是不是要去瞅瞅他寫的專案？

這周帶大夥去哪裡浪？

......

星星之火

技術團隊的靈魂是技術性——技術本身就是點燃團隊熱情的星星之火。

有人談論團隊文化，更多是從」道德「層面（公司層面）去思考某某團隊應該要有什麼文化，比如」客戶為先「、」奮鬥青年「。

文化是自內生髮的，而不是自外加冕的。

諸如」客戶為先「可以作為技術團隊的行事規範，但不能作為技術團隊的文化核心——除非他們是技術支援團隊。強加外部屬性作為其文化核心，會讓團隊成員覺得受到了忽視（甚至是歧視）——想想讓銷售團隊天天喊」我們是一群技術極客「，他們會是什麼反應？

文化一定是來自團體眾人的自有屬性。技術人員的自有屬性就是技術。對技術的熱愛使得他們進入這行（至少起初是這樣），技術性的產出會讓他們獲得至高成就感。

缺乏技術氛圍的技術團隊沒有靈魂。沒有靈魂的團隊很難做出優秀的東西，他們日復一日上演著一出出悲劇。

技術 Leader 的一個職責就是想方設法打造團隊的技術氛圍。

技術分享會應該作為團隊日常事項的一部分。分享會的目的並非是讓大家掌握到什麼高深的東西——一兩個小時能講個啥——而是調動大家的技術熱情，以及開放分享的心態，同時也能作為日常繁忙事務中的一杯調節劑。

分享會可定期或不定期舉行，最好不要限制範圍（有些公司會軟性限制需和公司業務或技術棧相關，這會讓人感覺功利性太強而失去興趣）。

分享會一般在全公司範圍舉行（當然也可以團隊內部進行，因為有些人覺得自己分享的內容平平，不想在大範圍內表現）。

為了鼓勵大家參與，可以有些獎勵機制，如可以為考核或升職加分。

另外 Leader 要對團隊提出較高的技術要求，比如程式碼稽核，對程式碼的質量作出要求；壓力測試、滲透測試等，對系統質量作出要求。

在每個月的任務項中，要安排一定比例的技術性任務（如系統重構、基礎設施建設、頑固 bug 處理），這些任務相較於日常業務型任務具有更大的挑戰，更能鍛鍊人，也更能調起大家的興趣。

有了技術氛圍這個火種，才有可能去追求第二種特質：業務氛圍。

大部分的技術團隊都屬於業務團隊，大部分的開發工作也是在開發業務系統，但並不是每個人都對自己團隊負責的業務非常熟悉。有些人可能常年只負責某個模組，連完整的業務閉環都摸不清楚。

業務型技術團隊對業務的漠不關心是團隊的另一個悲劇。由於對業務缺乏進一步探索的熱情，很多人一直呆在一項業務的某一個環節上，對業務流程只見樹木不見森林，在做系統設計時便無法顧全大局——這種情況在按功能（而非專案）組織的團隊上尤為明顯。比如儲值卡業務，涉及到制卡、儲值、消費、車隊卡、家庭卡等，制卡、儲值和消費還涉及到不同的入口（如手機、POS 機），這些環節可能都是由不同的人維護的，如果他們對儲值卡業務根本不感興趣，便沒有動力去了解整個業務閉環的每一處細節。

對業務漠不關心的原因多方面，比如該業務並不賺錢，屬於公司的邊緣業務；又或者這個業務系統是歷史遺留下來的，不是親兒子，而且 bug 超多；還有可能是大家壓根不知道有多少人在用這套業務系統。

Leader 需要讓大家知道團隊負責的業務的價值，比如某業務上個月賺了多少錢，某 App 這周下載量上升了多少等。人們不會對沒有價值的東西感興趣。

對於歷史遺留系統，團隊應有較明晰的計劃去解決其遺留的頑固問題（當然如果這些問題不影響使用，不給大家的日常生活造成困擾（無休止的bug），則另當別論）。

只有當團隊對業務感興趣了，才有可能追求第三種特質：服務氛圍——只有大家有面向客戶的意識時，」客戶為先「才不會僅是一句空話。

技術氛圍、業務氛圍和服務氛圍是遞進關係，越在前面的越基礎也越重要，技術團隊可以沒有服務氛圍，甚至可以沒有業務氛圍，但唯獨不能沒有技術氛圍。

注意這個順序和公司層面的追求是相反的，公司層面一定是服務（客戶） -> 業務 -> 技術。正是出於這方面原因，很多公司不能理解技術團隊的特質，無視技術團隊的現狀，強行要求技術團隊和公司層面保持一致，在技術團隊中大力推行諸如」客戶為先「，讓技術人員覺得公司壓根就不關心技術團隊的死活。