來源：Tim Yang
在網際網路系統中，開發效率與系統穩定性與產品成敗非常相關。開發效率在一定程度反映了團隊的執行力，快速開發能力帶來了產品的競爭優勢。系統穩定性（包括安全及效能等）則是產品的後防線，稍有失誤則會給產品帶來很大傷害。因此開發效率與系統穩定性是衡量網際網路系統開發成熟度最重要的兩個指標。
在軟體開發週期不同階段，這兩者如何控制？
在需求階段，對開發效率的影響常見的是溝通理解偏差帶來的技術風險，之外最常見的還有需求變更的風險。後者大多是來自市場環境的變化作出調整，技術主管更多的是積極心態去應對。但對前者溝通理解偏差導致效率問題也不罕見，更值得警惕。
在技術設計階段最大的風險是技術方案，找個無需多講，考驗團隊的架構能力以及對當前系統的駕馭程度。
開發階段最大的風險是單元測試不到位或缺失。很多號稱“敏捷”型專案依賴線上上測試及修改，當模組增多後，這樣程式碼健壯性就會變得比較脆弱，不少團隊也會越走越慢。
Review階段風險是簡潔性及效能。除了壓力測試能達標之外，警惕那些不易懂的程式碼，這些程式碼將來會成為事故多發地帶。
部署階段最大的風險是上線計劃把控，上線過程中操作錯誤的情況並不罕見，如去年Amazon EC2的故障就是由於操作失誤造成。
從巨集觀看來，技術方案的風險最大，由於模組很多，具有豐富經驗的高手不可能參與每一個環節，這就會出現木桶的短板效應，架構師認為不重要的地方總是會出問題。給使用者體驗造成極大傷害。
另外還有團隊文化的風險。大部分團隊很難形成書面交流的習慣。口頭溝通需求、討論方案對創業團隊非常適合。在團隊變大之後，這樣的習慣會造成資訊流動障礙，可能會給工作效率帶來更多負面問題。同時大部分團隊也對流程、模板、規範缺乏瞭解與重視，過多依賴參與人的內部驅動力及能力，無法依靠制度與流程來取勝。