某次參加站立會議，某位 PM 情緒激動的說：「我後天要跟客戶回報進度了，但 A 同事這週請假三天，明天才回來，他手上的工作都沒有進展，我後天是要開天窗嗎？」此時團隊的眼神全向我掃來，因為我是 A 同事的直屬主管，此時，我空降這個團隊剛滿三個月。

我之前的文章有提過，空降初期，以觀察與欣賞為主；這個事件暗示了「禪機」已到，我嗅到了改革的機會。在這個事件中，PM 身上明顯有張力，張力會試圖被舒緩，這是一個簡單的張力-舒緩系統：

最直觀的解法，就是趕快去問 A 同事，他手上的任務進度，然後告訴 PM 。如果採用這樣的解法，PM 接下來就會得到啟發，開始頻繁的去追 RD 的進度，每天的工作負擔變重，形成了新的張力；而舒緩之道就是，降低追進度的頻率，過沒多久，進度又開始不明，張力-舒緩系統變成了擺盪的系統：

從上圖來看，兩種張力無法同時的舒緩，同時追問進度，又不能問得太頻繁。這裡衍伸的問題是，當 PM 的張力舒緩了，但 RD 一定會不堪其擾，因為沒有 RD 喜歡每天被追著問：你的進度呢？

就這是典型的解決眼前問題，但忽略了「系統性問題」，讓張力四處的碰撞。當然你可以說，我們可以在中間抓一個平衡啊，但其實這是一種迴避處理複雜情境的推託之詞。所以針對這個情境，我們該做的是：

創造具有「透明化」的專案推進狀況特性的系統

我在另一個團隊中遇到的張力，來自 QA 部門。某次，QA 同事帶著煩惱來找我：「 B 同事交給我們驗証的程式，時常在簡單的正向流程就有 Bug ，導至我們雙方必須來來回回好幾次，影嚮產品的交付時間；我們也嘗試過在實作前先跟他開會，提供很詳細的驗証步驟給他，一來我們的工作量變大了，二來他覺得我們在找碴。現在情況雖然有好轉，但他產出很蠢的 Bug 機會還是很高。」
此時 QA 的張力舒緩系統如下：

如同我上段所說，改善這個狀況，緊盯 B 同事的工作絕不是好主意。最好的方法：

創造「降低出錯率」的開發系統

每個團隊會遇到的狀況不一樣，所以張力-舒緩系統也不同。在團隊中常見的情況是，當系統不健康時，總會有某個成員會以增加工作量的方式，來讓系統內的張力得到舒緩。用人的抗壓性來解決系統問題，也太不人性。

我們最終想要得到的團隊系統，可以這樣描述：

一個高效的敏捷 Scrum 團隊，具透明化、高品質是這個系統的性質。

如果你要的「禪機」一直不來怎麼辦？這表示你的團隊系統處在一個穩定態下，系統中的張力是讓團隊成員舒服的，此時進行系統修改，不僅無效，而且容易引起反彈。團隊的最高優先任務，還是在於「產出」。如果產出都正常，成員也滿意於現狀，不要冒然的進行改革。張力總會累積，就耐心的等待張力需要釋放的時刻到來吧！