鄭昀 匯總 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案例庫??

---

贈圖一枚

---

附贈語錄幾枚 #職場思考系列#1）代入式思考（不當甩手掌柜）?http://www.cnblogs.com/zhengyun_ustc/archive/2012/07/29/2613751.html? ；2）挑戰應答模式?http://www.cnblogs.com/zhengyun_ustc/archive/2012/08/12/challenge_response.html? ；3）學習東北戰爭好榜樣?http://www.cnblogs.com/zhengyun_ustc/archive/2012/05/01/1947_1948.html? ；4）走出公司-進入產業-建立圈子?http://www.cnblogs.com/zhengyun_ustc/archive/2007/07/15/818837.html? ；5）細節和感覺三篇?http://www.cnblogs.com/zhengyun_ustc/archive/2007/01/25/CarrerSurvive1DetailsAndFeeling.html?，http://www.cnblogs.com/zhengyun_ustc/archive/2007/01/28/careersurvive2.html，http://www.cnblogs.com/zhengyun_ustc/archive/2007/01/28/careersurvive.html。

網易汪源:

做好運維多在于傻傻堅持一些基本法則。比如事故處理航天有二十字訣：定位準確、機理清楚、可以復現、措施有效、舉一反三。杭研引進3年多，促使眾多大大小小的線上事故，都得到嚴肅認真的對待。特別是舉一反三一項，有助于避免類似事故再次發生。單就這眾多事故的良好的事實紀錄，就已是不小財富

?

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

『Joel Spolsky有句話放在管理工作上很合適：“每人都有自己的一塊領地。是誰的，就是誰的。如果一個管理者或其他人，想插手一個事情的管理方式，他必須保證自己是事情擁有者。擁有者有最終話語權。”』 孫陶然： #昆侖的侖# 解決問題的第一步是確定一個明確的總負責人，一個沒有明確負責人的問題是不可能被解決的。 大寶： 『很多管理者以簡單的所謂“結果導向”來要求團隊，而忽略了中間輔導、輔助的過程，這樣就只能采用試錯、賭博的方式來用人，而不能形成團隊能力持續正向提升的正循環，從而也就無法形成屬于這個團隊自己的核心競爭力。是的，我認為，一個團隊真正的核心競爭力就在于：能不斷孵化出優秀的自己需要的人才。』

轉載于:https://www.cnblogs.com/zhengyun_ustc/archive/2013/03/28/sixpattern.html

總結

以上是生活随笔為你收集整理的职业化之可以固化的六个工作模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。