一、研發管理面臨諸多問題及解決思路
在與企業交流時，常聽到一句話：研發管理問題很多、很難管！比如研發專案經常延期，研發部門經常被生產、銷售等上下游部門抱怨：
「他們做的產品根本沒法生產，研發喜歡閉門造車，產品很難賣……」，研發人員的績效難以考核，研發人員難以培養、研發人員如何配置才合理等等。作為乙個研發管理者，在面對這些問題時，往往會產生一種無從下手的感覺。
研發管理也是一種管理，既然難管，那就說明有很多東西還沒有理清、沒有理順。面對這麼多的問題，從何下手才比較容易解決呢？
首先，我們可以將研發管理者面臨的問題進行分類。通過對研發管理問題分類，我們可以發現研發管理者面臨的問題主要有以下幾類：研發專案管理類問題，研發流程管理類問題，研發績效管理類問題，研發人員培養類問題，研發組織類問題。
其次，找到這幾類管理問題的內在關係。通過對這幾類問題進行分析，我們可以發現，研發流程管理與其它管理類問題都有著直接的關係：流程管理都是其它幾類管理的輸入、是研發管理的基礎。
最後，抓住研發流程管理，以此為切入點和主線，促進研發管理工作的整體改進與提公升。
下面，我們著重闡述研發流程管理與研發專案管理、研發組織管理、研發績效管理以及研發人員培養之間的關係。
二、通過研發流程優化促進研發專案管理改進
研發專案嚴格的說應分為技術研發及產品開發兩類，但為了便於說明，本文所提及的研發專案僅指產品開發類專案。研發專案管理的內容很多專業的書籍及文章都有詳細的講解，在此就不再表述。
作為一名研發管理者或研發專案經理，他們經常會遇到各種各樣的的研發專案管理問題，但比較重要的也就就是以下幾類：
● 研發計畫問題：研發計畫不准、計畫缺乏有力的監控、計畫經常延期；
● 研發質量問題：研發專案質量管理缺乏過程監控，經常返工，新產品問題較多；
● 研發組織與溝通問題：專案組成員之間，以及專案組與職能部門之間溝通不暢、常出現推諉、扯皮現象；
● 研發成本問題：專案成本經常超預算。
造成研發計畫經常延期的問題，其根本原因主要有兩大類，一類是計畫本身就不準確，往往是過於樂觀（對需求變更及專案風險考慮不足），計畫延期也就難以避免。另一類是計畫本身沒有什麼問題，但是計畫的資源（比如人手）不能及時到位。這兩類原因中，往往是由於第一類原因造成計畫延期的比較多。
那麼為何研發計畫總是不準確呢？回答這個問題之前，我們可以先看看我們是如何做研發專案計畫的吧。很多企業的研發專案計畫大都是某個人（一般是專案經理），根據上面的產品上市要求，結合以往的經驗，在頭腦裡快速的估算出來的。
這樣做出來的計畫，其準確性也就無法保證了。那麼如何提高計畫的準確性呢？首先，研發計畫人員必須很清楚的知道本專案要走的產品開發流程是什麼（並不是每個產品開發專案都走同乙個產品開發流程的），每個子流程是什麼，每個活動（要分解到一周或每天）由不同的人（具體到人）去做，分別需要多少時間。
其次，還要依據流程以及以往經驗，對流程中可能會出現的風險進行評估，預估處理風險的工作量及時間。換而言之，研發計畫要嚴格依據產品開發流程去層層細化、估算、並充分考慮到風險處理時間。這樣做出來的計畫，其準確度自然就會比拍腦袋出來的計畫要高的多。
而要做到這一點，就需要有乙個順暢、規範的產品開發流程體系，這就是研發流程優化及管理的工作了。
造成研發質量問題的原因可能會比較多，但也不外乎人、機、料、法、環等方面。而這五個方面，恰恰又都是我們流程優化及管理要考慮的基本要素。同時研發質量管理更需要事前的預防以及過程的監控。
要做到事前預防，就必須知道每個產品開發分別要走那些流程，每個流程中那些環節或活動經常會出質量問題，只有事前了解到這些薄弱環節及風險點，我們才可能做出相應的質量管理計畫，並依據質量管理計畫及流程，在產品開發過程中設定相應的監控點，以便更有效的對產品開發過程進行監控。要做到這些，也必須有乙個規範的產品開發流程體系，而這也是研發流程優化及管理的工作內容了。
造成研發專案溝通問題的主要原因是：研發專案組及職能部門的職責不明確，溝通渠道不明確。有不少企業，到目前為止，還認為產品開發僅僅是他們技術部門的事情，與市場、生產等部門無關。
在這種觀念的誤導下，研發專案組幾乎是清一色的技術人員，這樣一來，產品開發過程中的溝通無疑就會變得很困難，因為大家都在想：「我是在幫他們技術部門做事情，有時間就配合一下，沒時間也就沒辦法了」。而造成這種錯誤的想法，主要根源是只看到了職能部門的職責而沒有看到產品開發流程對各部門的要求。
只要通過流程梳理與優化，我們就可以很清楚的看到，產品開發絕非是技術乙個部門的事情，他需要市場、銷售、生產、財務、質量等部門參與，並在產品開發過程承擔著各自專業的職責。比如市場要承擔著市場需求分析及驗證的職責，生產要承擔著可生產性需求分析、產品工藝方案設計、樣品生產等專業職責。有了各部門在產品開發中的明確定位與職責，產品開發中的推諉、扯皮現象就會明顯減少。
實踐證明，通過持續的流程優化及管理工作，研發專案管理的計畫管理、質量管理、組織與溝通管理以及成本管理水平就會不斷的得到提高。
三、通過研發流程優化促進研發績效管理改進
眾所周知，研發工作結果不像銷售及生產等工作那樣容易被量化，所以研發績效考核工作也是每個研發管理者很頭痛的事情。如何才能更有效的、更客觀的考核研發人員的工作績效呢？
其實，績效考核的出發點很簡單，那就是我需要你貢獻什麼，我就考什麼。所以，要想提高研發績效考核的合理性及公平性，就必須要知道每個研發崗位在技術研究及產品開發中都介入了那些具體的流程、每個崗位在介入的流程中承擔了那些關鍵的活動以及每個關鍵活動的對每個崗位的價值貢獻要求（輸出要求）是什麼。
那麼，怎麼才能很清晰的知道每個研發崗位都介入了那些流程以及每個研發崗位的價值貢獻呢？這就需要我們對研發流程體系進行梳理及優化。通過對研發流程體系的梳理，我們就可以明確每個研發崗位應該需要貢獻什麼價值。
例如，a公司通過對其軟體開發流程的梳理及優化，發現軟體開發工程師不僅僅是要按計畫進度完成**編寫，更重要的是要按要求做好軟體開發及測試等相關流程中的關鍵活動的輸出，比如模組的需求分析、模組的方案設計等。在明確了軟體工程師的這些關鍵活動及其輸出要求後，就可以很清晰的明確其價值貢獻，那就是對軟體系統中的模組成功實現負責。依據這一定位及流程要求，不僅要考核其開發計畫的達成率，還要考核其模組評審一次性通過率、模組/**重用率等過程指標，這樣不僅可以提高kpi的量化比率，而且還可以加強對軟體開發過程的管理，提高研發績效考核的合理性，從而提高軟體開發的效率與質量。
所以，通過持續的研發流程梳理及優化，可以不斷提高研發績效管理水平。
四、通過研發流程優化促進研發招聘與培養管理改進
很多企業都感嘆：研發人員太難招了！研發人員難招，可能會有多方面的原因，但有一點原因，我們往往會忽視，那就是我們自己對要招聘的研發崗位的定位不清，導致要求過高。
例如，有一家軟體企業（a企業），研發部門讓他們的人力資源部給招聘乙個軟體開發工程師，要求既要又3年以上的程式設計經驗，要懂vc、vp等多種程式語言及工具，又要有2年以上的需求分析以及架構設計工作經驗，結果招了1年，也沒有招到。其實，這樣的結果早在他們的人力資源部的意料之中。原因很簡單，做需求分析及架構設計的人認為，如果我去了，以後還要做大量的程式設計工作，對我而言是一種浪費、也不會有更好的職業發展，所以他們是不會去應聘的。
而對程式設計人員來說，他們又達不到招聘要求，想應聘，也沒有機會。後來，我們在為其做流程優化時，建議將軟體工程師的崗位職責定位為程式設計以及模組級的需求分析（系統的需求分析及架構設計則由系統設計師去負責），招聘要求修改為3年以上的程式設計工作經驗，有過5個以上模組專案需求分析及設計經驗，掌握常見的需求分析及程式設計工具。很快，他們便招聘到了合適的軟體開發工程師，不久也招到了系統設計師。
招聘到了研發人員，接下來就是要對研發人員進行培養了。現在，有很多企業的研發管理者都為研發人員成長慢而發愁。究其原因，主要是企業對研發人員的培養缺乏系統性和針對性，表現在對研發人員的培養方式及手段單一，培訓課程設定缺乏針對性。
造成這些問題的原因可能是多方面的，但是，我們認為有乙個主要原因是由於企業忽視了研發流程建設所造成的。很多企業由於沒有規範的研發流程體系，產品開發的經驗教訓都在研發人員個人頭腦裡。這樣以來，對新來的研發人員來說，就缺乏乙個系統的培訓教材，要想進步的快，就只有靠自己不斷的去摸索或不停的去問「師傅」，而不停的去問「師傅」，則往往勢必會影響到師傅的工作，所以這種學習方式的效果會參差不齊。
如果，企業有由研發骨幹編制的研發流程體系，這樣的結果就不會出現。
另外，很多企業每年都會為研發人員安排很多培訓，但反饋往往都是缺乏針對性。原因是什麼呢？原因就是培訓需求不明確（不僅僅是培訓部門對培訓需求不明確，就連我們的研發部門自己有時候都說不清）。
那麼，怎麼才能明確培訓需求呢。其實很簡單，就是對研發流程進行梳理，通過研發流程梳理，我們可以很清楚的發現，目前那些流程有問題（比如需求分析），那些活動有問題（比如需求評審走過場，沒有起到把關的作用），以及這些問題的原因。相信這些問題的原因裡，一定會有一類原因是由於相應的角色缺乏相關的能力。
至此，我們的研發培訓需求就會明確，明確了培訓需求，培訓的針對性及效果就會得到改進。
五、通過研發流程優化促進研發組織管理改進
隨著研發規模的擴大，很多研發管理者就面臨著如何合理設定研發部門以及研發崗位的問題。要想合理的設計研發部門及崗位，就需要對研發過程的工作進行分類，依據不同類別的研發工作需求來設定不同的部門及崗位，所以對研發流程的梳理及優化是必須要做的功課。正如上例中的a企業，我們通過對其軟體開發流程梳理、分析發現，他們目前將需求分析及系統架構設計全都交給軟體開發工程師乙個崗位去做，結果經常出現由於需求分析不充分、不完整，而導致後期經常返工，而且也多次出現過由於系統架構設計問題到導致後期的「大返工」或致命的問題。
通過流程優化，我們建議將軟體開發工程師的工作進行分類，需求分析及架構設計類工作是屬於創造性的非操作性工作，而程式設計工作則屬於非操作性的操作性工作。所以，建議將軟體開發工程師崗位拆分為軟體工程師及系統設計師2個崗位。
通過研發流程梳理與優化，還可以進一步明確各職能部門在產品開發中的定位及職責，有效的打破「部門牆」，從而構建乙個與市場驅動的端到端的流程相匹配的研發組織架構，以快速的響應市場。
通過上述的分析，我們可以很清楚的看到，研發流程管理就是研發管理的基礎工作，是研發管理的一條主線，只要我們抓住這條主線、並對研發流程進行持續的優化，那麼研發組織管理、研發專案管理及研發人力資源管理的問題也就迎刃而解了，研發管理的水平也就會不斷的得到提公升。
軟體研發版本管理制度
本文件是為規範軟體研發版本管理而制定的。版本標識方法 軟體系統資料的存放 文件的修改控制 文件的備份制度 svnsvn是乙個開源的版本控制系統subversion的簡稱 文件 一種資料 和其上所記錄的資料。配置管理 標識和確定系統中配置項的過程，在系統整個生存週期內控制這些項的投放和更動，記錄並報告...
軟體研發面試題
2 從以上分析可以看出，把區域性變數改變為靜態變數後是改變了它的儲存方式即改變了它的生存期。把全域性變數改變為靜態變數後是改變了它的作用域，限制了它的使用範圍。3 static函式與普通函式作用域不同,僅在本檔案。只在當前原始檔中使用的函式應該說明為內部函式 static 內部函式應該在當前原始檔中...
軟體研發面試題
2 從以上分析可以看出，把區域性變數改變為靜態變數後是改變了它的儲存方式即改變了它的生存期。把全域性變數改變為靜態變數後是改變了它的作用域，限制了它的使用範圍。3 static函式與普通函式作用域不同,僅在本檔案。只在當前原始檔中使用的函式應該說明為內部函式 static 內部函式應該在當前原始檔中...