Как перейти от микроменеджмента к контролю, который реально работает

Контроль нередко воспринимается как выбор между двумя крайностями: полной творческой свободой и жестким микроменеджментом. Пространство между ними остается без внимания — хотя именно там рождается успех. Фокус на результатах помогает команде не терять из виду цели, но без надлежащего контроля процессов у нее не будет дисциплины, чтобы довести планы до конца. Это особенно справедливо для команд с большим числом джуниор-инженеров и сотрудников.

Стоит сразу подчеркнуть, что это не микроменеджмент.

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

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

У морских котиков США есть подход, который хорошо соответствует этой идее: поддерживать порядок.

Контроль — это порядок. Это возможность снизить риски, с которыми компания сталкивается на пути к целям, не жертвуя качеством и не доводя команду до выгорания. Это достижимо, когда руководство поддерживает порядок с помощью четких и регулярных процедур, которым следуют все в компании — от джуниоров до топ-менеджмента. Они генерируют данные для анализа и удерживают процессы в нужном русле. Цикл продолжается по мере роста бизнеса.

Данные — ключевой инструмент контроля, который владельцы бизнеса используют для поддержания порядка. В разработке программного обеспечения они называются "базовыми процессами разработки" (BPSD). Это фундаментальные процессы, которые инженерная команда должна выстроить, чтобы регулярно достигать своих целей. Они также предоставляют метрики, доступные для наблюдения любому бизнесу и спонсору проекта. BPSD включают:

• Ежедневные асинхронные стендапы. Короткие письменные отчеты о вчерашних достижениях и сегодняшних планах в групповом чате.
• Ежедневные ворклоги. Ворклоги необходимы для понимания того, куда уходит проектное время и как план команды соотносится с реальностью.
• Использование трекеров. Любая работа ведется в рамках тикета со статусами.
• Связь артефактов с задачами. Код или любой другой артефакт, помещаемый в репозиторий, должен быть связан с номером задачи, над которой велась работа.
• CI/CD и DORA-метрики. Эти меры достаточно строги, чтобы код не попадал в основную ветку без прохождения базовых проверок.
• Ежедневные базовые статус-отчеты. Отправляются в общий канал коммуникации, где инженеры, стейкхолдеры и другие участники команды могут видеть, что было сделано за конкретный день.

Эти процедуры помогают руководству выявлять конкретные области для оптимизации.

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

Микроменеджмент возникает по нескольким причинам:

• Незрелость управленческого персонала.
• Слабая мотивация в команде.
• Незнание правил и границ проекта.
• Различные рабочие культуры среди участников команды.

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

Удаленные команды страдают от микроменеджмента особенно сильно из-за временной и пространственной дистанции между участниками и руководством.

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

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