Почему я ввёл «ограничение скорости» для проектов в мультипроектной команде

Странный цикл параллельных проектов: всё движется, но ничего не завершается

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

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

Ограничение скорости: неочевидное правило

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

Под «ограничением скорости» я имею в виду не ограничение трудолюбия команды, а ограничение количества проектов, которые одновременно находятся в состоянии «полного хода».

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

Мы ввели правило: в каждый момент времени только один проект может идти на «полной скорости». Остальные либо заморожены, либо переведены в «крейсерский» режим.

Почему это работает?

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

Как определить, какой проект достоин полной скорости

Я использую два критерия:

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

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

С этими двумя критериями решение простое: чем ближе внешний дедлайн и чем больше инерция, тем больше проект заслуживает полной скорости.

Как мы внедрили это на практике

Мы сделали три вещи:

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

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

Третье — пересматриваем приоритеты каждую неделю. Проект на полной скорости не фиксирован. Если внешние сроки меняются или появляется новый блокер, мы перераспределяем приоритеты.

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

Как это правило может провалиться

У правила есть явные границы.

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

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

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

Если вы тоже застряли в болоте мультипроектности

Если вы ведёте несколько проектов одновременно, мой совет: не спешите нанимать людей. Сначала проверьте, не слишком ли много проектов работает «на полоборота».

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

Если сработает — закрепите правило. Если нет — значит, проблема глубже: возможно, ошибочно само направление проекта или в командном взаимодействии есть более серьёзные проблемы.

В любом случае эксперимент стоит дёшево и его стоит попробовать.

PaxLee