Ситуация:
Потоковая проектная разработка или эволюционирующий продукт. Разработчики научились работать инкрементально и итеративно, а у дизайнеров пока не получается. Дизайн либо получается годным, но не вовремя, либо вовремя, но без кайфушек.
В Бюро используется несколько принципов, помогающих избежать обеих ситуаций. Принципы просты, и многие о них уже наверняка читали:
метод прогрессивного джипега, описанный Тёмой,
FFF (fix time, fix budget, flex scope), описанный 37 сигналов,
система управления временем «Ресурс», на основе ROWE (results oriented working environment).
Расскажу о своём опыте применения этих принципов в дизайнерской практике. Жизнь показала, что подход годится для всех, кто решится его применять: для дизайнеров, управленцев, разработчиков.
Но, дорогой слушатель, — «серебряных пуль» не будет. Чтобы заставить принципы работать, придётся заставить работать себя.
Дизайн-долг в продуктовой и заказной разработкеAndrew Shapiro
В процессе разработки смешанные команды, кроме технического, копят дизайн-долг. В долгострочной перспективе это понижает качество продуктов и моральный дух команды. Наиболее уязвима к дизайн-долгу заказная разработка, где лишних денег на рефакторинг дизайна нет. Рассмотрим профилактические меры и наименее дорогие способы расплаты с дизайн-долгами.
Подходы к организации процесса работы смешанной команды продолжают эволюционировать. Судя по вопросам на конференциях, участников заказной разработки продолжает интересовать как работать гибко c контрактами fix price и удовлетворять заказчика.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Дизайн-долг в продуктовой и заказной разработкеAndrew Shapiro
В процессе разработки смешанные команды, кроме технического, копят дизайн-долг. В долгострочной перспективе это понижает качество продуктов и моральный дух команды. Наиболее уязвима к дизайн-долгу заказная разработка, где лишних денег на рефакторинг дизайна нет. Рассмотрим профилактические меры и наименее дорогие способы расплаты с дизайн-долгами.
Подходы к организации процесса работы смешанной команды продолжают эволюционировать. Судя по вопросам на конференциях, участников заказной разработки продолжает интересовать как работать гибко c контрактами fix price и удовлетворять заказчика.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
Creative or competitor analysis? How important is analytics when choosing tasks? How often to update backlog? On what period it should be? Oleg gives answers to these and other relevant questions related to backlog filling.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Какие вопросы встают перед руководителем разработки? Что нужно анализировать для успешного решения задач и запуска проектов? Как меняются вопросы, когда тим-лид дорастает до руководства департаментом?
Creative or competitor analysis? How important is analytics when choosing tasks? How often to update backlog? On what period it should be? Oleg gives answers to these and other relevant questions related to backlog filling.
Материалы к докладу — https://github.com/x-raizor/ddd-talk
Поместите данные в начало процесса проектирования, это обнажит проблемы раньше и подарит идеи по визуализации. Между изменениями в данных и дизайне должна быть мгновенная связь.
Моделирование продукта с использованием бумажного прототипирования. Agilecamp...Andrew Shapiro
Нередки ситуации, когда дизайнеров рядом нет, а проект уже нужно запускать в разработку. Или — собран исчерпывающий бэклог, но не получается узреть, что собой будет представлять будущий продукт. Как увидеть и пощупать продукт, не выныривая из процесса сбора требований?
Рассмотрим дешёвую в применении и в то же время изящную и простую практику на основе бумажного прототипирование и подхода к моделированию «Wizard of Oz».
Agilecamp, Новосибирск, ноябрь 2011
10 камней преткновения пользователя в путешествии по сложному интерфейсуAndrew Shapiro
Чем затупляют свои копья пользователи сложных веб-сервисов. О чем не стоит забывать проектировщику интерфейса и дизайнеру, сосредотачивающихся на решении массы составных задач в ходе проектирования.
Поговорим коротко и на реальных примерах об опасностях, которые мы оставляем пользователям наших продуктов, оставляя без внимания такие вопросы как
— назначение продукта,
— нестыковки ментальных моделей,
— система пространственной ориентации,
— монотонность и множественные пути,
— непрерывность и область невидимости,
— учет особенностей человеческого восприятия,
— различный опыт пользователей,
— мнемонические правила и системы ценностей пользователей,
— особенности реального отклика разных типов прототипов,
— языковые формулировки.
«Шустрый» дизайн: подходы к декомпозиции проектирования взаимодействия в Agil...Andrew Shapiro
Методики декомпозиции инженерных задач в кроссфункциональной команде программистов хорошо изучены на данный момент. Как быть с декомпозицией на независимые задачи с случае с дизайном интерфейса и проектированием взаимодействия не всегда понятно, в особенности для молодых команд.
Общее стремление одновременно повысить скорость и качество разработки, приводит к тому, что специалисты в области опыта взаимодействия всё чаще включаются в agile-команды. Как лучше устроить процесс с этом случае. Что следует проектировать сначала, что можно проектировать независимо и что можно отложить на будущие итерации без страха получить несочленимые компоненты. Как без ущерба разделить то, что, по определению, должно быть целостным.
39. пример с логотипом
Счастливая разработка
Что это? счастливы заказчик
и разработчики.
Почему?
З.: проект сдан в срок,
работоспособен и прекрасен, деньги
идут.
40. пример с логотипом
Счастливая разработка
Что это? счастливы заказчик
и разработчики.
Почему?
З.: проект сдан в срок,
работоспособен и прекрасен, деньги
идут.
Р: проект воплощён, люди довольны
41. пример с логотипом
Счастливая разработка
Что это? счастливы заказчик
и разработчики.
Почему?
З.: проект сдан в срок,
работоспособен и прекрасен, деньги
идут.
Р: проект воплощён, люди довольны
42. многоэкранная схема
эволюция
новые продукты в жизнь
проектирование счастливая разработка новые проект,
пенсия
счастье
Антивещь
счастливое разрушение
несчастная разработка
процесс,
функции, классы,
элементы кода,
вёрстки
52. алгоритм
1. Увидеть образ результата. понимание
2. Отмерять время. ресурсы
3. Решить, что подойдёт. джипег
итерации
ФФФ
53. алгоритм
1. Увидеть образ результата. понимание
2. Отмерять время. ресурсы
3. Решить, что подойдёт. джипег
4. Делать, контролируя итерации
результат и время
ФФФ
54. алгоритм
1. Увидеть образ результата. понимание
2. Отмерять время. ресурсы
3. Решить, что подойдёт. джипег
4. Делать, контролируя итерации
результат и время
5. При нехватке времени, ФФФ
решить, как успеть