Управление портфелем IT‑проектов: как выбирать, что убить, а что развивать

Аркадий Фроймчук

Сооснователь ИТ-компании BPA

Под портфелем IT-проектов в реальности понимается не просто формальный список инициатив, а весь объем работы, которым живет компания: действующие контракты, внедрения, доработки, пилоты, R&D и новые направления. В какой-то момент этих проектов становится достаточно много, и они начинают конкурировать между собой: за ключевых специалистов, сроки, бюджет и, что особенно важно, управленческое внимание.

На этом уровне зачастую меняется логика управления. Если внутри отдельного проекта ключевой момент заключается в вопросе «как реализовать», то на уровне портфеля — «почему именно это делается сейчас и какой вклад это дает бизнесу». Не все проекты равнозначны по влиянию: одни формируют выручку здесь и сейчас, другие открывают доступ к новым рынкам, третьи поддерживают операционную устойчивость.

При этом важный нюанс в IT-бизнесе — ограниченность ресурсов не только в деньгах, но и в экспертизе. Ключевых специалистов нельзя бесконечно масштабировать или быстро заменить без потери качества. Поэтому любое решение о запуске, развитии или изменении приоритетов проекта — это всегда выбор, который влияет на весь портфель. Фактически именно на уровне портфеля формируется реальная стратегия компании в операционном виде.

Когда портфель начинает требовать отдельного управления

Пока проектов немного, компания обычно управляет ими поштучно: у каждой инициативы есть заказчик, бюджет, команда и понятный результат. Но по мере роста бизнеса этого уже недостаточно. В какой-то момент проекты начинают влиять друг на друга: конкурируют за одних и тех же специалистов, смещают сроки, перегружают управленческий контур и меняют экономику друг друга. Именно здесь появляется необходимость смотреть не на отдельные проекты, а на портфель в целом.

В профессиональной методологии портфельное управление как раз и рассматривается как механизм согласования проектов со стратегией бизнеса и с доступными ресурсами. Иначе говоря, это способ ответить на простой, но для руководителя принципиальный вопрос: почему именно эти проекты находятся в работе сейчас.

На практике это особенно заметно в компаниях, где одновременно идет много длительных инициатив. Например, для бизнеса масштаба BPA портфель может находиться в диапазоне 20–50 проектов на постоянной основе в течение года. При этом такая конфигурация остается управляемой за счет выстроенной системы приоритизации и планирования загрузки: команда четко понимает последовательность работ, распределение ресурсов и временные окна реализации по каждому проекту.

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

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

Первый сигнал того, что портфель требует пересборки, зачастую прослеживается в поведении команды. Когда один и тот же специалист одновременно включен в слишком большое количество инициатив, компания начинает платить не только за его рабочее время, но и за постоянное переключение между контекстами. Исследования в области управления вниманием показывают, что после отвлечения человеку требуется значительное время, чтобы вернуться в рабочий контекст. В одном из наиболее цитируемых исследований профессора Калифорнийского университета Глории Марк указано, что в среднем на восстановление фокуса уходит около 23 минут. Для управленческих решений здесь важна не сама цифра, а вывод: избыточная параллельность неизбежно приводит к потерям в производительности и качестве работы.

Есть и вторая сторона этой проблемы — управленческая устойчивость команды. Если ключевые специалисты долго работают в режиме постоянного переключения и перегрузки, это постепенно начинает сказываться не только на скорости, но и на вовлеченности. Всемирная организация здравоохранения описывает выгорание как следствие хронического стресса на работе, который не был успешно управляем, и выделяет три характерных признака: истощение, дистанцирование от работы или цинизм и снижение профессиональной эффективности. Для руководителя это прямой сигнал о том, что портфель собран не вполне сбалансированно и что компании нужно заново посмотреть на приоритеты, загрузку дефицитных ролей и допустимый объем параллельной работы.

При этом перегрев портфеля проявляется не только через загрузку сотрудников. Есть ряд управленческих и экономических сигналов, которые возникают раньше, чем команда начинает явно «проваливаться».

Во-первых, это размывание сроков. Проекты формально находятся в работе, но начинают терять предсказуемость: этапы смещаются, появляются постоянные «переприоритизации», и ни один из проектов не движется с той скоростью, на которую изначально рассчитывали. Важно, что это происходит не из-за сложности конкретной задачи, а из-за конкуренции за ресурсы внутри портфеля.

Во-вторых, ухудшается управляемость маржинальности. В условиях высокой параллельности становится сложнее точно учитывать затраты: время ключевых специалистов распределяется между проектами, возникают незапланированные доработки, растет объем внутренних коммуникаций. В результате проекты, которые на старте выглядели экономически устойчивыми, начинают терять прибыльность уже в процессе реализации.

Еще один признак — снижение качества управленческих решений. Когда в портфеле слишком много активных инициатив, внимание руководства рассеивается. Решения начинают приниматься реактивно: в ответ на срочные запросы, эскалации и операционные проблемы, а не исходя из стратегических приоритетов. В такой конфигурации даже сильная команда начинает работать в режиме постоянного «тушения пожаров».

Также важно обращать внимание на клиентский контур. Перегруженный портфель часто приводит к тому, что коммуникация с заказчиками становится менее стабильной: увеличиваются сроки обратной связи, сложнее выдерживать единый уровень сервиса, чаще возникают разночтения по ожиданиям и SLA. Это не всегда критично на уровне одного проекта, но в совокупности начинает влиять на репутацию и повторные продажи.

Ключевые индикаторы, по которым можно оценить текущее состояние и управляемость портфеля проектов

Поэтому главная задача на этом этапе — не искать «виноватый проект», а увидеть общую картину. У портфеля почти всегда есть предел управляемости. И чем раньше компания начинает работать с ним как с единой системой, тем проще сохранять и темп, и качество, и экономику проектов.

Матрица приоритетов: как выстраивать фокус без потери качества

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

Поэтому для первого управленческого среза лучше работает не сложная финансовая модель, а простая и понятная матрица приоритетов. Ее логика строится на двух критериях: ценность проекта для бизнеса и его ресурсоемкость. Такой подход позволяет быстро увидеть, какие инициативы действительно стоит развивать, какие требуют оптимизации, а какие уже не соответствуют текущим задачам бизнеса.

Ценность проекта определяется прежде всего двумя параметрами: его прибыльностью и стратегическим значением. Прибыльность — базовый критерий для любого зрелого бизнеса. Но на практике этого недостаточно. Проект может быть не самым маржинальным в моменте, но при этом давать сильный стратегический эффект: открывать доступ к новому рынку, формировать показательный кейс, усиливать экспертизу команды или создавать возможность для повторного масштабирования решения в других контрактах. Именно поэтому при оценке портфеля важно смотреть не только на прямую экономику одного проекта, но и на его влияние на развитие бизнеса в целом.

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

Второй параметр — ресурсоемкость. И здесь ключевой управленческий акцент заключается в том, что ресурсоемкость нельзя сводить только к бюджету. Для IT-компании это всегда более сложная категория. Она включает деньги, время, управленческое внимание, фокус команды и загрузку дефицитных ролей. Если проект требует постоянного вовлечения архитектора, тимлида, аналитика или ML-инженера, то его реальная стоимость для портфеля может быть существенно выше, чем кажется по смете. Именно поэтому один и тот же проект может выглядеть экономически приемлемым на бумаге, но быть очень тяжелым для исполнения внутри текущей структуры.

И, наконец, бывают ситуации, когда проект начинает требовать непропорционально много внимания по сравнению с тем эффектом, который он дает. В этом случае задача не в том, чтобы «резко отказаться», а в том, чтобы пересобрать модель работы: скорректировать условия, перераспределить ресурсы или найти более эффективный формат реализации.

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

С практической точки зрения такая матрица дает руководителю понятную типологию проектов. По сути, это адаптация сразу двух управленческих подходов: классической логики BCG-матрицы (где активы делятся по вкладу в бизнес) и более прикладной модели «эффект / затраты», широко используемой в продуктовой и IT-разработке для приоритизации задач.

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

В этой логике в портфеле обычно выделяются несколько типов инициатив.

Проекты с высокой ценностью и низкой ресурсоемкостью — в терминологии BCG их можно сопоставить с «звездами» или точками роста. Это инициативы, которые дают быстрый и заметный эффект при относительно небольших затратах. Именно они чаще всего становятся драйверами развития: их масштабируют, тиражируют и используют как основу для дальнейших решений.

Проекты с высокой ценностью и высокой ресурсоемкостью — это стратегически значимые инициативы, близкие по логике к «дойным коровам» или ключевым продуктовым направлениям. Они требуют серьезных вложений, но формируют основную ценность для бизнеса. Здесь управленческая задача — не сокращение, а повышение эффективности: стандартизация процессов, снижение зависимости от дефицитных ролей, повышение предсказуемости.

Проекты с относительно низкой ценностью и низкой ресурсоемкостью — это инициативы, которые не оказывают существенного влияния на стратегию, но при этом остаются частью операционной деятельности. В классических моделях такие активности часто рассматриваются как кандидаты на оптимизацию или перераспределение. В реальной практике они требуют аккуратного управления: важно не их «убирать», а минимизировать влияние на ключевые ресурсы и не допускать накопления.

Проекты с низкой ценностью и высокой ресурсоемкостью — наиболее сложная категория с точки зрения управления. В теории портфельного управления именно такие инициативы рассматриваются как зона повышенного внимания, поскольку они создают нагрузку на систему без сопоставимого эффекта. Здесь задача руководителя состоит в том, чтобы не принимать резких решений, а пересматривать формат работы: корректировать условия, менять модель реализации или перераспределять ресурсы.

KPI жизни и смерти: когда закрывать проект

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

Хорошо это видно на примере развития собственной продуктовой линейки. Например, в BPA параллельно развиваются несколько направлений: платформенные решения в области видеоаналитики, отдельные прикладные ИИ-продукты и экспериментальные разработки на стыке AI и компьютерного зрения (зачастую это R&D разработки). На старте по каждой из таких инициатив есть понятное ожидание: где она может применяться, какой эффект давать, как масштабироваться.

Управление ИТ-портфелем усложняется тем, что в реальной разработке, особенно в AI-направлениях, движение почти никогда не идет строго по плану. Могут меняться требования, уточняться сценарии использования, усложняться интеграции, появляться новые ограничения по данным или инфраструктуре. Это нормальная ситуация сложной продуктовой разработки.

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

Поэтому в работе с проектной или продуктовой линейкой важно сохранять базовую дисциплину: периодически возвращаться к исходной логике проекта и проверять, сохраняется ли она в текущей конфигурации.

Это особенно важно для решений, например, в области искусственного интеллекта. В отличие от классической разработки, здесь ценность часто становится понятна не на этапе идеи, а в процессе внедрения: через пилоты, реальные данные и обратную связь от пользователей. Поэтому проекты в этой области требуют более частых точек пересмотра и более аккуратного управления ожиданиями.

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

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

Именно здесь для руководителя начинается самая сложная часть управления портфелем. Проблема обычно не в том, что компания не видит цифры или не понимает экономику. Гораздо чаще мешают психологические и организационные факторы: желание не признавать ошибку, надежда, что проект «еще дожмется», страх упущенной выгоды. Отдельно работает эффект уже сделанных вложений: чем больше в проект инвестировано времени, денег и усилий, тем сложнее принять решение о его пересмотре или остановке, даже если дальнейшая перспектива становится все слабее.

Поэтому закрытие проекта не должно быть эмоциональным решением. В зрелой системе управления это обычная управленческая процедура. Проект сохраняет место в портфеле до тех пор, пока у него есть понятное бизнес-обоснование. На практике это означает, что у каждой инициативы должны быть контрольные точки пересмотра. В них команда и руководство заново смотрят не на объем уже проделанной работы, а на текущую картину: сохраняется ли экономический смысл, подтверждается ли прикладная ценность, соответствует ли проект текущим приоритетам бизнеса, не стал ли он слишком дорогим по вниманию команды.

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

Чтобы такие пересмотры не превращались в субъективные обсуждения и не зависели от интуиции отдельных участников, важно зафиксировать набор конкретных критериев, по которым оценивается текущее состояние проекта. Это позволяет опираться на наблюдаемые сигналы в процессе реализации. Ниже приведен практический чек-лист, который помогает структурировать такую оценку и вовремя определить, требует ли проект корректировки формата, изменения подхода или отдельного управленческого решения.

1. Нарушение исходной гипотезы проекта. Текущая реализация существенно отличается от первоначальной логики: изменился сценарий использования, целевая аудитория или способ создания ценности.
2. Смещение точки ценности. Проект продолжает развиваться, но создаваемый результат уже не соответствует ключевой бизнес-задаче или не усиливает основное направление компании.
3. Накопление архитектурной или продуктовой сложности. Решение становится сложнее с каждой итерацией: растет количество костылей, зависимостей, доработок, что увеличивает стоимость дальнейшего развития.
4. Потеря прозрачности в принятии решений. Команда продолжает двигаться вперед, но становится сложно объяснить, почему именно такие решения принимаются и какой результат они должны дать.
5. Размывание границ ответственности. В проекте появляется слишком много пересечений: неочевидно, кто отвечает за результат, решения принимаются коллективно и долго, растет операционная инерция.
6. Несоответствие масштаба проекта текущей стадии. Проект может быть переусложнен для своей зрелости (слишком много функций, слишком ранняя оптимизация) или, наоборот, недоразвит для заявленных задач.
7. Потеря темпа обучения. Проект перестает давать новые управленческие или продуктовые инсайты: команда работает, но не становится понятнее, куда двигаться дальше.
8. Инерционное продолжение. Основной аргумент в пользу продолжения касается уже осуществленных вложений, а не текущей ценности или перспектив.
9. Разрыв между техническим и бизнес-видением. Техническая команда продолжает развивать решение, но бизнес уже не до конца понимает, как это будет использоваться или монетизироваться.
10. Рост «скрытой стоимости» поддержки. Проект требует все больше усилий на сопровождение, доработки и поддержку, которые не были учтены изначально.

Чек-лист пересмотра проекта в процессе реализации

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

Стратегия развития после пересмотра портфеля

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

В классическом портфельном управлении есть базовый принцип: баланс между тем, что дает результат сейчас, и тем, что формирует будущее. Часто этот баланс описывают через модель 70/20/10 — распределение ресурсов между основным бизнесом, смежными направлениями и экспериментами. Но важно понимать, что это не жесткое правило, а скорее ориентир, который помогает начать разговор о структуре портфеля.

На практике структура всегда зависит от типа бизнеса. В случае BPA, где значительная часть работы связана с разработкой сложных технологических решений и AI-продуктов, доля инициатив с высокой неопределенностью может быть заметно выше. Это естественно для deeptech-направлений. Но вместе с этим усиливается требование к управлению: чем больше в портфеле экспериментов, тем строже должны быть правила отбора, контроля и пересмотра таких проектов.

Поэтому вместо фиксированных процентов более полезно использовать простую управленческую логику разделения портфеля.

Первая группа — это ключевые направления бизнеса. Проекты и продукты, которые уже доказали свою эффективность и обеспечивают стабильную выручку или понятный результат. На них держится текущая операционная устойчивость, и именно здесь важно сохранять предсказуемость и качество.

Вторая — направления роста. Это инициативы, которые развивают текущие компетенции, расширяют продуктовую линейку и создают повторяемые кейсы. Они требуют инвестиций, но при этом находятся в зоне понятной логики развития.

Третья — инновационные инициативы. Проекты с высокой неопределенностью, которые могут дать значимый стратегический эффект, но не гарантируют его. Здесь особенно важно управлять не только идеями, но и условиями их реализации: ограничивать объем инвестиций, фиксировать контрольные точки и регулярно возвращаться к оценке результатов.

Пирамида приоритетов портфеля

В опыте BPA есть важный практический принцип, который помогает держать этот баланс: даже на ранних стадиях компания старается избегать полностью «бесплатных» экспериментов. Если заказчик или рынок не готовы подтвердить интерес хотя бы минимальным участием или бюджетом, это сигнал о слабой прикладной ценности. Такой подход снижает риск того, что портфель будет перегружен инициативами без реальной перспективы внедрения.

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

Портфель как управляемая система

Так, портфель проектов — это не статический набор задач, а управляемая система, которая постоянно меняется вместе с бизнесом. По мере роста компании усложняется не только количество инициатив, но и связи между ними: за ресурсы, внимание команды и управленческий фокус.

Именно поэтому регулярная ревизия портфеля — это не разовая управленческая активность, а часть нормального операционного цикла. Оптимальная частота определяется каждым бизнесом самостоятельно, но лучшим решением является проводить ее не реже одного раза в квартал, а для динамичных технологических бизнесов — чаще. Это позволяет вовремя корректировать приоритеты, перераспределять ресурсы и не допускать накопления инициатив, которые теряют актуальность.

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

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

Сегодня существует достаточно методологий (Agile, Scrum и другие подходы), которые можно адаптировать под конкретный бизнес. Важно не столько выбрать «идеальную» систему, сколько внедрить ту, которая действительно будет работать в вашей структуре и поддерживаться на всех уровнях.

Другой ключевой момент — это готовность руководителем принимать решения. Запускать проекты всегда проще, чем останавливать. Но если инициативы продолжают тянуть ресурсы без понятного эффекта, это начинает замедлять развитие всей компании. Портфель начинает работать тогда, когда им управляют как системой: с понятными правилами, регулярными пересмотрами и готовностью корректировать курс.