IBM Design Thinking на русском языке. Часть 4
Это заключительная часть рассказа IBM о собственной методологии и особенностях ее применения. Приводятся рекомендации по организации рабочего процесса, примеры вовлечения участников проекта для сбора обратной связи.
Предыдущие части перевода: первая, вторая, третья.
На практике
При использовании на практике любого фрейморка, формируются модели применения. Далее развернуто описаны паттерны и антипаттерны, которые мы выявляем во время работы с командами.
Приведите в рабочее состояние
Основная идея IBM Дизайн Мышления — прямое сотрудничество со стейкхолдерами приводит значительным результатам. Данная концепция применима для работы с командами размерами 10–200 человек. IBM Дизайн Мышление это набор концептуальных моделей, а не четких указаний.
Известно одно: если вы думаете, что IBM дизайн мышление замедляет работу, вы делаете что-то не так. Этот подход может только ускорять процессы. Вы продвинетесь вперед с уверенностью в выбранном направлении.
Все команды работают по-разному, потому что деловые отношения складываются тысячами различных путей. Поэтому будьте прагматичными при использовании нашего подхода. И научитесь лучше чувствовать команду.
Ваша команда
Ну конечно же у вас собрана многопрофильная команда? Иногда мы получаем неловкую паузу от людей после этого вопроса:
- «Мы работаем над привлечением дизайнера на пару недель, когда она освободится;»
- «Главный архитектор сейчас выступает в роли менеджера продукта;»
- «Мы команда очень сильных универсалов.»
Вы можете быть исключением, но если вы таковым не являетесь, есть более серьезный вопрос: в вашей команде есть все навыки, которые требуются для глубокого понимания решаемой проблемы, ее последующего дизайна и программирования, и предоставления от начала до конца соответствующего UX?
Если нет, то ожидания от релиза не оправдаются. И понадобится больше времени и ресурсов, чтобы завершить проект.
Сформируйте сбалансированную команду
Вовремя создания команды, задумайтесь какие умения понадобятся для гладкой работы. Просмотрев свое портфолио, мы обнаружили, что в среднем нужен 1 дизайнер на восемь человек пишущих код. Это примерная цифра, но она означает, что один дизайнер может продуктивно работать с 8 инженерами. Если добавить еще инженеров, без добавления дизайнеров — инженеры будут непродуктивны, или начнут делать работу дизайнера. Это свидетельствует о несбалансированности умений в команде.
Любой проект требует своего подхода. Для нового мобильного приложения на каждых четыре разработчика понадобится дизайнер; для большой back-end системы это соотношение 1:12. Но наше соотношение в среднем 1:8, и это говорит о потребностях в кадрах в компании.
Это полный состав команды. Он включает full-stack и back-end разработчиков, которые необходимы для высокопроизводительных продуктов. Мы выяснили, что соотношение между дизайнерами чистыми front-end разработчиками примерно составляет 1:1.
Ваше рабочее место
Для правильного применения IBM Дизайн Мышления необязательно иметь хорошо оснащенную студию. Неважно, в одной вы комнате или вас разделяют пространство, время и номер телеконференции. IBM Дизайн Мышление создано для помощи в работе с удаленными командами; для этого и придуманы Ключи. Культура важнее, чем совместное размещение.
Раз уж задумались о рабочем месте, важнее подумать, каким образом текущее пространство (виртуальное или физическое) укрепляет доверие и улучшает сотрудничество. Так как мы говорим о результатах команды, честная, индивидуальная продуктивность будет 3-я по списку. Помня об этом приведем несколько советов:
Выбирайте инструменты и организовывайте процесс максимально эффективно
Как можно чаще мы выбираем инструменты, которые доступны для каждого члена команды, независимо от роли и специализации. Мы дали доступ всем членам команды к инструменту визуального мышления. Таким образом даже разработчики могут проследить требования проекта по стикерам с изначальной информацией о целях проекта.
И нужно нечто, чтобы делиться прогрессом работ в реальном времени. Работа в реальном времени помогает создавать концепции, моделировать опыт и записывать решения. Отыщите инструменты которые позволят вам, создавать, улучшать и делиться своей работой с другими как можно быстрее. Пару стрим-камер примените для обсуждения бумажных прототипов в реальном времени с удаленной командой.
Создайте условия где ваша команда может свободно презентовать работу и конструктивно обсуждать ее.
У одной студии был интересный прием: вайтборды повернутые лицом команде означали, что время обсуждения еще не пришло; но если они обращены в сторону остальной части студии, все участники подключались для сбора обратной связи используя стикеры, пометки маркером или диалоги. В онлайне мы тоже используем инструменты для совместного сотрудничества, для сбора обратной связи.
Планируйте, и составляйте детальный бюджет для важных сессий, на которых обсуждаются:
- Планирование Холмов (когда вы создаете новых Холм или Холмы)
- Последние приготовления перед Нулевым Плэйбеком
В такие сессии не обязательно включать всех членов команды. При этом должны присутствовать ключевые участники, которые ответственны за прогресс проекта.
Наблюдения за пользователями реальных условиях
Наблюдения за пользователями это в первую очередь признание для самого себя — «Я не пользователь». Никто из нас не может по-настоящему примерить на себя шкуру пользователя, и прочувствовать его проблемы. Отодвинуть в сторону свои личные предпочтения, о том что следует для них создать нелегко. Но это может принести небывалый результат для пользователя.
Это заявление подталкивает нас к другим вопросам для пользователей. Мы задаем вопросы, чтобы получить правду о реальных трудностях пользователя без участия «главного свидетеля» который слышит, то что мы хотим слышать. Вместо «Вам нравится этот дизайн?», спросите «Что он для вас означает?» Вместо вопросов, «Стоит ли нам добавлять это в продукт» вы спросите «Что вызывает наибольшие трудности?»
Когда мы задаем нестандартные вопросы, мы открываем дверь с ответами, которые могут нас удивить. Подобные сюрпризы содержат ключи для правильных решений проблем пользователей. Вместо того чтобы проектировать инструмент, который помогает делать заметки, мы понаблюдав за пользователями выяснили, что им важней инструмент обмена сообщениями для улучшения общения в команде.
B IBM мы называем эти открытые наблюдения — «генерирующее исследование» благодаря им можно взглянуть на наши проекты под новым углом. Наблюдение за пользователями без ограничений, используя свой дизайн называется «оценочное исследование». Это исследование помогает сузить выбор лучших вариантов дизайна для удовлетворения потребностей пользователей.
IBM Дизайн мышление+ Agile
Это обширная тема. Когда люди говорят «agile» они подразумевают «ну вы в курсе, быстро, гибко, agile.» И agile c маленькой буквы «а». Другие под «Agile„понимают специфическую методологию. Ясно одно: вы можете применять Agile без IBM Дизайн Мышления, но вы не в состоянии использовать IBM Дизайн Мышление без Agile. Как же все-таки подружить IBM Дизайн Мышление с Agile ? Вот наш алгоритм.
- Строка 1: будьте скептиком, не фанатиком;
- Строка 2: Перейдите к строке 1;
Цель Agile методологии состоит в улучшении работы команд, чтобы добиваться лучшего результата для пользователей. Команды используют Agile для постоянного улучшения завершенной работы. Это касается и совместной работы членов команды. В тоже время IBM дизайн мышление предназначено для выявления реальных потребностей людей, отображения и реализации опыта, который улучшит их жизнь. Совмещая методы Agile и IBM Дизайн Мышления вы добьетесь успеха.
И IBM Дизайн Мышление, и Agile делают акцент на результатах, постоянном обучении, и сотрудничестве с командой. Комбинирование этих методологий создает прочную общую основу. Независимо от используемой командой Agile методологии, для получения максимума от IBM Дизайн Мышления будьте прагматичными и адаптируйте свой рабочий процесс.
Создайте правильную многопрофильную команду с умениями, которые вам понадобятся в в процессе работы. Внесите Ключи в рабочий процесс, и концентрируйтесь во время работы на пользователях и реальных решениях (это основополагающий принцип).
Используйте дизайн мышление чтобы ускорить процесс: не просто планируя и программируя, но улучшая понимание о пользователях, их проблемах и ваших возможностях, чтобы сделать нечто особое для них. Результат: меньше безуспешных попыток и лучшие результаты.
На случай если у вас нет уверенности какой подход быстрее приведет к цели, есть золотое правило: Ошибайтесь быстро! Найдите кратчайший путь для осуществления цикла, и вы вскоре будете на правильном пути.
