… в потери

Привет! Как вам «тяжелая» теория из прошлых постов?

Сегодня мы разбавим теорию приземленной практикой и поговорим о 20% технического времени — практике, которую мы первым делом внедрили на этапе стабилизации проекта. Разберёмся, зачем оно нужно, какие задачи подходят для этого времени, а какие — категорически нет. И почему важно избегать создания «элитных» команд.

Зачем нужно техническое время?

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

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

Что можно делать в техническое время?

Это время создано для масштабных улучшений, которые меняют правила игры: * автоматизация рутинных процессов (например, настройка CI/CD для ускорения релизов, автоматизация переключения по статусам в Task Management System, автоматизация тестового покрытия и т.д.); * внедрение новых инструментов, которые ускорят разработку в целом (система логирования, стандартизация практик, переиспользуемые компоненты и т.д.); * исследование и пилотирование технологий, способных решить системные проблемы (модуляризация, переход на новый фреймворк); * рефакторинг критически важных модулей, тормозящих несколько продуктовых команд; * разработка внутренних библиотек или компонентов, которые будут переиспользоваться во всех продуктах; * создание инструментов для самодиагностики кода (модульные, скриншот-, интеграционные тесты, линтеры, измерители покрытия кода и т.д.). Такие задачи не дают мгновенного результата в виде новой кнопки в интерфейсе, но меняют скорость и качество разработки в долгосрочной перспективе (Е- и I-функции по Адизесу).

Что нельзя делать в техническое время?

А теперь о запретах — они не менее важны. Техническое время — не повод для: * «эстетического» рефакторинга. Нельзя переписывать код просто потому, что «так красивее» или «я бы сделал иначе». Если это не даёт прироста эффективности — затраты не окупятся. * решения локальных проблем. Исправление багов одной продуктовой команды или доработка функционала конкретного модуля — это задачи спринта продуктовой команды, а не технического времени. Они не масштабируются и не меняют систему в целом. * экспериментов ради экспериментов или собственной «прокачки». Попытка внедрить модную технологию без чёткого понимания её пользы для проекта — пустая трата ресурсов. * задачи с неясным результатом. Например, попытка оптимизировать код без замеров производительности. Без метрик вы не сможете оценить эффект, а улучшения могут оказаться иллюзорными или даже отрицательными.

Правило простое: если польза ограничена одной командой или не влияет на общую продуктивность — это не задача для технического времени.

Почему это важно для команды?

Парадокс в том, что технические задачи — часто самые интересные для разработчиков. Они: * позволяют расти профессионально – дают возможность осваивать новые методологии и инструменты; * позволяют заниматься исследованиями и находить неочевидные решения; * повышают профессиональную самооценку: сотрудник видит, что способен влиять на архитектуру проекта, а не только «клепать фичи»; * сплачивают команду: коллеги начинают уважать друг друга за глубину экспертизы и сложность решаемых задач.

Когда разработчик тратит 20% времени на стратегические улучшения, он чувствует себя соавтором продукта, а не исполнителем. Это напрямую влияет на вовлечённость и удовлетворённость работой. Я тоже не устаю повторять, что наше первое место и ТОП-3 в рейтинге на протяжении 6 лет – это прямая заслуга каждого нашего сотрудника!

В следующем посте поговорим об опасности так называемых core-команд. Take care.