x
 
Артём
25 ноября 2013

Как в бюро ставят задачи?



В бюро при­ме­ня­ется прин­цип «испол­ни­тель пони­мает задачу».

В армии ответ­ствен­ность за поста­новку задачи лежит на коман­дире. Если его при­казы будут раз­мы­тыми и нечёт­кими, сол­даты вля­па­ются в болото или забре­дут на мин­ное поле. Сол­даты не имеют права на раз­мыш­ле­ния и ини­ци­а­тиву, а отве­чать за неудачу будет коман­дир. Коман­дир — воен­ный профессионал.

Сер­вис устроен иначе. Кли­ент ста­вит задачу про­фес­си­о­налу, но про­фес­си­о­нал не имеет права рас­счи­ты­вать на то, что кли­ент ока­жется хоро­шим коман­ди­ром. Чаще всего кли­ент вовсе и не хочет им быть — он зака­зы­вает услугу и ждёт хоро­ший сер­вис. Чело­ве­че­ские отно­ше­ния постро­ены на ожи­да­ниях, и пер­вым делом нужно узнать — чего же именно ждёт клиент.

Внут­рен­ние вза­и­мо­от­но­ше­ния в бюро устро­ены так же. Арт‑дирек­тор — не коман­дир дизай­не­ров, а дизай­нер — не коман­дир про­грам­ми­стов. Дизай­неры и раз­ра­бот­чики отве­чают за свою работу и неудачи.

Отсюда уни­вер­саль­ное пра­вило — испол­ни­тель пони­мает задачу. Про­фес­си­о­нал не начи­нает работу, пока не убе­дится, что он понял задачу и что кли­ент согла­сен с этим пониманием.

Бюро и клиент

Если кли­ент предо­ста­вит испол­ни­телю самое подроб­ное тех­ни­че­ское зада­ние, нет ника­кого спо­соба узнать, что испол­ни­тель его пра­вильно понял. Как усердно бы дизай­нер ни кивал голо­вой, он мог уви­деть в зада­нии что‑то своё.

Един­ствен­ный спо­соб кли­енту и испол­ни­телю убе­диться, что задача понята пра­вильно, — испол­ни­тель дол­жен пись­менно опи­сать, что он соби­ра­ется делать. Поэтому после рас­сказа кли­ента бюрош­ники все­гда сами пишут «пони­ма­ние задачи» и согла­со­вы­вают с кли­ен­том каж­дое слово.

Во время работы над про­ек­том дизай­неры полу­чают заме­ча­ния кли­ента, сами состав­ляют и согла­со­вы­вают спи­сок пра­вок, чтобы убе­диться, что ста­рые ошибки не повто­рятся. Бюро пони­мает задачу.

Арт‑директор и дизайнер

Работа дизай­нера с арт‑дирек­то­ром начи­на­ется с пер­вого дня про­екта. Нельзя при­не­сти работу нака­нуне дед­лайна и рас­счи­ты­вать её сдать.

Однако нет ника­кого смысла изо дня в день при­но­сить арт‑дирек­тору полу­фаб­ри­кат с одними и теми же недо­стат­ками. Вме­сто цен­ных сове­тов дизай­нер будет полу­чать повто­ря­ю­щийся набор заме­ча­ний. Про­гресса в работе не будет.

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

Дизайнер и разработчик

Дизай­нер пере­даёт резуль­тат соб­ствен­ной работы про­грам­ми­сту в виде кар­ти­нок и пояс­не­ний. Как бы подробно дизай­нер ни про­ду­мал про­ект, его эскизы — всего лишь раз­роз­нен­ные плос­кие «снимки» буду­щего мно­го­мер­ного про­дукта. Любой эле­мент интер­фейса не только имеет набор соб­ствен­ных состо­я­ний и режи­мов управ­ле­ния, но и вли­яет на дру­гие эле­менты, часто неоче­вид­ным образом.

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

Во время раз­ра­ботки про­грам­ми­сты стал­ки­ва­ются с нере­шён­ными дизай­нер­скими зада­чами, непред­ви­ден­ными состо­я­ни­ями и тех­ни­че­скими труд­но­стями. Необ­хо­ди­мые изме­не­ния в про­екте раз­ра­бот­чик согла­со­вы­вает с веду­щим дизай­не­ром и сам фор­ми­рует новый туду‑лист. Раз­ра­бот­чик пони­мает задачу.

Прин­цип «испол­ни­тель пони­мает задачу» не отме­няет ответ­ствен­но­сти веду­щего дизай­нера за выбор испол­ни­теля и кон­троль про­екта. Ста­вя­щий задачу пони­мает, что, кому и как он деле­ги­рует. Одному испол­ни­телю можно пору­чить сдать про­ект, а дру­гому нужно дать команду копать канаву «до обеда». Но во всех слу­чаях за про­ек­том и кана­вой нужно при­стально следить.


Поделиться
Отправить

Комментарии

Никита Прокудин
25 ноября 2013

Артём, у вас работа с программистом стоит на последнем месте. Разве не стоит дизайнеру прямо в процессе советоваться с технарями насчёт тех или иных фич?


25 ноября 2013

Никита!

Спецификация пишется как раз, чтобы в разработку не пошёл летающий асфальтоукладчик.

Примеры применения принципа идут в хронологии проекта, а не по важности. Есть и другие.

Михаил Орлов
27 ноября 2013

Говорят, в Индии было правило: перед спором каждый должен был пересказать точку зрения противника, и чтобы тот сказал: да, так.

Серёжа Переверзев
27 ноября 2013

На разработку спецификации требуется значительная работа (сопоставимая, если не превышающая усилия на разработку самого продукта). Как вы защищаете себя от потерь? Бывает ли, что вы составили подробное описание работы, а клиент отказался оплатить результат?

Евгений Игнашов
1 декабря 2013

Пользовательские сценарии пишет именно программист? Мы до недавнего времени писали сценарии. Это делали дизайнеры, т. к. программистов у нас нет и в принципе, всё продумать — это работа дизайнера (проектировщика). Сейчас от сценариев решили отказаться. Как считаете, есть польза в сценариях с описанием персонажей, контекста их использования сайта/сервиса и всем прочим?

Александр Кос
20 августа 2018

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Гугль-док, чтобы упорядочить командное обсуждение 1 Принцип «Прямо сейчас» Что значит «сделать»? О Скетче и Пиксельматоре 4




Недавно всплыло

1 Как снимали Феррари для обложки книги «Фотосъёмка автомобилей»? 2 Три признака иконочности 1 Как просить коллег о помощи, как оценить код программиста, навигация между книгами бюро, как научиться спрашивать 2