“Designing Delivery”图书评论与访谈

Jeff Sussna 的书“ Designing Delivery ”不只深入研究了公司该如何考虑他们的经营方针，还表现出了对客户真实期望的深刻理解。这些包括贯穿整个客户生命周期的提交新项目速度、BUG 修复的速度、运营绩效（随时随地访问）和积极的品牌参与（跨越多个平台、多种设备）。

简而言之，在当今时代作为一个服务型公司（目前为止大多数公司都是）所要面临的挑战可以归结为关于成功所需要具备的全面资质结构，可以洋洋洒洒地讲上大半天。尽管公司高管都是本书的目标读者（因为他们应该而且也能了解公司的整体状况和不足），他们应该非常小心，如果想要不断的改变自己尝试成为一个“以客户为中心的品牌”的话，自己先要具备一定成熟度才行。如果开发团队不敏捷、运维不接受 DevOps 或者研发团队不拿设计思维当回事，那他们可以就此打住了。

对于其他人，阅读这本书的过程会非常享受。对许多人来说这是一个关于未来的预言：大多数服务型公司要求她的员工们具备的技能和态度。

第一部分解释了为什么服务提交必须是一个以客户为中心的过程：永不结束、不断适应客户需要。里程碑驱动型公司需要转变：改进内部的提交和管理流程。而且，他们应该关注从客户的角度去发现产品的价值，意识到倾听客户反馈并做出迅速调整是多么重要。

第二部分在这种新的商业模式下详细地重新定义了质量。它从四个维度描绘了客户的期望（客户通常自己也意识不到）：客户成果（要做成的事）、可获得性（随时随地需要）、一致性（经历时间变化和多种客户感受渠道）和持续性（适应客户需求的变化）。QA 的新角色定义不仅要验证客户的使用体验，还要验证包含在服务设计里面的其他内部角色的体验：开发、运维、客户支持等。

“QA 就是用来验证一个服务型公司利用改变来帮助自己不断改进的能力”。

第三部分引入了承诺理论作为服务型思维的基础，将服务理解为对客户的一系列承诺。事实上，做出了承诺，就意味着很大程度上可能会无法遵守承诺。这样对于一个服务型公司，服务型思维就是要准备并拥抱失败，只要它会促使大家积极学习并可能由此做出更成功的承诺。打个通俗的比方，当前大家使用的社会技术系统从根本上来说就太复杂了，所以自然会在不可预见的方面出问题。

“问一个服务型公司做出的承诺是否恰当，其实就是在确认需求。问一个服务型公司要做些什么来实现承诺，其实就是分析和发现实现过程中潜在的问题。问除此之外还要做些什么来实现承诺，其实就是集成测试”。

InfoQ 有幸采访了 Jeff Sussna 来更好的了解书后面的想法：

InfoQ: 请问您写这本书的动机是什么？

Jeff Sussna：最近几年我在各种不同的会议上做了一系列讲座。所有讲座都是关于同一件事的：在当今的 IT 公司中把设计与工程结合起来的必要性。同期我读到了一本 Norbert Wiener 的自传，让我对控制论的历史和理论进行了深入思考。我也研究了 Mark Burgess 关于承诺理论的工作成果，本质上是非常符合控制论原理的。这些全都萦绕在我的脑海中，这本书就是尝试着向大家阐述一种新的思维方式，以及一种应用这种新思路的方法。

InfoQ: 请问您的职业生涯是如何体现到书中的？

Sussna：我领导团队构建各种系统，经历过整个开发 -QA- 运维周期。我也做过各方面工作，从编译器到内容管理系统、再到数据中心自动化平台等等。这些经历让我对普遍意义上的 IT、尤其是 DevOps 有了一些独到的见解。

我有文科背景。我是看着弗兰克·劳埃德·赖特（ Frank Lloyd Wright ）建筑的相片长大的。在大学里我学过人类学、社会学与艺术理论。前几年我在读 Tim Brown 的关于设计思维的书“Change By Design”时我有了些顿悟。我突然明白我并不是那种传统意义上的开发者，我常常是从设计思维的角度去解决问题的。从那时起我就发现了这个设计思维的旁支，即服务设计。它表明，因为 IT 已经越来越与服务有关，越来越直接与普通人相关，我们就该象设计别的服务一样设计它。

总之，我的背景和这本书的内容还是符合度很高的。

InfoQ: 你说控制论是一个远在大多数人看到动画片之前就存在了的概念。你能说说为什么在当今世界中它的原本含义仍是非常重要的吗？

Sussna: 本质上来说，控制论把控制过程看成是环形的而不是线性的。举个最简单的例子，是恒温控制器在控制屋子中空气的温度，还是空气在控制着恒温控制器的运行？答案是肯定的。产品型经济不断把事情和信息推送给客户，服务型经济逼迫公司与客户合作创造价值，当我们从产品型经济转向服务型经济时，我们需要用环形方法来进行控制。而且，因为我们现在面对的世界和问题越来越复杂，我们就需要进行更多思考，来让我们能有方法解决更多的复杂问题，而不只是把一些静态的解决方案拼凑起来。控制论（cybernetics）这个词来源于古希腊语（kybernetes），字面意思就是“良好的操纵”。在面对复杂问题时解决方案不应该只是“行得通吗？”，更多的应该是“我们操纵得好吗？”。

InfoQ: 书中强调了一个衡量当今公司的方法，就是看它们能如何又快又好的地改变自己的服务来应对客户不断改变的需求。那能不能说服务提交必须包含多方面的内容，而不只是技术提交（IT）？

Sussna: 完全正确！客户是通过从整体上判断他们与供应商之间的关系来判断服务价值的。说一个饭店好不会只是说食物好，也不会仅仅说食物和服务好，还要包括好的就餐氛围、价格、停车位、周围环境和方便易用的网站来让大家查看菜单等。现在所有的业务都在转变为服务型业务，所有的业务都在转变成数字型业务，IT 公司和其他类型公司之间的界限正在消失。如果你的产品功能很好，但是不能扩展、或者不安全、或者不易携带、或者客户支持比较差、或者你的主页上没能充分说明你的服务到底是干什么的或者为什么一定要用你的服务、或者你不能很好的处理故障和安全问题……等等，上述任何一方面的问题在你的客户眼中都意味着质量降级。

InfoQ: 从公司的角度该如何看待这种持续演进服务的思想呢？他们是不是需要改组公司架构来获得成功？

Sussna: 他们必须让员工和团队按照新的行为准则来工作。从个人角度来说，与具体的公司架构相比，我更看重的是行为和态度。我觉得让设计人员、开发人员和测试人员向不同的经理汇报是完全可以的。他们要做的是彼此之间进行合作和相互支持，要认识到彼此之间是不断的为对方提供服务，头脑中要有很强的分享和服务客户意识。

InfoQ: 你理想中的数字化服务的持续演进组合不止包括控制论、敏捷和 DevOps，还包括设计型思维。可是看起来设计工作并没有和技术交付物紧密相连。你认可这一点吗？你准备怎么改善？

Sussna：将设计与工程结合起来并不仅仅是让设计师和开发者更紧密的一起工作，它也是关于如何把设计应用于 IT，使 IT 成为一个艺术品设计。比如我们可以重新从以用户为中心、以服务为中心的角度设想一下 ITIL 突发事件管理、服务热线软件和工作流吗？？我们更关心了结工单，还是帮助客户解决他们的问题呢？

InfoQ: 您能简单地解释一下对您来说持续设计是什么、它与持续提交和质量的关系吗？

Sussna: 持续设计打破了设计与运营的边界。就象恒温控制器不断对空气的温度变化做出响应一样，持续设计也会不断对运营的反馈做出响应。持续设计具体表现在多个层次上：

1. 时间上持续：与 40 年如一日地生产和销售咖啡杯不同，设计过程永远不会停止。
2. 在整个生命周期持续：A/B 测试、游戏日、Chaos Monkeys 等都表明在生产过程中也会和别的过程中一样有设计。
3. 在整个公司内持续：公司的每一个部门，不管是设计还是开发部门，或者微服务团队，对公司的其他部门都是服务提供者，因此必须不断的从他的下游的角度设计和提交它的能力。
4. 持续提交是持续设计的一个必要而不充分的组成部分。可以认为持续质量可以作为对一个做持续设计的公司是否成功的一种考查标准。

InfoQ: 人们考查一个已完成的软件产品的质量时，以前常用的标准就是看发现了多少缺陷，或者从商业角度看签了多少合同或卖出去多少个许可证。当我们从持续运行的服务角度去考虑时，该如何定义质量的改变呢？

Sussna: 我们必须用控制论的方法从事数字业务的原因是事实上我们正在不断失败。即使我们能把一个功能设计和实现得非常完美，只要客户一开始用，他们的需求就会开始改变。常见的反馈是“不错，但你能不能让它做做什么什么？”。对一些功能的真正用法会让客户改变想法，进而改变设计。因此我们就是在不断的细化和发现在真实需求和已有能力之间的差距。因此，质量已经从由故障发生的平均间隔时间标志的稳定性，开始转换为弹性和应变性，或者说修复所需的平均时间。只要我们倾听客户反馈，对他们的要求做出反馈，我们就在成功的路上。

InfoQ: 你是说每一个公司现在都是服务生态系统中的一员，每个公司都同时担任着生产者和消费者的角色。那就管理服务依赖方面，有没有什么好的做法推荐给大家？

Sussna: 这就是引入承诺理论的原因了。“承诺”这个词首先意味着我们对别人做出承诺，然后我们非常重视它，去实现它，不管要付出多大代价。可另一方面，它也意味着我们不能假定我们所依赖的别人承诺一定会实现。不管我们说的是人的承诺（“我保证在你打客户支持热线电话的时候会帮你解决问题”）还是系统承诺（“我保证不管有多少用户在用，10 毫秒内都可以把网站页面显示出来”），把服务做为承诺提交都可以产生大家喜欢的低耦合，让系统功能连贯地推出，而不会导致大范围系统故障。

InfoQ: 你认为以客户为中心的服务会需要新的服务支持方法来重新吸引心中已有不满的客户，并把他们的反馈转达到公司的其他部门吗？

Sussna: 我觉得从客户支持向后的整个服务型公司的所有部门都要转变思路，从“给客户做东西”到“帮客户达到预期目标”。具有讽刺意味的是，ITIL 在这方面对服务的定义非常准确。如果能完成这种转变，我们就可以形成一种态度和行为，让反馈可以传达到整个公司，而不是早早的被雪藏起来。

关于被访者

Jeff Sussna是一位国际公认的 IT 顾问和设计思维实践者。他因将 DevOps 与同理心的重要性联系起来而在 DevOps 社区中享有盛名。Jeff 有近 30 年的软件开发、QA 和运维经验，在财富五百强、大型技术公司、软件服务初创公司和媒体企业集团等负责过项目。他是“Designing Delivery: Rethinking IT In the Digital Service Economy”的作者，也是在敏捷、DevOps、开发等方面极受尊敬的教师、作家和演讲家。

阅读英文原文： Designing Delivery Book Review and Interview