在當今的數字服務經濟中，IT組織不僅需要有改變的能力，也需要按正確的方向改變。這意味著，他們需要能夠感知反饋，并做出響應，以便持續地識別和衡量自己對目標適用性的理解與客戶看法的差距。

當然，標準的敏捷反饋環是由這三個部分構成的：產品演示、團隊回顧和自動化測試，它們提供了產品健康和適用性方面的寶貴意見。然而，還是有很多團隊和利益相關者在苦苦尋找一種可靠的方法來理解反饋的重要領域：服務交付的適用性。

本文引入服務交付審查，并將其作為該反饋的論壇。

數字化組織需要能夠感知客戶，并作出響應

Jeff Sussna在其《設計交付（Designing Delivery）》一書中寫到，服務供應商必須承諾傾聽客戶的聲音，并在制作和交付方面盡可能做出響應。市場變化如此之快，以至于5年甚至5個月前的工作，不知不覺之間就銷聲匿跡了。在意識到這一點之前，團隊或組織就已經不再適合曾經為之服務的目的了（看看Blockbuster、Kodak等等就知道了）。最重要的是，除了高大上的使命和宗旨聲明之外，Jeff Sussna指出，組織的存在是為了繼續存在下去。

也就是說，我們做生意是為了繼續做生意。因此，組織必須不斷尋求理解客戶選擇他們的理由。但是，不要簡單地假設客戶（無論是內部還是外部的客戶）因為產品的質量而選擇我們。我們如何評估工作中不太明顯的方面呢？

什么是服務？從“看板”的角度來看看組織

部分困難源自于只從產品的角度來看組織。但是，組織通常也有服務組件。甚至像咖啡店這種普普通通的東西也不僅僅光是賣杯咖啡什么的（其實絕大部分人認為星巴克不是只做產品或服務，而是兩者兼有）。

對于技術組織來說也是如此。如果我們應用Rodrigo Yoshima和Andy Carmichael稱之為“看板鏡頭”的東西，就變得更容易理解?？窗彗R頭是一種來“看”組織的方式，具體來說是：

• 把工作看成流
• 把知識工作看作服務
• 把組織看作是服務網絡

當“戴上”看板鏡頭時，就像戴著一副有超能力的護目鏡，可以從傳統的組織圖表看起，一直到組織中隨處可見的服務。從人們的選擇看到面向客戶的交付工作！

只要有能看到它們的鏡頭，那么服務無處不在。遺憾的是，通常只有在不滿意時，我們才會注意到它們。不久前，我在自己的組織中“發現”了一個內部服務：我的團隊創作了一個要給領導層看的演示文稿，因此，我們希望它看上去是精心打造的。不幸的是，我們都沒有視覺設計的才能，于是，我們請設計團隊的人幫忙。得到的回答是“有截止日期嗎？”我們還沒有定截止日期，但是，我們也不知道總是忙忙碌碌的同事什么時候可以出手相助。這顯然是一項對內部客戶的（設計）服務，內部客戶知道什么能適合其目的。在這個例子中，得有個明確的截止日期。

我們總是這樣向個人和團隊提出請求。但是，如果沒有信息的相互交換（比如，預期的交付速度），就只能用額外的時間或按錯誤的截止時間來做了 。如果沒有任何關于服務交付績效的定量反饋，就會一直有任意的截止日期和人為的界限。在我的組織設計服務案例中，如果我們透明且定量地交付數據，就可以更容易地交換信息，更有效率地詢問預期。這反過來，又會促進信任。

從適用性的角度來考慮服務交付

服務交付的適應性是什么意思？

首先，團隊和利益相關者是否知道他們的客戶對其服務的評價？

其次，他們是否知道如何來衡量？

再者，是否有定期的反饋環從客戶的角度來評估服務適應性？

問一問適應性問題，如：為什么選擇我們？對我們提供的服務有何評價？這是好事，但是，回答可能會隨著時間的變化而變化。通常情況下，服務隨時間的變化是否還符合選擇的標準，以及是否還與原標準保持一致，團隊并沒有持續的方法加以衡量。

交付維度

我通常用餐館打比方來描述產品和服務交付之間的差異：如果外出用餐，我們關心的不僅僅是食物和飲品（產品），還有它們是如何送到我們面前的（服務交付）。“客戶”的立足點是這些組件質量的一個維度，我們可以稱之為外部視圖。另一個是內部視圖，來自于餐館員工。他們也關心產品和服務交付，但是，他們從不同的角度來看，比如：食物是否新鮮？是否保存在恰當的容器里？是否以適當的溫度烹飪？員工是否能良好協作？是否能互相補充技能？互相尊重？

因此，我們基本上有兩對維度：組件（產品和服務交付）和觀點（外部客戶和內部團隊）

在軟件交付中，我們有反饋環來回答這4個問題中的其中3個。還有更多的口語術語來描述內部-外部維度（“正確地構建東西”和“構建正確的東西”）。你猜猜少了哪個？

回顧和站立會等反饋環為團隊內部工作提供了有價值的反饋。但是，這些常常沒去考慮客戶的顧慮。我與無數團隊合作過，我們相處愉快并享受合作，但是，關于客戶對于他們交付工作的期望，他們卻毫無頭緒。回顧可以傾向內部，只把重點放在團隊關心的“產品不夠“的問題上。當然，有足夠的產品是重要的，但是，客戶不會在意。

問題是，我們通常沒有專門的反饋環來正確理解我們的服務交付目的是否合適。這通常是客戶同樣最關心的問題，有時候，甚至比產品的適用性更重要。我們也許會在演示過程中觸及團隊速度等問題，但是，與客戶就其關心的服務問題進行建設性的對話，我們還缺一個輕量級的架構。

服務交付審查是缺失的反饋環

我首先想到了來自看板方法的服務交付審查，這個想法作為其7個反饋環之一以驅動進化變革。我一直在整合這個，以幫助解答團隊無法圍繞其服務交付適應性來進行對話的問題，在某些情況下，這似乎提供了他們的所需。

我定義服務交付審查的方式與2014年David Anderson的方式很相似，只需稍作調整：

客戶和交付團隊就其服務交付的目的適應性進行定期（如每兩周一次）定量的討論。

在審查過程中，團隊和客戶可以討論以下任意一個或全部內容：

交付速度：交付工作項目有多快？散點圖可以顯示最近工作的交付時間（也即周期時間，在制品時間）。我們可以有怎樣的預測？交付時間分布可以量化我們的可預測性。

圖：散點圖示例

圖：交付時間分布示例

• 交付吞吐量：我們正在交付多少工作？比如，我們每周可以接受3到5個用戶的工作嗎？
• 混合工作：對于我們分配的各種工作類型，是不是每個人都感到滿意？比如，10%的分配工作是否能消除可接受的技術債務？
• 策略變化：對不同類型的請求，怎樣處理？不同的利益相關者是否期望不同的處理？我們遵循的策略還有哪些沒有明確說明？各種服務是否支持預期的速度和可預測性閾值？
• 截止日期績效（due-date performance）：對于那些真正以截止時間為導向的項目，我們在達到這些日期（錯過固定日期）方面做得如何？可接受的成功率是多少？要達到這個成功率，我們需要做些什么？要達到這個績效水平，我們的成本是多少？
• 一線數據：輸入的數據，包括來自適應性調查（如F4P成績）、一線員工報告和社交媒體。
• 障礙：有哪些事情阻礙我們實現期望的服務交付？量化這個問題的一種方法是，通過阻止聚類的實踐，Klaus Leopold和Troy Magennis推廣了該系統，他們通過利用看板系統識別和量化那些阻礙工作流動的事物，并審查結果和補救措施。

這些不是那些團隊通常在現有反饋環中討論的績效領域，比如回顧和演示。然而，要實現客戶最重視的價值的共同理解，它們的作用是相當強大和重要的。

根據我的經驗，它們會發現一些最（不必要）痛苦的誤解。比如，我們是否在產生所預期的工作量？如果太多，可以考慮把一些容量移到其他地方。如果不足，那為什么不是一個機會，把交付進行不同的分割？比如，我們也許決定接受更少的服務閾值，作為對其他業務投資的權衡，比如能力構建，而對高需求的服務來說，恰恰相反。

此外，由于它們同時是定量的和適應性導向的，服務交付審查幫助團隊和客戶一起建立信任，并積極主動地管理以獲得更好的適應性。

服務交付審查入門

服務交付審查做起來相對容易，以我的經驗來看，投入的時間越多，獲得的回報就越多。先決條件是：

• 了解服務
• 發現或建立服務交付的預期

Janice Linden-Reed在她的《看板節奏》演講中，非常好地概述了會議的實踐方面，包括參與者、要問的問題、輸入和輸出，這些都是練習開始的好地方。

我還開發了可自定義的畫布，為會議的輸入和輸出提供了模板。具體實施不如明確會議目的、所需的受眾和促進者、輸入、輸出和產出更重要。根據我的經驗，畫布還可以包括對完成時間、風險及障礙的預測。

如果從更基礎的層面開始，比如發現這些適應性標準，甚至可以試試“Yelp review（譯者注：Yelp是美國最大點評網站，Yelp review類似于大眾點評）”，這是我與客戶進行的有趣活動，通過要求他們基于與團隊相處的經驗，從未來的角度來寫Yelp風格的評論，讓他們從產品和服務團隊兩個角度出發來思考問題。比如， 一個利益相關者發現并分享了其自身沒有說出來的興趣，在工作用時比預期要長的時候，這些就被關聯上并被引入。通過可視化可能的場景，回顧幫助團隊的方式是相同的，通過提前寫“評論”，他讓團隊了解他沒有說出來的的適應性期望，隨后他們在服務交付審查中對這個進行管理。

服務交付審查的好處

我與很多高績效團隊合作過，他們交付了令人驚訝的數字產品，然而，當其客戶表示不滿意時，他們仍然感到奇怪。這很常見，原因是，他們要么沒有感知到對從客戶的角度來看，其服務交付沒有滿足客戶的要求，要么沒有反饋環定期量化衡量這個適應性。我共事過的一個高級管理人員甚至指出，他寧愿參加服務交付審查，而不是產品演示，因為服務交付是其及團隊能夠更直接改進的東西，可以通過團隊構建和其他組織變革來完成。

具體而言，服務交付審查對組織是有益的，原因如下：

• 迫使自己專注于客戶，變得適合他們選擇你的目的。故事點數（story point）不代表客戶的適應性或者選擇標準。沒有人會因為令人驚訝的速度而聘請你的團隊。
• 設立清晰的標準和目標
• 用（有意義的）數據生成反饋
• 幫助了解失敗的原因，然后調整改進工作
• 建立客戶信任和忠誠度

此外，很多組織正在進行某種所謂的“敏捷轉型”，有時候只是簡單地堅持儀式。Andy Carmichael鼓勵組織通過對目的適應性，而不是實施采用來衡量敏捷性。服務交付審查是明確地反映了這一點的反饋環。然后，多個服務交付審查會向上進行定期運營審查，從而獲取服務交付輸入，并給管理人員更高階的決策制定提供視圖：基于組織（或部門）的目標，一些服務需要更多能力，如果是這樣的話，那么可以減少哪些，可以提供哪些？我們在查看什么系統級的模式，而這些模式是可以用來解決多服務的？一些組織已經通過安裝SAFe等框架解決了擴展問題；服務交付審查、運營審查和對目的的適應性思考的組合是個備選方案，它可以讓組織能夠繼續改進每個服務，以獲得更好的適應性，并創建持續感知客戶的適應性預期的機制。

最終，組織和團隊需要一些方法來感知并響應其外部和內部的客戶。在David Anderson和Alexei Zheglov的《適應目的（Fit for Purpose）》一書中斷言：

“反饋環越緊湊，企業就可以展示越好的敏捷性，并可以越快地感知并越快響應?！?/p>

---

作者簡介

作為能力培養者、組織適應性教練和工作場所活動家，Matt幫助組織和團隊持續地適應其目的。他對構建學習型組織和創建人性化及引人入勝的工作環境尤其充滿激情?？梢酝ㄟ^@mattphilip在推特上關注他。

閱讀英文原文：Service Delivery Review: The Missing DevOps Feedback Loop?

總結

以上是生活随笔為你收集整理的服务交付审查：缺失的DevOps反馈环的全部內容，希望文章能夠幫你解決所遇到的問題。

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