| 知乎专栏 |
我们在很多的企业都发现基层员工一听流程就反感，甚至想要骂人，流程就是一堆不干活的人，专门弄出来一套东西来为难干活的人，借此体现自己的价值。
而在管理层那边，又总是容易听到另一种说辞，认为员工能力素质不行，总喜欢不按流程违规操作，导致企业管理能力与效率一直上不去。
几乎所有的技术企业都会重视技术规范，为此制定各种规范，并要求员工严格执行。同时员工会想出各种对策，例如工作忙，就这样形成了潜规则，刚开始严格执行，然后松懈，最后不了了之。
这些规范就好比“请保持室内卫生，不准乱丢垃圾，禁止随地吐痰，不要闯红灯” 一样没起到的实质作用。
管理层擅长制定乌托邦式的流程与规范，随便拿出一条都堪称完美，无懈可击，但没有考虑到执行结果，流程规范在执行过程中每个环节都会出现问题。任何一个环节出现问题就如同多米诺骨牌，造成连锁反应，最终无法控制。
我19年的职业生涯中在不同的公司任职过，几乎每到一家公司都会遇到各种规范，随着职业发展最后我也成为了规范的制定者，也曾经主持制定过开发规范，运维规范，测试规范等等。
我做过很多规范，文档无数，技术人员根本不会去看，通过开会向下传达，开会的人根本没有心思理会你的规范，规范执行阻力是很大的，效果也差。
终于有一天我意识问题的存在，开始反思，是否需要制定这些规范？制定流程规范的目的是什么？
有些强制的规范可以通过一些流程或者技术手段避免出现，不会出现也就无需规范！
出现这种问题，最常见原因大致有以下三个
太多的企业在流程设计的过程中，总是关注领导想要什么，错把领导当成服务对象，却忽略了流程真正的使用者（一线业务人员）他们想要什么。
这就导致很多流程在设计出来以后发现领导看了很满意，但是一线业务人员操作起来却十分复杂。
所以我们在流程设计之初，一定要充分考虑流程的使用者，他们到底需要什么，一定要围绕着他们的需求来策划。
流程很大程度上是为了让业务合规，控制企业风险，这当然没有错，但是如何控制风险，方法选择就很重要。
所以在流程设计过程中，对于每一个增加的审批节点，我们都要问一问，需要这个节点审什么，能不能通过过程要求去替代。
控制风险最好的手段往往不是增加领导的审批节点，而是把规范要求融合到业务流程的过程当中去，形成标准的输入、输出，自然而然就控制了风险，减少了来回扯皮的过程。
例如下面一个小故事，公司某部因为将开发数月的代码丢失了，导致测试无法进行，领导大发雷霆，某管理层制定了下面的规范，大意为。
1. 定期备份机制
2. 代码注释要求
3. 代码访问需要更高层的批准
4. 详细的部署文档
等等
我认为源码管理主要有两种手段，技术手段与管理手段。
我先谈谈管理手段：例如通常通过规章制度，责任追究等等手段，要求员工达到规范标准，但通常执行力都会打折，无法达到预期，人的不稳定性因素太多。往往发现员工没有按照规范操作为时已晚，将该员工辞退也无法挽回公司的损失。
就如公司规章制度写的清清楚楚，要求员工提交代码到版本库，但各种原因没有被执行，当代码丢失，从上至下追究责任，公司的损失无法挽回。
所以我主张技术手段：例如源码如果发布到线上，必须经过版本库，只能使用自动部署，不允许程序员私自将代码交给运维手工部署。另外发布代码的同事，可以不提供生产服务器登陆权限，他只能通过工具发布代码。
部署流程如下：
源码(程序员) 提交到development 分支 ----> 合并到 testing 分支（主管合并，程序员没有权限）------> master 分支(主管合并) -----> 自动部署系统(运维) ----> 生产服务器。
这样通过技术手段防止了代码因员工离职，硬盘损坏等等原因，导致代码丢失的可能。
代码发布者也无需对照部署文档，手动登陆服务器逐条按照部署说明书操作，防止了人员误操作，也提高了部署效率，节省了人力成本，通常在5分钟之内可以完成所有部署。
我再来举另外一个例子，就是开发中的编码规范，很多软件企业都有是不是？
例如要求程序员：
if
(){}
要写成
if ()
{
...
}
等等要求不一一列举，甚至组织代码评审会解决编码规范问题。
我的建议为什么不在IDE上设置自动格式化，或者在svn/git提交的时候通过hook调用格式化程序。甚至可以做到，在提交的时候编译，编译不通过，就提交不上去。
管理层要求运维每天发送服务器状态报告，运维人员需要登录每个服务器获得服务器运行状态数据，然后制作一个报告文档，每天给各位发送一次。
运维需要一个专职人员做这个报告，这种报告几乎没有人看，就像“人民日报” 人民从来不看。
当运维事故该出现的时候还是会出现，老板一个一个骂，扣工资，扣奖金，运维觉得委屈，公司受到损失。平日里的这些工作并不能避免运维事故，也不能改善运维工作。
在举一个例子，运维工作要求备份数据，制定规范，A员工负责备份，B 员工负责检查A员工的备份。这个流程没有任何问题。
结果两年以后出事了，需要恢复数据，发现A没有备份，而B在一年前就再没有检查A的工作。
起初前一年还是按流程备份，后来A发现B不再严格检查工作，备份工作逐渐减少，最后停止了备份，一直相安无事，直到事发。
我曾经遇到过一个兢兢业业的管理者，他制定规范，要求值班的同事7*24小时，每间隔一定的时间做一次操作，验证系统正常运行，以便能够第一时间通知运维处理故障。
值班的同事偶尔偷懒，他就半夜起来监控他们工作。一个打工者能做到如此，真让人佩服。
但是故障的频率依然没有改观，运维仍是每天疲于奔命的救火。
但是我们有更好的方法，真的不必如此操劳且效率低下。
上面的几个故事是一个无休止的死循环，管理者也进入了一个流程制度的闭环思维，管理手段是无法解决和避免事故再次发生的。
出问题 -> 领导发火 -> 行政处分 -> 制定规范 -> 执行规范 -> 慢慢淡忘 -> 后续无人跟进 -> 石沉大海 -> 继续出问题。
流程与规范的制定需要需要满足几个条件：简单，易掌握，易执行，可重复执行
员工考虑的是尽快完成工作，规范不应成为完成工作的负担。
只有机器人才能100%执行流程，任何由人执行的流程规范都不可能做到100%执行，在军队中即使是严格训练过的士兵也常常犯错。
很多管理者将其归咎为 “执行力” 弱，我并不这么认为。有些犯错并不是执行力问题，也不是敬业度问题，可能需要从心理学角度解释。这是我在阅读几本心理学著作后发现的。
我觉得很多规范是形式主义，我一向主张实用主义。
通过技术手段可能避免很多没有意义规范，开发自动化，测试自动化，运维自动化，这是趋势也是我的努力的目标。
电梯与我们的生活是密不可分，生活在城市，很难想象如果没有电梯会怎么样。
几年前有一起电梯（手扶梯）伤人事件，事情的起因是这样的，一家商场电梯维修了一半，为了不影响商场运业，维修人员几把盖板临时盖上，供顾客使用。
事件的经过是这样的，一位妈妈带着孩子来到商场购物，一脚踩在电梯盖板上，盖板突然反转，顾客直接掉进电梯，母亲顺势将孩子抛出，然后就被搅入传送机构，血肉模糊，最后惨死在电梯里。
最后我们看看处理结果，事件发生之后，新闻与评论无非是指责商场，指责电梯维保，指责生产厂家，探讨电梯行业等等舆论层面。商场马上启动公关，进入司法理赔谈判等等。
我们看到舆论只会去职责，从未有人提出过解决方案。
社会舆论一边倒“管理层面”，也就是提高商场服务意识，工作人员敬业程度等等，但这些因素是不可控。
另一种是“技术层面”，通过技术手段解决电梯安全问题。在我看来此次事件是电梯设计缺陷所致。
电梯伤人事件解决方案. 现在我来说说技术层面“电梯伤人事件解决方案”。 首先在电梯盖板下面安装一个按压开关，当盖板安装好后，开关处于下压状态，电路导通，通过继电器，开电梯电源。 一旦盖板被打开，电梯立即停止供电。进一步延伸功能，当盖板被打开，停止电梯供电，同时触发警报。 怎么样？成本不足5元钱，安装两个零件彻底解决了安全问题， 在现有的电梯设备上改装，只需要几个小时就可以完成。 这种技术层面的解决方案，远比媒体/舆论期望的“管理层面解决方案”要好。 我们可以在很多方面作出技术改善，安装各种传感器，实现工作状态实时监控，故障报警，自动响应等等。
当下需要重点解决的是下面几点：
实时监控. 目前电梯都是每年巡检一次，使用过程中出现问题再找厂商上面维修。这样的检查是远远不够的，往往电梯出现问题，轻者将人困在其中，重者就会伤人。
例如我们可以采用很多传感器技术监控电梯：
远程监控. 远程监控是指电梯传感器收集的数据，实时或定时发送到厂家，用作数据分析，归档备份
故障报警. 目前主要靠人来判断故障，然后决定是否需要通知厂商维修。 有了上面的监控数据，电梯出现故障厂家第一时间知道，并上门维修。 甚至厂家可以可通收集的监控数据，通过技术人员分析，决定是否远程遥闭电梯。
自动响应. 是电梯智能化的标志，电梯能根据预先设定的程序，对轻微故障，作出自动响应。如上面谈到的“电梯门安全”，“红外空间扫锚”。
电梯行业应该引入4S概念. 目前电梯市场十分混乱，我认为电梯行业应该引入4S概念。
四位一体的销售企业，让电梯的销售，配件，售后保养，以及问题反馈流程化，标准化。