White paper: Google's Hybrid Approach to Research

Александр открыл выпуск шуткой: в прошлый раз, на главе про отказоустойчивость, тест на отказоустойчивость не прошла сама доска Miro и рассказывать пришлось голосом; отдельных слайдов он не сделал и теперь, но доска работала. Гости представились сами: Игорь Маслов руководит в группе компаний направлением базовых технологий обработки данных — это внутренние инструменты, которые повышают продуктивность и эффективность инженеров, и на них уходит, по его словам, 99% рабочего времени. Станислав Моисеев работает в подразделении Игоря и курирует инженерные исследования, помогая выводить компанию на передовой уровень. Сам white paper, напомнил Александр, появился в 2012 году, один из авторов — Питер Норвиг, а содержательного текста в нём буквально пять-шесть страниц.

Начинается она с миссии Google — организовать информацию мира и сделать её универсально доступной и полезной — и выводит из миссии три следствия: экономику масштаба, где информации много, а командам нужны мощные абстракции вычислений, хранения и сети в дата-центрах; модель поставки вокруг сервисов, где команды разного размера собирают сложные продукты на внутреннем инструментарии; и возможность нанимать людей, которые тянут не только продуктовые фичи, но и исследование по дороге. Один из гостей подчеркнул то, что легко пропустить в первых абзацах: Google хочет, чтобы исследования заканчивались близко к продакшену, а системы строились сразу готовыми к использованию — для исследовательской работы это необычно. Широко подход раскладывается на пять пунктов: идти в интересные компании направления; резать большое исследование на короткие шаги, каждый из которых даёт результат — внедрение, статью, локальное улучшение или хотя бы отрицательный эксперимент; опираться на огромную инфраструктуру и пользовательские данные; собирать команды гибко, без единственно верной схемы; и распространять знания через статьи, стандарты и open source.

Ключевой слайд статьи Станислав описал как перебор всех способов соединить жёлтый и зелёный кружочки. Первый вариант: инженерная команда делает свои задачи по расписанию, вдруг получает что-то, чего ни у кого не было, и решает рассказать об этом миру. Бывает так нечасто: командам неинтересно формулировать и публиковать результат, мешает KPI или просто нет привычки выделять собственные наработки. Google приводит здесь свой пример: практическую задачу обработки больших данных они решили первыми в мире, хотя сама идея не так уж сложна и функциональное программирование стоит на том же. Один из гостей назвал вариант отчасти лукавством: команда, которая хранит весь интернет, делает исследования просто чтобы система работала день за днём, а статьями оформляет их потом. Александр добавил: у Facebook инженерных статей немного, зато бесконечно много про социальные сети и графы, а как пошла история с VR — появились статьи и по ней.

Второй вариант — исследовательская команда с темой вроде автоматического перевода, живущая по внутренней логике; пример от Google здесь Google Translate, который стартовал как исследовательский проект. Участники отметили, что такой сценарий требует денег и людей на рискованные проекты и говорит скорее о продукте, чем о технологии. Третий — конвейер «сначала research, потом develop», который сами авторы называют традиционным и которому противопоставляют свою гибридность: исследователи отдают технологию, а инженерная команда доводит её до продуктового качества, правит исходники, гоняет тесты по безопасности, пишет документацию. Четвёртый Станислав честно не смог отличить от третьего ничем, кроме плотности общения, и заметил, что на схеме нет ни внешних партнёров, ни университетов. Игорь провёл границу иначе: в четвёртом команды вместе берутся за понятную бизнесу проблему, а третий — это когда он долго жмёт данные, а потом приходит команда YouTube и говорит «вау», и трафика становится сильно меньше. Пятый вариант — отдать исследовательскую задачу партнёру, после чего отношения сводятся к одной из первых четырёх схем. Андрей из чата спросил, какой вариант нравится гостям самим: у Google работают все, первый встречается реже, второй требует культуры и денег, третий самый надёжный и классический, а четвёртый — самый классный.

Схемы напомнили Александру книгу двух консультантов 2019 года про топологии команд: стримлайн-команды вокруг бизнеса, платформенные команды, enabling-команды, которые подключаются и помогают, и команды сложных подсистем, экспертизу которых дорого держать в каждой команде. Режим коллаборации из книги — это ровно четвёртый вариант: продуктовая и платформенная команды договариваются, как будет выглядеть продукт, и делают его вместе. Но коллаборация дорога, две команды тратят на обсуждения много времени, поэтому цель — довести контракты и поверхность продукта до состояния, когда он предоставляется как сервис и потому хорошо масштабируется. Присоединившийся позже участник принёс тезис из своего опыта в аутсорсинге: там R&D обычно выливается в проект, а не в продукт. Александр возразил, что настоящее исследование отдают не аутсорсеру, у которого нет компетенций переднего края, а лаборатории в университете, и называть это лучше партнёрством, разбитым на этапы с инкрементальным результатом.

За десять лет после статьи Google не остановился: на странице про философию исследований появилась классификация по четырём осям — фундаментальные исследования, новые продукты, вклад в существующие продукты и инфраструктура. Робототехника проходит у Google по фундаментальной оси, тогда как для Amazon с его складами это сугубо прикладная задача; машинный перевод вырос в отдельный продукт; BigTable, GFS и движок обработки больших данных — типичные инфраструктурные исследования, без которых ключевые продукты просто не завелись бы. Станислав добавил, что оси различаются метриками: продуктовое улучшение меряют скоростью и качеством, а инфраструктурное — новыми возможностями и масштабом. Игорь увидел здесь сдвиг: в статье 2012 года фундаментальные исследования скорее дисконтировались, а на странице философии выглядят супер важным направлением; Александр добавил, что в списке ключевых областей они идут первыми. В финале Александр вывел страницу с продуктами, а Игорь рассказал про них — платформу observability с самописной базой под логи и сервисы распознавания и синтеза речи из автоматизации колл-центров — и объявил, что со следующего года исследования станут системнее; Станислав, добавил Александр, уже ищет коллег.