業務端技術團隊有多痛？

作者｜沈劍

本文整理自 58 同城技術委員會主席沈劍在 QCon 2017 北京站上的演講，原題為：《業務端技術團隊真的痛？》本文將為你詳細分析業務端技術團隊的各種常見痛點。

技術團隊的痛處

團隊是指一種為了實現某一目標而由相互協作的個體所組成的正式群體。是由員工和管理層組成的一個共同體，它合理利用每一個成員的知識和技能協同工作，解決問題，達到共同的目標。團隊建設是企業在管理中有計劃、有目的地組織團隊，並對其團隊成員進行訓練、總結、提高的活動。

在本次演講中，我將講述的主題是業務端技術團隊所存在的痛處，我將介紹其業務團隊在帶隊過程中可能遇到的一系列問題，之後結合自身經驗與大家分享。問題如下：1、和 PM 為何不能愉快的玩耍？2、和 QA 為何不能愉快的玩耍？3、壓力大、項目做不完、永遠加班做業務怎麼辦？4、Bug 多、質量低、永遠加班該 bug 怎麼辦？5、人員流動率高，真的是因為沒有技術含量嗎？

1、PM 相處篇

1 目標一致

與產品經理相處存在的最普遍問題在於目標不一致，最典型的例子是 KPI 的制定、產品團隊 KPI 指標的考核。產品團隊、運維團隊等 PM 的績效指標在於 PV 的增長量、UV 的增長量。公司業務團隊 KPI 如何考核？技術團隊的 KPI 一般標準如何確定？技術團隊負責質量，產品團隊負責業務指標，假設當時產品團隊提出一個功能需求，完成此功能可提升其 PV 和訂單量，技術團隊對其進行評估發現，由於其高複雜性會對已有信息造成大的衝擊，並且這一更改會導致系統的不穩定性，或者說需要較長的時間更改它。那麼怎麼辦，為何會出現這種情況？

其主要原因在於目標不一致。如何協調兩者之間的關係？舉個例子，產品經理和技術經理在討論問題，產品經理覺得技術經理的團隊技術並不支持他們的產品，導致他們不能達到目標；而技術經理卻認為，如果他們的技術支持了產品會導致他們自己的目標達不到。為了防止此類現象的經常性發生，他們應該在業務開展開始前便達成一致目標，因為這是一個自上而下的過程。一個團隊組織架構是業務團隊的閉環，內部有產品技術部、測試部。而有些團隊組織架構內部包含的是產品部、技術部、質量部，若其以業務單元為組織架構可能不會存在目標不一致的問題，但若其以職能為組織架構卻可能發生該類問題。

但是，即使是這樣的組織架構，在目標上仍然需保持一致，在創業階段更需要保持業務優先原則。因此，一定要確保產品團隊與技術團隊達成目標一致性。一損俱損，一榮俱榮。對於目標不一致的解決方案，以業務指標為第一目標，然後統一目標，統一 KPI。為達成一致目標需要 PM 負責人以及業務團隊達成共同意識，否則各自完成各自目標，結果終究是對立的，他們不僅需要實現業務，還需要對系統的穩定性和質量負責。

初期的快速迭代可能因此不會考慮太多設計層面的問題，或者說初期的架構設計適應了當期數據量、並發量和業務迭代速度。但隨著時間的推移，業務發生變化，並發量、數據量持續上漲，系統架構不再能夠支撐，而這時便需要技術團隊進行技術改進的項目，儘管這可能與業務功能實現無關。

舉個例子，APP 重構，58 到家有多家 APP 商家、用戶端以及司機端等，一開始為了追求速度，招聘 3-5 人形成一個團隊進行開發，後來發現我們可以進行分層抽象和沉澱公共組件，以此提高開發效率。數據層也是同理，後端做服務端，web 端訪問資料庫，加入緩存，使得架構結構更加合理。我們最初採用 AM 線和 CM 線各自賬號體系的登入方式，後來業務方向發生變化，因此開始改做平台方向，但我們存在跨業務線登錄的需求，即 SSO 的需求，統一進行技術優化的項目。

然而當我們拿著技術改進項目與產品團隊溝通時，溝通結束之後雙方都可以達到自己的期望與預期嗎？舉個例子，技術同學花費兩個星期時間進行技術優化，產品同學卻說這個月我有非常重要的運營項目，我需要運營 PV 和 UV 來完成自己的業務指標，由此得出，產品同學並不理解技術改進、技術優化。那麼如何達成一致性？第一為達成一致目標，為指標負責。作為一名技術人，都想要達到 PV 高、技術好、流量漲的目標。如果產品經理與我的總目標一致，那麼當我說服產品同學為我做這些事情時會更簡單，因為總目標一樣，產品同學理解起來會更加容易。

2 數據說話、以理服人

目標一致、數據說話、以理服人。該採納的建議是什麼？

第一，我們可以與 PM 同學解釋，我們技術改進項目與其總體目標是一致的。而我們需要做一個 APP 的重構或者重組的組件化，需要產品同學降低其安裝包大小的百分比，進行完美配合之後，其用戶體驗性會更好、下載速度更快、使用流量更少，並且可以預期完成項目優化，據經驗也可提高 10% 成功率。

第二，緩存優化。關於分層架構，產品同學表示原先下一個單需要 800 毫秒，訪問資料庫效率緩慢。但是在完成此項目之後不需要訪問資料庫，下單時間變成 300 毫秒，直接提升用戶體驗，並且其用戶轉化率和留存率隨著業界體驗的提升而提升。關於 passport 重構，技術組與產品組各自完成自己的任務。當技術團隊做單步同步時，一旦完成一類項目，需要同時與 passport 項目減少 5 名人員，並且使用產品組所能理解的語言進行溝通，因為大家的目標是一致的，所有人的任務都是為了共同完成 PV、UV、GMV 等目標。我們從實踐中得出經驗，即使現在下單確實很慢，但在進行優化之後，轉化率顯著提高。而在進行技術改進的項目時需要使用數據來與產品經理進行溝通表示雙方一致的目標。

3 項目總結、效果說話、增強信任

每個公司都會產生這樣的狀況，研發資源不夠，需求難以滿足。據我所知，即使將工作人員的數量翻幾倍，該需求仍然不被滿足。那麼這該怎麼辦？技術同學每晚加班，項目多，壓力又大，人員流動性便大。短期加班衝刺、熬夜上線可以接受，可是長期以往如此，所有人都會拒絕。

用效果說話，增強其信任。如何用效果說話增強信任呢？首先產品同學與研發同學的人數比例需要採用經驗得出的數值，比如說我們需要做 B 端後台系統，信息系統 1:15，那麼一個產品需求需要 15 個研發，C 端後台系統 1:5，那麼一個產品需求對應 5 個研發。三個產品運營 + 運營 VS 一個技術，根據經驗數值比例可得人數必定不夠，或者說產品需求過多。

為什麼需求需要那麼多？真的需要完成這麼多需求，這麼多功能，這麼多改版嗎？而且每一個運營、改版真的可以達到我們預期嗎，或者說你進行任務之前做好預期嗎？功能完成對我們的總體目標有幫助嗎？會產生多大的幫助呢？如果需求做不完有沒有和技術同學說明效果評價、效果預期？

每個項目的預期是不一樣的，每個項目對目標達成的比例也是不同的，所需要佔用技術同學的比例也不同。每個人都想投入最少，卻得到最高的 PV。運營項目也是如此，假設該時期正逢雙十一，產品經理應告訴技術人員，採取技能優秀優先原則，需要大量人才來提高其 PV 率。對於技術人員的審核，介於雙方需求的一致性，若其提出的需求對達成目標有所幫助可採納，若不能則拒絕。因此，在我看來，產品同學需要提前做預期，而技術同學需要反向進行預期評估，而不能僅局限於功能實現的資源。

不管產品同學需求多少人，都不能以技術人員人數有限的態度敷衍派人員，因為大家都是朝著目標共同努力。舉個例子，當前共有 10 個項目，PM 同學需要對項目進行收益預期，此時正運行 5 個項目，PV 增長 10%；而對每一個項目技術同學也參與投入預期，投入 4 個技術人員，時長為兩周，若其運營較為簡單，那麼投入一個技術人員，時長為三天。經過這樣的預期計算，可能選擇五個人進行該十個項目，對目標達成的收益最大。

對產品的要求做效果評估，對技術同學反向做效果的詢問和明確，然後根據投入產出比衡量優先順序。功能項目需要收益總結、提升需求總結、建立信任關係等，即使初期的預期收益不精準，但長期如此，其結果會更加準確。但信任關係卻不是，比如某個技術團隊 VS 三個產品團隊，該團隊對接三個產品團隊，每個產品團隊必定說，與其他相比，我優先順序是最高的。在這之前我們需要建立一套機制，用來評估其預期值以及技術投入產出比。

於是，該產品團隊為爭取到資源而不斷努力，並提高其預期值來獲取優先順序，誇下海口說可增長 50% 的 PV，技術同學認為該團隊對我們有益，選取。但在項目結束之後，技術團隊進行項目總結髮現，預期並沒有完全達到，只達到 10%，技術同學便不開心，心想該同學提的需求特別不靠譜。而產品團隊卻認為，我雖然不能提高 50% 的 PV，但我可以提高 15% 的 PV，可項目一總結髮現 15% 也沒有達到，達到 12%，還相差一點。

因此，產品效果預期評估不準確，在未來的合作中，即使產品團隊表示自己團隊優先順序很高，但介於之前合作其不靠譜的需求預期，其信任關係便難以再次形成。若每次提出需求預測較為準確，且每次達成目標，那麼該信任目標也自然而然地被建立了。所謂統一對接人，上游需要技術團隊需求預期，業務、產品團隊也需要技術團隊需求預期，但是技術團隊難以評判。需求團隊對接產品團隊，技術團隊對接產品團隊，技術改進項目可和運營項目、產品項目共同評估優先順序，產品團隊需要做效果預期，技術團隊需要根據投入產出比評估項目優先順序。

2、QA 相處篇

1 目標一致

研發團隊與 QA 團隊的關係是一家人還是對立的？我曾在百度工作過，研發團隊的績效目標質量高，千行 BUG 率低於標準值。關於技術團隊質量的評定，幾個 9，超時即低於標準值。QA 團隊績效目標是將所有有問題的代碼測出來，千行 BUG 測出率高於標準值。因此，這兩個團隊必有其一達不成目標，其結果會產生什麼影響？

測試團隊為了達成 KPI，需要儘可能多的提出 BUG。若 KPI 產生該結果，那麼他們仍有改進的空間。與研發和產品目標不一致的觀點不同，以業務團隊統一目標與業務目標為標準，即共同達成 PM、RD、QA、FE、UI 的目標，且每個團隊仍然有自己的小目標。我們曾收到過一些反饋，包括測試質量低、可測性差、bug 研發搞不定、性能低下。

2 目標一致、任務分工明確、數字說話

如果測試團隊說，技術團隊質量低，那麼技術團隊是不會同意這個說法的，這與技術團隊對產品團隊說他們需求質量低，但產品團隊不接受一個道理，沒有證據不能隨意說出質量水平低此類評語。

開發現階段常存在的現象，提測質量低、可測性差、bug 研發不能解決、性能低下。RD 為質量負責，QA 輔助，這樣的搭配團隊可以達成目標一致嗎？所謂模塊負責人制，即每個模塊或者系統都有第一負責人、第二負責人。然而有些公司可能並不採取模塊負責人形式為項目組，直接安排工作人員完成、測試項目，然後繼續進行下一個項目，所以導致研發同學對代碼的編寫毫無責任心，結束項目便是萬事大吉，並不理會未來發展問題。模塊負責人制，每一個模塊都有一個負責人，而且不樂意他人在自己的模塊亂指揮。

比如 APP 團隊項目按照功能來分塊，A 同學做 A 功能、B 同學做 B 功能、C 同學做 C 功能等，每個人有自己的風格與習慣，因此你也會發現 MAV 分成明顯，各塊代碼風格迥異，由於 MAV 由多個同學開發，於是沒有人願意主動為其質量負責，為項目負責，他們僅是完成任務而不再後續進展了。於是邏輯層、數據層質量低下，各類風格的同學在寫代碼，沒有人想將其繼續優化做得更好。在有模塊負責人的情況下，假設該 APP 團隊被分為三組，分別負責展現、邏輯、項目。任何一個層次出現問題，都會有相應的團隊找到相關人員，要其做出處理，於是在項目中他們的交流溝通次數增多。

舉個例子，某同學進行開發 MAV、DAO 等，他很清楚地了解頁面設計、交互以及數據問題，但需要將其模式開發成一個頁面，於是三個小組各派成員進行溝通如何提高其質量，縮短時間。以現在的情況來看，越是大團隊越是採取的分工模式混亂，以 58 同城為例，一個 APP 團隊有 50 至 100 名工作人員，多個業務線，於是大批量人開發同一個 APP，而每個人各做各的事，編寫著自己的代碼，毫無溝通，導致其開發質量低下。所以必須採用模塊負責制，RD 為模塊負責，QA 輔助，利用專業方法和專業設計保證其模塊質量。

因此也必須明確兩點，第一研發是系統質量的第一負責人；第二必須通過准入達成一致，流程上的一致性、提測前的一致性，沒有通過准入 QA 不會進行測試。介面測試是近年來提高了效率才產生的，早期時候，測試與研發的比例為 1:3，一名功能測試同學，三名研發同學，以長遠的目光來看待這個比例並不是一個完美的選擇，因此需要提高其測試效率。那麼通過什麼方法提高測試效率呢？介面測試、性能測試、自動化測試等方式？

創業公司必然經歷過這樣的階段，招聘測試開發的同學慢慢學習開始做介面測試。介面測試需要設計，以及 bug 的提及。因此該同學需明確其提出的 bug，等其有復現過程後，與研發同學溝通交流，等待他們的修改和研發。但由測試同學告知研發同學需修改的地方，這是對研發同學的不信任表現。我們需要明確研發同學為性能負責，那麼研發同學定然已發現性能瓶頸，並對其進行了優化，提升了性能。做出任何的評價需要用數據，有理有據。

上圖為團隊數據月報。它詳細說明了每個業務部門產品需求、技能改進情況、bug 修復情況、上線需求總數、需求總數、需求完成率、需求超 5 人天需求數。技術團隊對產品團隊說，你們需求太多；產品團隊表示 ，我們需求並不多，只有 5 個需求，你們都沒有統計需求，怎麼可以說多。技術團隊表示不滿意，明明系統都有統計數據。於是產品團隊技術說，你們需求總是不能達成。技術團隊又不樂意了，他們表示他們需求完成率為 100%，全上線了，即使存在沒有上線的需求，但完成數仍保持高的狀態。而關於 bug 的修復，觀察數據就可以發現質量低的團隊，數據都是明確的。

3 找到主要矛盾，針對性的改進

不管是產品提測的問題，或者是研發測的問題，還是整個測試質量的問題，先看數據找到主要矛盾，再進行針對性的改進。我們曾經有過問題測試維度很高的情況，有些部門有三個，有些部門有五個，而一次上線成功的概率低，且上線之後第一時間總是出現問題，還要進行新一輪的修改再上線，於是收集數據、找到主要矛盾、針對改進。

3、加班篇

1 加入技術設計 + 評審環節

業務研發團隊壓力大，項目完不成，加班情況嚴重，就會導致項目延期。2016 年，我剛加入 58 同城，曾觀察過項目的執行情況。正如許多創業公司會做的，首先產品團隊寫出需求，之後進行評審，需求評審結束之後，項目產品負責人會諮詢技術負責人，評審已結束，需要多長時間完成項目 。技術負責人回復，需求較多，還不能完全消耗，據經驗需要四個星期時間完成項目。產品同學立馬呈現出不信任的樣子，並且表示這麼簡單的項目，時長期限只允許兩個星期。於是產品同學與技術同學對時長期限進行爭論，最後約定三個星期完成。

於是技術同學開始做任務，然後發現技術範圍比想的還多得多，以為介面已經存在只需調用就好，最後發現卻不是，而當時卻沒有考慮這個問題，可期限只有三個星期，於是趕快開始實現。其實經驗豐富的工程師評估時間是較為準確的，而經驗不豐富的新手工程師評估能力還有待提高。他們不能在三個星期的期限內完成任務，怎麼辦？他們不得不再次找產品同學表示他們確實不能在三個星期內辦到，產品同學表示需求時間是技術團隊自己決定的，不能按期完成，為何還找我們？技術團隊那怎麼辦？加人？從別的部門協調兩個人加入團隊。

但參加過項目團隊的同學都知道，並不是所有加人的項目都可以縮短工期，但產品團隊卻覺得人員增加一倍，時間減少一半。這種情況下，既然加人並不是一個完美的選擇，那麼怎麼辦？那就只有加班的選擇了。周六周日加班到 11 點，還可能因為未按期完成任務受到產品團隊的投訴，在經過長期幾輪的加班後，離職率便增高。而現階段的狀態也是如此導致其人員流動性高。

2 控制需求變更

1 流程存在的問題

如上圖所示，項目流程包括需求到需求評審、開發、聯調 + 提測、測試 + 修 bug、上線。然而，比經驗排的時間點不準確更可怕的是什麼？如下圖所示。

上圖為實際項目流程，需求到需求評審、開發到需求變更、開發到聯調 + 提測到需求變更、開發到聯調 + 提測到測試 + 修 bug 再到需求變更、開發到聯調到上線。

2 項目周期定理

變化出現在項目流程的越上游，項目風險越小，項目越可控。需求是項目流程的第一步驟，大多數推翻項目重新開始的階段便是在項目的早期階段，或是需求評審時期。在這階段時期，並沒有研發同學參與，全程僅僅是產品團隊在解決，那為何會產生如此多的需求變更？因為在很多情況下，產品團隊在沒有思考清楚時便開始著手準備，在進行一半時卻發現有一個更好的想法，只是這個想法在初期沒有想到，於是推翻重新開始。如果變化發生在設計階段或者開發階段，重來僅僅是重新設計、重新開發；若變化發生在需求階段時重新需求；若變化發生在上線階段，重來是整個流程的重新開始。因此變化越上游風險越小。

互聯網公司需求是不會保持一成不變的，反之是一定會變化的，並且有些變化的需求是不可拒絕的，然而這種情況的需求較少，產品較多。很多時候不是不讓變化，而是變化需要付出代價。大多數技術團隊認為，需求變化是理所當然且正常的行為，不變化才是不合理的狀態。但介於大家目標一致，都是為了 PV、UI、PD 等度量，因此正常的變化是被接受的，而頻繁的變化會讓人無法理解。

在技術同學與產品同學的雙方交涉過程中，一次、兩次的需求變化還可以接受，但頻繁需求變化之後，產品同學表示他的許可權不夠，如果還需要進行變化需要上報負責人審批，由於過於頻繁的變化，一級 Lead 許可權也有限，需要更上級的 Lead 同意，總結審批，產品同學便發現自己這麼頻繁需求的變化可能會導致上級領導誤會他是名不靠譜的員工，因此產品同學不得不在需求初期便想得更清楚，避免後期又出現這種狀況。

產品同學在調研、繪圖、寫文章、評審的幾個過程之後才完成一份完整的文檔；而技術同學也有設計、評審、工作任務分解的過程。每個團隊都有自己的工作，不可能產品同學需要技術同學的幫忙，技術同學便可以馬上拿出時間來。他們都需要提前安排時間。因此時間第一，控制需求變化頻率不變要有代價。除了需要改進需求、需求評審，還有設計和設計評審環節，這樣的方案才更靠譜。但尤其注意的是，工作任務分解，其現階段要求分解到半天級別，這樣即使分解出現不準確時間也不會有特別大的差距。

4、質量篇

1 數據說話、數據收集、bug 收集與分類

線上 bug 多，便投入大量的時間修改 bug。大多數公司表示線上 bug 是最高優先順序的，用戶反饋需要修改 bug，公司會優先解決，這也是個高優選擇。線上出現 bug 需要修復，在很多情況下，該臨時狀況並未考慮在項目排期過程中，因此經過多次的經驗總結，需要保留 10%-15% 的空間安排修改 bug，否則項目上線、bug 修改，兩件事的衝突最終結果仍然是加班完成任務。需求原因、項目流程原因、線上質量原因等各種因素都會導致加班結果，因此也需要不斷進行技術改進，減少線上 bug 問題，做更靠譜的未來排期。

數據說話解決主要矛盾。項目出現問題需要數據證實，但是項目的初期不存在數據，因此不得不花費一兩個月的時間做數據的總結和收集，並得出該期結論。比如，運營產品團隊的後台配置失誤、優惠券的打折出錯等需調整數據的問題也屬於 bug；你作為新用戶用手機號註冊 58 到家，但是過一段時間之後，你換了手機號碼，但發現沒有這個功能，於是提交訂單請求修改數據。

然而並不是所有類型的 bug 都需要第一時間接入進行修復。用戶側影響較大的需要第一時間解決，但後台側、體驗側、優先順序低的問題不需要立馬解決，可採取一些措施。首先進行 1 至 2 個月的數據收集，進行問題分類，對每類問題進行針對性地解決。第一類，難以避免的配置錯誤，被提供的系統運營和產品配置之間存在錯誤，但是犯錯是存在代價的。需求變化是正常的，第一次錯誤幫忙解決，第二次犯錯經理審批。多次的犯錯需要從自身找出原因，知識缺乏、技術缺乏、態度不端正等因素，任何的犯錯都需要代價。

舉個例子，技術同學抱怨自己的工作沒有技術含量，因為他日常的事情都在接受修改用戶手機號的需求，在資料庫中修改數據，並且日復一日地做這乏味的事情。產品反饋功能優先值較低，每個月只有一兩次幫忙修改，但是大家都不會設想未來隨著人數的增多，流量的增多，業務的發展，此類情況可能會變成高頻發事件。對於低頻的事件，RD 需要手動修複數據做成功能。Bug 不分優先順序，但需要 RD 第一時間介入修復，規範流程。

2 bug 修複流程

如上圖，Bug 修複流程。Bug 解決也是一個流程，研發團隊需要和產品、運營團隊、PMO 溝通、討論、確定線上 bug 解決流程。而在 bug 處理流程中，大多數是用戶側提出來的 bug，並且確定其確實為 bug，而不是功能和策略，且該部分的 50% 已被 down。達到研發團隊的 bug，評判優先順序較低，且需要一個復現的過程，請求 QA 確認過程。優先順序是依靠產品的方案進行快速判定，發現不能跟蹤的第一時間必定通知了研發團隊。然而並不是所有問題都是有技術團隊面向客戶群體，高優 bug 在當天晚上 24 點下班之前必須解決；次有問題 48 小時必須解決；之後便是兩周之內，最後影響不大的未來在考慮。

5、技術含量篇

1 深刻思考的重要性

業務團隊可能存在的問題。當一名技術同學每天重複地執行這資料庫的任務，常常做著沒有技術含量的事情，於是士氣低落，準備離職。可是我們需要開始反省，很多事情是真的沒有技術含量，還是說其實是我們想得不夠深刻。微信錢包靜態落地頁的運營需求，完成一頁靜態頁面，看上去似乎也是毫無技術含量。可是真的是這樣嗎? 我是一名架構師，曾作為該項目的技術評審，所以也不禁提出疑問，作為技術人員，你是否與運維同學了解過微信一秒鐘時間內大概覆蓋的用戶量？30 分鐘其覆蓋的轉化率如何？靜態頁面的點擊率又是多少？

根據運維產品同學的經驗表示，其 30 分鐘內兩千萬的覆蓋轉換率大概為 10%。可僅僅了解這個是不夠的，必須進行更深一步的思考，比如每秒靜態落地頁的吞吐量，若其吞吐量較高，沒有深入考慮該問題過就可能導致不能在第一時間解決問題。所謂靜態頁，即點擊之後會根據用戶所在的不同城市，展示該城市所開通服務的入口。

比如，北京開通了寶潔月嫂保姆，點擊之後便出現寶潔月嫂保姆的下單頁面；而上海只開通保姆和月嫂卻沒有開通寶潔，那麼上海用戶點擊之後會出現保姆月嫂的靜態頁。那麼如何實現不同城市的靜態頁？APP 端將此城市傳送過來，包括其開通的品類，然後將其品類入口重新拼裝再返回。然而用戶的持續點擊率造成了數據的負荷，需要緩存進行優化，可是選擇緩存數據還是頁面成為了新的問題，即使緩存的過程並不涉及技術含量，但是卻需要謹慎思考選擇哪一個更加合適。

選擇緩存數據，可數據量太龐大，將整個地區的數據進行計算、拼裝、返回，會造成用戶的浪費；選擇頁面，可緩存過程時的流量被提高擴大了 100 倍，帶寬也增加，會引發一致性問題。因此，在很多情況下，不是事情沒有技術含量，而是心態沒有端正、考慮不夠深刻從而導致我們不能做出有技術含量的事件。

除此之外，很多已發生的狀態都不能在被詢問時的第一時間回憶起，需要翻看日誌才能答覆，再者出現的問題永遠是用戶先知道，投訴客服、客服反饋產品團隊、產品團隊找技術團隊解決問題，所以解決問題的時間周期長、用戶影響時間長。而以上這些情況都僅僅是因為技術人員不夠深刻思考，不足夠了解性能數據。不同同學找 bug 的過程是不一樣的，有些同學需要三小時，有些同學卻只需要 3 分鐘。當一個經常性出現的問題，卻仍然使用複雜的過程修改 bug，卻不用最基礎類似改腳本的方式解決，這不是技術含量的問題而是不會思考的原因。

2 培養技術氛圍

每個同學擅長的技術點是不一樣的，有些同學喜歡站在講台上與大家分享的訴求，而有些同學卻喜歡聽別人講解，進行學習吸收知識的訴求。那麼何不建立一個可同時滿足兩類人訴求的平台，白天項目多，業務量大，無心分享，然而在晚上時間加班、分享二選一的選擇，絕對 100% 的同學會選擇做分享，因此該行為促進了他們白天的工作效率，使得其系統建設更全、質量更高、找 bug 時間也越短。

該種溝通分享方式稱之為技術培訓夜校，白天完成工作任務，晚上相互分享或者相互學習。在項目流程中加入設計環節與評審環節，對技術氛圍的培訓有較大的幫助。評審環節是技術方案討論與學習的好機會，在技術方案討論的過程中，除了設計者提出的方案，還有眾多同學會提出其意見，討論其緩存優化、一致性、頁面緩存等問題，可從中獲取經驗。

作者介紹

沈劍，前百度高級工程師，58 同城技術委員會主席，58 同城高級架構師，58 同城技術學院優秀講師，58 到家高級技術總監，58 到家技術委員會主席，「架構師之路」作者；在 58 同城負責過即時通訊業務技術團隊（後端），負責過二手、心寵、優品等業務技術團隊；在 58 到家負責過測試平台、PMO、DBA、OP、信息系統團隊，負責過架構、基礎平台、後端平台、中台業務等後端團隊；現負責支付平台、營銷平台、客戶平台、企業平台等業務技術團隊。

強相關廣告

當你成為技術管理者，是否困擾於如何帶領團隊成長？如何績效考核？如何凝聚團隊？如何打造影響力？

6 月 30 日 -7 月 1 日，上海，GTLC 全球技術領導力峰會，從初創公司到數千人規模公司，從老牌互聯網企業到新興互聯網公司，將處於各個階段的技術管理者匯聚一堂，帶來關於管理之術的終極探討。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！