В последние 1-1,5 месяца я просматриваю вакансии, оставляю отклики, посещаю собеседования (да 🙂 я решил найти новое дело) и заметил неприятную закономерность — примерно 7 из 10 вакансий с названием «Менеджер проекта в … сфере» по факту ищут SM или универсального солдата с функциями SM + PO + PdM. В одном случае нужен человек, который будет настраивать автоматизацию в Jira и писать JQL‑запросы — по сути, Scrum Master с технической прожаркой. В другом — Product Owner уже есть, бэклог он ведёт сам, внешние коммуникации на нём, а от кандидата хотят фасилитации и контроля спринтов. Вакансия — PM, реальность — совсем другое. В итоге обе стороны теряют по паре часов на собеседование, не получая ничего, кроме вежливого «мы подумаем».
Почему же важно чётко разграничивать роли менеджеров проектов, скрам-мастеров, владельцев продукта и менеджеров продукта? Как смешение этих ролей бьёт по команде и проекту? И что делать, чтобы навести порядок? Давайте разбираться на инженерном уровне — без воды, но с иронией. Куда ж без неё, когда и в резюме у кандидатов честно написано «Scrum Master / Product Manager, 5 лет опыта» 😜
Почему важно не путать роли?
Один из столпов эффективной разработки — понятное распределение ответственности. Когда каждый участник команды знает свою зону ответственности и процессы идут гладко: задачи выполняются в правильном порядке, решения принимаются вовремя, а риски предусматриваются и контролируются. Если же роли путаются, начинается бардак: задачи проваливаются в разрывы между обязанностями, люди дёргают не тех коллег и не по тем вопросам, растёт напряжение. В конечном счёте страдает скорость и качество разработки, а команда выдыхается.
Смешение ролей особенно опасно в сфере управления проектами и продуктами, где у каждой позиции свой фокус. Путаница между продакт-менеджерами и проджект-менеджерами случается достаточно часто. Не все ещё разобрались, что требуются совершенно разные навыки от этих ролей, даже если цель у них общая — успешный продукт для клиента. Чем чётче и понятнее обозначены обязанности, тем легче наладить коммуникацию в команде и добиться результата.
Кроме того, смешение ролей ведёт к конфликтам ожиданий. Руководство может ожидать от человека одного (например, стратегического видения продукта), а команда — другого (например, чёткой постановки задач и убирания блокеров). В итоге крайними оказываются эти универсальные бойцы, которым приходится разрываться. Люди склонны делать то, что у них лучше получается, а остальное — пускать на самотёк. Значит, какие-то функции неизбежно просядут.
Вывод простой — прежде чем строить процесс, нужно разобраться кто есть кто и распределить роли по людям (или хотя бы по «шляпам», если одному человеку досталось несколько ролей — но об этом позже). И дальше очень важно придерживаться выбранной структуры, а если в ней появляются слабые точки, то внедрять изменения которые известны и понятны всем в команде. Начнём с краткого ликбеза: чем же конкретно занимаются PM, SM, PO и PdM, и чем они отличаются.
PM, SM, PO, PdM: кто за что отвечает
Для начала расшифруем аббревиатуры, которые могут сбить с толку. PM обычно означает Project Manager (менеджер проекта), хотя иногда и Product Manager (менеджер продукта) — вот вам и первый источник путаницы! 🙂 В этой статье под PM будем иметь в виду проектного менеджера (проджект-менеджера). А продакт-менеджера будем называть PdM. SM — это Scrum Master (скрам-мастер). PO — Product Owner (владелец продукта). Все четыре роли относятся к менеджменту, но сферы ответственности у них разные.
Разграничим обязанности наших ролей на практике
Project Manager (менеджер проекта)
Проектный менеджер отвечает за успешную реализацию конкретного проекта в заданные сроки и бюджет. Его заботы — треугольник проекта: сроки, объем работ, ресурсы. Проще говоря, PM фокусируется на том, как и когда команда выполнит работу. Он составляет план проекта, ставит контрольные точки (milestones), следит за прогрессом и рисками, координирует взаимодействие между командами. В классическом понимании PM действует с позиции контроля: устанавливает дедлайны, распределяет задачи, отчитывается перед руководством о статусе. Если говорить о заказной разработке, то PM чаще всего включается в процесс ещё на этапе прессейла, работая в паре либо с сейлзом, либо с аккаунтом и тогда, кроме прочего, он отвечает за содержание, бюджет и внешние коммуникации.
Пример типичных задач PM:
Составить план проекта с разбивкой на этапы и спринты, определить сроки и ответственных;
Отслеживать прогресс, апдейтить статусы, вести диаграмму Ганта, видеть отклонения от плана;
Управлять рисками и заранее выявлять возможные проблемы (задержки, нехватка ресурсов), а также придумывать решения;
Коммуникация со стейкхолдерами, чтобы держать заказчиков и руководство в курсе, согласовывать изменения в требованиях, получать нужные данные и действия от внешних участников;
Контроль изменений, чтобы если появляются новые требования, решать, вписываются ли они в текущий проект или требуют изменений плана.
Product Manager (менеджер продукта)
Продакт-менеджер отвечает за стратегию и успех продукта в долгосрочной перспективе. Если у PM горизонт — конкретный проект (часто с конечной датой), то у PdM горизонт временами бесконечный: развитие продукта продолжается, пока он живёт на рынке. Продакт думает о ценности продукта для пользователей и бизнеса. Он изучает рынок и конкурентов, формирует видение продукта, решает, какие функции нужны и в каком направлении эволюционировать, чтобы продукт был востребован.
Пример задач Product Manager:
Исследование рынка и пользователей (ЦА). Проводить интервью с пользователями и анализ конкурентных решений, искать инсайты;
Формирование продуктовой стратегии. Определять видение продукта, его уникальных преимуществ, roadmap вперёд на длительный срок;
Приоритизация фичей. Решать, какие улучшения в продукте самые важные сейчас исходя из стратегии и обратной связи от рынка;
Анализ метрик продукта. Отслеживать KPI — например, конверсию, удержание, прибыль — и на их основе корректировать развитие;
Запуск и развитие. координировать запуск новых версий, работать с маркетингом, поддержкой, собирать отклики пользователей и планировать дальнейшие улучшения.
Продакт-менеджер — стратег, “идеолог бренда”. Его KPI — бизнес-результаты продукта: рост числа пользователей, выручки, удовлетворенности клиентов. Он отвечает на вопросы: что мы создаём и зачем это ценно? В то время как PM отвечает на вопрос: как и когда мы это сделаем?
Важно ☝️ Product Manager vs Product Owner — путаница внутри путаницы. Эти роли часто смешивают, поэтому разберём отдельно ниже. Но сперва проговорим про Scrum Master`а.
Scrum Master (скрам-мастер)
Scrum Master — это фасилитатор команды, который отвечает за процесс разработки по методологии Scrum. Если организация применяет Agile/Scrum, скрам-мастер следит, чтобы команда соблюдала принципы Scrum, помогала ей становиться эффективнее, устраняла препятствия. В отличие от PM, Scrum Master не является начальником для команды и не контролирует сроки в классическом смысле. Он скорее администратор процесса и команды.
Основные обязанности Scrum Master:
Обучение и поддержка Scrum-процесса — проводить ежедневные встречи, планирования, ретроспективы и помогать команде понимать Scrum`е;
Устранение импедиментов (блокеров) — устранять любые препятствия, мешающие команде двигаться вперёд, и защищать её от внешних помех;
Мониторинг процесса и его улучшение — следить за завершением спринтов, актуальностью задач и улучшать процесс на основе метрик типа Velocity, Cycle Time, инициировать изменения;
Коммуникация и психологический комфорт — организовывать командные обсуждения и ритуалы, замечать перегруз или недогруз участников и поддерживать рабочую атмосферу;
Связь с Product Owner — помогать PO формировать бэклог, доносить цели спринта и наладить взаимодействие с командой.
Scrum Master можно назвать нетехническим близнецом PM в Agile-мире: обе роли концентрируются на том, как выполняется работа, только подход разный . PM тяготеет к жёсткому контролю, а SM — к гибкому наставничеству и самоорганизации команды. В классическом Scrum никакого менеджера проекта не предусмотрено — его функции распределены между Scrum Master, Product Owner и самой командой разработчиков. Это важно понимать: если в Agile-команде вдруг появляется должность “Project Manager”, то нужно чётко очертить, за что он будет отвечать, чтобы не дублировать и не мешать SM/PO.
Product Owner (владелец продукта)
Product Owner (PO) — роль из Scrum. Это человек, ответственный за максимизацию ценности продукта, которую создаёт команда. Проще говоря, PO определяет что команда будет делать. Он формирует и ведёт бэклог продукта: список фичей, требований, задач, отсортированный по ценности. В идеале только PO решает, какая задача в каком приоритете попадёт в спринт, и принимает выполненную работу.
Зоны ответственности Product Owner:
Наполнение бэклога: сбор требований от пользователей, бизнеса, рынка. Описание user story, критериев приемки. PO – главный источник задач для команды*
Приоритизация: расставление задач в правильном порядке. Что важнее для ценности – то и будет делаться раньше. Менять приоритеты по мере появления новой информации*
Коммуникация видения: доносить до команды, зачем мы делаем те или иные фичи, какая ценность для пользователя. Участвовать в планировании спринтов, объяснять требования;
Приёмка готового продукта: проверять выполненные истории на соответствие критериям (acceptance criteria), давать обратную связь. Именно PO говорит “Done” или отправляет на доработку;
Работа с пользователями и стейкхолдерами: показывать результаты спринтов заказчикам, собирать обратную связь, управлять ожиданиями. PO мостик между командой и внешним миром.
Важно, что Product Owner — это роль, а не обязательно должность❗️Нередко vtyеджер проекта или продакт-менеджер исполняют роль PO для одной (или нескольких) Scrum-команд. Однако в крупных организациях могут быть отдельно продакт-менеджеры (отвечают за стратегию нескольких продуктов) и отдельно PO в командах (более тактическая роль, ведение day-to-day бэклога). В небольших компаниях наоборот один человек может быть и PdM, и PO, и даже частично Scrum Master — и вот тогда нужна особая осмотрительность, чтобы он не сгорел на работе.
Каждая роль заключает в себе отдельные комплексы компетенций и полномочий. Крайне редко быввает такое, что один человек будет способен хорошо выполнять больше чем одну роль. Особенно если проекты содержательные и интересные. И уж точно он не сможет быть таким универсальным солдатом бесконечно долгое время. Как писал Майк Коэн, комбинировать роли вроде Scrum Master и Product Owner — плохая идея 👎 Задачи слишком разные, требуют разных навыков, и людей, успешно совмещающих «звёздные» (стратегические) и «гвардейские» (операционные) обязанности, единицы.
Но реальность не всегда учитывает идеальные варианты и жизнь диктует своё. Да, бывает, и бывает у всех, что приходится совмещать. Далее поговорим о подобных случаях и про их последствия.
Путаница в вакансиях и найме: рецепты хаоса
В методологиях и правилах можно увидеть идеальный мир «розовых очков» в котором компании чётко знают, кто им нужен. Но на практике чаще всего всё не так радужно. На практике встречаются ситуации, как в моём рейсе, побудившим меня к написанию этой статьи — либо по неопытности, либо из безысходности, компании ищут кандидата способного быть и SM и PM в одном флаконе. Бывает и загадочные позиции 🙂 “Менеджер проектов/продуктовый аналитик”.
Почему так происходит?
Недопонимание от руководства или HR. Пока ещё не все хорошо понимают, чем отличается продакт от проджекта, или проджект от скрам-мастера и так далее. А бывает, что просто игнорируют рекомендации методологий и правил, думая, что возможно их виденье более правильное для их реальности (и такое тоже бывает, но редко). Поэтому в описании вакансий, в требованиях смешивается всё подряд. Искать могут “менеджера проекта”, хотя по факту компании нужен человек, который возьмёт на себя развитие продукта. Бывает наоборот, что стартапу нужен по сути проджект, чтобы довести до релиза MVP, а в вакансии написано красивое и модное “Product Manager”, к тому же от него же требуется знание Scrum и администрирование ритуалов. Тут конфликт ожиданий заложен уже на входе.
Стремление убить двух и более зайцев за раз. Небольшие компании и проекты, пока ещё не выросшие до больших, порой просто не могут содержать штат из нескольких менеджерских позиций. Они ищут “универсального солдата” и это можно понять. Иногда прямо пишут: “нам нужен и проджект, и продакт одновременно”. Радует, что в названиях вакансий всё реже встречаются лютые замесы вроде Product manager/Project manager с функцией Sckrum-коуча. Но тем не менее, по сути требований смешивание ролей пока частое явление. Возможно руководство полагает, что один человек справится со всеми управленческими задачами сразу. Обычно это иллюзия. Как минимум, надо такое открыто обозначать и обсуждать, чтобы вместе с проектом, такой универсальный солдат рос на основе своего идейного согласия с таким стартом.
Мода на Agile-термины. Некоторые компании, особенно не очень опытные в Agile, добавляют к названию должности слово Scrum Master или Product Owner просто потому, что “так принято”. Например, должность называется “Project Manager (Scrum Master)” — мол, мы гибкие, у нас скрам, но по факту от человека ждут типовых действий классического PM (планы, отчёты), плюс нагрузят проведением митингов. Такой “скрам-менеджер” в итоге ни полноценным SM не будет (некогда улучшать процессы, когда горят сроки), ни проджектом довольным не станет (ведь формально нужно следовать Scrum и не командовать командой).
Неопытность в составлении инструкции и должностных обязанностей. Иногда нанимающий менеджер сам смутно представляет, чем отличаются роли. Он может скопировать пункты из нескольких шаблонных описаний. Так появляется вакансия, где в списке: “формирование продуктового бэклога, ведение документации проекта, контроль метрик в Jira, проработка UX с дизайнером, организация демо для клиента, управление командой разработки, оптимизация бизнес-процессов заказчика”. Тут и продакт, и проджект, и немного бизнес-аналитика, и даже UX. Человек, который откликнется, либо сразу уточняет границы, либо готовятся к тому, что придётся разгрести кавалерию задач с минимальной поддержкой.
К чему приводит найм по таким размытым вакансиям? Короткий ответ: ни к чему хорошему. Далее рассмотрим реальные последствия.
Последствия 🔻
Сценарий 1 — Выгорание
Один человек выполняет функции PM, PO, и SM. Разумно, что он быстро станет перегружен. С утра дейлик, после которого надо проверить задачи, ответить на вопросы, провести внешние созвоны и созвоны с руководством… при этом надо удержать в фокусе общую ситуацию, как внутри команды, так и по рискам в проекте… параллельно надо ещё и с бэклогом поработать и оставить время на непредвиденное. Только хардкор 🤘 В итоге срыв сроков (про спринты тут вообще нет смысла говорить, они будут для галочки), 12-часовой рабочий день и выгорание. Вангую — скоро будут менять менеджера проекта 😁
Сценарий 2 — Конфликт ожиданий
Если у ролей нет чётких границ, то всё смешивается и путается. Проджект вмешивается в продуктовые решения («клиент попросил», а вдумчиво осмыслить и правильно отреагировать времени нет). Продакт ставит задачи напрямую разработчикам. Везде есть противоречивые указания, команда непонимающ что происходит (или понимает и параллельно ищет новое место работы), дедлайны срываются, подписчики не получают нужную ценность или получают её сделанной кое-как на костылях (обдумать реализацию тоже нет времени). Начинаются взаимные обвинения вместо совместной работы над общей целью. Команда развалится.
Сценарий 3 — Срыв спринтов
Отсутствие ключевых ролей критично. Без SM ретроспективы не проводятся, процесс стагнирует и блокеры не устраняются (их скорее всего, заранее даже не увидят). Без PO команда работает не над тем, что действительно первее всего нужно. Даже при соблюдении плана разработки почти наверняка продукт будет провальным.
Последствия всех сценариев
Выгорание особенно касается тех, кто совмещает несколько функций или находится в конфликте ролей. Продакт без проджекта выматывается, совмещая стратегию днем и операционку ночью. По итогу перегруз, чаще ошибки и отсутствие качественных решений. Растет Cycle Time, падает Velocity, накапливается техдолг. Команда теряет доверие к менеджменту, начинается пассивное сопротивление или анархия.
Решение кажется простым — перестать формировать "универсалов" и правильно выстроить работу с ролями. Но на деле это не всегда возможно прямо сейчас. В таком случае надо честно признать, что получить эту возможность — важнейшая стратегическая цель всей компании. Всем коллективом надо сформировать понятные всем план и график решения сложившейся ситуации. Да, кто-то уйдёт, но те кто останутся будут с вами на долго!
Как навести порядок — процессы, инструменты, метрики
Если в команде смешаны роли, план спасения включает: прояснение ролей и ожиданий, настройку процессов, подбор инструментов (Jira и Bitrix, Redmine и т.д.), внедрение метрик и автоматизацию рутины.
Разграничьте области ответственности
Первое и главное — обозначить границы каждой роли. Если у вас в команде есть и продакт-менеджер, и проджект-менеджер, сядьте вместе (в идеале с руководителем разработки/CTO) и пропишите, кто за что отвечает. Можно составить простую матрицу RACI или аналог: перечень ключевых процессов (формирование бэклога, планирование релиза, daily-стендапы, обновление статуса задач, общение с заказчиком, отчётность, приемка фич и т.д.) и назначить, кто Responsible (отвечает), Accountable (утверждает), Consulted (консультируется), Informed (уведомляется) по каждому пункту. Это поможет убрать серые зоны. Например, договоритесь, что “приоритизацию бэклога делает исключительно Product Owner, а Project Manager не изменяет порядок задач, но отвечает за то, чтобы команда успела взять необходимый объём”. Или: “Коммуникацию с внешними заказчиками по поводу изменения требований ведёт продакт, а проджект подключается для обсуждения влияния на сроки”. Формализуйте это в коротком регламенте ролей, разошлите всем заинтересованным.
Настройте процессы и церемонии под ваши роли
Если нет Scrum Master, решите, кто возьмёт эти функции (agile-coach, тимлид или разработчик). Кто-то должен модерировать ретроспективы и убирать препятствия;
Обеспечьте приоритет Product Owner на планировании спринта и демо. Никто не должен перепрыгивать через PO к разработчикам;
Для Project Manager выделите еженедельный статус-митинг по рискам и срокам, но не для обсуждения направления продукта;
Внедрите Kanban-элементы для гибкого распределения: визуализируйте поток и назначьте ответственных за каждую колонку на доске.
Используйте инструменты максимально эффективно
Разделите области в Jira: Product Owner ведёт Product Backlog (эпики, user story), Project Manager отвечает за спринт-борд и таски. Создайте две доски с разной фильтрацией для разных ролей;
Настройте шаблоны задач: для продуктовых задач обязательно поле "Business Value", для технических — "Story Points" или "Оценка часов»;
Создайте JQL-запросы для каждой роли:
Для Scrum Master. Задачи, застрявшие в процессе. Например, фильтр: status = "In Progress" AND updated < -3d — покажет таски, которые не обновлялись более 3 дней (возможно, они зависли и требуют внимания SM).
Для Project Manager. Задачи с горящими дедлайнами. Например: duedate <= 5d and status != Done — все незакрытые задачи, у которых дедлайн в ближайшие 5 дней. PM будет держать их на контроле или пинать исполнителей/эскалировать.
Для Product Owner. Новые идеи без оценки. Например, метка “New” и пустое поле оценка: labels = Idea AND "Story Points" is EMPTY. Это сигнал, что надо приоритезировать и проработать.
Общие фильтры для отчетов. например, исключение лишних задач при расчете метрик. В статье про оптимизацию Jira советуют фильтровать нерелевантные задачи из метрик Cycle Time: resolution != Unresolved AND status != Rejected – чтобы не считались задачи, над которыми ещё идет работа, или которые отменены . Настройте подобные quick-фильтры на кумулятивных диаграммах и отчетах.
Внедрите полезные метрики
Cycle Time — отслеживайте время выполнения задачи. Если оно растёт, ищите организационные блокеры;
Cumulative Flow Diagram — анализируйте, как растёт и сокращается бэклог. Если область "To Do" постоянно расширяется, значит команда не успевает или слишком много новых задач;
Velocity — контролируйте стабильность выполнения. Резкие скачки указывают на проблемы с планированием.;
Burnout Rate — следите за текучкой и удовлетворённостью команды. Проводите опросы о понимании ролей.
Автоматизируйте рутину
Часть проблем от смешения ролей усугубляется тем, что человек тратит время на механическую работу, вместо своей основной. К счастью, есть способы хоть немного это облегчить:
Jira Automation (или аналогичные средства): Настройте правила автоматизации. Например, если задача переходит в статус “Done” и это Prod Bug, автоматом ассайнить её на Product Owner для акцепта – PO получит уведомление, не нужно вручную отслеживать. Или простейшее: напоминания в канал Slack/Telegram, если задача висит в статусе “In Review” больше 2 дней – сигнал тестировщику и Scrum Master, что пора пошевелиться.
Скрипты для метрик и отчетов. Если Project Manager убивает полдня на свод Excel с прогрессом, стоит один раз написать Python-скрипт, который дергает Jira API и собирает нужные данные. Пример: получить список задач со статусом “Done” за последние 2 недели и посчитать средний Cycle Time. Это можно сделать через REST API Jira:
import requests, datetime
from requests.auth import HTTPBasicAuth
JIRA_URL = "https://yourcompany.atlassian.net/rest/api/3/search"
JQL = 'project = PRJ AND status changed to Done during (startOfDay(-14), endOfDay())'
resp = requests.get(JIRA_URL, params={"jql": JQL},
auth=HTTPBasicAuth("your.email@example.com", "API_TOKEN"))
issues = resp.json().get('issues', [])
cycle_times = []
for issue in issues:
fields = issue['fields']
started = fields.get('customfield_12345') # допустим, custom поле "Start date"
resolved = fields.get('resolutiondate')
if started and resolved:
t1 = datetime.datetime.fromisoformat(started[:-5])
t2 = datetime.datetime.fromisoformat(resolved[:-5])
cycle_times.append((t2 - t1).days)
print("Average Cycle Time last 2 weeks:", sum(cycle_times)/len(cycle_times) if cycle_times else 0)Этот грубый пример показывает идею: данные можно тянуть автоматически. В реальности, возможно, проще использовать готовые плагины или выгружать в BI-систему, но суть в том, что рутинные отчёты должны считаться машиной, а не человеком вручную каждый раз.
Поддерживайте прозрачность
Проводите внутренние митапы о различиях ролей;
Объясните команде, к кому обращаться по разным вопросам;
Лидеры должны показывать пример уважения к ролям, не обходя цепочку ответственности.
Советы для разных ролей
Если вы кандидат и на собеседовании вам предлагают размытое комбо из ролей, не бойтесь уточнять ситуацию и задавайте вопросы. Обязательно выясняйте какие будут зоны ответственности и какие из них наиболее важны работодателю. Может оказаться, что 80% времени нужен Scrum Master, и только изредка Product Owner. Или наоборот. Попросите привести примеры задач первого месяца работы и примеры задач после полного внедрения, например через 5-7 месяцев. Если слышите в ответ все и сразу – стоит задуматься 🤔 Вы конечно можете принять вызов стать менеджером героем, но заранее обсудите границы и сроки такого квеста. Явно озвучьте, что готовы совмещать, например, функции Scrum Master и Product Owner, но тогда давайте явно пропишем регламенты которые касаются процесса и продукта, установим реалистичные ожидания. Хороший работодатель это поймет и оценит. Плохо, если ваши вопросы вызовут замешательство. Тогда либо приготовьтесь наводить порядок самостоятельно (эта статья вам в помощь 🤓), либо подумайте, надо ли оно вам.
Если вы HR или рекрутер, тянущий вакансию на подобную позицию, постарайтесь ближе пообщаться с коллегами (чаще всего это директор по продукту, CTO или глава PMO). Узнайте, какая проблема стоит за вакансией. Задача рекрутера – не просто передать требования кандидату, но и помочь нанимающему коллеге лучше разобраться, кто ему нужен и как такая позиция правильно называется на рынке труда. Если видите в описании через слеш много всего разного, то аккуратно спросите “А что у нас болит больше всего? Что этот сотрудник, в первую очередь, должен будет выполнять?” Возможно, менеджер задумается и скажет: “Нам горят релизы, нужен тот, кто разрулит с разработкой сроки”. Тогда скажите честно «Давайте назовём эту вакансию Project Manager, а знания продукта будем как бонус смотреть.». Так вы сузите воронку до релевантных людей. Или наоборот “Некому заняться видением продукта” и тогда ищите Product Lead или Product Manager, а остальные навыки вторичны. Ваша роль — убрать лишние хотелки из описания, сделать его чётче. И не соблазняйтесь мыслью найти “супермена на все роли” – такие существуют но их мало и стоят они дорого.
Если вы тимлид или техлид в команде, страдающей от вакуума или наложения менеджерских ролей то проявите инициативу. Во-первых — озвучьте проблему на ретроспективе или напрямую руководству «У нас задачи плавают, потому что нет понятного продакт-менеджера, или мы тонем в созвонах, потому что Scrum Master есть лишь формально и практической пользы не приносит». Хороший руководитель прислушается и задумается. Во-вторых — временно вы сами можете закрыть некоторые пробелы. Тимлиды нередко берут на себя функции project manager (следят за сроками, разбивают задачи) – это нормально, если не превращается в постоянное отвлечение от кода. Старайтесь делегировать менеджерские вещи, как только появится кому. Но лучше уж задать команде направление самому, чем смотреть, как она хаотично мечется. Только не забудьте потом вернуть себе прежнюю роль, иначе рискуете перегрузиться.
Наконец, если вы руководитель (CTO, Head of Product, CEO), от которого зависит оргструктура то не экономьте на ролях в ущерб здоровью команды. Один сильный специалист может закрыть две области на стартовом этапе, но имейте план, как в будущем развести эти зоны ответственности по разным людям. Отправляйте сотрудников на обучение менеджменту, пусть разбираются в смежных ролях, это расширит кругозор и снизит взаимные претензии. Обязательно помните первое правило тайм-менеджмента ❗️ 30% времени всегда должно оставаться свободными, для непредвиденных моментов. Если непредвиденного не будет, то люди займутся повышением своих компетенций. В конце концов они даже просто выдохнут, возможно что-то новое придумают или заметят. Культивируйте культуру уважения экспертизы. Продакт не командует разработкой, а разработчики не спорят с приоритетами продакта по пустякам – каждый должен делать своё дело. И помните какое у вас дело, какой ваш бизнес 👑 Вы нанимаете не низкоуровневых персонал и компания ваша не веники вяжет 😎
Порядок вместо хаоса
Путаница ролей – как баг в организационном коде компании. Если её не исправить, система будет работать с перебоями: то зависнет спринт, то утечёт ценность продукта, то сгорит процессор (в лице перегруженного сотрудника). К счастью, эту проблему реально решить инженерными методами: явно определить модули (роли) и их интерфейсы, убрать дубликаты функций, вести мониторинг показателей и реагировать на аномалии.
Разделяйте обязанности, даже если их выполняет один человек. Настраивайте инструменты так, чтобы поддерживать, а не смешивать роли. Обучайте всех вокруг, зачем нужен каждый винтик в механизме разработки. И тогда ваша команда, где есть и PM, и SM, и PO, и PdM (каждому своё), будет работать слаженно, как хорошо отлаженный двигатель. А проекты полетят вперёд без скрипа и дыма.
Помните, что даже в самом гибком стартапе есть границы человеческих возможностей. Два Атланта лучше, чем один, когда надо держать небо проекта и продукта . Да, иногда одному приходится быть и капитаном, и штурманом, и машинистом сразу – но долго так не протянешь без потерь. Пусть каждый занимается своим делом – это не бюрократия, а залог эффективности и здоровья всей системы.
