Методология "3 Амиго". Совместное проектирование цифрового продукта | Ирина Мягкова red_mad_robot

• Ирина Мягкова, бизнес-аналитик компании Redmond Robot, рассказывает о методологии ТРИАМ.  

• Цель доклада: рассказать о методологии, её пользе, преимуществах и практике внедрения в компании.  

• Redmond Robot - диджитал партнер для крупного бизнеса, выпускающий продукты полного цикла.  

• Компания работает с разными отраслями: финтех, медицина, ритейл, страхование, технологии: ИИ, интернет вещей.  

• Компания состоит из десяти юнитов и представлена в четырех странах, с более чем тысячей роботов.  

• Методология ТРИАМ основана на совместном проектировании.  

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

• Процесс важен для создания продукта, соответствующего ожиданиям заказчика и рынка.  

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

• Сложности с дополнительной логикой требуют дополнительных ревью, что может замедлить разработку.  

• Решение: использование методологии ТРИАМ для быстрого проектирования сложных фич.  

• ТРИАМ включает взаимодействие бизнес-аналитика, разработчика и тестировщика.  

• Цель: генерировать идеи и риски на старте проектирования фичи.  

• Преимущества: оптимизация времени разработки, единое понимание проблемы и путей решения, раннее отслеживание рисков.  

• ТРИАМ подходит для фич высокой или средней сложности.  

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

• Практическое применение: подготовка к встрече, сбор требований, проектирование сценариев, выявление зависимостей, организация встречи с ключевыми ролями.  

• Аналитик знает паттерны рынка и может применять их в технической реализации.  

• Важно заранее направить контекст всем участникам встречи.  

• Встреча проходит в формате брейн-шторма, где аналитик выгружает фичу и отвечает на вопросы команды.  

• Важно учитывать критерии приемки, реакцию системы и возможные риски.  

• Сбор всех контекстов помогает генерировать идеи и решения.  

• Финализация требований и передача документации в разработку.  

• Использование шаблона из статьи на Хабре.  

• Шаблон включает юзер стори, критерии приемки, систему и риски.  

• Оптимизация шаблона для отслеживания работы критериев и рисков.  

• Пример функции анбординга в мобильном приложении.  

• Юзер стори с точки зрения продукта и пользователя.  

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

• Использование фичер тоглов для сегментации пользователей.  

• Риски: необходимость доработки для определенных групп пользователей.  

• Фиксация открытых вопросов и комментариев для улучшения реализации.  

• Инструмент помогает держать всех в едином контексте.  

• Тесное взаимодействие ускоряет результат и выявляет проблемы.  

• Высокий уровень поддержки и согласованности благодаря объединению трех контекстов.  

• Сокращение сроков разработки и улучшение качества продукта.  

• Детальная проработка на старте.  

• Призыв делиться кейсами и участвовать в тг-канале компании.  

• Анонс метапа для клей в апреле.  

• Призыв подписываться на канал и следить за новостями.  

• Вопросы и ответы о внедрении инструмента.  

• Оптимизация внутренних производственных процессов.  

• Проблемы с разрывом между аналитикой и разработкой.  

• Идея объединения аналитики и разработки для повышения эффективности.  

• Совместное проектирование для сложных фич.  

• Преимущества объединения ролей на старте.  

• Эффективность встреч и покрытие множества вопросов.  

• Простые фичи не требуют совместного проектирования.  

• Сложные фичи требуют детальной проработки.  

• Проблемы с человеческим фактором и загрузкой.  

• Контроль и согласование концепции с клиентом.  

• Совместная работа для достижения эффективности.  

• Выравнивание ожиданий от фич через критерии приемки.  

• Внедрение изменений в процессы работы.  

• Трудности и реакция команды.  

• Процесс внедрения и его влияние на работу команды.  

• Большинство людей сопротивляются изменениям, так как старое работает хорошо.  

• Внедрение новых методов, инструментов или систем всегда связано с рисками непринятия.  

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

• Встречи помогают собрать всех в один контекст и нивелировать будущие риски.  

• Объяснить команде, что изменения нужны для оптимизации будущего решения.  

• Активные встречи показывают, что изменения работают и приносят результат.  

• Инструмент помогает сократить количество встреч без потери эффективности.  

• Тестировщики могут предложить внедрение подхода, что приведет к новым докладам.  

• Благодарность Ирине Мягковой за прекрасный доклад.  

• Напоминание о том, что Ирина является бизнес-аналитиком в компании Ред.  

• Призыв задавать вопросы в разделе "Вопросы", на которые Ирина обязательно ответит.