Чему доставка еды научила меня об инженерии

Большую часть карьеры я писал системы, которыми пользовались другие: абоненты оператора, клиенты банка, пользователи платёжных сервисов. Между мной и реальностью почти всегда стоял кто-то ещё — аналитик, продакт, служба поддержки.

Потом появилась SOR PIZZA — доставка еды в Душанбе, которую мы делали как технологичный бизнес. Мы писали свою CRM, систему обработки заказов, приложения для курьеров, интеграцию с телефонией, инструменты аналитики. И впервые между мной и последствиями моих решений не было никого.

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

Предметная область грязнее любой модели

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

Потом начинается жизнь. Клиент диктует адрес, которого нет на карте. Дом есть, а подъезда не найти. Телефон выключен, курьер стоит у двери. Пошёл дождь, и половина курьеров едет медленнее. Клиент просит «без лука» уже после того, как пицца ушла в печь.

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

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

Интерфейс для человека, у которого заняты руки

Свой софт для колл-центра и кухни я проектировал так же, как обычные веб-приложения. Это была ошибка.

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

Что оказалось важным:

• Каждый лишний клик стоит денег. Не метафорически: умноженный на сотни заказов, он превращается в минуты задержки и в раздражённого клиента.
• Экран должен отвечать на один вопрос. «Что делать прямо сейчас?» — а не показывать всё, что система знает.
• Ошибку нужно предотвращать, а не сообщать о ней. Валидация после отправки формы в реальном времени бесполезна.
• Если сотруднику неудобно, он обойдёт систему. Запишет на бумажке, договорится голосом, поправит потом. И в этот момент ваши данные перестают отражать реальность — а вслед за ними и вся аналитика.

Последний пункт для меня был самым отрезвляющим. Раньше я думал, что плохой интерфейс — это про неудобство. Оказалось, это про достоверность данных.

Телефон никуда не делся

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

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

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

Метрика вместо мнения

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

Эта цифра не спорит. Её нельзя объяснить красивой архитектурой. Если изменение в системе её не улучшило — значит, изменение было бесполезным, каким бы элегантным оно ни казалось внутри.

Такой фокус многое расставляет по местам. Становится видно, что часть работы, которой ты гордился, ни на что не влияет. И наоборот — что скучная автоматизация одной рутинной операции даёт больше, чем месяц рефакторинга.

Данные, которые собираются сами

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

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

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

Что изменилось во мне как в инженере

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

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

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

Странным образом именно пиццерия сделала меня более требовательным разработчиком, чем любой код-ревью.