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