Я не инженер и не продуктовый менеджер. Я продолжаю работать в маркетинге как проектный менеджер и остаюсь скорее гуманитарием, но после переезда в Европу в моём окружении стало много специалистов из IT. Я наблюдаю, как они организуют работу, ведут проекты, договариваются о задачах — и многое из этого оказалось неожиданно практичным, рациональным и универсальным.
Ниже — практики, которые я подсмотрела у техлидов и продуктовых команд. Это не попытка «учить» разработчиков тому, что они и так знают лучше меня. Скорее, я описываю опыт со стороны — как человек, который постоянно учится у них дисциплине управления временем.
Буду рада комментариям: так ли это работает внутри ваших команд.
1. Принцип «без повестки — нет созвона»
Самое очевидное, и при этом самое неочевидное правило для маркетинговых команд (ведь у нас много креатива). Но у техлидов это — жёсткий стандарт.
Повестка — это не абстрактная формальность. Это список вопросов, на которые нужно дать ответ. Не «поговорить», а закрыть неопределённость.
У хорошей повестки есть три свойства:
конкретные вопросы,
ожидаемые решения,
кто должен что подготовить до встречи.
От разработчиков я услышала фразу, ставшую для меня рабочим правилом:
«Если я прихожу на митинг и не понимаю, какая от меня нужна информация, значит митинг организован плохо».
В маркетинге большинство встреч рушатся как раз на этом этапе — никто толком не знает, что является результатом (поэтому в своей команде я всегда пишу агенду и то, что мы должны получить в итоге встречи).
2. Асинхронность как дефолт, а не «опция для интровертов»
Во многих командах непрерывный поток встреч — это следствие старой управленческой инерции: если вопрос есть, нужно собраться.
У техлидов другой подход: если вопрос можно решить письменно — он должен быть решён письменно.
Асинхронность экономит время, но важнее другое: она оставляет людям непрерывные блоки работы, которые особенно важны разработчикам, пишущим код, или аналитикам, погружённым в задачу.
Письменное обсуждение удобно, потому что:
информация фиксируется,
решения легко пересматривать,
никто не возвращается к одному и тому же по кругу,
люди могут отвечать, когда им удобно.
Это особенно ценно в международных командах, где время не совпадает. Маркетингу этот подход тоже подошёл бы идеально — но требуется дисциплина. Лично я заменила дейлики в звонках на письменный дейли – у нас нет капасити каждый день встречаться даже на 15 мин, у нас гибкий график и разные часовые пояса, но есть промежуток времени по Берлину, когда каждый должен прислать свой дейли. Все видят задачи, прогресс друг друга, а я вижу, что под контролем.
3. «Подготовка — 50% успеха» (и это не метафора)
В IT есть культура подготовки: если человек идёт на встречу, он приходит с артефактами — схемами, логами, диаграммами, примерами, скриншотами, вариантами архитектуры.
В маркетинге (и не только там) часто происходят созвоны, на которых обсуждается то, что можно было собрать заранее за 10 минут.
Один техлид сказал мне:
«Худшее, что может сделать организатор митинга — прийти с чистым экраном и ожиданием, что команда сейчас что-то родит».
Поэтому перед встречей в IT обычно происходит работа, а не после. На маркетинговых встречах всё наоборот: вопрос формулируется только «вживую».
Это хорошая практика — и она невероятно экономит время.
4. Таймбоксы, которые реально работают
Таймбокс — стандартный приём, но я впервые увидела его по-настоящему работающим именно у разработчиков.
Особенно у техлидов, которые ведут несколько команд.
Как это выглядит:
встреча длится ровно 30 минут,
обсуждается не больше трёх вопросов,
перед началом оговариваются критерии успешности (возвращаемся снов к пункту 1).
Если вопрос не решён — он отправляется обратно в письменно-асинхронный формат.
Это экономит не только время, но и внимание команды: встречи становятся не «местом для разговора», а местом для принятия решения.
5. Ритуалы, которые стабилизируют хаос
Разработчики обожают ритуалы — короткие повторяющиеся процессы, которые делают работу предсказуемой. Не только стендапы, но и:
дизайн-ревью,
техревью,
грумминги,
ретро.
Но важное наблюдение: хорошие команды никогда не делают ритуалы ради ритуалов.
Если встреча перестала давать пользу — она сокращается, меняется или отменяется.
В маркетинге часто бывает обратное — повторяющийся ритуал никто не пересматривает годами (это то, что называется у нас «маркетинговый долг»).
Ритуалы дают структурность. Но лучшие команды постоянно обновляют их под реальность, а не под идеальную методологию.
6. Чёткие роли: кто отвечает за что на встрече
У техлидов я подсмотрела простое правило:
есть host — человек, который отвечает за цель и тайминг,
есть владельцы вопросов,
есть те, кто принимает решения,
есть те, кто просто информируется письменно.
Если человеку не нужна встреча — его на неё не зовут. Это кажется очевидным, но в реальности редко работает. У нас бывало так, что меня звали на встречи, потому что я руководитель отдела, но это не были встречи FYI, это были встречи-обсуждения моментов, которые меня не касаются, я просто сидела по 2 часа и думала «что я здесь делаю». Мы это изменили.
Что менеджерам (любым — не только маркетинговым) стоит взять из этого
Уважение к времени людей — как ресурс, который нельзя тратить впустую.
Переход в асинхронность по умолчанию — заметно снижает хаос.
Готовность отменять встречи, если они перестали выполнять функцию.
Понимание, что встреча — это инструмент, а не ритуал.
Мы привыкли считать, что проблемы бесконечных митингов — это следствие слабого менеджмента или просто онлайн-среды. Но я всё чаще вижу другое: правильная инженерная культура способна спасать команды гораздо эффективнее любых методологий.
Если у вас есть примеры того, как вы сокращали созвоны или переводили работу в асинхронность — буду признательна, если поделитесь наблюдениями.
Хочу лучше понять, как это устроено внутри разных технических команд.
Комментарии (19)
dimonier
26.11.2025 15:25Горячо поддерживаю всё написанное!
Но, как мне кажется, эти правила применяют не только ИТ-лиды, но и все люди, ценящие своё и чужое время и рационально его расходующие.
joueslin
26.11.2025 15:25Работаю в большом российском банке.
Все красиво написано, но все это не работает, если в организации "все занимаются всем". Сам, когда пришел, был удивлен, почему по 10-30 человек мигрируют из одного совещания в другое ... ставишь встречу на 5-7 человек, идет форвард - приходит 15 :) ... Причины: процессы прописаны, но само руководство их игнорирует; поощеряется формат постоянного тушения пожаров; все работают в постоянной неопределенности, но (!) с точными сроками, когда задача должна быть выполнена (сам кдивляюсь как, но работает подход). И так как зп в организации хорошие и расставаться с местом никто не желает, много коллег мигрируют по встречам - одни пытаются дать ответ на вопрос, как эта встреча поможет в решении его задачи, другие - как ничего не делать, получив информацию на этой встрече (первых 20%, вторых - 80%, так и живем. Причина - за идею можно и поплатиться, стать ответсвенным за ее реализацию в кратчайшие сроки с минимальным бюджетом, следовательно, коллеги держат язык за зубами и встреча аналитиков-технологов проходит так, что РП вещает, а эксперты... молчат).
Повторю, написано красиво, но если формат не самых эффективных встреч спускается "сверху", то тема не работает.
elizabeth_yy Автор
26.11.2025 15:25Спасибо, что поделились контекстом - это очень узнаваемая ситуация для крупных структур (моя коллега-проджект как раз ушла из "первого" банка рф по описанной вами причине). Полностью согласна: если культура «таскаем всех на всё» и вечного пожаротушения спускается сверху, то никакие правила про асинхронность не приживутся.
Моя статья про локальные практики, которые помогают командам хотя бы частично снизить хаос, когда у них есть пространство что-то менять.
И вы правильно пишете: в компаниях, где инициативность наказывается ответственностью «за всё и сразу», люди естественно выбирают молчание и пассивность. Это вопрос не встреч, а организационной культуры.
Спасибо за развернутый комментарий - такие примеры как раз помогают показать, почему тема сложная и не сводится к чек-листу :)
Tihon_l
26.11.2025 15:25Отлично написано) хочется верить, что со временем уважение к чужому времени станет реальностью
Созвон/совещание ради совещания - вообще обычная история в гос и окологос компаниях. Сколько же человеко-часов теряется в масштабах страны, ужас...
Yankee2d
26.11.2025 15:25Да вы прикалываетесь?
Господа менеджеры с двумя классами образования, вам не в техлидов учиться надо, а идти принимать заказы на гамбургеры. Умение организовывать работу это на целое образование.
Эта статья для кого? По принципам этой же статьи? Для тех менеджеров, которые элементарных вещей не понимают?
Тогда пункт 1. - увольняйтесь и не мешайте работать.
Или вы этой статьёй хотите помочь «людям с особенностями в развитии» подольше удерживаться на месте, которое они занимают по чистой случайности?
elizabeth_yy Автор
26.11.2025 15:25Спасибо за комментарий. Я как раз и написала в статье, что не учу инженеров (у меня другой профиль и другое образование, и слава богу, не 2 класса) — я описываю то, чему сама у них учусь. И если для вас это базовые вещи — отлично, значит вы работаете в зрелой культуре. Но у многих команд с этим всё ещё сложно, и именно им такие материалы часто помогают.
Yankee2d
26.11.2025 15:25Вы совершенно правильно описали практику. Я отвечал на другое - у вас прямо в заголовке статьи "как спасать команду от бесконечных митингов". Кто вообще вводит эту практику бесконечных митингов? Именно менеджеры, которые никогда не учились менеджменту, которые "чайка-менеджеры" и вместо помощи в работе и её организации создают ИБД (имитацию бурной деятельности).
К сожалению, "зрелой культуры" сейчас мало где найдёшь. Проблема некомпетентного менеджмента повсеместно.
А на вопрос "как спасать команду от бесконечных митингов" находится совсем в другой плоскости. Если эти митинги организуете вы (не лично вы, не принимайте на свой счёт), то тогда вам не место в менеджменте и нужно пойти подтянуть базу, понять, что проект это время-ресурсы-качество и т.д. По-любому такого менеджера нужно увольнять из проекта, а не учить агенду на митинг писать. Если он не понимает базы, ну научите вы его писать агенду и записывать результаты, но у него пробелы глобальные.
А вот если на своём месте вы всё понимаете, но эти бесконечные ВКС собирают люди повыше типа заказчиков, руководителей и т.д. и приглашают на них по 25 человек, включая разработчиков, тогда это, к сожалению, вопрос из области психотерапии и принятия, ибо уволить своего руководителя и заказчика вы не можете. Тогда вам нужно "лавировать", освобождать своих подчинённых от этих звонков, доносить организаторам, что присутствие всей вашей команды на ВКС это бездарная трата ресурса. И, к сожалению, очень не редко это встречается в штыки этими людьми. Опять по той же причине, что управлять они не умеют, написать письмо, где кратко объяснить суть они не умеют. Им нужно собрать большую конференцию, пятнадцать раз одно и то же проговорить разными способами, услышать вопросы, которые их направят в нужное русло и они родят то, что забыли упомянуть и после этого пойдут домой успокоенными, что "вроде донесли до команды". Хотя на самом деле им нужно было просто сесть и написать документ. Но они просто не умеют формулировать.
malkovsky
26.11.2025 15:25Мне кажется, что здесь еще косвенно затрагивается проблема микроменеджмента. В период онбоардинга считается нормальным буквально за ручку провести нового человека, особенно если это вчерашний выпускник, но если после начального периода менеджер продолжает влезать в рутину работы подчинённого, то чаще всего проблема в менеджере, а не в подчинённом, если вы у вас не получается делегировать задачи так, чтобы ваш подчинённый делал их самостоятельно, то либо вы плохо формулируете задачи, либо задачи слишком сложные и вы должны были об этом знать до того как их выдавать. Кажется, что часто излишние созвоны мотивируются именно микроменеджментом.
elizabeth_yy Автор
26.11.2025 15:25Вот прямо подписываюсь под вашими словами! Это 100% так, в какой компании бы ни видела такие "созвоны, чтобы согласовать повестку на созвон" - всегда есть большая проблема микроменеджмента.
marketer_ths
26.11.2025 15:25Ввела в рутину созвоны по понедельникам и пятницам. И мне и команде комфортнее стало работать. В понедельник разбираем статистику за выходные и сверяемся с планами на неделю, в пятницу — подводим итог по закрытым задачам. Уходим на выходные спокойно, без "хвостов"
elizabeth_yy Автор
26.11.2025 15:25Лайк! У меня тоже стоят weekly по понедельникам, daily текстовые каждый день, а вот про пятницу я тоже все думаю и думаю, как будто бы для логики их не хватает, обсудить планирую с командой на декабрьском ретро и предложить их тоже добавить, но только если всем покажется необходимость.
sibirrr
26.11.2025 15:25Самая нормальная пратика - нет повестки с конкретными решениями, значит нет митинга. Письменный дейли в Slack по шаблону 3 строки и всё, никто не ноет. В итоге созвонов станет втрое меньше, а работа идёт быстрее
joseph-cansas
Слово "митинг" имеет другое значение в русском языке, поищите в словарях. Здесь же уместно "собрание" или "совещание".
elizabeth_yy Автор
В профессиональной среде (особенно в IT) слово давно закрепилось как калька от meeting. В статье я использовала его в этом устоявшемся контексте, чтобы сохранить привычную терминологию, на которой говорю и сама в обиходе.
joseph-cansas
в обиходе можно говорить как душа пожелает. (Кстати, что мешает в обиходе называть как это принято для языка и культуры в целом? Я лично не вижу проблем. и работал в коллективе, где даже некоторые заимствования в русском языке не принимались, "морковный", а не "оранжевый"). Но в статьях надо писать как положено по нормам языка. В промышленной среде, где я вращаюсь, очень много чего называется через матерные и/или "черные" слова. Но всем хватает ума писать как положено, в соответствии с нормами языка и официальной терминологии.
Я не критикую Вашу статью, она неплохая. Но англицизмы не украшают язык, а портят.
elizabeth_yy Автор
В рабочих процессах митинг - это не синоним «совещания» или «собрания». Это конкретный формат: синхронная встреча с узкой целью, структурой, ролями и временем. В Agile-, продуктовых и инженерных командах слово закрепилось как термин, в том числе в русскоязычных компаниях.
Если заменить термин на «совещание», смысл и контекст исказятся - как если вместо «бэклога» писать «список задач», или вместо «дедлайна» — «крайний срок». Формально возможно, по сути - нет. Кстати, даже в ГОСТах зафиксированы десятки англицизмов как заимствования именно потому, что они стали частью профессионального языка и обеспечивают точность коммуникации.
Я сознательно использовала профессиональный термин так, как он используется командами в реальной практике.
Но спасибо за обсуждение, о русском языке я тоже могу говорить долго (я его люблю всей душой), просто не здесь — в данном случае «митинг» выбран не ради моды, а ради точности.
joseph-cansas
а чем "летучка" не угодила?
Это и мой языковой пуризм и более сложная вещь, как ключ к умам и сердцам. Я владею комплексом методов, которые позволяют писать инструкции и учебные материалы с усвоением на 80% с первого прочтения. Родной язык и относительно строгое следование его правилам дают такую вещь, как объяснять сложное просто. Русские слова длиннее, тексты, переведенные с английского, становятся длиннее. И, например, инструкции ТБ хуже воспринимаются и усваиваются (я с этим сталкивался). Но русской культурой выработано и решение этой проблемы. Наиболее близко это объясняется принципом Барбары Минто в сочетании с методами Норы Галь (из книги "слово живое и мертвое"). Для английского языка это не критично. Но для русского и казахского языков это важно /казахские тексты в переводе с русского еще длиннее/
martopt
Автор же достаточно подробно объяснил, почему именно митинг, а не летучка, планерка, собрание, совещание и т.д. Дело в том, что именно термин "мининг" закрепился в профессиональном сообществе. Чего вы тут решили задушнить автора на эту тему не вполне ясно. У нас в языке огромное количество заимствований, как и в любом другом языке, это абсолютно нормально, но вас, кажется, это чем-то задевает.
StraNNicK
Простите, но "летучка" — точно такой же жаргонизм, как и "митинг".
И то, что он используется дольше, не делает его частью языка.
Раз вы выступаете за языковой пуризм — будьте последовательны.