在開始后面的內容之前，還是需要先提前聲明一下，這并不是一篇吐槽的博客，而僅僅是將自己的感觸和經驗分享出來。當然大家更不要認為是炫耀，畢竟已經工作了十幾年，確實是因為依舊保持著一顆熱愛編程的心，所以直到現在依然奮戰在軟件開發的一線。好了，還是讓我們盡快言歸正傳吧。

在過去的十多年中，我曾就職的公司多為中小型公司，有美資、金融和國內股份制等多種不同性質的企業，唯一的一家大型公司還是軟件外包公司，而我在這個公司的職位則是架構師，不是研發經理。我想，在做具體闡述和分析之前，還是先亮明我的觀點，即軟件團隊的構建過程首先要考慮的是公司性質和企業文化，再者是我們的交付物，如特定的軟件項目、軟件產品、運營平臺，或者說干脆就是公司內部使用的軟件平臺或工具，最后需要考慮的才是人員成本。

對于軟件公司而言，不論是做項目還是做產品，不可否認的是研發經理，架構師和程序員都屬于公司的一線員工。他們的產出都將會或多或少的為公司帶來一定的收益，因此這些一線開發團隊在公司受到的重視程度自然也會高于其他性質的公司。由于本人更多的時間都是工作在軟件公司，所以該篇博客將主要針對如何在軟件公司中構建研發團隊進行分析和經驗分享。

1. 項目團隊：

這個相對比較簡單，一般而言都會根據項目的技術特征去尋找合適的開發人員，比如說，先挑選一位有經驗的，最好是有相關項目經驗的開發人員作為這個項目的Tech Leader，之后再根據技術特點，項目總額和開發周期去尋找適當數量和能力的開發者。如果再往深一層考慮，倘若該公司比較看好這個項目，甚至有可能在一段時間之后將其逐漸過渡為自己的產品，那么就需要在組建之初即刻考慮項目中技術人員的梯度建設問題。

2. 產品研發團隊：

相比于為了某個項目組建團隊，構建一支產品研發團隊就應該有更多的問題有待提前考慮和解決。因為軟件產品的盈利來源并不僅限于賣出一套產品所獲得的實際收入，因為軟件產品基本都是可持續更新的，所以除了可以每年向客戶收取一定比例的產品維護費之外，還可以在產品不斷成熟之后，收取更為可觀的咨詢費。由此可以看出，構建軟件產品團隊，不能僅僅單純的依照產品的技術特征去物色適合的開發人員，同時也需要在組建團隊的伊始，就要將人員梯度建設等問題考慮進來。比如，團隊中的成員分為高、中、低和專項技能專家，對于高端的技術人員自始至終都會承擔最核心、最關鍵的開發任務，然而對于中級技術人員來說，除了要保證產品開發的順利實施之外，在產品的不斷迭代和完善的過程中，還需要將一些已經突破的技術難關和沉淀下來的一些可復用基礎功能進行有效的封裝，從而大大降低之后的產品升級成本和維護難度。

在經過若干年之后，隨著產品的日臻成熟和穩定，當年的初級開發者已經成為這個團隊中的重要技術骨干，而中級開發人員中的佼佼者則成功躍升為高級技術人員，高級開發者可以進一步升級為專項技術專家或高級咨詢人員。此刻，公司便可以充分利用現有的人員和技術優勢，繼續深度挖掘和規劃現有的軟件產品并最終形成自己的解決方案。

3. 運行平臺研發團隊：

如果你所在的公司是非常有錢且知名的軟件或互聯網公司，他們往往都是在看好某一平臺之后，不計成本的招人并快速組件團隊，以便能夠成為第一個吃螃蟹的人，在此種情況下，最好的方式還是能夠和獵頭合作，有的放矢的找到合適的高端技術人員，而對于中級開發者，由于給出的薪水將會明顯高于市場行情，因此說快算組建將不會是什么難事兒。然而更多的問題卻留在了后面，如果平臺快速開發完畢同時也能達到預期，這樣問題將不會立刻凸現，否則這些人的薪資與能力的匹配度失衡問題將會給公司其他團隊的技術人員帶來一定的負面影響。那么對于那些沒有如此充裕預算的公司又該如何呢？其實這也是我現在在面臨的問題，我的做法是，在產品沒有完全啟動之前，先尋找一些可以幫助我們突破核心技術的高級技術人員，與此同時，挖掘公司內部可能用到該項技術的熱身性項目，前提是這種項目或者說小的產品仍然可以給公司帶來一定的收益。由此研發經理不僅可以爭取到更多時間、鍛煉隊伍，而且也會因每個成員都能快速對號入座而減輕了壓力。一旦這些熱身性項目實施成功，我們的研發團隊就會有效的提升在直接上級和產品經理心中的信任度。因此即便在今后核心產品的實施中遇到一些問題，他們也仍有可能給予這個團隊足夠的信任和理解。

該篇博客主要是以陳述的方式介紹自己的經驗和想法，并沒有進行更多的論述，因此對于一些失敗的場景并沒有給出具體的解決方法。最后需要說明的是，多年以來我始終都會堅持一個理念(引用一個非常不錯哥們兒的名言)，任何困難、挫折和暫時的失敗，在主義面前都是浮云。

淺陋之談，歡迎指正，切勿吐槽。

原文鏈接：http://www.cnblogs.com/stephen-liu74/archive/2012/09/17/2687562.html