Agile-грабли проектировщика интерфейсов Семена (Никита Ефимов, AgileDays-2013) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) (Новая страница: «== Аннотация == ;Докладчик: {{Speaker|Никита Ефимов}} <blockquote> </blockquote> == Видео == {{vimeoembed|65688290|800|450}} …») |
StasFomin (обсуждение | вклад) |
||
(не показано 67 промежуточных версий этого же участника) | |||
== Аннотация == ;Докладчик: {{Speaker|Никита Ефимов}} <blockquote> Доклад, основанный на реальных событиях, построен в форме рассказа-комикса и повествует о том, в какую ситуацию попадает и с какими трудностями сталкивается закостенелый проектировщик интерфейсов Семен, перейдя в продуктовую agile-команду. Каждый жизненный урок он заносит в свой блокнот, который позже называет «Грабли Семена». Краткое содержание рассказа. Проработав долгое время в крупной юзабилити-лаборатории, Семена потянуло на «вольные хлеба». Его друзья запустили несколько стартапов, водили его на различные «тусовки», и Семену так захотелось поучаствовать в каком-нибудь стартапе, что он решил уйти с текущего места работы. Набив портфолио крупными проектами и звучными именами, он отправился на собеседования. Там же от своего будущего менеджера проекта он услышал волшебные и новые для него слова «agile» и «scrum». Почитав перед выходом на работу «best practises» о том, как нужно внедрять UX в agile-процесс (нулевая итерация, проектирование на несколько итераций вперед и т.д.), он с радостью выходит на работу. Но в первый же день сталкивается с ситуациями, к которым не был готов: * Сжатые и фиксированные сроки. Спринт длится всего две недели. Первые идеи и наброски нужны уже сегодня, а готовый к реализации вариант (для разработчиков) к концу недели. К следующей среде уже нужен работающий функционал, чтобы QA-команде начать его проверять; * Утверждение идей. Семен привык показывать результат своей работы только когда практически все готово (а это всегда занимает много времени); * Описание поведения функционала. Семен привык описывать все возможные мелочи в поведении продукта (т.к. дьявол кроется в деталях), но для команды «Работающий продукт важнее исчерпывающей документации». Как теперь фиксировать и передавать требования о поведении продукта разработчикам, тестировщикам, маркетологам?; * Командное взаимодействие. Разработчикам нужен готовый макет с итоговым дизайном. Дизайнеру нужны мокапы с утвержденными текстами от маркетологов. Но маркетологи не понимают грубых мокапов, им нужны объяснения «что, где, когда».… Какой-то замкнутый круг; * Юзабилити-тестирование. Где найти время на него и когда исправлять ошибки? </blockquote> == Видео == {{vimeoembed|65688290|800|450}} <poll> ALTERNATIVE REVOTE UNIQUE Оцените доклад «{{PAGENAME}}»: Отлично! Хорошо. Нормально… Не очень :( Просто хочу узнать результаты. </poll> <!-- {{youtubelink|9IkMBms-hHQ}} == Слайды == [[File:Agile-грабли проектировщика интерфейсов Семена (Никита Ефимов, AgileDays-2013).pdf|left|page=-|256px]] --> {{----}} == Примечания и отзывы == * [{{ConferencePage|http://msk13.agiledays.ru/reports/view/60/ Страничка доклада на сайте конференции]}} <!-- <blockquote>[©]</blockquote> --> <references/> <!-- topub --> {{stats|disqus_comments=0|refresh_time=2021-08-31T16:10:46.382907|vimeo_comments=0|vimeo_plays=32|youtube_comments=0|youtube_plays=0}} [[CategoryКатегория:AgileDays-2013]] [[Category:ToPublish]] [[Category:Agile]]Категория:Agile process]] [[Категория:UX + Agile]] |
Текущая версия на 12:45, 9 декабря 2023
Содержание
Аннотация
- Докладчик
- Никита Ефимов
Доклад, основанный на реальных событиях, построен в форме рассказа-комикса и повествует о том, в какую ситуацию попадает и с какими трудностями сталкивается закостенелый проектировщик интерфейсов Семен, перейдя в продуктовую agile-команду. Каждый жизненный урок он заносит в свой блокнот, который позже называет «Грабли Семена».
Краткое содержание рассказа.
Проработав долгое время в крупной юзабилити-лаборатории, Семена потянуло на «вольные хлеба». Его друзья запустили несколько стартапов, водили его на различные «тусовки», и Семену так захотелось поучаствовать в каком-нибудь стартапе, что он решил уйти с текущего места работы. Набив портфолио крупными проектами и звучными именами, он отправился на собеседования. Там же от своего будущего менеджера проекта он услышал волшебные и новые для него слова «agile» и «scrum».
Почитав перед выходом на работу «best practises» о том, как нужно внедрять UX в agile-процесс (нулевая итерация, проектирование на несколько итераций вперед и т.д.), он с радостью выходит на работу. Но в первый же день сталкивается с ситуациями, к которым не был готов:
- Сжатые и фиксированные сроки. Спринт длится всего две недели. Первые идеи и наброски нужны уже сегодня, а готовый к реализации вариант (для разработчиков) к концу недели. К следующей среде уже нужен работающий функционал, чтобы QA-команде начать его проверять;
- Утверждение идей. Семен привык показывать результат своей работы только когда практически все готово (а это всегда занимает много времени);
- Описание поведения функционала. Семен привык описывать все возможные мелочи в поведении продукта (т.к. дьявол кроется в деталях), но для команды «Работающий продукт важнее исчерпывающей документации». Как теперь фиксировать и передавать требования о поведении продукта разработчикам, тестировщикам, маркетологам?;
- Командное взаимодействие. Разработчикам нужен готовый макет с итоговым дизайном. Дизайнеру нужны мокапы с утвержденными текстами от маркетологов. Но маркетологи не понимают грубых мокапов, им нужны объяснения «что, где, когда».… Какой-то замкнутый круг;
- Юзабилити-тестирование. Где найти время на него и когда исправлять ошибки?
Видео
Слайды
Примечания и отзывы
Plays:32
Comments:0