Как устроена работа над системой FoodSoul: от идеи до результата

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

FoodSoul — это живая система

FoodSoul — это не просто приложение. За ним стоит большая инфраструктура: CRM, хранение и защита данных, шаблоны сайтов и мобильных приложений и тысячи ресторанов-партнёров, каждый со своими потребностями и сценариями работы.

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

Как устроена команда и структура работы

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

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

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

Аналитики собирают и структурируют пожелания партнёров, оценивают, насколько изменение востребовано и как оно повлияет на других клиентов, прежде чем задача попадёт в разработку.

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

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

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

Как мы расставляем приоритеты

Когда возникает проблема, мы действуем по одному из сценариев.

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

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

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

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

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

Почему возникают баги

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

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

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

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

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

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

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

Если вы столкнулись с проблемой или хотите поделиться идеей, напишите в техподдержку FoodSoul. Каждое обращение попадает к нужному специалисту и не теряется. Мы рядом!

С Уважением,

Project Manager FoodSoul