В динамичном мире стартапов управление проектами чаще похоже не на предсказуемую и понятную работу, а на сложную навигацию в неизвестных водах. Немного лучше дела обстоят в командах разработки. Там планирование чуть более прозрачно и предсказуемо, несмотря на постоянно меняющиеся требования. Например, все этапы проекта могут быть расписаны на три месяца вперед с помощью привычного софта для управления проектами, который будет учитывать изменения в графике.
Но как только мы касаемся основателей или руководителей высшего звена, уровень неопределенности резко повышается. Каждый рабочий день этих менеджеров состоит из самых разнообразных и быстро сменяющихся задач, которые нужно балансировать между собой буквально на ходу. Тут и внезапные созвоны, и юридические вопросы, и практическое взаимодействие с командой — все это делает роль этих управленцев совершенно непредсказуемой. Даже не смотря на наличие квартальных целей и ключевых показателей (OKR), реальной проблемой для основателей бизнеса является именно динамическая корректировка планов для решения внезапных и крайне важных задач, которых не существовало еще полчаса назад. И все это надо делать в условиях жестких временных ограничений, потому что сутки не резиновые.
Логичным выводом из всего этого хаоса будет следующее утверждение: у нас есть существенный пробел в инструментах и методологиях управления проектами, ведь существующие инструменты ориентированы на более предсказуемые рабочие процессы и не учитывают саму возможность существования настолько хаотичного графика, как у основателей или топ-менеджеров. У руководителей высшего звена до сих пор не закрыта потребность в системе, которая бы позволяла гибко менять порядок задач, добавлять новые и четко отслеживать этапы их выполнения.
Недавно я стал одним из основателей стартапа, целью которого является разработка продукта в области мониторинга и наблюдаемости (observability) в технологической индустрии, и в очередной раз прочувствовал все вышеописанные проблемы. Сейчас в нашей команде всего два основателя и несколько специалистов, так что моя роль как гендиректора совершенно непредсказуема, а вектор задач меняется чуть ли не ежедневно.
Основное направление моей работы сейчас — определить уровень рыночного спроса на наш будущий продукт. Это включает в себя проведение исследований клиентов, разработку рабочего прототипа (MVP) и принятие итогового решения о масштабировании. Также на меня легла разработка стратегии выхода на рынок, создание и проработка финансовых моделей, формирование маркетингового присутствия и доработка идеи продукта. И на все это у меня есть всего три месяца.
Точечно управлять постоянно меняющимися задачами и при этом достигать более глобальных стратегических целей крайне непросто. Сам для себя я разработал собственный рабочий процесс, который объединяет различные инструменты динамической адаптации планирования и оценки соответствия ежедневных задач нашему квартальному графику.
Такой подход крайне важен для основателя любого стартапа. Если вы не сможете эффективно подстраиваться под меняющиеся требования и задачи, при этом эффективно используя собственное время, проект скорее всего не дойдет до полноценного запуска.
Структурирование собственных задач я начал с того, что разделил их на маленькие (требуют час или менее) и большие (требуют до 20 рабочих часов). Мелкие задачи включали в себя подачу заявок на кредиты AWS, настройку Google Analytics, составление клиентских брифов. Крупные — создание маркетинговых материалов и исследование продукта. В целом на управление этим проектом я выделял четыре часа в день.
Основная сложность заключалась в том, чтобы найти инструмент для визуального представления и динамического пересчета сроков по мере корректировки задач. После довольно долгих поисков я интегрировал Trello с Google Calendar, чтобы закрыть эти потребности.
Давайте взглянем на мое сегодняшнее расписание.
Кликабельно
На скриншоте выше показана моя текущая повседневная доска Trello, которая использует стандартные списки для управления проектами:
Backlog: для задач, которые я не могу сделать прямо сейчас или которые надо выполнить позже.
Blockers: для задач, которые завязаны на других членов команды и к которым я не могу приступить до того, как они выполнят свою часть.
To-Do: для задач, выполнение которых возможно и которые запланированы.
Done: для задач, которые были успешно выполнены.
Notes: для хранения полезных ссылок и прочей информации.
А теперь поближе рассмотрим мой лист To-Do, в котором можно заметить тот самый важный элемент, о котором я говорил ранее. Каждый таск содержит пользовательское поле с предполагаемым временем в часах, которое мне придется потратить на его выполнение. Так как список задач у меня довольно обширный, то для эффективного управления я рассчитываю время, которое мне придется потратить на каждую из них. При расчете я учитываю, что максимум в день я могу потратить только четыре часа. Кроме того, расписание корректируется с учетом праздников, отпусков, других нерабочих дней и ситуаций для того, чтобы сроки выполнения каждой задачи были максимально приближены к реальности.
В своем календаре я провожу таймблокинг, который отражает очередность задач. Это необходимо, так как каждый рабочий день непредсказуем. При этом при составлении расписания в календаре я не просто забиваю все свое время с 9 до 18, как это обычно происходит в подобных инструментах, но вношу и такие вещи, как работа по дому, оставляю запас для внезапных созвонов или других личных дел.
Каждый день я отдельно выделяю около четырех часов специально для задач стартапа, четко отмечая их в календаре. Такой подход помогает мне получить вместо идеального и стройного расписания — реалистичное. Ведь давайте будем честны, никто не работает полный рабочий день, особенно на удаленке. Идеальный офисный график остался в далеком прошлом, так что я включаю в свое расписание и личные задачи. Так же замечу, что блоки с зарезервированным временем под нужды стартапа очень важны для того, чтобы я гарантированно выделял достаточно времени на этот проект вне зависимости от того, что со мной происходит в этот день, и какие задачи я решаю на своем основном месте работы.
Стоит сказать еще немного о связке Trello и Google Calendar. Для того, чтобы подружить их друг с другом, я написал скрипт, который по порядку сверху вниз извлекает все карточки тасков из To-Do листа. После этого скрипт извлекает все события стартапа из календаря и распределяет задачи по одной, делая оценку времени на каждое событие. Если задача занимает больше времени, чем выделено в этот день на работу, то она разбивается на несколько связных тасков поменьше, каждый не длиннее четырех часов. После выполнения скрипта все мои задачи добавляются в отдельный календарь. Для того чтобы избежать дублирования, я очищаю список задач каждый раз после отработки скрипта.
Если у вас есть опыт работы с Python и вы знаете, как создавать API-ключи, то можете забрать скрипт здесь.
Сейчас он предназначен только для моего личного пользования, запускается из терминала и имеет некоторые проблемы. Чтобы заставить его работать, нужно вручную скопировать и вставить код подтверждения календаря. Еще там есть пара ошибок, и если у вас есть идеи, как сделать этот код лучше — пишите в ЛС, комментариях или на GitHub в Issues.
Итак, вернемся к тайм-менеджменту. После выполнения, скрипт обновляет даты в Trello и вставляет события в календарь. Как можно увидеть, текущий предполагаемый срок завершения всех задач — 4 июня.
После выполнения скрипт обновляет даты в списке trello и вставляет события в календарь в отведенные места. Как вы можете видеть, текущее предполагаемое завершение списка дел произойдет 4 июня.
Теперь давайте представим, что:
Сначала мне нужно сделать таск «Set Up OpenTelemetry».
У меня есть несколько других задач, которые займут 5 часов.
У меня есть внезапные звонки 15 и 16 числа.
После корректировки задач на дашборде я перезапускаю скрипт и получаю следующее:
Теперь предполагаемый срок завершения всех задач уехал с 4 на 6 июня. Чтобы вернуться к старому графику мне нужно будет скорректировать свои планы — уменьшить объем задач, сократить время выполнения и т.д. Но самое главное, я вижу наглядно, какой сдвиг создает пара звонков и одна большая задача, которую приходится дробить на несколько тасков.
Все описанное — буквально моя ежедневная рутина. Как только в моем расписании происходят изменения, я пересчитываю его, а затем сверяюсь с календарем, чтобы убедиться в том, что ранее поставленные задачи будут выполнены в необходимые мне сроки. Изначально, как и любому разработчику, мне очень хотелось найти готовое решение, но я его, к сожалению, не обнаружил. На мой взгляд, для основателя нового проекта самую большую опасность представляет как раз список из множества задач без четкого понимания, когда это все на самом деле будет сделано. Менеджерскую работу надо рассматривать точно так же, как и процесс разработки программного обеспечения. Нужно всегда понимать, когда будет сделана задача, чтобы банально иметь возможность скорректировать свои планы и просто знать о том, что планы нуждаются в корректировке. Мой пример выше, где всего два созвона и одна крупная задача сдвинули расписание сразу на два дня — крайне показателен.
Я надеюсь, что мое видение этой проблемы поможет другим людям, даже если они не будут пользоваться скриптом и начнут заполнять календарь вручную. Если же у вас есть идеи о том, как улучшить мой скрипт или вовсе идея нового продукта, особенно если у вас есть опыт в роли Product Manager — напишите мне. Буду рад пообщаться.
Про управление проектами и многое другое я пишу в своем телеграм-канале — буду рад если присоединитесь.