Table of Contents

Почему время имеет значение для инженерных команд

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

Когда обучение напрямую связано с доказательствами, полученными во время обучения, оно становится более актуальным, более привлекательным и гораздо более эффективным. Инженеры видят связь между новым навыком и их повседневными задачами. Менеджеры получают уверенность в том, что их инвестиции в обучение улучшают как индивидуальную производительность, так и пропускную способность команды. Результатом является культура непрерывного совершенствования, где данные о времени информируют о приоритетах обучения на каждом уровне.

Что такое исследование времени?

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

Исследования времени могут проводиться вручную с помощью секундомеров и наблюдательных листов или автоматически с программными инструментами, которые регистрируют использование приложений, активность контроля версий и проверки управления проектами. Оба подхода имеют сильные стороны. Ручное наблюдение фиксирует контекст и прерывания. Автоматическое отслеживание обеспечивает масштаб и объективность. Многие инженерные команды объединяют эти два для наиболее точного просмотра.

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

Типы исследований времени в инженерии

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

Как провести время в инженерной команде

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

1.Определить масштабы и цели

Начните с выяснения того, что вы хотите узнать. Вы изучаете, почему выпуски кода задерживаются? Хотите узнать, тратят ли младшие инженеры слишком много времени на отладку по сравнению с дизайном? Будьте конкретны. Запишите ключевые вопросы, на которые должно ответить исследование времени. Этот фокус будет направлять, какие действия вы отслеживаете и как вы их категоризируете.

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

2.Выбрать участников и роли

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

3.Определить продолжительность и метод

Для большинства исследований, связанных с обучением, двухнедельный период наблюдения уравновешивает глубину с практичностью. Более короткие периоды рискуют пропустить еженедельные циклы (обзоры спринта, развертывания). Более длительные периоды становятся навязчивыми. Используйте комбинацию ручного наблюдения во время критических фаз (например, планирование спринта, обзор кода) и автоматизированное журналирование инструментов для оставшейся части. Если вы используете самозаготовку, предоставьте простую цифровую форму и краткую калибровочную сессию.

4.Создание категорий деятельности

Разработайте список категорий, который отражает ваш инженерный контекст. Общие категории включают:

  • Дизайн & архитектура
  • Кодирование (новые функции)
  • Отладка & устранение неполадок
  • Код (пересмотр чужого кода)
  • Тестирование (единица, интеграция, руководство)
  • Документация (внутренний, API, пользователь)
  • Встречи (стойки, спринт, ad-hoc)
  • Административный & накладные расходы (электронные письма, обновления JIRA, утверждения)
  • Learning & самообучение

Сохраните список между 8 и 12 категориями. Слишком много вызывает путаницу; слишком мало скрывает нюансы.

5. Поезд наблюдателей или подготовка инструментов

Если используются ручные наблюдатели, проинформируйте их о категориях и важности нейтрального, не нарушающего работу присутствия. Если используется программное обеспечение, настройте журналирование для соответствия категориям — например, системы теггита, такие как Toggl Track или RescueTime, могут назначать время проектам и задачам. Для отслеживания, ориентированного на код, системы контроля версий (например, Git) предоставляют временные метки, которые могут быть проанализированы отдельно.

6.Сбор данных

В течение периода исследования записывайте каждый переключатель активности, прерывание или задержку. Обратите внимание на время начала и окончания, категорию активности и любой соответствующий контекст (например, «прерванное срочным исправлением ошибок»). Для отслеживания на основе инструментов ежедневно экспортируйте журналы для раннего выявления несоответствий. Убедитесь, что инженеры понимают, что исследование не является оценкой производительности - это инструмент обучения. Анонимизированные данные укрепляют доверие.

7.Анализ результатов

После периода исследования, агрегируйте данные. Рассчитайте процент общего времени, проведенного в каждой категории среди всех участников. Ищите отстающих - инженеров, распределение времени которых резко отличается от сверстников. Затем углубитесь в конкретные задачи, которые заняли необычно много времени. Например, если ваши младшие инженеры тратят 40% своего времени на отладку, тогда как пожилые люди тратят только 15%, это сигнализирует о разрыве в обучении методологии отладки или языковому мастерству.

Использование данных исследования времени для определения потребностей в обучении

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

Пробелы в навыках во времени аномалии

Сравните время, затрачиваемое на выполнение задания, с ожидаемыми показателями или средними показателями сверстников. Общие аномалии, указывающие на потребности в обучении, включают:

  • Чрезмерное время отладки: Инженерам может не хватать систематических методов отладки, знакомства с инструментами отладки или глубоких знаний кодовой базы.
  • Долгие циклы рецензирования кода: Рецензенты могут не иметь четких стандартов или могут нуждаться в обучении эффективному чтению кода.
  • Непропорциональное время проектирования: Команды могут быть чрезмерно инженерными или отсутствующими методами структурированного проектирования (например, шаблоны проектирования, UML).
  • Частые переключения контекста: Хотя само по себе это не является пробелом в навыках, высокое переключение часто коррелирует со слабым приоритетом или отсутствием навыков выполнения задач.
  • Расширенные усилия по документированию: Инженеры могут бороться с техническим написанием или отсутствием шаблонов и примеров.

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

Использование временных исследований для проверки влияния обучения

Данные исследования времени также служат инструментом измерения до и после обучения. Запустите базовое исследование, доставьте целевое обучение, затем проведите последующее исследование через 4-6 недель. Если время, затрачиваемое на целевое узкое место, уменьшилось, обучение, вероятно, сработало. Если нет, содержание обучения или метод доставки могут нуждаться в корректировке. Эта система замкнутого цикла превращает обучение из разового события в непрерывный процесс улучшения.

Примеры из реального мира: исследование времени, применяемое к инженерному обучению

Случай 1: сокращение времени отладки для младших разработчиков

Компания среднего размера, занимающаяся программным обеспечением, заметила, что её младшие разработчики тратили в среднем 35% своей недели на отладку устаревшего кода. Исследование времени с использованием самозарегистрации подтвердило, что задачи отладки занимали в три раза больше времени, чем аналогичные задачи, выполняемые старшими разработчиками. Компания разработала двухдневный буткамп по стратегиям отладки, включающий использование точек останова, анализ журналов и методы двоичного поиска. Последующее исследование времени отладки младших разработчиков через три месяца показало, что время отладки младших разработчиков сократилось до 18% недели, а показатели качества кода улучшились.

Случай 2: Упорядочение обзоров кода в команде DevOps

Команда из восьми инженеров DevOps провела исследование времени работы-сборки в течение двух недель. Результаты показали, что обзоры кода потребляли 25% от общего количества часов работы команды, со средним циклом обзора 48 часов. Дальнейший анализ показал, что рецензенты тратили чрезмерное время на форматирование и комментарии к стилю, а не на логику и архитектуру. Команда представила литератор (автоматизированное форматирование) и контрольный список обзора кода, а затем обучила всех участников эффективности обзора. Второе исследование показало, что время обзора сократилось до 14% от общего количества часов, а время цикла сократилось до 12 часов.

Интеграция результатов исследования времени с вашей программой обучения

Сбор данных - это только половина дела. Чтобы превратить идеи в действия, следуйте структурированному процессу интеграции.

Шаг 1: Приоритетность темы обучения на основе воздействия

Не все пробелы в навыках равны. Используйте время исследования для расчета потенциальной экономии времени, если разрыв был закрыт. Умножьте среднее время, проведенное в неделю числом инженеров, затронутых. Например, если три младших инженера каждый тратит 10 часов в неделю на отладку из-за отсутствия знаний, и обучение может сократить это до 4 часов, еженедельная экономия составляет 18 часов - эквивалент половины инженерной роли. Приоритет учебных тем с самым высоким соотношением времени и воздействия.

Шаг 2: Обучение дизайну для конкретных типов поведения

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

Шаг 3: Внедрение обучения в рабочий процесс

Наиболее эффективная инженерная подготовка происходит вблизи работы. Используйте результаты исследования времени для планирования коротких, целевых сессий во время спринт-ретроспектив или обеда-и-уроков. Объедините обучение с практическими упражнениями с использованием реального кода из проекта команды. Это уменьшает разрыв между обучением и применением.

Шаг 4: Измерять и повторять

Как отмечалось, для измерения изменений необходимо провести последующее исследование времени после обучения. Если время, затрачиваемое на целевую деятельность, не уменьшилось осмысленно, следует рассмотреть альтернативные форматы обучения (парное программирование, наставничество, онлайн-курсы) или первопричины, выходящие за рамки навыков (например, проблемы процесса, ограничения инструмента). Само исследование времени становится инструментом обратной связи.

Преимущества и ограничения использования времени для обучения

Ключевые преимущества

  • Объективность: Решения, принимаемые в ходе обучения, основываются на измеренном поведении, а не на предположениях или анекдотических жалобах.
  • Целенаправленные инвестиции: Ресурсы идут в области с наибольшим влиянием на производительность, избегая отходов на нерелевантные темы.
  • Улучшение внедрения: Инженеры видят обоснование обучения и более мотивированы применять новые навыки.
  • Постоянный мониторинг: Повторяющиеся исследования времени создают продольный взгляд на развитие навыков.
  • Культурный сдвиг: Команды чувствуют себя комфортно с самосовершенствованием, основанным на данных, и открыты для обратной связи.

Ограничения для управления

  • Эффект Хоторна: Инженеры могут изменять свое поведение при наблюдении. митигатировать с помощью автоматизированных инструментов или постепенного наблюдения с явным неоценочным обменом сообщениями.
  • Навязчивость: Ручное наблюдение может ощущаться инвазивным. Сохраняйте сеансы короткими и ограниченными конкретными ролями или используйте анонимные агрегированные данные.
  • Время и усилия: Проведение тщательного исследования требует планирования и анализа времени.Начните с пилотной команды, чтобы уточнить процесс перед масштабированием.
  • Неправильное толкование: Сырые данные времени без контекста могут вводить в заблуждение. Всегда сопоставляйте количественные результаты с качественными интервью или ретроспективами.

Вывод: сделать изучение времени стандартной практикой

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

Начните с малого. Выберите одну команду, одну цель и одно двухнедельное исследование. Проанализируйте данные, спроектируйте одно целевое вмешательство в обучение и измерьте изменение. Как только вы увидите влияние в уменьшенном времени цикла, меньшем количестве дефектов и более высокой уверенности в команде, вы задаетесь вопросом, как вы когда-либо планировали обучение без него.

Для дальнейшего чтения методологии исследования и анализа потребностей в обучении, проконсультируйтесь с ресурсами из iSixSigma и Общество управления человеческими ресурсами .