В бюро применяется принцип «исполнитель понимает задачу».
В армии ответственность за постановку задачи лежит на командире. Если его приказы будут размытыми и нечёткими, солдаты вляпаются в болото или забредут на минное поле. Солдаты не имеют права на размышления и инициативу, а отвечать за неудачу будет командир. Командир — военный профессионал.
Сервис устроен иначе. Клиент ставит задачу профессионалу, но профессионал не имеет права рассчитывать на то, что клиент окажется хорошим командиром. Чаще всего клиент вовсе и не хочет им быть — он заказывает услугу и ждёт хороший сервис. Человеческие отношения построены на ожиданиях, и первым делом нужно узнать — чего же именно ждёт клиент.
Внутренние взаимоотношения в бюро устроены так же. Арт‑директор — не командир дизайнеров, а дизайнер — не командир программистов. Дизайнеры и разработчики отвечают за свою работу и неудачи.
Отсюда универсальное правило — исполнитель понимает задачу. Профессионал не начинает работу, пока не убедится, что он понял задачу и что клиент согласен с этим пониманием.
Бюро и клиент
Если клиент предоставит исполнителю самое подробное техническое задание, нет никакого способа узнать, что исполнитель его правильно понял. Как усердно бы дизайнер ни кивал головой, он мог увидеть в задании что‑то своё.
Единственный способ клиенту и исполнителю убедиться, что задача понята правильно, — исполнитель должен письменно описать, что он собирается делать. Поэтому после рассказа клиента бюрошники всегда сами пишут «понимание задачи» и согласовывают с клиентом каждое слово.
Во время работы над проектом дизайнеры получают замечания клиента, сами составляют и согласовывают список правок, чтобы убедиться, что старые ошибки не повторятся. Бюро понимает задачу.
Арт‑директор и дизайнер
Работа дизайнера с арт‑директором начинается с первого дня проекта. Нельзя принести работу накануне дедлайна и рассчитывать её сдать.
Однако нет никакого смысла изо дня в день приносить арт‑директору полуфабрикат с одними и теми же недостатками. Вместо ценных советов дизайнер будет получать повторяющийся набор замечаний. Прогресса в работе не будет.
Поэтому каждый визит дизайнера к арт‑директору — мини‑презентация, в ходе которой он отчитывается о работе и исправленных ошибках и сортирует новые замечания. Дизайнер разбирается в задаче, составляет и утверждает у арт‑директора новый туду‑лист. Дизайнер понимает задачу.
Дизайнер и разработчик
Дизайнер передаёт результат собственной работы программисту в виде картинок и пояснений. Как бы подробно дизайнер ни продумал проект, его эскизы — всего лишь разрозненные плоские «снимки» будущего многомерного продукта. Любой элемент интерфейса не только имеет набор собственных состояний и режимов управления, но и влияет на другие элементы, часто неочевидным образом.
Когда дизайн попадает к профессиональному разработчику, он должен убедиться, что правильно понимает задачу. Поэтому разработчики в бюро описывают сценарии использования, режимы и состояния элементов управления в подробных технических спецификациях. Эти спецификации согласовываются с дизайнерами.
Во время разработки программисты сталкиваются с нерешёнными дизайнерскими задачами, непредвиденными состояниями и техническими трудностями. Необходимые изменения в проекте разработчик согласовывает с ведущим дизайнером и сам формирует новый туду‑лист. Разработчик понимает задачу.
Принцип «исполнитель понимает задачу» не отменяет ответственности ведущего дизайнера за выбор исполнителя и контроль проекта. Ставящий задачу понимает, что, кому и как он делегирует. Одному исполнителю можно поручить сдать проект, а другому нужно дать команду копать канаву «до обеда». Но во всех случаях за проектом и канавой нужно пристально следить.