← К публикациям

Замер работы команды: четыре промпта для техдиректора

· 7 минут чтения

Как собрать помесячные коммиты, слитые PR и оценку часов по каждому разработчику. Готовые промпты и пример трёх таблиц.

Три помесячные таблицы: коммиты, PR и оценочные часы

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

На выходе — три таблицы: строка — разработчик, колонка — месяц. Ниже четыре промпта, адаптированные из моего практического замера. Пример заполнен вымышленными числами.

Что подготовить

Дайте агенту доступ ко всем репозиториям команды: директориям проектов с полной историей изменений Git. Для Pull Request (PR) — запросов на проверку и слияние изменений — нужен также доступ к GitHub, GitLab или Bitbucket. В GitLab их называют Merge Request (MR).

Запускайте промпты последовательно в одной сессии любого кодингового агента. Замените поля в фигурных скобках. Конец периода не включается: 01.01–01.07 означает шесть полных месяцев. Выберите репозитории, ветки и часовой пояс до начала подсчёта.

Помесячную динамику до и после внедрения агентной разработки я показал в кейсе «С 8 до 188 PR в месяц». Там считаются открытые PR по всему проекту; в этом шаблоне — слитые PR по каждому разработчику.

Что означает оценка часов

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

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

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

Промпт 1. Подготовить источники

Сделай исходный замер инженерной активности команды. Читай исходные репозитории и сервисы без изменения их состояния. Прочитай локальные правила; результаты сохраняй в {OUTPUT_DIR}. Не отправляй и не публикуй их. Период: [{ДАТА_НАЧАЛА}, {ДАТА_КОНЦА}). Часовой пояс: {ЧАСОВОЙ_ПОЯС}. Репозитории и целевые ветки: {СПИСОК}. Сотрудники и даты участия: {КОМАНДА}. Проверь полноту Git-истории и доступа к PR/MR. Сохрани дату выгрузки, SHA целевых веток, источники, фильтры и пробелы в данных. Объедини Git-имена, email и логины одного человека по подтверждённым соответствиям. Неясные совпадения оставь для проверки; ботов выдели отдельно. Зафиксируй методику: считаем немержевые коммиты в истории целевых веток, месяц — по дате автора коммита; PR/MR — только слитые в эти ветки, месяц — по дате слияния, автор — создатель запроса. Это срез интегрированных изменений; незавершённая работа в других ветках в него не входит. Слияние с объединением коммитов (squash) меняет число видимых записей.

Промпт 2. Посчитать коммиты и PR

По согласованной методике собери все коммиты и PR/MR за период, включая все страницы API. Не подменяй PR подсчётом merge-коммитов. Удали дубли повторных выгрузок и зеркал репозиториев. Для каждого события сохрани репозиторий, SHA или номер PR, автора и дату. Создай monthly_commits.csv и monthly_prs.csv: строки — все сотрудники, колонки — месяцы, среднее и число месяцев в среднем. Суммируй по всем согласованным репозиториям. 0 означает проверенное отсутствие событий; Н/Д — неполные данные; «не участвовал» — месяц вне периода работы сотрудника. Среднее считай по полным календарным месяцам участия с полным покрытием, включая нулевые. Неполный месяц покажи отдельно, без пересчёта на полный. Сохрани исходные выгрузки. По каждой ячейке должно быть возможно восстановить список событий. Покажи неизвестных авторов и исключения.

Промпт 3. Оценить часы

Рассчитай часы за тот же период. Режим: {GIT_ACTIVE или EFFORT_ESTIMATE}. GIT_ACTIVE: для человека и месяца объедини выбранные коммиты всех репозиториев, отсортируй по дате автора. Первый коммит даёт 2 ч; каждый следующий — min(интервал с предыдущим в часах, 2). Одинаковые даты добавляют 0; месяц без коммитов даёт 0. Сохрани расчёт по каждому интервалу, округляй только итог. Не складывай независимые оценки по репозиториям: интервалы могут пересекаться. Подпись — «Git-активные часы». EFFORT_ESTIMATE: изучи код, описание PR, задачи и тесты. Объедини связанные изменения в единицы работы без повторного учёта одного кода. Для каждой единицы сохрани PR/SHA, автора, месяц, оценку min/central/max и основание. Заранее задай одинаковые допущения о квалификации, знакомстве с проектом и использовании ИИ. Месяц — по слиянию PR, для прямых коммитов — по дате автора; для нескольких участников покажи правило распределения. При нехватке данных ставь Н/Д. Подпись — «Оценка трудоёмкости, ч»; сумма диапазонов — сценарная оценка. Создай monthly_hours.csv по тем же правилам среднего и пропусков, что две предыдущие таблицы. Не выдавай оценку за фактическое время и не додумывай невидимые созвоны, исследования или ревью. Если есть табель, покажи его отдельно.

Промпт 4. Проверить и сохранить результат

Пересчитай таблицы из исходных выгрузок. Сверь итоги по людям, месяцам и репозиториям, даты, дубли, объединение авторов и расчёт часов. Проверь по первоисточникам 10 коммитов и 10 PR из разных месяцев и репозиториев (если меньше — все), а также нули, пропуски и неполные месяцы. Исправь расхождения. Сохрани baseline.md и три monthly_*.csv. В отчёт включи период, дату среза, покрытие, правила подсчёта, таблицы, ограничения и ссылки на локальные доказательства. Укажи версию промптов, скрипта и модель агента. Приложи короткий список выполненных и не пройденных проверок. Не включай секреты или исходный код компании.

Пример трёх таблиц

Скачать пример отчёта в PDF — четыре страницы: три таблицы, динамика и методика. Имена, названия и числа заменены на условные.

Все значения вымышлены. Среднее - за шесть полных месяцев; в реальном отчёте Н/Д означает отсутствие данных, а 0 - проверенное отсутствие событий.

Коммиты

Разработчик Янв Фев Мар Апр Май Июн Среднее
Разработчик 1 24 28 31 25 32 34 29,0
Разработчик 2 18 21 20 24 22 27 22,0
Разработчик 3 30 26 29 31 28 33 29,5

Слитые PR / MR

Разработчик Янв Фев Мар Апр Май Июн Среднее
Разработчик 1 6 7 8 6 8 9 7,3
Разработчик 2 4 5 5 6 5 7 5,3
Разработчик 3 7 6 7 8 7 8 7,2

Git-активные часы

Разработчик Янв Фев Мар Апр Май Июн Среднее
Разработчик 1 38 42 46 40 48 50 44,0
Разработчик 2 28 32 30 36 34 40 33,3
Разработчик 3 44 40 42 46 44 48 44,0

Как повторить замер

Сохраните выгрузки, методику и версии инструментов рядом с отчётом. В следующий раз используйте те же источники и правила. Изменения состава команды или покрытия покажите отдельно; при смене метода начните новую серию.

Термины

  • Коммит — запись об изменении кода в Git.
  • Целевая ветка — линия изменений, историю которой анализируем.
  • API — программный интерфейс сервиса для выгрузки данных.
  • SHA — идентификатор коммита.
  • CSV — текстовый формат таблиц для табличного редактора.

Автор: · Дата:

Хотите внедрить это у себя?

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

Работать со мной или канал «Жизнь стартапа в стране ИИ»