一个优秀的平台应该“够用就好”

👆点击“博文视点Broadview”，获取更多书讯

一个设计优秀和运行优秀的平台，用Henrik Kniberg的话来说就是“用户驱动的平台团队”，其对于组织内的软件交付而言具有明显的促进作用。

但值得注意的是，平台总是应该满足使用应用和服务的需要，而无须关注其他方面。

一个优秀的平台要提供标准、模板、API及经过验证的最佳实践，帮助开发团队快速创新和高效工作。

一个优秀的平台能够简化开发团队的工作，按照正确的方式做正确的事情。这不仅针对软件开发，而且对任何类型的产品开发来说都是如此。

然而现实中经常遇到的情况是，平台由之前的系统管理人员构建和运行，并且开发过程中也没有应用优秀的软件开发方法（敏捷实践、TDD、持续交付、产品管理等），或者平台开发在组织层面得不到资源投入和关注，以至于无法给其他团队带来帮助，甚至会伤害其他团队。

01

最小可用平台

最简单的平台可能仅仅是Wiki上的一个列表，描述了供外部软件消费的底层组件或服务信息。

如果这些底层组件或服务总能可靠运行，那么就没必要组建一个全职的平台团队。

然而，随着底层系统变得越来越复杂，甚至有些时候所有组件和服务都交给外包团队，一个平台团队要能够在平台细节之上提供一组有价值的抽象管理层，用于协调新的和已弃用的API和组件。

如果组织希望构建定制化的解决方案并将其集成到平台上以满足开发团队的需求，那么平台团队负责的领域就会随之扩张。

为此，我们的目标是搭建一个最小可用平台（Thinnest Viable Platform，TVP），而不是让平台面面俱到。

就像Allan Kelly所说的，“软件开发人员热衷于构建平台，如果没有强有力的产品把控，那么平台的能力就会远超真实需求。”最小可用平台是保持平台小而美，以及让平台帮助团队简化和加速软件交付。

02

降低认知负荷，加速产品开发

让我们回顾一下过去几十年里那些成功并且广为人知的软件技术平台：IBM 8086处理器、Linux和Windows操作系统、Borland Delphi、Java虚拟机、.Net框架、Pivotal Cloud Foundry、Microsoft Azure，以及最近的物联网平台balena.io和容器平台Kubernetes。

这些平台普遍都是成功的，降低了底层系统的复杂度，并且给使用平台的团队提供了足够多有用的功能。

如康威所说的，这让开发者的世界变简单。

降低使用者的认知负荷（详见《高效能团队模式》一书第3章）是一个优秀平台的关键评判标准之一。

通过降低开发团队的认知负荷，一个优秀的平台帮助开发团队聚焦于业务问题本身，可以加速个人和团队的开发速度，从而让整个团队更高效地工作。

就像国际出版集团康泰纳仕（Conde Nast International）的Kenichi Shibata所说的，“平台最重要的就是面向开发者提供服务。”

03

充满吸引力、一致性、必要的约束

如果脱离团队需求来开发平台就陷入了一个典型的困境，为了避免这种情况的发生，需要确保平台团队关注用户体验（UX），尤其是开发者体验。

也就是说，当平台规模扩张时，需要将用户体验能力注入平台团队。

如Shibata所说：“如果不这样做，开发人员经常会有挫败感……应该为平台开发人员提供一种反馈途径来了解平台究竟做得怎么样。如果不能做到这一点，平台就成了公司内部的孤岛，难以让团队真正用起来。”

良好的用户体验和开发者体验能够让平台充满吸引力，同时能够让平台的功能特性和API层面保持一致。

用户操作手册及其他文档可以覆盖所有功能（无须过度冗长）且实时更新，聚焦达成特定任务目标的方法，而不是面面俱到地罗列平台所有细节。

平台应该帮助开发团队扫清障碍，确保团队能够在没有那么多条条框框的前提下开发自己所需的功能。

新开发人员上手平台的容易程度是对开发者体验的很好的检验。

04

基于底层平台开发

所有软件应用和服务都是基于平台开发的，通常平台并不起眼或者并没有引起构建软件团队的足够重视，但即便如此平台依然存在。

正如一句富有哲理的话所说的：It’s turtles all the way down（一切建筑皆有底座）。

在软件领域，这个比喻意味着每个平台都是基于另一个平台构建的，即便它的底层平台是隐藏和不可见的。

如果底层或下层平台无法稳定运行或者设计上有缺陷，那么上层平台也会变得不稳定，无法提供加速组织内其他软件交付所需的坚实基础。

如果底层平台存在运行漏洞或者性能问题，那么平台团队就需要构建隔离抽象和给出临时解决方案，或者通知开发团队这类潜在问题来避免他们踩坑。

Stafford Beer的经典著作Brain of the Firm中的多层可用系统模型（Viable-Systems Model，VSM）描述了这种情况。

小贴士

可以绘制一张全景图来描述你所在组织的平台层级关系。这将帮助各个内部平台团队及使用平台的开发团队理解这些平台能提供什么，以及彼此的依赖关系。

05

像线上产品或服务一样管理平台

平台需要明确定义服务可用时间，并周知用户（开发团队）。用户依赖平台的可用性，同时需要了解什么时候会上线新特性，而旧特性什么时候会下线。

因此，为了帮助开发团队用户更高效地使用平台，我们需要做到：

（1）把内部平台视为线上/生产系统，计划和管理维护时间；

（2）引入软件产品管理和服务管理技术。

当我们把平台视为线上或生产系统的时候，就需要采取类似其他线上系统的各项活动和实践：定义服务在线时间、定义故障和支持响应时间、安排支持平台的轮值表、使用适当的沟通渠道（比如通过服务状态网页）管理故障和宕机时间等。

当然，随着平台的成长，应该不断反思团队究竟需要什么服务，以及平台能够提供什么服务，以此来应对平台团队不断增加的运营工作。

Kenichi Shibata认为，“平台团队的主要用户应该是产品团队。”

那么，我们如何管理有确定目标用户群和运行时间的线上软件系统呢？答案是，引入软件产品管理。

因此，应该由产品管理人员确定平台的发展规划，同时与开发团队进行沟通讨论，至少要考虑开发团队的需求。

平台团队几乎肯定会制作用户画像，比如网页开发工程师Samir、测试工程师Jennifer、产品负责人Mani、服务体验工程师Java等。

用户画像方法将帮助平台团队了解并聚焦典型用户的需求、痛点和目标。

平台团队的成员应该与开发团队用户定期沟通，了解他们的需求。

关键在于平台这个“产品”的演进，不应该只是简单地接收并实现开发团队提出的需求，而是应该精心打磨以满足他们的长期需求。通过指标来跟踪特性的使用情况，用于评估开发优先级。

平台不仅是开发团队在过去某个时间点提出的一组特性的集合，而应该进行整体的、精心的、一致的设计，并且考虑技术发展变化的趋势，以及组织不断变化的需求。

一个好的平台也应该能减少安全和审计团队对开发团队的打扰，直接提供相应的数据和信息。

* 本文摘自《高效能团队模式：支持快速交付的组织架构》第5章“四类基本团队拓扑”。

▊《高效能团队模式：支持软件快速交付的组织架构（全彩）》

[英] Matthew，Skelton（马修・斯凯尔顿），[西班牙] Manuel，Pais（曼纽尔・派斯） 著

石雪峰，董越，雷涛 译

• 软件开发组织架构的优秀模式（团队拓扑）
• 企业数字化转型组织结构指导书
• 结合大量知名企业案例
• 有助于软件快速交付

六折专享

快快扫码抢购吧

如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连

 热文推荐  
阿里云专家带你揭秘云计算数据底座
小白也能2周搞定3个月的Web开发任务！
如何高效工作，享受品质生活？
立于山巅！他，凭什么抗住万亿级流量冲击

▼点击阅读原文，查看本书详情~