Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Двенадцатый митап Software Craftsmanship пройдет онлайн и будет посвящен высоконагруженным системам. Мы систематизирует инструменты, применяемые для разработки архитектуры высоконагруженных приложений, опишем базовый алгоритм из 6 шагов проектирования нагруженной системы.
Также мы рассмотрим 3 примера нагруженных приложений - клиент для участия в Real Time Bidding аукционах, поисковик вместе с краулером для него, чат.
Мы коснемся опасностей, которые подстерегают новичков и опытных архитекторов.
Кроме того, рассмотрим подходы к построению высоконагруженных систем в стартапе и в сервисной компании.
Александр Андронов, Engineering AssessmentScrumTrek
Улучшить можно то, что можно измерить. Это главный тезис измерения. Мы измеряем, чтобы улучшать. Мы хотим улучшать код, инженерку. Для этого нужно код измерять. Как?
Я расскажу о метриках на самом низком уровне создания IT-продуктов. О тех метриках, которые находятся на уровне инженерки, на уровне программистов и QA. Упор сделан на те, которые зависят от человеческого фактора, которые не измерить автоматическими инструментами. Работая над несколькими проектами и наблюдая за десятком других как Agile-тренеры, мы выработали 9 метрик, которые описывают текущее состояние системы с точки зрения инженерки. В динамике они помогают мгновенно реагировать, если что-то идет не так.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
Tech Talks @NSU: Методологии разработки ПО. Что на самом деле скрывается за с...Tech Talks @NSU
http://techtalks.nsu.ru
15 марта 2012. Методологии разработки ПО (Семён Факторович и Алексей Сапожков, Noveo)
«Семён Факторович (Noveo) рассказывает про методологии разработки и про то, что на самом деле скрывается за словами "scrum" и "agile"»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Презентация доклада Максима Дроздова, менеджера проектов компании "ИСС Арт" "Контроль над распределенной командой".
Вебинар "Управление удаленной командой разработчиков".
Tech Talks @NSU: Методологии разработки ПО. Что на самом деле скрывается за с...Tech Talks @NSU
http://techtalks.nsu.ru
15 марта 2012. Методологии разработки ПО (Семён Факторович и Алексей Сапожков, Noveo)
«Семён Факторович (Noveo) рассказывает про методологии разработки и про то, что на самом деле скрывается за словами "scrum" и "agile"»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
User Experience 2012: Как меняется Mail.Ru — Продукты, процессы, командаYury Vetrov
Презентация части интерфейсной команды Mail.Ru (Юрий Ветров, Алексей Кандауров, Александр Киров, Алексей Сергеев, Наталья Спрогис) на конференции User Experience Russia 2012.
ADN @ UI/UX Design Meetup Barnaul - «Эволюция процессов проектирования в веб-...ADN Digital Studio
- Боль старого подхода: Какие проблемы мы испытывали применяя старый метод, и что стало отправной точкой в поиске и разработке новых подходов к проектированию.
- Что такое “Золотой стандарт”, что мы из него взяли, и как перестроили процессы проектирования. С чем столкнулись, и что получили.
- Куда движемся: что планируем внедрять в ближайшее время, и как будем решать проблемы с проектирование крупных проектов.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"Sasha Kutsenko
Презентация Саши Куценко для семинара «Front-end разработка. Менеджерский блок», 29 января 2014 года, Санкт-Петербург.
http://leadzeppelin.timepad.ru/event/101471/
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
2. О чем этот рассказ?
— Как создается дизайн продуктов Mail.Ru –
все детали процесса.
— Новая интерфейсная команда – зачем она
создана и что именно делает.
— Инструментарий и технологический
процесс – как мы автоматизируем
производство.
— Прогнозируемый процесс развития
дизайна – как интерфейсные гайдлайны и
паттерны помогают сохранять единую
стилистику.
2
3. 1. Вводная
2. Команда
3. Процесс работы
4. Инструменты и технологический
процесс
5. Паттерны и гайдлайны
6. Тестирование и исследования
7. Творческие планы
6. Немного обо мне и прошлом опыте. Чем отличается
процесс в компании-подрядчике и продуктовой
компании.
6
7. Подрядчик – много разных заказчиков, нужен
быстрый старт нового проекта и ранние первые
результаты. Проще обучить клиента, чем каждый
раз менять процесс.
7
8. Продуктовая компания – небольшое количество
постоянных менеджеров-заказчиков, проще
подстроиться под них для большей эффективности.
8
9. 1. Вводная
2. Команда
3. Процесс работы
4. Инструменты и технологический
процесс
5. Паттерны и гайдлайны
6. Тестирование и исследования
7. Творческие планы
11. В Mail.Ru Group есть сразу несколько дизайн-команд в
разных продуктах и подразделениях – стратегические
продукты, социальные сети, многопользовательские
игры, юзабилити-лаборатория, поиск и другие.
11
12. Основные роли и специализации –
дизайнеры, проектировщики интерфейсов, юзабилити-
исследователи. Стремимся к не совсем четкому
разделению на проектировщиков и дизайнеров – так
эффективнее.
12
13. Нельзя делать одно большое внутреннее дизайн-
агентство – важна плотная работа с командами
продуктов, внедрение в них.
13
14. Моя команда работает над общепортальными
правилами, главной страницей, Почтой, Агентом и
их мобильными сайтами и приложениями. Плюс
новые коммуникационные продукты.
14
15. С июля команда выросла в два раза, но еще не
весь штат укомплектован. На каждом продукте
должны быть трое – проектировщик и два
дизайнера (для основной и мобильных версий).
15
16. Зачем так много людей? Важно обеспечить скорость
выдачи дизайна и его отличное качество. Также
проверяем много концепций, чтобы находить
интересные интерфейсные решения, поэтому работы
хватает.
16
17. Подрядчики и фрилансеры. Можно ли говорить про
них? Выстраиваем пул постоянных
подрядчиков, чтобы можно было закрывать задачи
при отсутствии собственных ресурсов.
17
18. 1. Вводная
2. Команда
3. Процесс работы
4. Инструменты и технологический
процесс
5. Паттерны и гайдлайны
6. Тестирование и исследования
7. Творческие планы
20. Мы используем классический подход к проектированию и дизайну
интерфейсов – в большинстве компании он выглядит аналогично.
Но есть нюансы.
Детальное Поддержка
Исследования Концепция Дизайн
проектирование разработчиков
Проверка решений
20
21. Много общения с менеджерами проектов и
1 продуктов, топ-менеджерами. Это отдельный
самостоятельный процесс, который мы также
выстраиваем.
21
22. Задачи двух типов – развитие текущих версий
2 продуктов и их новые релизы. Процесс похожий, но
отличается в деталях.
22
23. Долгосрочное планирование – весь пул задач по
3 продуктам известен, хотя приоритеты между ними
часто меняются. Форс-мажоры и внезапные
срочные задачи сравнительно редки.
23
24. Стараемся значительную часть работы по дизайну
4 переложить на проектировщика. В этом помогают
паттерны, шаблоны и гайдлайны. Снимает
угнетающую рутину с дизайнера и ускоряет процесс.
24
25. Процесс гибкий и может корректироваться по
ситуации на каждом из этапов. Где-то срезаем
углы, где-то наоборот – копаем глубже.
25
26. 1. Вводная
2. Команда
3. Процесс работы
4. Инструменты и
технологический процесс
5. Паттерны и гайдлайны
6. Тестирование и исследования
7. Творческие планы
28. Используем связку Adobe InDesign + Photoshop.
Есть неплохие альтернативы –
Fireworks, Visio, Omnigraffle, MS
Sketchflow, Axure, Balsamiq. Но наш вариант
считаем оптимальным. Почему?
28
29. Позволяет сделать мощную автоматизацию
1 производства – можно создавать сложные скрипты
и плагины для сокращения ручной работы.
Например, автоматическая выгрузка в вики.
29
30. Дает дизайнеру и проектировщику (почти) единую
2 рабочую среду. Наследование документов, сложные
библиотеки элементов, похожий
интерфейс, командная работа с файлом.
30
31. Проектировщик может делать максимально
3 приближенные к дизайну прототипы интерфейса.
Это ускоряет процесс и упрощает приемку –
меньше уровней абстракции.
31
32. Используем связку Jira + Confluence + Git. Также
работаем над автоматизацией работы с ними.
Например, нажимая в InDesign CTRL+S –
автоматически обновятся макеты в вики.
32
33. Меньше ручной работы – больше
производительность команды и времени на
создание интересных интерфейсных решений.
Процесс публикации готового дизайна:
1. Сохранить текущий документ
2. Экспортировать макеты в PNG и PDF
3. Дать правильные имена макетам
4. Синхронизироваться с репозитарием
5. Выложить макеты в вики
6. Приложить макеты к задаче в таск-трекере
7. Запросить комментарии у менеджера задачи
33
34. Быстрая публикация нового дизайна упрощает
приемку и другие процессы. Например, быстрое
итеративное прототипирование + юзабилити-
тестирование.
менеджер
дизайнер или
проектировщик
пользователь
34
35. Критично, чтобы автоматизация была
действительно автоматизированной – большие
накладные расходы по ручной публикации приведут
к ее нерегулярности.
35
36. 1. Вводная
2. Команда
3. Процесс работы
4. Инструменты и технологический
процесс
5. Паттерны и гайдлайны
6. Тестирование и исследования
7. Творческие планы
41. Быстрее и проще поддержка и развитие продукта –
3 типовые задачи решаются легко и быстро.
41
42. Новые участники команды быстрее разбираются в
4 продуктах компании и меньше косячат в первое
время работы.
42
43. Сейчас мы создаем гайдлайны по всем продуктам
под нашим началом. Процесс небыстрый, но скоро
финишируем и работать станет намного проще.
43
44. При создании гайдлайнов важно понимать, как и кем
они будут использоваться. Мы пишем не абстрактную
спецификацию, а готовим рабочий инструмент для
проектировщиков, дизайнеров, разработчиков и
менеджеров.
44
45. Из чего состоит гайдлайн? Описание сеток, типовых
элементов, цветов, шрифтов, принципов
использования иллюстраций и т.п. Т.е. он описывает
разные слои интерфейса.
45
46. Нужно сразу понимать, кто и как будет
поддерживать и развивать гайдлайны. Иначе они
быстро становятся неактуальными и даже
вредными.
46
48. Библиотека паттернов собирает типовые элементы
управления и информационные блоки, которые
используются в интерфейсе. Чем они помогают на
практике?
48
50. Сделаны в виде шаблонов для InDesign, которые
2 используются проектировщиками ежедневно. А
значит все общаются на одном языке.
50
51. Позволяют быстро собрать первую версию
3 прототипа интерфейса и дешево
экспериментировать в дальнейшем.
51
52. В библиотеке паттернов также критичен процесс ее
регулярного обновления. Важно, чтобы было просто
не только взять из библиотеки элемент, но и
положить в нее новый.
52
53. Первыми полезность хорошей библиотеки паттернов
осознали в Yahoo! Много продуктов, которые нужно
было развивать единообразно. Это и сейчас одна из
лучших библиотек, доступна публично.
53
54. 1. Вводная
2. Команда
3. Процесс работы
4. Инструменты и технологический
процесс
5. Паттерны и гайдлайны
6. Тестирование и исследования
7. Творческие планы
56. Пользовательское тестирование и исследования
критичны для получения хорошего массового
продукта. Мы выстраиваем процесс плотного
взаимодействия с юзабилити-лабораторией.
56
57. Юзабилити-лаборатория – это внутреннее
агентство, которое проводит исследования для
коммуникационных сервисов, социальных сетей и
многопользовательских игр.
57
58. Важно, чтобы лаборатория синхронизировалась с
нашим темпом работы над продуктами – могла
проводить много разных исследований для всей
пачки продуктов и их версий.
58
59. Задачи для лаборатории разные – где-то обычное
юзабилити-тестирование или eye-tracking, где-то
более неформализованные вещи – например, выбрать
подходящие звуки для Агента. Также
опросы, интервью, другие предварительные
исследования.
59
60. В лаборатории собрано много интересного
оборудования, которое вместе дает комплексную
картину – включая физиологические показатели
(кардиограмма, мозговые импульсы, дыхание и т.п.). В
вебе это не так важно, а вот игровикам очень нужно.
60
61. Помимо лаборатории активно используется сплит- и
бета-тестирование. Сравниваем разные дизайн-
решения, обкатываем новую функциональность.
61
62. Очень помогает мощная внутренняя система
статистики RB – можно отслеживать огромное
количество действий в интерфейсе.
62
63. 1. Вводная
2. Команда
3. Процесс работы
4. Инструменты и технологический
процесс
5. Паттерны и гайдлайны
6. Тестирование и исследования
7. Творческие планы
71. Было приятно видеть вас! Вопросы?
Юрий Ветров
www.jvetrau.com
twitter.com/jvetrau
www.mail.ru
facebook.com/pages/MailRu
Все иллюстрации, использованные в данной презентации, принадлежат их уважаемым владельцам. В случае, если вы являетесь их
правообладателем и против размещения этих иллюстраций – напишите, пожалуйста, письмо по адресу jvetrau@gmail.com и я уберу их из слайдов.