Apple Maps провалились не из-за карт, а из-за качества данных и интеграций
Неудачный релиз Apple Maps - лучший публичный урок по источникам данных, контракту качества и цене обратной связи от пользователей.
В сентябре 2012 года Apple выпустила iOS 6 с новым картографическим приложением, заменив Google Maps, который был на всех iPhone с самого начала. Реакция оказалась громкой - и не в хорошем смысле. Отсутствующие города, неверные адреса, мосты, уходящие в воду, аэропорты посреди полей. Тим Кук написал публичное извинение. Это редкость для Apple.
Можно объяснить это тем, что Apple поспешила, недооценила сложность или переоценила свои возможности. Всё это верно. Но за этим кейсом стоит более системный урок о том, как данные ведут себя в продуктах, которые от них зависят.
Откуда берётся картографическое качество
Карты - это не одна база данных. Это слои: геометрия дорог, адреса, точки интереса, подписи, бизнесы, маршруты, спутниковые снимки. Каждый слой - отдельный источник данных, отдельные поставщики, отдельная история обновлений, отдельный контракт качества.
Google строил эту инфраструктуру постепенно с 2005 года: скупал компании, подписывал контракты с муниципалитетами, организовывал полевые съёмки, строил флот машин для панорамных съёмок, вручную верифицировал бизнесы. И параллельно собирал обратную связь от сотен миллионов пользователей, превращая её в поправки.
Apple начала этот путь позже, с разными поставщиками, и у неё не было такой базы живой обратной связи. Интерфейс был красивым. Данные под ним - неполными.
Контракт качества с источником данных
Один из главных уроков этой истории - разница между "данные есть" и "данные достаточно хорошие для этого применения".
Поставщики картографических данных предоставляют покрытие - но покрытие не равно точности. Данные по крупным городам могут быть свежими, а данные по малым населённым пунктам - трёхлетней давности. Адреса могут существовать в базе, но быть привязаны к неправильной геометрии. Категории точек интереса могут не совпадать с тем, что пользователь считает очевидным.
Это называется контракт качества: явное определение того, что именно гарантирует источник данных и в каких условиях эта гарантия работает. Без него вы интегрируете данные в продукт, не зная реальных границ их применимости. Та же логика работает внутри компании ещё до того, как дело доходит до аналитики.
Обратная связь как часть системы качества
Google Maps работает не только потому, что у Google хорошие данные. Он работает потому, что у Google огромный поток обратной связи: миллионы пользователей, которые сообщают об ошибках, предлагают правки, открывают приложение ежедневно и тем самым дают сигнал о том, что используется, а что нет.
Это не декоративная функция "сообщить об ошибке". Это производственный конвейер поддержания качества данных. Apple в момент запуска такого конвейера не было.
Любая система, которая работает с данными, нуждается в петле обратной связи - способе узнавать, когда данные расходятся с реальностью. Без этого деградация качества невидима до тех пор, пока не становится скандалом.
Что это значит за пределами карт
Этот паттерн встречается не только в картографии. Он встречается везде, где продукт зависит от внешних данных:
- Справочник контрагентов, который не обновляется после первоначальной загрузки.
- Каталог товаров, который живёт в нескольких системах с разными версиями одних и тех же позиций.
- Ценовые данные, которые поступают от поставщика с задержкой или пропусками.
- Нормативная база, которую импортировали однажды и забыли проверять.
В каждом из этих случаев вопрос не в том, есть ли данные. Вопрос в том, насколько они соответствуют реальности в каждый конкретный момент - и есть ли у вас способ об этом узнать.
Вопросы для проверки своих источников
- Для каждого внешнего источника данных в вашей системе: когда последний раз проверялось его качество?
- Есть ли у вас явный контракт с поставщиком о том, что именно он гарантирует?
- Как вы узнаёте, что данные устарели или стали неточными - до или после того, как это заметил пользователь?
- Есть ли у пользователей способ сообщить об ошибке в данных, и куда идут эти сообщения?
Ответы на эти вопросы определяют, насколько управляемым будет качество вашего продукта по мере его роста.