Team Leader你會帶團隊嗎？你懂合作嗎？你好像都不會?。。ㄉ掀?/span>
                                                  ------打好你手中的牌

前言：

       這篇文章是寫給Team Leader和往這個方向前進的人。也適合一般的程序員，對你們在團隊合作的理解上面會有所幫助；對你將來選擇什在什么樣的團隊做事也有幫助。在文章中我也側面道破了國內好多敏捷開發(fā)失敗的原因。

    團隊管理是一個比較大的范圍和概念，但我們可以把它進行簡化到以團隊為基礎，在團隊上進行一些方法的應用。我在文章中，將分為不同的塊講解。當你把這些不同的塊都理解清楚，結合起來就是團隊管理。

PS：文章中的一些理解，是基于我學習一些管理書籍的內容和在工作中實踐總結的一些個人概念的敘述。是一種經驗的分享，可能會包含錯誤和不全面。需要讀者自己去判斷和理解。
      為了能讓大家對團隊更好的理解，我講的很細，導致了字數(shù)嚴重偏多。我本來想一起放上來，但怕大家看著睡覺，故分成了上下兩部分。下篇會重點集中在團隊的內部培訓和團隊成員的招聘，還有團隊關系處理上。先把上篇放出來看看大家的意見和反響，也可方便我對下篇進行調整。 看完后，如果你覺得受用，請推薦下。共同提高，我們的工作和發(fā)展才能更和諧。

　　下篇《Team Leader你會帶團隊嗎？你懂合作嗎？你好像都不會??！(下)》

以團隊開頭：（如果你知道什么是團隊，可以跳過）

       什么是團隊？這里有個比較標準的解釋：團隊（Team）是由員工和管理層組成的一個共同體，它合理利用每一個成員的知識和技能協(xié)同工作，解決問題，達到共同的目標。

    在軟件公司，一個基本的團隊單位，是由Team Leader（也可能是項目經理，每個公司對頭銜的分配不一樣。這里以Team Leader為總的稱謂）所帶領的一群人（如程序員）。以數(shù)據(jù)結構來說，就是一個多叉樹的結構；每一個節(jié)點都是下面子節(jié)點的領導；節(jié)點和子節(jié)點組成了一個團隊。Team Leader的領導（項目主管或項目經理）又會管理著多個Team子節(jié)點（開發(fā)組，測試組，美工組等）；這些Team組成了一個大的Team團隊，主管也是大Team的Leader。換句話說，每個節(jié)點都是下面子節(jié)點的Team Leader，至于起什么頭銜，并不會影響Leader的職能。

團隊類型和選擇：（重要，直接決定著后續(xù)的多個因素）

       團隊的類型其實沒有一個什么固定的稱謂和標準。一些團隊領導在工作中不斷調整團隊成員的組成。當達到一個比較成熟的團隊模式時，為了方便大家理解，會拿生活中大家熟知的一些事物來代替（如手術臺類型）。

    其實，前人已經為我們總結出了很多成熟的團隊組成類型。如：手術臺類型。做手術大家一般比較熟悉，是以一個主治醫(yī)生為主刀，其他醫(yī)生為輔助，來完成整個手術。我們可以很容易的把這種模式與團隊組成結合起來。一個團隊中，以一個或兩三個程序為主導，其余程序員為輔助來完成代碼開發(fā)；這樣的模式在國內游戲開發(fā)中經常使用。主刀也就是我們常說的主程（主要程序員或技術一把手），以主程為核心進行開發(fā)，其他程序員輔助完成附加功能。

    在實際的工作中，我個人傾向于交響樂隊類型（這個是我個人的叫法，因為這個模式和交響樂隊基本一樣，也便于大家理解。我在后面的“團隊合作”里進行了較詳細說明和對比）。在交響樂團中，團員都有各自的技能，并分工明確；在指揮的指導下完成演奏。這里的指揮就是我們的Team Leader。

    團隊的類型有很多，這里只是列了兩個被大家廣泛使用的類型；其它的類型，就請大家自己鉆研了。

    選擇什么樣的團隊類型，是一個Team Leader在組建團隊時要解決的一個問題。不同的團隊類型涉及不同的團隊成員組成，并對團隊成員技能的要求也不一樣。這會涉及到你需要招什么樣的人，這也是為什么我把副標題定為：打好你手中的牌。不同的團隊成員就如同不同的撲克牌，你要去組織和打好它。發(fā)散下思維，可以把團隊管理抽象成打撲克牌的過程，打牌就是在進行管理。

      不同的團隊類型有不同的優(yōu)劣。如手術臺類型，對主程的要求很高。在整個團隊開發(fā)中，主程的個人能力決定了整個項目的成??；在很多時候，主程也擔當著Team Leader的角色。主程個人能力這個因素，導致了我不太喜歡使用這個模式；因為風險較集中。但是在一些尖端技術的開發(fā)中，往往又是需要手術臺這種模式。原因很簡單，尖端當然需要頂尖人才去做了。這個模式有一個好處，就是對其他程序員的要求不高，比較容易招到合適的人。

      再來說說交響樂隊類型。這個是我普遍推薦的，很大一部分原因是我們并沒有很尖端的技術要去實現(xiàn)，并且這個模式可以分散風險。但是這個模式對程序員的能力有一定要求，就是需要某方面的特定能力（具體需要什么能力，根據(jù)你的項目需要來劃分）。我不需要你會很多東西，你只需要對特定領域有鉆研；或者你對某個領域趕興趣，并愿意往這個領域走下去。我需要你專精一點，如同交響樂隊里面每個人有各自的樂器技能。但這模式也有個缺點，那就是在初級程序員的招聘上，基本很難找到有鉆研一個方向的。畢竟他們對程序才起步。不過這個問題通過內部培訓是可以解決的。后面會具體探討內部培訓。

    所以，選擇什么團隊類型要看項目需要和Team Leader的經驗。發(fā)散下思維，其實在好多小公司或非正規(guī)團隊，也是使用的手術臺類型。3-5人一個團隊就上架干活了，1個技術領頭的（主程），搭配2-3個人就干了。這種類型好搭建，成本低。換作交響樂隊類型，同等情況一般人員配置會稍多，成本稍高。但是作為長期發(fā)展來看，交響樂隊類型的團隊比較穩(wěn)健和可持續(xù)發(fā)展；如果是要技術難點突破，手術臺類型的團隊就比較適合去攻克難題。

    提點敏捷開發(fā)，敏捷開發(fā)也是一種團隊類型，被大家嘗試過、討論過、分析過。我也嘗試過，最終還是轉回了交響樂隊的模式。這里簡單說下我對敏捷開發(fā)的拙見。優(yōu)勢，快速開發(fā)，快！非常快！劣勢，按照敏捷開發(fā)的理論，應該是沒啥劣勢。一切看起來是那么美好的敏捷開發(fā)，到具體操作起來卻很多失敗。其主要問題就是，敏捷開發(fā)對開發(fā)團隊的人員平均素質要求太高，一般的中小公司，很難達到這個平均素質水平。這也是我失敗的原因。

團隊合作：（別跟我說你會團隊合作，十有八九你在忽悠）

       團隊合作根據(jù)團隊類型的不同，合作的方式也是不同的。這就是為什么我在“團隊類型和選擇”后面標上重要。如果你現(xiàn)在對團隊類型的功能性理解不清楚，下面好多問題你都會產生模糊不清的觀點。那么我建議你最好花點功夫去弄清楚不同團隊類型的組成模式。比如手術臺，你可以想象在做手術時，醫(yī)生們是怎么樣合作的；在交響樂隊演出時，大伙是怎么合作的。

    團隊合作不是一群人在一起做事，不發(fā)生沖突，自己做自己的事情。通過我在工作中的觀察，發(fā)現(xiàn)很多人都持有這一觀念。根本原因是，我們從小到大就沒有接受過團隊合作的訓練。雖然我們走上社會時會知道出去工作要合作，老師也會提醒。但我們腦子里的映象是，一群人在一起做事就是合作。不發(fā)生沖突和大伙一起做事，這只能是一個基本的工作態(tài)度。如果這都做不到，那么你根本就沒有準備好做事。

    如果你要問我什么是團隊合作。那我也只能給你字面意思的解釋：團隊合作指的是一群有能力，有信念的人在特定的團隊中，為了一個共同的目標相互支持合作奮斗的過程。

    如果按照字面的意思來理解，其實是理解不了的。這只是一個理念，不是具體操作。要怎么做，我將給大家在下面道破。但是要記住一點，不同的團隊類型，其合作的方式和具體實現(xiàn)都是不一樣的。這樣就會產生很多不同的合作方式，因為有很多不同的團隊類型。如果你說你懂團隊合作，這不是忽悠你自己嗎？能弄懂弄會一兩種方式的團隊合作就很不錯了。這里再提一下敏捷開發(fā)，敏捷開發(fā)對合作是另一種方式，這種方式明顯對合作素質要求比較高。很多人連基本的兩個團隊類型的合作方式都不知道，就要他們直接跳到敏捷開發(fā)的合作模式。你說能不失敗嗎？

    下面我將通過交響樂隊的演出來說明團隊合作如何進行和為什么要這樣做。這里只是一種類型的合作方式，我主要以交響樂隊類型打開你對團隊合作的理解。后面在慢慢講解其他類型。

      一個交響樂隊有很多團隊成員組成，可以分成弦樂組、木管組、銅管組和打擊樂組（如開發(fā)組，測試組等）。如弦樂組又是一個提琴的家族，包括小提琴、中提琴、大提琴和低音提琴（如開發(fā)組里面的前端，后端等）。不難發(fā)現(xiàn)交響樂隊分工明確，職能清楚。對了，還有一個指揮（Team Leader），先忽略他。如果沒有指揮，大家各自只顧自己的，你拉你的大提琴，我吹我的雙簧管等，他弄他的長號。這樣演奏出來的只能是噪音。也許大家可以商量下，我拉完大提琴，你在吹雙簧管，他吹完你在演奏長號。不錯哦，這是一個辦法，好像沒指揮啥事。如團體舞蹈表演里面就是這樣的過程，通過觀察別人的表演事件點是否完成或者到某個狀態(tài)點時來啟動我接下來的表演；通過上一個人的事件來觸發(fā)下一個人的事件。但這有一個缺點，就是需要處理大量的上下文環(huán)境事件（前一個人表演結束，或者某個觸發(fā)點）。一旦中間有人出錯了（異常），就會引起后面的人整體出錯，因為大家不能捕獲異常和對異常進行處理。而且這樣的一個表演，對表演者的個人素質要求很高，需要大家有很高的默契和能夠對復雜不確定的異常進行處理。我們可以從中初略看到，引發(fā)異常的不確定因素很多。那么怎么處理和簡化這個問題呢？回到我們的交響樂團，這里出現(xiàn)了一個指揮（其扮演著Team Leader的角色）。現(xiàn)在交響樂隊的團隊成員不用去觀察復雜的上下文環(huán)境，而是專注自己的技能和觀察指揮的手勢（命令）來觸發(fā)演奏（執(zhí)行）的開關。這樣問題就變得簡單和好控制了，因為指揮可以縱觀全局，并扮演著異常處理的角色。一旦有團員出現(xiàn)異常，指揮可以馬上捕獲這個異常，并用經驗進行處理；且不用中斷演出，團隊成員也不用去關心有什么異常。每個人都有自己獨特的功能，只用等待指揮的調用即可。問題是不是變得簡單很多呢？但在這里突出了一個人的重要性，那就是指揮。其實很多人不理解指揮，認為指揮其實沒什么大不了，就是在上面揮揮手。一個很簡單和容易角色，沒有樂器演奏者重要或技術含量高。不要指揮，不出現(xiàn)異常，其實也可以表演的很好嘛。如果你這樣想，那是因為你不懂指揮的重要性，你不懂團隊合作的精髓。如果你是這樣一個團隊成員，那么你不會信任你的指揮（Team Leader）。當異常出現(xiàn)時，這個演奏可能中斷并崩潰。因為你不信任你的指揮，在出現(xiàn)異常時，你會用你的個人能力去判斷該怎么做。這時指揮對你的調用將不起作用，那么這樣就會造成一個無法處理的異常。這也是很多團隊失敗的原因?？梢娭笓]（Team Leader）處理著整個表演的異常情況。（發(fā)散思維：根據(jù)這樣一個流程，我們就可以很容易追蹤到事故源。查明是Team Leader異常處理的方法有問題，還是異常調用出現(xiàn)問題。具體細節(jié)不是這篇文章討論的重點，但是通過異常的判斷很容易定位到責任人。）

      團隊合作是要Team Leader來控制和主導的。對于團隊成員來說，你只要明確的執(zhí)行了Team Leader的指示，你就產生了一個合作。但這不是說你就會團隊合作了。對于團隊合作的精髓，Team Leader和團隊成員都要很清楚的理解，要不然你們是不可能產生信任，那么也不會存在合作。經過我的觀察和跟別人的交流發(fā)現(xiàn)，團隊里面最大的問題是不信任。但產生不信任的原因是什么呢？用編程的思想“抽象”來處理這個問題，經過不斷提取發(fā)現(xiàn)，最根本的原因是大家不懂什么是團隊合作。

    回到交響樂隊類型的團隊，我們可以從中發(fā)現(xiàn)：程序員信任你的Leader，并完成Leader對你的指令。這就是交響樂隊類型的團隊合作。是不是很簡單？希望你是真心理解了。記住“信任”這個關鍵詞。

    簡略說一下手術臺類型的團隊合作，主要是讓你理解不同類型團隊的合作差異。手術臺：程序員要默契輔助你的主程（其實主程就是你的Leader）。注意這里的關鍵詞是“默契”而不是信任。在手術臺模式下，成敗完全是由主程一個人決定的，程序員可以不去信任主程。但要和主程有一個默契，當主程需要什么時，馬上提供相應的輔助。

      其實還存在一個每種類型的共同點，就是Team Leader你要信任你的團隊成員。我不著重講，是因為你要是不信任你的團隊成員，你也不會去用他。你用人的基本前提就是：疑人不用，用人不疑。

    留給你自己去琢磨的，交響樂隊類型，Leader需要了解你的每個團隊成員技能，并且自己本身也需要會技術?；旧辖豁憳逢狀愋偷腖eader都是從高級程序員發(fā)展而來。手術臺類型，其實這個類型Leader的概念比較模糊。如果你分為主程和Team Leader，那么Team Leader不需要任何技術技能。這樣Team Leader會有點多余，所以很多團隊里面，主程就是Leader。這樣的組織結構，成敗完全在一個人手里。如果不是做技術難點攻破、核心技術開發(fā)，我個人不建議組建這種類型的團隊。

PS：這里我要推薦大家去看一部電影《速度與激情5 Fast Five》2011年上映的片子，我把這部電影定義為是一部標準的講解團隊合作的片子，我組織部門的人都看了一遍。網上高清下載一大把。這個電影很好看，很有激情。電影中他們一群人組成了一個團隊，分工明確，獨特的技能。他們團隊也出現(xiàn)了不信任，并處理不信任。是一個完整的交響樂隊類型的演繹。這個片子2011年上映時，我看完心里感觸很多。當我正通過閱讀來學習團隊管理時，對團隊合作等好多概念還比較模糊，能理解但又不能很好的把每個地方結合。直到看完Fast Five，整個任督二脈被打通了。這個電影也觸發(fā)了我想寫一篇團隊管理的文章，但一直遲遲沒有下筆。                     

Team Leader你會帶團隊嗎？你懂合作嗎？你好像都不會啊?。ㄏ缕?/span>
                                                  ------打好你手中的牌

導讀：

　　這是接著上一篇《Team Leader你會帶團隊嗎？你懂合作嗎？你好像都不會??！(上）》寫的。上一篇，我著重寫了什么是團隊，并比較深入的去解釋團隊和其組成。團隊管理不是什么新鮮玩意，有很多好的案例和經驗給我們學習；但是如何運用，則需要我們很好的去深入理解團隊開發(fā)的每一個細節(jié)。在下篇，就會涉及到一些人提出的疑問，并比較偏應用了。但是整篇對整個團隊管理涉及還不是很完整，因為團隊管理的全部內容不是就靠兩篇文章可以寫完的。有機會我會再深入的寫一篇團隊管理的進階篇，但是對讀者的能力要求就會比較高。

　　我看了下關于上一篇的評論，有些人不屑于去深入理解什么是團隊，我只能說你將來在團隊管理上的進步是會很渺小和漫長的。如同在我們做軟件開發(fā)時，有些人根本就不理解操作系統(tǒng)原理、編譯器原理、托管代碼運行的原理，但這影響他們編程嗎？不影響，他一樣可以編寫出程序，還會出來叫囂；但是對于懂編程和懂原理的，你會發(fā)現(xiàn)代碼質量是差別很大的，而且以后的成長也是看得出差距的。

招聘和培訓：

　　只要你明確好你到底需要什么技能的程序員，招聘其實是一件相對容易做的事情。既然很容易，可為什么有時候卻又老招不到人，結果卻變成了招人難。對于這個問題，在我的實踐當中，可以歸納為以下幾個方面。

1）  需要超人。

2）  需要超人。

3）  需要超人。

　　對于招人難，我不斷總結、反復總結，能總結出的就是“需要超人”。對于超人這個東東，可以看我的另一篇文章《不是HR，Leader你到底需要招什么樣的程序員（變形金剛？超人？可能嗎！）》。

　　在這里我以一個小團隊的創(chuàng)建來舉例說明下如何招聘和招到你需要的人。其中的核心思想就是明確你需要什么技能的程序員。

　　招聘前，你要對你的項目需求有正確的理解。你才能了解你需要哪方面技能的人。假如這里我要做的是一個.Net的Web網站的項目。首先可以把程序員分為兩級，初級和高級。如果我想把Web網站的前臺和后臺獨立開來，那么我們就需要兩個高級程序員（一個負責前臺，一個負責后臺）；如果你覺得沒有必要獨立開來，一個高級程序員就可以了。接著你就要明確高級程序員在項目中的職責。我希望高級程序員在項目中負責架構設計和前端后端核心代碼的編寫。到這里其實就可以完了，可以開始寫招聘需求了。至于要幾年工作經驗和有沒有相關項目的經驗，看你自己的把握，畢竟是你的團隊。按照普遍高級程序員3-5年的工作經驗來算，我們就可以大致寫個如下的招聘需求。

1.3-5年工作經驗

2.熟練使用C#開發(fā)語言（語言看你們項目使用來定），熟悉網絡開發(fā)

3.能夠完成項目中的框架代碼的編寫和主要功能開發(fā)

4.掌握Javascript 和 Html

其實這就可以了，如果你有明確的更細的要求，自己再列出。如：

5.理解MVC開發(fā)原理

6.熟練使用Jquery

等，具體要什么，看你的實踐需求。切記，不要寫出來的招聘需求是在招超人。寫完后Leader你自己好好讀讀你寫的招聘需求，看是不是在招超人。要是是，那么就需要修改需求，直到合適。其實在每次修改需求時，也是在加深你對你們需求的真正理解。 

　　下面我們就要開始進行初級程序員的招聘了。首先我們要確定總工作量和高級程序員的工作量。這樣我們就可以計算剩余的工作量。工作量的計算在很大程度上取決于你個人經驗的計算。當我們確定了剩余工作量，我們就可以細分我們需要幾個初級程序員來完成和需要什么技能。如需要完成接口的開發(fā)和前端網頁的編寫。這樣我們也可以寫出招聘需求了。

1.1-3年工作經驗

2.能夠使用C#進行指定功能開發(fā)，對接口開發(fā)有一定了解

3.能夠使用Javascript進行網頁交互操作

4.能夠使用Html和Css制作網頁

有時我們還需要帶美工性質的前端

1.1-3年工作經驗

2.熟練使用Html和CSS制作網頁

3.能夠使用Photoshop切圖和繪圖

4.會Javascript和Visual Studio的優(yōu)先考慮 

　　先說到這里。你也許會說，實際比這復雜的多。這里我要說，我只是通過例子讓你去了解一個流程和理解它。如果你真正理解了，其實整個流程也就是很簡單；沒有你想象的那么復雜。如果你覺得很復雜，可以從一個方面說明你目前能力還不夠。

　　在我實際的經歷中。剛開始，我寫的招聘需求內容很多，要會這要會那。在我現(xiàn)在的觀點，我就是在招超人。但是當時我覺得，我就是要會這么多技能的人，要不然沒法做?，F(xiàn)在看來，其實不用會這么多，也能做。因為在開發(fā)的過程中還涉及有學習和培訓的一個過程（我下面在講）。當你寫出的招聘需求是在招超人時，你就要開始簡化，盡量簡化到單一且核心的需求。但是有個情況，你的實際需求確實需要會很多很多。那我們怎么辦？你可能也是程序員過來的，以你自己的經驗和你身邊人的經驗。會這么多的人，你身邊多嗎？既然很少，那么你肯定招不到合適的人。這時你就需要把一個人的任務拆分成兩個人或三個人的任務，招兩個人或三個人來做。這里可能還有一個情況，就是你的老板說要招一個人，可是按照拆分下來的算，你需要兩個人。這時的你，需要和老板好好談談，因為這時不是你的能力可以及的。不要鉆牛角尖，那樣只會讓你招超人。問問老板，看老板有什么建議和指點的。有時你可能會覺得你的老板某些觀念過時了、是錯的、不如你。雖然我也有過，但是在實際的經歷當中，這些有著老程序員經歷的老板確實比你想象中的厲害很多。

　　還有一種情況，就是我要涉及到的培訓了。當你把招聘需求提煉到很簡潔了，對能力要求也按照經驗做了調整。可是，你還是會發(fā)現(xiàn)前來應聘的人達不到你想要的要求。怎么辦？有時你會覺得在降低需求就真的沒有需求了。在這里也許會有人要來抨擊我了，覺得我把程序員說的太那個了。這里我來表達一下我個人的觀點。人才確實有，但很多優(yōu)秀人才不可否認的都集中在了大型企業(yè)和公司；還有一些人則在老程序員前輩的創(chuàng)業(yè)公司為了理想而奮斗。還有一個現(xiàn)狀就是，現(xiàn)在軟件公司真的是越來越多（當然倒閉的也多）。一些中流砥柱基本上都已經被瓜分完了，有時還略顯不足，最后攤下來的其實沒有多少了。我個人的看法是，以現(xiàn)在軟件公司的數(shù)量和環(huán)境，中高級的軟件人才確實還是一個嚴重不足的情況。那么這就造成了中小企業(yè)招人難的一個問題。雖然投簡歷的人很多，來面試也是一批一批的，但是卻往往很難招到合適的人。這個時候，我們就要對應聘者放寬點要求，并提供內部培訓。

　　當你經過數(shù)次招聘后，發(fā)現(xiàn)應聘者的整體水平沒有達到你的需求。這時你就要調整一下你的要求，適當降低一些技能。因為我們得接受事實；雖然你覺得你的要求不高，但是來的人卻都沒有達到你的要求。這時我們的重點就不應該放在是否達到了你的所有需求，而是只要滿足你某些需求（你自己覺得比較重要的幾個需求）。我們就可以把他暫時列為一個合格的候選人。當我們有了數(shù)個這樣的候選人時，我們就可以從中篩選我們所要的人。這時篩選的依據(jù)是什么呢？就是學習能力。這里又涉及到怎么去考察一個人的學習能力了，這就要看Leader你的能力了。這個也屬于你該會的一個技能。我個人使用的是，通過深入談話來對候選人進行了解。通過一個具體的問題，讓候選者給出個設計方案或者思想。通過候選者對問題的回答和闡述，其實就很容易找出哪一個具有比較好的學習能力。那么，你要招的人就是他了。你接下來要做的就是對他進行內部培訓，讓他達到你所需要的技能。這里又涉及到一個問題，如何去做內部培訓。在這篇里面，我不打算涉及具體的怎么去做內部培訓，因為這又是一個大的話題。你可以自己去琢磨琢磨怎么弄，不是很難。我們不是要搞個培訓學校什么的，只要可能達到你需要的技能。我想說：對于應聘者，其實只要可以做事并且有一定學習能力，他就是符合你的。什么要這要那的，都是浮云。

　　對于初級程序員的招聘，我們可以采取筆試題+面試的方法。一般招聘初級程序員的人數(shù)相對較多，而且有時會安排集體來考核。筆試的作用就是節(jié)省時間，快速的過濾掉不合格的人。再在篩選出剩下的幾個人中進行面談。

　　對于高級程序員的招聘，我們直接采取面試。這里我是極度反感使用筆試的。不是不能用筆試，只是你往往出不了很好的筆試試卷來考核高級程序員的水平。而且高級程序員的數(shù)量要求比較少，也不需要用筆試進行快速篩選。通過深入的談話，就可以了解到很多你從試卷當中了解不到的。有時我們要結合一下公司自身實力來考慮是否需要大量的筆試題。要不然你會發(fā)現(xiàn)很難招到人，且不合適。如果，你是世界500強、你的工資開的非常高；那么，你想怎么樣都行。

　　最后提醒下你，如果你需要特定的人時，或者招不到合適的時候。我們還有一個選擇，可以通過獵頭來幫你尋找。

　　其實，我只列出了些比較基本和重要的一些因素。當往后發(fā)展，你還會涉及到實習生的招聘。等層級結構變復雜后，還會涉及到架構師等很多細分的職位。但是只要我們明確，到底我需要他來做什么。明確需求后，其實招聘的過程都是大同小異。

團隊關系：

　　團隊關系我不會講很細，只是會稍微提下，因為這話題本身就很復雜和深奧。想完全擊破它需要花費長時間經驗累積。不是說2，3年的管理經驗就可以理解透徹。你要不斷學習，不斷去思考，才可能引導你進步。我就把我遇到的和理解的做個分享，以便于提供一個方向。最后，其中的對于錯，還需大家結合實際去分析。

　　團隊關系涉及到管理學里面的內容了，大家這時需要去讀一些管理書籍，最好是西方管理和中式管理的都要涉及。西方的管理體制很完善和健全，但是很多地方不適合中國國情，特別是對人性的管理。學習西方的管理理念在結合中式管理是你需要掌握的技能。

　　團隊關系的處理，分下來可以為兩個方面：員工對員工的問題和員工對領導的問題。如當某個員工知道另一個員工和自己級別一樣、能力差不多且工資卻比自己高時或有員工工作態(tài)度比較隨意和散漫，都會產生一個員工對員工的問題。當領導給一個員工加工資時，就會產生其他沒有加工資員工對領導的問題；有可能還會產生其他員工對加工資員工的問題。產生這些問題都是人性管理當中的問題，每個人的性格不同，會產生很多你無法預計的問題出來。想要處理它，你需要長時間的經驗摸索。一旦產生問題，就會影響團隊和諧。當團隊不和諧時，雖然不會怎么嚴重的影響到每個人手上的開發(fā)任務，但是會影響團隊之間的合作效率。團隊的合作效率一旦受到影響，開發(fā)的時間周期就會延長，并產生風險。所以Leader，你要好好照看你的團隊成員。其實通過控制風險的一些方法，也可以看出團隊之間是否有不和諧的端倪，我放在后面在講。

　　團隊關系的處理雖然復雜多變，但他始終是一個對人性管理的過程。我們只要滿足了員工的基本需求，員工也會自我去調整和團隊的關系。大的需求集中在：工資、工作環(huán)境和發(fā)展空上。當有員工開始出現(xiàn)問題，這時我們就需要了解是什么影響力他，讓他產生了問題。普遍不會逃出這三個大方向。你在看是否需要滿足他其中的一個要求。如果不在這三個之內，基本上都是些不太合理的需求，我個人認為是無理取鬧。但是我們還是要細心去了解是什么其他原因。如很長見的是員工家庭的原因，這時你就需要進一步了解。如果是，可以給予幫助或合適的便利。

　　還有員工的跳槽啊等等都會產生員工的問題。這里不會再去討論和解說了。只要你掌握了原理和深刻理解了，當出現(xiàn)問題時，你都會有方法來解決它。

風險管理：

　　對于剛開始做Leader的人來說，風險控制是很頭疼的一件事情。有時心里會祈禱不要出現(xiàn)風險或對自己說應該不會出問題的。當有這種想法時是萬萬要不得的。一旦風險出來，你可能會慌亂和不知所措，最后導致項目的失敗。那么風險管理的難點在哪里呢？其實就是在于你對團隊理解深不深刻。只要你理解了團隊，使用些曉得方法就可以控制住風險。最后你會發(fā)現(xiàn)風險控制很簡單嘛，那是因為你對整個團隊的流程和細節(jié)都了解清楚了。這時的你，也開始走上團隊管理的正確道路上了。

　　在項目開發(fā)當中，最主要的風險就是時間。那么我就在這里擊破它。首先我要說：如果你項目的復雜度所需的真正時間確實超過了老板所給的時間或者超過了你估計的時間，那么神仙也救不了你。因為一個是你老板的問題，一個是你自身的問題。如果是這樣，你自己找墻去撞。除了這個之外，我們使用些小方法，就可以解決掉時間的問題。在分配任務時，我們都會明確的給予一個功能的具體時間。如果一個單個功能需要4個工作日以上的，就需要寫報告來匯報功能進度（每3天一個報告或你自己定）。這樣你可以很好的了解功能的進度，一旦發(fā)現(xiàn)可能會超期完成，你就要介入進去了解和分析是什么原因造成的。如果是你們確實低估了該功能的難度，那么馬上進行調整，是重新分配工作時間還是降低該功能的要求。如果是員工個人原因造成的，那么你需要了解是什么原因造成的?？纯催@個功能是否需要與人合作開發(fā)。如果需要與人合作，那么很可能是產生了團隊關系的員工問題。這時你需要去調解和解決問題。通過風險的管理，我們也可以找出一些團隊關系的潛在問題出來。如果是個人能力不夠開發(fā)該功能，那么馬上更換人員進行開發(fā)。對于4個工作日以下的不需要發(fā)送報告，只用在功能完結時發(fā)個報告，以便進行下一個功能。因為這種功能時間需求短，一旦超期，是有時間來調換人員來做的。如果某人長期超期，你就要進一步去了解了。有公司強行每個員工每周寫周報，有的是2個星期一寫。我只能說，周報這玩意真的很稀爛。別跟我說是方便管理方便考核，這就是Cao蛋。這里還有一個問題，就是每個工作日的有效工作時間。有Leader是控制在一個工作日80%時間都在進行開發(fā)，有的甚至是90%。我個人喜歡控制在70%左右，因為一天能高效編寫代碼的時間也沒有多少。而且一旦遇到有超期的功能，你就有人手和足夠的時間來進行處理。我們要留出風險處理的時間。

　　當項目完成后，發(fā)現(xiàn)有Bug。這時可能已經接近項目尾聲了，你沒有多余的時間去處理Bug了，這時產生了一個風險。為了能把Bug在開發(fā)中就消滅掉，我們需要開發(fā)和測試并行執(zhí)行。在項目開發(fā)的時候，測試組就根據(jù)功能接口開始編寫測試代碼。當有開發(fā)人員提交一個完成功能時，就可以馬上開始測試，并當有Bug時可以馬上進行修復。這也是為什么在一個工作日當中留多一點時間，因為你還有Bug要修復的。當Bug提交時，每天早上花30分鐘（30分鐘就夠，不要花太多時間）集中程序員和測試人員快速開個會，把Bug全部過一遍。有些Bug是不用修復的，我們可以標出。有些Bug是需要排出優(yōu)先級的，這時需要你來分配。通過每天對Bug的審查，當項目交收時，你會發(fā)現(xiàn)Bug都被你控制了。

　　還有一些突發(fā)事件引起的風險。如：程序員離職和項目中提出要求加工資。一般這兩個因素會打擾你的整個計劃。當出現(xiàn)這兩個因素時，處理的優(yōu)先級是最高的，要馬上解決掉。如果是有人離職，就放他走吧。就算你強留下來，可人家心已經飛了。這對于功能完成和時間上的風險已經不好控制了。你要做的是趕快重新分配人手和調整時間，并馬上進行招人。有人可能會說這哪里來的急。這里就要回到我前面招人所說的，明確你需要的每個人的職責和所需要的技能；當有復雜的招聘需求時，就進行拆分，使需求盡量比較單一。這樣當出現(xiàn)問題時我們可以很容易招到合適的人。如果你招的是超人，那么到這里你就沒法處理風險了。還有一個我們需要做的就是平時儲備人才，遇到合適的就先招之。對于臨時要求加工資的，分兩個情況：公司沒有一個明確的加工資制度和有正規(guī)的考核加工資制度。如果你們公司屬于前者，你不要怪別人，你們自己都很Cao蛋；如果是后者，那么對于要加工資的殺無赦，并準備開始換人吧。

總結：

　　這是一篇初級的文章，我沒有講的很多，但盡量講全。從文中我們可以知道，從團隊開始的每一個環(huán)節(jié)都會和后面的風險處理緊緊相扣。這也是我為什么強調一定要理解什么是團隊這個基礎概念。要不然到后面，你會發(fā)現(xiàn)風險越來越不受你控制。就算你找到辦法補救了一個，卻還有很多未知的風險。你就等于在亡羊補牢。亡羊補牢我們都知道，晚了嘛。