Всем привет!

Меня зовут Диана, я дизайн-лид двух направлений в Купере. Сегодня расскажу про одно из них — RTE (ready-to-eat), где мы развиваем личный кабинет ресторана. В статье поделюсь тем, как мы выстроили процессы и что из них реально работает, а также расскажу, как мы проектируем личный кабинет ресторана и для кого он создаётся.

Как устроены процессы

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

Как это было раньше

• daily sync-up каждый день

• планирование — в первый понедельник спринта

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

• по средам — PBR (Product Backlog Refinement)

• спринт-ревью и ретроспектива — в конце каждого спринта

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

Что такое PBR и зачем он нам

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

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

Спринт-ревью и ретро: внешний результат и внутренняя работа над ошибками

Каждый спринт мы заканчиваем двумя встречами: спринт-ревью и ретро.

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

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

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

Результатом ретро становится список проблем и план действий с назначенными ответственными. Это помогает постепенно закрывать слабые места. Например, когда заметили, что задачи «проскакивают» мимо дизайн-ревью и потом ловим баги на проде — сделали ревью обязательным.

Эволюция процессов

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

• На дейли теперь продакты тоже рассказывают про свои задачи.
  Это помогает всей команде видеть картину целиком.

• Планирование разделили на «предпланирование» и «планирование».
  Так стало проще оценивать задачи и назначать ответственных.

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

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

Появилась новая встреча «Три амиго». Обычно такие встречи проводятся перед началом тестирования задачи или перед стартом разработки. О ней расскажу подробнее дальше.

«Три амиго»

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

Зачем это нужно:

• тестировщики заранее понимают, где искать баги

• разработчики проговаривают ограничения

• продакты уточняют требования
  

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

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

Совет: главное — не переборщить. Не надо ставить встречу, не разобравшись сначала самостоятельно. У нас «Три амиго» — это нерегулярная встреча, которая проводится по требованию любого из участников задачи.

Что ещё помогает нам быть эффективными

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

• задачи не проходят мимо дизайн-ревью

• ведём страницу, где всегда собраны актуальные ссылки на макеты

• задаём вопросы и инициируем встречи, если непонятно

• не забываем про тексты

• при проектировании задачи думаем о ее перспективах развития заранее

Личный кабинет ресторана

Теперь про сам продукт. Личный кабинет — это рабочий инструмент партнёров: администраторов, менеджеров и владельцев кафе и ресторанов масс-сегмента.
В нём они:

• заводят меню

• настраивают график работы

• управляют зонами доставки

• и самое главное — принимают, отправляют на готовку, собирают и передают заказы курьеру

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

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

Увеличение числа разделов отражает не просто «наращивание фич», а то, что продукт взрослеет вместе с потребностями партнёров.

Откуда мы понимаем, что делать дальше

Мы не «выдумываем» фичи, а собираем идеи из нескольких источников:

1. Обратная связь партнёров. Интервью, опросы, саппорт. Часто именно администраторы подсказывают, где интерфейс неудобен.

2. Метрики. CSAT и CSI помогают понять удовлетворённость и восприятие продукта.

3. Конкуренты. Смотрим не только на прямых конкурентов, но и на маркетплейсы, международные решения.

4. Стратегия компании. Новые функции должны совпадать с целями роста.

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

Что дальше

Здесь я рассказала больше про процессы и эволюцию самого продукта. А подробнее про интерфейсные моменты — например, как мы полностью переделали раздел «Меню», запускали Telegram-бота и внедряли другие интересные фичи — расскажу
в отдельной статье.

Итоги

Хороший продукт — это не только красивые экраны в Figma. В основе — всегда люди, процессы и умение признавать ошибки.

Что у нас получилось за это время:

• сделать процессы живыми и полезными, а не ради галочки

• встроить практики, которые реально экономят время

• шаг за шагом прокачать личный кабинет ресторанов

И, конечно, всё это работает только потому, что у нас сильная команда. Ребята вовлечены, эмпатичны к пользователям и искренне болеют за результат. Иногда, чтобы просто «почувствовать» друг друга, мы договариваемся включить камеры
на синках — мелочь, а атмосфера сразу меняется.

Я верю, что команда начинается с каждого из нас. Для меня это про то, чтобы говорить прозрачно, описывать задачи так, чтобы всем было понятно, отвечать быстро
и не откладывать вопросы «на потом». Быть проактивным, потому что именно тебе больше всего важно, как будет реализована задумка. И, конечно, держаться
за аналитику и метрики — они отрезвляют лучше всего, когда хочется «сделать красиво».

А как у вас? Какие процессы у вас реально работают, а какие кажутся пустой формальностью? Поделитесь опытом в комментариях — будет классно сравнить практики!