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

Ниже — практики, которые я подсмотрела у техлидов и продуктовых команд. Это не попытка «учить» разработчиков тому, что они и так знают лучше меня. Скорее, я описываю опыт со стороны — как человек, который постоянно учится у них дисциплине управления временем.

Буду рада комментариям: так ли это работает внутри ваших команд.

1. Принцип «без повестки — нет созвона»

Самое очевидное, и при этом самое неочевидное правило для маркетинговых команд (ведь у нас много креатива). Но у техлидов это — жёсткий стандарт.

Повестка — это не абстрактная формальность. Это список вопр��сов, на которые нужно дать ответ. Не «поговорить», а закрыть неопределённость.

У хорошей повестки есть три свойства:

• конкретные вопросы,

• ожидаемые решения,

• кто должен что подготовить до встречи.

От разработчиков я услышала фразу, ставшую для меня рабочим правилом:

«Если я прихожу на митинг и не понимаю, какая от меня нужна информация, значит митинг организован плохо».

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

2. Асинхронность как дефолт, а не «опция для интровертов»

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

У техлидов другой подход: если вопрос можно решить письменно — он должен быть решён письменно.

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

Письменное обсуждение удобно, потому что:

• информация фиксируется,

• решения легко пересматривать,

• никто не возвращается к одному и тому же по кругу,

• люди могут отвечать, когда им удобно.

Это особенно ценно в международных командах, где время не совпадает. Маркетингу этот подход тоже подошёл бы идеально — но требуется дисциплина. Лично я заменила дейлики в звонках на письменный дейли – у нас нет капасити каждый день встречаться даже на 15 мин, у нас гибкий график и разные часовые пояса, но есть промежуток времени по Берлину, когда каждый должен прислать свой дейли. Все видят задачи, прогресс друг друга, а я вижу, что под контролем.

3. «Подготовка — 50% успеха» (и это не метафора)

В IT есть культура подготовки: если человек идёт на встречу, он приходит с артефактами — схемами, логами, диаграммами, примерами, скриншотами, вариантами архитектуры.

В маркетинге (и не только там) часто происходят созвоны, на которых обсуждается то, что можно было собрать заранее за 10 минут.

Один техлид сказал мне:

«Худшее, что может сделать организатор митинга — прийти с чистым экраном и ожиданием, что команда сейчас что-то родит».

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

Это хорошая практика — и она невероятно экономит время.

4. Таймбоксы, которые реально работают

Таймбокс — стандартный приём, но я впервые увидела его по-настоящему работающим именно у разработчиков.

Особенно у техлидов, которые ведут несколько команд.

Как это выглядит:

• встреча длится ровно 30 минут,

• обсуждается не больше трёх вопросов,

• перед началом оговариваются критерии успешности (возвращаемся снов к пункту 1).

Если вопрос не решён — он отправляется обратно в письменно-асинхронный формат.

Это экономит не только время, но и внимание команды: встречи становятся не «местом для разговора», а местом для принятия решения.

5. Ритуалы, которые стабилизируют хаос

Разработчики обожают ритуалы — короткие повторяющиеся процессы, которые делают работу предсказуемой. Не только стендапы, но и:

• дизайн-ревью,

• техревью,

• грумминги,

• ретро.

Но важное наблюдение: хорошие команды никогда не делают ритуалы ради ритуалов.

Если встреча перестала давать пользу — она сокращается, меняется или отменяется.

В маркетинге часто бывает обратное — повторяющийся ритуал никто не пересматривает годами (это то, что называется у нас «маркетинговый долг»).

Ритуалы дают структурность. Но лучшие команды постоянно обновляют их под реальность, а не под идеальную методологию.

6. Чёткие роли: кто отвечает за что на встрече

У техлидов я подсмотрела простое правило:

• есть host — человек, который отвечает за цель и тайминг,

• есть владельцы вопросов,

• есть те, кто принимает решения,

• есть те, кто просто информируется письменно.

Если человеку не нужна встреча — его на неё не зовут. Это кажется очевидным, но в реальности редко работает. У нас бывало так, что меня звали на встречи, потому что я руководитель отдела, но это не были встречи FYI, это были встречи-обсуждения моментов, которые меня не касаются, я просто сидела по 2 часа и думала «что я здесь делаю». Мы это изменили.

Что менеджерам (любым — не только маркетинговым) стоит взять из этого

• Уважение к времени людей — как ресурс, который нельзя тратить впустую.

• Переход в асинхронность по умолчанию — заметно снижает хаос.

• Готовность отменять встречи, если они перестали выполнять функцию.

• Понимание, что встреча — это инструмент, а не ритуал.

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

Если у вас есть примеры того, как вы сокращали созвоны или переводили работу в асинхронность — буду признательна, если поделитесь наблюдениями.

Хочу лучше понять, как это устроено внутри разных технических команд.