iT邦幫忙

2025 iThome 鐵人賽

DAY 5
0
自我挑戰組

綠洲計畫:當團隊開始看見自己系列 第 5

Day 5 第五章:診斷的探針

  • 分享至 

  • xImage
  •  

第五章:診斷的探針

應用理論:診斷式組織發展 (Diagnostic OD)

穆拉提的授權為艾佛勒的診斷工作打開了綠燈。但他並沒有立刻發放那種傳統的、充滿了量化指標的滿意度問卷。在他看來,那樣的問卷就像是用固定的網格去測量一條流動的河,只能得到僵硬而失真的資料。他需要的是更深入、更質化的探針,去觸碰這個組織活生生的血肉和神經。

他的診斷式組織發展 (Diagnostic OD) 分為三個層次同步進行:資料探勘 (Data Archeology)一對一深談 (One-on-One Dialogue) 和 焦點團體訪談 (Focus Group Interview)

資料探勘 (Data Archeology)

艾佛勒首先像一位資料考古學家一樣,沉浸在團隊的數位足跡中。他花了整整兩天時間,與一位受信任的資淺 DevOps 工程師合作,分析了過去六個月的資料:

  • Jira 看板的流動效率 (Flow Efficiency):他們發現,一張 Ticket 從「待辦 (To-Do)」移動到「完成 (Done)」的平均週期時間長達15天,但其中真正處於「進行中 (In Progress)」的時間不到3天。超過80%的時間都耗費在各種「等待」狀態:等待需求澄清、等待Code Review、等待測試、等待部署。看板上的「阻塞 (Blocked)」標籤隨處可見,像一個個數位化的血栓。

  • Git 提交紀錄 (Commit History):除了之前發現的充滿情緒的提交訊息外,他們還發現了一個模式:在每次重大發布前夕,代碼的提交頻率會異常飆高,而且單次提交的代碼行數極多,動輒上千行。這意味著團隊沒有做到小步快跑、持續整合,而是在最後關頭進行「核彈級」的代碼合併,風險極高。

  • CI/CD 流水線的失敗率:資料顯示,超過40%的自動化建置與部署會在中途失敗。失敗的原因五花八門:測試環境不穩定、依賴套件衝突、腳本錯誤等等。這迫使開發人員花費大量時間手動修復流水線,而非開發新功能。CI/CD 本應是高速公路,在這裡卻成了一條顛簸的泥土路。

  • Slack 頻道分析:艾佛勒用腳本簡單分析了公共頻道的溝通模式。他發現,@人的頻率極高,但形成有效對話串的比例極低。大量的提問石沉大海,或者被新的告警訊息淹沒。這是一個充滿噪音卻低信噪比的溝通環境。

這些冰冷的資料,客觀地勾勒出系統失能的外在骨架。它們是無可辯駁的事實,將成為後續討論的堅實基礎。

一對一深談 (One-on-One Dialogue)

接著,艾佛勒開始了他最核心的工作:與團隊成員進行一對一的保密訪談。他隨機抽取了涵蓋前後端、QA、PM、DevOps 各個角色的十五位成員。訪談的地点不在嚴肅的會議室,而是在公司樓下的咖啡廳。

他的開場白總是很簡單:「我不是來做績效考核的。我們的對話內容完全保密。我只想聽聽你的故事。在『星雲科技』工作,對你來說是什麼感覺?」

這個問題像一把鑰匙,打開了許多成員的心防。

  • 資深後端工程師大衛,在強硬的外殼下,流露出深深的疲憊:「我也不想當惡人。但如果我不把關,那些亂七八糟的代碼合進來,最後系統崩潰了,CTO第一個找的還是我。我感覺自己像個獨自扛著整個伺服器的人。」

  • 前端工程師馬克則充滿了挫敗感:「我們想用新的前端框架,提升用戶體驗,但每次都被後端以『影響穩定性』為由駁回。感覺我們永遠在給他們的老舊架構擦屁股。我們之間隔著一道牆。」

  • QA負責人莉莉的聲音帶著一絲苦澀:「我的工作本應是預防問題,但現在卻成了在災難發生後指出是誰的錯。我回報的Bug越多,團隊的士氣就越低落。有時候我甚至會猶豫,要不要回報那些『不那麼嚴重』的問題。」

  • 一位年輕的產品經理安娜幾乎快要哭出來:「我感覺自己像個傳話的服務生。業務要A,工程師說只能做B,最後做出來是C,然後所有人都在罵我。我根本不知道這個產品的方向到底是什麼。」

在這些對話中,艾佛勒始終保持著專注的傾聽,他很少打斷,只是在對方停頓時,用「然後呢?」、「那時候你有什麼感覺?」這樣的中性問題來引導對方繼續深入。他關心的不是事件中的客觀真實性,而是成員們在事件中的主觀體驗與感受

焦點團體訪談 (Focus Group Interview)

最後,艾佛勒組織了兩場小規模的焦點團體訪談。一場是純工程師的,另一場是PM和QA的混合組。在訪談中,他會拋出一些更具挑戰性的問題:

「如果我們有一個魔法棒,可以改變這個團隊的一件事,你們希望改變什麼?」

「大家普遍認為,我們團隊最大的優點是什麼?最大的挑戰又是什麼?」

「回想一次最成功的合作經歷,那時候發生了什麼?再回想一次最失敗的合作,又是什麼情況?」

在這些討論中,集體的模式開始浮現。工程師們普遍認為最大的挑戰是「需求不清晰」和「溝通成本太高」。而PM和QA組則認為最大的挑戰是「工程師的本位主義」和「缺乏透明度」。有趣的是,雙方都認為團隊的優點是「大家都很聰明,個人能力很強」。

艾佛勒敏銳地捕捉到了這個矛盾點:一群聰明能幹的個體,組成的團隊卻效率低下。這再次印證了他關於系統問題的假設。

經過一週密集的診斷,艾佛勒的筆記本上寫滿了故事、引言、資料和觀察。他沒有得出一個簡單的結論,而是得到了一幅豐富、立體、充滿了矛盾與張力的「現況圖」。

他知道,下一步,就是要如何將這面鏡子,以一種安全而又震撼的方式,呈現在整個團隊面前。這將是「綠洲計畫」的第一個關鍵時刻,也是「解凍」過程的正式開始。


上一篇
Day 4 第四章:系統的共業
下一篇
Day 6 第六章:「綠洲計畫」的誕生
系列文
綠洲計畫:當團隊開始看見自己14
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言