🤬Почему конфликты в проекте — это нормально

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

⏩Конфликты в проекте — это не признак проблемы. Это признак того, что в проекте есть разные интересы и люди не боятся их озвучивать.

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

Конфликт возникает там, где люди начинают обсуждать реальные ограничения.

Например:

когда команда говорит, что срок нереальный, ПМ объясняет, что ещё одна фича сдвинет релиз, разработчики спорят о техническом решении, а бизнесу

приходится выбирать между скоростью и качеством.

⏩Проблема не в самих конфликтах. Проблема возникает, когда конфликты перестают обсуждать.

Тогда люди начинают:
⭕️молчать на созвонах
⭕️соглашаться «для вида»
⭕️обсуждать проблемы в кулуарах
⭕️копить раздражение

И в какой-то момент это всё равно выливается, только уже в большой конфликт или сорванный дедлайн…

❕Задача ПМа — не избегать конфликтов, а управлять ими.

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

Здоровый конфликт помогает проекту двигаться быстрее, потому что проблемы обсуждаются сразу, а не когда уже поздно что-то менять.

И часто самый тревожный сигнал в проекте — не конфликт, а его отсутствие. Когда на созвонах никто не спорит, не задаёт вопросов и просто кивает. Поэтому

хороший ПМ не боится конфликтов. Он следит, чтобы они оставались рабочими и приводили к решениям

😉

А как у вас в проектах? Конфликты чаще помогают двигаться вперёд или наоборот тормозят работу?

Делитесь в комментариях❤️

#базаPM

😳Самые токсичные фразы в проекте

В любом проекте есть фразы, после которых атмосфера в команде резко меняется.
Иногда это даже не грубость и не конфликт, а просто слова, которые запускают цепочку проблем.

Они звучат вроде бы безобидно, но на практике после них начинаются срывы сроков, недопонимание и раздражение внутри команды.

⏩Вот несколько классических примеров:

1️⃣«Это же быстро делается»

Чаще всего эту фразу говорят люди, которые сами не будут делать задачу.

И после неё почти всегда происходит одно и то же:
⭕️появляется «срочная» задача
⭕️ломается текущий план
⭕️команда вынуждена переключаться
⭕️сроки начинают плыть

Проблема не в самой задаче, а в том, что её сложность оценивают без команды.

2️⃣«Ну вы же разработчики, придумайте»

Одна из самых токсичных фраз для команды, потому что она означает:
⭕️требований нет
⭕️решения нет
⭕️ожидания при этом есть

Фактически ответственность за продуктовое решение просто перекладывается на разработчиков.

В итоге команда начинает делать догадки вместо работы.

3️⃣«Давайте потом обсудим»

Иногда это нормальная фраза, но очень часто она означает, что мы просто откладываем неудобный разговор.

Например:
⭕️непонятные требования
⭕️конфликт между командами
⭕️нереалистичный срок

Проблема никуда не исчезает. Она просто становится больше и всплывает в самый неудобный момент.

4️⃣«Ну вроде работает»

Это одна из самых опасных фраз перед релизом.

«Вроде работает» обычно означает:
⭕️не всё протестировали
⭕️не до конца проверили кейсы
⭕️просто надеемся, что всё будет нормально

И очень часто именно после этой фразы начинается разбор инцидента.

5️⃣«Давайте добавим маленькую фичу»

Любой ПМ знает, что «маленькая фича» почти никогда не остаётся маленькой.

Потому что за ней обычно скрывается изменение логики, новые сценарии, тестирование, правки в других частях системы

И в итоге эта «маленькая» задача начинает тянуть за собой ещё несколько.

Самое интересное, что почти все эти фразы звучат

в каждом проекте

.

За ними часто стоит отсутствие ясности, решений или ответственности

🥲

Делитесь в комментариях, какая фраза в проектах раздражает вас больше всего.
Уверен, список можно сильно расширить👀

#базаPM

💥Самый дорогой конфликт в проекте. Бизнес VS команда

Почти в каждом проекте есть один и тот же конфликт.

Бизнес говорит:
⭕️нужно быстрее
⭕️давайте добавим ещё одну фичу
⭕️это же несложно
⭕️клиент ждёт

Команда говорит:
⭕️сроки нереальные
⭕️требования
⭕️мы уже перегружены
⭕️сначала надо переделать архитектуру

И между ними всегда оказывается ПМ🙂

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

⏩Бизнес говорит → ПМ передаёт команде.
⏩Команда отвечает → ПМ передаёт бизнесу.

Но это не управление, а курьерская служба😅
Конфликт при этом только усиливается…

На самом деле, у бизнеса и команды

разные цели

.

Бизнес думает про:

1️⃣

деньги

2️⃣

рынок

3️⃣

сроки

4️⃣

клиента

Команда думает про:

1️⃣

качество

2️⃣

технический долг

3️⃣

стабильность системы

4️⃣

нагрузку

И если эти два языка просто сталкиваются, и начинается вечный спор. Поэтому одна из главных задач ПМа:

переводить, а не пересылать

.

Например:

❌«Команда говорит, что это сложно»
✅«Если добавить эту фичу сейчас, релиз сдвинется на две недели»

❌«Бизнес хочет быстрее»
✅«Для бизнеса критично выйти в релиз до конца месяца, потому что запускается маркетинг»

Когда обе стороны понимают реальные ограничения, конфликт превращается из эмоционального в рабочий.

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

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

помогал принимать решения

, а не разрушал проект🦸🏻‍♂️

А в ваших проектах чаще на чьей стороне конфликт? Бизнеса или команды?

#базаPM

С 8 марта, девушки!🌷

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

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

И поменьше срочных задач в пятницу вечером🙂

С праздником!💐

⚠️Конфликт, который ПМ должен остановить сразу

В проектах конфликты — это нормально: команда спорит о решениях, бизнес давит на сроки, дизайнеры и разработчики по-разному видят продукт. Но есть один тип конфликта, который нельзя оставить на «пусть сам решится».

⏩Это конфликт между людьми, а не между задачами. Он обычно начинается очень тихо, и ПМ может даже не знать об этом…

Сначала появляются фразы:
⚫️«с ним невозможно работать»
⚫️«он опять сделал по-своему»
⚫️«я больше не буду это переделывать»

Потом люди перестают общаться напрямую. Начинают писать через ПМа, через чаты, через комментарии в задачах.

Появляется пассивная агрессия:
⚫️саркастические комментарии
⚫️игнорирование сообщений
⚫️демонстративные правки

И вот в этот момент многие ПМы делают ошибку — надеются, что люди сами разберутся. Но почти никогда этого не происходит🥲

Потому что конфликт уже перестал быть рабочим, он стал личным. И дальше начинается самое неприятное:
⭕️люди перестают помогать друг другу
⭕️скорость команды падает
⭕️мелкие задачи начинают тянуться днями
⭕️растёт раздражение

В итоге страдает весь проект…

❗️Поэтому задача ПМа здесь не быть наблюдателем. Лучшее, что можно сделать — остановить ситуацию сразу.

Иногда достаточно простого разговора:
⭕️развести ожидания
⭕️договориться о правилах взаимодействия
⭕️вернуть обсуждение к задачам, а не к людям

Потому что в проектах можно спорить о решениях, о сроках, о приоритетах. Но когда конфликт становится

между людьми

, его нужно гасить быстро, иначе

он начинает разрушать команду изнутри

😕

💬А у вас были такие ситуации в проектах, когда конфликт из рабочего вдруг становился личным? Делитесь своим опытом в комментариях❤️

#базаPM

🤐Почему команда перестаёт говорить ПМу правду

Есть момент, который почти всегда пропускают.

Сначала команда делится всем: говорит о проблемах, предупреждает о рисках, честно говорит, что не успевает, спорит и предлагает решения🤓

Но проходит время, и что-то меняется…

Команда начинает говорить:

⭕️ «всё нормально»
⭕️ «сделаем»
⭕️ «почти готово»
⭕️ «да, успеем»

А потом внезапно выясняется, что сроки горят, задача сделана не так, проблема тянется уже неделю…

👉

И ПМ думает:

«почему мне не сказали раньше?»

Но правда в том, что команда редко начинает молчать просто так. Обычно это происходит по одной из трёх причин:

1️⃣Реакция ПМа на плохие новости

Если на проблемы команда получает раздражение, давление,«почему так долго?», «надо было раньше думать, то люди быстро понимают, что проще сказать «всё ок», даже если это не так🥲

2️⃣Бессмысленность честности

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

И появляется логика: «зачем говорить, если всё равно ничего не поменяется?»🫠

3️⃣Перегруз контроля

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

В какой-то момент люди начинают

прятать проблемы

, чтобы не тратить силы на лишние объяснения.

И тогда появляется самая опасная ситуация в проекте. Когда команда говорит ПМу

не реальность, а то, что он хочет услышать.

А в этот момент управление проектом фактически исчезает, потому что решения принимаются на основе неправильной картины проекта.

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

Ставьте «🔥», если считаете, что это действительно важная проблема в работе ПМа

#базаPM

Друзья, сейчас вокруг Telegram происходит множество непоняток… и есть риск, что в какой-то момент канал может стать нестабильным или вообще недоступным😵

Поэтому думаю заранее, куда переносить контент, если вдруг что.

Хочется понять, где вам реально удобно потреблять контент.
Ответьте, пожалуйста, в опросе ниже, это поможет не потерять вас🥲

🤯Как управлять проектами в неопределённости: 3 рабочих лайфхака

Последние события показывают одну простую вещь: даже если у тебя всё было стабильно, это может поменяться очень быстро🙂

⏩Платформы, доступы, процесс — всё может стать «под вопросом» за один день.

И это, на самом деле, максимально честная среда для ПМа, потому что проекты почти всегда живут в неопределённости, просто не всегда в такой явной.

👉3 вещи, которые реально помогают не развалиться в таких условиях:

1️⃣Не пытайся всё зафиксировать

Главная ошибка — начать судорожно всё планировать и «закрывать», но в неопределённости это не работает.

Пока ты фиксируешь, требования меняются, приоритеты уезжают, а решения устаревают🥲

❗️

Рабочий подход —

сокращать горизонт планирования

.

Планируй не «на квартал», а на неделю, спринт или на ближайший результат

2️⃣Принимай решения быстрее, чем становится комфортно

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

❗️

Лучшее правило:

решение лучше среднего сейчас, чем идеальное потом

Да, иногда придётся переделывать, но это дешевле, чем стоять на месте.

3️⃣Управляй не задачами, а ожиданиями

Когда всё нестабильно, люди больше всего бесятся не из-за задач, а из-за того, что не понимают, что происходит, не знают, чего ждать, не уверены в сроках.

❗️

Поэтому

задача ПМа

чаще синкаться, проговаривать риски, не обещать то, в чём не уверен

Честность в неопределённости — это не слабость, а способ сохранить контроль.

📌Самое важное:

Неопределенность — это не исключение, а нормальное состояние проекта. И выигрывает не тот ПМ, у кого идеальный план, а тот, кто быстрее адаптируется.

А как у вас сейчас с проектами?
Ставьте «🔥», если стало больше хаоса и «❤️», если всё под контролем

#базаPM

5️⃣ типов неопределённости, которые ломают проекты (и что с ними делать)

Когда говорят «в проекте неопределённость» — это звучит как что-то общее. Но на практике неопределённость всегда конкретная.

И если её не распознать, ты не сможешь ею управлять.🙅🏼‍♂️

⏩Какие же типы неопределенности убивают проекты?

1️⃣Неопределённость требований

Классика:
⭕️«давайте начнём, потом уточним»
⭕️«примерно понятно, что нужно»

В итоге:
⚫️переделки
⚫️конфликты
⚫️потеря времени

👉Что делать:
не начинать разработку без Definition of Ready и фиксировать, что именно считается “готово к работе”

2️⃣Неопределённость приоритетов

Сегодня важно одно, а завтра — другое.

Команда делает → приоритет меняется → работа обесценивается…

👉Что делать:
фиксировать приоритеты хотя бы на короткий период (спринт/неделя) и не трогать их без причины

3️⃣Неопределённость решений

Когда решения не принимаются, откладываются, пересматриваются по 3 раза, проект начинает зависать.

👉Что делать:
вводить правило: каждое решение имеет дедлайн и ответственного

4️⃣Неопределённость загрузки команды

Снаружи кажется, что все заняты, а на деле кто-то перегружен, кто-то недогружен, сроки плавают

👉Что делать:
считать реальный capacity, а не «на глаз»

5️⃣Неопределённость ожиданий - самая опасная

Когда команда думает одно, а заказчик ожидает другое. И это выясняется в конце…

👉Что делать:
регулярно синхронизировать ожидания:
— демо
— промежуточные проверки
— частая обратная связь

💡Важно:

Неопределённость нельзя убрать, но её можно разделить и начать управлять частями, потому что «хаос» — это не проблема.

Проблема — когда ты не понимаешь, какой именно хаос у тебя сейчас.

Какой тип чаще всего встречается у вас?
Напишите цифру в комментариях👇

#базаPM

🤔Как принимать решения, когда данных нет

Спойлер:
так происходит почти всегда...

Редко бывает ситуация, когда у тебя есть все цифры, подтверждённые гипотезы, понятный прогноз🥲

Чаще всего ты принимаешь решения в режиме: «ну… вроде так логично»

И вот тут многие ПМы начинают тормозить. Они ждут больше данных, подтверждений, время на «еще чуть-чуть разобраться»

⏩Но в этот момент происходит главное: решение не принимается → проект останавливается

Вот как с этим работать:

1️⃣Правило 70% информации

Если у тебя есть хотя бы 60–70% понимания, уже можно принимать решение. Остальное ты всё равно не узнаешь заранее.

А цена ожидания почти всегда выше, чем цена ошибки.

2️⃣Делай решения обратимыми

Не надо искать идеальное решение. Надо понять:

👉если это окажется ошибкой, насколько больно будет откатиться?

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

3️⃣Проговаривай уровень уверенности

Одна из самых сильных вещей, которые может делать ПМ: говорить не только решение, но и контекст.

Например:
⭕️«решаем так, но данных мало»
⭕️«это гипотеза, проверяем»
⭕️«можем пересмотреть через неделю»

Это снижает ожидания и убирает ощущение «нас куда-то ведут вслепую».

⏩

Самое важное:

Проблема не в том, что ты ошибёшься, а в том, что ты

слишком долго не принимаешь решение.

В проектах выигрывает не тот, кто всегда прав, а тот, кто быстрее двигается, быстрее проверяет, быстрее корректируется

А для вас что сложнее: принять решение или потом за него отвечать?
«❤️» - принять решение
«🔥» - отвечать за него

#базаPM

📌Немного организационного

В связи с последними событиями я решил не рисковать и заранее подумать, где будем на связи, если вдруг что. По результату опроса большинство выбрало ВКонтакте. Спасибо всем, кто ответил ❤️

👉Уже создал сообщество и начинаю по-тихоньку его развивать. Пока всё просто: дублирую туда контент отсюда, чтобы вы ничего не потеряли.

Дальше будем:
⭕️настраивать оформление
⭕️тестировать форматы
⭕️смотреть, как удобнее вам потреблять контент

Если вы читаете здесь, лучше сразу подпишитесь и туда, чтобы не потеряться, потому что сейчас стабильность — вещь относительная🥲

Я понимаю, что многим из вас удобнее читать здесь, буду вести до последнего контент и здесь, пока это возможно❤️