好的技術選型，能最大程度地提高企業和團隊的效率，從而開發出滿足用戶需求的產品。作為一線的技術管理者，他們都是怎樣做的呢？
大公司或者大一點的團隊的技術選型幾乎不需要太多討論，因為最后會不可避免地繞到技術官僚的話題上去。這里我簡單說說技術型創業團隊的技術選型問題。
擁抱開源技術
如果只能選擇微軟的 技術路線，比如團隊只會用微軟技術，也不想學別的，那么似乎沒有別的辦法，將就一下吧。如果還有的選擇，盡量使用開源技術。這樣不但可以有效降低軟硬件成 本，還有更多的部署方案可供選擇，服務器上線甚至還能避免病毒的侵襲。開源技術的好處是出了問題，你總有辦法可以找到答案。而用微軟的產品，可能平時不出 問題，但一出問題，你根本沒什么辦法。微軟的產品使用門檻倒是低，但復雜度可一點都不小，而且隨著發展，成本越來越高。國內有幾個大中型網站，比如天涯、 5173、大眾點評、京東等，怕是深有感觸吧，有的因為成本太高而繼續被捆綁，有的則破釜沉舟要擺脫這種束縛，但不管怎樣，總要付出一定的開銷。
開源技術路線有數種分支，該怎樣選擇呢？選擇大路貨，選擇可以掌控的開源技術產品、語言、程序、框架，乃至解決方案。比如PHP，比不上Ruby陽春白雪，但用戶基數大，總能找到不錯的工程師。PHP雖然粗糙，但是管用。以PHP作為開發語言的成功產品不計其數，很多東西根本不需要你再開發，稍加定制即可。技術本身沒有高下之分，差別在于使用技術的人。
避免過度炫技
技術人員創業最容易犯的一個錯誤就是“炫技”，即熱衷于使用最新、最時髦的技術。新東西的確可以給技術人員以滿足感，但也很快會將你的時間資源消耗進去，除非你準備做的是一款基礎產品，否則你要花時間去學新規范、熟悉新功能、對付新出現的軟件Bug……但這時你最需要做的是開發產品，而不是搗鼓其他東西。一些新技術或者方案，可以花些時間分析一下但沒必要立刻就用，只需確保將來有一天能真的用上時，對一些重大的陷阱或是缺陷能夠了然即可。
很多人神往37Signals的成功，但你一定要知道類似37Signals的團隊，默默無聞地夭折掉的不知道有多少。每當看到創業團隊就那么1~2個 人還整天搗鼓Go、Erlang這些東西，并想硬生生地用到產品中去，我就知道，這樣的團隊要懸了。有這些精力和能力，應該想辦法盡快讓技術變現，研究一 下怎樣改進產品、怎樣給用戶帶來更大的價值，而這些不一定用最好的技術才能做好。想辦法盡快讓產品發布，盡快接受更多人給你第一輪反饋，只憑創業團隊幾個 人閉門冥想是很難出來好產品的，有時產品推出的時機比完備的功能更重要：GroupOn最早不過是搭建在WordPress上的幾個頁面，而阿里巴巴網站最初也不過是一個論壇，你又何必等到所有細節都打磨好呢？
擁抱開源技術，避免過度炫技，如果技術型團隊創業（做互聯網），這兩條都能堅持的話，我想你已經抓住了問題的80%的部分，基本上你不會做太多的無用功。
另外，剛啟動時不要直接招技術總監、技術經理、架構師這些看起來級別很高的人，因為他們未必認同你的想法和你現在的團隊。建議找能實現你產品想法的人。最后有一點必須要說一下：不要因為一個人的技術喜好而舍棄整個技術團隊，在任何時候這都是很愚蠢的事情。
作者馮大輝，丁香園網站CTO
在重大產品決策或者大規模應用開發前一般需要進行技術選型，其目的是為了降低產品研發的技術風險。所以首先需要明確為什么需要技術選型、需要達到什么目的，整個過程需要有一套的組織流程來保證。
一般可以將整個過程分為調研、候選對比、關鍵技術驗證、原型驗證幾個階段。在調研階段主要調研對象是目前該范圍業內主要產品以及開源產品，需要了解其主 要技術特點和各自的優勢和劣勢；在候選對比階段，是在前一階段基礎上選出兩種傾向用于最終路線的技術進行進一步的研究和對比。在關鍵技術驗證階段，需要列 出所有的技術驗證點，對驗證點描述、驗證方法、驗證步驟、驗證前提、驗證環境以及最后的交付物和評估方法指標在驗證方案中體現；在原型驗證階段，主要是針 對重點關注的場景，通過一個原型來整體驗證比較。在這個階段一般需要進行概念模型、編程模型以及結構設計例如設計時視圖、系統結構圖等，定義需要的 API，必要時還需要劃分子場景，在場景中包括場景描述、Feature、預研點以及相關設計。
當然也需要對人員角色進行分工，一般劃分程序經理、開發人員、測試人 員幾種角色。程序經理需要確定原型目標范圍，編寫原型目標文檔并組織評審；制訂和跟蹤原型開發計劃，對原型進行驗證，確保原型符合原型目標要求。開發人員 需要從開發角度提出原型需求，評審原型目標文檔，按照原型目標文檔和原型開發計劃完成原型相關設計和開發。測試人員需要Review原型目標文檔，根據原 型目標文檔采用一定的測試手段驗證原型是否符合原型目標要求。
在最近我們進行的ESB新產品中，就采用了類似上述的流程。我們確信技術 選型的最主要目標是要自主掌控，所以從非常底層的技術開始，重點關注并發、資源隔離這樣的目標，解決在不確定環境中實現交易控制和可擴展的目標。所以我們 設計了一個三段式的SEDA架構，基本原則是要實現架構的資源可分配性，提升吞吐率，當然最初實現的功能可以比較簡單。通過上述流程，有效保證了我們在新 產品研發過程中的效率和產品架構質量。
最后，在技術選型產出物上，一般的結果可以有三類，有馬上轉化應用的新產品，也可以是結合現有產品的一個解決方案，或者是某個方面的一個提升點（如一個新的組件）。
作者馮興智，普元信息資深架構師
關于公司/團隊技術選型的話題涉及到很多非技術層面的問題，特別是大公司在技術選型方面，不可避免要受到企業官僚的影響。
下面我結合自己公司的實際情況，談談初創企業或小型開發團隊的技術選型。技術選型涉及產品/項目開發流程中各個環節所用到的工具和技術。例如項目開發前期的需求收集、整理分析工具、開發階段的IDE和版本控制系統、測試階段的測試工具等。
我們作為初創企業在進行技術選型時會根據產品的需求、技術的復雜性、可擴展性、跨平臺可移植性以及成本來做出最終的決策。
成本因素
初創企業的資源特別是資金往往不是很充裕，如果采用商業化的技術解決方案，往往價格不菲，像Visual Studio專業版、Windows Server、SQL Server的價格動輒上萬，這種情況下不妨考慮一些免費開源的技術框架。比如使用SharpDevelop代替Visual Studio，MySQL代替SQL Server。此外，也可關注并加入一些針對初創企業的扶植計劃。例如我們創業前所工作的公司采用的都是微軟技術，大家對微軟技術掌握得很熟練，這樣自己 成立公司開發自己的產品時同樣優先考慮微軟技術。我們通過加入微軟的BizSpark計劃，有效降低了成本。
復雜性，成熟度
我們在做技術選型時最忌諱的就是盲目追崇新技術和框架。有些技術剛剛面世不久，還沒有成熟的社區支持和成功案例。如果這時為了趕時髦或者在產品 的推廣宣傳上加點花頭而采用新技術的話，往往會導致項目陷入泥潭。采用不成熟技術而導致失敗的案例比比皆是，如網景在Java剛面世不久就使用Java重 寫Netscape Navigator瀏覽器，導致用戶體驗大幅下降及用戶群的流失。還有當時被稱為下一代Windows客戶端技術的WPF，到現在發展得仍然不瘟不火，如 果僅僅是為了更炫的展現效果而使用WPF，結果肯定會得不償失。
產品自身因素
技術選型不可避免地要以產品為中心。如果產品是Windows智能客戶端軟件，那么微軟的技術框架必然成為優先考慮。如果開發Android軟件，Eclipse和Android SDK同樣必不可少。
作者石鈺，奈特軟件聯合創始人、首席架構師
我在微軟和騰訊從事了三年的軟件測試和團隊管理工作，期間涉及兩大類的研發工作：第一，用于質量控制的各種平臺系統，例如缺陷管理系統、用例管 理系統、產品健康指數可視化系統、自動測試管理系統等；第二，用于具體的產品測試工具，例如桌面軟件的UI自動化測試工具、JavaScript自動化測 試工具、Web服務壓力/性能測試工具等。
在團隊的建設和技術選型上，遇到過一些困惑也走過一些彎路，總結出來有兩點經驗。
閱讀公司文化，借鑒成功團隊經驗
測試團隊一定要深刻閱讀和理解公司文化，作為其技術選型的首要考慮因素。比如，在微軟，無論是構建質量控制系統，還是開發各種產品測試工具，都以Windows+IIS+.NET作為技術框架；在騰訊，就會選擇LAMP這樣的開源技術框架。
在選定了技術框架的基礎上，還面臨一個問題，就是應該如何去設計和實現出具體的系統或者工具。一個非常重要的經驗就是一定要借鑒成功團隊的經 驗，站在巨人的肩上。例如，當初在騰訊，我們需要評測QQ地圖的POI檢索功能的質量和用戶滿意度。于是，我們花兩周時間設計了一個自以為完美的盲測系 統，結果在評審時才發現該盲測系統功能過于簡單而且性能達不到指標。后來，我們在與騰訊SOSO團隊討論時，才發現他們經過多年的研發，已經有一款非常完 善的搜索盲測系統，直接借鑒過來，就能很好地解決項目測試的問題。這點特別是對很多新任命的團隊負責人，是很重要的經驗。
敏捷務實，持續集成，切勿過設計
工程的基本要素是實用和強調執行力。對于一個軟件/互聯網企業或者團隊而言，最重要的是先解決眼前遇到的具體問題，而不是盲目追求系統的擴展性 和性能。例如，我們在測評QQ地圖后臺服務的性能狀況時，首先想到的是選用的測試方案要具備良好的功能特性，可擴展性要強、足夠開放，能夠與已有的一個研 發管理系統做集成。按照這個標準，我們選擇了LoadRunner，這是一個比較復雜的工具，光配置就花掉了大量的時間。結果，導致實際測試的時間太靠 后，發現的性能問題都無法在即將發布的版本中得到修正。這就是一個非常典型的因為過設計而引發的技術選型耽誤工程進度的例子。后來，我們選用 http_load這個開源、簡單、實用的工具對后臺服務做快速的壓力測試，從而在第一時間得到測試報告。然后在沒有測試任務的時候，花時間將該工具集成 至研發管理系統中，做到了持續集成。
其實總結起來，測試團隊的技術選型首先要順應公司的框架性要求，然后在具體實施過程中，要以解決問題作為決策目標，多向成功團隊取經，敏捷務實，切勿過設計。
作者劉舒，阿里巴巴高級產品經理，曾任微軟測試開發工程師、騰訊測試經理
轉載自：http://www.programmer.com.cn/8514/