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

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

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

1. Принцип «нет повестки дня – нет звонка»

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

Вызов – это не абстрактная формальность. Это список вопросов, на которые необходимо ответить. Не «поговорить», а близкая неопределенность.

У хорошего дневника есть три свойства:

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

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

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

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

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

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

2. Асинхронность по умолчанию, а не «вариант для интровертов»

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

У технических менеджеров другой подход: Если вопрос можно решить в письменной форме, он должен быть решен в письменной форме.

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

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

• информация записывается,

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

• никто не ходит туда-сюда по одному и тому же,

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

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

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

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

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

Технический менеджер сказал мне:

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

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

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

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

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

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

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

• встреча проходит хорошо 30 минут,

• мы больше не говорим об этом три вопроса,

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

Если проблема не решена, она возвращается в асинхронном формате записи.

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

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

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

• обзор дизайна,

• техническая экспертиза,

• уход,

• ретро.

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

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

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

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

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

Я заметил простое правило от технических лидов:

• Есть хозяин — лицо, ответственное за цель и сроки,

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

• Есть лица, принимающие решения,

• Есть те, кого просто информируют в письменной форме.

Если кому-то не нужна встреча, его не приглашают. Это кажется очевидным, но на самом деле это редко работает. Были случаи, когда нас вызывали на встречи, потому что я руководитель отдела, но это были не брифинги, а встречи для обсуждения вопросов, которые меня не касались, я просто сидел там 2 часа и думал: «Что я здесь делаю». Мы это изменили.

Чему из этого должны научиться менеджеры (всех типов, а не только те, кто занимается маркетингом)?

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

• Переключиться на асинхронный режим по умолчанию — существенно уменьшает хаос.

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

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

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

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

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