职业化之可以固化的六个工作模式

郑昀 汇总 20130320

职业化所包含的行为模式
——总有一些工作套路是可以带走的
(1)
  • 任务已读回执模式
    • 示范A
      • 数据中心的应答
        • 收到数据提取邮件后立即应答: 
          应答人:某某 
          数据提取时间:1小时
    • 示范B
      • 测试环境你提测的工程跑不起来
        • 收到QA的通知后立即应答: 
          应答人:提测接口人 
          立刻过去排查?十分钟后排查? 
          是某某业务中心的问题,找×××十分钟后过去排查
    • 避免给其他部门留下泥牛入海毫无响应的恶劣印象
    • 部门的专业形象来自于这些对外话术的细节  
 
(2)
  • 分歧升级模式(工作中与其他部门有争论有了分歧怎么办)
    • 重要且紧急事务有分歧,逐步升级
    • 问题快速升级,别等死
    • 确认这一层没有解决,再升级,不要不尝试沟通就直接升级  
 
(3)
  • 不随波逐流模式
    • 在日常工作之外、在流程之外,发现问题,提出问题,解决问题
    • 主动出击,主动干预,不要被动地被其他部门 Push 你往前走
    • 每天结束时想想今天有哪些“迹象”需要组织或部门或制度或流程或意识“Change”的 
    • 自己的命运自己掌握
 
(4)
  • 免绕道模式
    • 需要警觉的迹象
      • 现象
        • 本隶属于你的业务范畴,屡屡被绕道
      • 原因
        • 有可能成为了别人眼中的瓶颈或障碍
        • 第三方找其他人或人家自己干效率更高  
 
(5)
挑战/应答模式
  • 史上最差应答模式
    • Challenge:谁? 
      Response:我!
    • 没有主动纠正对方问题描述
    • 没有主动做现状和背景描述
    • 没有做原因调查
  • 错误应答模式1
    • Challenge:我觉得你们这么做有问题! 
      Response:你算老几!over。
  • 错误应答模式2
    • Challenge:有问题! 
      Response:不存在。over。
  • 正确的Challenge/Response模式
    • Challenge
      • (设计)有问题!
      • (开发)用不了!
      • (数据)对不上!
    • Response
      • 名义规则
        • 一旦定义这是Challenge
        • 自动视应答者以部门名义出面回应
        • 口头沟通、会议沟通之后,必须有正式Response邮件
        • 邮件抄送双方部门各级主管
        • 拒绝点对点应答!
      • 事实规则
        • 事实!事实!还是事实!
          • 拒绝“我猜”“我听说”“我想”!
          • 未走访、未掌握事实之前请勿Response!
      • 定性规则
        • 确认设计使然还是实施偏差
          • 如是设计使然, 
            应答之后由更高一级主管 
            审视是否修改设计
      • 正确顺序
        • 定义问题
          • 挑战者给出的问题描述多半不能直接使用
            • 语法错误
            • 术语错误
            • 因果错误
            • 甚至事实都张冠李戴
          • 请应答者重新描述该问题
        • 收集整理信息
          • 将双方部门可能都不太清楚的背景信息整理出来
          • 一定要统一认知!不要每次都在一堆废墟上讨论
        • 调查和分析问题
          • 5W2H分析法
            • What
              • 现象是什么?
            • How
              • 继续下去的话会怎么样?
            • Why
              • 为什么会出现这样的问题?
            • When
              • 什么时候开始出现这样的问题?
            • Where
              • 涉及哪些系统?C还是B?
            • Who
              • 与谁有关?会影响到哪些人?
            • How much
              • 波及面有多大?造成多少损失?
          • 用“5个为什么”建立因果链
          • 刨根问底才能找到Root Cause
        • 问题纠正
          • 实施整改措施
          • 实施短期纠正措施
        • 预防
          • 如何杜绝Root Cause?
          • 吸取教训
        • 应答
          • 广播式应答
            • 拒绝点对点应答
          • 记住这是以部门名义发出的应答,它应该是一个终极权威回答
  • 为什么要强调正确的挑战应答模式?
    • 50%的Challenge是误会产生的
      • 没有统一的认知基础
        • 不了解基本概念
        • 无法区分因果关系
        • 设计本是解决需求A的,但当需求B到来时……
    • 50%的Challenge可能直指系统隐患
      • 我们有义务找到隐患,close it
    • 经受正确的、深入的、大量的Challenge是你进阶的助推器  
 
(6)
大事件模式
  • 收集足够多信息
    • 堆栈信息
    • 错误日志
    • 数据库日志
    • 操作历史
    • 存储介质日志
  • 描述问题
    • 现象没有描述清楚之前,请勿急于下结论
  • 构建证据链
  • 给出结论
  • 线下重现
  • 纠正线上数据
  • 制定防范措施
  • 公开通报
  • 纳入RCA案例库  
 
 
赠图一枚

附赠语录几枚
 

网易汪源:

做好运维多在于傻傻坚持一些基本法则。比如事故处理航天有二十字诀:定位准确、机理清楚、可以复现、措施有效、举一反三。杭研引进3年多,促使众多大大小小的线上事故,都得到严肃认真的对待。特别是举一反三一项,有助于避免类似事故再次发生。单就这众多事故的良好的事实纪录,就已是不小财富

 

http://www.aqee.net/should-developers-have-access-to-production/

『Joel Spolsky有句话放在管理工作上很合适:“每人都有自己的一块领地。是谁的,就是谁的。如果一个管理者或其他人,想插手一个事情的管理方式,他必须保证自己是事情拥有者。拥有者有最终话语权。”』
 
孙陶然:
#昆仑的仑# 解决问题的第一步是确定一个明确的总负责人,一个没有明确负责人的问题是不可能被解决的。
 
大宝:
很多管理者以简单的所谓“结果导向”来要求团队,而忽略了中间辅导、辅助的过程,这样就只能采用试错、赌博的方式来用人,而不能形成团队能力持续正向提升的正循环,从而也就无法形成属于这个团队自己的核心竞争力。是的,我认为,一个团队真正的核心竞争力就在于:能不断孵化出优秀的自己需要的人才。
 
posted @ 2013-03-28 17:20 旁观者 阅读(...) 评论(...) 编辑 收藏