Согласно исследованию PMI (Project Management Institute), 58% крупных IT-проектов сталкиваются с проблемами из-за нехватки ресурсов или несогласованности приоритетов, а внедрение гибких практик Agile увеличивает вероятность успешной реализации на 30%.
В условиях такой динамики управление портфелем проектов становится настоящим искусством: нужно одновременно распределять ограниченные ресурсы, минимизировать риски и поддерживать прозрачность для команды и клиента.
О том, как это делать лучше всего, и какие есть секреты мастерства, мы поговорили с Алёной Талыковой, проект-менеджером, которая успешно руководит международными командами, внедряет Agile-практики и создаёт стандарты PMO, позволяющие достигать результатов без потери гибкости и вовлечённости.
Алёна Талыкова - проект-менеджер с подтвержденным опытом увеличения коммерческих показателей клиентов (AOV, конверсия, удержание) через эффективное управление проектами. Успешно руководила международными командами, внедряя Agile-практики, что повышало продуктивность на 30%. Её навыки охватывают полный цикл: от управления рисками и бюджетами до разработки документации и пресейла. Владеет инструментами (Jira, Confluence, Figma) и основами веб-технологий (HTML/CSS, JS, SQL).
- Управление портфелем проектов на $16 млн - это постоянный выбор и расстановка приоритетов. Расскажите о ситуации, когда вам приходилось принимать сложное решение о перераспределении ресурсов (людей, бюджета, времени) с одного «громкого» проекта на другой, менее заметный, но более критичный для общих целей. Как вы это обосновали и отстаивали?
В управлении портфелем проектов время от времени приходится тушить пожары, это часть работы. И здесь важно не просто быстро реагировать, а понимать, насколько у нас действительно есть возможность перераспределить ресурсы.
Всё зависит от контекста: в какой сфере работает клиент, насколько критичен релиз в конкретную дату, по какому типу контракта мы взаимодействуем и по какому подходу к разработке работаем. Например, если клиент из производственного сектора, то даунтайм для запуска новой системы планируется заранее, и остановка производства просто невозможна. В таких случаях говорить о переносе дедлайна сложно, поэтому приходится сместить фокус и перестроить приоритеты внутри команды.
Если, скажем, команда разработки временно задействована на другом проекте, я стараюсь перераспределить работу так, чтобы в этот момент параллельно шел прогресс по задачам из более поздних этапов, например, подготовка технической документации, тест планы: для клиента и внутренний, инструкции для клиента, лейаут и формат лейблов, настройка доступа к энвайронментам для клиента, проведение тестирования клиентом и сбор фидбека по уже готовым модулям. Таким образом проект продолжает двигаться, даже если основные dev-ресурсы временно ограничены.
Если же и это невозможно, например, когда проект полностью зависит от конкретных разработчиков или находится на определенном этапе, тогда важно признать ограничения и работать над оптимизацией последующих спринтов, а также рассматривать частичный релиз (phased Go-live or staggered Go-live).
В таких ситуациях помогает именно открытая коммуникация (внутри команды и с клиентом) и системный подход.
- В Agile мы часто говорим о «fail fast». Был ли в вашей практике момент, когда вы осознанно пошли на серьезный риск (например, в технологии, сроках или бюджете), понимая возможность провала? Что это был за случай и чему он вас научил, независимо от исхода?
Осознанно идти на серьезный риск можно только если клиент готов его принять, и важно понимать, что для него в приоритете: Learn or Earn.
Если говорить о возможности провала, были случаи, когда после пресейла мы понимали, что наша система соответствует требованиям бизнеса клиента и полностью их покрывает. Но риском было то, что клиент не использовал подобную систему на практике до этого.
Это могло вести к завышенным ожиданиям и change requests на финальных этапах разработки, когда нужно было либо вносить изменения, либо переносить релиз.
Нам было важно дать клиенту понять, как система будет работать в контексте его бизнеса. Мы внедрили kick-off тренинг. Возможность для клиента «потрогать» систему, понять, чего ожидать и как она работает. Это решило сразу несколько задач: клиент получил лучшее понимание того, что будет доставлено на выходе, а UAT на финальной версии продукта стал более продуктивным. Параллельно с этим, во время тренировочных сессий, так или иначе разговор касался требований бизнеса и наша команда была уже более подготовлена к работе над функциональными требованиями и понимала темы, которые стоит обсудить более предметно.
- Вы создаете стандарты PMO. А что происходит, когда эти безупречные процессы сталкиваются с хаотичной реальностью и срочными запросами? Где вы проводите черту между необходимостью следовать стандарту и гибкостью «ради бизнеса»?
На практике идеальных условий не бывает, поэтому важно понимать, что стандарты PMO это инструмент. Они нужны, чтобы структура и контроль помогали, а не мешали бизнесу. Например, иногда бывают ситуации, когда имеет смысл начать разработку по уже согласованному функционалу во время или до полного запуска цикла согласований и подписей по шаблону. Тогда я действую таким образом и фиксирую решения постфактум. Важно, чтобы была понятна логика. Не «мы нарушаем процесс», а «мы действуем осознанно и управляем риском». Вот такой баланс между формальной дисциплиной и гибкостью.
