Нет PM в команде: что должен делать Senior?

Недавно я прошёл испытательный срок, и на 1-on-1 мой менеджер сказал: «Хотелось бы, чтобы ты был более проактивным в исследовании проблем продукта.»

Это застало меня врасплох. Я каждый день писал код, исправлял issue, двигал проекты вперёд. Как это всё ещё недостаточно проактивно? Мне потребовалось время, чтобы понять, что он на самом деле имел в виду.

Всё работает одновременно

Прохождение испытательного срока не означало меньше давления. Скорее наоборот — это означало жонглировать ещё большим количеством вещей одновременно:

Пункт	Характер	Что я могу контролировать
Исправление issue	Ежедневная работа, результат частично измеряется объёмом	Поддерживать стабильный темп
Проект A	Официальный проект, но пользовательская сторона медленно подтверждает требования	Ограниченно — в основном ожидание ответов
Исследование продукта	Проактивный поиск способов улучшения продукта	Когда сдавать, как презентовать, как отчитываться

Когда переключаешься между тремя и более вещами за один день, утомляет не количество часов. Утомляет постоянный context switching.

Потом я осознал: у нас нет PM

Я знал это с первого дня, но никогда серьёзно не задумывался, что это значит.

У нас есть BA (Business Analyst), который занимается анализом требований, но никто по-настоящему не владеет вопросами вроде: На каком этапе это находится? Кто заблокирован? Нужно ли пересмотреть приоритеты?

В моей предыдущей компании PM или Tech Lead занимался всем этим. Мне нужно было только проверить backlog, подтвердить приоритеты, уточнить требования к продукту и сосредоточиться на написании кода. Приходил spec — я строил. Если застревал — говорил PM, и они разбирались с остальным.

Теперь этой роли не существует. Так кто берёт это на себя?

Senior.

Senior — это не PM, но нужен Ownership

Сначала я не понимал. Я инженер — почему я должен гоняться за пользователями ради ответов, проактивно сообщать о blocker или выравнивать приоритеты с менеджером? Разве это не работа PM?

Но это не значит, что Senior должен заменить PM, взяв на себя roadmap команды, кросс-функциональную координацию или отслеживание прогресса всех остальных. Настоящий смысл проще: нельзя относиться к blocker в собственной работе так, будто это чья-то чужая проблема.

Когда я сравнил эти две роли, разница стала яснее:

	PM	Senior
Чей прогресс отслеживать	Всей команды	Свои собственные линии работы
Решать, что строить	Roadmap, приоритеты	Не решает, но выравнивает
Преследовать stakeholder	Всех вовлечённых	Свои blocker
Ответственность перед	Бизнес-целями	Функциональностью, за которую отвечаешь

Senior не нужно управлять другими людьми. Нужно просто не ронять свои три-четыре линии. Сообщать о blocker проактивно вместо молчаливого ожидания. Иметь мнение о функциональности, за которую отвечаешь, вместо простого ожидания инструкций.

Это называется ownership, а не PM.

Дело не в том, что предыдущая работа была слишком простой

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

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

В lean-команде это нормально. Это не неразумно. Я просто ещё не привык.

Что я на самом деле сделал

Разобравшись в этом, я внёс несколько изменений:

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

Когда заблокирован — переключи линию, но оставь запись. Если пользователь Проекта A не отвечает, я пингую раз в неделю и оставляю письменный след. Менеджер знает, что blocker не на моей стороне, а освободившееся время можно потратить на продвижение исследования продукта.

Не делай context switching слишком часто. Используй приоритеты, чтобы решить, над чем работать сегодня, вместо того чтобы трогать всё понемногу. Заблокированные линии записывай, откладывай в сторону и возвращайся, когда разблокируются.

Заключительная мысль

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

К слову, мысли для этого поста я сначала упорядочил через разговоры с AI, а потом отслеживал через личную систему, которую построил для ежедневного логирования и обратной связи — я называю её Pasiv. Vibe coding — это не только использование AI для создания проектов. Это ещё и использование его для распутывания того, где ты сейчас находишься.