技術研究與工程開發

2021-05-12 19:48:49 字數 1462 閱讀 4436

一、r&d概念的分拆

搞研發的掏出名片來一般會印上這麼個部門:r&d。所謂r&d就是research & develop,研究與開發,所以簡稱研發。我曾經碰到個高人,強調把這兩詞拆開來單獨理解。「研究」就是把乙個團隊知識之外的知識點弄懂,引入專案中使用;「開發」就是把已經明白的東西做出來。

二、為什麼多數程式設計師更喜歡搞研究我也遇到過某些比較特別的、喜歡做重複性勞動的、喜歡在已知領做工程開發的程式設計師,實際上這些程式設計師沒有很好的職業素養,而且基本都缺乏上進心,朽木不可雕也。

三、重研究輕開發的中小型團隊多數下場悲哀

但對於中小型團隊,尤其是創業階段的團隊,如果只做開發而不做研究,運氣好還能苟延殘喘一陣子,養活團隊估計還沒問題;而側重研究而沒有開發,絕對是死路一條,結果就是工程師做完研究,砍完大boss獲得經驗值和等級的快速提公升(我稱為「鍍金」)完畢後,已經把投資人的錢燒光了,留個廢品給投資人,然後各自高飛。

比如乙個創業階段的小團隊想做個很炫的ui框架能和iphone媲美;或者想自己做個3d遊戲引擎;或者想做乙個向量地圖引擎。不僅多數程式設計師喜歡砍這種高經驗值的大boss,投資人也很難擋住這種**力。但如果不是在該領域已有很深厚的積累,而是在只掌握了一二成核心技術的情況下去做這種研究,試圖把這種高風險專案做出來以獲得高回報的話,那基本上等於找死。高度研究型專案對於中小型團隊來說,就是投資人的高風險,程式設計師的高回報。

四、研究和開發的資源布局

既然是r&d並提,說明兩者基本上密不可分。做軟體不可避免地、或多或少都會有研究的成分,而不純粹是工程開發。所以出現下面兩種資源布局:

(1)有的公司是把研究和開發任務混在一起,平均分給每個工程師;

(2)有的公司則把兩者割裂開,有專門的精英團隊做研究,有專門的工程團隊做開發。

有些軟體團隊會有這樣的追求:少數幾個大牛搞定乙個開發框架,然後用月薪兩三千塊錢大量招「**工人」進來,快速開發出客戶需求。這是一種「軟體流水線化生產」的思路。當我們把這種軟體公司的模式比作「中國製造」的時候,就發現這很有趣。這種模式在國內做企業開發(erp、crm、oa等)和網路遊戲開發的公司中被廣泛採用,實際上就是上面所說的第二種方式,建立兩個團隊分別做研究和開發。

這兩種方式都有利有弊,前者會把核心人員浪費在體力活上,但有利於團隊的「和諧穩定」以及從外圍人員培養出新的核心成員;後者的組織效率會更高一些,但是由於階級化明顯,做工程開發的外圍團隊人員流失率會比較高,也不利於培養核心成員出來。

所以我認為,對於乙個想獲得成功的研發團隊而言

(1)要想清楚研就和開發的投入比例。用雖然笨拙的已知方法替代對未知的、高效的、很酷的未知方法,在很多時候是必要的。專案風險必須處於可控範圍內。我見過個資料,軟體專案中的未知核心技術如果能佔所需核心技術的20%以下,那麼這個專案的成功率會大大提高。當然,這個也和行業領域的特點也有關係。

(2)要想清楚如何分配研究和開發任務。如上面所說,是分拆成兩個團隊單獨做,還是把任務混合後平均地分配所有工程師。

技術研究與工程開發

一 r d概念的分拆 搞研發的掏出名片來一般會印上這麼個部門 r d。所謂r d就是research develop,研究與開發,所以簡稱研發。我曾經碰到個高人,強調把這兩詞拆開來單獨理解。研究 就是把乙個團隊知識之外的知識點弄懂,引入專案中使用 開發 就是把已經明白的東西做出來。二 為什麼多數程式...

AOP技術研究 引言

1 引言 軟體設計因為引入物件導向思想而逐漸變得豐富起來。一切皆為物件 的精義,使得程式世界所要處理的邏輯簡化,開發者可以用一組物件以及這些物件之間的關係將軟體系統形象地表示出來。而從物件的定義,進而到模組,到元件的定義,利用物件導向思想的封裝 繼承 多型的思想,使得軟體系統開發可以向搭建房屋那樣,...

引擎技術研究之Shader技術

shader 技術屬於 gpu的渲染技術,其相應語言是高階著色器語言 high level shader language 簡稱hlsl hlsl 主要作用為將一些複雜的影象處理快速而又有效率地在顯示卡上完成。在 directx 中有兩種 shader 頂點著色器 vertex shader vs ...