Всем привет!
Меня зовут Диана, я дизайн-лид двух направлений в Купере. Сегодня расскажу про одно из них — RTE (ready-to-eat), где мы развиваем личный кабинет ресторана. В статье поделюсь тем, как мы выстроили процессы и что из них реально работает, а также расскажу, как мы проектируем личный кабинет ресторана и для кого он создаётся.
Как устроены процессы
Хороший продукт редко появляется «по вдохновению» — чаще это результат системной работы команды. Мы идём в ритме двухнедельных спринтов, и поначалу процесс выглядел вполне обычно:
Как это было раньше
daily sync-up каждый день
планирование — в первый понедельник спринта
еженедельная встреча дизайнеров и продактов: показывали макеты, обсуждали дедлайны
по средам — PBR (Product Backlog Refinement)
спринт-ревью и ретроспектива — в конце каждого спринта
Классический набор, но со временем стало ясно: в одних местах мы теряем эффективность, а в других — набираем лишние правки. Об этом я расскажу чуть позже.
Что такое PBR и зачем он нам
PBR — это регулярная встреча, где дизайнеры, разработчики, продакты и тестировщики синхронизируются по задачам. Мы показываем концепты, обсуждаем технические ограничения и проверяем, что ничего не упустили.
Важный плюс таких встреч: разработчики часто подсвечивают нюансы, которые дизайнеры просто не видят. Например: «эта кнопка у тебя красиво уехала за край,
но в верстке это невозможно без костылей». Лучше услышать это на PBR, чем потом перепиливать макеты в последний момент.
Спринт-ревью и ретро: внешний результат и внутренняя работа над ошибками
Каждый спринт мы заканчиваем двумя встречами: спринт-ревью и ретро.
Спринт-ревью — это показ результатов стейкхолдерам. Продакт рассказывает, что удалось сделать за спринт, демонстрирует работающий функционал и собирает обратную связь. Для команды это способ держать стейкхолдеров в курсе, а для стейкхолдеров — возможность повлиять на продукт ещё до релиза.
Ретро — это внутренний формат. Хотя звучит не слишком увлекательно, мы стараемся превратить его в живое обсуждение.
Перед встречей модератор готовит картинки (мемы, героев фильмов, котов). Каждый выбирает картинку, которая отражает его состояние в спринте, и рассказывает,
как всё прошло. Это помогает раскрепостить команду и «разговорить» разработчиков, которые обычно бывают не слишком многословны. Обсуждения могут касаться не только задач, но и внутренних процессов. У каждого — полная свобода высказаться, если наболело.
Результатом ретро становится список проблем и план действий с назначенными ответственными. Это помогает постепенно закрывать слабые места. Например, когда заметили, что задачи «проскакивают» мимо дизайн-ревью и потом ловим баги на проде — сделали ревью обязательным.
Эволюция процессов
Благодаря ретро мы постепенно выявляем проблемы в процессах, корректируем их и улучшаем. Вот что изменилось за последнее время:
На дейли теперь продакты тоже рассказывают про свои задачи.
Это помогает всей команде видеть картину целиком.Планирование разделили на «предпланирование» и «планирование».
Так стало проще оценивать задачи и назначать ответственных.Встречи дизайнеров и продактов расширили. Теперь мы не только обсуждаем макеты, но и продакты приходят с описанными тасками на будущую неделю.
В PBR добавили правило. Перед встречей делаем анонс, что будем смотреть,
а при презентации макетов по просьбе разработчиков мы показываем не только решение, но и контекст задачи: откуда возникла проблема, зачем это нужно бизнесу и пользователю, и только потом показываем, как хотим её решить.
Появилась новая встреча «Три амиго». Обычно такие встречи проводятся перед началом тестирования задачи или перед стартом разработки. О ней расскажу подробнее дальше.
«Три амиго»
Методику подсказала наш продакт Алёна. Смысл: собрать минимум трёх участников — разработчика, тестировщика и продакта — ещё до начала тестирования или разработки.
Зачем это нужно:
тестировщики заранее понимают, где искать баги
разработчики проговаривают ограничения
продакты уточняют требования
Представьте, что вы спроектироали дизайн и передали макеты разработчикам.
Во время разработки могут возникнуть ограничения или новые требования, которые повлияют на дизайн и функциональность. А когда задача переходит тестировщику, то
тоже не всегда всё бывает гладко: документация может устареть или появляются сомнения, является ли это багом или фичей. В итоге уходит много времени
на дополнительную коммуникацию.
Встречи по методике «Три амиго» помогают выявить недопонимания на ранних этапах, акцентируют внимание тестировщиков на важных моментах и снижают потенциальные риски.
Совет: главное — не переборщить. Не надо ставить встречу, не разобравшись сначала самостоятельно. У нас «Три амиго» — это нерегулярная встреча, которая проводится по требованию любого из участников задачи.
Что ещё помогает нам быть эффективными
Помимо процессов, у нас есть набор принципов, которые работают «по умолчанию»
и помогают команде быть эффективной и слаженной. Они простые, но проверены на практике — многие родились из реальных факапов, поэтому мы особенно к ним привязаны:
задачи не проходят мимо дизайн-ревью
ведём страницу, где всегда собраны актуальные ссылки на макеты
задаём вопросы и инициируем встречи, если непонятно
не забываем про тексты
при проектировании задачи думаем о ее перспективах развития заранее
Личный кабинет ресторана
Теперь про сам продукт. Личный кабинет — это рабочий инструмент партнёров: администраторов, менеджеров и владельцев кафе и ресторанов масс-сегмента.
В нём они:
заводят меню
настраивают график работы
управляют зонами доставки
и самое главное — принимают, отправляют на готовку, собирают и передают заказы курьеру
Когда мы начинали, функциональность была минимальной. За два года кабинет сильно разросся, что хорошо видно по сайдбару:
Слева — версия два года назад: минимум разделов, только ключевой функционал. Справа — текущая версия: полноценный инструмент, где есть десятки возможностей для управления рестораном.
Увеличение числа разделов отражает не просто «наращивание фич», а то, что продукт взрослеет вместе с потребностями партнёров.
Откуда мы понимаем, что делать дальше
Мы не «выдумываем» фичи, а собираем идеи из нескольких источников:
Обратная связь партнёров. Интервью, опросы, саппорт. Часто именно администраторы подсказывают, где интерфейс неудобен.
Метрики. CSAT и CSI помогают понять удовлетворённость и восприятие продукта.
Конкуренты. Смотрим не только на прямых конкурентов, но и на маркетплейсы, международные решения.
Стратегия компании. Новые функции должны совпадать с целями роста.
Тренды и технологии. Например, мы смотрим, как автоматизация может разгрузить администраторов.
Что дальше
Здесь я рассказала больше про процессы и эволюцию самого продукта. А подробнее про интерфейсные моменты — например, как мы полностью переделали раздел «Меню», запускали Telegram-бота и внедряли другие интересные фичи — расскажу
в отдельной статье.
Итоги
Хороший продукт — это не только красивые экраны в Figma. В основе — всегда люди, процессы и умение признавать ошибки.
Что у нас получилось за это время:
сделать процессы живыми и полезными, а не ради галочки
встроить практики, которые реально экономят время
шаг за шагом прокачать личный кабинет ресторанов
И, конечно, всё это работает только потому, что у нас сильная команда. Ребята вовлечены, эмпатичны к пользователям и искренне болеют за результат. Иногда, чтобы просто «почувствовать» друг друга, мы договариваемся включить камеры
на синках — мелочь, а атмосфера сразу меняется.
Я верю, что команда начинается с каждого из нас. Для меня это про то, чтобы говорить прозрачно, описывать задачи так, чтобы всем было понятно, отвечать быстро
и не откладывать вопросы «на потом». Быть проактивным, потому что именно тебе больше всего важно, как будет реализована задумка. И, конечно, держаться
за аналитику и метрики — они отрезвляют лучше всего, когда хочется «сделать красиво».
А как у вас? Какие процессы у вас реально работают, а какие кажутся пустой формальностью? Поделитесь опытом в комментариях — будет классно сравнить практики!