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

Современное гибкое (Agile) производство программного обеспечения базируется на принципах бережливого (Lean) производства. Чем меньше промежуточных артефактов разрабатывается в процессе, тем больше высвобождается ресурсов для разработки чего-то реально полезного. В связи с этим в Scrum-командах поощряется, если UX/UI-дизайнер не участвует в итерации, когда создается улучшение продукта.

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

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

Артефакты, часто ожидаемые от ключевых участников процесса производства цифровых продуктов

В маленьких компаниях ответственность за создание артефактов часто лежит на одном человеке, а в больших за это могут отвечать сразу три человека:

• продуктолог – менеджер продукта или проекта, владелец продукта в Scrum или бизнес-исследователь, член команды, собранной владельцем продукта;

• UX-дизайнер – аналитик-эргономист, архитектор взаимодействия;

• UI-дизайнер – специалист, отвечающий за внешний вид точки касания и за ощущения от продукта.

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

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

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

Конечно, современный рынок труда пока не готов поставлять таких универсальных Scrum-разработчиков, но тенденция к уменьшению ролей есть и на практике дает положительный результат. На рынке появляются UX/UI-дизайнеры или, как их иначе называют, продуктовые дизайнеры (Product Designer).

Объединение исторически разделенных ролей позволяет избежать образования «микроводопада» между ними и усложнения внутренних приемочных процедур.

Участники производственного процесса по-разному задействованы на разных этапах разработки дизайна продукта.

В модели слоев, описанной в главе 5, зоны ответственности будут распределены следующим образом.

На стратегическом уровне дизайном продукта занимаются люди, заинтересованные в его жизнеспособности, – инвесторы, заказчики, владельцы продукта. На уровне скоупа – владелец продукта и команда разработки, на последующих уровнях (структура, компоновка, поверхность) – исключительно команда разработки, включающая и продуктового дизайнера