Дизайн-мышление (ДМ) – это методологии решения инженерных, управленческих и других бизнес-задач, где акцент делается на творческой генерации идей. Как методологический подход к созданию революционных решений появился довольно давно: некоторые его элементы можно обнаружить в практике компаний еще в 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
мышление всегда ок, а уж если "за дизайн" то дважды плюс, техника не новая но вполне рабочая если есть возможность повторять итерации техники при некачественных результатах этапов, позволяет за счет итераций выжать из ситуации проектирования многое и рационально перебрать вариант
По моему я где-то уже слышал... Новое мЫшление, углУбить, ленинградчина и тому подобное.... А если серьезно, то из той же мною "любимой" викепедии: "...Дизайн-мышление (англ. design thinking) — методология решения инженерных, деловых и прочих задач, основывающаяся на творческом, а не аналитическом подходе. Главной особенностью дизайн-мышления, в отличие от аналитического мышления, является не критический анализ, а творческий процесс, в котором порой самые неожиданные идеи ведут к лучшему решению проблемы..." Меня немного смущает "... не критический анализ, а творческий процесс..." Иными словами, меня должно волновать не на что потратят деньги компании (читай мои), а насколько творчески это сделают! И еще немного смущает, то что "к лучшему решению проблемы" нет добавки что это не временное, но "лучшее" решение... но возможно это просто мой старческий гундёж... :)))))))
в том то и дело, что на практике лучшие решения выбираются через итерации повтора проектного паттерна после провала тестирования прототипа и на это нужно время, столько времени сколько будет повторов цикла. поэтому бренды нанимают дизайн команды финансируя им столько времени сколько понадобится
к примеру полгода поисков, чтобы финальное решение было максимально улучшенным
Не понял как уходят от риска убытков и чем это отличается от обычного мозгового штурма. Ну вжились мы в роль потребителя и нам кажется, что идея супер, но выходим на рынок и упс....... у нас гугл глас. Так по моему с Нокией случилось. Кто в итоге ответит эта идея это эпик фейл или новый айпад. Я так и не осознал, как посиделки за пицей с пивом снижают риск провалов, раньше люди просто тусили а теперь это дизайн синкинг. В общем спорно и сыро
вся соль этой техники в распространении требований к этапам, просто шторм это выдвижение идей и их обработка, ДМ это множество кейсов правил и методов для каждого этапа ДМ- что нужно считать эмпатией, как именно выяснить что нужно потребителю, как уточнить и надежно проверить - множество привязанных к паттерну ДМ обменов опытом и результативностью, т.е. глубоко ли ты выяснил в первом этапе, сфокусировал ли верно на втором, проработал прототипировал и далее тест - а какие методы теста? они зеркалят ли методы выявления потребности - рамка ДМ скорее позволяет собрать все методы поэтапно и еще пообщаться по эффективности методов с активистами ДМ
Скорее Agile окажется здесь лишней - всё уже было и есть в ДМ )))
Автор статьи работает IT области и в его описании ДМ невозможно отличить от того, что продвигается как Agile-Scrum в бизнесе ))) - Очень Похоже - За исключением Новояза, который заполняет пустоту последнего. Но поскольку Agile уже сильно поднадоел, потерял новизну и множественно проваливается на практике, то - Дорогу ДМ )))
В плане провала идёт речь, конечно, не о разработке ПО, где применяются реальные технологии типа XP ))).
Суть создания Agile-Scrum состоит в том, что всё что можно из технологий пытаются затащить под зонтик Agile, ... Так что вряд ли получится - Вначале ДМ, а потом Agile - в очередной попытке Форма победит Содержание - Форма (Scrum) в этом случае довлеет.
И стоит вспомнить, что ДМ появилась намного-намного раньше, чем притащили технологии разработки ПО в "Agile в бизнесе". Если в разработке ПО это вело к увеличению производительности и результативности, то о результативности Agile в бизнесе говорить пока не приходится - об этом говорят уже и апологеты. Возможно, глубокое изучение ДМ поможет прогрессу - но Agile в принципе и не нужен в случае использования ДМ - в нем уже есть Всё что нужно ))) ДМ! - только без Agile-Scrum и его новояза )))!!!
Джордж Оруэлл:«1984» Приложение О НОВОЯЗЕ - Цитата: "Новояз должен был не только обеспечить знаковыми средствами мировоззрение и мыслительную деятельность приверженцев ангсоца, но и сделать невозможными любые иные течения мысли. Предполагалось, что, когда новояз утвердится навеки, а старояз будет забыт, неортодоксальная, то есть чуждая ангсоцу, мысль, постольку поскольку она выражается в словах, станет буквально немыслимой. Лексика была сконструирована так, чтобы точно, а зачастую и весьма тонко выразить любое дозволенное значение, нужное члену партии, а кроме того, отсечь все остальные значения, равно как и возможности прийти к ним окольными путями".
так само ДМ это просто рамка для набора техник по поводу - каким изначально и сделали ДМ
более того на открытых семинарах ДМ все время разбираются ошибки - фатальные ошибки применения методов эмпатии - а как на самом деле нужно спросить и а как на самом деле избежать выяснения не настоящей проблемы пользователя дизайна - т.е. ДМ за счет внутренних ресурсов не обеспечивает методом и появляются пуристы с докладами "а вот как нужно делать"
ДМ похоже на универсальную рамку общения между дизайнерами и клиентами дизайнеров - раньше клиенты вообще не понимали что делают дизайнеры и почему они не сразу рисуют эскизы - теперь научившись ДМ они включаются в процесс проектирования чуть более осознанно
можно ли слить в нуля ДМ - вполне, просто плохо сделайте первый этап ДМ и все станет бесполезным, но ДМ это и конференции, там расскажут вот зачем вы слили и неправильно сделали первый этап, так что как рамка ДМ работает за счет сообщества ДМ и организованной конференции ДМ
во всяких модных скрамах ДМ можно применить, но не очень эффективно - времени не хватит, ДМ построен на ошибочности действий и возврату к переделке этапов после тестирования или фокусировки, если скрамовцам дадут 3 месяца на ДМ или полгода тогда вроде может сложится, но кто даст то
у нас в рекламке креативные директора в сетевых агентствах дают креативным группам на разработку концепции общенациональной кампании для крупного бренда .... тадам 40 минут.... это дофига мало, вот где скрам техники, поэтому аполагетам ДМ с их медленным течением итераций мы только завидовали всегда
насчет новояза скорее не так
дизайнерам всегда было нужно селф промо правил своей работы, чтобы клиенты не прессовали а уважали - распространение рамки ДМ везде где можно делает из дизайнеров организаторов проектной работы куда включен сознательно клиент - это то хорошо как для дизайнеров
во вторых первый этап ДМ с эмпатией соразмерен необходимости проектирования UX и сразу делает из дизайнеров проницательных UXеров
Agile-Scrum тоже насобирал под свой зонтик множество техник, которые вместе должны работать, и Новояз как оформление этой рамочной суммы технологий, ограничивающий - шаг влево, вправо - "расстрел на месте" - удалят из SCRUM Team.
Почему вы решили, что Agile-Scrum это быстро? Всё разбивается на итерации, которые повторяются - как метод проб и ошибок. И уже обсуждалось раньше неоднократно - на примере разработки ПО - если в проекте Agile предварительно не разработана платформа (может дорабатываться - но должна уже быть) на которой всё будет работать, то на выходе будет только макет ... Это далеко не быстро. Идея на самом деле такая же как и в ДМ - на выходе надо получить то, что нужно клиенту, пусть даже если он об этом ещё не знает )))
в этом случае дизайнерам можно дать время на привязку продукта к пользователю на глубинном уровне эмпатии, из практики исследований могу сказать, что пользователь может страстно желать 4% возможностей технологии и ему совсем не нужно 96%, хотя при неправильном опросе он вроде бы всего хочет
в такой ситуации ДМ может сильно разгрузить разработчиков