Как я статистику git парсил

Работаю я в бюрократизированной конторе с плохими процессами. Текучка тут достаточно большая. Люди приходят и уходят. Менеджмент на уровне дна. В какой-то момент в команду докинули нового разработчика (с неясными целями и задачами). Ну вроде парень умный, вроде что-то делает, вроде не просто так.

Спустя четыре месяца (испытательный закончился) у многих закрались подозрения, что на самом деле парень ничего не делает. Но как доказать это со стороны объективно? Решили посмотреть историю коммитов. Оказалось, он почти не коммитил (последний месяц вообще перестал), а на дейликах ссал в уши ездил по ушам. Парень продолжил работать на прошлой работе и был преподом на курсах. Такой вот overemployed, с двумя зарплатами по ставке синьора.

Ему предложили перевестись в другой отдел. Менеджеру все сошло с рук. Часть разрабов сидела с лицами «‎а что так можно было?»‎. А я понял, что нельзя так просто взять и посмотреть статистику коммитов.

Что есть на рынке

Пердолинг в консоль, что приемлемо, но хотелось бы «красивых обоев» и графиков:

• https://github.com/IonicaBizau/git-stats

• https://github.com/knadh/git-bars

• https://git-quick-stats.sh/

Десктоп тулзы которые чутка устарели

• https://apps.apple.com/us/app/gitstatx/id592679713?mt=12 (Mac)

• https://sourceforge.net/projects/gitstat/ (Linux)

• https://gitstats.lostindetails.com/ (Windows)

Квесты по установке бесконечных зависимостей и пакетов в пакете (Python, Ruby и другие языки). Некоторые отчёты +/- норм, но утомляет ставить компиляторы и пакетные менеджеры языков, на которых ты не пишешь.

• https://gitstats.sourceforge.net/ (python)

• https://github.com/vifactor/repostat (python)

• https://github.com/src-d/hercules (python)

• https://github.com/morucci/monocle (python)

• https://github.com/ejwa/gitinspector (python)

• https://github.com/tomgi/git_stats (Ruby)

• https://docs.mergestat.com/ (SQL! WHAT?!)

• https://github.com/alexejsailer/git-analytics-docker (Docker)

Плагины к другим продуктам, как огрызки функционала.

• https://www.whatplugin.ai/plugins/git-oss-stats (ChartGPT)

• https://marketplace.visualstudio.com/items?itemName=Tino.simple-git-stats (VisualStudio)

Хорошие, но платные штуки.

Они всё сделают, нужен только простой советский ......... но регистрация на демо по паспорту и СМС каждый пятый четверг месяца с двух до трех. Я решил оставить данные и их менеджер обещал обязательно связаться со мной и обсудить план пошаговой интеграции на ближайшие полгода.

• https://codeclimate.com/velocity/what-is-velocity

• https://www.gitclear.com/

• https://waydev.co/

• https://linearb.io/

• https://www.pluralsight.com/product/flow (анально огородились от IP из РФ)

Ты же не будешь писать свой велосипед?

Чувствуете, что задача кажется проще? Git уже есть. Статистику он выводит. Наверное, можно её как-то вытащить в отчёт без лишних телодвижений.

Я направил поток вывода git log в файл. Таким образом за одну консольную команду можно сформировать файл с данными. Ну а дальше уже распарсим строки в html и нарисуем графики. Никаких дополнительных пакетов и приседаний не нужно. Все очень просто.

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

Так я, собственно, и сделал.

Начало разработки

Дело было вечером, делать было нечего. Очень хотелось немного порисовать графики, и я откопал git-отчет. Решил построить графики на этой стате. Графики в целом получились.

Потом я решил вывести ещё немного доп. инфы, заплатить дизайнеру (чтобы было красиво), залить на github и поставив себе галочку «сделал вклад в open source».

Где в середине этого процесса, случайно была прочитана книга «Графики, которые убеждают всех» (Александр Богачев) и наступило осознание что ВСЕ ВООБЩЕ НЕ ТАК. Отчёт выводит графики, а людям интересны выводы.

Например: Петя коммитит чаще Оли, а Олег никогда не коммитит до обеда. В итоге наступил редизайн, и я залип ещё на пару месяцев.

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

• скопировать все фичи аналогов;

• дать больше денег дизайнеру;

• пригласить фокус группу;

• добавить всякие смешные ачивки, чтобы заинтриговать пользователей;

А, ну и самое главное — выкинуть весь код, и начать писать с нуля. Весело же!

Дефективный менеджер

Вся эта гонка за КПД приводит только к выгоранию в попытках соответствовать синтетическим метрикам. Помню раньше вовлеченность в проект еще любили мерить путем анализа активности в чатах, тасках и на почте... @beduin01

Перед тем как продолжить, нужно написать о важной проблеме: «Как не сделать инструмент дефективного менеджера?»

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

Повлияет ли это на конторы, где бардак? Наверное, нет. Вспомните, у меня же коллега буквально каждый день на статусах отчитывался о работе 4 месяца подряд ничего не делая. В следующий раз ещё авто-коммит пару раз в день по скрипту поставит и год точно просидит.

Повлияет ли это на нормальные конторы? Наверное, то же нет. Планы, ревью, 1-1, обзоры 360 и т.д. и так подсветят все проблемы.

Будет ли от этого хоть какая-то польза? Тоже не ясно. Но я попробую, а там видно будет.

Анализ статистики

А теперь давайте вслед за Сашей Кирилловым угорим по логике и паттернам поведения. Весь текст ниже про фулл-тайм разработку в стабильной команде на зарплате.

Сколько стоит разработка проекта?

• если человек коммитит, то он, наверное, работает;

• если работает, то скорее всего за зарплату;

• среднюю зарплату в IT мы видим прямо в баннерах на хабре;

Выводы:

• если мы знаем среднюю зарплату, количество человек и временной промежуток работы, то можем прикинуть минимальную стоимость проекта;

• если коммиты подписаны номерами задач, то можно прикинуть среднюю стоимость задачи;

• если в коммите упоминается фича, то можно примерно оценить стоимость фичей;

Да, тут появляется много «если». Но вот такой приблизительный расчет эту уже хоть какие-то цифры, от которых можно начинать считать. Давайте потренируемся на котиках open-source либах:

• средняя зарплата судя по рекламе хабра 180 тыс. ₽ в месяц за синьора. Есть больше, есть меньше, можно считать с налогами, а можно с северными коэффициентами. Бывают недооцененные синьоры из Новосибирска, а бывают переоцененные мидлы из Москвы. Но для примеры мы остановимся тут.

• 22 рабочих дня в месяц в среднем (работа с пн. по пт., допустим с 09:00 до 18:00)

• 8200₽ в день на программиста

• Человеко-день — день в который программист сделал хоть один коммит. Если два программиста делают по коммиту, то считаем как два человеко-дня, ведь они работали параллельно. Иногда они могут изменить всего одну строку, а бывают переписывают 50 файлов.

И это только разработка! А ведь ещё есть куча накладных расходов (налоги, отпуска, покупка оборудования, аренда офиса, зп тестировщика, дизайнера, аналитики и т.п.) и банальное завышение цены конечному заказчику. И это если у нас было супер идеальное ТЗ и мы «не клали код в стол»

Я «отжимался» на рабочих проектах, где народ работает пятидневку, работа стабильная, выходные и больничные оплачиваются в полном объеме, а переработки с коэффициентом х2. Как видите, это довольно сильно отличается от типичного open-source с github, где народ коммитит по вечерам раз в месяц. Поэтому строить какой-то прогноз или аналитику по open-source, мы можем только очеееееень широкими мазками.

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

• сколько проект может съедать оборотных средств в месяц;

• сколько суммарно стоила разработка за все время;

• сколько человеко-дней потратили;

• какая была текучка кадров;

• как часто работали на выходных, и какая переплата вышла;

• и т.д.

Но мы как бизнес итак их видим, зачем нам в git смотреть? Как бизнес — да, видим, но как работник можем не замечать. Кроме того, это может быть и не наш бизнес, а просто чужая репа, слитый код конкурентов, внутренний аудит и т.п.

А если я заказчик?

Ну вот я заказчик. Нанимаю какую-нибудь галеру пилить проект моей мечты. Мне продают 4х синьоров на полный рабочий день. А что может показать мне git? А может он показать, что на деле коммитит толпа фрилансеров. Видно, что рабочий день не день, а вечер. Да и вечер не каждый вечер, а вечер-через-вечер. Залетные аккаунты с чужими тасками, мержи сразу пачки задач из патчей и прочие отклонения «от нормы».

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

Есть ли польза для программиста?

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

Такой вот перемоткой, придя в новую контору, можно быстро вскрыть несколько историй:

• говорят «переработок нет», а сами стабильно работали на выходных;

• говорят «проект развивается», а по статистике видно, как половина команды уволилась. Ну если и развивается, то возможно куда-то не туда.

• говорят «менеджмент адекватный», а PR-ы в среднем висят по два месяца. Ну, наверное, адекватный не в управлении разработкой.

Среднестатистическому программисту, наверное, стоит запустить этот отчет два раза:

• когда только приходишь на проект, чтобы быстро понять какой в целом был roadmap, кто ящер-тащер, где и у кого по модулям зоны компетенций;

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

Давайте, для примера, посмотрим на один из проектов

Вопрос, к знатокам: «Проект развивается или находится в стадии стагнации? Будет на такой работе больше новых фич и развития, или костылей в легаси?»

Среднестатистическому тимлиду

Среднестатистическому тимлиду отчёт помогает «‎сравнить свои ощущения от проекта и команды с фактическим состоянием дел»‎ (с) Главное тут не свалиться в безумные KPI высосанные из пальца, а скорее искать отклонения от типичной картины.

Давайте найдем такое отклонение. Как вы думаете, кто недогружен в этой команде?

Видите, как один программист сильно выбивается из общей картины? Давайте сделаем разбивку по дням:

А теперь сравним с другим сотрудником за ту же неделю

Странно, да? Могут быть разные причины для такой картины, но если это ваш отдел, думаю вы будете в курсе о всех этих причинах и точно поймете нормально это или тревожный звонок. Но картина со стороны вызывает очень много вопросов к распределению задач и работе.

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

Главное правило

Анализируя статистику никому не рассказывай, что анализируешь статистику. Тут появляется эффект наблюдателя. Если люди знают, что статистику проверят, то и вести себя будут по другому. Например я:

• заполнял ежемесячный отчёт о проделанной работе и планах;

• списывал каждый день потраченное время с разбивкой по задачам;

• писал планы работ на две недели или на три месяца (на себя и на других);

• отчитывался на совещаниях;

• следил за статистикой в git;

Сделало это мою работу более эффективной? Не знаю. Но 100% научило всегда показывать полную занятость, наличие планов, высокий KPI и скорость. Даже если я смотрел весь день котиков на ютубе.

Мне нужна «помощь зала»

Как уже писал выше, одна и та же статистика может быть следствием абсолютно разных вещей. Чтобы отчёт мог выдать какую-либо рекомендацию, нужно хорошо понимать глубинные причины показателей. Давайте посмотрим на график мержа PR:

Время ожидания влития — это время, когда PR просто висит без правок. Оно считается от времени последнего коммита. Мы можем видеть тут, что часть PR висит в таком состоянии неделю. Т.к. коммитов нет — это не ревью, иначе могли бы быть правки кода. Что же это?

Конкретно в данном случае у нас проблема с тестированием. Оно очееень сильно отстает от разработки, а без тестирования мы не имеем права вливать ветки. Можем ли мы сделать это общим выводом для всех отчётов? Нет, т.к. у других команд это может быть «отмашка менеджера» или «ревью без правок кода».

Поэтому мне интересны ваши случаи, когда есть проблема и вы можете, косвенно, увидеть её на каком-либо графике. Собрав такие пары можно будет вносить в общий анализ новый паттерн «поиска проблемы и рекомендации». Но на одном проекте этого тупо не сделать, т.к. не собрать все ошибки управления (а может даже и не осознать, что проблема есть).

Что получилось

И так прошел год, потом второй. Переписывая отчёт третий раз я выдохся. Он получился вроде лучше аналогов, но наступил момент поддержки:

• правка и перевод текстов;

• подсчёт коэффициентов;

• добавление мелких фичей;

• покрытие тестами;

• написание мануалов и т.п.

Это уже не весело, это уже «разница между написанием программы, превращением ее в продукт»‎ (с) @apevzner

Глобально дальше вижу четыре пути развития функционала:

• добавление свистелок-перделок, достижений и викторин;

• анализ паттернов поведения и советы тимлидам;

• локализация и интернетизация;

• продолжу играть в CS по ночам, а проект дропну;

Если у вас есть ещё какие-либо идеи или замечания — отпишитесь пожалуйста, постараюсь добавить. Если нет — можете посмотреть какие ачивки вы выбили по стате текущего места работы.

Ссылка на проект