Моё выступление на Profsoux 2016: как полагается вести эвристическую оценку, и как это получилось в нашей компании. Сократили, ускорили, результат - весело и быстро.
Доклад предназначен для проектировщиков и дизайнеров интерфейсов.
Что полезного дизайнеру может пригодится из мира программирования? Громкие термины про контроль версий, архитектуру, чистый код и т.д. это все чуждые слова или повод перенять опыт? Настолько ли суровы программисты чтобы испортить своими подходами творческую суть дизайнера?
Ольга Лужецька - Exploratory testing: Love it or Leave it?DataArt
Є думка, що exploratory testing - це хаотичний процес, яким важко керувати. Ми розберемось, чи можна організувати exploratory testing так, щоб продукт був крутим та якісним, ризики більш передбачувані, а тестувальники отримували задоволення.
У семи нянек дитя без глаза? Пара лет проблем и решений в UX зарубежного веб-...ПрофсоUX
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хоро...Yandex
Конференция "План Б" в Санкт-Петербурге (17 декабря 2011)
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хорошо..." (DINO Systems)
Тезисы:
– тестировщики хотят того же, чего и все остальные – играть по правилам;
– правила игры не могут не меняться;
– готовность к изменениям закладывается при планировании;
– плановые риски требуют профилактики;
– планирование тестирования завершается не раньше, чем само тестирование.
Прыжок веры. От настоящегого к будущему. (AnalystDays2016)Alexey Vasilyev
При разработке и внедрении ИТ-систем мы так концентрируемся на факторе "чего бы такое продать клиенту, чтобы он купил", что забываем о "жизни после продажи". Как результат разработанная ИТ-система или изделие стоит на полке у Заказчика, а пользователи решают свои задачи привычным им способом.
К сожалению, о том, что надо было сделать, мы понимаем слишком поздно.
Как бы так сделать, чтобы подумать о будущем уже сегодня? Как заглянуть за горизонт событий?
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Доклад предназначен для проектировщиков и дизайнеров интерфейсов.
Что полезного дизайнеру может пригодится из мира программирования? Громкие термины про контроль версий, архитектуру, чистый код и т.д. это все чуждые слова или повод перенять опыт? Настолько ли суровы программисты чтобы испортить своими подходами творческую суть дизайнера?
Ольга Лужецька - Exploratory testing: Love it or Leave it?DataArt
Є думка, що exploratory testing - це хаотичний процес, яким важко керувати. Ми розберемось, чи можна організувати exploratory testing так, щоб продукт був крутим та якісним, ризики більш передбачувані, а тестувальники отримували задоволення.
У семи нянек дитя без глаза? Пара лет проблем и решений в UX зарубежного веб-...ПрофсоUX
Доклад рассчитан на создателей и руководителей продуктовых команд, проектировщиков, дизайнеров. Разработчикам тоже может быть интересно.
Последние два года я работаю в довольно интересном веб-сервисе. Хочу поделиться кейсами из опыта.
Как быть, когда в вашем портфеле несколько продуктов, каждый продукт развивает отдельный юзабилити-специалист, и у подразделения нет начальника?
Что делать, если каждым из этих продуктов пользуются «немного разные» люди, а навигация общая? (и вообще, продукты живут в едином веб-сервисе и должны между собой как-то дружить)
Как договориться, если все эти продукты — часть единого большого веб-сервиса с кучей общих мест?
Как решать общие проблемы?
Как синхронизироваться и быстрее внедрять лучшие решения из опыта коллег?
Как вообще работать без «арт-директора», «менеджера проекта» или другого начальника?
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хоро...Yandex
Конференция "План Б" в Санкт-Петербурге (17 декабря 2011)
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хорошо..." (DINO Systems)
Тезисы:
– тестировщики хотят того же, чего и все остальные – играть по правилам;
– правила игры не могут не меняться;
– готовность к изменениям закладывается при планировании;
– плановые риски требуют профилактики;
– планирование тестирования завершается не раньше, чем само тестирование.
Прыжок веры. От настоящегого к будущему. (AnalystDays2016)Alexey Vasilyev
При разработке и внедрении ИТ-систем мы так концентрируемся на факторе "чего бы такое продать клиенту, чтобы он купил", что забываем о "жизни после продажи". Как результат разработанная ИТ-система или изделие стоит на полке у Заказчика, а пользователи решают свои задачи привычным им способом.
К сожалению, о том, что надо было сделать, мы понимаем слишком поздно.
Как бы так сделать, чтобы подумать о будущем уже сегодня? Как заглянуть за горизонт событий?
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
История развития отдела вёрстки в Одноклассниках: причины, опыт организации, рефакторинг и путь к чистому коду. Помимо личного опыта и процессов в отделе, речь пойдёт о методологиях вёрстки и инструментах для командной разработки — зачем, как выбрать, на что обратить внимание.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Демонстрация процесса continuous delivery на базе коктейля – гремучей смеси из телесериала "Игра престолов" и богатом практическом опыте докладчика, а так же проговаривание примеров использования логических инструментов для облегчения работы тестирования.
Динамика изменений со стороны бизнеса (наших заказчиков) сейчас настолько велика, что впереди оказываются компании, процесс разработки в которых непрерывно эволюционирует.
Эволюционный процесс позволяет научиться делать более быстрые поставки, более качественные решения, а главное, поставлять с первого раза именно то, что нужно бизнесу.
Необходимый минимум для построения современных процессов разработки - это три ключевых, обязательных для освоения навыка, которым просто обязан научиться каждый участник проектной команды.
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
История развития отдела вёрстки в Одноклассниках: причины, опыт организации, рефакторинг и путь к чистому коду. Помимо личного опыта и процессов в отделе, речь пойдёт о методологиях вёрстки и инструментах для командной разработки — зачем, как выбрать, на что обратить внимание.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Демонстрация процесса continuous delivery на базе коктейля – гремучей смеси из телесериала "Игра престолов" и богатом практическом опыте докладчика, а так же проговаривание примеров использования логических инструментов для облегчения работы тестирования.
Динамика изменений со стороны бизнеса (наших заказчиков) сейчас настолько велика, что впереди оказываются компании, процесс разработки в которых непрерывно эволюционирует.
Эволюционный процесс позволяет научиться делать более быстрые поставки, более качественные решения, а главное, поставлять с первого раза именно то, что нужно бизнесу.
Необходимый минимум для построения современных процессов разработки - это три ключевых, обязательных для освоения навыка, которым просто обязан научиться каждый участник проектной команды.
7. 7
• Популяризована
Якобом Нильсеном
• Помогает быстро найти
проблемы интерфейса
• Основана на
“эвристиках”
• Требует 3-5 экспертов
Эвристическая оценка
https://www.nngroup.com/people-jakob-nielsen-photos/
14. 14
1. Единообразие и стандарты
2. Соответствие между системой и реальным
миром
3. Эстетичный и минималистичный дизайн
10 эвристик Нильсена: Понятность
https://en.wikipedia.org/wiki/Heuristic_evaluation
15. 15
4. Свобода действий
5. Гибкость и эффективность
6. Всё должно быть на виду
10 эвристик Нильсена: Удобство
16. 16
7. Отображать текущий статус системы
8. Предотвращение ошибок
9. Помощь в исправлении ошибок
10.Справочные материалы и документация
10 эвристик Нильсена: Обратная связь
17. 17
1. Интерфейс решает задачу?
2. Простота и краткость представления
данных
3. Удобство
4. Понятность
5. Эстетичность
Наши эвристики
18. 18
Установочная сессия
1. Рассказать экспертам, что будет
происходить и что от них требуется.
2. Показать интерфейс
3. Объяснить эвристики
4. Раздать анкеты
20. 20
• Пройти сценарий минимум дважды
• Записать проблемы и нарушаемые
эвристики
Оценка: работа с макетом
21. 21
• Эксперты, наблюдатели, дизайнеры,
разработчики
• Обсудить результаты
• Предложить решения (Мозговой штурм)
• Оценить возможность исправления
• Ранжировать проблемы (0..4)
Подвести итоги: как должно быть
22. 22
• Эксперты по очереди оглашают найденные
проблемы. Ведущий записывает их на
доске
• Ранжируем проблемы
• Выделить самые значимые (не более трех)
• Оставляем самых сильных экспертов (1-2)
• Проводим мозговой штурм по решению
самых важных проблем
Подвести итоги: наш опыт
23. 23
• Работая с макетом эксперты, не должны
общаться между собой
• Макет смотреть за обычным монитором, в
отдалении от «помех»
• При высказывании проблем не спорить.
Всё решится на подведении итогов.
• Не настаивать на заполнении анкеты
Наш опыт: правила
24. 24
• Только небольшие интерфейсы, которые
можно изучить за 10 минут
• Минимум 4 человеко-часа всё равно
тратятся
• Может затянуться дольше, чем на час
• Выявляется меньше проблем, чем в
юзабилити-тестировании
• Не каждый может стать экспертом
Проблемы
25. 25
• Выявили наиболее острые проблемы
• Предложили их решение
• Это быстро
• Ускорилось согласование макетов
• Повысилось качество интерфейсов
Что получилось