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

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

Комфорт

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

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

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

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

Фреймворк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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