Agile-грабли проектировщика интерфейсов Семена (Никита Ефимов, AgileDays-2013) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) (Batch edit: remove Category:ToPublish) |
StasFomin (обсуждение | вклад) (Batch edit: replace |800|450}} with |800|450}} {{youtubelink|}}) |
||
== Видео ==
{{vimeoembed|65688290|800|450}}
{{youtubelink|}}
== Слайды ==
[[File:Agile-грабли проектировщика интерфейсов Семена (Никита Ефимов, AgileDays-2013).pdf|left|page=-|256px]]
{{----}}
== Примечания и отзывы ==
* [http://msk13.agiledays.ru/reports/view/60/ Страничка доклада на сайте конференции]
<!-- <blockquote>[©]</blockquote> -->
<references/>
[[Category:AgileDays-2013]]
[[Category:Agile process]]
[[Category:Юзабилити]]
<!-- topub --> |
Версия 00:27, 1 июня 2016
Содержание
Аннотация
- Докладчик
- Никита Ефимов
Доклад, основанный на реальных событиях, построен в форме рассказа-комикса и повествует о том, в какую ситуацию попадает и с какими трудностями сталкивается закостенелый проектировщик интерфейсов Семен, перейдя в продуктовую agile-команду. Каждый жизненный урок он заносит в свой блокнот, который позже называет «Грабли Семена».
Краткое содержание рассказа.
Проработав долгое время в крупной юзабилити-лаборатории, Семена потянуло на «вольные хлеба». Его друзья запустили несколько стартапов, водили его на различные «тусовки», и Семену так захотелось поучаствовать в каком-нибудь стартапе, что он решил уйти с текущего места работы. Набив портфолио крупными проектами и звучными именами, он отправился на собеседования. Там же от своего будущего менеджера проекта он услышал волшебные и новые для него слова «agile» и «scrum».
Почитав перед выходом на работу «best practises» о том, как нужно внедрять UX в agile-процесс (нулевая итерация, проектирование на несколько итераций вперед и т.д.), он с радостью выходит на работу. Но в первый же день сталкивается с ситуациями, к которым не был готов:
- Сжатые и фиксированные сроки. Спринт длится всего две недели. Первые идеи и наброски нужны уже сегодня, а готовый к реализации вариант (для разработчиков) к концу недели. К следующей среде уже нужен работающий функционал, чтобы QA-команде начать его проверять;
- Утверждение идей. Семен привык показывать результат своей работы только когда практически все готово (а это всегда занимает много времени);
- Описание поведения функционала. Семен привык описывать все возможные мелочи в поведении продукта (т.к. дьявол кроется в деталях), но для команды «Работающий продукт важнее исчерпывающей документации». Как теперь фиксировать и передавать требования о поведении продукта разработчикам, тестировщикам, маркетологам?;
- Командное взаимодействие. Разработчикам нужен готовый макет с итоговым дизайном. Дизайнеру нужны мокапы с утвержденными текстами от маркетологов. Но маркетологи не понимают грубых мокапов, им нужны объяснения «что, где, когда».… Какой-то замкнутый круг;
- Юзабилити-тестирование. Где найти время на него и когда исправлять ошибки?
Видео
Слайды
Примечания и отзывы