Эксперимент: личный тайм-менеджмент для Agile-гиков (часть 1)

Последние несколько лет я активно применяю философию Agile в профессиональной деятельности — управлении проектами. В этом году я решила провести эксперимент: приложить принципы Scrum к личному планированию и тайм-менеджменту. Думаю, мой опыт может показаться любопытным всем, кому интересны гибкие методологии разработки и управления, прежде всего, коллегам из IT-индустрии.

Что такое Agile? Вдруг кто еще не знает

Если вы работаете в IT-сфере, с Agile-методологией наверняка знакомы не понаслышке.

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

В широком смысле Agile-подходы к управлению объединяет ряд основных принципов:

• Итеративность, т. е. работа в циклах, особенно важная при создании сложных продуктов;
• Гибкость команды, готовность к изменениям, активное использование обратной связи;
• Фокус на ценности продукта;
• Развитие уровней ответственности команды;
• Прозрачность работы как для владельцев и спонсоров проекта, так и для членов команды;
• Гуманистический подход.

Agile позиционируется как подход, балансирующий между хаосом и бюрократией

Agile проповедует самоорганизацию команд и призывает к отказу от «надзирателя» в виде назначенного менеджера. Иногда можно услышать фразу: «У нас полный Agile» в значении абсолютного хаоса в проекте, прикрытого соответствующей терминологией. Однако это касается исключительно неудачных кейсов применения методологии, ее неверной трактовки, и в отношении Agile в целом, конечно, несправедливо.

Методология давно вышла за пределы индустрии разработки и используются в других сферах, например, транспорте, медиа, бизнесе, финансах. И это неудивительно: Agile — это философия управления, независимая от области применения.

Работая с Agile-проектами как проджект-менеджер, я заинтересовалась: а что если попробовать применить один из фреймворков — Scrum — к личному планированию и тайм-менеджменту? Вдохновленная философией Scrum и Agile, вооружившись методикой Стивена Кови и EOS, я решила провести самостоятельный эксперимент.

Зачем и кому это нужно?

Кому эта затея может подойти? Я думаю, в первую очередь, она может найти отклик у моих коллег: проджект и продакт-менеджеров. Но и других IT-специалистов этот подход тоже может заинтересовать. Вместе с тем не думаю, что сфера профессионального знания должна служить здесь ограничителем. Это скорее эксперимент, чем руководство к действию. Давайте просто посмотрим, «что будет, если…».

Что может дать Agile компании и проекту? В Agile-гайдлайнах приводятся следующие постулаты:

• Гибкость и готовность команды к смене приоритетов, как следствие — более успешная реализация проекта в меняющихся условиях;
• Как правило, более счастливые и мотивированные команды;
• Большая удовлетворенность спонсоров проекта и более высокое качество продукта;
• Лучшая предсказуемость результата и раннее выявление проблем.

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

Баланс без перегибов — вот что я искала в личном тайм-менеджменте

При применении принципов Agile в личном тайм-менеджменте важными для меня стали следующие моменты:

• Темп. Работа в спринтах всегда задает его. Итерации с планированием и оценкой результатов на выходе позволяют достаточно точно определить собственную эффективность на каждом этапе. Нельзя достичь значительных результатов, например в спорте, без регулярных тренировок. Интенсивные нагрузки с интервалом в пару недель — наверное, лучше чем ничего, но их недостаточно для заметных изменений.
• Роадмап или по-русски — календарный график работ. Правда, это понятие не совсем из области Agile, скорее — из product development. Я обозначила для себя вехи на ближайших год и разметила чекпоинты — в какой точке я хочу оказаться на том или ином направлении через определенный отрезок времени. Это позволило мне более внимательно следить за балансом сфер моей жизни и расставлять приоритеты более взвешенно.
• Фокус. Поставленная цель спринта позволяет не распыляться и концентрировать внимание на главном. Я использовала роадмап как стратегический план и декомпозировала его на мелкие задачи для отдельных спринтов. Это служило напоминанием, что сейчас особенно важно, и позволяло не сворачивать с пути.
• Прозрачность и подотчетность. Agile тренирует accountability — подотчетность. Сколько из запланированного я успела сделать? Что осталось? Что пришлось выкинуть или заменить и почему? Очевидно, что эффективность подразумевает отслеживание прогресса.
• Всесторонность. Каждый спринт я старалась стабилизировать за счет наличия задач и фокуса на второстепенных для этого периода эпиках (об этом ниже).

Фреймворк

Что я взяла за основу своего подхода?

• Scrum — один из популярных фреймворков для внедрения Agile. Библия по вопросу — книга Джеффа Сазерленда и Кена Шваббера, краткое руководство доступно по ссылке.
• EOS — система подходов к управлению бизнесом, вот ее официальный сайт.
• Книга Стивена Кови “First things first” («Главное внимание главным вещам»).

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

В своем эксперименте я использовала следующие элементы:

1. Sprint (Спринт) — горизонт планирования. Для меня удобно было работать в недельном спринте, это коррелировало с моим обычным тайм-менеджментом. Думаю, для кого-то подойдут и отрезки в две недели. Важно определить длительность спринта такой, чтобы она, с одной стороны, была комфортной, с другой — позволяла решить поставленные задачи. Напомню, что в процессе она уже не меняется. Я начинала и заканчивала спринты по воскресеньям.
2. Epic (эпик) — под эпиками я выделяла направления своей жизни, например: карьера, спорт, занятия музыкой, семья, здоровье и прочее.
3. Task (Задача) — это кирпичик, достаточно емкая, но сравнительно небольшая единица. К примеру, цель — улучшить английский язык и сдать IELTS на определенный балл звучит скорее как эпик, который можно разделить на более мелкие части. Путь к заветной отметке в сертификате разбиваем на шаги, например:

• Подбор курса.
• Покупка учбеника.
• Еженедельные занятия самостоятельно (повторяющаяся задача).
• Еженедельные занятия с учителем (повторяющаяся задача).
• Прохождение онлайн-курса.
• Сдача тестового задания с целевой отметкой в N баллов.

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

Я использовала SMART-постановку задач, для некоторых ставила четкий срок исполнения.

4. Retrospectives (ретроспективы) — анализ результатов и поиск возможностей улучшения. Я объединяла ретроспективы со спринт-планингом.

5. 90 days world — концепция, взятая из EOS-фреймворка. Суть ее в том, что на 90 дней определяется одна большая цель — ее называют скалой. Скала всегда одна, максимум две. Это позволяет ограничить порывы объять необъятное. Я выбирала эпик на 90 дней, что значило: наибольшего улучшения за это время я планирую достичь в этой сфере. Так, к примеру, эпик «карьера» может стать ключевым, когда поставлена цель получить повышение до определенной позиции в первом квартале. При этом эпики, которые на это время становятся второстепенными — например, здоровье, отношение с семьей, занятие музыкой — не будут иметь крупных и амбициозных целей. Тем не менее, задачи по ним будут входить в спринты для поддержания баланса.

6. Backlog (беклог) — в разработке под беклогом понимают пул задач, из которых впоследствии планируются спринты. Я смотрела на него так же: любые инсайты, новые идеи, to-do задачи я помещала в беклог и возвращалась к ним при планировании спринта. Беклог тоже можно структурировать — о том, как я веду личную доску развития и беклог в Miro, я напишу в следующих постах.

7. Velocity (скорость) — это скорость работы команды, условно, количество задач, которое команда может покрыть. У меня спринты были небольшими, они могли содержать не более 5–10 задач.

О том, что из этого всего вышло я расскажу в следующем посте.