Как создают продукты для миллиардной аудитории: инженерные уроки из Microsoft и Skype

Что меняется в работе инженера, когда продуктом пользуются сотни миллионов человек? Ошибка становится дороже, архитектурные решения живут годами, а большая часть работы заключается не в том, чтобы построить что-то новое, а в том, чтобы не сломать уже работающее.

Я поговорила об этом с Антоном Букаревым, который пришел в Skype вместе с командой стартапа Qik после его покупки в 2011 году. В Skype и Microsoft он занимался разработкой новых функций для мобильного клиента, в том числе сделал первый прототип офлайн-передачи файлов. Сегодня Антон руководит разработкой в американской компании Scalio. Обсудили, чему работа с продуктами глобального масштаба учит инженера, какие компромиссы приходится принимать и почему зрелая инженерия часто выглядит совсем не героически.

«Работать над вещью, которую практически никому не нужно объяснять, особенное чувство»

— Когда инженер работает над продуктом для сотен миллионов людей, масштаб становится не цифрой в презентации, а частью ежедневной реальности. В какой момент вы впервые почувствовали, что работаете именно с таким продуктом?

В Skype я попал не с улицы: наш стартап Qik, где я строил сетевую библиотеку для мобильного видео, купили в 2011 году, и внутри большого продукта я оказался вместе со своей командой. Кстати, снаружи поглощение выглядит куда драматичнее, чем изнутри: в первый месяц не поменялось почти ничего, мы продолжали работать как работали, и только со временем стали появляться задачи, связанные уже с самим Skype.

А вот ощущение масштаба пришло, по сути, сразу, и цифры тут были ни при чем. Нам рассказывали истории пользователей: как родные, которые по разным причинам не могли встретиться и жили в разных странах, сохраняли связь именно через Skype. Тогда и пришло понимание, что продуктом пользуются сотни миллионов людей, от мала до велика. Есть простой признак, по которому это чувствуешь на себе. Когда рассказываешь людям про другие продукты, обязательно начинаются вопросы: а что он делает, какие у него функции, кто его потребители. Про Skype таких вопросов мне не задавали: всем и так было понятно все. Работать над вещью, которую практически никому не нужно объяснять, особенное чувство.

«Файл можно было передать только тогда, когда оба участника находились в сети одновременно»

— У любого большого продукта есть разрыв между тем, как его видят пользователи, и тем, насколько сложной системой он является внутри. Что пользователи Skype никогда не замечали, но для инженеров было одной из самых сложных частей продукта?

Его архитектурную основу. Skype исторически был peer-to-peer-продуктом: там, где это было возможно, устройства собеседников связывались напрямую, и вся система строилась вокруг прямых соединений. Пользователь этого не видел, но именно отсюда росли и сильные стороны продукта, и его невидимые ограничения.

Самое наглядное из ограничений: файл можно было передать только тогда, когда оба участника находились в сети одновременно, продукт просто не умел сохранить файл и дождаться получателя. Сегодня это звучит дико: мы привыкли, что отправленный файл просто ждет получателя. А тогда такой возможности в Skype не существовало.

Я занимался прототипированием новых продуктов, и одной из моих задач стала как раз офлайн-передача файлов. Проект я начинал один: прототип функциональности для Skype для iPhone сделал сам, на основе нашего сервиса, а дальше выросла команда, и до релиза мы доводили это уже вместе. Отдельной болью тех лет был фоновый режим iPhone: стоило приложению уйти в фон, система обрывала соединения. Apple шаг за шагом добавляла механизмы фоновой работы, и со временем это отпустило, но пожить на этом переломе пришлось. То, что сейчас кажется само собой разумеющимся в любом мессенджере, тогда требовало шага поперек всей архитектуры продукта.

«Стабильность важнее красоты»

— Масштаб часто меняет саму природу инженерных решений: иногда правильный выбор не самый красивый код и не самая быстрая реализация. Какие компромиссы вам чаще всего приходилось принимать в Skype?

Самый частый: стабильность важнее красоты. В маленьком продукте можно переписать модуль просто потому, что новое решение элегантнее. В продукте на сотни миллионов пользователей любое «элегантнее» взвешивается против риска сломать то, что прямо сейчас у людей работает, поэтому часть кода живет дольше, чем хотелось бы инженерному самолюбию, и это правильно.

Второй компромисс зашит в саму архитектуру: прямые соединения делали продукт независимым от центральной инфраструктуры, но каждая возможность, которой нужен сервис в середине, давалась с боем. Отсюда урок, который пригодится любому продукту, а не только гигантскому: архитектурный выбор, сделанный в начале, годами определяет, какие функции будут даваться вам легко, а какие со скрипом.

И третий, время. У сервиса связи особые отношения с надежностью: никому не приятно, когда обрывается важный разговор или файл не удается передать вовремя. Поэтому все, что касается соединения и доставки, тестируется особенно тщательно и с вниманием к деталям, а это осознанные затраты времени, на которые идешь даже тогда, когда сроки поджимают.

«Простая пользовательская просьба на деле означала появление в продукте нового звена»

— Есть задачи, которые выглядят небольшими, пока не понимаешь их последствия для глобальной системы. Был ли в вашей работе случай, когда простое на первый взгляд изменение оказалось гораздо сложнее, чем ожидалось?

Был: та же офлайн-передача файлов. На слух задача элементарная: пусть файл сохранится и дождется получателя, все же так делают. Но «все так делают» в продуктах, которые изначально построены вокруг сервера. А в peer-to-peer-системе этой точки ожидания просто не существует: файл шел с устройства на устройство, и если получатель не в сети, отправлять некуда.

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

«В каждой жалобе на самом деле спрятан подарок»

— Skype был не просто техническим продуктом, он менял привычный способ общения людей задолго до появления многих современных сервисов. Насколько инженеры внутри команды чувствовали влияние продукта на повседневную жизнь пользователей?

Постоянно, потому что продукт не оставлял шанса о нем забыть. Реагировали люди всегда позитивно, но у известности была занятная бытовая сторона: узнав, где ты работаешь, человек почти сразу переходил к делу, рассказывал о проблеме, которая беспокоит именно его, или просил что-то улучшить. Это было неминуемо: продуктом ежедневно пользовались миллионы людей по всему миру, и у каждого находилось что-то свое.

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

«Работающий прототип заканчивает спор за одну демонстрацию»

— За большими продуктами всегда стоят решения, которые не видны пользователям: что строить, что откладывать, от каких идей отказываться. Как инженеры и продуктовая команда понимали, куда должен двигаться Skype дальше?

Со своей позиции инженера я видел эту кухню через прототипирование. Часть ответов на вопрос «куда дальше» рождалась в работающих прототипах раньше, чем в любых презентациях. Я как раз занимался прототипированием новых продуктов: берешь идею, за разумное время доводишь ее до состояния, которое можно потрогать, и дальше идея защищает себя сама.

Что-то умирало, едва родившись, и это нормально: дешевле похоронить прототип, чем выкатить сырую функцию на сотни миллионов человек. А что-то дорастало до продукта, та же офлайн-передача файлов прошла ровно этот путь от прототипа до функции в iPhone-клиенте. Мне до сих пор кажется, что это самый честный способ принимать продуктовые решения: спор мнений может длиться бесконечно, а работающий прототип заканчивает его за одну демонстрацию.

«У зрелого продукта скучные релизы»

— Со временем у инженеров появляется собственное представление о том, что отличает просто работающую систему от действительно зрелого продукта. Что для вас стало главным признаком инженерной зрелости после опыта со Skype?

Для меня инженерная зрелость складывается из двух вещей. Первая: процессы выстроены так, чтобы все падения происходили на тестовых стендах, а не у пользователей. Чем раньше выявлена проблема, тем дешевле она обходится, поэтому проверка встраивается в каждый этап разработки, а не приклеивается в конце.

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

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

«Когда что-то шло не так, вопрос звучал не «кто это сделал», а «что нам поменять в нашем процессе, чтобы это не повторилось»

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

Плотность опыта вокруг, причем распределенная по странам. Я работал из московского офиса, а проектная жизнь шла в постоянной связке с коллегами в Таллине и Стокгольме. Рядом, вживую или на другом конце переписки, работают люди, которые уже прошли через задачи, которые тебе только предстоят, и до любого можно дойти с вопросом. Мой код читали на ревью инженеры, строившие большие системы задолго до меня, и каждый их комментарий был маленьким уроком архитектуры.

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

«Настоящий класс выглядит буднично: дисциплина, проверки, повторяемость»

— Многие инженеры мечтают поработать над продуктом глобального масштаба, но такой опыт несет и большую ответственность. Что о такой работе обычно недооценивают люди со стороны?

Долю невидимой работы. Со стороны кажется, что инженеры глобального продукта все время строят новое, а в действительности большая часть усилий уходит на то, чтобы ничего не сломать: совместимость, поддержка длинного хвоста устройств и версий, согласование каждого изменения с тем, что уже работает у миллионов людей.

Недооценивают и то, как такой масштаб меняет отношение к ошибке: привычка перепроверять перестает быть занудством и становится рефлексом, потому что цену любой небрежности ты представляешь очень конкретно. Но сильнее всего недооценивают другое: в таком масштабе почти не бывает героизма одиночек.

Красивая история про гения, который за ночь все спас, на практике означает, что процессы провалились раньше. Настоящий класс выглядит буднично: дисциплина, проверки, повторяемость. Именно это и есть высшая форма инженерного мастерства, ее важно понимать с самого начала, и своей команде я объясняю это в первую очередь.