Также напоминаю вам, что уже завтра в 19:00 состоится совместный эфир с Евгением Жильцовым.

⏩Евгений:

— Head of QA
— в IT больше 12 лет
— руководил командами тестировщиков и разработчиков
— работал в стартапах, госсекторе, аутсорсе и продукте
— уже 9+ лет работает с Agile-подходами

⏩О чём будем говорить:

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

📍 Завтра
⏰ 19:00
📌 Совместно с Евгением

Ссылку отправим перед эфиром.
Ставь напоминание и присоединяйся к нам!❤️

Ставь «❤️», если планируешь присоединиться

Друзья, уже сегодня состоится наш эфир❤️

Про то, о чём редко говорят вслух — почему команды устают, даже когда задач вроде меньше.

Обсудим:

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

Без мотивации и «просто отдохни». Только практика, процессы и реальные кейсы.

📍 Сегодня, 27 января
⏰ 19:00
🎙 Совместно с Евгением

👉Ссылка на эфир: https://my.mts-link.ru/j/154631337/11948730750

Если управляешь проектами или людьми — очень рекомендую подключиться🔥

🎥Запись эфира: энерго- и тайм-менеджмент команд
Как сохранять продуктивность без выгорания

Если у команды постоянно не хватает сил, концентрация падает, а задачи вроде есть, но «не идут», этот эфир стоит посмотреть целиком❤️

Разобрали выгорание не как эмоцию, а как следствие системы работы: входящего потока, планирования и ограничений.

Тайм-коды:

00:00 — начало
00:54 — знакомство с Евгением
02:04 — знакомство с Владимиром
05:22 — о чём эфир и чем он будет полезен?
06:31 — почему команды не успевают и выгорают?

⏩Выгорание

10:00 — старт блока про выгорание
11:13 — что считается выгоранием и как оно проявляется?
14:59 — ранние сигналы, которые чаще всего игнорируют
20:05 — системные причины выгорания
24:43 — материалы

⏩Канбан и защита энергии

25:23 — старт блока про Канбан
26:06 — почему Канбан реально разгружает команду?
29:49 — что такое WIP-лимиты и как они спасают от перегруза?
31:44 — правила качества и входящий поток
38:05 — правило срочности
45:05 — материалы
47:17 — как понять, что входящий поток выжигает команду, даже если WIP не превышен?
50:24 — как работать с поколением Z, если задачи не доводятся до конца?

⏩Scrum и планирование

53:36 — старт блока про Scrum
53:58 — почему планирование = комфорт
55:34 — capacity planning: как планировать по-умному
58:19 — ограничение и защита спринта
01:01:31 — план внедрения нашей «системы против выгорания»
01:04:49 — материалы
01:04:55 — какое оптимальное количество задач на человека, после которого энергия резко падает?
01:07:15 — завершение эфира

📌

Выгорание лечится не отпуском, а

управлением потоком, приоритетами и ограничениями

.

Смотрите запись, сохраняйте тайм-коды и делитесь с теми, кому будет актуальна тема❤️

*Все материалы в комментариях

#интересныематериалы

У каждого ПМа было такое😅

Если ты считаешь, что экономика проекта — это просто, подожди, пока к тебе придут с этой фразой🙂

На этой неделе разберем, почему проекты теряют деньги ещё до первого релиза.

💵Ты ПМ, задачки ставятся, спринты завершаются, но твое руководство то и дело твердит, что получается не самый лучший проект?

💬Ты думаешь: «Что не так?»

А оказывается, что твоему руководству не так важно какой капаситет спринта и скорость выдачи ценности заказчику, зато важно, сколько ты тратишь на проект и какой выхлоп бизнес получит🎯

Большинство ПМов считают, что их работа — ставить задачи, следить за сроками, синкать людей и тушить пожары🔥

И вроде всё ок: спринты закрываются, задачи двигаются, заказчик не кричит. Но потом внезапно:

⭕️бюджет заканчивается раньше срока
⭕️команда работает на износ
⭕️маржа проекта тает
⭕️«добавим ещё пару фич» почему-то превращается в минус по экономике

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

⏩Что вообще такое экономика проекта?

Это не бухгалтерия, не «считать деньги в конце», не финдирский Excel.

Экономика проекта — это понимание:

1️⃣Сколько реально стоит работа команды (в день, в спринт, в месяц)
2️⃣Сколько стоит каждая дополнительная фича
3️⃣Где вы теряете деньги — в переключениях, простоях, переделках
4️⃣Как изменения скоупа влияют на маржу
5️⃣Что происходит с прибылью, когда «всё успели», но работали в режиме аврала

Если ПМ не видит этих взаимосвязей — он управляет движением карточек по доске. Если видит, он управляет бизнес-результатом.

Самая опасная иллюзия:

«Проект в срок — значит всё хорошо».

Проект может быть:
— в срок
— без конфликтов
— с довольным заказчиком

И при этом быть убыточным, потому что:

⭕️команда переработала
⭕️сделали больше, чем оплатили
⭕️добавили фичи без пересмотра бюджета
⭕️недооценили стоимость переключений

И это зона ответственности ПМа.

⏩Почему каждый проджект обязан в этом разбираться?

Потому что именно ПМ:

⭕️принимает задачи в работу
⭕️соглашается на расширение скоупа
⭕️распределяет ресурсы
⭕️планирует загрузку
⭕️принимает решения о приоритетах

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

Если ты хочешь быть ПМом, который влияет на бизнес, а не просто ведёт таски — эта тема для тебя, поехали❤️

#базаPM

🛫Самый дорогой факап ПМа — игнорировать экономику

Экономика — это не про финансы ради финансов, а про управленческие решения📊

Что значит «контролировать экономику проекта»?

Это не сидеть в Excel сутками, это понимать 4 базовые вещи:

1️⃣Где деньги?
— бюджет
— маржинальность
— стоимость часа команды
— фактические трудозатраты

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

2️⃣Где перерасход?
— фичи без пересчёта бюджета
— “давайте быстренько добавим”
— бесплатные доработки
— постоянные переделки

Каждая “маленькая просьба” = минус к марже.

3️⃣ Где риски?
— плавающий скоуп
— нет чётких критериев готовности
— слабый входящий поток
— команда перегружена

Экономика начинает рушиться раньше, чем это видно в цифрах.

4️⃣Где точка принятия решений?
Экономика — это не «посчитать в конце». Это вовремя сказать:

— либо увеличиваем бюджет
— либо двигаем сроки
— либо режем объём

🤯

Самый частый факап:

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

Потому что убыточный “успешный” проект — это просто красиво оформленный минус.

Если тема откликается, ставь «🔥», а если остались какие-то вопросы, пиши в комментариях.

#базаPM

Ребята, хочу сказать спасибо❤️

Нас на курсе уже 270 человек…

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

⏩И то, что вы прошли его и остались здесь — это очень круто.

Спасибо каждому, кто остаётся со мной. Буду дальше дорабатывать формат, исправлять недочёты и усиливать программу❤️

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

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

Если вы уже перешли в мидла или только готовитесь к этому шагу, какие темы для вас были бы действительно важными? Что сейчас сложнее всего? Чего не хватает в открытых материалах?

Напишите в комментариях.
Хочу сделать это не “в теории”, а максимально прикладно под реальные запросы❤️

🤯5 цифр, которые ПМ обязан знать про свой проект

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

Первое — это таски, митинги и дедлайны.
Второе — это деньги, скорость и маржинальность.

Если вы не знаете эти 5 цифр, вы операционный координатор, а не менеджер экономики проекта.

1️⃣Маржа проекта (не бюджет, а прибыль)

- Вы знаете, сколько проект зарабатывает?
- Или просто знаете, что «он в бюджете»?

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

👉Без понимания маржи вы не понимаете, выгоден ли проект вообще.

2️⃣Фактическая загрузка команды

- Сколько часов реально уходит?
- Где люди перегружены?
- Где недогружены?

Перегруз = падение скорости + рост стоимости часа.
Недогруз = сжигание бюджета.

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

3️⃣План/факт по бюджету (в динамике)

- Сколько уже потрачено?
- Какой burn rate?
- Когда наступит точка перерасхода?

👉Большинство проектов умирают не резко. Они тихо утекают по 2–5% каждую неделю.

4️⃣Реальная скорость команды

Если вы не знаете throughput или velocity, вы планируете из ощущения, а ощущение не равно экономика.

👉Каждая ошибка в планировании — это деньги.

5️⃣Стоимость изменения

Сколько стоит:
- срочная задача?
- переключение?
- новая фича в середине спринта?
- переделка из-за плохих требований?

Если вы не можете быстро оценить стоимость изменения, проект начинает «расплываться», а вместе с ним и бюджет.

ПМ — это не про Jira и планы.
ПМ — это человек, который держит под контролем деньги, скорость, стоимость решений

Если вы знаете только дедлайн, вы управляете временем.

Если знаете эти цифры, вы управляете экономикой🎉

#базаPM

💬Сколько стоит одно «срочное» сообщение?

Кажется, что это мелочь: «на минутку», «быстро созвониться», «срочно уточнить».

Но в экономике проекта мелочей не бывает. Разберём на цифрах👇

• Команда: 5 человек
• Средняя внутренняя ставка: 2.000₽/час (очень скромно для IT).

В день прилетает 5 срочных вмешательств:
- внеплановый созвон
- срочная правка
- уточнение требований
- быстрый ресёрч
- «посмотрите, пожалуйста, сейчас»

Каждое переключение — это не 5 минут🫩
Это:
- остановка текущей задачи
- потеря фокуса
- возврат в контекст
- повторное вхождение

Среднее реальное выпадение — 20–30 минут. Возьмем 25 минут.

⚫️5 переключений × 25 минут = 125 мин/день ~ чуть больше 2 часов
⚫️2 часа × 2.000₽ = 4.000₽/день на одного человека.
⚫️4.000₽ × 5 человек = 20.000₽/день.
⚫️20.000₽ × 20 рабочих дней = 400.000₽/месяц.

Почти полмиллиона просто на переключениях…

Фонд оплаты труда — это фиксированные расходы проекта. Вы платите зарплату вне зависимости от того, создаётся ценность или люди ходят по срочным созвонам.

Если 2 часа в день уходят в «срочно», то 25% рабочего времени сгорает в ФОТ. То есть, четверть фонда оплаты труда не создаёт ценности.

Если ФОТ проекта 1.500.000₽ в месяц, то 25% — это 375.000₽, которые просто съедаются хаосом.

И это без учёта:
- удлинения сроков
- снижения скорости
- увеличения цикла задачи
- ошибок из-за спешки
- демотивации
- выгорания

А теперь добавим ещё один момент.

Каждое «срочно» увеличивает cycle time.
—> Чем дольше задача в работе, тем дольше заморожены деньги заказчика
—> Чем дольше цикл, тем ниже оборачиваемость
—> Чем ниже оборачиваемость, тем меньше маржа

То есть, вы теряете деньги дважды:
1. Через прямую оплату времени
2. Через замедление всего проекта

Эти потери не видны в P&L, они размазаны по фонду оплаты труда и не выделены в отчётах, поэтому кажется, что «всё нормально».

Но потом внезапно проект выходит в ноль, маржа меньше, чем планировали, команда устала, сроки поплыли. И никто не понимает почему, потому что

контекст — это тоже ресурс, и он стоит денег

.

⏩Экономика проекта — это не только бюджет и часы, это управление ФОТ и фокусом команды.

Если вы не защищаете контекст, вы теряете деньги каждый день, просто не видите этого.

И вот вопросы, которые стоит себе задать: У вас действительно нет денег в проекте? Или вы просто их сжигаете на «быстро обсудим»?

Пишите в комментариях, что думаете по этому поводу🙂‍↕️

#базаPM

🥲Мой реальный факап в проектной экономике
(не завидую тем, кто тоже допускал эту ошибку)

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

А потом проект вышел почти в ноль🤯

И проблема была не в заказчике и не в команде, а в том, как я считал экономику🙂

Я заложил расчёт по «нормальному» сценарию:
- без переделок
- без затяжных согласований
- без просадки скорости
- без управленческого оверхеда
- без системных переключений

То есть, по модели, где всё идёт так, как запланировано. Но, к сожалению, в жизни всё иначе…

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

Проект формально успешный, а фактически — маржа съедена.

⏩Что я делал дальше:

1️⃣Перестал успокаивать себя фразой «ну в целом нормально»

Я сел и пересчитал реальную экономику: фактические часы, реальную скорость, реальный управленческий оверхед.

2️⃣Вынес это заказчику спокойно и на цифрах

Где расширился объём, где изменились вводные, где появились допработы.

Часть удалось оформить change request, а другую часть — принять как мой управленческий урок.

3️⃣Пересобрал модель расчёта:

- начал закладывать управленческий оверхед
- считать не идеальную скорость, а фактический throughput
- добавлять резерв, исходя из типа проекта
- вести регулярный план/факт по ФОТ и марже
- учитывать влияние переключений и удлинения cycle time

🎯

Главное, что я понял:

экономику нельзя считать один раз в начале.

Если ты не пересматриваешь её регулярно, она «пересчитается» сама и не в твою пользу…

После этого маржа стала не идеальной, но управляемой. И это, честно, сильно спокойнее.

У кого был проект, который «на бумаге красивый», а по факту — почти в ноль?

#жизньвпроектах

🗣️Все говорят, что «управляют рисками»…

Но давайте честно. У большинства риск-менеджмент выглядит так:
- на старте проекта сделали табличку
- записали туда 7–10 очевидных пунктов
- забыли про неё навсегда

А потом:
- «Ну кто ж мог предположить, что сроки поплывут?»
- «Мы не ожидали, что заказчик изменит требования»
- «Никто не думал, что разработчик уйдёт в отпуск внезапно»

⏩Риск — это не документ, это управленческое мышление.

✅Хороший ПМ:
- регулярно пересматривает риски
- оценивает вероятность и влияние
- имеет план реакции
- понимает, где риск уже стал проблемой

❌Плохой ПМ:
- надеется, что все решится само
- тушит пожары

Давайте честно проверим уровень экспертности👇

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