то однозначно второй сделал меньше коммитов, дальше можно сходить в коммиты первого и проанализировать, может быть это на самом деле производительный человек

Я, когда раньше писал код, вечером всегда делал коммит.

При том, что реальная выкатка могла быть раз в две недели.

Таки я был бы менее эффективен, если бы коммитил раз в неделю и более - если бы пять раз в день?

проблема не в Qlick

Я делаю консолидированный фид из трёх источников: jira, gitlab, toggl. Начинаю беспокоится, если у меня "горка" по задаче какой-то не идёт из всех трёх систем одновременно.

Но у меня команды смешанные из трёх типов сотрудников: фултайм-офис, фултайм-удалёнка, точечный фриланс.

Иначе в этом "винограднике" гроздья людей/задач под контролем не удержать.

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

А вот какие из нее выводы делать это вопрос.

Обилие коммитов может говорить не в пользу программиста например.

кто-то data lake за data warehouse считает

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

А лучше отдать это проджектам, которые бы мерили не по частоте коммитов и не по тайм-трекерам, а по удовлетворённости заказчика, вовлечённости разработчиков в проект и по своевременной выкатке релизов :)

🤔

не не, все хотят циферки, и формулу, что бы по этим циферкам, подкручивая их, всё становилось лучше :)

+

Коллеги, задача такая: я сижу Архитектором в большом корпе (который еще и в стадии агрессивного развития). ~100 внутренних аппликух, аккумулированных за 30 лет. Проектные группы разбросаны по всему миру. В Бангалоре в том числе.  Мой директор сидит в борде. Борда хочет в клауд (по многим причинам). Народ на местах не хочет. Мне надо выбрать аппликуху и группу в кандидаты на модернизацию и перевод в клауд. И логически это обосновать, что бы мой дир пошел в борду, и борда в своей бесконечной мудрости приняла бесконечно мудрое решение.

Я думаю, метрики "общая плотность задач в Жире", и "средняя скорость выполнения этих задач" даст мне какое-то распределение "проекты где вообще ни хрена не происходит", "шатко-валко", "самые занятые проекты". Это высокий уровень. Потом выбрать 5 - 10 аппликух и смотреть на них ближе: важность для бизнеса, стоимость ошибки etc.

У меня не стоит задача мерять производительность отдельного сотрудника по количеству багов или коммитов. Для начала стоит задача просто понять, это проект живой или уже 10 лет на лайф саппорте.

Вот я и спрашиваю, на что бы вы посмотрели при такой задаче.

кмк тут одной джирой можно обойтись

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

ну и черт с ними

Я тоже так думаю :)

тебе же нужно пилотный выбрать - выбирай тот, где люди хотя бы к джире привыкли уже

куда задачи часто сыпятся (особенно снаружи, если это можно по джире понять) - тот и живой, из них выбираешь десяток и уже руками смотришь на гитхаб, кадры и тп