涉及项目可能遇到各种不确定因素。它包括风险识别，风险量化，制订对策和风险控制等。
开发，测试，运维不是三个独立部门，他们相互紧密联系，但又相互制约：
开发只负责写程序，将运行无误的程序提交至版本库中
开发不能私自将程序交给运维部署，也不能将编译好的程序给运维测试。
测试部只能从版本库提取代码，然后编译，打包，运行，测试
不允许测试部将代码交给运维部部署
避免代码没有经过版本库流入生产环境，线下与线上代码不一致
运维部负责部署应用程序，配置管理，只接受测试部确认无误的版本，部署代码只能从版本库中提取
开发 -> 测试 -> 运维 贯穿始终。
几乎所有的技术企业都会重视技术规范，为此制定各种规范，并要求员工严格执行。同时员工会想出各种对策，就这样形成了潜规则。
流程与规范的制定需要需要满足几个条件，简单，容易掌握，容易执行，可重复执行
企业管理层擅长制定乌托邦式的流程与规范，随便拿出一条都堪称完美，无懈可击，但没有考虑到执行结果，流程规范在执行过程中每个环节都会出现问题。
我16年的职业生涯中在不同的公司任职过，几乎每到一家公司都会遇到各种规范，随着职业发展最后我也成为了规范的制定者，也曾经主持制定过开发规范，运维规范，测试规范等等。
我做过很多规范，文档无数，技术人员根本不会去看，通过开会向下传达，开会的人根本没有心思理会你的规范，规范执行阻力是很大的，效果也差。
终于有一天我意识问题的存在，开始反思，企业是否需要制定这些规范？ 我发现与企业环境/文化有很大关系。
有些强制的规范可以通过一些技术手段，避免出现。不会出现也就无需规范！
只有机器人才能100%执行流程
除了事，制定规范，后续无人跟进，
员工考虑的是尽快完成工作，
但这些规范起到的实质作用就好比“请保持室内卫生，不准乱团垃圾，禁止随地吐痰”
原文出处：Netkiller 系列 手札
本文作者：陈景峯
转载请与作者联系，同时请务必标明文章原始出处和作者信息及本声明。
