Рутина проджекта без страданий: как каждый день приближаться к цели (и не выгорать)

Проблема в том, что именно рутина — ежедневные и еженедельные повторяющиеся действия — в итоге определяет, будет проект управляемым или превратится в хаос «как-то сам собой».

В этой статье разберём:

• что такое эффективность без менеджерского булшита,
• почему цель важнее «правильных практик»,
• какие регулярные действия реально делают проджекты,
• как упростить рутину c помощью методологии P3.express и сделать так, чтобы её выполнение стало почти неизбежным.

Эффективность без магии: приближаться к цели

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

Эффективность — это приближаться к цели.

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

Ни одно из решений не является «плохим» или «хорошим» само по себе — оно либо приближает вас к цели, либо нет.

Как только мы приняли, что эффективность — это приближаться к цели, нам необходимо определяться с целью.

Любая коммерческая организация ставит перед собой одну цель (и она даже прописана в уставе организации. Но кто ж эти уставы читает, да?) — это зарабатывать деньги. Да не просто зарабатывать здесь и сейчас, а еще и в долгосрочной перспективе.

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

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

Может ли цель проекта быть другой? Конечно. Например «сделать команду довольной» или  «освоить бюджет». Важно не то, какая формулировка «правильнее», а то, что цель честно проговорена, связана с целями организации, и зафиксирована на старте (например, в Резюме проекта). А еще важно понимать, как вы будете измерять свое приближение к цели (как сделать команду довольной — вопрос открытый, но в некоторых проектах — почему бы и нет).

Почему именно рутина решает судьбу проекта

Если вы хотите приближаться к цели не рывками, а стабильно, одной осведомлённости о цели мало. Нужна рутина — набор повторяемых действий, которые:

• регулярно показывают, где вы находитесь,
• побуждают реагировать на отклонения,
• удерживают команду в едином информационном поле,
• не дают результатам «повисать в воздухе».

Ниже — практичная версия рутины по методологии P3.express: еженедельные и ежедневные шаги, которые на деле и составляют большую часть работы менеджера.

Еженедельная рутина: понять, где мы, и договориться со всеми

С01 — Оценить и зафиксировать прогресс

В начале недели важно ответить на вопрос: где мы сейчас относительно обязательств?
Это поможет увидеть отклонения, новые требования, задержки, риски.

Частая ошибка — пытаться измерять прогресс идеально: формулы, веса, проценты, «учесть всё». В итоге вы либо выгораете при попытке свести эти показатели, либо начинаете подменять реальность фантазиями, чтобы метрика выглядела прилично.

Чтобы не попасть в эту «ловушку точности», придерживайтесь простого правила: метрика должна помогать приближаться к цели. Если вам помогает «освоенный объём» — отлично, а если достаточно простого «светофора» — просто замечательно.

Пример практичной метрики: считать прогресс через поставку результатов, например
выполненные дочерние задачи / общее количество дочерних задач.

И да: люди подстраивают поведение под метрики. Если ваш способ работы с метриками провоцирует «рисовать статус» — вы это и получите. 

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

Подготовить отчёт

Хороший еженедельный отчёт нужен не для микроменеджмента. Он нужен, чтобы:

• сообщить статус и задать ритм,
• сделать проблему видимой (если она есть, конечно),
• подготовить почву для просьбы о помощи.

Содержание отчёта:

• что поставили за период,
• какие проблемы появились,
• прогресс по календарному плану,
• какие документы сделали/согласовали (чтобы их можно было быстро найти и сослаться).

С02 — Реагировать на отклонения

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

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

Что надо реально сделать:

• понять причины возникновения отклонений,
• поискать повторяющиеся паттерны,
• то, что мы видим — это как правило симптомы проблемы, поэтому надо поискать корневые причины возникновения проблем,
• составить план, как мы справляемся с отклонением, ну и
• привлекать спонсора и стейкхолдеров.

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

Если реакция меняет планы или обязательства — изменения должны попасть в проектные документы.

С03 — Провести еженедельную встречу

Да, без регулярных встречи мы не обходимся. 

Однако, мы проводим регулярную встречу не для сбора статуса (он уже собран на шаге С01), а для укрепления команды. С точки зрения P3.express именно это — главная цель шага С03.

Задачи встречи:

• синхронизировать команду,
• убедиться, что все одинаково понимают ситуацию,
• укрепить совместное движение к цели.

Идеально вообще проводить одну встречу с заказчиком и командой одновременно. 

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

С04 — Направить фокусированную коммуникацию

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

Руководителю проекта важно публично признавать результаты: это поддерживает боевой дух и показывает, что проект живой.

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

Формат не принципиален — канал в Telegram, письмо по команде, короткий дайджест. Важно, чтобы коммуникация была регулярной и связанной с реальными результатами.

Здесь вам может помочь ИИ — сформировать первый черновик сообщения, например. Помните, что вас будут читать люди, поэтому обязательно отредактируйте то, что написал ИИ.

Ежедневная рутина: как жить в мире неопределённости

Ежедневная работа проджекта — это неопределённость. Она не сверяется с планом. Незапланированная хрень случится обязательно — вопрос только когда и в какой форме.

И ключевой навык — не угадывать всё наперёд, а управлять своей реакцией.

D01 — Управлять рисками, проблемами и запросами на изменения

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

Ну или делаем вид, что ничего не происходит и угроза нас не коснется.

Ну или пытаемся от нее уклониться. Это все проявления инстинктивных импровизационных реакций — бить, бежать или притвориться мертвым.

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

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

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

• Реакция должна обеспечивать безопасность для организации (читаем — соответствовать стандартам)
• Реакция должна быть адаптирована к конкретно этой угрозе (то есть — импровизационной)

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

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

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

Решение, которое удовлетворит оба этих необходимых условия: задать рамки (форму) и внутри них импровизировать сколько угодно.

Рабочий инструмент — простой реестр последующих действий (так мы будем называть сущность, к которой обычно относятся как к реестру рисков), где вы фиксируете:

• событие,
• причины,
• меры реагирования.

Почему реестр рисков часто не работает

Потому что включается прокрастинация. Не «потому что вы ленивые», а потому что вокруг миллион отвлечений.

Два практичных способа победить это:

1) Снизить порог входа
Не ставить задачу «работать с рисками», а ставить задачу, которую можно начать без дополнительной задачи для мозга «подумай, как ты это будешь делать»:

«Открыть реестр и журнал проекта»

Если к задаче приложена кликабельная ссылка — это вообще чит-код: «нажал — открыл».

2) Держать инструменты рядом
Если документ далеко (надо искать, вспоминать, где лежит) — шанс сделать шаг резко падает.

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

Вот так выглядит реестр:

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

Это очень простая форма — датированный ежедневник, куда я в свободной форме записываю то, что относится к тому или иному шагу проекта (и не только!). Кроме того, этот журнал доступен всем в команде — они могут в него посмотреть и понять, что происходит на проекте, внести свои заметки и даже пофлудить в комментариях.

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

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

В этом смысле журнал является хорошим способом отфильтровать реальные риски/проблемы, на которые мы можем повлиять от просто иррациональных страхов. реальные проблемы должны будут поехать в реестр, а страхи — пусть остаются в журнале. Ретроспективно вы сможете поразбираться, почему такой страх возникает, и найти реальную проблему.

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

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

D02 — Принять результаты работ

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

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

На этом шаге нас тоже поджидают опасности прокрастинации, про которые мы много говорили на шаге D01. И снова способ справиться — снижение порога входа и упрощение формулировок и доступа к инструменту.

Вместо «принять результаты работ» — конкретно: «Проверить готовые результаты на досках»

Дальше всё просто:

• открыть трекер,
• посмотреть колонку «готово»,
• привлечь эксперта/тимлида, если нужно,
• зафиксировать принятие/проверку в задаче или чате,
• поблагодарить за поставку (даже если дальше будут правки).

Выводы

1. Эффективность — это приближаться к цели.
2. Чтобы приближаться к цели стабильно, нужна рутина.
3. Прокрастинация будет всегда — поэтому вместо самобичевания нужно упрощать вход:
   • формулировать задачи так, чтобы их можно было начать без размышлений,
   • держать инструменты рядом,
   • начинать с простого первого действия.
4. Конфликта «система vs импровизация» нет. Нужны рамки, которые задают форму, а внутри них — адаптация к реальности.

Подчиняйте свою рутину цели и упрощайте её до тех пор, пока выполнение не станет неизбежным.