Проектный метод планирования для предпринимателей и «свободных художников»
Классические списки дел на день — худший способ планирования, который можно себе представить в условиях высокой занятости.
Почему проектный метод, а не списки дел на день
Предприниматели, фрилансеры и вообще «свободные художники», которые приходят к пониманию необходимости заниматься планированием, обычно сталкиваются с такими проблемами:
- У них много задач
- Сложность этих задач варьируется от простых и быстрых до сложных и долгих
- Задачи, зачастую, относятся к разным сферам деятельности и требуют переключения с одной категории дел на другую
Примеры:
- Основатель стартапа, которому необходимо заниматься вопросами, связанными с разработкой, привлечением клиентов и организацией работы команды
- Дизайнер-фрилансер, который работает над заказами, параллельно развивает свой личный бренд, занимаясь написанием статей и обзоров, а еще параллельно учится (хотя, скорее, преподает) в Британке
- Блоггер, которому нужно ежедневно работать над контентом, развивать свою тематическую экспертизу (развлекательную или прикладную) и заниматься продвижением
В таких условиях попытки организовать дела с помощью составления списка задач на день не работают, потому что обычно ведут к следующей последовательности событий:
- Составляется список дел на день (скажем, на завтра)
- На следующий день список открывается и тут же демотивирует тем, что в нём много задач
- Вдобавок к прокрастинации, вызванной муками выбора из длинного списка, добавляется естественная суета и текучка рабочего дня
- В результате, к концу дня список дел выполняется не полностью, часть дел переносится на завтра
- На следующий день история повторяется, список дел приобретает огромные размеры и демотивирует еще больше
В итоге получается, что список дел не помогает, а мешает. Даже если много работать, осознание, что в конце дня выполнено не всё, демотивирует и снижает эффективность.
Все из-за того, что мы крайне плохо оцениваем свои ресурсы, сложность решаемых задач и энергозатратность переключения между ними. Поэтому легко понадеяться на себя завтрашнего и заполнить список дел под завязку. А на следующий день сдуться под тяжестью реальности.
В условиях высокой загрузки лучше вообще не заниматься планированием, чем использовать списки дел на день. Они подходят только для малой нагрузки и механических, а не интеллектуальных задач.
Проектный метод, в свою очередь, направлен на создание ощущения постоянного прогресса и спокойствия, вызванного структуризацией активностей.
Суть проектного метода
Проект — это когда сложная составная задача разбивается на простые шаги таким образом, чтобы было понятно что делать в первую очередь, а не ломать голову с чего начать, глядя на задачу в списке дел.
Примеры проектов
Проект № 1:
Написать и опубликовать пост о сетевом эффекте как основном инструменте дистрибуции для утилитарных сервисов и приложений
Задачи:
- Определиться с основной площадкой размещения поста (VC, Хабр, Medium, социальные сети)
- Сформулировать основную мысль статьи в одном предложении
- Определиться с CTA в конце поста (куда вести аудиторию после прочтения — в телегу или на курс?)
- Подготовить план поста
- Описать сценарий развития типичного проекта на примере заметочного сервиса
- Сформулировать адаптированный сценарий развития сервиса с добавлением функций коллабораций
- Сформулировать основные выводы статьи, развивая основную мысль
- Подготовить первый черновик полного текста
- Скорректировать и отредактировать текст
- Опубликовать статью на основной площадке
- Сделать репосты статьи во вспомогательных каналах
Проект № 2:
Запустить предзаказ курса «Принципы самоорганизации и планирования»
Задачи:
- Составить список тем для курса
- Подготовить план курса, добавив описания к темам
- Написать текст для секции «Как устроен курс» лендинга
- Адаптировать план курса для секций «Программа курса» и «Главные темы» лендинга
- Описать тарифы и определиться с их стоимостью
- Написать первую итерацию текста для секции «Частые вопросы»
- Передать тексты для лендинга дизайнеру
- Настроить оплату курса на стороне Tilda
- Поменять домен сайта с курсами на стороне эквайринга
- Адаптировать обработку приема платежей на нашем бэкенде для нового курса
- Финально вычитать все тексты на лендинге и опубликовать его
- Опубликовать анонсы нового курса в личных социальных сетях
- Опубликовать анонсы нового курса в социальных сетях Хаос-контроля
- Добавить ссылку на курс в Welcome-email’ы для новых пользователей Хаос-контроля
- Опубликовать новые сборки Хаос-контроля со ссылкой на курс в App Store и Google Play
В органайзере эти проекты будут выглядеть так:
Как видите, проекты, представляя собой простейшие списки задач, имеют важные свойства:
- Формулировка самого проекта — обозначение конкретного желаемого результата (цели)
- Каждая задача — простое прямолинейное действие, которое можно просто взять и выполнить, не мучаясь вопросами как к нему подступиться
- Выполнение проекта представляет собой последовательное продвижение вперед по задачам. В каждый момент времени понятно, что делать дальше, чтобы проект двигался дальше
Основной плюс проектов в том, что такой простой подход организации задач хорошо подходит для людей с предпринимательским складом ума, привыкшим мыслить категориями целей. Когда каждая задача, которую ты выполняешь, привязана к какой-то конкретной цели, это создает ощущение прогресса и мотивирует двигаться вперед. Сравните это с демотивацией от списков дел на день.
Декомпозиция сложной задачи в проект
Теперь давайте посмотрим как трансформировать комплексную задачу в проект.
Допустим, я работаю продакт-менеджером в стартапе, и мне нужно подготовить прототип мобильного приложения. У меня есть ресурс из дизайнеров, которые будут отрисовывать прототип, а мне нужно предоставить им необходимые для отрисовки материалы в виде документации, блок-схем и комментариев. С чего начинать — непонятно, что должно быть в проекте — тоже.
Приступим. Наша задача заключается в подготовке прототипа первой версии приложения. Зафиксируем название проекта:
Очевидно, первым делом нужно определиться с целями создания прототипа, потому что они окажут влияние на закладываемую в прототип функциональность, на его облик и то, как будет организована работа. Это наша первая задача в проекте:
В данном случае, логичнее сперва решить эту задачу, а потом уже далее заполнять проект. Итак, прототип нужен, чтобы:
- вся команда проекта одинаково понимала как выглядит и работает продукт
- показывать его раннему сообществу пользователей и собирать их обратную связь
- показывать его инвесторам и партнёрам, чтобы учитывать их комментарии
- нарезать из него скриншоты, гифки и видео, которые можно будет использовать на сайте, в социальных сетях и, тем самым, демонстрировать прогресс проекта
- ускорить процесс разработки реального приложения и, тем самым, сэкономить на нём
Как видите, суть прототипа состоит в том, чтобы привести видение всех участников команды проекта к единому знаменателю и чтобы «светить лицом» проекта во вне, создавая ажиотаж и видимость прогресса. Исходя из этого, понятно, что:
- прототип должен обладать более-менее приличным дизайном, поскольку показывать людям скупые серые макеты — это не очень
- дизайн прототипа стоит проработать сразу, потому что начать показывать экраны инвесторам и партнерам лучше как можно раньше
Получается, что нужно в короткие сроки нарисовать какие-то приличные экраны с претензией на дизайн.
Наиболее простой способ это сделать — использовать тёмное оформление с яркими элементами UI. Это требует минимум усилий на стороне дизайнеров, не сильно отвлекает от проектирования логики, а на выходе быстро получаются вполне приятные экраны приложения. А чтобы начать показывать прототип как можно быстрее, в первой версии реализуем один, ключевой, пользовательский сценарий.
Поэтому выполняем первую и единственную задачу в проекте и дополняем его двумя новыми:
Помимо документа с описанием сценария, дизайнерам понадобится блок-схема переходов между экранами, которые задействованы в этом пользовательском сценарии. Плюс каждый из этих экранов нужно описать в контексте того, что на нем расположено и как он себя ведет. Поэтому добавляем еще две задачи:
Как видите, мы довольно быстро пришли от состояния «как подступиться к этому проекту?» к ясному пониманию первых шагов. В данный момент мы не особенно представляем себе что будет происходить в рамках этого проекта после завтрашнего дня, но это не страшно. Главное, что зафиксирована цель, понятен ориентир и спланированы следующие шаги в его сторону.
Подготовив материалы для завтрашнего созвона с дизайнерами и объяснив им, что мы отрисовываем вот этот конкретный сценарий, а также делаем это в темной теме оформления, мы естественным путем приходим к такому содержанию проекта:
Кажется, мы тут уже нашли свой процесс работы над проектом: описываем очередной сценарий, отдаем его на отрисовку дизайнерам. И так со всеми сценариями прототипа, пока они не закончатся.
Предположим, что в какой-то момент дизайнеры возвращаются с отрисованным первым сценарием. Глядя на первый драфт прототипа, мы видим, что нужно внести правки в макеты, а в самом сценарии нарисовалась проблема — он какой-то сложный. Нужно обсудить с командой изменения в архитектуре авторизации, чтобы упростить его. Плюс оказалось, что не хватает иконки, которую никто не нарисовал. Поэтому проект дополняется такими задачами:
Обратите внимание, что мы постепенно продвигаемся вперед — появляются первые драфты прототипа, возникают и решаются проблемы, происходят обсуждения. И все это время мы находимся в рамках проекта-контейнера, который объединяет все эти активности вокруг четкой цели.
Такая организация задач в привязке к желаемому результату создает ощущение фокуса, прогресса и ясности дальнейших действий.
Организация проектов по категориям
Теперь представьте себе, что для любой комплексной задачи вы создаете проекты и работаете с ними как в примере выше. Очевидно, что у занятых людей таких проектов будет много, поэтому нужно как-то их организовывать.
Для этого есть смысл объединять проекты по категориям. В Хаос-контроле это делается с помощью папок:
При организации проектов по категориям стоит следовать следующим рекомендациям:
- Ваша основная задача при использовании проектного метода — создание простой и интуитивно понятной структуры ваших проектов. Такой, чтобы вы знали где что искать и не тратили много времени в поисках нужного проекта где-то в дебрях навигации по папкам
- Старайтесь не создавать огромное количество вложенностей в папках и не плодить категории. Регулярно пересматривайте структуру своих папок. Если видите, что какая-то категория покрылась пылью, и в ней лежит богом забытый проект, значит стоит удалить эту категорию вместе с ее содержимым
- Каждая категория, которую вы заводите в органайзер, должна активно использоваться. Проекты в ней должны создаваться и выполняться, а не лежать нетронутыми. В органайзере стоит хранить только актуальные проекты в работе, а не задачи и цели из серии «когда-нибудь потом» и «хорошо быть сделать». Неактивные категории, проекты и задачи только замусоривают органайзер и ухудшают его эргономику
Последний совет может показаться несколько контр-интуитивным на фоне классических тайм-менеджерских рекомендаций «хранить все в одном месте — и задачи на сегодня, и мечты о будущем». Это один из самых вредных советов в контексте планирования, потому что тогда органайзер становится свалкой несбывшихся надежд, а не стабильно работающим инструментом.
В идеале вы должны стремиться к тому, чтобы ваш органайзер бы пустым, потому что вы в нем все выполнили, а не заполненным под завязку, потому что вы туда записываете то, что не собираетесь делать.
В любом случае, использование папок сильно упрощает жизнь в случае большого количества проектов. Но много проектов = много задач, а это вызывает очевидный вопрос как в течение рабочего дня работать над задачами из разных проектов. Но это тема для отдельной статьи.
Эта статья — адаптированная версия первого письма из email-курса «Принципы самоорганизации и планирования».
P. S. Я завел Telegram-канал, в котором пишу про различные аспекты создания ИТ-продуктов (да и любых продуктов, в общем-то) и как организовывать созидательный процесс. Присоединяйтесь.
Круто написано! 🔥