Управление несколькими IT‑проектами — это дисциплина портфеля: вы выходите на предсказуемые сроки и бюджет за 4–8 недель настройки процессов, но ключевой риск — «мультизадачность по героизму», когда один менеджер пытается тащить всё и в итоге срывает всё понемногу.

Почему «несколько проектов» ломают даже опытных

Боитесь потратить полгода на «наведение порядка», а получить ещё больше хаоса? Нормально. Вести 2–5 проектов одновременно — это не про умение «успевать». Это про железную систему приоритизации и прозрачность, которая переживает форс-мажоры, отпуск разработчика и внезапное «а давайте ещё фичу, там же на час».

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

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

1) Декомпозиция цели: что значит «без срывов» в цифрах

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

Практический вывод: зафиксируйте 4 метрики на весь портфель — и вы резко уменьшите «внезапности».

• План/факт по срокам (в процентах выполненного объёма к дате)
• План/факт по бюджету (burn rate: сколько денег/ресурса сгорает в неделю)
• Throughput (сколько задач/историй команда реально закрывает за неделю)
• WIP (сколько задач «в работе» одновременно — главный убийца сроков)

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

2) Ограничьте параллельность: WIP‑лимиты как страховка бюджета

Тезис: сроки чаще всего умирают в очередях и переключении контекста, а не в «кодинге».

Практический вывод: введите жесткие WIP‑лимиты на уровне людей и команд: «один исполнитель — одна активная крупная задача» (максимум две, если одна — ожидание).

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

3) Единая точка правды: портфельная доска

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

Практический вывод: сделайте одну портфельную доску (Jira/YouTrack/Trello/Notion — не принципиально), где каждый проект сравним по статусу и рискам.

Типичная ошибка: пытаться сделать «идеальную» систему учёта и утонуть в настройках. Вам нужна система, которую команда реально обновляет.

4) Приоритизация между проектами: правило «одного главного»

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

Практический вывод: раз в неделю — 30 минут портфельного ревью с владельцами бизнеса/продукта: 1 проект — главный, 1–2 — поддержка, остальное — либо «заморозка», либо «после даты Х».

1. Определите «главный проект недели» (которому достаётся внимание узких специалистов).
2. Зафиксируйте, что откладываем (это важнее, чем что делаем).
3. Согласуйте SLO ожиданий: «ответ на инциденты — 2 часа», «новые фичи — не раньше следующего ревью».

Подводный камень: «Мы не можем заморозить». Тогда вы замораживаете срок и бюджет — просто не признаёте это вслух.

5) Бюджет и сроки: как не утонуть в изменениях

Тезис: многопроектность = постоянные изменения. Поэтому управлять надо не «идеальным планом», а механикой изменений.

Практический вывод: введите лёгкий Change Control:

• любое изменение — в виде заявки (1 абзац: что меняем и почему);
• оценка влияния: сроки (+N дней) или бюджет (+N часов/рублей);
• решение раз в неделю на портфельном ревью.

Типичная ошибка: принимать изменения «на лету» в чатике. Это выглядит как забота о бизнесе, а на практике — это как кредит под 200% годовых: быстро, больно, неожиданно дорого.

Скрытая цена многопроектности (которую не закладывают)

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

Экспертный вердикт и инструмент: чек-лист портфельного PM

Если хотите вести несколько IT‑проектов без эпических срывов, вам нужна не «сила воли», а короткий регулярный ритуал управления. Вот 5 вопросов, которые стоит задать себе (и стейкхолдерам) прямо на этой неделе:

• Какой проект главный на ближайшие 7 дней? Название, а не «все важные».
• Что мы сознательно не делаем до даты Х? Если списка нет — значит вы врёте сами себе.
• Где узкое место? Один человек/роль/сервис, который тормозит всё.
• Какие 3 риска самые вероятные? И кто владелец каждого риска.
• Как мы принимаем изменения? Кто имеет право менять сроки/объём и как часто.

Если на 2–3 вопроса ответов нет — вы не управляете портфелем, вы реагируете на шум. А шум, как известно, дедлайны не уважает.

Частые вопросы