在團隊中，研發(fā)團隊都在想辦法提高研發(fā)效率，可以快速搶占市場，快速降低成本。這篇文章，我們來看看為什么要提高研發(fā)效率的分析。

研發(fā)效率為什么總是慢？

開發(fā)資源怎么總是不夠用？

是不是哪里從一開始、從所有人就出錯了？

一、為什么產品研發(fā)都要特別重效率？

任何研發(fā)團隊，大概率都在絞盡腦汁想要提高研發(fā)效率，與時間賽跑，搶占短暫的市場高光窗口期、甜蜜空白期；資本或者vp圈的增長預期壓迫；研發(fā)這個高成本的團隊組織，不論從時間角度、成本角度上都要求必須研發(fā)需要高效運轉起來。

二、快砍需求！提升研發(fā)效率

往往我們會因為研發(fā)效率的提升應該從需求管理入手，懂得“砍需求”，砍掉不必要的、沒有性價比的、非真相的需求，抓住關鍵路徑上的高價值需求，這樣子我們就都是在做高價值的事情。

這當然是需要的，是產品經理團隊、開發(fā)團隊都應該考慮的最基本的事情，可事實是大家仍會發(fā)現(xiàn)，為什么還是出現(xiàn)了研發(fā)效率低下呢？資源總是不夠用，總是追著業(yè)務走。

三、換成發(fā)展視角再看研發(fā)效率

長焦變短焦，看更大的視野，我們很簡單的看到，一個支持用戶進行價值交易的產品，除了成品的皮膚、功能框架、產品邏輯、產品架構，背后更有技術架構。而技術結構并不是一開始就會有的，跟產品架構類似，開始的時候，沒有架構，都是為了滿足直接的業(yè)務需求，走著走著生態(tài)在變，架構也就需要逐漸形成。

技術架構、產品架構他們都有共同的基準對象，就是業(yè)務架構的發(fā)展性，外部環(huán)境和約束的變動，導致業(yè)務發(fā)展的不確定性，從而驅動要求不論是組織結構還是信息化結構的同步迅速調整。

用戶規(guī)模、市場規(guī)模、產品功能規(guī)模不斷變化，技術架構也同樣需要跟著生態(tài)來成長甚至重構，不然怎么支撐不斷龐大的產品架構。這時候，想一想，自己團隊規(guī)劃代碼重構、技術重構是多久前的事情了。

四、藏在水面下的效率阻礙冰山

矛盾的地方在于，往往產品的功能框架、產品架構的升級是比較顯性的，在業(yè)務上、管理者視角上，是和團隊主價值鏈條直接相關的，也是更加緊迫的。必然不斷導致，技術話語權被壓制，疲于奔命的應對滔滔不絕的需求迭代，根本無暇考慮代碼/技術層的優(yōu)化。更時有發(fā)生的情況是，在破爛不堪的代碼基礎上，繼續(xù)承接新的需求，硬著頭皮構建這棟搖搖欲墜的大廈。

短視的行為必然是，每個產品經理也都為了自己顯性的產品成就和表現(xiàn)，哪管開發(fā)者的技術架構，恨不得24小時讓程序員coding。這種做法很討喜，管理者甚至認為這是個得力的助手，能夠有效的推動項目的進展。很多簡單的事情，這個時候變得迷霧重重，無人看清，嘆息：可能團隊里的vp也需要表現(xiàn)吧！

然而，技術的重構和產品的成長必然是雙螺旋結構，加上市場/商業(yè)，形成三螺旋合力一股繩。產品需要關注自己所依賴的強健的技術架構，技術結構背后也需要穩(wěn)定的it架構。它們的前提又需要有清晰耐打的業(yè)務架構做支撐。

工欲善其事，必先利其器，可是有多少大廠中廠小廠、有多少人愿意花時間去磨刀呢？

產品經理們，你們一定要對開發(fā)者好一點，給他們主動擠出時間做技術的升級，和諧團隊不說，產品也獲得了健壯的技術架構支撐。