Планирование проектной работы — стандартная практика. Она знакома каждому, кто работал в современных командах разработки. Но что, если ваш сервис — не просто одна команда? Что, если это целый «оркестр» из нескольких самостоятельных коллективов, которым нужно сыграть одну партию без дирижёра?
Именно в такой ситуации оказываются многие зрелые продуктовые сервисы. Рассмотрим пример Соискательского JobBoard в hh.ru — это сервис, который отвечает за весь пользовательский опыт людей, которые ищут работу: от поиска вакансий до откликов на них. Я — Анвар, Сервис Деливери лид этого сервиса. Моя зона ответственности — эффективные процессы поставки ценности. Покажу, как несколько продуктовых команд учатся договариваться и синхронизироваться. Как они достигают общих целей без дирижёра.

Почему процесс планирования так важен?
Прежде чем погрузиться в детали, важно определиться с терминами. Когда я говорю «планирование», то имею в виду квартальное планирование продуктовых инициатив. Это не планирование спринтов или детальных задач внутри команд. Речь идёт о высокоуровневом планировании фичей, проектов и направлений развития продукта на три месяца вперёд.
Это планирование включает:
-
Выбор ключевых инициатив для реализации
-
Распределение ресурсов между командами и направлениями
-
Координацию зависимостей между проектами
-
Синхронизацию с общей стратегией компании
Теперь к главному вопросу. Зачем вообще нужен структурированный процесс такого планирования?
-
Повышение вероятности достижения целей. Структурированное планирование значительно увеличивает шансы получить желаемый результат. Без планирования команды работают интуитивно, что снижает эффективность.
-
Координация работы множества команд. Без чёткого процесса неизбежны конфликты ресурсов. Появляется дублирование работы и упущенные зависимости.
-
Приоритизация в условиях ограниченных ресурсов. Команды всегда имеют больше идей, чем могут реализовать.
-
Согласование действий с бизнес-целями. Важно убедиться в правильном направлении. Техническая работа должна служить стратегическим целям.
-
Прозрачность для всех заинтересованных сторон. Все должны понимать, что и почему происходит.
За годы работы мы пришли к эффективному процессу. Он позволяет достичь всех целей с минимальными накладными расходами. Что особенно важно — этот процесс масштабируется. Он растёт вместе с продуктом и командой.
Контекст задачи
Наш сервис «Соискательский JobBoard» состоит из трёх продуктовых направлений. Каждое отвечает за определённую часть пользовательского пути соискателя и включает пару команд. Обычно это фронтенд-бэкенд + мобильная команда. Итого: шесть команд разработки плюс кросс-функциональные команды: DSML и Маркетинг.
Планирование происходит синхронно во всей компании. Каждый сервис должен предоставить согласованный список фичей, которые планируется реализовать за квартал.
Задача многократно усложняется из-за:
-
Сложной сети зависимостей — как внутри сервиса между командами, так и с другими сервисами компании
-
Разного темпа развития отдельных команд и технологий
-
Необходимости баланса между продуктовыми и техническими задачами
Стратегическая основа — главное с чего начать
В основе нашего подхода к планированию лежит стратегия. В нашем случае — это квартальные цели сервиса. Они выравнивают все команды и направления.
Наши цели — это всегда конкретные бизнес-метрики, которые мы хотим вырастить за квартал. Следуем принципам SMART-целей: конкретные, измеримые, достижимые, но амбициозные. Оптимально 3-5 ключевых метрик на квартал — если их больше, это размывает фокус команд.
Важный момент: цели фиксируются публично на специальной Miro-доске в самом начале процесса. Они служат «полярной звездой» для всех последующих решений. К этим целям мы возвращаемся при каждом сложном выборе и приоритизации.
Структура процесса планирования
Наш процесс квартального планирования занимает примерно четыре недели, но это не означает, что все команды полностью погружены в него на весь период. Мы выделяем несколько ключевых точек синхронизации, чтобы выровнять цели, обсудить пересечения и принять финальные решения.
1. Подготовка и настройка окружения (1-2 недели до старта)
Этот этап требует минимальных усилий от большинства участников.
Основную работу выполняет лид сервиса, который:
-
Сохраняет для истории копию доски предыдущего квартала
-
Подготавливает свежую Miro-доску с шаблоном планирования
-
Формулирует предварительные квартальные цели сервиса на основе стратегии
-
Планирует ключевые встречи в соответствии с общим графиком процесса
Тайминг: 2-3 часа работы продакт-лида в роли координатора. Без вовлечения остальных команд.
2. Планирование внутри направлений (1-2 недели)
На этом этапе каждый продакт-менеджер направления проводит одну-две встречи со своими командами. Обычно час-полтора каждая.
На встречах происходит следующее:
-
Обсуждаем стратегические цели и их значение для направления
-
Определяем предварительный скоуп работ на квартал
-
Даём приблизительные оценки в неделях, учитывая праздники и планируемые отпуска
-
Определяем процент времени на технический долг
Ключевой вызов: на этом этапе часто возникает проблема оценки инициатив, так как они ещё недостаточно проработаны. Это естественный сигнал о необходимости улучшения процесса discovery в общем потоке ценности. Одна из наших целей — достичь того, чтобы к моменту планирования большая часть инициатив уже имела достаточную степень проработки. Это нужно для более точной оценки.
Тайминг: 2-3 часа встреч + несколько часов асинхронной работы продакта.
3. Планирование техдолга (1-2 недели)
Параллельно с продуктовым планированием техлид сервиса проводит отдельные встречи с командами. Цель: планирование задач техдолга.
Мы сознательно выделяем не менее 30% времени на работу с техдолгом — и этот процент не подлежит пересмотру. Опыт показывает печальную закономерность: попытки «сэкономить» на техдолге в пользу продуктовых задач всегда приводят к его накоплению. И, в итоге, к серьёзным проблемам в будущем.
Тайминг: 1-2 часа встреч + несколько часов асинхронной работы техлидов.
4. Публикация черновиков планов (до конца 2 недели)
После внутреннего планирования каждая команда асинхронно публикует свои черновики и запросы:
-
Черновики инициатив и задач в Miro
-
Запросы к другим командам (внутри вертикали)
На этом этапе начинается настоящая магия процесса. Становятся видны пересечения и зависимости. И, что важно — всё это происходит до начала активной фазы разработки. В этот момент изменения ещё не требуют значительных затрат.
Ключевой принцип: максимальная прозрачность. Все планы всех команд доступны всем участникам процесса. Это значительно упрощает координацию и позволяет выявить проблемы на ранних стадиях.
Тайминг: 1-2 часа асинхронной работы продактов и техлидов.
5. Приоритизация и согласование (3 неделя)
На третьей неделе происходит самый интенсивный обмен информацией:
-
Команды приоритизируют свои планы с учётом выявленных зависимостей
-
На уровне всего департамента могут происходить общие кросс-сервисные синхронизации
-
Продакты публикуют уточненные черновики в общем бэклоге на квартал
-
В конце недели проводится общий синк соискательской вертикали (1-2 часа)
Важный аспект: приоритизация в основном происходит на уровне каждого направления с учётом квартальных целей. Команды используют различные подходы к приоритизации, выбирая те, которые лучше подходят для их конкретных задач и контекста.
Тайминг: 1-2 часа встреч + 2-3 часа асинхронной работы.
6. Финализация и презентация (4 неделя)
Финальный этап — утверждение и представление планов:
-
Проводим финальную встречу-презентацию (полтора-два часа)
-
Каждое направление представляет свои цели и ключевые инициативы
-
Обсуждаем основные риски и зависимости
После этой встречи считаем планы утвержденными — команды могут приступать к их реализации.
Тайминг для команды: 2 часа на финальную встречу + 1-2 часа на подготовку к ней.
К чему мы стремимся: непрерывное адаптивное планирование
Описанный процесс отлично работает и позволяет командам самостоятельно координироваться в рамках общих целей и процессов. Но мы видим возможность сделать его еще более органичным — превратить планирование из периодического мероприятия в естественную часть ежедневной работы команд.
Наше видение — создание непрерывного адаптивного планирования, которое органично вплетено в повседневную работу команд.
В такой модели:
-
Нет отдельного «периода планирования» — планирование встроено в рабочий процесс и происходит на постоянной основе
-
Инициативы проходят глубокую проработку до момента попадания в бэклог — это улучшает точность оценок и снижает риски срыва квартальных целей
-
Цели и метрики можно отслеживать в реальном времени — это позволяет быстрее реагировать на изменения
-
Синхронизация происходит по мере необходимости, а не по расписанию
Параллели с мировыми практиками
Многие глобальные технологические компании перешли к адаптивному, итеративному планированию, где ключевыми опорами стали автономные кросс-функциональные команды, регулярные ритмы синхронизации и встроенные петли обратной связи. Spotify демонстрирует это через модель Tribe/Squad, Amazon — через «two-pizza teams» и процесс планирования от клиента (Working Backwards), Google увязывает итеративные планы с OKR-циклами и еженедельными OKR-sync, а Atlassian поддерживает постоянное улучшение с помощью регулярных ретроспектив и оценки состояния команд.
Наш подход не является прямым копированием этих моделей. Мы адаптируем лучшие идеи под специфику нашего бизнеса, задач и организационной культуры. Такой обмен опытом и переосмысление практик позволяет нам оставаться гибкими и эффективными в быстро меняющейся среде.
Уроки на пути к идеальному процессу
Синхронизация между командами
Мы решаем задачу координации через стандартные инструменты: публикацию планов, кросс-командное выравнивание и общие синки. Но в прошлом цикле пошли дальше — объединили ключевые этапы планирования с сервисом, с которым у нас больше всего пересечений.
Результат превзошел ожидания: команды напрямую обсуждали зависимости, решения принимались на месте без эскалаций, точность планирования заметно выросла. Главный вывод: стандартизированные процессы должны гибко адаптироваться под конкретные потребности бизнеса.
Фокусировка по стратегическим темам
Мы категоризируем все задачи по стратегическим темам — это не цели, а общие направления работы над стратегией (например: развитие продукта, улучшение клиентского опыта, рост бизнеса). Когда задач много, они крупные и между ними есть иерархия, без чёткой категоризации сложно отслеживать фокус команды и поддерживать нужные пропорции между разными направлениями. Категоризация по стратегическим темам помогает лучше ориентироваться в приоритетах и связывать повседневную работу со стратегическими целями.
Эволюция через обратную связь
После каждого цикла планирования проводим опрос команд, участвующих в планировании, и внедряем улучшения. Так, мы отказались от избыточных встреч, внедрили чёткие регламенты и создали прозрачную систему отслеживания зависимостей.
Команды довольно быстро почувствовали разницу — меньше времени на организационные моменты, больше фокуса на содержании. Важно: планирование должно быть инструментом для достижения бизнес-результатов, а не самоцелью.
На что обращать внимание
Для успешного внедрения подобного процесса критично:
Зрелость команды — продакты и лиды должны понимать ценность планирования, иначе любой процесс станет бюрократией.
Прозрачность процессов — все зависимости и планы должны быть видны заинтересованным сторонам.
Единый ритм — синхронизация в масштабах компании создаёт предсказуемость.
Объединение инструментов — множество систем (Jira, Miro, Excel) требует дополнительной синхронизации, что снижает эффективность.
Интеграция в рабочий процесс — планирование должно стать естественной частью работы, а не выделенным мероприятием.
Заключение
Квартальное планирование в крупном продуктовом сервисе — это баланс между структурой и гибкостью. С одной стороны, нам нужен чёткий процесс для координации множества команд. С другой — мы работаем в динамичной среде, где требования и приоритеты могут быстро меняться.
Описанный процесс — результат нескольких лет экспериментов, ошибок и улучшений. Он позволяет нам эффективно координировать работу множества команд, сохраняя фокус на стратегических целях и обеспечивая необходимую гибкость.
Важно понимать, что этот процесс — не бюрократическая формальность, а инструмент, который помогает командам быть более эффективными и создавать более качественный продукт. И как любой инструмент, он должен постоянно совершенствоваться в соответствии с меняющимися потребностями.
А какие подходы к планированию работают у вас? Сталкиваетесь ли вы с похожими вызовами? Делитесь в комментариях своим опытом — эта тема всегда актуальна и вызывает интересные дискуссии.
ссылка на оригинал статьи https://habr.com/ru/articles/915318/
Добавить комментарий