Привет! Меня зовут Серёжа, я дизайнер цифрового продукта в Альфа-Банке. Однажды я стал отвечать за вопросы по дизайну сразу для четырех команд. Мне постоянно писали в личные сообщения, и небольшая просьба что-то выяснить превращалась в полноценную консультацию, срочное дизайн-ревью сдвигало некоторые приоритетные задачи, и на свои дела времени не хватало. В этой статье я рассказываю, как я научился справляться с большим потоком задач с помощью книги Марка Форстера «Сделай это завтра», и как я адаптировал оригинальный метод под специфику работы продуктового дизайнера.

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

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

Да и число самих задач оставалось внушительным — какие-то нужно было делать параллельно, фиксировать их по прогрессу и ничего не упускать. Более того, много времени терялось из-за того, что я часто переключался между делами: прерывал работу над одной задачей, если в голову приходила идея по другой.

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

Как итог, я задался вопросом, как эффективно управлять своим временем. Пока я искал решение, мне посоветовали книгу «Сделай это завтра» британского автора книг по тайм-менеджменту и продуктивности Марка Форстера. Основная идея его подхода в том, чтобы все свои задачи на сегодня записывать в один закрытый список, а всё остальное и несрочное переносить на следующий или любой другой день (в зависимости от приоритета).

Я решил переложить теорию из книги на свое поле деятельности и поработать в таком формате несколько недель. Вот как это происходило на первом этапе.

Основы подхода

Раньше я работал в следующем режиме, который казался мне логичным: делал приоритетную задачу к определенному сроку; если что-то влетело, то помогал, ведь у коллег тоже все срочно; затем возвращался к своей основной задаче. К вечеру я понимал, что не успел сделать то, что запланировал.

Принципы из книги предполагают другое:

1. Составить список дел на день и подвести черту, чтобы закрыть его для новых задач. Важно взять на себя не слишком много: ограничить день несколькими задачами, оставив буфер для срочных входящих.

2. Выполнять задачи по закрытому списку, не переключаясь постоянно между ними.

3. Выделить отдельное время в течение дня для обработки входящих задач, чтобы не отвлекаться на них от работы над запланированными делами.

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

5. Если какое-то дело нельзя перенести на завтра, — добавить его под черту и выполнить в удобное время в течение дня.

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

Далее я выделил себе несколько тайм-слотов для проверки сообщений: утром, один или два раза в середине дня и ближе к концу рабочего дня. Таким образом я снизил количество переключений, что привело к большей сосредоточенности и скорости выполнения задач.

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

К примеру, если раньше я читал в сообщениях: «Серёга, привет! Мне надо сейчас пройти ревью», то в таком случае бросил бы макет и пошёл делать ревью. 

Но теперь я всегда уточняю: «До какого времени желательно посмотреть с учётом возможных правок?»

И выясняется, что чаще всего «сейчас» или «срочно» означает вполне себе конкретные даты — например, до конца недели. В таком случае ревью спокойно уходит на другой день, а мой сегодняшний день не страдает от других внезапно появившихся задач.

Исходя из этого, я вывел для себя правило: настоящая срочность — это когда откладывать в принципе нельзя, как при эвакуации. А «нужно срочно» в рабочем чате почти всегда означает «нужно к какому-то времени», просто это нужно уточнять. 

Мои дополнения

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

Первая проблема — размер задачи. И тут мало было просто декомпозировать задачу на этапы. Для закрытого списка требовалось точно указывать, что именно я буду делать. Не «Собрать макеты», а «Собрать сценарий загрузки документа на iOS/в светлой теме» или «собрать состояния ошибок для всех платформ». То есть формулировать задачу как можно более конкретно, чтобы понимать её границы. 

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

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

Отсюда я сделал вывод, что прежде чем что-то взять, стоит добавлять задачу по оценке задачи. То есть я не «просто поправлю», а мне нужно немного времени оценить трудозатраты, разобраться в объеме. Это помогло сделать день ещё чуть более предсказуемым.

Третье — это тип задачи. В едином списке смешивались слишком разные задачи, поэтому для своего удобства я разделил его на три части: проектирование сценариев и сборка макетов (то, что нужно делать руками), коммуникация (все созвоны и встречи), а также личные дела (спорт, хобби, дела по дому), ведь система, по мнению автора, применима не только для работы, но и вообще для всего. 

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

Обобщая, я добавил к оригинальному методу такие детали, чтобы адаптировать его к работе в продуктовых командах:

1. Формулировать задачи так, чтобы у каждой был понятный конец: не «поправить макет», а «собрать состояния ошибки для iOS». Крупные задачи закладывать не как «сделать», а как «поработать N часов». Тогда вечером видно, что реально сделано, а не что «начато».

2. Если задача непонятна по объёму, поставить в список дел подготовительную задачу по оценке необходимого времени на неё.

3. Разделять список дел на дизайнерские задачи, задачи по коммуникации и личные дела.

4. Отдельно составлять список задач на неделю, чтобы на его основе наполнять списки дел на день.

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

Итог

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

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

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

Читайте также:

• Календарь всемогущий: (мой) идеальный инструмент планирования

• Калибровка Life Work Balance. Система планирования, которую я развиваю уже 14 лет

• Как мы сделали конструктор эмоций в мире чётких процессов

• Штормить никогда не перестанет: почему реализация концепции спустя несколько лет — это нормально

• Почему вредно сразу начинать рисовать макеты

• Веб-графика, которая вредит: что разработчики делают не так

• Когда CJM нужен через 3 дня (а не месяца)

• Эксперименты на 3,5 квадратах: качнул сетап от «бомж-уровня» до «мини-студии»

• Основы BDUI для продуктовых дизайнеров. Шпаргалка