Двадцать лет в софте — начиная с кода.
Начинал разработчиком. Перешёл в проектное управление, потом в delivery-руководство в нескольких софтверных компаниях для клиентов из США, Великобритании и Европе. Delivery-проблемы, с которыми помогаю сейчас, — это в основном проблемы, которые я видел изнутри: как PM, как Delivery и как человек, отвечающий за портфель проектов.
Корни в разработке. Карьера в delivery построена оттуда.
Начинал разработчиком — в Acumium и Sony Creative Software. Затем более десяти лет проджект-менеджером в TUT.BY Media, Softeq и ScienceSoft, работая с американскими, британскими и европейскими клиентами в веб-, мобильных, embedded- и облачных проектах. Пресейл был частью работы в большинстве этих компаний — там я начал внимательно смотреть на разрыв между тем, что продаётся, и тем, что в итоге доставляется.
В ITRex Group полноценно перешёл в delivery-руководство — управлял юнитом из пяти PM внутри PMO. Работа была не про управление их проектами. Она была про построение delivery-инфраструктуры, которой им не хватало: единых форматов отчётности, стандартов трекинга рисков, процессов эскалации, чеклистов ревью скоупа. Два года превращения группы способных PM в нечто, что может работать последовательно — без senior-человека, который латает дыры неделя за неделей.
В Paysera руководил департаментом Employee Engagement and Performance в 8 командах разработки — это многое дало в понимании того, что реально определяет поведение команд на масштабе, в отрыве от дизайна процессов. Затем Project Delivery Manager в Itexus, где отвечаю за delivery крупнейших клиентских аккаунтов компании, управляю командой PM напрямую и владею пресейл-флоу от начала и до поставки результата.
Опыт
15+
лет в delivery
Команды PM
5–8
PM под прямым управлением как Delivery
Регионы
США · Великобритания · Европа · 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. Системный процесс — исправит.
Проблема часто не только в том, что данные не видны. Проблема еще и в том, что никто не договорился, какие данные собирать, как их использовать и что считать. Инструмент без этой договорённости — просто набор показателей на доске, часто собранный "на глазок".
Избранные результаты и опыт.
Проблемный проект стабилизирован за три недели — изначальный план пересобран, ритм коммуникации с клиентом перестроен, руководство перестало получать прямые звонки.
Портфель из 12 PM переведён с 6 несогласованных форматов отчётности на один общий. Еженедельный итоговый отчет для руководства собирается с нескольких часов ручной сборки до 10 минут.
Передача из пресейл в delivery подтянутулучшена в софтверной компании — delivery подключился раньше в цикле продаж, что снизило пост-контрактные сюрпризы по объему работ в следующем квартале.
PMO построено практически с нуля в ITRex Group — процессы, чеклисты, delivery-стандарты и трекинг рисков для юнита из пяти PM на нескольких активных клиентских проектах.
Финтех · Enterprise software · Агентства заказной разработки
Клиенты из США, Великобритании, Европы и GCC.
Начинал разработчиком. Этот бэкграунд по-прежнему влияет на то, как я читаю статус-репорты, интерпретирую delivery-оценки и отличаю реальные риски от шума в обновлениях PM.
20-30 минутный звонок, чтобы понять, подходит ли это к вашей ситуации.
Расскажите про загрузку проектов и расстановку PM. Если есть фит — стартуем с 2-недельной диагностики. Если нет — скажу на звонке.