不知不覺中，已經(jīng)進入IT圈子五個多年頭了，短短五年，卻是人生最美好的五年，這五年中經(jīng)歷了塞班的沒落到消失，經(jīng)歷了移動互聯(lián)網(wǎng)的興起、瘋狂到理性發(fā)展，這五年中也接觸了太多的人，形形色色、稂莠不齊，有行業(yè)的頂級大牛，也有工作八九年卻只有兩三年經(jīng)驗的水平。帶了幾年團隊后，才發(fā)現(xiàn)的發(fā)現(xiàn)，即使你是千里馬，如果不能遇到你的伯樂，你可能一輩子都是拉車的騾子。

?

• 1、招人過程中的一些要素
  • • • · 邏輯思維
      • · 溝通能力
      • · 團隊精神
      • · 技術(shù)能力
      • · 補充
• 2、對于接手新項目的一些判斷
• 3、對于隊友的培養(yǎng)和提高
  • • • · 對于新手的建議
      • · 進階的建議
      • · 資深的建議
      • · 補充建議
• 4、發(fā)現(xiàn)問題與解決問題
  • • • · 產(chǎn)品問題
      • · 團隊問題
      • · 代碼質(zhì)量問題
• 5、結(jié)尾
• 6、推薦

?

1、招人過程中的一些要素

這幾年中，當面試官和被面試都好多次，總的來說，在我面試別人的時候，能方便他人都會盡量去方便，面試過程中，盡量營造一個輕松的氣氛，比如聊一些別人的強項，總是抓住別人薄弱點不放，把氣氛搞得很尷尬，真的沒必要，我所在的團隊，需要招的可以是偏才，我并不在乎是不是全才，就算是鉆研多年，也不可能做到樣樣精通，而我自己，薄弱的地方也很多，這些都是很現(xiàn)實的事情擺在眼前，能幫忙多爭取點薪資，盡量去爭取了，直白點，在不壓薪資的基礎(chǔ)上，在爭取多一點薪資，隊友會更加努力的工作，更有激情去完成每一次挑戰(zhàn)，再說了，老板能接受15k一個月，一般17k也是能接受的。

接下來就說下在組建團隊的過程中，我所關(guān)注的點。

· 邏輯思維

為啥我把邏輯放在招人第一位，而不是首先看技術(shù)。沒有一個好的邏輯，代碼會顯得雜亂無章，工作中，比較反感一類人，看到需求文檔拿過來就寫，不懂的人看到這情況，也許會覺得工作效率好高，實則不然，這樣的代碼，通常是很難維護的。如果僅僅是某個功能寫錯了，出了bug 很容易去修復(fù)，但是一旦邏輯出問題了，這個災(zāi)難可能是滅頂?shù)?#xff0c;大到整個功能可能需要推倒重做。在沒理清思路的情況下就去寫代碼，當發(fā)現(xiàn)文檔沒讀清或者中途部分需求改變的情況下，邊寫邊添加、修改功能，幾次迭代，再想使用的時候，發(fā)現(xiàn)已經(jīng)沒法維護了，當隊友想使用這塊內(nèi)容的時候，發(fā)現(xiàn)修改的成本遠遠大于重構(gòu)，這就給團隊帶來了不該有的麻煩，嚴重拉低了效率。

建議：理清思路的方式有很多，如果功能確實很復(fù)雜，推薦先畫圖，一圖勝千言。

· 溝通能力

談完了邏輯，接下來會是看技術(shù)嗎？非也。在我看來，如果沒有一個好的溝通能力，談吐不清，會給隊友或者其它部門同事帶來很多不必要的麻煩。一個簡單的功能，說的不明不白，協(xié)作者也是一種痛苦，一個好的談吐能力，可以營造更加高效的工作環(huán)境，同時也能營造更好的氣氛，使得身邊人更愉快的工作。相信在日常工作中，因為沒表達清楚造成一些不必要的麻煩，這肯定是一個普遍現(xiàn)象，而不是個例。

之前同學在微軟的時候，有一句話他們那邊經(jīng)常提到，“絕大部分的失敗，都可以以歸咎于沒有溝通好”。

· 團隊精神

說到團隊精神，這是我三年多前開始帶團隊和招人的過程中一點點學會的，或許這是我來上海后，第一家公司領(lǐng)導(dǎo)對我一個比較重要的影響。真有那么重要嗎？這是肯定的，有一次招人，面試過程中，面試者的技術(shù)、邏輯都很好，談吐說不上好或者不好，那時候沒關(guān)注那么多，直接就是一輪技術(shù)面試，面完了后就給領(lǐng)導(dǎo)匯報，領(lǐng)導(dǎo)又下去聊了一會，回來就找我談話，覺得怎么樣？我說技術(shù)還挺好，領(lǐng)導(dǎo)又問了一句，那別的呢？瞬間懵逼，我們找技術(shù)，不就是看技術(shù)嗎？別的指的是啥？領(lǐng)導(dǎo)和我說了一句話，“如果他加入，可能會影響到團隊，很難融入我們的團隊中，我們要的不僅僅是技術(shù)過硬，團隊更重要”，就這么簡單的一句話，我卻思考了好久，是的，我們不是一個人在戰(zhàn)斗，不能因為一個不合適的人影響到整個團隊的氛圍。

后來帶團隊而過程中，我也時常把團隊放在首位，我們是一個團隊，不能因為僅僅站在自己的角度考慮問題，該提取的要提取，該抽象的藥抽象，完成自己的同時，盡可能方便他人，公共類和父類的修改，不可以影響到別人的功能，更不能因為自己使別人產(chǎn)生不必要的閃退。盡可能把代碼的可擴展性、可維護性、可重用性、靈活性做得更好，高內(nèi)聚低耦合，細節(jié)決定成敗，只會寫功能的，那只是碼農(nóng)，處處為團隊考慮的，那是最起碼的領(lǐng)袖氣質(zhì)，不想當 Leader 的程序員，不是好的工程師。

· 技術(shù)能力

好了，終于談到了技術(shù)，這塊放到最后，并不是說不重要，這要看公司要招的職位了，如果僅僅是招初級開發(fā)，只要掌握基礎(chǔ)就可以了，沒必要問得太深入，如果一個一年工作經(jīng)驗的，架構(gòu)設(shè)計的很好，那何必還要招一些五年及以上的，反過來說，用五年經(jīng)驗的或者三年經(jīng)驗的去要求工作一年左右的，這有點扯淡，招人沒誠意。有了扎實的基礎(chǔ)，學東西事半功倍，下層基礎(chǔ)決定上層建筑。對于中級，可以適當問一些設(shè)計模式，或者平時所用到的一些優(yōu)化或者處理問題的方式，當然，基礎(chǔ)也必須扎實，不管哪一階段，基礎(chǔ)都是重中之重，這個是硬性要求，決不妥協(xié)。對于高級或者資深，根據(jù)對方的強項，一個問題可以探討個大半小時，從表面到底層、從應(yīng)用到源碼，問題不在于多而在于精，還有就是一些解決問題的方式，多個解決方案，那種最優(yōu)。

· 補充

我在招人的過程中，一般都是按照以上幾點去招人，像那些故意用一些項目中用不到的技術(shù)來壓工資，這些方式都是無恥的，比如有的項目，現(xiàn)在和以后都用不到藍牙開發(fā)，卻不停的問一些藍牙的協(xié)議，何必呢？一個非音視頻的產(chǎn)品，不斷地問 FFmpeg，真沒必要。碼農(nóng)何必為難碼農(nóng)。每一個來面試的人，在沒有被pass掉之前，都可能會成為你的隊友，該怎么去處理這層關(guān)系，這對于團隊以后的發(fā)展是很重要的。

2、對于接手新項目的一些判斷

這個標題可能有點歧義，我想說的是入職新公司，接手公司之前的一個項目，對于自己來說，這就是一個新項目。

對于這個問題，其實討論的就是重構(gòu)和再利用的這層關(guān)系，在分析源碼后，在過完項目需求后，在排期出來后，對于新接手的項目，到底該重構(gòu)還是再利用，這是做為 Leader 該慎重考慮的問題，如果直接推倒重做，那之前的很多工作就會隨著項目的推倒而付諸東流，可利用的代碼也會少之又少，甚至幾乎都用不到了。這其中還要考慮到團隊的作戰(zhàn)能力、時間的緊迫性、推倒重做的可行性。如果不推倒重做，在原有基礎(chǔ)上的維護，成本會不會大于推倒重做的成本，項目上線后的維護是不是災(zāi)難性的。

去年在聯(lián)想控股的時候，接手一個供應(yīng)鏈金融的項目，這個項目在我來之前是兩個非 Android 同事寫的，雖然這兩位同事代碼質(zhì)量都是非常高，水平高但不一定能寫的好，因為他們是站在非 Android 的基礎(chǔ)上考慮問題的，也是在非 Android 的基礎(chǔ)上寫的代碼。入職的時候，只有一個半月的時間，要做一個大版本，采用封閉式開發(fā)，團隊是新組建的，幾十頁的需求文檔，評審就過了兩天，金融項目本來邏輯就很復(fù)雜，從業(yè)務(wù)經(jīng)理到最后的放款，角色有十幾個，從申請貸款到最后提貨或者逾期平倉，這個過程中的狀態(tài)也有十幾個。之前負責的同事也和我做了簡單的溝通，建議在原有的基礎(chǔ)上在開發(fā)，畢竟之前一些功能還是可以用的，而且大家都是新來的，對我們這批新人的不放心應(yīng)該也是有考慮的。是的，在原有的基礎(chǔ)上開發(fā)，這個方式確實比較穩(wěn)當，但穩(wěn)當?shù)谋澈笫切枰冻龃鷥r的，在順利完成任務(wù)后，后期出現(xiàn)了很多不該有的bug。封閉式開發(fā)后，接下來的版本，時間沒那么緊迫，對項目又一點點的進行了重構(gòu)，這個過程也是挺痛苦的。

對于后來的這些痛苦，并不認為是當初判斷出了錯，在那樣龐大的需求面前，不了解同事的情況下，只能求穩(wěn)避險，讓項目按時上線才是第一要素，對于后來的一些重構(gòu)，封閉式開發(fā)結(jié)束后有更多的時間去優(yōu)化和重構(gòu)代碼，充分利用好這些時間，項目代碼還是可以達到高質(zhì)量的水準。

再后來來到這個新公司，也是接手一個新項目，一個新的團隊，之前的代碼看了下，對于新版本來說，完全可以干掉重做，之前的項目代碼量太少，質(zhì)量也差強人意，在這之前，一直在修復(fù)bug的過程中，在這個基礎(chǔ)上繼續(xù)開發(fā)，得不償失。雖然又是遇到了封閉式開發(fā)，但這次做出的決定和上一次完全不同，直白點說，就算我一個人單扛這個項目，雖然有壓力，但也是可以按時保質(zhì)完成的，為了以后更愉快的開發(fā)，這次不再是求穩(wěn)避險而是穩(wěn)操勝券，選擇了重構(gòu)，對于這次的選擇，至今依然覺得對正確的，幾個隊友也覺得比之前寫起來更舒服。

總結(jié)：對于新接手的老項目，到底該如何選擇去留，這并不是看心情所能決定的，一旦判斷錯誤，這將可能是沒日沒夜的加班，根據(jù)需求，合理的把控時間節(jié)點，給自己多幾分把握。對于新團隊，可以通過平時聊天和觀察隊友的長處與短板，合理安排任務(wù)，對項目進度事半功倍，順利取得按時保質(zhì)的上線。

3、對于隊友的培養(yǎng)和提高

“聞道有先后，術(shù)業(yè)有專攻”。這幾年帶團隊過程中，有剛?cè)胄械男□r肉，也有工作四五年的世外高人，有激情澎湃的激戰(zhàn)分子，也有功力深厚卻混吃等死的小伙伴，再說了，不可能每個團隊里面的人才都是一個樣，各有所長是很正常的現(xiàn)象，對于每個不同的團隊，做為一個Leader該如何去提高培養(yǎng)和提高同事？

隊友的培養(yǎng)和提高，不僅僅是技術(shù)上的，有些團隊的技術(shù)大牛遠遠強于 Leader，這也是非常常見的，然而作為一個合格的 Leader 也不僅僅有過人的技術(shù)，還有讓隊友俯首是瞻的氣質(zhì)。

· 對于新手的建議

對于新手，此時處于萌芽階段，最主要的就是指明一個方向，比如面向接口編程而不是面向?qū)崿F(xiàn)編程，比如六大基本原則熟記在心，比如不要重復(fù)造輪子。對于一些事故多發(fā)地帶，適當提醒下，即使不小心入坑了，也能快速找到原因并從坑中爬出。在項目時間寬松的時候，可以多給新手點機會，哪怕類似的功能，不同的人思考的方式是不同的，隨著代碼量的提升，使用的實現(xiàn)方式也是不同的，采用的架構(gòu)設(shè)計也會是不同的，新手很需要代碼量的提升，此處說的代碼量是思考后的代碼，不包括單純的復(fù)制粘貼。

對于新手，個人不建議早早接觸太多高深的技術(shù)，穩(wěn)扎穩(wěn)打才是正確的方式。在沒有熟悉一門語言之前，沒必要多門語言同事學習，一旦不經(jīng)常去寫，很容易被遺忘。虛心接受過來人的建議，并不是每個人都有必要去指點你。

· 進階的建議

有些工作好多年的，同樣一個功能、流程，已經(jīng)走了好多遍，比如注冊、登錄，都是大同小異，達芬奇密碼下面是啥？當然是達芬奇驗證碼了。對于這樣的隊友，代碼量還是挺豐富的，應(yīng)該把更多的時間放在源碼分析、性能優(yōu)化、架構(gòu)設(shè)計。對于登錄、注冊，資深和新手寫出來明顯是不一樣的，新手會把更多的時間放在功能的實現(xiàn)，而作為經(jīng)驗豐富的你，是否更應(yīng)該把多考慮可擴展性和靈活性，比如以后增加了第三方登錄了，比如增加了郵箱登錄了，是否可以在不改變或者幾乎不改動原有代碼的基礎(chǔ)上，無縫添加這些新的功能，而不是一味地修修補補，最后迫不得已就重構(gòu)。在對接一個第三方的時候，比如接了百度地圖，當日后需要用高德地圖替換掉百度地圖的時候，是否可以做到一鍵替換？

學而不思則罔，思而不學則殆，邊走邊看，邊看邊思考，高效的代碼是90%的時間在思考，10%的時間在coding，把修改bug的時間用在思考，而不是日后的修修補補。

· 資深的建議

這個階段，應(yīng)該更好地提高其它編程語言，或者提高技術(shù)之外的能力，往往通過一門語言去達到登峰造極的程度，這是很難的，一門語言所接觸到的編程思想畢竟有限，可以通過更多的技術(shù)來學習更好的思想，從而大大的提高編程效率。現(xiàn)在很多語言建也是相互借鑒，最初的時候，微軟的C#更多的借鑒java的一些編程思想，但java的響應(yīng)式編程和lambda又是從別的語言借鑒而來。

在這個階段，技術(shù)之外更有必要去提升，比如帶新人、帶團隊，我算是比較幸運的，在工作不滿一年的時候就開始帶新人，工作不滿兩年的時候就開始主導(dǎo)項目，現(xiàn)在想起來都覺得慚愧，自己啥都不會的情況下，公司就趕鴨子上架，哈哈。雖值得欣慰的是，每任領(lǐng)導(dǎo)對我的工作還是比較認可的，因為接觸帶團隊比較早，作為過來人，對于早期的問題或許會更加清晰一點，經(jīng)過幾年的積累，更加游刃有余，知人善用，方可事半功倍。

對于工作多年沒帶過團隊的朋友，在合適的時機，可以主動請纓，毛遂自薦，機會是留給有所準備的人，在這之前，邏輯思維、表達能力、團隊精神和技術(shù)能力都需要得到公司的認可，公司也可以更放心把團隊交給你，這也是我為啥招人的時候，非常看重這幾點，我也希望有一天我的小伙伴離開團隊出去找工作，都能獨當一面，成為當前公司的技術(shù)型管理。

· 補充建議

人們經(jīng)常說程序員是青春飯，或許這句話是沒錯的，也經(jīng)常看到XX公司35歲后被辭退，不管這新聞是否屬實，我們都應(yīng)該未雨綢繆。coding是不能一輩子的，61 歲的 Java 之父 James Gosling 在 Facebook 上發(fā)表了他所遭遇的年齡歧視：“通常我們不招你這種年齡的程序員，但你的情況特殊（指的是他 Java 之父的身份），所以對你特殊考慮。”做為程序員，我們未來的選擇無非就是從技術(shù)轉(zhuǎn)管理、創(chuàng)業(yè)或者轉(zhuǎn)行，到底該怎么選擇，這將根據(jù)自己的興趣愛好和需要，在此不做闡述。

4、發(fā)現(xiàn)問題與解決問題

對于一個 Leader，發(fā)現(xiàn)問題這是很重要的，這將包括產(chǎn)品問題、團隊問題、代碼質(zhì)量問題，下面將分別闡述。

· 產(chǎn)品問題

曾經(jīng)一個朋友跟我說過一件面試中的小事，一個技術(shù)官問他：

甲：“你是怎么定位自己的？”
乙：“我在上家公司的的offer是資深開發(fā)，在公司是團隊Leader”。
甲：“我問的是你怎么定位自己？或者說，你是把自己定位成開發(fā)還是開發(fā)加產(chǎn)品”
乙：“抱歉，這個問題我之前沒考慮太多，平時開發(fā)中，我更多的時間關(guān)注的是代碼質(zhì)量和用戶體驗”

對于以上的事情，我相信這是一個很普遍的現(xiàn)象，細節(jié)，真的決定著成敗，站在產(chǎn)品的角度考慮問題，更有助于理清產(chǎn)品思路。之前在過完需求后，第一時間想到的就是我該如何去更好的實現(xiàn)這個功能，從程序員的角度出發(fā)，這是沒任何錯誤的，但是從一個 Leader 的角度出發(fā)，這就是一個錯誤。

· 團隊問題

這個問題，片面點說，這就是一個民主與集權(quán)的問題，因人而異，對不同的人不同的對待。工作中的隊友一般分為兩種，一種不指派任務(wù)就會忙自己的事，看書、看新聞、逛帖子，一種是做完事情后主動請纓，能否為公司、為團隊多做一點，從而更快的提升自己，對于第二種，這樣的隊友很容易打理，可以實現(xiàn)過度民主，因為他知道自己該干嘛，會竭盡所能去多做點事，對于第一種，如果在項目進度寬松的時候，可以適當民主，每個人都有自己的愛好和業(yè)余生活，拓展一些其它技能也在所難免，在項目緊張的時候，過于民主可能會影響公司進度，因人而異，因地制宜。

· 代碼質(zhì)量問題

這個嘛，之前寫過一些博客，分析了為什么有些人不適合重構(gòu)代碼，雜亂無章的寫法，重構(gòu)后不久，可能又面臨著無法維護，還需要再次重構(gòu)，惡性循環(huán)，當誤了時間，降低了效率。做為 Leader，很有必要制定一些準則和規(guī)范，對于字段的命名統(tǒng)一規(guī)范，對于一些必要地方的注釋，一些不必要的地方濫用注釋，好的命名方式，可以減少很多不必要的注釋，過多的注釋或者錯誤的注釋，會嚴重影響開發(fā)效率，誤導(dǎo)他人或者自己。接下來就是一些可重用的代碼，方便自己也方便他人。

對于代碼質(zhì)量，我認為應(yīng)該不定期的 review，對于新加入的同事，可以抽出更多地時間去審閱代碼，指出一些不足和不規(guī)范。對于一些老隊友，在時間充足的情況下，可以互相審閱，互相批評指正，互相學習共勉，達到共同進步。

5、結(jié)尾

最后我想說，作為一個團隊的Leader，別拿自己當回事，其實就是一個打雜的，團隊內(nèi)各種瑣事都需要去處理、去溝通，有功一起分享，有事自己扛。作為一個團隊的Leader，真不能不把自己當回事，因為你的一個行為判斷，這可能會影響一個團隊的運作。做好眼前事，珍惜眼前人。

6、推薦

• 第一篇：勿忘初心，繼續(xù)coding
• 第二篇：編程路上，送給處于迷茫中的你和自己
• 第三篇：編程路上，對于迷失者的一些小小建議
• 第四篇：如果不從事編程，我可以做什么？
• 第五篇：給最真的自己加上static final

---

微信掃我

總結(jié)

以上是生活随笔為你收集整理的技术部门 Leader 与团队那些事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。