第一屆搞管理|志遙 - 如何在小型前端團隊的管理中踩坑

前端早早聊大會目標成為用得上，聽得懂，抄得走的前端大會，計劃 2020 年辦 12 期，第一期 2020 年 1 月 11 日在杭州夢想小鎮舉辦，報名 450 人，到場 230 人，話題聚焦在 「前端轉管理」，來探討大家常遇到的問題：

三五年後我大概率走上管理，之前該做什麼準備呢？
老闆提拔我帶前端小組，我內心慌慌該怎麼應對？
真有 35 歲天花板麼，我要不要堅持走前端這條路？
技術編碼做好多年，現在轉型管理是對的選擇麼？
公司業務發展太快，我怎麼才能帶好 3 人到 50 人？
我老闆懂不懂管理，我想看看別人公司怎麼做的？
...

會議的五位講師工作經驗從 5 到 15 年不等，帶的團隊從 5 到 50 人不等，這些問題他們是如何處理的呢，一路怎麼走來的呢？這 5 場乾貨的分享一定會帶給大家完全不同的觀察視角：

• 5 人團隊 | 竹隱 - 如何從 7 年技術架構走向業務管理
• 10 人團隊 | 志遙 - 如何在小型前端團隊的管理中踩坑
• 20 人團隊 | Scott - 如何在中小前端團隊中完成管理轉型
• 40 人團隊 | 芋頭 - 如何帶領前端架構團隊突破價值困局
• 50 人團隊 | 堂主 - 如何推動與影響中型前端團隊的成長

本文是第二場講師 - 志遙的講稿文字版，來看看他是如何講的，觀看視訊請掃碼文末二維碼，回覆 “早早聊第一期” 即可獲得其他 4 篇文章、錄播視訊及 PPT 地址。

大家下午好，主持人提到的跳舞只是一個愛好，也不是跳的很好。下面開始我的分享。我是來自丁香園丁香醫生業務線的一名前端工程師，今天給大家分享的一個話題叫做如何在小型前端團隊的管理中“踩坑”。

我是 15 年本科畢業的，16 年的 3 月份加入了丁香園，17 年的夏天開始正式去負責丁香醫生的前端團隊。

今天的分享主要是三個部分，第 1 部分是簡單的背景介紹，第 2 部分是從正式加入丁香醫生業務，逐步開始帶團隊到目前的踩坑心得，第 3 部分是做一個總結。

背景介紹

關於丁香醫生

我們先簡單瞭解一下丁香醫生：

• toC 方向。丁香醫生是一個 toC 方向醫療健康相關的業務。
• 線上問診。16 年的夏天丁香醫生開始去嘗試做線上問診。可能有些人線上問診這個詞還是比較陌生的。
• 探索型的業務。線上問診對於整個網際網路醫療行業來說都是一個探索型的業務。在這個行業中，不僅是國內，甚至是整個世界上，都沒有一個成熟度像電商一樣可以去借鑑的商業模型，要靠一點一滴去探索業務的方向。
• 網際網路醫院政策。線上問診業務是背靠國家網際網路醫院的政策。

丁香醫生前端團隊發展歷程

這裡做了一個比較詳細的團隊發展歷程整理，從 16 年開始業務的試水，到 19 年我們業務模型初步清晰的一個過程中團隊的變化。表格中整理了每一個業務階段，一些具有代表性事件，包括我們產品形態的變化，團隊人員的變化，團隊技術棧的變化等。

我把它做了進一步精簡：

• 從 16 年到 17 年是業務試水的探索期，初步通過 Web 平臺驗證了業務是可以進一步去做的，所以公司決定把線上問診業務用 APP 形態去承載。
• 17 年，丁香醫生技術團隊開始快速迭代 APP，這個時候需要更多的同學參與進來，我們的前端團隊也開始快速的擴張。
• 18 年，我們的業務在繼續增長的同時，還有一些新的健康領域相關業務想嘗試，這個時候我們團隊人員會繼續的增加。
• 19 年，我們大概想清楚了一些事情，業務的基本模型已經達到了一個穩定的狀態，此時前端團隊也達到了一個相對穩定成長的狀態。

表格中最核心的是我把整個團隊發展過程中，面臨的一些主要的問題拎了出來。比如，最開始為了快速上線，面臨的程式碼質量問題。程式碼寫的怎麼樣，實際上那個時候對於快點上線這個目標來說，真的不那麼重要。到了 17 年，我們面臨著團隊人員快速的擴張後，團隊規範短缺、人才梯度不足等問題。18 年，我們的一些同學會產生技術焦慮，然後我們還經歷了專案管理、研發效能提升、技術沉澱等問題。

“踩坑”指南

主要是結合一些實際的工作的經歷，分享一下踩過的那些坑。

概述：3 個方面，15 個點

3 個方面：

• 個人轉變
• 團隊建設（人、技術、氛圍）
• 團隊協作

1.個人 - 定位管理

當我們從技術開始走向管理的時候，我們會遇到自己的心魔。我在 17 年夏天的時候，就非常真切地遇到這樣的困惑。最開始團隊由 2 個人變成 3 個人，然後快速地去迭代業務、學習新的技術、把技術應用到業務當中，是一種可以讓人非常愉悅的狀態，甚至可以說有點享受。因為通過個人的努力，可以又快又好地去把業務需求交付掉，與此同時還學到了新的技術。

但是，當團隊從 3 個人到 7 個人，開始正式的去帶團隊，整個業務部門也在快速地發展的時候，leader 每天的工作當中，會有各種各樣的瑣事來找你。可能你剛要去做事情 A，然後事情 B 馬上就來打斷你，接著事情 C 需要你去響應一下。

最開始的時候，我的心態是怎樣的呢？面臨這樣的問題，我也會有一些焦慮。團隊夥伴都很努力地學技術、寫業務。之前我也在很努力地學技術、寫業務，變化是我開始每天被很多事情來打斷。我該怎麼辦呢？

解決方案 1 - 越挫越勇：

我選擇第 1 個方案是越挫越勇。不甘心在被經常打斷的情況下，個人的業務需求輸出減少。這個方案可能出現的情況是什麼？每天大家都已經下班了，我一個人開始去做那部分我想做的業務、我感興趣的東西。但實際上跑了一段時間之後，發現這個方案是不行的。因為無論個人的還是團隊的交付能力（交付的質量和效率）都沒有明顯的一個提升，甚至出現了變糟糕的趨勢。

解決方案 2 - 被動分配任務，跟蹤任務進度：

因為自己有了管理的職責，可以更加“正大光明”地去分配任務：把一些業務需求讓團隊的同學一起去做。分配了任務之後，還需要去關注任務的進度，這是專案管理當中很基本的一個點。採用這個方案後，情況會稍微好一點，但還是會有問題。因為雖然任務是從我這裡分配出去，但是團隊處在一個從 3 人到 7 人的過程中。一個新人到了一個團隊的時候，前期會戴一個“面具”。他可能跟其他人去交流的時候，不太能做到完全的敞開心扉。每一個新人的技術能力也是有差距的，這種差距可以細節到每個人的程式碼風格都不一樣。這個時候即使把任務分配出去了，每天花一些精力去關注進度，可能沒有達到很好的效果。

這個時候就給我的一個觸動是什麼呢?

觸動/轉變：球隊的教練不一定是團隊當中技術最好，衝在最前面的。在開始正式帶團隊之前，我屬於那種衝鋒陷陣型的選手，跑在最前面、努力拿個好的績效，大概就這樣的一個節奏。但是實際上當開始有了管理職責之後，這個方式就不靈了，需要我做一個定位上的轉變。

解決方案 3：主動認領任務+整體協調、建立團隊規範、定期 Review 問題、加強技術基建、虛擬小組等**

經過 17 年、18 年、19 年做了一些嘗試後，現在能以相對能舒服的狀態去和團隊一起做事情。會讓大家主動的去認領自己想做的事情，在大家認領之後，可能會進行一個微調。如果大家已經可以很好地協調好，就不需要再去做後面的調整，只需要去 Review 一下分工是否合理。建立了完善的各方面的團隊規範，比如，剛剛提到的程式碼風格不一致問題，我們就建立了詳細的程式碼規範，並且在具體的前端專案中使用一些輔助性的工具。大家彼此的交流還是沒有那麼的坦誠，我們就去一點點的推進 Code Review。19 年，業務初步地清晰之後，我們在團隊內部成立了虛擬小組，由不同的虛擬小組來負責不同的業務。

通過這樣的方式，我就逐步地坦然面對最開始的心魔。所以，我分享的第 1 個坑是，我們一直習慣於去扮演業務高手。出現了各種各樣的問題，首先告訴團隊的人你們不要動、讓我來。這對於管理來說，不是一個很好的事情，需要去規避。

總結一句話：要成就他人，就要發揮團隊力量。這是我關於個人定位上的一個變化。

2.個人 - 情緒管理

第 2 個變化是關於個人情緒的管理。

前面提到了丁香醫生的線上問診是一個探索型的業務，探索意味著什麼？意味著會出現方向迷茫。業務方向不清楚，體現在產品需求層面就是產品的需求，這個月是一個方向，下個月又是一個方向。這樣的情況就讓我產生了一些急躁、焦慮的情緒。

產生負面情緒的例子還有：覺得團隊成員成長速度慢、身邊合作的人不專業、團隊骨幹成員流失等，實際上這些我們工作當中可能會出現各種各樣的負面情緒。

當我踩到第 2 個坑時，我當時甚至都沒有意識到。大概 17 年年底左右，我把各種原因導致的負面情緒在工作中表現出來了。這不僅會影響到個人的工作狀態和工作協作，負面情緒還會傳遞給團隊。

所以說，當我們去開始帶領一個團隊的時候，一定要把自己的情緒管理好。或急躁，或焦慮，或擔心，這些事情我們要儘可能去收斂，不要去把這樣的問題輕易地表現給團隊的成員。因為這些都會給他們帶來一些負面的影響。

在整個轉變的過程中，有兩個事情給我的觸動還是蠻大的。第 1 個是一部電影，這個電影大家有知道的嗎？

這是《功夫熊貓》中的一幕。當熊貓遇到了敵人、要去打仗，卻內心膽怯、焦慮，覺得自己不行時，他師傅在教導他。這裡面有個關鍵詞叫Inner peace，內心的平靜。

功夫熊貓聽到了這句話之後，他的表現是怎樣的，還記得嗎？用頭不停的撞牆，思考什麼叫 Inner peace。

我 17 年的時候大概也經歷過這樣的狀態，只不過我的 Leader 跟我說不是 Inner peace，而是心如止水（第 2 件給我觸動的事情）。心如止水怎麼做到？不同的人可能有不同的方式，但是作為一個管理者，無論如何都要一點一點地去朝著這樣的方向走。哪怕當時做不到，我們也要有這樣的意識，去一點點往那邊走。經過 18 年、19 年的磨練，到現在我覺得在「心如止水」這件事情上做的會稍微好一點了。

當功夫熊貓做到 Inner peace 的時候，他最終成功的把對手打敗了。這就是我第 2 個分享的點，遇事的時候要保持良好的心態，對心如止水。

3.個人 - 資訊管理

第 3 個點是關於資訊的管理。實際上這件事情我發現在很多人的工作當中，是容易被忽略掉的。不僅僅是有管理許可權的人，技術線的軟體工程師也有這個問題。他不重視工作當中的一些資訊，只關注自己眼中的那一畝三分地。對於 Leader 來說，他獲取資訊的渠道會比專注於做技術研發的人會多一些，但是他可能做不到把有價值的資訊及時傳遞給團隊成員。比如：業務方向調整了，Leader 可能知道原因，但團隊成員不清楚。此時團隊成員的視角是什麼？是需求又變了，我上週辛辛苦苦做了一個需求，這周就把方向變了，我努力的結果輕易就被否定了，此時團隊夥伴可能會產生對產品或者其他的合作方的不信任感。

還有什麼事例呢？比如：團隊遇到了一個技術難題，怎麼辦？Leader 說兄弟們上，把個問題解決掉。花了一週時間問題終於解決掉了，團隊成員很有成就感。但是問題在於，其他的兄弟部門早已經解決過這個難題了，或者說業界已經有更好的解決方案了，身為 Leader 卻沒有去找這些有價值的資訊，也沒有去把這樣的資訊傳遞給團隊的人。

這是我認為的第 3 個坑。避坑的總結是，要重視資訊的價值。首先，我們要能從觀念上要重視這件事情，然後我們要想盡辦法儘可能的多去獲取資訊，因為有的時候資訊不會主動找上門來。然後，我們要起到連線和過濾的作用。不是說我們收到了什麼資訊，轉身就毫無保留的告訴給團隊，有時候這樣是不合適的，我們只需要把其中一部分，對團隊成員更有幫助的資訊告訴他們即可。

4.個人 - 專案管理

第 4 個踩坑的點是專案管理。這個表格是從前面最詳細的團隊發展歷程表格當中提取出來的，業務階段和團隊人數這兩列沒有變，只是最後面一列變為了「發版週期」。

最開始時，業務試水階段，產品形態只需要 H5，要求儘快上線、快速迭代。此時隨做隨發的節奏便於驗證一個新的業務方向。

當確定了新的業務方向是 OK 後，業務開始需要 APP 去承載。最開始 APP 團隊的迭代習慣是根據需求量去排期。比如說這麼多需求，需要一個月之後發一個版本，最早的時候這種節奏也是能被業務方接受的。但是業務逐漸地發展，就會變成業務方不滿足，他們需要快，所以發版節奏就變成兩週。APP 調整成兩週後，已經比之前變快了，但是前端還在隨做隨發，因為業務方說你們這發版成本低。雖然多次嘗試去和業務方解釋，我們的發版成本也沒像是說一句話那麼簡單，但是他們可能還是要你更快。

到了 18 年，我們不僅要去探索原有的業務增長，還要去開闢新的業務。這個時候是最痛苦的一個過程，原本是兩週發一個版本，業務方說要快，我們嘗試做到一週一發，但是業務方還不滿意。怎麼辦？最快的時候，我們甚至做過一天之內發幾個小程式的版本。這種節奏，我們已經明確感覺到技術團隊不舒服了。所以，還要繼續去尋找解決方案。我們會嘗試去跟業務方、產品協調，能不能把這個節奏調慢一點，比如調成一週一個版本。調成一週一個版本之後，技術團隊果然稍微舒服了一些。一旦舒服了一些，就會想著更舒服，就開始嘗試能不能發版週期調整為1.5周、2周，結果業務方又不滿意不舒服了。

經歷了這樣一個不斷磨合調整，尋找適合團隊的專案管理方案的階段後，19 年整年技術產品團隊配合的還是會相對舒服一些。每週我們能保持一個主版本（包括 APP）的發版。19 年下半年，我們可以達到在主版本之外，如果有額外的必要的需求，也是可以支援再去發一個版本的。

這是關於專案管理的一個坑。最開始帶團隊的時候，我的主要精力，或者說我的主要視角，都在如何做好需求，如何讓團隊的產能更大。但實際上隨著業務的發展，越來越多地去貼近業務，我們就發現專案管理也是每一個有管理許可權的人，他需要去掌握的一個技能。

我們生活當中也有很多專案管理的例子，比如說這次「前端早早聊」活動的舉辦，它也涉及到了專案管理。

現在回頭看，在 18 年，就是在最痛苦的那個時期，我發現自己有個誤區：把很多事情都歸結到了人的身上。比如：團隊出了一個bug，那是團隊同學這個人的問題；需求變了，或者說業務方沒有把需求想清楚，是產品經理這個人不行。甚至說團隊出了一些問題時，我覺得是我這個人不行，做管理不行。

但是現在我更會這樣去想：正是因為各種各樣的人存在各種各樣的不足，我們才需要去制定制度、應用管理手段，更科學的方式在整個團隊的團隊協作和專案管理中去發揮作用，而不是要把很多問題的點全部歸結到人的上面。比如：前面提到的交付質量問題，我們要去思考，能不能去規範研發同學自測、提測的流程來規避，或者說我們能不能去推進自動化測試來規避問題。在日常工作中，我們要用管理的方式，去推進一些規範，一些制度來去彌補前面我們可能會遇到人的問題。

列了一些對我來說，看過之後很有幫助的學習資料：

• 研發效能提升和敏捷實施 36 計
• 《精益產品開發 原則、方法與實踐》
• 《敏捷革命》
• 《學習敏捷構建高效團隊》

5.個人 - 價值管理

第 5 坑是關於價值管理，我把它籠統地總結為：不去關注技術和業務的結合，不去關注技術的投入產出比。

實際上，我是從 18 年初開始思考這個問題的。那個時候業務部門的老大問我：在過去一年，你對業務的貢獻是什麼？

我們可以從技術視角回答，我做了很多業務需求，並且這些需求也帶來了業務價值，同時自己所支援的業務需求具有一定的社會意義，這可以是我們的一個答案。大家有自己的答案嗎？

這個問題讓當時的我產生了一系列的思考。我會開始去思考技術的價值在哪裡？因為我是用技術的人，所以我還會思考我（技術人）的價值在哪裡？技術的價值和業務價值，它們的關係又是怎麼樣的？最開始的一個問題，觸動我去做這些進一步的思考。

還有一個關於價值的例子：產品經理急衝衝地過來說，我這有一個緊急需求，能不能支援一下？實際上在過去的工作中我被問到了這個問題好多次。我發現每當我反問“你這個需求為什麼緊急？它給業務帶來怎樣的價值？”這種問題的時候，產品就容易先跑回去做進一步的思考。所以說，這也是關於價值管理的一個延伸。總體來說，我們工作中要去思考需求的價值。所以，這個地方的一個避坑建議是，我們要儘可能去想清楚這樣的一些價值問題。

技術的價值定位在哪裡

關於技術價值的定位，19 年下半年開始，我自己得出了一些答案。在此會嘗試著分享一下：

• 公司/集團為「使用者價值」負責：我們公司或者任何一家公司，最關注的是使用者價值。我們做各種各樣的服務、各種各樣的產品，最終都是去為使用者價值服務，從使用者那裡產生價值。
• 事業部/事業群為「業務價值」負責：我們需要用實際的業務去承載使用者價值業務價值通常怎樣是由公司的各個事業部、各個級各個業務部門去承擔的。
• 市場/運營/產品等為「業務創新」負責：對於我們技術來講，我們要為全部的業務價值負責嗎？不是的。在業務價值之下，距離最近的有一個業務創新層。業務創新主要是由市場團隊、運營團隊、產品團隊等來負責的。業務創新是指我們為什麼要去做這樣的需求、這樣的需求解決使用者怎樣的問題、可以通過哪些方式更好的創造業務價值。
• 技術/產品為「持續交付」負責：在業務創新價值層之下，才是技術團隊、技術人需要去重點關注的價值，叫做持續交付層。這是我們技術人要去負責買單的事情。

技術持續交付價值分層

前面提到：技術的價值在於持續交付。持續交付，是一個很大的話題。我把它去做了進一步的分層。

• 基本價值：技術最基本的價值是交付。就是把需求做掉，能上線就好了。會使用交付需求需要的技術，這是對於技術人最基本的價值。
• 技術增值：在實現了技術的基礎價值後，我們會去追求能優質高效地把需求交付，這個時候我們關注點會變成質量和效率。這個時候，不僅僅要求技術人會使用技術，而是開始要求能用好技術、更深入的掌握技術，能夠用一些輔助的系統、工具或者用技術去創造一些工具出來，利用這些系統、工具來不斷提升交付質量和效率。這一層我會把它定義為技術的增值。
• 軟體資產：在技術增值基礎上，我們會進一步的去追求能持續順暢的交付。這一層會開始關注專案管理，關注我們的交付流程。對於技術同學，會要求系統性的去思考、要求技術人的工程化能力。此時單點的軟體系統、工具已經無法滿足價值訴求了，而是要求技術進行體系化的建設，去沉澱優質的軟體資產。技術團隊能夠給公司不斷的沉澱優質軟體資產，已經是一件不容易的事情了。在這個價值層之上，還會有進一步的技術價值嗎？
• 技術附加值：最高的技術價值層，我把它定義為技術附加值。此時技術人開始能關注、把握有效的使用者價值。日常工作中，並不是技術人交付每一個需求都是有效的。所以說我們要有能力去關注到真正有效的價值，要做到這一點，其實是對技術提出了更高的要求：理解業務、驅動業務，這需要我們技術人可以跨越技術的邊界。

6.個人 - 思維管理

第 6 個點是思維管理，說的是要求團隊 leader 能夠系統性、全域性性地去思考。可以在工作當中經常問問自己，我的老闆他在想什麼，或者說公司做了一個決策，其背後到底為什麼去做了這樣的決策？

7.個人 - 健康管理

第7點是關於我們的個人健康管理。實際上這是一個工作中非常容易被大家忽略掉的點。我們技術人總是關注技術的成長，忽略了健康。

如果大家三年前見到我，那你會見到一個 180 斤的胖子，胖使我有了種種的健康的問題，通過對個人健康的重視，現在減肥到 135 斤了，每年體檢各項指標也是健康的。還有比如說生病的時候疼到深夜無法入睡，那個時候真的會覺得：我還沒有看過 Node.js 原始碼這件事已經沒那麼重要了。但是人的慾望是一個有趣的事情，當我生病好了以後，就會開始考慮：Node.js 原始碼還沒學習過，找個時間得盤它。此外，生活工作中我們可以見到的健康問題還是很多的，無論如何我們都需要重視個人的健康。身體不健康、生命不存在了，談其他的事情就沒有什麼意義了。

上面 7 條是關於個人轉變的一些坑，後面的 8 條是關於團隊的一些坑。談到團隊，最開始的直面的話題就是人。

8.團隊建設 - 人才招聘

我的 2019 Q4 OKR 中有這樣一個 KR：招聘一名資深及以上級別的前端工程師。KR 的背景是 2019 年一直在做這個事情，但始終沒有成功。是因為不努力嗎？似乎也不是。招聘系統上的記錄，可以看到關於招聘是做了不少事情的，但始終就是沒有成功。

到了 Q4 的時候我就開始了不斷的思考，逼著自己去想問題到底出在哪裡？然後去思考解決方案，更多的思考以及行動這裡地方就不展開說，在 一個前端招聘者的內心獨白 和 杭州丁香園丁香醫生招聘資深前端工程師 中有詳細的記錄。幸運的是，最終結果是我們招到了適合我們團隊的人。

所以關於招聘的這個坑，我把它概述為：關於招聘思考的不透徹。如何避坑我把它總結成了三個點：

1. （招聘前）想的明：業務現狀、團隊人才現狀、崗位現狀、招聘標準 (JD) 、招聘的優先順序 、需要HR資源情況。
2. （面試中）面的準：能力因素(能不能做) 、動力因素(願不願意做) 、人格因素(合不合適做)。
3. （面試後）決策穩：匹配專業能力 、匹配價值觀 、匹配個人意願。

在適合團隊的人招進來之後，接下來要做的一件事情就是人才的培養了。

9.團隊建設 - 人才培養

第 9 點的坑，也是一個思維上的轉變，就是我們要對團隊的成員發展去負責。

10.團隊建設 - 人才培養 - 目標管理

在人才培養這一點，有一件很重要的事情是目標管理。在團隊目標管理上，我曾經犯過的一些失誤，比如給團隊定了遠超出團隊能力範圍的一些目標，會導致團隊會很疲憊；比如團隊目標分散，在一個季度我們想做成三個方向的事情，人的精力是有限的，目標分散導致精力分散，最終就會導致目標達成效果不好；再比如，Q1 我們目標是想做 A 事情，Q2 目標完全 180 度轉彎，要做與 A 毫不相干的 B 事情。

關於目標管理的避坑方式，我個人的解決方案是要去系統性的去學習目標管理。給我最大的感觸是 OKR 學習與應用。同樣的這裡提供了一個學習參考資料。

11.團隊建設 - 人才培養 - 績效溝通

關於人才培養的，另外一件很重要的事情是績效溝通，或者概述總結為「溝通」。

「To Cure Sometimes, To Relieve Often, To Comfort Always.」是在醫學界廣為熟知的一句話，翻譯成中文是：有時去治癒，時常去幫助，總是去安慰。

生活中我們接觸到的大多數人看上去都很健康，但是一個客觀事實是世界上 80% 的疾病是不能被治癒的。醫生做的更多事情是提供幫助，他在醫院、在診所給你提供幫助，比如告知我們該去做怎樣的檢查、根據他的經驗給到我們治療方案、去給患者做手術，這些都是實際行為的幫助。但是幫助實際上也是有限的，對吧？醫生做的最多的一件事情是去安慰你，有的時候我們去醫院拍一些片子，最終結果是怎樣？醫生說沒什麼事你回去多休息多喝水就好了，此時他在安慰你，不僅是提供了實際行為上的幫助，更多的通過他的話是讓我們對自己的健康放心，給了我們心靈上一顆“安心丸”。

其實，在我們團隊做績效溝通的時候，甚至說在平常去跟別的團隊同學相處的時候，我們也要去像醫生這樣做。為什麼？提到治癒的時候，通常是某一個結構性的一個質變，意味著要去改變一個同學，比如改變他的一個做事情的方式或者一個認知，這是很難的事情，我們很難去“治癒”一個人。作為 Leader，我們更能做的事情是給團隊夥伴提供幫助，然後總是去安慰。團隊成員每天的工作當中，他們也有各種各樣的情緒，這些是需要我們去做安慰的。

12.團隊建設 - 人才離開

踩坑的第 12 點是人才的離開。在今天來活動現場的路上，我跟車上的一個小夥伴在交流，實際上我們都會遇到這樣的問題。團隊總會有人離開的時候，核心骨幹的離職會難過；讓不太適合團隊的人離開可能會不忍心，他也不是不努力，挺努力的，但是結果可能就跟你的標準差了一些。

這個地方的建議是面對人才離開要果斷。我現在會這樣跟自己說，大家分開是因為彼此的不合適，分開之後實際上是為了彼此更好。

13.團隊建設 - 技術沉澱

第 13 點是關於團隊建設的技術沉澱。

從 16 年開始，團隊從兩個人到現在的這樣一個穩定的狀態，我們實際上是做了很多的關於技術沉澱的探索，尤其是在 19 年業務比較穩定之後，我們會更有精力來做這樣的事情。最終的效果是，如果我們踏踏實實認認真真的去做了技術沉澱，它真的會去反哺到業務的優質高效交付上，同時團隊夥伴也獲得了技術的成長。
**

這裡展示了一些丁香醫生前端團隊的技術沉澱：

• 小程式研發體系
• 持續整合服務
• 小程式元件庫

14.團的建設 - 團隊氛圍

第14點關於團隊建設的坑就是不重視團隊的氛圍。這裡我把它定義成了坑，因為我見到過一些氛圍比較差的團隊。但是不謙虛的說，自認為在這一點上做的還可以。

在這裡想和大家分享一下丁香醫生前端團隊文化的關鍵詞：快樂、優質、高效、成長和自由。我把快樂放在第1位，因為我認為一個人如果在工作當中快不快樂、在這個團隊當中快不快樂，這是最核心的問題。這個時候都不要去談工作，我們先把這樣的問題解決掉，要能保持心情愉悅地去面對工作。然後，我們會關注我們團隊交付的質量和效率。在能做好交付的同時，我們要去追求每一個技術同學的成長，希望今天的事情會比昨天的事情是有進步的。最後我會認為自由對技術團隊的同學來說是很重要的一件事情。

15.團隊協作

關於整個踩坑分享的最後一個部分就是團隊協作。這是今年某個 Q 我做的一個 OKR，其中一個 KR：在 APP 熱更新機制上，使用 A 系統替換 B 系統。這是一個前端團隊負責人確定的一個關鍵結果。這個 KR 會有怎樣的問題？我沒有去跟移動端的同學提前溝通好。因為這件事是要跟他們配合的，沒有提前做好充分溝通的結果就是 KR 的延期落地，因為移動端團隊也有他們的目標。當我們想推進一個技術升級，移動端團隊、服務端團隊也有他們自己的一些考量，所以說關於團隊協作方面，最核心的還是要去共贏，不僅我好，你也要好。

總結

小型技術團隊管理指南

以上是關於整個踩坑指南部分的分享，我把它做了一個總結，一共 15 條：

實際上我還是想把它進一步的精簡了一下。去總結出影響我這幾年做團隊管理的一些核心理念。

支撐我做團隊管理的核心理念

• 健康、快樂是最重要的事情。第一個核心點就是健康快樂是最重要的，剛剛前面由於時間關係，我沒有展開說，這真的非常重要，每一個人都要重視自己的健康和快樂。
• 關注價值與價值流動。第二點是前面提到技術價值定位和價值分層，我們要去關注價值，關注價值的流動，這件事情無論是在團隊內部、在團隊協作上，在自己個人的成長上都是很重要的一件事情。
• 互相成就 / 共贏。我很喜歡的一個詞叫做互相成就，不僅是說作為一個團隊負責人要去成就團隊的成員，我跟我的 Leader 也是一個互相成就的過程，甚至說一個團隊跟公司的關係也是互相成就的。
• 明者因時而變, 知者隨事而制。

明者因時而變, 知者隨事而制

我們去做管理，不是單純的去看管理方法，當今這個時代也不是說缺什麼樣的管理方法，而是當我們遇到問題了想清楚是什麼樣的問題，我們可以採取怎樣的方案去解決掉問題。比如今天做分享的嘉賓會提供很多管理方法、管理理論，當把這些理論方法拿到其他團隊去應用、放在實際的問題場景下去看，它可能也不是最合適的。這個時候需要直接面對問題的人，要能去定義問題，找到解決路徑，然後帶著團隊走過去。

告誡自己的三句話

當我的職業發展走到了當下一個節點後，我會去反思，會想給自己一些提醒：

• 個人技術深度要深耕（根本）。告誡自己，個人的技術還是要去深耕，這是我們技術同學安身立命的根本，我還不想死的那麼快。
• 不要急（風物長宜放眼量)。深耕歸深耕，努力歸努力，在這樣的過程中告訴自己不要急，風物長宜放眼量。比如我們會有自己的榜樣、有個人目標，還是要儘可能保持自己心情愉快的去朝著既定的方向去努力，不要急躁，也不要擔心。
• 健康、快樂才是最重要的。再一次的告誡我自己，這件事情真的很重要。

關於「個人技術深耕」想做一個展開：光說不練假把式，告誡自己要深耕也不能說只嘴上說說，要落地到實際的事情上。基於這樣的思路，19 年我用 TypeScript 做了一個小程式的 Sentry SDK：sentry-miniapp，遵守官方統一的 API 設計文件，使用方式和官方保持一致。感興趣或者有需要的夥伴可以瞭解一下。

最後跟大家分享的是這樣的一張圖片，這是在公司我們部門內部在一個大螢幕上每天都會看到的，它是一箇中國的地圖，每一個點代表的是國內每個省份有多少使用者在使用我們的線上問診等健康服務。每次看到這個大螢幕，我都會去覺得：我們做了這樣的健康服務，它真真切切地能去幫助到一些使用者，是一件有情義的事情。

回過頭，今天是關於管理的一個話題。如果我用一句話來去總結我們的管理是怎樣的一件事情，我想用這句話：聚一群有情有義的人，做一件有情有義的事。

以上分享，謝謝大家觀看。

近兩年 Scott 觀察到前端行業已經完全進入競爭的深水區，各大小公司的前端 TL 剛剛上任，初帶團隊，針對前端工程師這個群體，應該怎麼管人理事，搭臺拿結果，幫帶有成長，就成立了這個全國的前端技術主管學習交流群，在人的選用育留上互相學習成長，入群的門坎是你有實線或者虛線在帶團隊，請加 Scott 微信: codingdreamer 邀請入群，同時，未來的前端早早聊大會行程動態、資料下載請掃碼下方的公眾號：