Час простоя — миллион рублей. Как мы лечили систему онлайн-заказов на сайте пиццерии

Рассказываю, как мы привели в порядок систему онлайн-заказов Italian Pizza и помогли сэкономить на разработке приложения

Привет! Я Трофим Жугастров, основатель компании Elonsoft. Мы разрабатываем решения для среднего и крупного бизнеса, которому нужна автоматизация.

Наверняка вы слышали, как недавно СДЭК потерял из-за простоя своих ИТ-сервисов от 300 млн до 1 млрд руб (по данным РБК). Надежность и бесперебойная работа системы — это важный аспект безопасности бизнеса, даже если он не такой крупный как СДЭК. И в этом мы можем помочь.

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

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

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

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

Для Italian Pizza мы предложили сделать технический аудит.

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

Клиент остался доволен аудитом и предложил нам самим выполнять то, что мы наметили. Но прежде чем мы приступили к комплексной работе над сайтом, появилась срочная задача.

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

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

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

Дашборд стал пробным проектом, на котором мы на практике показали, как мы работаем, и доказали свою экспертизу в бою. Когда дашборд был готов, заказчик смог доверить нам разработку основной системы.

Результат. Теперь цифры по точке можно было наглядно показывать потенциальным покупателям франшизы.

Когда клиент обратился к нам, сайт работал нестабильно. На выходных, когда на сайт одновременно заходили больше 50 пользователей, он падал — и ничего нельзя было сделать, пока кто-то оставался на сайте.

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

Совсем скоро были ноябрьские праздники, а потом новогодние каникулы. Чтобы не упускать заказы, нужно было срочно что-то придумать.

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

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

Результаты нагрузочного тестирования показывают, что сейчас сайт выдерживает 150 одновременных пользователей при 213 запросах в секунду. Запросы — это разные действия пользователей, например, когда он на что-то кликает.

Однако, мы понимаем, что это чудовищно мало. Помню, когда я работал программистом в Game Insight, мы писали код так, чтобы держать 10 000 соединений в секунду. Потом, когда я писал магистерскую диссертацию по computer science, я защищал проект на 100 000 соединений в секунду.

Современной высокой нагрузкой считается 10 000 000 соединений в секунду. Поэтому точно есть куда улучшать работу, и у нас есть конкретный план действий, как выйти хотя бы на 10 000 одновременных пользователей в каталоге с конверсией в 1000 заказов в секунду. Но все постепенно, бизнес-задачи идут параллельно с техническим долгом и всё это требует взвешенной приоритезации.

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

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

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

Когда мы начинали заниматься сайтом, он работал очень медленно — с хорошим интернетом главная страница загружалась 5-6 секунд, причем это был просто белый экран. А с 3G сайт не грузился вообще. Сейчас все мы привыкли к мгновенной загрузке, так что за 5 секунд можно подумать, что интернет пропал или это вообще неверная ссылка.

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

Мы продолжаем работать над быстродействием — по нашему плану рефакторинга, мы должны выйти на загрузку за 1 секунду.

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

Сейчас онлайн-покупки чаще всего делаются в один клик, а на сайте Italian Pizza клиенту приходилось преодолевать несколько окон и заполнять много полей.

Мы меняем дизайн сайта, корзины и логику заказа, чтобы этот путь сократить.

Результат. Сайт воспринимается более современным — загружается в два раза быстрее, за 3 секунды вместо 6 секунд, а у пользователя стало меньше шагов до заказа.

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

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

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

В случаях, когда не требуется сложных функций, вместо мобильного приложения можно сделать прогрессивное веб-приложение — PWA. Простыми словами, это мобильная версия сайта, которая «обернута» в мобильное приложение.

PWA можно разместить в сторах — и это будут видеть партнеры. А клиенты могут заказывать в нем пиццу, как в любом другом приложении доставки.

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

Результат. Такое решение обошлось заказчику всего в 200 000 рублей — это 66 наших часов на разработку PWA и публикацию в сторах.

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

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

Кроме того, выбор внешнего или внутреннего курьера зависит от того, как покупатель оплачивает заказ. Внешние курьеры могут развозить заказы только с онлайн-оплатой на сайте. А если оплата наличными или картой при получении, нужно отправлять внутреннего курьера.

В модуле доставки отображается, сколько внешних и внутренних курьеров свободно с временным интервалом в 15 минут. Если никого свободного нет, этот промежуток подсвечивается красным.

Результат. Теперь время доставки рассчитывается более реалистично. Стало проще принимать управленческие решения, например, когда стоит вызвать больше курьеров, чтобы не терять заказы.

Кроме того, если заказ доставляли не вовремя, повышался шанс, что покупатель оставит негативный отзыв. А если время рассчитано реалистично, всё должно быть в порядке.

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

Но продукт-оунер со стороны Italian Pizza присутствует на всех наших рабочих встречах по проекту: и ежедневных синхронах, и ретроспективах, когда мы оцениваем проделанную работу.

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

Можно быстрее получить друг от друга ответы на вопросы, которые иначе застопорят работу, и сразу же в моменте корректировать понимание задачи — правильно ли мы видим потребность клиента.

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

Мы продолжаем работу и над быстродействием сайта в целом, и по конкретным задачам:

Мы занимаемся разработкой кастомного софта, сайтов, интернет-магазинов и личных кабинетов.

Можно оставить заявку на сайте Elonsoft или написать в Телеграм мне, Трофиму Жугастрову — обсудим вашу задачу и прикинем, чем мы сможем помочь. А если ее можно решить без нового софта, напрямую об этом скажем.

Веду канал Переводчик с айтишного — рассказываю, как предпринимателям не сливать деньги на разработку, какие бывают ИТ-стратегии для бизнеса и как сделать классный продукт за разумный бюджет.