Комментарии 50
> Далеко за примерами ходить не надо. Все знают понятие «индусский код»: как только разработчикам начинают платить за количество написанный строчек кода
> А между тем, это как ни парадоксально, это очень точная метрика.
Я с вами очень и очень не согласен.
Возьмите любой фреймворк и решите задач с его использованием.
Теперь решите задачу без этого фреймворка. Кода у вас будет больше, а писать решение вы будете дольше.
При том что у каждого есть свои наработки и этакий самописный фреймворк для личного пользования.
> А между тем, это как ни парадоксально, это очень точная метрика.
Я с вами очень и очень не согласен.
Возьмите любой фреймворк и решите задач с его использованием.
Теперь решите задачу без этого фреймворка. Кода у вас будет больше, а писать решение вы будете дольше.
При том что у каждого есть свои наработки и этакий самописный фреймворк для личного пользования.
В прочем к общей мысли статьи притензий не имею. Это на случай чтобы кому-то не вздумалось мерить эффективность «негласно» количеством строк.
Вы неверно поняли автора, как мне кажется. Суть сводится к тому, что при таком подходе, даже использую фреймворк — можно написать кучу кода, который в реальности не нужен. И заметьте, что написать
if (f==f), времени много не нужно.Вся проблема в том, что не каждый управленец может отличить одно от другого и в этом случае совет становится вредным. Для того, чтобы понять, что это количество строк действительно имеет смысл, а не программер быдлокодит, надо делать ревизию кода.
Ну так о чем и речь :) Этим же и знаменит «индусский код», если бы количество строчек считали те, кто реально понимает в чем их смысл… но к сожалению машины пока этого делать не научились.
На самом деле обычный «инспектор» любой современной IDE быстро покажет как минимум половину хрени в таком индусском коде (что где бессмысленно написано, где можно сократить и т.п.).
Так что останется только писать «реальные» куски быдлокода, вдумываясь при написании, чтобы такой инспектор их пропускал. А уж если разработчик этим будет заниматься — в пору его уволить…
Так что останется только писать «реальные» куски быдлокода, вдумываясь при написании, чтобы такой инспектор их пропускал. А уж если разработчик этим будет заниматься — в пору его уволить…
Там важное уточнение: … необходимо много условностей (схожие задачи, наличие стандартов кодирования, например, максимальная длина метода, отсутствие дублирования, рефакторинг и так далее), но все же метрика достаточно точная… если не использовать ее как оценку производительности.
НЛО прилетело и опубликовало эту надпись здесь
> Но, к сожалению, не все так просто: как только мы вводим метрику, поведение команды
> начинает меняться. Команда и каждый ее член начинает подстраиваться под
> введенную нами метрику.
То, что начинает меняться — это очень хорошо.
То, что начинает меняться не в ту сторону, в какую хочется — это плохо.
Выход прост — критерии измерений должны быть известны вам и не известны команде.
Тут хороший пример — рейтинг на Хабре.
Вы знаете, что он считается, но точно не знаете, как.
> начинает меняться. Команда и каждый ее член начинает подстраиваться под
> введенную нами метрику.
То, что начинает меняться — это очень хорошо.
То, что начинает меняться не в ту сторону, в какую хочется — это плохо.
Выход прост — критерии измерений должны быть известны вам и не известны команде.
Тут хороший пример — рейтинг на Хабре.
Вы знаете, что он считается, но точно не знаете, как.
Как раз смысл в том, что у метрик есть побочные эффекты, которые не так очевидны. И их можно не увидеть до внедрения.
А вариант того, что команда не знает метрик, по которым оценивается их эффективность, на мой вгляд не очень хорош, как раз тем, что команда не получает фидбека и не понимает, насколько эффективно она работает.
А вариант того, что команда не знает метрик, по которым оценивается их эффективность, на мой вгляд не очень хорош, как раз тем, что команда не получает фидбека и не понимает, насколько эффективно она работает.
Вместо «не навреди» надо мерять те метрики, которые не приведут к суб-отимизации по метрике, а к оптимизации на финальной фазе (всем потоке создания ценности — lean-style): например число довольных продуктом заказчиков, долгосрочно получаемый за продукт профит\ресурсы, lead time. (ц) вольный пересказ Деминга.
Абсолютно согласен. Могу добавить только то, что по системам/субсистемам есть очень много интересных мыслей у Гольдрата.
Хорошая мысль.
Но довольные заказчики, как и всё остальное — такая же «оптимизируемая» метрика. Специально обученный человек садится на телефон и обзванивает заказчиков, в том числе потенциальных:
— Здравствуйте, вы довольны нашим продуктом?
— Эта проблема уже решается. А ещё?
— Эта проблема будет решена в следующей версии. А ещё?
— Эта проблема есть во всех аналогах, но мы работаем над ней. А ещё?
— То есть в целом вы довольны, спасибо.
В любом случае лучше здравого смысла пока ещё ничего не придумали.
Но довольные заказчики, как и всё остальное — такая же «оптимизируемая» метрика. Специально обученный человек садится на телефон и обзванивает заказчиков, в том числе потенциальных:
— Здравствуйте, вы довольны нашим продуктом?
— Эта проблема уже решается. А ещё?
— Эта проблема будет решена в следующей версии. А ещё?
— Эта проблема есть во всех аналогах, но мы работаем над ней. А ещё?
— То есть в целом вы довольны, спасибо.
В любом случае лучше здравого смысла пока ещё ничего не придумали.
А борщ, остыл…
На самой своей первой работе был как раз тестировщиком. И как раз «мерили» нас количеством найденных багов. Но не только количеством.
Был руководитель отдела (а у него были свои KPI, о которых мне неизвестно) классифицировал баги (по сложности обнаружения, приоритету), что давало багу «вес». Соответственно, эффективность тестировщика измерялась количеством и «весом».
Вполне нормальная схема.
Был руководитель отдела (а у него были свои KPI, о которых мне неизвестно) классифицировал баги (по сложности обнаружения, приоритету), что давало багу «вес». Соответственно, эффективность тестировщика измерялась количеством и «весом».
Вполне нормальная схема.
> цикл Деминга: Plan-Do-Check-Act
Кажется, Деминг и говорил, про то, что надо убрать все показатели для исполнителей, и оставить их менеджменту. К девелоперам не надо применять метрики, и к людям вообще, по-моему их надо применять к проекту, к процессу, к отделу, к компании наконец.
Кажется, Деминг и говорил, про то, что надо убрать все показатели для исполнителей, и оставить их менеджменту. К девелоперам не надо применять метрики, и к людям вообще, по-моему их надо применять к проекту, к процессу, к отделу, к компании наконец.
В компаниях где мне доводилось работать эффективность измеряется количеством оплачиваемых часов. Понятное дело, что это ни к каким реалистичным планам и большей эффективности не приводит. Вопрос в том, какими могут быть те метрики или способы, которые улучшают сам процесс вместо улучшения отчетности.
Статья как будто бы о наблюдении и измерении, а на самом деле об оплате труда и наказаниях. Это совсем разные вещи.
Если действительно хотите измерить, то не надо орать об этом. Просто сделайте это, причём максимально незаметно.
Кстати, метод кнута и пряника — это действительно не самый эффективный метод повышения производительности. Кому интересно, советую поизучать такую тему как «Эмоциональный интеллект».
Если действительно хотите измерить, то не надо орать об этом. Просто сделайте это, причём максимально незаметно.
Кстати, метод кнута и пряника — это действительно не самый эффективный метод повышения производительности. Кому интересно, советую поизучать такую тему как «Эмоциональный интеллект».
«Эмоциональный интеллект» — лежит на столе. Спасибо за напоминание!
Скорее статья о том, как не надо использовать метрики для «наказаний» :)
Согласен.
Кстати, как раз вспомнил ещё пример. В одной компании менеджеров по продажам стали штрафовать и премировать за количество звонков. В результате многие менеджеры стали делать много совершенно бесполезных звонков. Даже бесполезных для себя.
Кстати, как раз вспомнил ещё пример. В одной компании менеджеров по продажам стали штрафовать и премировать за количество звонков. В результате многие менеджеры стали делать много совершенно бесполезных звонков. Даже бесполезных для себя.
Похожая история в одной из ссылок из поста: local.joelonsoftware.com/wiki/Измерения_продуктивности
Примечательно, что статья по ссылке так же не соответствует своему названию, как и этот топик. Слово «измерить» принимает значение «премировать и штрафовать».
Вся ирония в том, что я только сейчас заметил, что Вы автор топика и сами иронично подметили его несоответствие названию и подмену смыла понятию «измерить».
Вся ирония в том, что я только сейчас заметил, что Вы автор топика и сами иронично подметили его несоответствие названию и подмену смыла понятию «измерить».
Я на практике вижу эффективной систему метрики сложности задач, времени исполнения и качества исполнения. Руководитель проекта оценивает задачи и раздает их девелоперам, девелоперы в свою очередь тоже ставят задачи друг другу, но важность и сложность задач определяет руководитель проекта. Тестировщики ставят задачи снова таки проходя этап оценки сложности у руководителя проекта. В итоге собирается статистика по количеству задач, сложности задач, затраченному времени и качеству выполнения. Исходя из этого можно рассчитать оплату труда. У нас например есть ставка у каждого, но в зависимости от выполнения тех или иных задач насчитывается бонус, который рассчитывается по вышеприведенным критериям.
Работает?
Да. На удивление очень хорошо работает. Все видят работу друг-друга и я еще не видел что бы возникали конфликты на почве нечестного разделения труда и задач. Это конечно больше заслуга руководителя проекта, но он руководствуется именно теми метриками что я написал. Помогает ему в этом такой продукт как Jira, но кроме продукта нужно умение оценивать сложность задач и назначать их правильно. Это он умеет.
Я почему спросил: когда руководитель проекта сам оценивает задачи и раздает их девелоперам, у него не очень много времени на стратегические задачи…
Согласен полностью. Поскольку у нас проект разросся в еще несколько веток, то добавился еще один руководитель проекта (он же один из девелоперов) на новые ветки, что позволило частично разгрузить первого руководителя проекта и разделить задачи как старые так и новые. Я бы целую статью написал о том как у нас процесс организован начиная с теории и заканчивая практикой и используемым вспомогательным ПО, но по сути дела таких статей много и моя будет касаться только отдельного случая и будет ни о чем много для кого.
Проблема таких постов — «ни-о-чем». Краткая суть «У вас проблема». Что делать? Ответ «Думайте о рыбе».
В физике есть такое понятие как «эффект наблюдателя»: если над системой ведется наблюдение, то оно вносит изменение в ее поведение
Было бы кстати очень интересно почитать также про физическое понятие. Например, как корпускуляно-волновой дуализм проявляет свои свойства при «эффекте наблюдателя»…
Было бы кстати очень интересно почитать также про физическое понятие. Например, как корпускуляно-волновой дуализм проявляет свои свойства при «эффекте наблюдателя»…
Есть такое, да.
Простая ассоциация — поисковики стараются ранжировать контент по его качеству, чтобы выдавать его на первом месте, как самый полезный, пользователям… И сразу появились «тунеядцы» под названием SEO-онанизаторы, прошу прощения, оптимизаторы, которые реально наносят вред здравой идее метрик полезности интернет-контента :-)
Борис, спасибо за статью. Есть над чем задуматься. А, как известно, половина успеха — это поставить правильный вопрос :-)
Борис, спасибо за статью. Есть над чем задуматься. А, как известно, половина успеха — это поставить правильный вопрос :-)
Количество строк кода — не метрика вообще. Тоесть формально, она что-то измеряет, но непонятно что.
Есть распространенное название для разного рода метрик в упралении — KPI, или «ключевые индикаторы ЭФФЕКТИВНОСТИ», а количество строк кода не имеет ничего общего с эффективностью.
Отсюда следует, что главный принцип не «не навреди», а «реши, зачем меряешь», или, на шаг веперед, «определи, какие решения хочешь принимать».
На мой взгляд — индивидуальные метрики в разработке вообще мало осмыслены. Только групповые. Например, безбажность кода применима не к программисту лично а к связке программист+тестер, так как с точки зрения управления не сделаная ошибка или исправленная — одно и то же, если на это ушло одинаковое количество времени (в этом примере я упрощаю).
Есть распространенное название для разного рода метрик в упралении — KPI, или «ключевые индикаторы ЭФФЕКТИВНОСТИ», а количество строк кода не имеет ничего общего с эффективностью.
Отсюда следует, что главный принцип не «не навреди», а «реши, зачем меряешь», или, на шаг веперед, «определи, какие решения хочешь принимать».
На мой взгляд — индивидуальные метрики в разработке вообще мало осмыслены. Только групповые. Например, безбажность кода применима не к программисту лично а к связке программист+тестер, так как с точки зрения управления не сделаная ошибка или исправленная — одно и то же, если на это ушло одинаковое количество времени (в этом примере я упрощаю).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эффект наблюдателя