Дизайн-долг в продуктовой и заказной разработкеAndrew Shapiro
В процессе разработки смешанные команды, кроме технического, копят дизайн-долг. В долгострочной перспективе это понижает качество продуктов и моральный дух команды. Наиболее уязвима к дизайн-долгу заказная разработка, где лишних денег на рефакторинг дизайна нет. Рассмотрим профилактические меры и наименее дорогие способы расплаты с дизайн-долгами.
Подходы к организации процесса работы смешанной команды продолжают эволюционировать. Судя по вопросам на конференциях, участников заказной разработки продолжает интересовать как работать гибко c контрактами fix price и удовлетворять заказчика.
Ситуация:
Потоковая проектная разработка или эволюционирующий продукт. Разработчики научились работать инкрементально и итеративно, а у дизайнеров пока не получается. Дизайн либо получается годным, но не вовремя, либо вовремя, но без кайфушек.
В Бюро используется несколько принципов, помогающих избежать обеих ситуаций. Принципы просты, и многие о них уже наверняка читали:
метод прогрессивного джипега, описанный Тёмой,
FFF (fix time, fix budget, flex scope), описанный 37 сигналов,
система управления временем «Ресурс», на основе ROWE (results oriented working environment).
Расскажу о своём опыте применения этих принципов в дизайнерской практике. Жизнь показала, что подход годится для всех, кто решится его применять: для дизайнеров, управленцев, разработчиков.
Но, дорогой слушатель, — «серебряных пуль» не будет. Чтобы заставить принципы работать, придётся заставить работать себя.
Дизайн-долг в продуктовой и заказной разработкеAndrew Shapiro
В процессе разработки смешанные команды, кроме технического, копят дизайн-долг. В долгострочной перспективе это понижает качество продуктов и моральный дух команды. Наиболее уязвима к дизайн-долгу заказная разработка, где лишних денег на рефакторинг дизайна нет. Рассмотрим профилактические меры и наименее дорогие способы расплаты с дизайн-долгами.
Подходы к организации процесса работы смешанной команды продолжают эволюционировать. Судя по вопросам на конференциях, участников заказной разработки продолжает интересовать как работать гибко c контрактами fix price и удовлетворять заказчика.
Ситуация:
Потоковая проектная разработка или эволюционирующий продукт. Разработчики научились работать инкрементально и итеративно, а у дизайнеров пока не получается. Дизайн либо получается годным, но не вовремя, либо вовремя, но без кайфушек.
В Бюро используется несколько принципов, помогающих избежать обеих ситуаций. Принципы просты, и многие о них уже наверняка читали:
метод прогрессивного джипега, описанный Тёмой,
FFF (fix time, fix budget, flex scope), описанный 37 сигналов,
система управления временем «Ресурс», на основе ROWE (results oriented working environment).
Расскажу о своём опыте применения этих принципов в дизайнерской практике. Жизнь показала, что подход годится для всех, кто решится его применять: для дизайнеров, управленцев, разработчиков.
Но, дорогой слушатель, — «серебряных пуль» не будет. Чтобы заставить принципы работать, придётся заставить работать себя.
курс Ideann lesson 3. product development vs customers developmentAngel Relations Group
Презентация третьего занятия факультива "Предпринимательский образ мышления" в НИУ ВШЭ 2013/14
Онлайн площадка для обсуждения и выполнения Home Work http://vk.com/ideann
Шестое занятие факультива "Предпринимательский образ мышления" в НИУ ВШЭ.
Онлайн площадка для обсуждения и выполнения Home Work http://vkontakte.ru/club30450858
В презентации использованы слайды и конструктор бизнес-моделей Александра Остервальдера.
You and Сustomer: Solve problems Tsepkov Myasnikov Uzhevko SQAdays-15Maxim Tsepkov
Вы и Заказчик: решаем проблемы, а не отрабатываем требования (Максим Цепков, Андрей Мясников и Рина Ужевко на SQAdays-15) http://mtsepkov.org/You-and-Customer-sqadays15
курс Ideann lesson 3. product development vs customers developmentAngel Relations Group
Презентация третьего занятия факультива "Предпринимательский образ мышления" в НИУ ВШЭ 2013/14
Онлайн площадка для обсуждения и выполнения Home Work http://vk.com/ideann
Шестое занятие факультива "Предпринимательский образ мышления" в НИУ ВШЭ.
Онлайн площадка для обсуждения и выполнения Home Work http://vkontakte.ru/club30450858
В презентации использованы слайды и конструктор бизнес-моделей Александра Остервальдера.
You and Сustomer: Solve problems Tsepkov Myasnikov Uzhevko SQAdays-15Maxim Tsepkov
Вы и Заказчик: решаем проблемы, а не отрабатываем требования (Максим Цепков, Андрей Мясников и Рина Ужевко на SQAdays-15) http://mtsepkov.org/You-and-Customer-sqadays15
Материалы к докладу — https://github.com/x-raizor/ddd-talk
Поместите данные в начало процесса проектирования, это обнажит проблемы раньше и подарит идеи по визуализации. Между изменениями в данных и дизайне должна быть мгновенная связь.
Моделирование продукта с использованием бумажного прототипирования. Agilecamp...Andrew Shapiro
Нередки ситуации, когда дизайнеров рядом нет, а проект уже нужно запускать в разработку. Или — собран исчерпывающий бэклог, но не получается узреть, что собой будет представлять будущий продукт. Как увидеть и пощупать продукт, не выныривая из процесса сбора требований?
Рассмотрим дешёвую в применении и в то же время изящную и простую практику на основе бумажного прототипирование и подхода к моделированию «Wizard of Oz».
Agilecamp, Новосибирск, ноябрь 2011
10 камней преткновения пользователя в путешествии по сложному интерфейсуAndrew Shapiro
Чем затупляют свои копья пользователи сложных веб-сервисов. О чем не стоит забывать проектировщику интерфейса и дизайнеру, сосредотачивающихся на решении массы составных задач в ходе проектирования.
Поговорим коротко и на реальных примерах об опасностях, которые мы оставляем пользователям наших продуктов, оставляя без внимания такие вопросы как
— назначение продукта,
— нестыковки ментальных моделей,
— система пространственной ориентации,
— монотонность и множественные пути,
— непрерывность и область невидимости,
— учет особенностей человеческого восприятия,
— различный опыт пользователей,
— мнемонические правила и системы ценностей пользователей,
— особенности реального отклика разных типов прототипов,
— языковые формулировки.
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agil...Andrew Shapiro
Методики декомпозиции инженерных задач в кроссфункциональной команде программистов хорошо изучены на данный момент. Как быть с декомпозицией на независимые задачи с случае с дизайном интерфейса и проектированием взаимодействия не всегда понятно, в особенности для молодых команд.
Общее стремление одновременно повысить скорость и качество разработки, приводит к тому, что специалисты в области опыта взаимодействия всё чаще включаются в agile-команды. Как лучше устроить процесс с этом случае. Что следует проектировать сначала, что можно проектировать независимо и что можно отложить на будущие итерации без страха получить несочленимые компоненты. Как без ущерба разделить то, что, по определению, должно быть целостным.
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agil...
К искусству записи пользовательских историй
1. К искусству записи
пользовательских историй
Андрей Шапиро
12-я конференция .NET разработчиков, dotnetconf.ru
15 мая 2016, Челябинск, Смолинопарк, конференц-зал X.O.
2. 2
«Я, как Андрей Шапиро, проектирую
взаимодействие, чтобы множить радость в мире»
3. Даниэль и Гадензия пригласили
нашу «печную дизайн-команду»
в их семью из девяти человек
в Бонгве — городе Танзании.
Нашей первой остановкой был
рынок, где мы купили всё для
банкета: мясо, фасоль, картофель,
мука, фрукты, овощи и…
живую курицу.
Придя домой, женщины быстро
принялись разжигать три угольные
печи и нарезать мясо и овощи.
Старшему сыну, Годве, было
поручино зарезать вопящую
курицу. Камеры наготове, мы
видели надрез шеи, слив крови
и тушу, оставленную дергаться
в ожидании ощипывания.
4. Приготовления кушаний заняло
несколько часов. Кастрюли
и крышки менялись местами,
крышки использовались как
нарезные доски. Каждый
ингредиент, включая воду и курицу,
прошли несколько процессов перед
тем как попасть на стол. Тремя
часами позднее, когда готовка была
завершена, еда была тщательно
разложена по тарелкам для мужчин
и гостей, а женщинами и детьми
съедена прямо из кастрюль. Всё
было поглощено за 20 минут.
Затем, после уборки они разожгли
угольные печи вновь и начали
готовить ужин.
5. 7
История:
последовательность, контекст, ценность
Кристи питчит проект. В зале
сотни инвесторов, расписание
насыщенное. Кристи понимает,
что нет времени на обмен
бумажными визитками. Перед
началом питча она «открывает»
свою электронную визитку.
Теперь её визитку смогут взять
все желающие, находящиеся
поблизости.
6.
7.
8.
9. 11
Форматы историй. Классический
Я, как современный горожанин,
хочу вовремя найти достойный подарок
ко дню рождения друга,
чтобы не было мучительно стыдно
10. 12
Форматы историй. Классический
Я, как рекламодатель,
хочу покупать трафик с сайтов
автомобильной тематики,
чтобы эффективно использовать
бюджет на привлечение
РОЛЬ
ЗАДАЧА
ЦЕННОСТЬ
13. 15
Форматы историй. Изменение поведения
Вместо того
чтобы раздавать бумажные визитки,
которые теряют актуальность
и не вовремя заканчиваются,
<новое действие>
раздать электронные
14. 16
Форматы историй. Изменение поведения
<новое действие>
клиент видит актуальный отчёт
в любое время
тогда как сейчас
оператор регулярно ошибается
при создании и отправке отчёта
клиенту вручную
15. 17
Форматы историй. Изменение поведения
Начать отправку документов
на возврат НДС
через интернет,
и перестать возить их фурами
22. 24
Как организовать сбор историй
• Организовать встречу с «теми» людьми
• Кто-то один ведёт дискуссию, команда
поддерживает
• Задавать открытые вопросы, например
• С чего всё начинается?
• Что мы забыли в этом сценарии?
• Что ещё важно для роли „Менеджер“?
• Держаться формата, пока он помогает
23. „Система должна уметь
предоставлять все необходимые
групповые операции
в интерфейсе: статистика
по пунктам доставки, типам
доставки и оплаты“. В том числе:
выгружать города, пункты со сроками
и сборами;
показывать сколько пунктов открыто
для заказов
сколько пунктов по доставщикам
по типам доставки;
какие города включены в правило.
• Оператор видит какие параметры
далеки от нормы, чтобы
исправить ошибки настройки.
• Колцентр понимает какие
способы доставки в городе
не на ходу и какими их заменить.
• Оператор видит суммарные
статистические данные для пресс-
релизов.
• Оператор выгружает отчёт в Excel
о текущих тарифах для субъекта
доставки, чтобы отчитаться перед
руководством.
ФОРМУЛИРУЕТ ЗАКАЗЧИК ИСТОРИИ
24. 26
Дисциплина записи историй
• Убрать термины, гиперонимы, абстракции
• Менеджер использует CRM
• Заявитель получает документ
• Президент приказал напасть на соседнее
государство, чтобы защитить
интересы нации.
25. 27
Дисциплина записи историй
• Убрать термины, гиперонимы, абстракции
• Минимум:
• пользователь и его контекст
• проблема или задача
• полезное действие — ценность
• Отказ от пет-фич: „хотелось бы“
• Отказ от записи быстрых решений
26. 28
История с пузырями. Вводная
Продукт: Давно живущая электронная система
рекомендаций юристам и бухгалтерам
Участники: Заказчик, команда дизайнеров
Ситуация:
Заказчик пришел с готовым решением:
сделать всплывающие подсказки в виде
пузырей или подписывать функции
системы поверх полупрозрачной
«кальки».
27.
28. Начинали с пузырей, пришли к истинной проблеме:
Клиенты не становятся постоянщиками
29. 31
Критерии годности истории
• Ценность истории ясна
• Потребность — в сфере влияния,
поставка — в зоне контроля команды
• Внутреннее ощущение:
• понимаю задачу, чувствую боль
пользователя / бизнеса
• вижу несколько образов решения сходу
• хочу взяться и сделать: энергия
30. 32
Рекомендации по стилю в записи историй
• Синтаксис: подлежащее – сказуемое – …
• Сначала главное, затем детали
• Писать, как будто через минуту забудешь
суть, контекст и детали
• Инфостиль maximilyahov.ru/hello/
32. 34
Что сделать уже завтра
Рассказывайте и пишите истории…
Пробуйте формат роль—задача—ценность
„Человек действует, чтобы постичь своё
место в мире“
Я, как проектировщик взаимоедйствия, помогаю людям подружиться с компьютерами и друг с другом. Провожу сбор требований в составе команды,
Общаюсь с бизнесом, разработчиками и пользователями.Истории — первичный инструмент
Расскажу как и зачем развивать навыки добычи и записи историй
Это история? Чем она не годится для разработки?Это не типичная пользовательская история, какие мы используем при разработке ПО
Эта история для погружения. Она погружает в контекст и даёт необходимые детали.
Расскажу как и зачем развивать навыки добычи и записи историй
Это история? Чем она не годится для разработки?Это не типичная пользовательская история, какие мы используем при разработке ПО
Эта история для погружения. Она погружает в контекст и даёт необходимые детали.
В разработке исполь
Раз у нас несколько участников этой системызначит будут истории для каждого
Как ни странно, но все истории в софте пользовательские.
Пользователи, представители бизнеса, технология — части общей экосистемы.
Пользовательские истории — истории, описывающие работу этой экосистемы
На каких этапах процесса разработки появляются пользовательские истории
Раньше мне нравилась история про рекламодателя и автомобильный трафик