城速遞那麼快捷一個下午就到達目的地。很多大學的孵化中心就是一種型別的技術轉移過程。這裡說說微軟研究院中一個典型的軟體技術轉移的過程：
1。 研究組選研究題目。這個題目可能是領域內長久的研究方向，希望可以得到某些突破，或者是來自與已有產品的問題。
2。 研究員深入分析問題，設計演算法，構造原型系統，收集資料，選擇演算法，評估結果，不斷迭代嘗試。
3。 當原型系統顯示有能力解決問題的時候，我們開始與相關產品部門接洽技術轉移。研究部門有專人負責與產品組的資訊溝通。同時我們也可以得到產品組對我們結果的反饋意見。
4。 當原型演算法的質量到達相當不錯的階段，產品組看過後便有了更有明確的需求。RSDE開始和研究員成立一個臨時的虛擬小組（virtual team，有別於平時的管理組）一起工作，進一步提升原型系統的設計和質量以達到產品組的要求，研究員、產品組的專案經理、開發工程師、測試工程師一起工作，最終把演算法程式碼實現寫入到產品組的程式碼中去。
5。 最終產品釋出。到了這個時候，參與專案的人會得到一個石頭或金屬嵌玻璃的獎牌（Ship…it Award），上面寫著“感謝xxx對xxxx產品做出的貢獻——比爾·蓋茨”。
這是一個相當明確的流程，而現實常常出乎意料，任何一步都不是那麼簡單，而是變數叢生、繁複無比。產品部門的要求來自與市場，通常期望值很高，可這時往往暴露了研究階段成果的一個問題，那就是——研究成果和產品要求的差距。
不是所有的研究專案都會成功產品化，為了提高研究的效率，通常當一個演算法解決了問題的主要方面就可以開始向產品部門推銷了。當“買方”對演算法結果基本認可並有意向整合之前，會提一系列的具體要求，希望演算法可以達到產品標準。很典型的要求比如是否能夠能否達到99％以上的正確率，融入產品已有架構的容易程度，演算法複雜度、實現的速度、資料適應性、資源記憶體消耗、安全性、可靠性、等等。我們在這些方面有過不少坎坷。
例如我們做人臉卡通，第一步在是使用者輸入正面肖像照輸入後自動的配準面部五官，然後再繼續後續步驟。最初的的演算法在亞洲人的照片上可以工作得很好，可是產品組要求演算法必須在世界其他國家市場上要正常工作。這就帶來了新的要求，必須考慮世界上其他人種的膚色、髮色、眼睛鼻子大小。新的要求導致了資料和演算法上的很大改動。
當一項技術是“基本可用的”，假設它已經達到80％的產品要求，而產品的真正要求是“非常好用”，可能意味著90…99％，產品組的眾多要求累積在一起，這之間將近20％的距離往往就是發生量變到質變的那一段。這常常意味著演算法要做相當的調整和適應，甚至結構需要大修改。RSDE的典型技術轉移工作就在這20％的一段。這個象“&”一樣擰吧的階段，我們要和研究員開會，學習他們的東西，出差去總部和產品組面談，或者每天大早起床趕時間與總部開跨16個小時時區的電話會議，與產品的開發測試工程師一起工作，共同努力讓一項研究技術完美地實現使用者需求。
研究是高風險的事情，能夠變成真正產品的研究只是成功的極少數。很多專案就在這個階段前不幸夭折了。長江後浪推前浪，死在沙灘上的前浪研究專案的數量相當可觀。這個艱苦的過程，難的不光是技術，還有在長長的辛苦、燒掉無數腦細胞之後卻要接受專案無果而終的現實。txt電子書分享平臺
研究院“&”的故事 陳剛（3）
所以每當有一個技術轉移專案順利完成時我們都很興奮。當我們收到一份產品組高階經理的感謝信，還有看到好久不見的同事從總部出差回來挺著腰圍暴漲了一圈的肚子時，就會上前恭喜他，然後和他一起抱怨總部的中餐館的菜真油，公司樓下的食堂Pizza吃得太多了，Ship…it Award獎牌的玻璃太難看了……
我們說研究院是幫助公司賺後天，甚至5年以後、10年以後的錢。從我們的經驗看來，做技術轉移，過程有長有短，3個月不算短，5年也不算長。這從另一方面驗證了關於這個時間的說法所言非虛。如同任何一件事情的成功，必須努力也要有運氣，是天時地利人和的結果。
技術轉移過程也是一個人與人、機構與機構之間互動、互相支援和取得信任的過程。研究院成立之初做研究專案推廣的時候，研究院對產品組的周