在互联网系统中，开发效率与系统稳定性与产品成败非常相关。开发效率在一定程度反映了团队的执行力，快速开发能力带来了产品的竞争优势。系统稳定性（包括安全及性能等）则是产品的后防线，稍有失误则会给产品带来很大伤害。因此开发效率与系统稳定性是衡量互联网系统开发成熟度最重要的两个指标。
在软件开发周期不同阶段，这两者如何控制？
在需求阶段，对开发效率的影响常见的是沟通理解偏差带来的技术风险，之外最常见的还有需求变更的风险。后者大多是来自市场环境的变化作出调整，技术主管更多的是积极心态去应对。但对前者沟通理解偏差导致效率问题也不罕见，更值得警惕。
在技术设计阶段最大的风险是技术方案，找个无需多讲，考验团队的架构能力以及对当前系统的驾驭程度。
开发阶段最大的风险是单元测试不到位或缺失。很多号称“敏捷”型项目依赖在线上测试及修改，当模块增多后，这样代码健壮性就会变得比较脆弱，不少团队也会越走越慢。
Review阶段风险是简洁性及性能。除了压力测试能达标之外，警惕那些不易懂的代码，这些代码将来会成为事故多发地带。
部署阶段最大的风险是上线计划把控，上线过程中操作错误的情况并不罕见，如去年Amazon EC2的故障就是由于操作失误造成。
从宏观看来，技术方案的风险最大，由于模块很多，具有丰富经验的高手不可能参与每一个环节，这就会出现木桶的短板效应，架构师认为不重要的地方总是会出问题。给用户体验造成极大伤害。
另外还有团队文化的风险。大部分团队很难形成书面交流的习惯。口头沟通需求、讨论方案对创业团队非常适合。在团队变大之后，这样的习惯会造成信息流动障碍，可能会给工作效率带来更多负面问题。同时大部分团队也对流程、模板、规范缺乏了解与重视，过多依赖参与人的内部驱动力及能力，无法依靠制度与流程来取胜。
一、具有丰富经验的高手不可能参与每一个环节，这就会出现木桶的短板效应，架构师认为不重要的地方总是会出问题。给用户体验造成极大伤害。
二、大部分团队很难形成书面交流的习惯。口头沟通需求、讨论方案对创业团队非常适合。在团队变大之后，这样的习惯会造成信息流动障碍，可能会给工作效率带来更多负面问题。同时大部分团队也对流程、模板、规范缺乏了解与重视，过多依赖参与人的内部驱动力及能力，无法依靠制度与流程来取胜。
这两点非常认同，也亲身的经历与体验过
系统稳定性？
where?
从宏观看来，技术方案的风险最大，由于模块很多，具有丰富经验的高手不可能参与每一个环节，这就会出现木桶的短板效应，架构师认为不重要的地方总是会出问题。给用户体验造成极大伤害。
任何问题都是人的问题啊！
只谈问题，没有解决方案啊……
最后一段深有感触，就是我们目前经历着的。流程规范对大团队是必须的。
非常好的经验之谈，化解这些风险也并非易事
非常赞！
不是直接面向应用的，而是面向开发人员的。
非常赞同，我们公司从几个人的创业团队发展到现在达到150人的技术团队，沟通的问题真的是越来越明显，文档的沉淀也显得越来越重要。
这东西是相辅相成的，主要看自己把控了。
Just in time! This resource is what I am needing right now. Thank you for sharing.