穷追不舍、事故入手和倒逼

郑昀 创建于2014/10/22 最后更新于2014/10/30

对干部和员工的行为管控是一件很困难的事情。
原因呢有三。
一,员工在之前的职业生涯里并没有接受过职业培训。譬如你常常见到员工像踏足现代商业社会的原始人,连“Reply”和"Reply All“都分不清楚。
二,员工从干部那里接收到的行为指令往往是模糊不清的。譬如”下午做个设计评审“,到底意味着什么?需要给员工一个明确指示和范例。
三,人普遍忘性大惰性大。
所以,很多问题会随着铁打营盘流水兵而一再上演。

那么呢,有三种手法来训练自己的团队,使得在突发事件出现时(也就是之前既没有流程定义,也没有干部知道该如何处理),团队能够自动自发地灭火。
第一,穷追不舍。
干部叫以身作则亲身示范,对每件事都穷追不舍,必须有一个结果
首先,每一件事情到了干部这里,都能够不惜时间不惜体力不惜代价地对自己的团队要一个结果。
其次,干部明确传达出一个信息,所谓“结果”代表的是“真正解决问题”,要拿出解决问题的诚意,而不是被两句话打发。
长此以往,干部和员工就知道这个团队的作风是不会善罢甘休的,譬如对于研发干部而言,就知道涉及到交易支付的技术问题,不死不休。
那么,这种“行为”就会向下传染,成为一种“惯例”,一代一代的员工都能感受到。


第二,事故和投诉入手。
建立基本规范和流程后,干部长期从事故和投诉入手,对每一件都追查到底,顺藤摸瓜。
为什么要这么做?
所谓企业文化,很多时候是由“组织习惯”组成,而它很大程度上是公司成百上千的员工独立决策所形成的、长期“坚持”的组织习惯,这些行为习惯往往不在你的规章制度和业务流程范畴内。
那么从事故和投诉入手,就很容易揭开盖子,发现以往的一些习惯和行为是错误的,或者说是不可靠的。有些习惯以前是对的,现在是错的,这些都能够通过事故和投诉暴露出来。
实践证明,很多组织习惯是轻率的产物
对 于研发板块来说,顺着事故和投诉发现问题、提出问题和解决问题较为简单。我们毕竟是技术人员,可以用机器干掉这些习惯,减少人为干预因素。譬如说,我们可 以依靠项目管理平台,让所有需求在它们的生命周期里从头到尾在平台上任务流转。譬如说,我们可以禁止手工提交发布包和手工上线,人只是上线任务的发起者而 已,其他的事情交给更可靠的机器做。


第三,倒逼。
下游倒逼上游。
这也是技术领域常见的手法。一开始,开发规范和项目质量管理制度都会流于形式,大家懒得看、懒得遵守或者觉得束手束脚。我们不会去揣测大家的动机是什么,我们只需要纠正行为即可。
如何纠正?
下游设立一组或多组最后的看门人。看门人对事务的判断非常简单,非黑即白。
譬 如,第一招,不符合质量控制的要求,不允许上线,甚至不允许提测,第二招,系统管理员只接收质量控制流转的上线操作指令,第三招,开发者没有生产环境的发 布、修改配置文件等权限,更不用说数据库写权限了,只有数据库管理员才有写入权限。有了QA、SA、DBA这三组看门人,要求和压力慢慢地就会自下而上 地、一层传一层地传播,最终大家都意识到,遇到事情先想想怎么过质量控制的check list吧。

这三种手法印证了一句话:先有技法,后(才可能)有心法
指望先教会大家心法,然后形成技法,多半不靠谱。
『先有技法,后(才可能)有心法』,其实与华为说的“僵化、固化、优化”是一样一样的。


-over-
推荐阅读:
郑昀——职场真相:七句话
郑昀——十个行为模式
郑昀——研发阿米巴组织

 

欢迎订阅我的微信订阅号『老兵笔记』,请扫描二维码关注:
老兵笔记订阅号二维码
posted @ 2014-11-17 16:20  旁观者  阅读(...)  评论(...编辑  收藏