Что делать в ситуации, когда несколько команд работают над одним проектом или продуктом? Возникают зависимости. Мы рассмотрим как ими можно управлять и как повысить общую эффективность процесса.
Выступление на коференции AgileDays'15 20 марта
Повышает мотивацию и интерес к учебе
Увеличивает наглядность подачи информации
Можно использовать наработанный материал, информацию из сети Интернет.
Коллективная работа над учебными проектами
Запись и воспроизведение действий для разбора ошибок и использования материала в дистанционном обучении
Что делать в ситуации, когда несколько команд работают над одним проектом или продуктом? Возникают зависимости. Мы рассмотрим как ими можно управлять и как повысить общую эффективность процесса.
Выступление на коференции AgileDays'15 20 марта
Повышает мотивацию и интерес к учебе
Увеличивает наглядность подачи информации
Можно использовать наработанный материал, информацию из сети Интернет.
Коллективная работа над учебными проектами
Запись и воспроизведение действий для разбора ошибок и использования материала в дистанционном обучении
3 способа проверки гипотез, когда у вас ещё ничего нетNikita Efimov
Доклад в рамках ProductConnect, Minsk.
Рассказал про 3 способа проверки гипотез о фичах/решениях на той стадии, когда вы ещё даже не сделали прототипа:
- модель Кано
- карточная сортировка
- интервью о решении с пользователями
Impact Map & Feature Canvas. Как держать фокус на целях при внедрении новых фич.Nikita Efimov
Доклад с Growth Business Forum '18.
Если в вашей компании ставятся амбициозные квартальные (или другие) цели: OKR, SMART, KPI, но нет понимания, как функциональность связана с целями, как контролировать достижение целей, как валидировать идеи по улучшению продуктов до проработки и как не тратить время и силы на никому ненужную функциональность.
Инструменты Feature Canvas и Impact Mapping не решат всех проблем с продуктом или бизнесом, но помогут начать договариваться, обоснованно говорить "нет" всем хотелкам и "крутым" идеям.
Feature Сanvas. С чего начать работу над новой идеей.Nikita Efimov
Доклад с ProductSense'18 Moscow.
Feature Canvas может помочь:
- Дольше оставаться в области проблем перед тем, как вы начнёте прорабатывать конкретное решение.
- Синхронизироваться со всей командой (чтобы все были на одной волне) об идеи, причинах её реализации и всего, что находится в области проблем.
- Увидеть "белые пятна" в вашем понимании контекста проблемы и пользователей. И подготовиться к исследованиям.
- Помогать контролировать себя ("А не забыл(-а) ли я чего-нибудь?") перед тем, как включить режим "Чик-чик и в продакшен".
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Информационные персоны (как люди ищут информацию)Nikita Efimov
Очередной доклад про персон-шмерсон? В какой-то степени...
Ведь, к сожалению, часто персоны просто придумывают. Причём эти "придумки" касаются цвета глаз Марины или имени её кота, что никаким образом не относится к проектируемой системе. Все становится ещё хуже, когда проектируют сложные информационные системы.
В докладе я хочу рассмотреть подход, который часто использую для проектирования сложных (с точки зрения информационной архитектуры) систем. Ведь в таких системах люди обрабатывают большое количество информации: ищут что-то новое, взаимодействуют с найденным, возвращаются к старому.
И каждый раз их поведение может меняться в зависимости от разных факторов:
от той информации, которую они ищут;
от того, какой информацией обладают на данный момент;
от того, что хотят с этой информацией сделать в дальнейшем.
Для себя я выделяю несколько состояний человека (как я их называю - режимы поиска), в котором он может находится. И на основании этих режимов прорабатываю типичных представителей и их взаимодействие с системой.
В докладе я подробно расскажу про эти "магические" режимы поиска, и как на основании этих данных я создаю информационных персон. Ну и, конечно, я расскажу про инструменты, которые мне помогают эти информационные персоны создавать.
Многие agile-команды используют в своей работе user story. Это отличный и простой в понимании инструмент. Однако, как это часто бывает, нельзя просто так взять и применить инструмент и сразу добиться нужного результата: фичи, которые были придуманы почему-то оказываются не нужны пользователям. Но не потому, что они (фичи) плохо реализованы, а потому, что эти фичи не удовлетворяют пользовательским потребностям.
В докладе я расскажу про инструмент под названием «дизайн история». Это user story на UX-стероидах, другой взгляд на привычный для многих инструмент. Мы поговорим о том, на основании чего создавать дизайн историю (точнее, как модифицировать user story). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
3 способа проверки гипотез, когда у вас ещё ничего нетNikita Efimov
Доклад в рамках ProductConnect, Minsk.
Рассказал про 3 способа проверки гипотез о фичах/решениях на той стадии, когда вы ещё даже не сделали прототипа:
- модель Кано
- карточная сортировка
- интервью о решении с пользователями
Impact Map & Feature Canvas. Как держать фокус на целях при внедрении новых фич.Nikita Efimov
Доклад с Growth Business Forum '18.
Если в вашей компании ставятся амбициозные квартальные (или другие) цели: OKR, SMART, KPI, но нет понимания, как функциональность связана с целями, как контролировать достижение целей, как валидировать идеи по улучшению продуктов до проработки и как не тратить время и силы на никому ненужную функциональность.
Инструменты Feature Canvas и Impact Mapping не решат всех проблем с продуктом или бизнесом, но помогут начать договариваться, обоснованно говорить "нет" всем хотелкам и "крутым" идеям.
Feature Сanvas. С чего начать работу над новой идеей.Nikita Efimov
Доклад с ProductSense'18 Moscow.
Feature Canvas может помочь:
- Дольше оставаться в области проблем перед тем, как вы начнёте прорабатывать конкретное решение.
- Синхронизироваться со всей командой (чтобы все были на одной волне) об идеи, причинах её реализации и всего, что находится в области проблем.
- Увидеть "белые пятна" в вашем понимании контекста проблемы и пользователей. И подготовиться к исследованиям.
- Помогать контролировать себя ("А не забыл(-а) ли я чего-нибудь?") перед тем, как включить режим "Чик-чик и в продакшен".
Про ИА. Визуальные сценарии и объекто-информационная модель.Nikita Efimov
- Проблемы перехода от этапа анализа к проектированию
- Информационная архитектура и модели поиска
- Визуальные сценарии
- Объектно-информационная модель
Информационные персоны (как люди ищут информацию)Nikita Efimov
Очередной доклад про персон-шмерсон? В какой-то степени...
Ведь, к сожалению, часто персоны просто придумывают. Причём эти "придумки" касаются цвета глаз Марины или имени её кота, что никаким образом не относится к проектируемой системе. Все становится ещё хуже, когда проектируют сложные информационные системы.
В докладе я хочу рассмотреть подход, который часто использую для проектирования сложных (с точки зрения информационной архитектуры) систем. Ведь в таких системах люди обрабатывают большое количество информации: ищут что-то новое, взаимодействуют с найденным, возвращаются к старому.
И каждый раз их поведение может меняться в зависимости от разных факторов:
от той информации, которую они ищут;
от того, какой информацией обладают на данный момент;
от того, что хотят с этой информацией сделать в дальнейшем.
Для себя я выделяю несколько состояний человека (как я их называю - режимы поиска), в котором он может находится. И на основании этих режимов прорабатываю типичных представителей и их взаимодействие с системой.
В докладе я подробно расскажу про эти "магические" режимы поиска, и как на основании этих данных я создаю информационных персон. Ну и, конечно, я расскажу про инструменты, которые мне помогают эти информационные персоны создавать.
Многие agile-команды используют в своей работе user story. Это отличный и простой в понимании инструмент. Однако, как это часто бывает, нельзя просто так взять и применить инструмент и сразу добиться нужного результата: фичи, которые были придуманы почему-то оказываются не нужны пользователям. Но не потому, что они (фичи) плохо реализованы, а потому, что эти фичи не удовлетворяют пользовательским потребностям.
В докладе я расскажу про инструмент под названием «дизайн история». Это user story на UX-стероидах, другой взгляд на привычный для многих инструмент. Мы поговорим о том, на основании чего создавать дизайн историю (точнее, как модифицировать user story). И самое главное, как эту историю использовать в дальнейшем, как на основании ее генерировать идеи и фичи для реализации.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.