Дизайн-мышление (ДМ) – это методологии решения инженерных, управленческих и других бизнес-задач, где акцент делается на творческой генерации идей. Как методологический подход к созданию революционных решений появился довольно давно: некоторые его элементы можно обнаружить в практике компаний еще в 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 привлечением специалистов с высокими компетенциями исключительно под проект.

https://www.e-xecutive.ru