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

Project Manager - это и есть тот, кто следит, чтобы кровь текла, но не превращалась в хаотичные внутренние кровотечения. 90% времени PM уходит на то, чтобы слушать, говорить, писать, уточнять, напоминать и фиксировать. Если вы думаете, что работа PM - это «планировать», то сюрприз: план без правильной коммуникации так и останется красивой табличкой в Excel.

1. Где PM общается: каналы и их особенности

 

Короткие митинги (15 минут)

Это операционные встречи, которые нужны, чтобы команда «сверила часы» и быстро сняла блокеры.
- Пример: daily stand-up в Scrum.
- Формат: каждый отвечает на три вопроса:

1. Что сделал вчера?
2. Что планирую сегодня?
3. Что мешает?

Почему 15 минут: это не дискуссия, а обмен статусами. Если начинают обсуждать детали - выносят в отдельный разговор.

Такие митинги - как экспресс-зарядка: быстро пробежались по проекту и побежали работать.

Средние митинги (30–45 минут)

Это тематические обсуждения, где нужно реально разобраться в проблеме.
- Пример: разбор багов, планирование следующего спринта, уточнение требований по фиче.
- Формат: повестка + назначенный модератор (обычно PM).
- Почему до 45 минут: за это время можно обсудить несколько задач, но внимание людей ещё не упало.

Длинные митинги (до 1 часа и чуть больше)

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

Чаты

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

Минусы:
- шум,
- потеря информации,
- бесконечные нотификации, которые мешают работать.

Правила выживания в чатах

1. Суть → детали → эмоции.
   Пиши по формуле: «Что нужно → контекст → спасибо/смайлы».

   • Плохо: «Привет! Как дела? Слушай, а можешь посмотреть баг?»

   • Хорошо: «Нужно проверить баг в форме регистрации: при вводе email падает ошибка. [скриншот] Спасибо!»

2. Тематика и каналы.
   Один чат = одна цель.

• «Dev-chat» для обсуждения кода,
• «Design-chat» для макетов,
• «General» для мемов и корпоративных фоточек.
  Если всё смешано - найдётся момент, когда баг потеряется между котиками и гифками.

1. Теги и треды.
   В Slack и Discord можно использовать треды, в Telegram @упоминания. Это помогает не утонуть в потоке.

2. Async vs. sync.
   Чат - не всегда про «срочно отвечай». Если вопрос требует обдумывания, лучше вынести его в письмо или задачу. Ошибка PM пытаться решать всё «здесь и сейчас», из-за этого люди отвлекаются и теряют фокус.

3. Документы vs. чаты.
   Никогда не фиксируй важные решения только в чате. Это как писать договор на салфетке: удобно, но потом не докажешь. После договорённости всегда «подшивай» результат в задачу или документ.

4. Шум и «пустые сообщения».

• Сообщения «Привет» без сути — зло: человек видит нотификацию, отвлекается, а сути ещё нет.
• Лучше сразу писать полное сообщение.
• Если уж начал с «Привет», добавь сразу основное: «Привет! Нужно обсудить перенос дедлайна».

Этикет.

• Не злоупотребляй @all или @channel.
• Пиши время ожидания: «Нужно проверить баг до конца дня».
• Если пишешь вечером или в выходной — не расчитывай на быстрый ответ.

Реальный кейс

В одной команде когда я был разработчиком наш тестер писал всё в общий чат: баги, идеи, шутки, мемы. Через месяц я перестал туда заходить по причине «слишком шумно». В итоге баги оставались без внимания. Решение которое мы ввели: завели отдельный «Bug-report chat» и правило: если баг не задокументирован в Jira - его не существует. Через пару недель хаос исчез.

Письма

Почему письма до сих пор важны

• Юридический след. Если клиент через месяц скажет: «Мы такого не обсуждали», именно письмо станет твоим щитом. Скрин из чата можно подделать, а письмо в корпоративной системе - куда сложнее.
• Формальность и вес. Письмо воспринимается серьёзнее, чем сообщение в Telegram. Для инвестора или заказчика это «официальный канал».
• Структура. В письмах принято писать длиннее и обстоятельнее. Это удобно для историй, отчётов, инструкций.

Правила выживания в почте:

1. TL;DR сверху. Первое предложение должно отвечать на вопрос «о чём письмо». Например: «Мы договорились о переносе дедлайна на 15 сентября». А потом уже детали.
2. Одна тема = одно письмо. Не смешивай баг-репорт и бюджет в одном письме. Иначе никто потом не найдёт.
3. Цепочки и заголовки. Не ленись менять тему письма. «Re: Re: Re: Fwd» - ад. Лучше: «Проект X Перенос дедлайна».
4. Сроки и ответственность. Чётко формулируй: «Иван, жду от тебя документ до среды». Без этого письмо превращается в «прочитал и забыл».

Реальный кейс
Однажды  мы с клиентом договорился о сдвиге дедлайна в телеге. Клиент согласился выслав смайлик 👍. Через пару недель клиент сказал: «Я ничего не подтверждал». Я показал переписку в телеге, но заказчик сказал: «Я случайно кликнул смайлик». В итоге я не смог ничего доказать и мы сработали в минус по этому проекту. С тех пор все договорённости закрепляли письмом по почте.

Доски задач

Почему они критичны

• Видимость. Вся команда видит, кто что делает.
• История. Легко отследить, кто и когда что поменял.
• Фокус. Без доски проект живёт в головах и чатах, а значит - обречён на хаос и возможную смерть.

Правила работы с доской:

1. Нет задачи на доске - задачи не существует. Это должно быть правило №1. Даже если договорились в коридоре - всё равно завести тикет необходимо.
2. Доска = не свалка. Следи, чтобы там не было сотни «зависших» карточек. Иначе инструмент теряет доверие.
3. Прозрачность. Каждый тикет должен быть понятен любому члену команды: заголовок, описание, приоритет.
4. Обновления. Тикеты должны быть актуальными. «В работе» — значит реально в работе, а не «завёл и забыл».
5. Разграничение. Разделяй баги, фичи, исследования. Пусть у них будут разные колонки или теги/метки.

Реальный кейс

Когда-то мы купили финтех-проект вместе с командой, какое-то время шли споры, в каком виде его запускать и куда двигать. Пока обсуждали стратегию, команда не сидела без дела: фичи пилились, баги чинились, но всё обсуждалось только в чатах. И вот настал момент X: стратегию утвердили, решили провести ревизию проекта, что реально готово к релизу? На простом вопросе «Какие фичи закончены?» команда зависла: у каждого была своя версия. Когда все задачи пересоздали в Jira, картина стала ясной: 40% задач в работе, 30% повисли «ни туда ни сюда», ещё 30% даже не начинали. Только после этого стало понятно, где проект на самом деле стоит и сколько сил нужно для выхода в прод.