Долгих дней и приятных ночей! В каждой IT-команде есть свой "хранитель стандартов" — тот, кто знает, сколько пробелов должно быть перед комментарием. Но что происходит, когда перфекционизм начинает мешать работе?
Я Наталия Курченкова, за 10+ лет в IT видела много команд, но эта история запомнилась особенно. Наш тимлид автотестов мог по памяти найти любой баг, но... забыл про релиз на 3 недели. Клиент, к счастью, тоже не заметил, но этот случай заставил нас пересмотреть всю систему работы.
Что вы узнаете из статьи:
- Как 10 итераций code review по поводу запятых убивали мотивацию
- Почему самый техничный лидер может быть неэффективным менеджером
- 3 конкретных изменения, которые дали улучшили ситуацию
- Как метод Адизеса помог найти баланс
Вступление: Как перфекционизм сорвал наш релиз
Эта история произошла около 10 лет назад. Наша команда автотестирования мобильного приложения (iOS/Android) была стандартной для многих компаний - опытный тимлид с глубокими техническими знаниями и группа джунов, осваивающих автоматизацию. Тимлид, работавший на проекте более 4 лет, мог найти решение любой технической проблемы, идеально знал код проекта и всегда был готов помочь. Клиент был очень лояльный, проблем не знали, пока на одном из статусных созвонов одна из джунов осторожно не сказала "мы три недели назад должны были сдать релиз...". Клиент тоже забыл про релиз, на первый раз нас это спасло, но допустить повторения было нельзя. Тут мы стали разбираться в причинах задержки.
Несколько откровенных 1-1, проведенных между джунами с менеджером выявил следующее:
- Code review проводились в 5-10 итераций — правка орфографии и пунктуации комментариев, форматирования кода, занимала больше времени, чем обсуждение логики и работоспособности тестов
- Скорость разработки страдала — новички боялись отправлять свои пул-реквесты, ожидая десятков замечаний по оформлению. Стоит отметить, что у нас тогда не было настроено автоматического форматирования, а для расстановки отступов были введены правила, прописанные в confluence.
- Важные сроки пропускались — тот случай с забытым на 3 недели релизом оказался не единственным, а первым критичным
При этом команда любила своего лидера — он был терпеливым, всегда готовым объяснить, никогда не повышал голос. Но проблема была налицо.
Разбираем ситуацию через призму PAEI
Напомню, методология Ицхака Адизеса выделяет 4 ключевые роли эффективного менеджмента:
P (Производитель)
- Фокус: достижение результатов
- Проблема в нашем случае: релизы пропускались, приоритеты расставлялись неверно
A (Администратор)
- Фокус: процессы и порядок
- Проблема: гипертрофированное внимание к формальностям в ущерб продуктивности
E (Предприниматель)
- Фокус: инновации и изменения
- Проблема: процессы не развивались годами
I (Интегратор)
- Фокус: командный дух
- Плюс: в нашей команде это было сильной стороной
Диагноз: Явный перекос в сторону A-роли (администрирование) при дефиците P (результаты) и E (развитие). Нужно было снизить градус A и ввести меры, чтобы помочь лиду с результативностью и стратегией.
Цель: наладить ситуацию с минимальными потерями, усилить лида.
План изменений: как мы выравнивали баланс
1. Для тимлида (тренировка P и сбалансировать А):
- Внедрили "правило 80/20 для code review":
Т.е. изначальный фокус на проверку логики и работоспособности, только потом — на оформление (если осталось время) - Назначили "напоминателя о релизах" из числа junior-ов (неожиданно, но это дало им чувство ответственности)
- Провели митап по делегированию — часть review простых задач передали наиболее опытным тестировщикам из команды, ввели дежурных по ревью на каждой платформе.
2. Для процессов (сбалансировать A + показать пример Е):
- Ввели авто-форматирование кода (хочу отметить что этот кейс был около 10 лет назад, и все было не так очевидно)) Теперь джунам не приходилось помнить "сколько отступов надо сделать", а тимлиду освобождалось свободное время на другие задачи, в том числе стратегические.
3. Для команды:
- Запустили ротацию ведущего daily — каждый по очереди вел встречи (тренировка A у всей команды)
- Ввели "правило 2 часов" — если застрял дольше, обязан спросить помощи (тренировка P и А)
Результаты: неожиданные и приятные
Через 3 месяца мы увидели:
- Скорость code review выросла на 60% — теперь средний PR проходил за 1 день вместо 3
- Сроки больше не пропускали. Сработала система напоминаний + ротация ответственности
- Появились инициативы от команды по улучшениям, т.к. явно освободилось время, которое раньше тратилось на выверение и корректировку отступов, стало интереснее и спокойнее работать
- Сам тимлид признался, что стал более продуктивным, не отвлекаясь на мелочи
Главный вывод: Идеальный код - не равно эффективной команда. Баланс между качеством и скоростью, между процессами и результатами — вот что действительно важно. Рекомендую метод Адизеса, т.к. он очень удобный и простой для диагностирования сильных и слабых сторон руководителей, с ним гораздо проще понять куда обратить фокус внимания и продолжить свои исследования.
P.S. Позже наш тимлид иногда даже сам нарушал свои же правила оформления — и мир не рухнул! А код продолжает работать.
#УправлениеКомандами #МетодАдизеса #CodeReview #МобильнаяРазработка #КарьераВIT #ОшибкиМенеджмента