Человек и процесс. Зачем DesignOps нужен команде дизайнеров

Вместе с ДАЛЕЕ разбираемся, почему дизайн-команде необходим человек, который будет заниматься DesignOps-процедурами. И какие бенефиты это даст заказчикам продукта, которые не видят магии разработки и получают финальный результат работы. В конце статьи будет небольшой анонс.

Менеджмент дизайна возникает, когда дизайнер выпускает свой первый коммерческий продукт, в котором он примеряет еще и роль аккаунт-менеджера. При работе над крупными проектами роль менеджмента в дизайне усиливается.

Зарубежные авторы написали много статей о DesignOps, есть даже целая конференция по теме, но у нас только начинают вести разговор. Некоторые до сих пор думают, что это очередной buzzword, модное словечко для пускания пыли в глаза и повышения часовой ставки для заказчика. Хотя это не так, да и систематизация процессов еще никому не вредила.

Как в свое время DevOps был призван исключить QA и администрирование из списка забот разработчиков, так и процедуры DesignOps призваны вынести из дизайн-уравнения сервисные и коммуникационные задачи, а все, что останется — структурировать и подтолкнуть к развитию.

Воплощение концепции дизайн-операций зависит от потребностей команды. Для некоторых важны HR-ценности: мотивация, онбординг, управление скиллами и талантами (talent management). Для других это борьба с рутиной: автоматизация, доски, процедуры, собранные на workflow-движках. Для третьих более важны технологии: фреймворки, интеграции, пространства для коллабораций, дизайн-инструменты.

Этим можно заниматься коллективно, распределяя роли в дизайн-команде. Например, кому-то достается онбординг, кому-то гайды, а третий будет заниматься поддержанием актуальности инструментария. Но так придется приносить в жертву основную работу, а распределенная экспертиза слишком размывает фокус на процедуры и их ценность.

Если кратко: он следит за тем, чтобы результаты работы дизайнеров соответствовали требованиям процессов и стандартов, контролирует соблюдение форматов и процедур внутри команды, управляет мощностью команды, технологиями и ценностями.

Кажется, примерно то же самое делают и арт-директор, и проектный менеджер, и дизайн-лиды в командах — тогда в чем отличие? Единого ответа на этот вопрос нет. Но мы все равно попробуем конкретизировать суть дизайн-операций и опишем пять задач, которые возлагают на DesignOps большинство авторов:

1. Управляет мощностью и компетенциями команды

Задача дизайнеров и их главный профессиональный интерес — находить решение прикладной задачи. Для этого нужна насмотренность, погружение в контекст и предметную область, результаты исследований, дизайн-выходные, инженерные дни и еще многое другое. Все это вне пределов интереса проектного менеджера, но в фокусе DesignOps-менеджера.

Он четко понимает мощность дизайн-команды, у него перед глазами актуальный скилл-сет, а в руках инструменты для стимулирования развития дизайнеров. Инструменты разнообразны: от закупок курсов и внутренних митапов, до сертификации и внешних интенсивов. Он следит за грейдами и фиксирует движение по ним. DesignOps-менеджер всегда может ответить, как и за какой срок команда выполнит задачу, и вовремя защищает бюджет на обучение и онбординг.

2. Внедряет и улучшает процессы

Процессы — ключевые сущности, которые превращают людей в команды и формируют связи. Эти связи облегчают передачу информации между всеми участниками проектов и руководством. Самые слабые звенья процессов — точки коммуникаций. Задача DesignOps-менеджера следить за тем, чтобы эти точки не превращались в «бутылочные горлышки» и «глухие телефоны», чтобы форматы и формы передачи данных в них трактовались одинаково всей командой.

Для этого у DesignOps-менеджера есть множество инструментов, а также свобода их выбора и сочетания. Он решает, какая методическая платформа будет использоваться — бережливое производство, SCRUM, Agile или гибридные подходы.

3. Подбирает и внедряет инструменты

Правильно подобранный инструментарий составляет рабочую экосистему дизайнера: программные решения, средства коммуникаций, онбординга и накопления знаний. Процедуры, процессы, контроль версий, рабочее пространство и база знаний — все это должно воплощаться в конкретных интерфейсах. Какие именно сформируют рабочее пространство дизайнера, должен определять DesignOps-менеджер.

Инструменты должны быть едиными для всей команды и помогать развивать скиллы каждого участника. Следует помнить, что дизайнер часто выбирает свой путь развития с оглядкой на актуальный стек инструментов и технологий, принятый профессиональным сообществом. DesignOps-менеджер облегчает этот выбор.

4. Синхронизирует работу дизайнеров и разработку продукта

Задача прямо связана с организацией процессов, но имеет самостоятельный смысл:

Чтобы это произошло, важно иметь прозрачное понимание, каким задание должно быть на входе и какие процедуры будут выполняться при постановке целей.

В триумвирате продукта — продуктовый менеджмент, проектирование, дизайн — последний традиционно наименее интегрирован в DevOps-среду. Во многих компаниях это привело к организации процессов по принципу «wagile» — «водопад перед agile». Это неоптимальный подход, поскольку основные процессы «ждут», пока закончится проектирование. Наличие внедренных DesignOps-процедур позволяет использовать подход «dual-track», который обеспечивают доставку дизайна в продукт параллельно с основным циклом, не допуская холостого хода в разработке.

Показательный пример можно найти в практике Atlassian, которая интегрирует DesignOps-процедуры во все аспекты рабочего процесса проектирования, в том числе для сторонних команд.

Процедуры DesignOps заимствуют все лучшие практики у DevOps: они так же интегрируются в Agile, включают в процесс дизайн-методы исследований (discovery) и совершения открытий (discovery), а также доставку инсайтов и результатов дизайн в продукт (delivery).

5. Стандартизирует все, что поддается стандартизации

Обычно в организациях некому управлять стандартизацией процедур дизайна: арт-директор отвечает за дизайн-мышление, а проектному менеджеру не хватает погруженности в предметную область, чтобы решить эту задачу. Тем временем проработанные и переиспользуемые стандарты — это новая нефть проектирования.

Типовые задачи или действия необходимо зафиксировать процедурно или автоматизировать, что сэкономит уйму времени, улучшит взаимодействие, передачу заданий и информации. Чтобы это случилось, нужно много времени и внимания уделять анализу внутренних процессов. Это может себе позволить только DesignOps-менеджер.

Он же будет следить, чтобы все гайды, фреймворки, паттерны и дизайн-язык, используемый в работе, хранились в одном месте, актуализировались и применялись командой. Ранее эти сущности описывались в контексте дизайн-систем, теперь их связывают с DesignOps.

Концепция DesignOps объединяет многие существующие подходы и подводит их к единому знаменателю с фокусом на масштабирование процессов. Она забирает сервисные и технологические задачи не только у дизайнеров, но и окружающих их проектных и продуктовых менеджеров. DesignOps-процедуры фокусируют продукт на ценностях клиентов и помогают всей команде видеть ключевые сущности — работать вместе, доводить работу до конца, видеть ценность работы.

Многие включают в сферу интересов DesignOps-менеджера синхронизацию UX-стратегии с видением продукта. Например, в Fidelity ресурс дизайн-операций вовсю используется в создании многих продуктовых фреймворков, в частности, для измерения качества цифрового опыта (Experience Measurement Framework).

С точки зрения бизнеса DesignOps обеспечивает непрерывный техпроцесс проектирования, формирует эффективный конвейер. Но это конвейер, который не исключает творчество, а каждый его узел постоянно совершенствуется. Рутинные задачи уходят к специалисту с более дешевой ставкой, который поможет фокусировать ценные часы дизайнеров на тех работах, которые максимально важны для бизнеса и заказчика.

Это поможет использовать часы дизайнера только там, где они наиболее нужны в продукте. Можно брать больше проектов, делать больше фич за отрезок времени, быстрее вводить и выводить из проектов новых дизайнеров, не теряя при этом в ценности вклада каждого в конечный продукт.

Также, как и DevOps-процедуры в разработке, методология DesignOps помогает решить многие проблемы в общей картине разработки, сделать процессы дешевле и более предсказуемыми, а значит, более доступным становится и результат дизайна. Для заказчика это выражается в понятных метриках — сокращается time-2-market и, в конечном итоге, в ROI. Для разработчика — это eNPS команды и возвращаемость довольных клиентов.

P.S.: чтобы купить билет на РИФ, нужен аккаунт в RunetID.