Comments 26
анализировать продуктивность людей
Когда всплывает слово «продуктивность» — это прям сразу маркер неадекватности ИМХО. Еще ни разу не встречал, чтобы в таком контексте что-то нормально работало.
Нужно просто нормально строить общение в командах и хорошо знать своих сотрудников. И доверять нижестоящим руководителям команд. Все. Все эти KPI и прочее — зло в чистом виде.
Вышесказанное сугубо мое личное мнение, не претендующее на истину в первой инстанции.
//Сорян, случайно ответил на коммент вместо поста :)
Нужно просто нормально строить общение в командах и хорошо знать своих сотрудников. И доверять нижестоящим руководителям команд. Все. Все эти KPI и прочее — зло в чистом виде
Это в идеальном мире, а в реальном никогда ничего не просто: руководители комманд отчитываются перед вышестоящим начальством, они в свою очередь отчитываются выше по цепочке. А на уровне совета директоров все разговаривают исключительно на языке KPI. Вот и вам, если захочется зарплату для своих сотрудников повысить, премию выбить или ещё какие плюшки, то придётся объяснять начальству, каким образом Вася работает лучше Пети.
Или наоборот, если нужно будет объяснять Пете, почему у него "продуктивность" неудовлетворительная - такое же бывает? Вы ж не будете говорить - ну, мне вот тут кажется, что ты должен "быстрее, лучше, сильнее" код писать, или "вон посмотри, Вася лучше тебя работает". Надо какие-то объективные метрики предоставить, чтобы обсуждать конкретику.
В общем, руководить командами - это непросто, а правильные метрики полезны. Другой вопрос - используются ли они во благо.
Хотел написать подобный комментарий. Все эти метрики обычно нужны чтобы устроить очередные менеджерские игрища на тему "как найти виноватого".
Но потом дочитал статью до конца и могу точно сказать - тут не тот случай. Автор реально предложил хорошую методу которая может формализовать реальность, а не просто нарисовать очередные бессмысленные графики.
Приятно видеть что иногда среди топ менеджеров встречаются грамотные люди. Приятно наверное работать в такой компании.
гит не сохраняет статистику пользователя, в отличии от гитхаба
Это, на самом деле, не совсем так. Из гитового репозитория можно получить достаточно много информации о поведении комиттера, особенно если он часто пушит.
Вся эта гонка за КПД приводит только к выгоранию в попытках соответствовать синтетическим метрикам.
Помню раньше вовлеченность в проект еще любили мерить путем анализа активности в чатах, тасках и на почте.
Меня больше интересует треккинг руководства если это не собственники бизнеса конечно, а наемные. Вот кто должен отчитываться и рассказывать о своих достижениях.
Они и отчитываются. Перед советом директоров ежеквартально, как правило.
Вся эта гонка за КПД приводит только к выгоранию в попытках соответствовать синтетическим метрикам.
Или к идиотизму в процессах вместо нормальной работы. Есть пример завода, где эффективные менеджеры ввели KPI и прочую фигню. Расчет эффективности строился тоже на метрике — считалось количество сопряжений в трехмерной сборке в проекте. Все это привело к тому, что вместо нормальных моделей стали делать ДИЧЬ, лишь бы соответствовать и не прослыть «непродуктивным».
Полезные ссылки, но я в облако наши проекты не стал бы загружать ради этих метрик. Вот если бы что-то было похожее без облака...
Из достаточно простого я нашел вот это https://github.com/change-metrics/monocle
Ну вот эффективные менеджеры добрались и до программирования. По каждой метрике легко находятся контрпримеры, в которые никто вникать конечно же не будет или не сможет технически.
Да здравствует творчество отсюда и до обеда!
Предположу, что любой KPI одинаково плох и хорош. Доводы за и против из практики легко найти. Поэтому просто приведу пример. Два месяца разрабатывал группу задач, объединенных в эпик, над которых предварительно поработали аналитики. Составлено ТЗ, утвержден бюджет. Сделал все в соответствии с ТЗ, тестировщики проверили, поправил недочеты, казалось бы можно в релиз. Но от бизнеса пришло "пожалуй не нужно нам это все". Куча времени аналитика, разработчика, тестировщика "в стол". Деньги бизнес заплатил. У богатых свои причуды. А мы-то плохие айтишники? Или стоило осаждать заказчика и махать перед ним своим гитом с коммитами - "пусти в релиз, окаянный!"
С интересом прочитал статью. В ней много умных вещей. Например, я впервые в жизни увидел выражение Code Churn (хотя работаю программистом уже 30 лет). Наверное, все это - хорошая тема для кандидатской диссертации на тему управления проектами. Но работать на проекте, в котором используются такие вот KPI, очень не хотелось бы.
И какой паттерн у аналитика, который создал эти метрики?-)
Снайпер. ...Точечные и ёмкие коммиты по задачам.
А как определить ёмкость коммита автоматическими способами?
Скаут. ...Высокий уровень legacy-рефакторинга по новым задачам (даже того кода, что вне контекста задачи).
Как выявить, касаются правки контекста задачи автоматическими способами?
На обложке JSON не валидный ...
В идеальном мире. На практике много где не разделяется как бек и фронт и х**ачишь как фуллстек. А командной работой называют ретроспективные созвоны и возможность созвониться и попросить совета. А на деле ты фуллстек на одном двух проектах и твои коллеги также - только на других проектах. В итоге гит выглядит как путь самурая - где один чел тащит, СТО мерджит и все это идет на прод. В итоге и вроде команда есть и недельные спринты стартуешь и заканчиваешь весело и с командой, а всю неделю один и тока тестировщики разбавляют твое одиночество показав где что отвалилось
Я бываю плюшкиным не редко. Это требование текущего тим лида ибо. Петы чаще на пуш отправляю, если что
Не понимаю почему тут все привязались к KPI, автор вообще об этом не говорил. Основной посыл был в том, как избежать рисков на проекте, посмотрев метрики. Так вроде смотришь все пушистые и хорошие, но метрики говорят за людей. Статья очень интересная, хорошо описаны паттерны поведения и к чему они могут привести, однозначно в закладки.
Покажи мне свой Git, и я скажу, кто ты