Антон Анискин
у нас тоже метан из коровьего навоза выделяют и сжигают )
Интересно, платную версию много покупают?
На скринах мы видим скорее перт диаграммы.
Можно считать количество реопенов по результатам код ревью, багов и т.д. Это если есть в проекте однозначные критерии для код ревью. Чтобы это была не вкусовщина и настроение ревьюера, а некий прозрачный набор критериев.
И если реопенов много - то наверное лид недообучил программиста как работать в данном проекте. И вот сразу понятно что делать и как решить проблему - дообучить, пока не подтянется на общий уровень.
Это пример кривого втыкания "а навайте как-нибудь внедрим кипиай, я в книжке читал что то круто", не понимая нафига в данной конкретной компании, команде и ситуации это делать или не делать.
Тут вы правы.
Кстати любимый многоими нормальными менеджерами Элия Голдратт в своей теории ограничений как раз пишет то же самое, о чём вы говорите - локальные показатели эффективности бессмысленны. И даже вредны.
Так как результат даёт вся система целиком. И если у нас например узкое место это деплой (бывает ли такое?))) или там тестирование, то глупо оценивать работу разработчиков по количеству доставленных в прод задач, так как они не могут повлиять на то узкое место, которое определяет, сколько же задач доедет в единицу времени.
Ну или там если проблема в том, что бизнес всегда хочет всё вчера, без планирования без приоритетов и скидывает задач в десять раз больше, чем разработчики могут переварить - то проблема явно в том промежутке между бизнесом и конкретными разработчиками. И это узкое место, на которое разработчиктак же не может повлиять. (и в плохих конторах это ещё и используется чтобы выжать с программистов побольше а потом ещё и зарплату порезать - кто потом на них работать вообще будет?)
Вот от последней проблемы как раз может защитить нормальный лид или проджект, который с одной стороны бизнесу будет говорить твёрдое нет. Складывать задачи в бэклог, и обещать только то, что реалистично сделать с учётом рисков. Прикрывая при этом программистов от ада и трэша )
И с другой стороны огранизуя номральный последовательный процесс в команде, чтоыб миеть возможность в итоге давать большую пропускную способность команды и более быстрый тайм ту маркет для бизнеса. И понятный флоу работы для команды, которая спокойно с нормальнйо скоростью может хорошо и качественно делать свои задачи и получать от этого удовлетворение и зараплату.
Так никто об этом и не говорит. Просто вопрос в том, как сделать так, чтобы переделывать пришлось меньше, чтобы тайм ту маркет был быстрее и чтобы задачу которую делали аналитики, разработчики, тестировщики потом не выкинули за ненадобностью, потому что кто-то за пределами команды например не правильно сформулировал что нужно или не подумал о приоритетах.
Очевидно что всё это нужно рассматривать как единую систему.
Тут вопросов то нет.
Но можно трекать метрики какие-то, чтобы понимать где конкретно проблема, и что можно сделать чтобы её решить. Например если мы видим что задач после ревью становится всё больше и больше, а через тестирование они проезжают всё так же медленно - то понятно что нужно что-то сделать с тестированием - и для этого нужно понять в чём проблемы. например тупо нехватает людей и нужно донабрать. Или например слабая аналитика и у тестировщиков уходит куча времени чтобы понять что вообще должно как работать в задаче. Или разработчики не проверят работу своих задач даже примерно и половина задач доходят до тестирования нерабочими, или там например разворачивание окружения у тестировщиков занимает очень много времени, например день на то чтобы париться с развёрткой и час на тестирование.
Тогда понятно что можно сделать, чтобы это решить.
Проблема может быть на любом этапе или может вообще состоять из несколькоих взаимосвязанных проблем. и имея метрики типа таких как описано в статье - можно всё это исправить.
А так как на конечный результат влияет всё равно вся команда, то кипиай может быть только на всю команду включая лида и проджекта.
Так как например могут быть разные проблемы в разных частях проекта, и все они например из-за того, что плохая коммуникация в команде. и люди делают несколько одинаковых задач, или противоречащих задач, или несовместимные между собой задачи в разных компонентах. В таком случае программист просто сделал что от него требовалось, а результат плохой, и было бы странно например этого программиста лишать премии ит.д.. И решать эту проблему нужно во всей команде.
Но с другой соторны одному программисту/аналитику/тестировщику может быть на всё пофиг, а другому нет и огн пойдёт выяснять неясности и уточнять неточности, возьмёт под мышку остальных участников задачи и они выяснят какие-то нюансы, и не нужно будет переделывать три раза по неделе а потом ещё месяц ждать согласования на деплой ))))))
Бывает и наоборот. Программист отдает в тест нерабочий код а потом несколько дней успешно отбивается от тестировщика что у того криво стенд настроен.
А ещё задача может вернуться после тестирования на доаналитику например )
Командные показатели?
Не помог саппорту - запорол всем премию.
Для работника может и без разницы, стоила ли фича в итоге сто часов работы или шесть. Но для бизнеса разница огромная. Просто разработчики редко думают о пользе для бизнеса. А вы тут ругаете человека за то, что он - думает об этом.
По вашему - работнику пофиг - переделывалась ли задача три раза по неделе или была сделана сразу в один заход но за 7 рабочих дней например.
Он всё равно ту же самую зарпоату получит.
А для компании есть разница - каждый месяц откручивать несколько лямов на щарплаты налоги. И получать либо в несколько раз меньге либо в несколько раз больше доставленных в прод задач.
Просто за счет того, что кто то взял и взглянул на процесс системно.
Вот за это "эффективные менеджеры" и получают свои деньги.
Или поедет с готовым оффером на конкретное место работы сразу...
...и где противоречие?