У продуктовой команды редко бывает только одна задача и один проект. Пока разработчики заканчивают одну инициативу, аналитик уже нужен во второй, дизайнер переключается на третью, а бизнес приносит срочную задачу, которую нужно поставить «в самое начало».
На уровне отдельных проектов всё может выглядеть нормально. У каждого есть список задач, оценки, ответственные и желаемые сроки. Проблема появляется, когда эти планы начинают использовать одну и ту же команду.
Backend-разработчик не может одновременно работать над тремя проектами. Аналитик не начнёт следующий этап, пока занят текущим. Отпуск одного специалиста способен сдвинуть цепочку зависимых работ. А повышение приоритета одной инициативы почти всегда означает, что что-то другое будет сделано позже.
Поэтому управление несколькими проектами — это не просто ведение нескольких досок или диаграмм Ганта. Главная задача — построить единый исполнимый план, в котором приоритеты связаны с реальной доступностью команды и календарными сроками.
Почему несколько независимых планов перестают работать
Представим продуктовую команду, которая одновременно развивает три направления:
- новый пользовательский кабинет;
- интеграцию с внешней системой;
- переработку процесса оплаты.
Для каждого направления можно отдельно построить красивый план. В первом проекте backend нужен с понедельника. Во втором — тоже с понедельника. В третьем — со среды.
Если это один и тот же разработчик, все три плана одновременно выполнить невозможно.
В результате появляется знакомая картина: сроки существуют, задачи оценены, приоритеты вроде бы расставлены, но никто не может уверенно ответить на простой вопрос:
когда каждый проект реально закончится с учётом остальных проектов?
Это принципиальная разница между планированием отдельного проекта и планированием нескольких проектов одной командой.
Отдельный проект можно рассматривать как последовательность работ. Несколько проектов нужно рассматривать как общую очередь работ за ограниченные ресурсы.
Начинать нужно не со сроков, а с приоритетов
Одна из типичных ошибок — сначала назначить всем проектам желаемые даты, а потом пытаться разместить работы внутри этих сроков.
Если ресурсов меньше, чем одновременно запланированных работ, такой подход создаёт не план, а набор ожиданий.
Сначала нужно определить, какие инициативы действительно важнее других.
Например:
- Запуск нового тарифа.
- Интеграция с ключевым партнёром.
- Переработка внутренней административной панели.
- Техническая модернизация отчётности.
Приоритет должен отвечать не на вопрос «какой проект важен», потому что важными обычно оказываются все. Он должен отвечать на более жёсткий вопрос:
какой проект должен получить дефицитный ресурс раньше, если одновременно выполнить всё невозможно?
Именно в этот момент приоритизация превращается из управленческой декларации в механизм планирования.
Если проект №1 действительно важнее проекта №3, общий план должен отражать это в очередности работы специалистов.
Приоритет проекта и приоритет задачи — не одно и то же
Внутри каждого проекта тоже есть свои срочные и важные задачи. Поэтому легко попасть в ситуацию, когда команды пытаются сравнивать между собой десятки или сотни отдельных задач из разных инициатив.
Для верхнеуровневого планирования это быстро становится слишком сложно.
Практичнее разделять два уровня:
Приоритет проекта или инициативы определяет, кто первым получает ограниченный ресурс между несколькими направлениями.
Приоритет задач внутри проекта определяет порядок выполнения работ уже внутри выбранного направления.
Такой подход помогает Product Owner не превращать общий план развития продукта в одну огромную очередь тикетов.
Сначала определяется порядок инициатив. Затем каждая инициатива раскладывается на этапы и работы.
Следующий шаг — найти общие ограниченные ресурсы
После приоритизации нужно понять, из-за каких специалистов проекты на самом деле конкурируют друг с другом.
Это не обязательно вся команда.
Например:
| Проект | Аналитик | Backend | Frontend | QA |
|---|---|---|---|---|
| Новый тариф | нужен | нужен | нужен | нужен |
| Интеграция | нужен | нужен | почти не нужен | нужен |
| Админ-панель | не нужен | нужен | нужен | нужен |
Главным ограничением здесь может оказаться backend-разработчик. Именно его доступность будет определять, когда смогут стартовать ключевые этапы всех трёх проектов.
В другой команде узким местом может быть аналитик, дизайнер, DevOps-инженер или единственный специалист по конкретной технологии.
Поэтому ресурсное планирование проектов начинается не с вопроса «сколько у нас людей вообще», а с вопроса:
каких специалистов одновременно требуют наши приоритетные инициативы?
Не нужно планировать сотрудника на 120%
Когда проектов много, возникает соблазн распределить человека между ними: 40% сюда, 30% туда, ещё 30% в третий проект.
На уровне финансовой модели такая арифметика может быть полезна. На уровне ежедневной продуктовой разработки она часто создаёт ложное ощущение доступности.
Если специалист постоянно переключается между несколькими крупными работами, календарный результат зависит не только от суммы часов. Появляются переключение контекста, ожидание уточнений, незавершённая работа и дополнительные точки синхронизации.
Для грубого стратегического планирования проценты допустимы. Но если задача — получить понятную последовательность работ и прогнозируемые даты, полезнее явно видеть, какая работа занимает специалиста сейчас и что он сможет взять после неё.
Так появляется очередь, которую можно проверить на реалистичность.
Оценка длительности ещё не даёт дату завершения
Допустим, разработчик оценил этап в пять рабочих дней.
Это не означает, что этап закончится через пять дней от сегодняшней даты.
Сначала нужно ответить:
- когда специалист освободится от текущей работы;
- завершены ли предыдущие зависимые этапы;
- нет ли отсутствий в нужный период;
- не стоит ли выше другая инициатива;
- может ли следующий участник команды принять результат сразу после завершения.
Поэтому между понятиями «оценка работы» и «календарный срок» есть принципиальная разница.
Оценка говорит, сколько времени требует работа.
Календарный план показывает, когда для этой работы появится возможность и когда она реально сможет закончиться.
Для Product Owner важны оба значения. Без первого невозможно построить план. Без второго невозможно управлять ожиданиями бизнеса.
Учитывайте зависимости между этапами
Несколько проектов усложняют планирование не только общей командой, но и внутренними зависимостями.
Например:
- Аналитик готовит требования.
- Backend реализует API.
- Frontend подключает интерфейс.
- QA проводит проверку.
Frontend-разработчик может быть свободен уже сегодня, но это не поможет, если API будет готов только через неделю.
Поэтому реальный план должен учитывать одновременно:
- приоритет инициатив;
- доступность специалистов;
- длительность работ;
- зависимости между этапами.
Если учитывать только один или два фактора, сроки начинают выглядеть точными, но перестают быть реалистичными.
Что делать, когда появляется срочная задача
Именно здесь проверяется качество системы планирования.
Представим, что общий план уже построен. Команда знает последовательность проектов и ожидаемые сроки. В этот момент появляется новая инициатива, которую бизнес просит начать немедленно.
Обычная реакция — поставить её первой.
Но это только половина решения.
Если новый проект получает специалиста, который был нужен другим инициативам, изменятся их сроки. Поэтому после изменения приоритета нужно ответить ещё минимум на три вопроса:
- Какие работы будут отложены?
- На сколько изменятся сроки остальных проектов?
- Приемлемы ли эти последствия для бизнеса?
То есть изменение приоритета должно приводить не просто к перестановке карточки в списке, а к пересчёту последствий для общего плана.
Это одна из главных причин, почему статичный roadmap быстро перестаёт отвечать на операционные вопросы продуктовой команды.
Хороший общий план должен отвечать на пять вопросов
Для управления несколькими проектами Product Owner не обязательно нужен план с сотнями показателей.
На практике достаточно, чтобы он быстро отвечал на пять вопросов.
1. Что команда делает сейчас?
Должно быть понятно, какие инициативы уже находятся в работе и какие специалисты ими заняты.
2. Что команда будет делать следующим?
Очередь будущих работ должна определяться не случайностью и не громкостью очередного запроса, а понятными приоритетами.
3. Когда освободятся нужные специалисты?
Это позволяет понять, когда следующая инициатива вообще может начаться.
4. Когда закончатся проекты?
Не «по первоначальному обещанию», а по текущему состоянию плана.
5. Что изменится, если поменять приоритет?
Это критический вопрос. Если система показывает только новое положение проекта, но не показывает последствия для остальных инициатив, управленческое решение принимается практически вслепую.
Как построить процесс планирования нескольких проектов
Практический процесс можно свести к семи шагам.
Шаг 1. Соберите инициативы в один контур
Пока каждый проект живёт в отдельном файле, доске или голове владельца, сравнивать их между собой трудно.
Нужен единый список всех активных и запланированных инициатив.
Шаг 2. Расставьте приоритеты
Зафиксируйте относительный порядок проектов.
Важно именно заставить инициативы конкурировать за место в очереди. Если у половины портфеля стоит одинаковый «высокий приоритет», приоритизации фактически нет.
Шаг 3. Разложите проекты на достаточно крупные этапы
Не обязательно переносить в верхнеуровневый план каждый тикет из таск-трекера.
Для портфельного планирования полезнее оперировать этапами, которые имеют понятную длительность, исполнителя или специализацию и зависимости.
Шаг 4. Зафиксируйте оценки
Без оценок невозможно рассчитать последовательность работ.
При этом оценки не обязаны быть идеальными. План всё равно будет уточняться. Гораздо важнее иметь единую систему измерения и регулярно обновлять её по мере появления новой информации.
Шаг 5. Назначьте реальные ресурсы
Свяжите этапы с конкретными специалистами или понятными ролями команды.
Именно здесь обнаруживаются конфликты, которые были незаметны в независимых проектных планах.
Шаг 6. Постройте общий календарный план
Работы должны занять реальные свободные интервалы с учётом приоритетов, текущей занятости, зависимостей и отсутствий.
После этого у инициатив впервые появляются не просто желаемые, а расчётные даты.
Шаг 7. Пересчитывайте последствия изменений
План не должен быть документом, который один раз согласовали на квартал и больше не трогают.
Новая информация, изменение оценки, отпуск сотрудника, срочная задача или смена приоритета должны приводить к обновлению прогноза.
Ценность плана именно в том, что он помогает принимать решения после изменений, а не только красиво описывает ситуацию в момент создания.
Что обычно не работает
Планировать проекты независимо друг от друга
Так можно получить три корректных проектных плана, которые невозможно выполнить одной командой.
Обещать даты до ресурсного планирования
Желаемый дедлайн превращается в обязательство раньше, чем команда проверила его реализуемость.
Ставить всем инициативам высокий приоритет
Если всё важно одинаково, в момент конфликта решение всё равно придётся принимать вручную.
Использовать roadmap как точный календарный план
Roadmap хорошо показывает направление развития продукта. Но для ежедневного ответа на вопрос «когда освободится backend и что из-за этого сдвинется» нужен более детальный операционный уровень.
Переставлять приоритеты без оценки последствий
Повышение приоритета одного проекта не сокращает объём остальных работ. Оно меняет очередь. Значит, кто-то почти неизбежно получит результат позже.
Как Product Owner может использовать такой план
Хорошее планирование не должно превращать Product Owner в диспетчера задач.
Наоборот, оно освобождает его от постоянного ручного выяснения:
«А когда примерно закончим?» «А кто сейчас занят?» «А если эту задачу поднять наверх, что уедет?» «Почему этот проект опять не стартовал?» «Мы вообще помещаемся в квартал?»
Когда инициативы, приоритеты, ресурсы и сроки связаны в одной модели, разговор с бизнесом меняется.
Вместо:
«Команда постарается взять это раньше».
можно обсуждать:
«Мы можем поднять эту инициативу. Тогда проект B сдвинется примерно на такой период. Этот компромисс нас устраивает?»
Это уже не спор о том, что важнее. Это управленческое решение с видимыми последствиями.
Где здесь KORDO
KORDO предназначен именно для ситуации, когда несколько проектов или продуктовых инициатив конкурируют за одну команду. Связанные разборы: ресурсное планирование и оценка сроков разработки.
Вместо независимых планов проекты собираются в общий контур: можно задать их относительный приоритет, описать этапы и ответственных специалистов и получить связанный календарный план.
Если приоритеты или исходные условия меняются, смысл перепланирования состоит не просто в перестановке проекта в списке, а в том, чтобы увидеть, как изменение влияет на дальнейшую последовательность работ и сроки.
При этом KORDO не должен заменять таск-трекер. Jira, YouTrack, Kaiten и другие системы могут оставаться местом, где команда ведёт конкретные задачи разработки. KORDO решает другой уровень задачи — в какой последовательности выполнять инициативы общей командой и когда они смогут завершиться.
Главное
Управление несколькими проектами начинается не с красивой диаграммы Ганта и не с ещё одной доски задач.
Нужны четыре связанные вещи:
приоритеты → ограниченные ресурсы → последовательность работ → календарные сроки.
Пока они существуют отдельно, команда может быть очень занята, но общий план всё равно будет постоянно расходиться с реальностью.
Когда они соединены, изменение приоритета перестаёт быть абстрактным решением. Становится видно, какой проект получит ресурс раньше, какой начнётся позже и как изменится прогноз по всему набору инициатив.
И именно такой план помогает Product Owner управлять не списком обещаний, а реальной очередью развития продукта.