User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...Yury Vetrov
Презентация Юрия Ветрова "Когда проектирование заказывать не нужно. Памятка для клиента и проектировщика" с конференции User Experience / UPA Europe 2009.
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
User Experience / UPA Europe 2009: Когда проектирование заказывать не нужно. ...Yury Vetrov
Презентация Юрия Ветрова "Когда проектирование заказывать не нужно. Памятка для клиента и проектировщика" с конференции User Experience / UPA Europe 2009.
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
16-17 августа в Санкт-Петербурге на Курсе Интерактивных Коммуникаций в Рекламе (ИКРа) Максим Кузин, продакшн-директор GRAPE, провел интенсив «ИКРа. Digital Produсer».
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Гибкие методологии при создании ИТ продукта. Сравнения. Основные инструменты.
Дашкин Руслан Валерьевич, тренер-консультант, сертифицированный преподаватель АСКОН.
18 сентября 2014 г.
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
Цель этого процесса состоит в том, чтобы ответить на вопрос: «Есть ли у нас стоящий и жизнеспособный проект?» Мандат на проект обычно является единственным документом, который существует при запуске этого процесса, и этой информации недостаточно для того, чтобы Совет проекта принял решение о начале Стадии инициации.
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Курс Управления Проектами.
Лекция 1- 2 .
Содержание:
Вступление
Что такое Project Management
Кто такие менеджеры проектов в IT?
Должностные обязанности менеджера проектов.
Разница между Product и Project Manager.
Перспективы развития: горизонтальная и вертикальная карьерная лестница.
Типы IT компаний.
Разница между аутсорс, аутстафф и продуктовой.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
16-17 августа в Санкт-Петербурге на Курсе Интерактивных Коммуникаций в Рекламе (ИКРа) Максим Кузин, продакшн-директор GRAPE, провел интенсив «ИКРа. Digital Produсer».
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Гибкие методологии при создании ИТ продукта. Сравнения. Основные инструменты.
Дашкин Руслан Валерьевич, тренер-консультант, сертифицированный преподаватель АСКОН.
18 сентября 2014 г.
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
Цель этого процесса состоит в том, чтобы ответить на вопрос: «Есть ли у нас стоящий и жизнеспособный проект?» Мандат на проект обычно является единственным документом, который существует при запуске этого процесса, и этой информации недостаточно для того, чтобы Совет проекта принял решение о начале Стадии инициации.
Продуктовый дизайн в рамках подрядных отношенийArthur Arsyonov
В этой презентации рассматриваются причины явления продуктового дизайна в рамках подрядных организаций. Основные ценности в сравнении с внутренними командами. Правила перехода и ключевые проблемы в этих отношениях.
По статистике, три из четырех проектов заканчиваются неудачей. Из-за нечетких целей, плохого планирования, недоучета рисков и так далее и тому подобное.
И есть еще одна причина.
Плохое управление людьми. Проекты делают люди, поэтому, все управление проектами – это управление людьми. А вовсе не вырисовывание красивых картинок в MSProject. Об этом вы поговорите с Олегом Вайнбергом, экс CIO и тьютором факультета менеджмента Открытого Университета Великобритании.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Similar to Software People 2010: Форматы работы команды проектирования интерфейсов с клиентом (Юрий Ветров) (20)
Will Robots Replace Designers? No. It's more like an exoskeleton for designers. Algorithm-driven design tools can help us to construct a UI, prepare assets and content, and personalize the user experience. In 2016 the technological foundations of these tools became easily accessible, and the design community got interested in algorithms, neural networks and artificial intelligence (AI). Now is the time to rethink the modern role of the designer.
Презентация Юрия Ветрова "Алгоритмический дизайн: Экзо-скелет для дизайнера" с конференции User Experience Russia 2016. Обновлено для конференции Krupa Product Design Conference 2017.
The shorter version of these slides was presented at Amuse UX 2015 Special Meetup (Budapest, Hungary) — http://www.meetup.com/UXbudapest/events/225944151/.
WUD2012 Tallinn: Y.Vetrov — How to Turn Around an Aircraft CarrierYury Vetrov
The presentation "How to Turn Around an Aircraft Carrier — Changing UX in One of the Europe’s Largest Online Companies" told by Yury Vetrov at Pan-Baltic World Usability Day 2012, Tallinn.
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, командаYury Vetrov
Презентация части интерфейсной команды Mail.Ru (Юрий Ветров, Алексей Кандауров, Александр Киров, Алексей Сергеев, Наталья Спрогис) на конференции User Experience Russia 2012.
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...Yury Vetrov
Мастер-класс Юрия Ветрова "Кросс-платформенное проектирование для мобильных — Android, iPhone, Windows Phone 7, Symbian" с конференции User Experience 2011.
User Experience 2011: Мастер-класс: Кросс-платформенное проектирование для мо...
Software People 2010: Форматы работы команды проектирования интерфейсов с клиентом (Юрий Ветров)
1. Юрий Ветров Форматы работы команды проектирования интерфейсов с клиентом и командой разработки UI Modeling Company
2. О чем эта презентация? Для решения каких задач клиенту бывает нужна помощь специалистов по интерфейсам. Что могут предложить проектировщики со своей стороны. Как совмещаются эти спрос и предложение на практике. 2
4. Проблемы клиента Что заставляет клиента обратиться к специалистам по проектированию? Основные пожелания: Снять с себя нагрузку по проектным работам. Выполнить эти работы более быстро и качественно, чем это можно сделать внутренними силами. Быстро решить конкретные интерфейсные проблемы в существующем проекте. Получить свежие идеи извне. Подтвердить качество интерфейса тем, что его делали квалифицированные специалисты. 4
5. Что нужно клиенту от проекта Ключевые слова, которые важно услышать клиенту: Быстро – так, чтобы успеть внедрить придуманное. Дешево – так, чтобы не пришлось выторговывать дополнительный бюджет «наверху», а если можно – сэкономить, сделав что-то внутренними силами. Качественно – так, что не нужно будет переделывать, будет готова всеохватывающая документация, продуманные и проверенные решения. Сразу знать все затраты - так, чтобы не было ползучего бюджета, понимать что не нужно будет заказывать что-то сверху. 5
7. Что может дать команда проектирования 3 главные задачи специалистов по интерфейсам: Проработать концепцию нового проекта – кто его целевая аудитория, что он умеет делать, на кого похож и чем от них отличается. Подготовить сопроводительную документацию по интерфейсу – из чего он состоит, как выглядит и работает, что делает в исключительных ситуациях. Улучшить потребительские качества существующего проекта – решить болезненные проблемы, подтянуть ключевые показатели эффективности. 7
8. Что нужно проектировщику от проекта Ключевые слова, которые хочет услышать проектировщик: Прибыльно – так, чтобы покрыть издержки, заработать на развитие и персональный виш-лист. Опыт и наработки – такие, что их можно использовать в будущих проектах. Портфолио – такой проект и клиент, наличие которого поможет получить новые заказы. Риски – такие, что не сделают проект убыточным, репутацию подмоченной, а атмосферу в команде напряженной. 8
10. 10 Когда мы подключаемся до начала работ – есть возможность повлиять на общую концепцию; уже в процессе разработки – возможности более ограничены, но время есть; в ходе эксплуатации – необходимо улучшать то, что уже есть;
11. 11 Кто отвечает за концепцию клиент – основы продукта задаются «сверху»; команда проектирования – предлагает и прорабатывает ее на основе общего направления; совместная выработка концепции;
12. 12 Тип взаимоотношений подряд – прямой заказ; субподряд – общение через промежуточный контакт; собственный проект; проект в партнерстве; привлекаемый консультант – без непосредственного участия в проекте;
13. 13 Состав работ концепция продукта – общее видение, целевая аудитория, ключевые функции; документация на интерфейс – детальное проектирование, дизайн, сопроводительные документы; консалтинг – рекомендации, помощь в выстраивании процесса внутри;
14. 14 Ресурсы бюджет – какие работы можно включить в процесс; сроки – когда и какие результаты будут нужны; доступность принимающих решения лиц – будут ли решения согласовываться быстро; политические ограничения – нет ли косвенных ограничений;
15. 15 Итеративность процесса в целом по проекту – «водопадные» или гибкие методики разработки; для работ по интерфейсу – как часто мы можем показывать результаты клиенту, обсуждать их и дорабатывать;
16. 16 Цена ошибки завязан ли продукт на управление критичными ресурсами (например, деньги), жизнью человека, экологией? есть ли возможность вносить изменения после запуска продукта?
17. 17 Кто принимает решения единствои согласованность принимающих решения на стороне клиента; доступность этих людей для команды проектирования; окончательность согласованных решений и понятный процесс их корректировки;
18. 18 Знания и опыт опытность и адекватность заказчика– нужноли его учить, бороться с неадекватными менеджерами; знание предметной области – в первую очередь это касается проектировщика и его понимания сложных отраслей (например, финансы или медицина)
20. 20 Will It Blend? Зная перечисленные параметры, важно выстроить правильный процесс взаимодействия команды проектирования с клиентом и командой разработки.
21. 1. Привлекаемый ресурс в большой команде разработки 21 на первых этапах или позже, участие по мере возникновения задач (равномерно на одних этапах и кусками на других) регулярный контакт с командой разработки и руководством проекта, периодически – с клиентом четко оговоренные куски работ в большом процессе – редко больше одной задачи определяются конкретной задачей, режутся легко, доступ к стейкхолдерам минимальный труднодоступны для влияния – клиент, руководство проектом (забот хватает и без интерфейса) жестко задан сверху, все что помимо него – личная инициатива в свободное время можно сэкономить ресурсы и не мешать разработке, при том что за интерфейсом все-таки будут следить; постоянная включенность в проект – проектировщик в курсе дел; влияние на интерфейс часто косметическое – качественно улучшить можно далеко не всегда; проектировщик не особо развивается как специалист;
22. 2. Собственный продукт крупной компании 22 на ранних этапах, активное участие по ходу всего проекта единая команда в тесном контакте – продукт-менеджер, группы проектирования и разработки полный – проработка концепции, подготовка документации на интерфейс, проверка решений хватает времени, можно использовать другие внутренние ресурсы, доступ к стейкхолдерам и пользователям единая команда в тесном контакте – продукт-менеджер, группы проектирования и разработки проектирование идет на несколько шагов впереди разработки, частые обсуждения и доработка промежуточных решений обширные возможности влияния на интерфейс проекта;постоянный доступ команды разработки к специалистам по интерфейсу;накапливание знаний и наработок. в некоторые проектные фазы ресурс работает вхолостую;специалист надолго зацикливается на одном проекте.
23. 3. Заказной проект в комплексе (проектирование + разработка) 23 в самом начале, активное участие в первой половине проекта и поддержка после запуска тесный контакт с клиентом и командой разработки на первом этапе, далее интенсивность меньше полный – проработка концепции, подготовка документации на интерфейс, проверка решений достаточно времени для проработки концепции (ближе к запуску его меньше), доступ к стейхолдерам команда проектирования – соавтор концепции, клиент – владелец бюджета и бизнес-целей, разработчики – технические решения предварительная проработка концепции, затем – проектирование на шаг впереди разработки; частые обсуждения вначале широкие возможности влияния на интерфейс; есть время и возможность проверить интерфейсные решения; контакт с разработчиками помогает взаимопониманию; возможны проблемы с передачей ответственности за видение продукта;
24. 4. Прямой заказной проекттолько на проектирование 24 на первых этапах нового проекта или перед началом редизайна, поддержка после запуска тесный контакт с клиентом на первом этапе, далее интенсивность меньше; с разработчиками – как повезет подготовка документации на интерфейс, проверка решений; работа над концепцией – как повезет разброс вариантов большой, но чаще бюджет достаточно ограничен, хотя есть время и доступ к стейкхолдерам клиент, хотя как правило проектировщик может влиять на концепцию; как правило заказывает небольшая компания достаточно гибок, можно договориться на удобный для всех сторон вариант можно добиться хорошего влияния на интерфейс; компактные проекты, часто с быстрой оборачиваемостью; процесс гибок слишком много влияющих на концепцию людей, что часто вредит интерфейсу; проекты часто не доживают до реализации;
25. 5. Непрямой заказной проекттолько на проектирование 25 при хорошем раскладе – договоренность заранее, хотя часто в последний момент, когда нужно «вчера» субподряд – общение через менеджера проекта или аккаунта, что затрудняет предметное обсуждение интерфейса обычно только подготовка документации на интерфейс разброс вариантов большой, хотя времени бывает достаточно, но доступа к стейкхолдерам нет на стороне изначального заказчика, промежуточный менеджер проекта часто не может или не умеет влиять на давно принятые решения длительность обычно короткая, поэтому не так важен; итеративности как правило нет быстрая оборачиваемость; решения не всегда эффективны – не хватает итеративности процесса и доступа к принимающим решения;
26. 6. Помощь команде стартапа 26 на ранних этапах, часто до начала проекта, продолжение под вопросом из-за расползания концепции тесный контакт с клиентом (он же команда разработки), активное участие в формировании и проработке концепции полный – проработка концепции, подготовка документации на интерфейс, проверка решений времени хватает, доступ к стейкхолдерам есть, хотя с бюджетом часто есть вопросы часто полная энтропия – команда стартапа тесная, влияют на концепцию все; принятые решения легко меняются через час достаточно гибок, можно договориться на удобный для всех сторон вариант можно добиться хорошего влияния на интерфейс; процесс гибок; лучше быть частью этой команды концепция не устаканилась, поэтому корректируется ежедневно; проекты часто не доживают до реализации; основатели не всегда имеют опыт работы;
27. 7. Генерация идейдля работающего или планирующегося проекта 27 соответственно, перед началом редизайна или в процессе проработки концепции тесный контакт с клиентом, можно и нужно влиять на концепцию проработка концепции, подготовка предварительной документации на интерфейс времени и доступа к стейкхолдерам хватает, бюджет компактный, но достаточный клиент в плотной связке с командой проектирования; поскольку нужны идеи, работоспособность их не так важна предварительная проработка концепции, затем – проектирование; связки с разработкой как правило нет можно опробовать интересные и свежие идеи; нет давления сроков; увлекательный процесс для обеих сторон; речь идет об идеях, поэтому не факт что они будут внедряться;
28. 8. Легкий ремонт работающего продукта 28 перед небольшим редизайном, когда проблемы в продукте серьезно мешают его развитию тесный контакт с клиентом и командой разработки, хотя влиять на концепцию уже поздно подготовка документации на обновленный интерфейс, улучшение потребительских качеств продукта времени хватает, доступ к стейкхолдерам есть, но бюджет стараются держать компактным клиент в плотной связке с командой проектирования; в сложной корпоративной иерархии могут размываться изучение проблем, проработка их решения, оценка эффективности новых решений быстрая оборачиваемость; недорогой способ, решающий конкретные проблемы; сложно сделать качественные улучшения, часто нужно ограничиваться «косметикой»;
29. 9. Причесывание продукта перед запуском 29 в последний момент, когда уже сложно что-то серьезно изменить тесный контакт с клиентом и командой разработки, хотя влиять на концепцию уже поздно подготовка документации на обновленный интерфейс, улучшение потребительских качеств продукта по остаточному принципу – в ограниченное время и бюджет сделать хоть немного лучше команда разработки при одобрении клиента – внедрение изменений зависят от ее ресурсов быстрое изучение проблем, проработка их простых решений возможность быстро и дешево сделать продукт немного лучше не усложняя жизнь команде разработки; качественно изменить что-то уже сложно;
31. Ключевые метрикии их влияние на процесс Вовлеченность в проект: высокая, часть команды – мало проектов, глубокий опыт; низкая, временное подключение – много проектов, широкий опыт; Время подключения к проекту: рано, надолго – можно сделать много, дороже; поздно, коротко – косметические улучшения, дешево; Итеративность процесса: частые обсуждения и этапы приемки – более проработанные решения, но больше ресурсов клиента; сдается сразу все – меньше отвлекаются ресурсы клиента, но результат может быть не тем; 31
32. Процесс проектированияв идеале Чтобы получить хорошее решение, необходимо проработать и обосновать его. Исследования Проектирование, дизайн Внедрение Развитие продукта Проверка решений 32
33. …и на самом деле Реальный процесс неидеален, но к нему нужно приспосабливаться и уметь работать в нем. Исследования Проектирование, дизайн Внедрение Развитие продукта Обоснование сделанных решений 33