Один из законов системантики (John Gall) гласит — любая сложная система эволюционировала из простой системы.

В 2006 году Amazon запустил сервис хранения данных S3. У него не было UI. Только API и документация.

Чуть позже появился UI под названием AWS Console. Его разрабатывала отдельная команда «фронтендеров».

Году так к 2010-му эта команда поддерживала около 10 сервисов в едином монолитном UI, где у каждого сервиса была своя закладка (tab).

В какой-то момент это перестало масштабироваться:

1. Команда консоли перестала поспевать за бурно растущей экосистемой сервисов.

2. Стало слишком много доменов, в которых была нужна экспертиза. Помимо хранения данных появились виртуальные машины, базы данных, IAM и много ещё чего. Во всем этом нужно было разбираться + некоторые сценарии требовали уникальных компонентов.

3. Табы с сервисами тупо перестали влазить в экран.

Тогда было принято решение децентрализовать разработку интерфейсов. Каждая из сервисных команд стала разрабатывать свои собственные UI (веб-аппы, по одной на каждый регион), а команда консоли взяла на себя ответственность за платформу — роутинг запросов по вебаппкам, сбор метрик, аналитика, хранение настроек и т.п. Они также отвечали за домашнюю страницу, общую менюшку и футер.

Табы со списком сервисов сначала превратились в «море иконок». Потом в море иконок с подзаголовками. Потом в море иконок, которое перестало влазить в экран ноутбука.

Команды использовали свои собственные фреймворки. Кто-то писал на GWT, кто-то на Angular, кто-то на Spring, потом стал появляться React.

В UI фреймворках так же был зоопарк от Twitter Bootstrap до самописного не пойми чего. Всё выглядело, мягко говоря, самобытно.

Это был Conway’s Law на стероидах. Интерфейсы выглядели так, как будто они были созданы разными компаниями.

Я пришёл в команду AWS Console вторым продакт менеджером (вскоре - единственным) в 2015 году. Моим менеджером был чел, который создал первый UI, уперся в ограничения централизации и разблокировал рост через децентрализацию.

В 2015 организация уперлась в новое ограничение — слишком много децентрализации создало много дублирующего функционала и систем. На тот момент было несколько сотен отдельных веб-аппов, разрабатываемых отдельными командами так, как им было удобно, как будто пользователи пользуются только их сервисами, а не платформой в целом.

Следующие 5 лет мы занимались стратегической трансформацией, пытаясь сохранить децентрализацию, при этом делая интерфейсы более консистентными.

В нашей команде родилась библиотека компонентов и дизайн-система. Её переделывали два раза. В первый раз она была слишком opinionated (это когда забыли спросить у пользователей, как им нужно, и сделали, как считали сами).

На то, чтобы команды начали мигрировать на новую дизайн-систему ушли годы, так как это не контрибутило в бизнес-метрики конкретных сервисов. Это были бесконечные встречи, переговоры и общие годовые цели с другими организациями.

Был даже знаменитый емейл с вопросом от Безоса. Кто-то пожаловался ему на шизофреничность интерфейсов.

В той команде я познал насколько это неблагодарная работа — управлять быстрорастущей платформой с багажом легаси, где каждый бизнес-юнит думает только о своих показателях.

Когда я уходил в 2020, интерфейс AWS был относительно консистентный, но даже тогда еще нет-нет да можно было наткнуться на bootstrap в каком-нибудь из тёмных уголков за тремя менюшками.

Когда кто-то критикует продукты больших компаний, я не могу не согласиться с тем, что «они ужасны», но при этом я понимаю, насколько люди наивны в своих предложениях а-ля «это же так легко сделать <визуально простое изменение в интерфейсе>»

Каждый продакт, который приходил в мою команду, прошел через все фазы принятия. От «ща я вам тут все пофиксю» до глубокой депрессии.

Сделать изменение в небольшой компании (или там где нет легаси) — это как скатиться с горы на велосипеде.

Сделать изменение в большой платформе — это как перенести гору на соседнюю тектоническую плиту.