研發效率是在現代企業都關注的，注意是因為靠譜的工程師是有限的，而且軟體工程師的人力成本較高，時間成本更高，在大多數情況下，軟體工程是一個團隊活動，通過協作實作突破，好的想法從不匱乏，但高速執行卻不那么容易，高效團隊會習慣于更高的標準，當研發速度停滯時，人們會創造性地尋找重建高速產出的方法，但是如果長時間停滯，也會造成人員的流失，
如何提升研發效率呢？或者說，研發速度是否可控呢？
高效的目標——方向
速度是位移和時間的函式，很多時候，位移方向的目標更容易被忽視，然而，專案失敗的最常見原因是團隊構建了錯誤的東西，“繞樹三匝，何枝可依，”，實際上，方向錯了，停止就是進步，
確定方向本身就是很困難的事，例如預測產品或市場匹配度等，通常需要關注客戶的聲音，成功不是提供一個特性，而是學習如何解決客戶的問題，理想情況下，我們希望傾聽客戶的意見，滿足他們的需求，同時只發布他們最感興趣的那20% ，
即使那些所謂具具遠見的創新者，也很難預測客戶到底需要什么，由于在選擇方向時需要一些猜測，因此系統的靈活性和可擴展性就變得至關重要，靈活性可能表現為開放性，最大限度地提高試驗的速度，減少對給定計劃的承諾，快速發展的產品，以及在決策中區分可逆和不可逆的功能特性，盡管，可擴展性使犯錯的代價比想象的要低，而“time to market”則肯定是昂貴的，
高效的感知——度量
有很多人嘗試直接觀察軟體團隊的研發效率，但眾所周知，這樣的測量是非常困難的，為了彌補這一缺陷，企業會使用員工參與度來調查與研發效率相關的問題，這樣的調查往往局限于對員工參與度和與公司目標一致性的高層次衡量，這也是OKR模式的輔助手段，利用這些調查來決定是否實作了高速迭代，詢問工程師實際花費了多少時間來設計和撰寫代碼，工具是否充分，程序是否有效，以及技術債務的影響等，
在著手進行這類問題的調查之前，一般會承諾根據調查結果采取行動，以便這些行動對目前的調查和今后對這類調查的答復產生積極影響，
高效的組織——自治
可擴展性可以通過自治團隊來改進，這些團隊圍繞著有良好邊界的特定責任區形成高度的內部凝聚力，團隊所負責的服務彼此公開API; 在理想情況下，不存在跨團隊溝通，因為與業務邏輯互動所需的全部都是API，而業務邏輯是業務團隊的責任，
服務的實作細節通常是不共享的，并且不存在對遠程服務所依賴的資料存盤進行私有訪問，即使服務需要不前向兼容，API的新舊版本仍然通常會在重疊的一段時間內可用，因此業務可以在舊版本被棄用之前進行遷移，
服務的擁有者可以按照團隊自己的速度發展并發布變更，獨立于可能發生的其他變更，并在時間上與其脫鉤，這就是所謂的“無許可創新”，然而，確定責任領域之間的介面是具有挑戰性的，這些介面會不可避免地隨著時間的推移而演變，完美的自治永遠是虛幻的，
一組軟體服務不斷進化，就像一個鮮活的生命，發布新的介面，整個服務可能分離或合并，單個服務可能經歷重大的重新設計或被棄用，理想情況下，內部團隊擁有高度的自治，在組織結構上與“高內聚、低耦合”的軟體設計原則相一致，
基于康威定律，這些團隊提供的服務應該是獨立的，理想條件下，不需要對所依賴的服務進行任何更改，任何團隊就可以實作80% 的任務，在剩下的20% 中，通過特定的介面實作，
在符合研發路線圖的情況下，服務擁有者會同意那些有意義的變更，但是在路線圖上的優先級較低，這時，業務方可能會提供一個“援助團隊”來實作所請求的更改，援助團隊由來自業務團隊的開發人員組成，這些工程師臨時加入擁有服務的團隊，設計、測驗、編碼和發布都需要服務擁有者的逐步批準; 當完成更改后，援助人員將回傳到他們原來的團隊，這個方式的一個附加價值是交叉授粉，在團隊之間缺乏溝通的情況下尤其有效，
高效的方式——敏捷
產品開發的敏捷方法可以迭代和速度之間做平衡，
即使在需求快速變化的世界里，團隊井然有序的積壓作業也是可以的，只要最新版本用于sprint即可，團隊明確承諾從待辦串列中完成一系列任務，而作為回報，則是團隊獲得了一個不可中斷的受保護時間視窗，這是一個盡可能快速作業的沖刺，在完成這個不間斷、無波動的幸福周期之后，sprint 的成果將展示團隊履行的承諾，
在下一個 sprint 計劃會議繼續之前，團隊將進行回顧，這是一個內省會議，其中團隊評估其達到的速度，并確定在隨后的sprint中提高速度的方法，一個誠實的回顧，建立在信任和自我意識的基礎之上，可以找出在進入下一個sprint之前如何“提高研發效率”，
高效的條件——專注
專注是實作高效研發的必要條件，
團隊希望專注于解決客戶的問題，高速實作所責任的業務邏輯，他們不希望不能控制自己的團隊，可靠的基礎架構和基礎設施是無許可創新的助推器，更是是軟體架構轉變的推動者，勿在浮沙筑高臺，不為繁華易匠心，
高效的土壤——文化
一個高效團隊注重培養一種文化，這種文化鼓勵團隊成員高效交付成果，這是一種自我強化，具有高效文化的團隊往往能夠吸引到高手，重要的是，要假定團隊成員是有才華的，與使命保持一致，并且希望高效作業，文化中對研發效率產生積極影響的方面包括: 多樣性和包容性、謙遜、信任、樂于學習、愿意帶著“緊迫感和重點”前進、自主性以及集體承諾取得成果的意愿等等，
高效的實作——工具
為了實作高效研發，有必要投資那些使工程師能夠高速作業的系統，并最大限度地將他們的時間花費在自己的責任領域，顯而易見，出發點是構建、集成和部署代碼的工具和程序，以及那些在代碼發布后用來運營的工具和程序，確保代碼滿足可用性、可靠性、性能和安全性的要求，
雖然基于服務的體系結構可能帶來自治性的好處，但跨服務邊界的故障可能更難排查，如果日志采集、傳輸、監控、報警和問題跟蹤在各個服務之間都是通用的，那么就會很有幫助，可觀測性的能力應能夠進行分布式跟蹤，便于精確檢測關鍵信號和指標，并逐步細化排出空間，從而精確找到問題的根本原因，
高效的實驗——試錯
為了提高創新速度，需要積極尋求降低實驗成本，以便能夠做更多的實驗，高實驗率可以促進更頻繁糾錯，但實際上，高比率的實驗可以被看作是大量丟棄的想法、檔案垃圾、死代碼和失敗，造成資源的大量浪費，
成功的團隊擁抱失敗，是指做出的大多數錯誤選擇是容易逆轉的，失敗，如果處理得當，可能是一個成長的機會，錯誤并不是必要的罪惡，是做新事物的必然結果，可以被看作是有價值的，
但是，我們客觀地認識到了自己的錯誤么？！
小結
盡管大家都覺得軟體工程越來越重要，但是太多的軟體專案最侄訓是偏離了目標，并且超出了預算，有效的交付需要對所要的東西有一個完美的視野，同時要朝著那個視野堅定地前進，對所有的干擾視而不見，這可能是一個長期存在的誤區，提高研發效率的一個更可靠路徑是優化研發速度，提倡高效文化，開放的實驗和學習，自治而敏捷的組織，不忘初心，
【關聯閱讀】
沒有被了解的API？一個老碼農眼中的API世界
華為資料之道：資料分類管理框架和經驗
隄上創新誰述記——老碼農的“創新”漫談
斯須改變如蒼狗——一張圖的隨想
軟體架構的10個常見模式
老曹眼中研發管理二三事
面向全堆疊的技術管理
服務可用性的一知半解
性能，10點系統性思考
分布式系統的時間問題
如何進入一個新領域
零信任安全的認知
老碼農的AI漫談
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/280632.html
標籤：AI
上一篇：以AI制作AI，當AutoML加入AI研究員內卷大潮
下一篇：用安全策略加固無線局域網安全