Андрей Богданов – Как сделать дизайнеров счастливыми (страница 3)

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

Все три потребности существуют постоянно, но дают о себе знать на разных этапах отношений дизайнера и компании.

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

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

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

И, наконец, прогресс. О нем дизайнер начинает серьезно задумываться, когда закрыты предыдущие, базовые, потребности. Даже если работать комфортно и интересно, возникают вопросы «А что будет дальше?», «Развиваюсь я или стою на месте?», а вместе с ними и желание двигаться вперед.

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

Для самых дотошных читателей оговорюсь: в строгом смысле слова, конечно, эти практики не являются алгоритмами, потому что не всегда предполагают четкой последовательности действий. Но «управленческие практики» звучат сухо и бюрократично, а прекрасное слово «паттерны» застолбил за собой Юрий Ветров[3]. Так что пусть будут алгоритмы.

Всего алгоритмов у меня получилось одиннадцать, по четыре на «комфорт» и «прогресс» и три для «интереса»:

Далее я подробно разберу эти алгоритмы, и каждому из них будет посвящена отдельная глава.

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

Потребность 1

Комфорт

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

Задача любого руководителя – рассеять неопределенность и снять психологическое давление со своей команды. Тогда сотрудники смогут «выдохнуть» и полностью сконцентрироваться на понятных и четких рабочих задачах.

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

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

Фреймворк

Первый алгоритм закрытия потребности в комфорте я назвал «фреймворк». Возможно, вы слышали, что так разработчики в IT называют набор инструментов, ускоряющих разработку приложений. Framework переводится с английского как «структура», «каркас» и даже «система взглядов». Фреймворком в широком смысле можно назвать любой набор инструментов, позволяющий, с одной стороны, упростить какой-либо процесс, а с другой – четко обозначить его рамки и границы.

Фреймворк работы продуктовых дизайнеров должен включать в себя три составляющие:

1) правила работы с задачами;

2) понятное распределение компетенций;

3) церемонии.

Поговорим о каждой из них подробнее.

Правила работы с задачами

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

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

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

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

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

Легкий фреймворк scrum, по которому работают (или стремятся работать) компании, где я получил основной опыт работы, предполагает, что работа команд разработки идет по спринтам. Спринты – это регулярные промежутки времени, в течение которых участники команды выполняют запланированные задачи. Спринт имеет фиксированную длину и обычно длится две недели, а задачи, которые будут выполняться в спринте, определяются на планировании спринта.

Я не буду рекламировать scrum: выбор фреймворка зависит от многих факторов, в том числе зрелости процессов в организации и стратегии продукта, и «серебряной пули» для всех не существует. Да и не хотелось бы заходить на территорию специалистов по скраму – это не моя профессиональная область.

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

Качественное планирование снимает стресс и у дизайнеров, и у заказчиков. Первым оно позволяет спокойно работать, а вторым – получить гарантию результата в виде обязательств по выполнению задач.

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

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

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

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

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

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

Понятное распределение компетенций

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