Вроде конференция по JS, но не обошли стороной эффективных менеджеров и любителей KPI, браво. Инструкция о том, как уничтожить рабочие процессы используя git статистику. Не верится что в 2к24 находятся руководители которые считают зарплату сотрудников, исходя из среднего количества коммитов в час, это прямо реликт.
Если принята практика после аппрува MR все коммиты его составляющие сквошить в один, то у нас остается ещё много показателей: количество задач, список MR, список релизов, и т.п.
По дням без коммитов некоторый дисбаланс между теми кто следит за атомарностью коммитов, и теми кто просто каждые 15 мин киммитит дич, в расчете на сквошь
Многие комментаторы, похоже, упускают из виду, что статистика собирается на основе коммитов, но выводы делаются на основе других показателей. Частота и объём этих коммитов могут вообще не влиять на метрики. У докладчика прямо на слайдах про задачи написано.
Если новый человек на испытательном сроке, то надо контролировать минимум раз в день. Если проработал месяца три и понятно что он умеет - все равно раз в неделю какой-то результат должен быть, хотя бы в своей ветке.
Знаю чела, который комитит каждое изменение. Комменты к комитам выглядят примерно так: "Изменил инт на флоат" "добавил две строчке к комментарию" "Зарефакторил класс" "Зарефакторил класс, который рефакторил вчера"
Это хорошо. Коммиты должеы быть атомарными и не ломать тесты/корректность работы. Вот если бы он сделал 1 коммит со всеми этими изменениям - значит гит используется просто как хранилище истории
Зачем доклад откровеного вредителя взяли на конференцию?! Во-первых, он тупо рекламирует свою систему. Во-вторых, он хочет превратить индустрию - в индусов- главное кол-во коммитов.... Але, все просто будут коммитить по 2 строчки каждые 2 часа, лучше от этого не станет ни бизнесу, ни тем более сотрудникам.
Такое ощущение, что докладчик рулит сразу тысячью разрабов. Обычный тимлид с тимой из нескольких человек прекрасно все и так знает, кто на что способен и что делает, и где кто приуныл.
> Обычный тимлид Тимлид может быть неопытный и в запаре. Просмотр статы раз в год поможет лишний раз убедиться, что картина у него в голове совпадает с реальностью. > рулит сразу тысячью разрабов Начиная с позиции руководителя отдела и выше связь с реальностью начинает теряться. Ты очень много времени сидишь на совещаниях, а нижестоящий менеджмент иногда подтасовывает метрики в JIRA. + ситуация человека из отдела аудита или тех. лида, который не знаком с кодом, но ему нужно быстро понять проблемные места процессов в команде (графики: фактический состав релизов, долгоживущие PR, отсутствие тестов и т.п.).
Ой, не скажи. Банально, если проект такой, что команда из нескольких отделов, тимлид - мб знает тех с кем до этого работал, а новые - а хз, они там чет делают, коммитят, появляются-исчезают, их кидают то туда, то сюда. Дополнительно, в разных конторах представления о тимлидах и что они должны делать разное, и иногда тимлид превращается в непонятного чела, который всем обязан, 99% времени он на совещаниях, и где-то раз в неделю он может быстренько спросить: че там по задачам. И вот в таких случаях - даже те кто обычно нормальный перформанс выдавали, иногда начинают сачковать, ведь, а че я буду брать другую задачу, придумаю сложности, буду пилить месяц то что делается за 1 день. А другие - не сачкуют, берут и завалены из-за этого, в результате команда, которая была слажена и выдавала нормальный перформанс - проседает, начинается грызня, ведь тот кто продолжает перформанс выдавать - выгорает, ну и никому в результате не весело. Инструмент, который бы быстро помог оценить, кто что там делает - нужен. Но строиться ессно должен не на коммитах и строчках кода. Но вот какую метрику для разрабов взять, без того чтобы над душой стоял менеджер с палкой, хз на самом деле.
Звучит как конференция по JS, но эффективных менеджеров и любителей KPI не обошли стороной, молодцы. Инструкция как остановить выполнение процессов с помощью статистики git Не могу поверить, что в 2к24 есть менеджеры, которые рассчитывают зарплату сотрудников исходя из среднего количества коммитов в час, а это всего лишь остаток. Спасибо. большое за продолжение и удачи
Самое что смешное - нормальная в общем и целом тулза. Уберите из нее нахрен рекомендации по увольнению и премированию и живите счастливо. Потому что как раз объем работ и выполненных задач это САМАЯ плохо оценненная штука в этой тулзе, ну просто коммиты и количество времени + строк кода это КРАЙНЕ сомнительная метрика оценки эффективности разраба.
Большие и даже исследовательские, а не кодерские, задачи можно декомпозировать и оценить в стори-поинтах, по которым потом отчитываться, хоть каждую неделю.
Почему в системе нет метрик, которые могли бы выявлять неэффективность управленца или лида? Например, такие метрики, как количество revert-коммитов по отношению к количеству правок в задачах Jira, частота изменений файлов в рамках разных задач, могли бы помочь понять, кто и когда поставил некорректную задачу. Если задача делается много раз, это часто означает, что она не была продумана изначально. Такие метрики могли бы помочь выявить проблемы на уровне постановки задач и принятия решений. Возможно, это даст повод задуматься, не стоит ли пересмотреть роль лида. Что думаете по этому поводу? Ведь нередко за хаосом в команде стоит слабый лидер или неэффективные процессы.
> Почему в системе нет метрик, Такие метрики есть и их большинство. Каждая третья рекомендация системы ссылается на проблему управления, планирования и архитектуры. Возможно, в докладе не подчеркнул это. > Если задача делается много раз хорошая идея, добавил в TODO лист
Он сам сказал что он "в крысу снимает статистику" и ни в коем случае нельзя чтоб команда это узнала. Вся суть этого персонажа. Глупо считать кол-во коммитов / строк.
Вот это реально крутая тема, так держать. Даже я, как человек, который обмазывается графиками, офигел от количества информации и инсайтов. Ребята это топ, возможность развернуть в докере крайне радует. Делаете правое дело)
Большие и даже исследовательские, а не кодерские, задачи можно декомпозировать и оценить в стори-поинтах, по которым потом отчитываться, хоть каждую неделю.
Какой эффективный менеджер. Аж рука к арматуре потянулась.
Вроде конференция по JS, но не обошли стороной эффективных менеджеров и любителей KPI, браво. Инструкция о том, как уничтожить рабочие процессы используя git статистику. Не верится что в 2к24 находятся руководители которые считают зарплату сотрудников, исходя из среднего количества коммитов в час, это прямо реликт.
-Почему вас уволили с прошлого места работы?
-Я часто делал сквош
*сквонч
th-cam.com/video/-LQuh9dlTDQ/w-d-xo.html
Если принята практика после аппрува MR все коммиты его составляющие сквошить в один, то у нас остается ещё много показателей: количество задач, список MR, список релизов, и т.п.
По дням без коммитов некоторый дисбаланс между теми кто следит за атомарностью коммитов, и теми кто просто каждые 15 мин киммитит дич, в расчете на сквошь
Полезная информация в этом видео заслуживает внимания👍
Многие комментаторы, похоже, упускают из виду, что статистика собирается на основе коммитов, но выводы делаются на основе других показателей. Частота и объём этих коммитов могут вообще не влиять на метрики. У докладчика прямо на слайдах про задачи написано.
Ну хотите вы докопаться до человека, докопаетесь и без аналитики, по мне этим занимаются менеджеры из разряда чайка-менеджмента
Cтатистика собирается только для основного бранча или для всех веток сразу? Можно ли игнорировать ветки?
Если новый человек на испытательном сроке, то надо контролировать минимум раз в день. Если проработал месяца три и понятно что он умеет - все равно раз в неделю какой-то результат должен быть, хотя бы в своей ветке.
Знаю чела, который комитит каждое изменение. Комменты к комитам выглядят примерно так:
"Изменил инт на флоат"
"добавил две строчке к комментарию"
"Зарефакторил класс"
"Зарефакторил класс, который рефакторил вчера"
А бранча перед мержем сквошится? Это норм микро коммиты делать лишь бы этого бреда в мастере не было.
Это хорошо. Коммиты должеы быть атомарными и не ломать тесты/корректность работы. Вот если бы он сделал 1 коммит со всеми этими изменениям - значит гит используется просто как хранилище истории
Зачем доклад откровеного вредителя взяли на конференцию?! Во-первых, он тупо рекламирует свою систему. Во-вторых, он хочет превратить индустрию - в индусов- главное кол-во коммитов.... Але, все просто будут коммитить по 2 строчки каждые 2 часа, лучше от этого не станет ни бизнесу, ни тем более сотрудникам.
Такое ощущение, что докладчик рулит сразу тысячью разрабов. Обычный тимлид с тимой из нескольких человек прекрасно все и так знает, кто на что способен и что делает, и где кто приуныл.
> Обычный тимлид
Тимлид может быть неопытный и в запаре. Просмотр статы раз в год поможет лишний раз убедиться, что картина у него в голове совпадает с реальностью.
> рулит сразу тысячью разрабов
Начиная с позиции руководителя отдела и выше связь с реальностью начинает теряться. Ты очень много времени сидишь на совещаниях, а нижестоящий менеджмент иногда подтасовывает метрики в JIRA.
+ ситуация человека из отдела аудита или тех. лида, который не знаком с кодом, но ему нужно быстро понять проблемные места процессов в команде (графики: фактический состав релизов, долгоживущие PR, отсутствие тестов и т.п.).
Ой, не скажи.
Банально, если проект такой, что команда из нескольких отделов, тимлид - мб знает тех с кем до этого работал, а новые - а хз, они там чет делают, коммитят, появляются-исчезают, их кидают то туда, то сюда.
Дополнительно, в разных конторах представления о тимлидах и что они должны делать разное, и иногда тимлид превращается в непонятного чела, который всем обязан, 99% времени он на совещаниях, и где-то раз в неделю он может быстренько спросить: че там по задачам. И вот в таких случаях - даже те кто обычно нормальный перформанс выдавали, иногда начинают сачковать, ведь, а че я буду брать другую задачу, придумаю сложности, буду пилить месяц то что делается за 1 день. А другие - не сачкуют, берут и завалены из-за этого, в результате команда, которая была слажена и выдавала нормальный перформанс - проседает, начинается грызня, ведь тот кто продолжает перформанс выдавать - выгорает, ну и никому в результате не весело.
Инструмент, который бы быстро помог оценить, кто что там делает - нужен. Но строиться ессно должен не на коммитах и строчках кода. Но вот какую метрику для разрабов взять, без того чтобы над душой стоял менеджер с палкой, хз на самом деле.
Вера, важный пост, спасибо, что поделились
Очень информативное и красивое видео👍❤
Это лучший урок, который я видел
Самый простой способ убить эффективность своими же руками
18:43 мы видим что менеджмен проекта хуёвый, раз год за годом идет аврал в одно и то же время.
Совершенно верно. Пропустил эту фразу, но она была важной.
Классное видео 👍
Звучит как конференция по JS, но эффективных менеджеров и любителей KPI не обошли стороной, молодцы. Инструкция как остановить выполнение процессов с помощью статистики git Не могу поверить, что в 2к24 есть менеджеры, которые рассчитывают зарплату сотрудников исходя из среднего количества коммитов в час, а это всего лишь остаток. Спасибо. большое за продолжение и удачи
хорошее видео, мне нравится
Самое что смешное - нормальная в общем и целом тулза. Уберите из нее нахрен рекомендации по увольнению и премированию и живите счастливо. Потому что как раз объем работ и выполненных задач это САМАЯ плохо оценненная штука в этой тулзе, ну просто коммиты и количество времени + строк кода это КРАЙНЕ сомнительная метрика оценки эффективности разраба.
так красиво
Вау какое хорошее видео
The post is very interesting
не говорите ему, что rebase еще есть
А ещё reset и force push
Большие и даже исследовательские, а не кодерские, задачи можно декомпозировать и оценить в стори-поинтах, по которым потом отчитываться, хоть каждую неделю.
Как это нечто проскочило в доклады?
Вера Ника Видео и лайк
Yes i like you
nice
Щас бы с разработчиков спрашивать за количество коммитов.
Дак он же тупо свой продукт рекламирует, разве не? Так можно было?
Это кек
Почему в системе нет метрик, которые могли бы выявлять неэффективность управленца или лида? Например, такие метрики, как количество revert-коммитов по отношению к количеству правок в задачах Jira, частота изменений файлов в рамках разных задач, могли бы помочь понять, кто и когда поставил некорректную задачу. Если задача делается много раз, это часто означает, что она не была продумана изначально. Такие метрики могли бы помочь выявить проблемы на уровне постановки задач и принятия решений. Возможно, это даст повод задуматься, не стоит ли пересмотреть роль лида.
Что думаете по этому поводу? Ведь нередко за хаосом в команде стоит слабый лидер или неэффективные процессы.
> Почему в системе нет метрик,
Такие метрики есть и их большинство. Каждая третья рекомендация системы ссылается на проблему управления, планирования и архитектуры. Возможно, в докладе не подчеркнул это.
> Если задача делается много раз
хорошая идея, добавил в TODO лист
Он сам сказал что он "в крысу снимает статистику" и ни в коем случае нельзя чтоб команда это узнала. Вся суть этого персонажа. Глупо считать кол-во коммитов / строк.
Вот это реально крутая тема, так держать.
Даже я, как человек, который обмазывается графиками, офигел от количества информации и инсайтов.
Ребята это топ, возможность развернуть в докере крайне радует. Делаете правое дело)
До сих пор ржу с некоторых своих реп по достижениям, ребята это чума! xDD
@@roman-berezkin спасибо ^_^
А эффективность такого менеджера кто измерит?
Лёха
ну давай еще бигдату поставим чтоб вобще сразу сигнал посылать кого уволнять ))
как стать омерзительным менеджером - новый курс на отус
Большие и даже исследовательские, а не кодерские, задачи можно декомпозировать и оценить в стори-поинтах, по которым потом отчитываться, хоть каждую неделю.
не говорите ему, что rebase еще есть