"У вас 8 часов разработки": главная иллюзия Junior PM, которая сжигает бюджеты ИТ-проектов
Каждый раз, когда я менторю начинающих проджектов, я вижу одну и ту же картину в MS Project или Jira. Красивый календарно-сетевой график, идеальная последовательность задач и… 100%-я утилизация ресурсов. Сеньор-разработчик привязан к проекту на 8 часов в день, 5 дней в неделю. В теории — швейцарские часы. В реальности — кассовый разрыв и просрочка контракта на первом же спринте.
Почему на реальном ИТ-производстве (особенно в крупных интеграторах с матричной структурой) эта математика ломается и как джуну перестать выжигать команду?
🪤Капкан №1: Иллюзия «Эффекта 8 часов» Начинающий PM считает, что если рабочий день длится 8 часов, то все эти 8 часов архитектор пишет код, а аналитик проектирует базу данных. Реальность: Чистого времени (Focus Time) у разработчика выходит не более 5–6 часов. Остальное безжалостно съедают: Дейли, синки, ретроспективы и архитектурные созвоны. Переключение контекста между задачами (багфикс vs новая фича). Заполнение тайм-шитов. Итог: Заложив 8 часов чистой разработки, джуниор гарантированно получает отставание от графика уже к концу первой недели. Проект начинает копиться как снежный ком, и PM включает «ручное управление» — овертаймы.
🪤Капкан №2: Матричная война за людей (можно отдельную статью написать...) Джуниору часто кажется, что выделенный ему backend-разработчик принадлежит только его проекту. Реальность: В крупных компаниях ресурсы «распилены». Один и тот же специалист может быть занят на 30% на вашем пресейле, на 40% на коммерческом проекте коллеги и на 30% на закрытии критического госконтракта по 44-ФЗ. Поскольку начинающий PM не умеет договариваться со смежными менеджерами и функциональными руководителями, его задачи просто встают на «паузу». У него нет ресурсной матрицы на 2–4 недели вперед, и он замечает простой сотрудника слишком поздно — когда дедлайн сорван.
🪤Капкан №3: Ставка на «незаменимых» и улетающий P&L Когда сроки начинают гореть, у Junior PM включается базовый инстинкт: «Отдай задачу Senior-разработчику, он сделает быстрее». Реальность: Сеньор перегружается на 150%, начинает выгорать и делать ошибки в архитектуре. Находящиеся в команде джуны и мидлы сидят без задач и утилизируются «вхолостую». Себестоимость проекта улетает в космос. Час сеньора стоит дорого, и маржинальность проекта стремительно падает. Вместо плановых 40% рентабельности продаж компания получает убыток.
📚Чему не учат на массовых курсах? Сейчас рынок перенасыщен курсами «Стань PM за 3 месяца». Там отлично учат двигать карточки в Jira, писать User Story и красиво говорить на ретроспективах.
Но бизнес требует от проджекта другого — финансово-ресурсного мышления. Директору проектного офиса (PMO) не нужен менеджер, который при любой проблеме с ресурсами бежит с криком «нам нужно нанять еще людей!». Бизнесу нужен PM, который умеет: ❗️Считать реальную емкость (Capacity) команды с учетом рисков и отпусков. ‼️Выстраивать систему раннего мониторинга перегрузок (видеть проблему за 2 недели до факапа, а не в день сдачи этапа заказчику). ❗️‼️Аргументированно защищать unit-экономику и ресурсные матрицы перед C-level и жесткими стейкхолдерами госструктур.
Управление ресурсами — это не про софт-скиллы и не про «поболтать на дейли». Это жесткая математика, Excel-таблицы и умение прогнозировать себестоимость. И пока начинающий PM не научится управлять утилизацией команды как деньгами, он так и будет оставаться координатором задач, а не руководителем проектов.
