Дизайн-мышление (ДМ) – это методологии решения инженерных, управленческих и других бизнес-задач, где акцент делается на творческой генерации идей. Как методологический подход к созданию революционных решений появился довольно давно: некоторые его элементы можно обнаружить в практике компаний еще в 70-80-х годах. Однако лишь в последние 2-3 года можно говорить о действительно массовом использовании ДМ в IT-разработке.
Новое время — новое мышление
С чем это связано? Скорость, с которой бизнес и организации хотят получать готовые к применению цифровые инновации, резко возросла. Отрасли разработки ПО и комплексных IT-решений срочно понадобился способ, позволяющий снижать количество итераций и общие риски, которые несет процесс разработки по-настоящему топового по функциональности продукта. Причем этот сверхбыстрый и супернадежный способ должен был быть одинаково эффективным как для разработки продуктов с нуля, так и для доработки существующих решений.
Методика необязательно применяется для создания несуществовавших ранее интерфейсов или принципиально новых продуктов. ДМ, безусловно, подходит и для таких задач, но также прекрасно справляется и с привычными, будь то создание интернет-магазина или разработка мобильного приложения. Главная особенность использование ДМ — сокращение затрат на разработку и снижение рисков. Итераций, при этом, может быть большое количество, более того, они могут не прекращаться даже после создания успешного прототипа, если ваша цель — создание работающего продукта. Просто использование дизайн-мышления, в данном случае, обеспечивает высокую вероятность того, что конечный продукт «взлетит».
Главной особенностью дизайн-мышления, в отличие от аналитических методик, является творческий, интерактивный процесс, когда самые неожиданные идеи и предложения срабатывают и существенно сокращают сроки перехода от стадии генерации идей до разработки, и далее ввода в production. Принципиальное отличие от «классики» — отсутствие всей формальной стороны процесса с написанием ТЗ, согласованиями, получением утверждений от глав департаментов и прочих привычных элементов работы в крупных организациях.
ДМ-сессии позволяют «срезать» путь из точки А в точку Б за счет набора методик оперативной проработки скетчей и первичных прототипов, быстрого перехода к фазе тестирования и определения «шорт-листа» наиболее перспективных сценариев дальнейшего развития уже силами софтверных разработчиков. Во многом популяризации дизайн-мышления в последнее время содействовала и его идейная близость Agile-разработке.
Поток инициатив — в разработку и продуктив!
ДМ предшествует в производственном цикле работе Agile-команд. Design Thinking позволяет проработать все гипотезы решения до стадии адекватного задаче прототипа, с которым далее максимально удобно, просто и эффективно смогут работать программисты. В ДМ-подходе главное не собрать документы, сверить ГОСТы и технические стандарты, а создать рабочую гипотезу продукта путем вживания в роль конечного пользователя, через непосредственное прохождение «пути клиента» с примеркой на себя всех болевых точек и преимуществ будущего продукта.
На ДМ-сессиях участники оговаривают перечень инициатив и предположений по финальному продукту, которые с помощью специальных инструментов можно сразу же визуализировать, обсудить стэк технологий и инструментов, который оптимально подойдет под задачу. За счет такой оперативности можно прямо по ходу обсуждения конвертировать перспективную гипотезу в наглядный и понятный всем сторонам процесса концепт-проект.
Все пять классических шагов Design Thinking работают применительно к IT-разработке, вопрос только в том, как именно в каждом проекте их задействуют. Например, где-то акцент будет смещаться на стадию эмпатия в качестве главного этапа, в другом проекте — на фазу формулировки проблемы, какие-то проекты потребуют особого фокуса на прототипировании и т. д.
Не только для разработки
Следует отметить, что ДМ в ИТ сегодня успешно применяется не только для разработки digital-продуктов и решений, но и при обучении новым методам взаимодействия ИТ-департамента и бизнес-подразделений крупных компаний.
Эффект достигается через обмен мнениями в рамках ДМ-сессий, где обсуждаются все плюсы и минусы работы, выдвигаются гипотезы для улучшения качества коммуникаций разнопрофильных специалистов. «Как нам научиться лучше друг друга слышать?», «В каком направлении нам нужно наладить взаимодействие, и к каким практическим результатам мы должны стремиться и можем реально их достигать?». «Где у нас «тонкие места», а у конкурентов — преимущество над нашим продуктом и в организационных процессах, в чем мы отстаем?».
Казалось бы — простые вещи, но проблема в том, что разные специалисты видят их со своей точки зрения. Обсуждение, визуалиация схем взаимодействия (текущих и перспективных), сравнение с конкурентами и с лучшими практиками — прекрасный способ провести апгрейд внутрикорпоративного взаимодействия на новый уровень.
Еще один путь получения пользы от ДМ помимо генерации идей для IT-продуктов — решение с помощью методики таких глобальных задачи, как разработка общей стратегии развития компании, IT-стратегии, плана развития продаж, а также любых других стратегических задач по корпоративной трансформации. Это сложнейшие вызовы, на подготовку которых по классическим методикам уходят месяцы, тонны бумаги и много нервов. В рамках ДМ для этого необходимо всего лишь собрать компетентных специалистов в одном месте, обеспечив диалог представителей компании-клиента, консультанта, независимых отраслевых экспертов и сессиями за 2-3 дня выйти на единое понимание road map по всем поставленным задачам.
Помимо времени, это огромная экономия в деньгах, поскольку в предельно короткие сроки компания получает готовый план действий, без «воды» и оттестированный критикой лучших специалистов в своей области и разными точками зрения, а также дополненный перечнем инициатив и согласованных приоритетов в дальнейшей работе.
Все специфические для нашей страны моменты в этом отношении: сроки согласования, количество необходимых «апрувов» и подписей, комментарии типа «я не это имел в виду», «меня не было на том совещании», «я не успеваю прочитать», в рамках ДМ полностью упраздняются. Разница между «было» и «стало» — налицо, и она огромна.
Минусы, подводные камни и как их избежать
Поскольку в последние несколько лет дизайн-мышление переживает своего рода «хайп-стадию» своей адаптации, и каждая вторая компания или консалтер стали внедрять этот подход, базовый смысл ДМ часто подается в искаженном виде.
Прежде всего, есть соблазн воспринимать ДМ-сессии, как некий новый способ проводить семинары и деловые встречи. Я не раз встречался с примерами неудачного опыта с ДМ, когда от этой методики на практике реализовывалась только формальная составляющая. Если увлечься возможностями ДМ как инструмента для снижения коммуникационного барьера между департаментами, можно упустить момент, когда в диалоге нужно переходить к созданию реальных практических результатов. Одна из главных опасностей ДМ — так и не перейти к прикладной фазе. Специалисты встретились, пообщались, согласились. А далее — ни плана действий, ни продукта.
Между тем, каждая ДМ сессия должна приближать к практическому продукту или решению. У Agile-команды на входе должна быть user story, пусть даже в виде простого плана продукта: что нужно получить, в каком виде, с какими характеристиками и на какую перспективу в плане бизнес-результата.
Типичная ошибка — участники ДМ-процесса останавливаются на высокоуровневой формулировке задачи: «Нам нужно приложение с новым уровнем функционала». Разработчики с этой точки далеко не продвинутся, или потратят на такое продвижение уйму времени на итерации, доработку, переделывания и т. д. Но тогда пропадает весь смысл ДМ. Поэтому на любой сессии ДМ по IT-продуктам обязательно присутствие хотя бы одного разработчика, чтобы он в любой момент мог вмешаться в процесс, сразу отобрать реалистичные идеи под будущие прототипы и отсечь явно нереализуемые концепты. Также необходимо уточнить, что разработчику нечего будет «отсеивать», если задача будет сформулирована чересчур — команда попросту не сможет сгенерировать идеи, они будут такими же широкими и общими, как и сама задача.
Фокусировка и формулировка задачи ДМ-семинара должна быть четкой, в ней должна содержаться цель и персона, для которой мы решаем задачу. Пример: «Как мы можем помочь Васе купить подарок в один клик с помощью мобильного приложения?». Направить команду к правильной формулировке — задача модератора.
Следующая ошибка — отсутствие отраслевых инсайтов от консалтера, когда команда ко встрече с клиентом не готовится должным образом и не представляет на ней лучшие практики из своего (или мирового) опыта. Таким образом, проявление инициативы полностью перекладывается на плечи клиента. Между тем, заказчик, как правило, хорошо знает только себя и конкурентов, а вот времени и сил, чтобы по-настоящему погрузиться в глобальные тренды и работу с передовыми IT-инструментами, зачастую не хватает.
В итоге отдача от ДМ-сессии оказывается минимальной от возможного уровня. Вдохновить заказчика и показать ему лучшие практики — очень важно, но нужно очень тонко чувствовать грань между вдохновляющим питчем и навязыванием своих идей. Последнее тоже может дать результат для семинара — заказчик может прийти к прототипу по вашему сценарию. Однако в таком случае продукт рискует оказаться провальным, поскольку основные сценарии и направления разработки заказчик должен определить сам, «спросив у пользователя» на этапе эмпатии.
Последняя проблемная зона в ДМ-подходе — целеполагание. Нужно сразу понимать, зачем проводить ДМ-сессию, и от этого понимания отталкиваться в определении ее профиля. Относительно того, какую задачу предстоит решать — формируется разная команда специалистов.
Будущее ДМ: слияние с Agile, аутсорсинг, распространение
ДМ будет развиваться в IT и дальше: его продолжат массово использовать для разработки концепций продуктов, стратегий, программ digital-трансформации и т. д. В среднесрочной перспективе мы увидим полное слияние ДМ и Agile.
Получится высокоуровневая методология, когда генерация идей будет бесшовно встроена в процесс дальнейшей разработки прототипов с дальнейшей передачей в производство. В практике Accenture это происходит уже сегодня, инициативы и проекты такого рода реализуются сегодня в 40 различных отраслях с участием ведущих мировых игроков.
Также можно прогнозировать, что все ДМ-задачи останутся в компетенции агентств и внешних консультантов, внутренних специалистов типа Chief Design Thinking Officer не появится просто потому, что компаниям выгоднее аутсорсинг такого рода задач c привлечением специалистов с высокими компетенциями исключительно под проект.
Фото: Pixabay
Можно, на это посмотреть с другой стороны... Современный инженер. он уже и технолог и отчасти дизайнер... По крайней мере к этому идёт... Современные требования, а тем более будущие требования, в том. чтобы человек объединял в себе все эти качества и профессии... По крайней мере в области технических инноваций, без этого уже не обойтись... И возникает вопрос... если мне нужен дизайнер, то зачем ему инженерное образование, которое устарело, пока он учился... Начав работать по профессии. он на производстве будет постигать смежные сочетания знаний, от более опытных работников... При этом есть один большой плюс, у нового человека, не забита голова стереотипами. поэтому в моменты вникания и понимания он может выдать более нестандартные по эффективности решения...
Мы используем XP в разработке ПО уже много лет - это тот настоящий Agile, с которого всё начиналось - не Scrum.
И я не вижу противоречий в использовании ДМ - всё как родное ))), и на выходе будет конечный продукт.
Очень точно-образно пояснил Брюс Насбаум по поводу ДМ - это оформление творчества в формат процесса. И это не про Дизайн, в итоге это про Творческий Подход )))
И он ссылается на статью в блоге своей коллеги Helen Walters "Design Thinking Won’t Save You", в которой она разбирает плюсы и минусы ДМ:
https://helenwalters.com/2011/03/21/design-thinking-wont-save-you/
Дело в том, что уже пытались скрестить 6-Сигма с ДМ, и массового результата не получили. Скрещивать Agle-Scrum с ДМ - это как скрещивать Ежа и Ужа, оба будут друг друга тормозить или "колоть иголками".
Что стоит использовать, так это российский ТРИЗ + ДМ, как оформление творчества в формат процесса!
А по поводу аутсорсинга достаточно красочно написали Брюс Насбаум и Хелен Валтерс ))) - одна из ссылок была приведена выше.
так это оно и есть экспансия дизайна в менеджмент, пока дизайнеры не стали пропагандировать ДМ в середине 20 века они вынуждены были давить рынок своей харизмой
в середине века все стало ок - но пришли маркетологи и взяли на себя функцию исследований а кстати в ДМ дизайнеры возвращают себе управление исследованием и это неплохо, по сути ДМ со всем своим творчеством проваливается если проблема плохо исследована разработчиком - первый этап ДМ - ключевой
кстати дизайнеры дизайнерам рознь - есть типы I-based, T-based, М-based и так далее, для всех после T-based все ок с ДМ, но менеджеры не всегда знают разницы между уровнями в дизайне
настолько успешно, что общество похоже пропиталось этими идеями, и многие понимают это как Творческий подход для задач из разных предметных областей.
Но слишком много, на мой взгляд, ставят акценты и уделяют внимание методу Мозгового Штурма Осборна. Он помогает, конечно, можно привлекать для этого других спецов и даже клиентов ))), но Из результатов этого успешного опыта делают выводы ((( об использовании ДМ в больших командах, и там всё глохнет - Если собрать толпу молодых специалистов, то они не заменят одного опытного и творческою личность - но ему рта не дадут раскрыть, и атмосфера для творчества уже не та ((( Брюс Насбаум пишет, что после того как ДМ стал широко использоваться в больших компаниях, ДМ "закостенел"
На мой взгляд, одна из причин - ДМ не для большой команды. Возможности Спеца с большим творческим потенциалом - "Дизайнера" не будет использоваться по максимуму.
Но Харизма не помешает, конечно - но её влияние может отличаться для разных поколений. Для кого-то и Стив Джобс казался чудаком, хотя он не использовал ДМ, разве что на подсознательном уровне )))
ещё бы
это же даже не инструмент а рамка, причем более менее полезная для договоренности между бизнесом (желательно в 95% случаев производственным и в 5% бизнесом услуг) и достаточно подготовленным дизайн бюро с дизайнерами уровня T-based и выше
для бизнеса лучше подойдут наши методологи с внедрением в Самсунги, примеры знаменитых дизайн проектировшиков, которые действовали в направлении ДМ и эмпатии - Генри Дрейфус
а его конкурент Раймонд Лоуи больше арт директор-визионер, а успел сделать не меньше и проектировал для прямых конкурентов Дрейфуса - они шли параллельно по всем рынкам по конкурирующим клиентам и разница подходов не особо влияла на качество проектов, но Дрейфус представлялся системным проектантом, а Лоуи ярким харизматиком остро чувствующим будущее
что важнее для бизнеса - подробная системность при проектировании или яркая харизма и чувство будущего - вот это вопрос )))
Если не искать панацею от всего и сразу, то ДМ - работающий инструмент.
Мы применяли этот подход с 2014 г., сначала с поддержкой "носителей" технологии (Британская школа дизайна и пр.), а потом - сами. Область применения - разработка банковских продуктов (не только ИТ). ДМ легко "отторгается" (берется внутрь), если не относиться к технологии как к фетишу, а понимать, для чего тебе ЭТО нужно.
Многие определяют ДМ не как инструмент, а как культуру ведения дела, ключевым элементом которой является приятие и понимание позиции "второй стороны" (клиента, партнера), то, что в ДМ называется "эмпатия". "Надел галоши" клиента, походил в них, понял, как он смотрит на продукт/процесс/формат взаимодействия с тобой, и вперед, искать решение.
Ничего нового в этом нет, правы те участники обсуждения, кто "плавали, знаем", но про клиентоориентированность тоже знают все, однако каждый потребитель почувствует разницу между "знают" и "ориентируются".
ДМ - это алгоритм прохождения "тропой клиента". В чем-то похож на "шаги продаж" - это тоже форма организации работы. Наполнение может быть разным - в ДМ, на этапах "фокусировка" и "генерации идей", логично встраивается ТРИЗ или другие технологии "управляемого мозгового штурма" (Guided Brainstorming).
Опять же, если не превращать алгоритм в церемониал, а работать в нем, то скорость поиска и принятия решений реально увеличивается. ДМ - демократичный подход, с ним могут работать не только продвинутые креативщики, но и просто нормальные люди, которым интересна и небезразлична их работа. На любом этапе (прототипирование, тестирование) быстро вырабатываются свои внутренние правила и подходы, и работа ускоряется. На самом деле, многие работают с таким подходом, даже не называя это ДМ. В одном из форумов на Ехе участник из, по-моему, Красноярска, по пунктам расписал, как он видит работу по выходу на новый рынок, на самом деле, нарисовав формат ДМ.
Не совсем понятно являются ли слова "Британская школа дизайна" каким-то аргументом или нет :) - это типа франшиза, которая начиналась усилиями предпринимателя Александра Аврамова и его партнера Игоря Ганжа, основателя рекламного агентства "Пилот-медиа". И Дизайн мышление - это не Дизайн, хотя может использоваться и в дизайне - это уже ранее обсуждалось.
Нормальным людям ДМ тоже поможет, но тот же Алгоритм , или шаги, схему - используют разные названия - можно с таким же успехом применять и в Маркетинговом мышлении, и применяют ...И здесь в этих типах "мышления" нет чёткой границы. Например, если в этой статье заменить ДМ на Маркетинговое мышление суть особенно не изменится на тех же примерах )))
Если сравнить два крайних полюса этих двух "мышлений" :) ,то лучше всего подходит пример из логистики: ДМ - это продвигающая, а ММ - это вытягивающая. Это как пишите тропа клиента, но с разных сторон )))
И Демократичный подход можно использовать в очень небольшом коллективе, а в большом получается неуправляемая гомонящая толпа ((( И ещё раз - метод Brainstorming, в котором по принципам его организации может участвовать много людей - это исключение на одном из этапов ДМ. На остальных этапах- шагах слишком большое число участников будет только мешать - лучше работает небольшой устоявшийся коллектив с явными лидерами, опытными специалистами.