服务交付审查：缺失的 DevOps 反馈环

在当今的数字服务经济中，IT 组织不仅需要有改变的能力，也需要按正确的方向改变。这意味着，他们需要能够感知反馈，并做出响应，以便持续地识别和衡量自己对目标适用性的理解与客户看法的差距。

当然，标准的敏捷反馈环是由这三个部分构成的：产品演示、团队回顾和自动化测试，它们提供了产品健康和适用性方面的宝贵意见。然而，还是有很多团队和利益相关者在苦苦寻找一种可靠的方法来理解反馈的重要领域：服务交付的适用性。

本文引入服务交付审查，并将其作为该反馈的论坛。

数字化组织需要能够感知客户，并作出响应

Jeff Sussna 在其《设计交付（Designing Delivery）》一书中写到，服务供应商必须承诺倾听客户的声音，并在制作和交付方面尽可能做出响应。市场变化如此之快，以至于 5 年甚至 5 个月前的工作，不知不觉之间就销声匿迹了。在意识到这一点之前，团队或组织就已经不再适合曾经为之服务的目的了（看看 Blockbuster、Kodak 等等就知道了）。最重要的是，除了高大上的使命和宗旨声明之外，Jeff Sussna 指出，组织的存在是为了继续存在下去。

也就是说，我们做生意是为了继续做生意。因此，组织必须不断寻求理解客户选择他们的理由。但是，不要简单地假设客户（无论是内部还是外部的客户）因为产品的质量而选择我们。我们如何评估工作中不太明显的方面呢？

什么是服务？从“看板”的角度来看看组织

部分困难源自于只从产品的角度来看组织。但是，组织通常也有服务组件。甚至像咖啡店这种普普通通的东西也不仅仅光是卖杯咖啡什么的（其实绝大部分人认为星巴克不是只做产品或服务，而是两者兼有）。

对于技术组织来说也是如此。如果我们应用 Rodrigo Yoshima 和 Andy Carmichael 称之为“看板镜头”的东西，就变得更容易理解。看板镜头是一种来“看”组织的方式，具体来说是：

• 把工作看成流

• 把知识工作看作服务

• 把组织看作是服务网络

当“戴上”看板镜头时，就像戴着一副有超能力的护目镜，可以从传统的组织图表看起，一直到组织中随处可见的服务。从人们的选择看到面向客户的交付工作！

只要有能看到它们的镜头，那么服务无处不在。遗憾的是，通常只有在不满意时，我们才会注意到它们。不久前，我在自己的组织中“发现”了一个内部服务：我的团队创作了一个要给领导层看的演示文稿，因此，我们希望它看上去是精心打造的。不幸的是，我们都没有视觉设计的才能，于是，我们请设计团队的人帮忙。得到的回答是“有截止日期吗？”我们还没有定截止日期，但是，我们也不知道总是忙忙碌碌的同事什么时候可以出手相助。这显然是一项对内部客户的（设计）服务，内部客户知道什么能适合其目的。在这个例子中，得有个明确的截止日期。

我们总是这样向个人和团队提出请求。但是，如果没有信息的相互交换（比如，预期的交付速度），就只能用额外的时间或按错误的截止时间来做了 。如果没有任何关于服务交付绩效的定量反馈，就会一直有任意的截止日期和人为的界限。在我的组织设计服务案例中，如果我们透明且定量地交付数据，就可以更容易地交换信息，更有效率地询问预期。这反过来，又会促进信任。

从适用性的角度来考虑服务交付

服务交付的适应性是什么意思？

首先，团队和利益相关者是否知道他们的客户对其服务的评价？

其次，他们是否知道如何来衡量？

再者，是否有定期的反馈环从客户的角度来评估服务适应性？

问一问适应性问题，如：为什么选择我们？对我们提供的服务有何评价？这是好事，但是，回答可能会随着时间的变化而变化。通常情况下，服务随时间的变化是否还符合选择的标准，以及是否还与原标准保持一致，团队并没有持续的方法加以衡量。

交付维度

我通常用餐馆打比方来描述产品和服务交付之间的差异：如果外出用餐，我们关心的不仅仅是食物和饮品（产品），还有它们是如何送到我们面前的（服务交付）。“客户”的立足点是这些组件质量的一个维度，我们可以称之为外部视图。另一个是内部视图，来自于餐馆员工。他们也关心产品和服务交付，但是，他们从不同的角度来看，比如：食物是否新鲜？是否保存在恰当的容器里？是否以适当的温度烹饪？员工是否能良好协作？是否能互相补充技能？互相尊重？

因此，我们基本上有两对维度：组件（产品和服务交付）和观点（外部客户和内部团队）

在软件交付中，我们有反馈环来回答这 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）》一书中断言：

“反馈环越紧凑，企业就可以展示越好的敏捷性，并可以越快地感知并越快响应。”

作者简介

作为能力培养者、组织适应性教练和工作场所活动家，Matt 帮助组织和团队持续地适应其目的。他对构建学习型组织和创建人性化及引人入胜的工作环境尤其充满激情。可以通过 @mattphilip 在推特上关注他。

阅读英文原文：Service Delivery Review: The Missing DevOps Feedback Loop?