iT邦幫忙

2025 iThome 鐵人賽

DAY 8
0
自我挑戰組

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

Day 8 第八章:不信任的防火牆

  • 分享至 

  • xImage
  •  

第八章:不信任的防火牆

應用理論:信任的支柱 (Pillars of Trust)

在聚焦於「前後端協作」這個具體問題的同時,艾佛勒也在思考一個更根本的議題:為什麼團隊的權力動力學會變得如此失衡?為什麼本應是合作夥伴的團隊會演變成資源的博弈方?

他將在診斷階段收集到的所有故事和資料,套入了他常用的信任的四大支柱 (Pillars of Trust) 理論模型中進行分析。這個模型由四個核心要素構成:清晰度 (Clarity)、同理心 (Compassion)、一致性 (Consistency)、能力 (Competence)。他發現,「星雲科技」的團隊,在這四個支柱上都出現了嚴重的裂痕,共同構築起了一道堅不可摧的「不信任的防火牆」。

1. 清晰度 (Clarity) 的崩塌:我們到底要去哪?

信任的第一個支柱是清晰度 人們是否清楚地知道對他們的期望是什麼?目標是什麼?以及為什麼要做這件事?

在「星雲科技」,清晰度是極度匱乏的。

  • 需求的模糊性: 產品經理安娜,作為需求的源頭,經常從業務團隊那裡接收到一些模糊的指令,比如「我們需要提升用戶活躍度」。但具體「如何」提升,卻沒有明確的定義和資料支撐。她只能將這種模糊性原封不動地傳遞給開發團隊,導致工程師們在開發過程中充滿困惑,只能憑藉猜測寫代碼。

  • 目標的搖擺不定: 公司高層每個季度都會提出新的戰略方向。這個季度強調「用戶增長」,下個季度就變成了「營收利潤」,再下個季度又是「技術穩定性」。這種搖擺讓團隊無所適從。當他們剛剛投入資源解決技術債時,又會被新的緊急功能需求打斷。團隊感覺自己像在一個沒有羅盤的船上,船長卻在不斷地變換目的地。

  • 「為什麼」的缺失: 艾佛勒在訪談中發現,很少有工程師能清楚地說出,他們正在開發的功能,究竟能為用戶解決什麼問題,或者為公司帶來什麼商業價值。他們接到的指令通常是「做這個功能」,而不是「為了幫助用戶解決X問題,我們需要實現Y功能」。這種對「為什麼」的無知,讓工作本身失去了意義感,淪為純粹的任務執行。

2. 同理心 (Compassion) 的缺失:你不是我的戰友

信任的第二個支柱是同理心 人們是否感覺到自己被當作一個「人」來對待?他們的感受和困難是否被看見和理解?

在追求效率和進度的壓力下,「星雲科技」的同理心幾乎消失殆盡。

  • 工具化的視角: 工程師們普遍感覺自己被視為「開發資源」或「人頭」,而不是活生生的人。管理者關心的只是Jira上的任務進度條,而不是他們為了解決一個棘手Bug熬了多少個通宵,或者他們對現有架構有多麼失望。

  • 指責文化: 當線上出現問題時,第一反應不是「我們一起來看看怎麼解決」,而是「這是誰的錯?」。「究責郵件」(Blame Email) 甚至成了一種不成文的企業文化。這種環境下,承認錯誤需要巨大的勇氣,而隱藏問題和推卸責任則成了最安全的生存策略。

  • 跨團隊的隔閡: 後端團隊無法體會前端為了兼容老舊API所付出的額外工作量;開發團隊也無法理解QA為了確保質量,需要一遍遍執行重複測試的枯燥。每個團隊都站在自己的立場上,認為對方「不專業」或「找麻煩」,卻從未試圖去理解對方工作的難處和壓力。

3. 一致性 (Consistency) 的斷裂:你說的話,我還能信嗎?

信任的第三個支柱是一致性 言行是否一致?承諾是否被兌現?

這是團隊中信任崩塌最直接的原因。

  • 跳票的技術債: 穆拉提和幾位技術主管曾在多次會議上承諾,要專門劃出20%的「固定時間」來償還技術債。但這個承諾在緊急的業務需求面前,一次又一次地被犧牲。這讓工程師們感覺自己被欺騙了,他們不再相信管理層的任何長期承諾。

  • 變動的獎勵機制: 公司的績效考核標準也缺乏一致性。有時獎勵那些按時交付功能的「英雄」,即使代碼質量很差;有時又會獎勵那些發現重大Bug的人,儘管這可能正是因為之前的開發流程有問題。這種不一致的導向,讓員工感到困惑,不知道究竟該為什麼樣的行為努力。

4. 能力 (Competence) 的質疑:你真的行嗎?

信任的最後一個支柱是能力 人們是否相信你有能力完成你所承諾的事情?

諷刺的是,儘管「星雲科技」的工程師個個履歷光鮮,但在團隊內部,對彼此能力的信任卻很低。

  • 跨領域的不信任: 後端工程師不相信前端能處理好複雜的狀態管理;前端工程師則懷疑後端寫的API是否真的穩定可靠。這種相互質疑,導致了大量的「防禦性編程」和過度檢查,增加了不必要的複雜度。

  • 對流程的不信任: 團隊成員普遍不相信現有的「敏捷流程」能真正幫助他們。Sprint計畫會被隨意打亂,回顧會議流於形式。大家只是在表演「敏捷」,而不是在踐行敏捷。

艾佛勒將這四個支柱的分析整理在一張圖上,清晰地展示給了穆拉提。他總結道:「穆拉提技術長,我們團隊的問題,就像一座地基鬆動的大樓。我們看到的漏水、牆壁開裂(前後端衝突、Bug頻發)都只是症狀。地基,也就是『信任』,已經被嚴重侵蝕了。我們任何試圖修補牆壁的努力,如果不能加固地基,最終都會是徒勞的。」

「在『綠洲計畫』中,我們做的每一件事,設計的每一個實驗,都必須有意識地服務於重建這四個支柱。我們需要通過契約式的合作來重建清晰度,通過換位思考的練習來培養同理心,通過說到做到的小承諾來累積一致性,並通過賦能和共同學習來恢復對彼此能力的信心。」

穆拉提看著那張圖,久久不語。她意識到,她作為技術最高主管,對於信任地基的崩塌負有不可推卸的責任。她批准了那些跳票的決定,她容忍了指責文化的存在,她也未能為團隊提供一個清晰、穩定的航向。

「我明白了。」她對艾佛勒說,眼神中多了一份沉重的責任感。「那麼,我們的第一個『地基加固工程』,該從哪裡開始?」


上一篇
Day 7 第七章:提交與指責
下一篇
Day 9 第九章:勒溫的拆解指令
系列文
綠洲計畫:當團隊開始看見自己12
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言