🤯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 очевидных пунктов
- забыли про неё навсегда

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

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

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

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

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

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

🤨Ты не видишь риск, пока он не стал проблемой…

Есть риски, которые ПМ видит.
А есть риски, о которых он узнаёт слишком поздно. И проблема в том, что вторые — самые дорогие…

Не потому что они сложные, а потому что они тихие.

➡️Разработчик перегружен, но молчит
➡️Требования «пока сырые», но уже начали делать
➡️Заказчик стал дольше отвечать
➡️Скорость команды плавно падает
➡️Всё вроде ок… но ощущение, что что-то не так
Это и есть риски, которые пропускают.

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

Но риск почти никогда не приходит с формулировкой:
«Здравствуйте, я риск».

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

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

🤯Топ-3 самых опасных «тихих» рисков в проекте

1️⃣Сырые требования, по которым уже начали работу — самый дорогой риск.

Последствие: скрытый перерасход, удлинение цикла, потеря маржи.

Факт: большинство переделок — это не ошибки разработки, а старт без готовности.

2️⃣Перегруз ключевых людей (который никто не признаёт) выглядит как «норм, справляемся».

Последствие: внезапные задержки, деградация скорости, точка отказа проекта.

Факт: перегруз почти всегда становится риском сроков раньше, чем это видно в отчётах.

3️⃣Медленное ухудшение скорости команды — самый недооценённый риск.

Последствие: проект «вдруг» перестаёт успевать, экономика начинает плыть.

Факт: скорость почти никогда не падает резко — она ухудшается постепенно.

⏩

Главная мысль:

Самые дорогие риски — не форс-мажоры. Самые дорогие — те, которые выглядят как обычная работа.

Ставьте «🔥», если тема интересна

#базаPM

🤯Риск, который ПМ создаёт себе сам

Самый дорогой риск в проекте — не внешний. Его создаёт сам ПМ, когда слишком долго живёт в неопределённости.

⏩Это не выглядит как ошибка, это выглядит как нормальная работа:

⭕️начали без финальных требований
⭕️«срочно» пропустили вне процесса
⭕️договорённость не зафиксировали
⭕️странную динамику заметили, но не проверили
⭕️эскалацию отложили «до подтверждения»

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

🚨

Почему это

опасно

:
самосозданные риски тихие. Они не падают как инцидент — они накапливаются.

Сначала появляется:

неясность → лишние вопросы → переключения → переделки → рост сроков → давление → потеря маржи.

И в какой-то момент кажется, что «проект внезапно поехал», хотя это совсем не внезапно.

⏩Есть три типовых риска, которые ПМ создаёт сам:

1. Запуск работы без готовности (Definition of Ready игнорируется)
Когда начинаем «чтобы не тормозить», почти гарантированы переделки. Цена — повторная оплата того же времени + рост cycle time.

2. Неконтролируемая срочность
Каждое внеплановое вмешательство ломает план, увеличивает WIP и создаёт скрытые потери ФОТ. Это прямой экономический риск, а не просто процессный.

3. Поздняя эскалация
Самый дорогой риск. Пока ПМ «разбирается сам», окно дешёвого решения закрывается. Чем позже поднимается проблема, тем дороже её стоимость.

⏩

Практический маркер:

Если мысль «надо бы зафиксировать» появилась —

уже риск.

Если мысль «пока рано эскалировать» появилась —

риск растёт.

Если мысль «потом оформлю» появилась —

риск уже создан.

Сильный ПМ не ждёт, пока риск станет проблемой, а уменьшает пространство неопределённости.

Пишите в комментариях, с какими из рисков вы уже успели столкнуться❤️

#базаPM

🔍Как сильные ПМы видят проблемы за 2 недели до дедлайна

Большинство ПМов думают, что управляют рисками, а на практике просто ведут risk register, который никто не открывает🫩

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

Я подобрал для вас доступные в РФ инструменты, через которые риски видно раньше всех👇

1️⃣Kaiten — перегруз и скрытые блокеры

Контролировать:
⭕️ где копятся задачи
⭕️где растёт cycle time
⭕️где задачи «висят» между колонками
⭕️где один человек тянет больше остальных

2️⃣Яндекс Трекер — риск размытых требований

Контролировать:
⭕️сколько задач возвращается на доработку
⭕️сколько комментариев до старта разработки
⭕️сколько задач стартуют без финального описания

Повторные открытия задач — прямой сигнал риска качества и сроков.

3️⃣Weeek — риск хаоса в приоритетах

Контролировать:
⭕️сколько задач переприоритизируется
⭕️сколько задач «срочно» появляется внутри недели
⭕️сколько задач переносятся

Частые переносы — риск срыва планирования, а не «гибкость».

4️⃣Pyrus — риск коммуникационных провалов

Контролировать:
⭕️где зависли согласования
⭕️где задачи долго ждут ответа
⭕️где много участников без решений

Долгие согласования — один из самых дорогих скрытых рисков проекта.

5️⃣Datalens — системные риски скорости

Контролировать:
⭕️throughput
⭕️cycle time
⭕️загрузку по людям
⭕️рост незавершённой работы

📍Когда скорость падает плавно, риск уже случился, просто ещё не признан. Сильные ПМы не «фиксируют риски», они смотрят на поведение системы.

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

Ставьте «❤️», если было полезно и сохраняйте себе, чтобы не потерять.

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

😳ПМ — самая бесполезная роль в IT. И я это докажу.

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

Созвоны останутся, задачи будут двигаться, разработчики продолжат работать. И это неприятная правда🙂

Проблема не в роли ПМа, а в том, что большинство ПМов не создают ценность.

Они:
⭕️передают сообщения
⭕️ходят на встречи
⭕️обновляют статусы
⭕️пушат сроки
⭕️делают видимость контроля

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

❗️

Настоящая ценность ПМа вообще не в этом.

ПМ нужен там, где есть сложность.

Сильный ПМ — это не координатор задач, это человек, который уменьшает хаос и стоимость ошибок💸

Он:
⭕️защищает фокус команды
⭕️управляет рисками до проблем
⭕️принимает неприятные решения
⭕️держит экономику
⭕️убирает лишнюю работу
⭕️создаёт систему, где скорость растёт, а не держится на героизм
И вот парадокс.

Если ПМ делает работу правильно, его меньше видно, потому что хаоса меньше. Но если убрать сильного ПМа, система начинает ломаться очень быстро.

Поэтому вопрос не в том, нужен ли ПМ. Вопрос в том, координатор ты или реально влияешь на систему?

Если ты все же ПМ, а не координатор и готов двигаться дальше, ставь «❤️»

#базаPM

🥲Почему классический ПМ умер год назад?
Что останется у ПМа, когда всю рутину автоматизируют?

К сожалению или к счастью, в наши дни автоматизируется почти всё, что ПМы делали годами:

⭕️статусы собираются сами
⭕️репорты генерятся сами
⭕️дедлайны считаются
⭕️напоминания отправляются
⭕️митинги заменяются async
⭕️задачи двигаются без тебя

И это уже происходит.

Но есть работа, которую не автоматизируют и не смогут это сделать (по крайней мере, в ближайшее время😅). Это и есть реальная зона ценности ПМа, за это ему и готовы платить.

👉Что же на сегодняшнее время остается под влиянием хороших ПМов?

1️⃣Решения в условиях неопределённости, когда нет правильного ответа и нужно выбрать.
2️⃣Приоритизация, которая влияет на деньги. Не «что первое», а «что вообще делать не надо».
3️⃣Управление конфликтами между скоростью, качеством, бизнесом и командой.
4️⃣Снижение рисков до того, как они случились — это всегда человеческая работа.
5️⃣Перевод хаоса в понятные решения. ИИ помогает анализировать, но решение принимает человек.

❕

Самые частые ошибки ПМа сейчас:

- усиливать то, что скоро исчезнет
- оптимизировать репорты
- улучшать статусы
- делать ещё больше контроля

Усиливать нужно другое — влияние.

Проблема в том, что многие ПМы всё ещё растут в старой модели, где ценность — это следить, напоминать, контролировать, «держать в курсе». Но рынок уже платит не за это📊

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

Слабый ПМ:

⭕️

ведёт процесс

⭕️

реагирует

⭕️

фиксирует проблемы

⭕️

объясняет, почему не получилось

Сильный ПМ:

⭕️

влияет на решения

⭕️

видит риски раньше

⭕️

убирает лишнее

⭕️

делает проект управляемым

👉Поэтому главный навык ПМа сейчас не управление задачами, а управление системой.

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

Автоматизация убирает рутину, но резко повышает требования к мышлению.

И дальше будет только жёстче.

Если откликается, ставь «👍». Интересно посмотреть, сколько здесь ПМов, которые это уже чувствуют❤️

#базаPM

🤬Почему конфликты в проекте — это нормально

Многие ПМы боятся конфликтов. Они стараются сгладить, договориться, никого не задеть. Кажется, что если все друг с другом вежливы и спокойны, значит, проект идёт хорошо, но на практике всё часто наоборот😐

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

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

Конфликт возникает там, где люди начинают обсуждать реальные ограничения.

Например:

когда команда говорит, что срок нереальный, ПМ объясняет, что ещё одна фича сдвинет релиз, разработчики спорят о техническом решении, а бизнесу

приходится выбирать между скоростью и качеством.

⏩Проблема не в самих конфликтах. Проблема возникает, когда конфликты перестают обсуждать.

Тогда люди начинают:
⭕️молчать на созвонах
⭕️соглашаться «для вида»
⭕️обсуждать проблемы в кулуарах
⭕️копить раздражение

И в какой-то момент это всё равно выливается, только уже в большой конфликт или сорванный дедлайн…

❕Задача ПМа — не избегать конфликтов, а управлять ими.

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

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

И часто самый тревожный сигнал в проекте — не конфликт, а его отсутствие. Когда на созвонах никто не спорит, не задаёт вопросов и просто кивает. Поэтому

хороший ПМ не боится конфликтов. Он следит, чтобы они оставались рабочими и приводили к решениям

😉

А как у вас в проектах? Конфликты чаще помогают двигаться вперёд или наоборот тормозят работу?

Делитесь в комментариях❤️

#базаPM