В софте с 2008 года, 12+ лет в delivery — начиная с кода.
Начинал разработчиком. Перешёл в проектное управление, потом в delivery-руководство в нескольких софтверных компаниях для клиентов из США, Великобритании и Европе. Delivery-проблемы, с которыми помогаю сейчас, — это в основном проблемы, которые я видел изнутри: как PM, как Delivery и как человек, отвечающий за портфель проектов.
или напишите: alexbelkavets@gmail.com
Корни в разработке. Карьера в delivery построена оттуда.
Начинал разработчиком — фронтенд и бэкенд e-commerce в Acumium. Затем более десяти лет проджект-менеджером в TUT.BY Media, Softeq и ScienceSoft, работая с американскими, британскими и европейскими клиентами в веб-, мобильных, embedded- и облачных проектах. Пресейл был частью работы в большинстве этих компаний — там я начал внимательно смотреть на разрыв между тем, что продаётся, и тем, что в итоге доставляется.
В ITRex Group полноценно перешёл в delivery-руководство — портфель клиентских программ в скоупе Head of PMO: управлял юнитом из пяти PM и отчитывался по статусу программ напрямую на уровень CEO/директора. Работа была не про управление их проектами. Она была про построение delivery-инфраструктуры, которой им не хватало: единых форматов отчётности, стандартов трекинга рисков, процессов эскалации, чеклистов ревью скоупа. Два года превращения группы способных PM в нечто, что может работать последовательно — без senior-человека, который латает дыры неделя за неделей.
В Paysera с нуля спроектировал и запустил функцию Employee Engagement and Performance Management — в рамках перехода компании на scaled Agile, с governance в 8 командах разработки, собранных в value-stream юниты по 20–30 человек. Это многое дало в понимании того, что реально определяет поведение команд на масштабе, в отрыве от дизайна процессов. Затем Itexus, где я владел пресейл-флоу от начала и до поставки результата и был единой точкой эскалации по крупнейшим клиентским аккаунтам компании. Переработка пакета передачи в производство, шаблона оценки и шаблона предложения подняла конверсию из лида в клиента на 30%.
С мая 2026 веду независимую практику — fractional- и interim-проекты по delivery плюс прикладная работа с AI-инструментами для delivery. Последний проект — платный двухнедельный аудит процессов для европейской продуктовой компании, где реальной причиной оказалась сломанная кросс-функциональная передача, а не разрыв в оценках, с которым команда пришла.
Опыт
12+
лет в delivery
Команды PM
5
PM под прямым управлением в ITRex Group
Регионы
США · Великобритания · Европа · GCC
Индустрии
Финтех, healthcare, e-commerce, SaaS, B2B, медиа, enterprise software, агентства заказной разработки
Что чаще всего встречается.
Эскалированные клиентские аккаунты в середине проекта
Клиент звонит директору напрямую. PM не понимает, как ситуация ухудшилась. В статус-отчетах всё было зелёным. Зайти, понять, что реально произошло, и стабилизировать отношения, пока они не испортились окончательно.
Несогласованная отчётность PM по портфелю
Пять PM, пять разных форматов, нет общего языка для риска или статуса. Руководство не может сравнивать статус проектов без опроса каждого PM по отдельности. Построение общего операционного ритма, который делает портфель видимым в одном представлении.
Разрывы пресейл → delivery
То, что обещали на этапе продажи, и то, что реально может delivery, расходятся с первого дня. Решение обычно живёт в передаче между отделами: по чему delivery должен быть подключён до закрытия контракта, а не после.
Обьем работ тихо съедает маржу
Маленькие неутверждённые изменения обхема работ принимаются неформально, ни одно не отслеживается, все они появляются в цифрах в конце месяца. Установка процесса пересмотра объема работ, который работает с тем же ПМ.
Фаундер всё ещё менеджер по эскалациям delivery
В компании 150 человек. Delivery всё ещё управляется директором, когда что-то идёт не так. Построение операционного слоя, после которого это перестаёт происходить — без замены команды ПМ, просто давая ей нужные инструменты.
Разрывы по зрелости в растущей команде ПМ
Одни ПМ хорошо владеют рисками. Другие ждут, пока их спросят. Senior компенсируют junior. Построение общих стандартов и ритма чек-инов, которые сужают разрыв, не превращая это в управление компетенциями ПМ.
Встроенно, не консультативно. Конкретные часы, конкретные результаты.
Работаю внутри вашего текущего процесса — с вашими PM, инструментами, ритмом отчётности. Не наблюдаю снаружи и не сдаю отчёт. 8–10 часов в неделю для частичного сотрудничества; больше — для полной занятости.
У работы конкретная форма: еженедельные ревью здоровья проектов, поддерживаемый список рисков, чек-ины с PM, месячный итоговый отчет для руководства. Не консалтинг, заканчивающийся слайд-деком и советами.
Большая часть — асинхронно: статус-ревью, обновления списка рисков, письменные выводы и отчеты, План и контроль по всему, что всплывает между чек-инами. Один еженедельный звонок для того, что требует живого разговора. Доступен между сессиями для срочного вмешательства.
Встроен в вашу команду PM, а не внешний консультант
Async-first, но доступен для срочных звонков между еженедельными ревью
Все сотрудничества начинаются с 2-недельной диагностики до того, как что-либо станет стандартом
Если диагностика не оправдывает продолжение — скажу прямо
Даю гарантию результата - если не видите пользы, то платить не надо
Несколько вещей, которые я нашёл верными в большинстве проектов.
Большинство delivery-проблем — структурные, а не личные.
PM, который постоянно пропускает риски, — не плохой PM. Обычно он работает без чёткого формата того, что должен содержать список рисков, без общего языка для оценки и без надёжного пути для эскалации, когда что-то выглядит не так. Создайте систему — человек обычно подтянется.
Разрыв между «продано» и «доставлено» — там, где исчезает большая часть маржи.
Это почти всегда можно исправить. Но ловить это надо на в момент передачи в производство — до закрытия контракта, а не когда бюджет закончился через шесть недель. Это значит, что delivery должен быть подключён к пресейл-разговорам достаточно рано, чтобы поймать оценки и обещания, которые не переживут контакт с проектом.
Дашборды не исправят delivery. Системный процесс — исправит.
Проблема часто не только в том, что данные не видны. Проблема еще и в том, что никто не договорился, какие данные собирать, как их использовать и что считать. Инструмент без этой договорённости — просто набор показателей на доске, часто собранный "на глазок".
Избранные результаты и опыт.
Проблемный проект стабилизирован за 2–3 недели — изначальный план пересобран под реальную сложность, спринты заменены на Kanban-поток, клиент получил статус-отчётность, которую реально можно читать.
Портфель из 25 активных проектов и 15 PM переведён на одну общую операционную модель delivery. Сбор статуса по портфелю сократился с 10–12 часов до 1–2.
Передача из пресейл в delivery перестроена в софтверной компании — производственный PM подключается до подписания контракта, поэтому риски и допущения всплывают до старта разработки, а не после.
Конверсия из лида в клиента выросла на 30% в Itexus — после переработки пакета передачи в производство, шаблона оценки и шаблона предложения.
Платный двухнедельный аудит процессов для европейской продуктовой компании: замедление delivery свелось к сломанной кросс-функциональной передаче, а не к разрыву в оценках, который предполагала команда. Результат — отчёт с корректирующими действиями.
PMO построено практически с нуля в ITRex Group — чеклисты, инструменты, шаблоны, политики и delivery-стандарты для юнита из пяти PM на нескольких активных клиентских проектах.
Финтех · Enterprise software · Агентства заказной разработки
Клиенты из США, Великобритании, Европы и GCC.
Начинал разработчиком. Этот бэкграунд по-прежнему влияет на то, как я читаю статус-репорты, интерпретирую delivery-оценки и отличаю реальные риски от шума в обновлениях PM.
20-30 минутный звонок, чтобы понять, подходит ли это к вашей ситуации.
Расскажите про загрузку проектов и расстановку PM. Если есть фит — стартуем с 2-недельной диагностики. Если нет — скажу на звонке.
или напишите: alexbelkavets@gmail.com