Дизайн-мышление (ДМ) – это методологии решения инженерных, управленческих и других бизнес-задач, где акцент делается на творческой генерации идей. Как методологический подход к созданию революционных решений появился довольно давно: некоторые его элементы можно обнаружить в практике компаний еще в 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 (ну, мышление же, господа, не способ работы) слышала в доблестной компании IBM лет 5 назад. От консалтера, а , вренее, консультанта. Он, правда, не смог толком об этом рассказать, т.к. являлся теоретиком в области управления, хотя что-то понимал в разработке. Основные риски гибкого подхода (а Agile - это подход ко всему, не только к разработке) заключаются как раз в области управления предприятием, которое этот подход использует. В том числе в разработке ПО. Уж столько об этом говорят, столько пишут. А тут эта мантра, "Design Thinkung"/ Как со старым знакомым повидалась )))
Как то трудно разделить мышление и работу, разве что на уровне навыка, который может-должен быть у разработчика ))).
ДМ - это метод или набор методов, как совокупности правил, приемов, способов и в том числе лежащих в основе этого мышления идей и принципов.
И очень достойно об этом написал Стив Джобс. - Цитата:
"Дизайн это не то как предмет выглядит, а то как он работает".
Если на пятом этапе ДМ предполагается прототипирование, а не шестом тестирование, то как отличить ))), что получим после работы с использованием ДМ и что на выходе Agile-Scrum?
Минимум в обоих случаях это должен быть Макет, в лучшем случае для ДМ это будет конечный продукт. Agile-Scrum будет скорее лишним )))
макет в ДМ будет конечным если он решает проблему пользователя или будет опровергнут тестом и итерации начнутся снова
эджайл и скрам могут легко сделать работоспособный макет или прототип, который не идеально прилажен к пользователю а лишь временно "в порядке"
в рамке ДМ сильна цель сделать эмпатию ядром всего продукта
Реально работающий Прототип или просто Решение тоже может быть конечным продуктом не менее чем в другой проектной деятельности.
Это будут означать толочь воду в ступе высокооплачиваемыми спецами.
Мне тоже понравилось, что в ДМ можно временно приостановиться, и есть время подумать и пообщаться. Бывает так, что серьёзная проблема решиться на подсознательном уровне ))) когда есть время подумать без гомона на Scrum Meetings, и когда не требуется смотреть предано в глаза Scrum Master оправдываясь за задержку .... )))
да Вы правы, но ДМ все же про дизайн и эмпатию, а не про продакшен
еще раз повторюсь что ДМ это экспансия дизайна в бизнес с дизайнерско гуманитарным подходом
кстати могут попасться дизайнеры не понимающие в исследованиях и не понимающие в ДМ, так что ДМ это еще и образовательная программа и для дизайнеров тоже )))
Я - либо совсем идиот, либо из меня пытаются сделать идиота, какими то новыми словечками... Кроме воды, на киселе, я так и не понял что - же такое ДМ... Речь о чём ???... О креативном (предприимчивом) мышлении, или о образном ???... Потому что в психологии ДМ - не существует...
Владимир это старая техника для проектировщиков дизайнеров из 30-х 60-х годов 20 века тогда дизайнерам требовалась орг смычка с менеджментом бизнесов и обьяснялка что такое дизайн - менеджеры уже тогда любили как то названные схемы и описанные в логике управленцев
Сегодня ДМ дошло и до нас, но очень "празднично" как шоу потому что продуктов разрабатывается мало доля разработанных своих сложных продуктов на полках не велика, а ДМ отлично заходит в большие бизнесы связанные с услугами для улучшения культуры оказания услуг - типа не заказывают дизайнерам разработку сложных продуктов продай лаборатории ДМ ))) и хорошо продаетс
Дмитрий, если создаётся и продаётся товар (услуги, лаборатории, IT лаборатории студии), то процессы производства (мыслительные процессы(, нужно точно представлять... Особенно зная статистику мыслительных способностей населения... Я так понимаю, что это формат соединения образного мышления (дизайн) и системного прогрессивного мышления (креативного)... При этом при образном мышлении, а это 20% способных людей от населения, только половина может иметь объёмное мышление (графически дизайнерское), при этом объёмное системное мышление, может и не иметь... Это особая категория людей...Около 1% от населения... Основное население при том что есть 3D всё равно видит плоскую картинку...
Рынок и ниша мне понятна, она колоссальна... Но чтобы понять тем, кто решил разрабатывать такой товар и торговать им, нужно понимать все процессы его производства, отсюда и понимание рынка...
это ключевое, нас в свое время прямо готовили работать в тройке с инженером и технологом - причем с очень хорошим инженером и очень хорошим технологом, а сейчас в институтах дизайна НЕТ инженерной кафедры