Менеджмент

Проджект или Продукт?

18 декабря 2026

6 мин

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

Проект

Временное предприятие, направленное на создание уникального продукта, услуги или результата. У него есть чёткое начало и чёткий конец.

Проджект-менеджмент

Применение знаний, навыков, инструментов и методов для удовлетворения требований к этому проекту.

Поэтому принципиальная разница: продукт-менеджер спрашивает «что и зачем?», его цель — ценность для пользователя, успех измеряется NPS и retention; проджект-менеджер спрашивает «как и когда?», его цель — сроки, бюджет и содержание, успех — on-time, on-budget, scope achieved. Продукт мыслит возможностями, проджект мыслит ограничениями. Это не два уровня одной иерархии, а две ортогональные оси координат. Продукт без проекта — мечта, проект без продукта — бессмысленная работа.

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

Первая

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

ВТОРАЯ

Вторая фаза — планирование: час славы проджекта. Пока продукт-менеджер рисует стратегический роадмап, проджект строит WBS (Work Breakdown Structure) и раскладывает «запустить мобильное приложение» на 300 конкретных задач: нарисовать иконку, настроить CI/CD, подписать сертификат, протестировать кнопку входа через Google. Ключевой навык здесь — видеть зависимости и синхронизировать входы и выходы так, чтобы никто не ждал и никто не переделывал трижды.

ТРЕТЬЯ

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

ЧЕТВЕРТАЯ

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

ПЯТАЯ

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

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

ПЕРВЫЙ

«У нас нет чартера, мы работаем по устной договорённости». Поздравляю, у вас есть чартер, просто он не оформлен как отдельный документ. Если спонсор написал вам в мессенджере «Начинай, я согласовал бюджет» — это чартер. Если он провёл встречу и сказал «Петров отвечает за проект, выделяю ему двух человек» — это чартер. Документ не обязан называться «Project Charter» и не обязан лежать в папке с красивой обложкой.

ВТОРОЙ

«Сначала надо собрать все требования, потом писать чартер». Это ловушка. Чтобы собирать требования, нужны ресурсы. Чтобы получить ресурсы, нужен чартер. Чартер пишется на этапе, когда требований почти нет, и это нормально. Миф третий: «Чартер — это толстая книга». Нет. Чартер — стратегический документ, а не техническое задание. 20 страниц — значит, вы либо пишете лишнее, либо подменяете чартером план проекта. Миф четвёртый: «В Agile чартер не нужен». Agile меняет форму, но не суть. Даже в Scrum у проекта есть цель, владелец продукта (фактический спонсор), выделенная команда и бюджет. Где-то это зафиксировано? Поздравляю, это чартер. Просто он может называться «Vision Document» или «Project Brief».

Особый случай — продуктовые команды. В чисто продуктовой разработке, где один продукт, одна команда и бесконечный горизонт, отдельного чартера на каждую фичу нет. Продукт — это не проект, у него нет даты окончания. Но даже в продукте есть проекты. Запуск новой версии мобильного приложения — проект. Интеграция с внешним сервисом — проект. Переход на новую архитектуру — проект. И у каждого такого начинания должен быть чартер. В корпоративном Waterfall чартер — вход в формальный процесс с кучей согласований. В продуктовой команде — краткая запись в Confluence: «Мы берём на себя следующие три спринта, чтобы сделать А, не делаем Б, ожидаем рост метрики В на 10%». Суть одна: авторизация, полномочия, границы.

Почему это важно тимлиду? Вы не обязаны писать уставы проектов. Это работа проджект-менеджера. Но вы обязаны требовать устав, прежде чем тратить время команды. Простой тест: к вам приходит PM и говорит «Надо срочно сделать интеграцию с новым шлюзом, бизнес горит». Вы спрашиваете: «Проект утверждён? Бюджет выделен? Кто спонсор? Какие сроки — реальные, а не „вчера“?». Если PM приносит чартер — вы работаете в зрелой организации. Если говорит «пока устно, но очень надо» — вы имеете право отказаться. Потому что без чартера нет обязательств. И нет защиты, когда через две недели выяснится, что денег не выделили, а спонсор вообще уволился. Чартер — это не про бюрократию. Это про уважение. Спонсор уважает проект настолько, чтобы потратить 20 минут на формулировку задачи и подпись. Менеджер уважает команду настолько, чтобы не дёргать её в пустоту. Команда уважает своё время настолько, чтобы не начинать работу без чётких правил игры.