穷追不舍、事故入手和倒逼
郑昀 创建于2014/10/22 最后更新于2014/10/30
对干部和员工的行为管控是一件很困难的事情。
原因呢有三。
一，员工在之前的职业生涯里并没有接受过职业培训。譬如你常常见到员工像踏足现代商业社会的原始人，连“Reply”和"Reply All“都分不清楚。
二，员工从干部那里接收到的行为指令往往是模糊不清的。譬如”下午做个设计评审“，到底意味着什么？需要给员工一个明确指示和范例。
三，人普遍忘性大惰性大。
所以，很多问题会随着铁打营盘流水兵而一再上演。
那么呢，有三种手法来训练自己的团队，使得在突发事件出现时（也就是之前既没有流程定义，也没有干部知道该如何处理），团队能够自动自发地灭火。
第一，穷追不舍。
干部叫以身作则亲身示范，对每件事都穷追不舍，必须有一个结果。
首先，每一件事情到了干部这里，都能够不惜时间不惜体力不惜代价地对自己的团队要一个结果。
其次，干部明确传达出一个信息，所谓“结果”代表的是“真正解决问题”，要拿出解决问题的诚意，而不是被两句话打发。
长此以往，干部和员工就知道这个团队的作风是不会善罢甘休的，譬如对于研发干部而言，就知道涉及到交易支付的技术问题，不死不休。
那么，这种“行为”就会向下传染，成为一种“惯例”，一代一代的员工都能感受到。
第二，事故和投诉入手。
建立基本规范和流程后，干部长期从事故和投诉入手，对每一件都追查到底，顺藤摸瓜。
为什么要这么做？
所谓企业文化，很多时候是由“组织习惯”组成，而它很大程度上是公司成百上千的员工独立决策所形成的、长期“坚持”的组织习惯，这些行为习惯往往不在你的规章制度和业务流程范畴内。
那么从事故和投诉入手，就很容易揭开盖子，发现以往的一些习惯和行为是错误的，或者说是不可靠的。有些习惯以前是对的，现在是错的，这些都能够通过事故和投诉暴露出来。
实践证明，很多组织习惯是轻率的产物。
对
于研发板块来说，顺着事故和投诉发现问题、提出问题和解决问题较为简单。我们毕竟是技术人员，可以用机器干掉这些习惯，减少人为干预因素。譬如说，我们可
以依靠项目管理平台，让所有需求在它们的生命周期里从头到尾在平台上任务流转。譬如说，我们可以禁止手工提交发布包和手工上线，人只是上线任务的发起者而
已，其他的事情交给更可靠的机器做。
第三，倒逼。
下游倒逼上游。
这也是技术领域常见的手法。一开始，开发规范和项目质量管理制度都会流于形式，大家懒得看、懒得遵守或者觉得束手束脚。我们不会去揣测大家的动机是什么，我们只需要纠正行为即可。
如何纠正？
下游设立一组或多组最后的看门人。看门人对事务的判断非常简单，非黑即白。
譬
如，第一招，不符合质量控制的要求，不允许上线，甚至不允许提测，第二招，系统管理员只接收质量控制流转的上线操作指令，第三招，开发者没有生产环境的发
布、修改配置文件等权限，更不用说数据库写权限了，只有数据库管理员才有写入权限。有了QA、SA、DBA这三组看门人，要求和压力慢慢地就会自下而上
地、一层传一层地传播，最终大家都意识到，遇到事情先想想怎么过质量控制的check list吧。
这三种手法印证了一句话：先有技法，后（才可能）有心法。
指望先教会大家心法，然后形成技法，多半不靠谱。
『先有技法，后（才可能）有心法』，其实与华为说的“僵化、固化、优化”是一样一样的。
-over-
推荐阅读：
郑昀——职场真相：七句话
郑昀——十个行为模式
郑昀——研发阿米巴组织
