Эффект наблюдателя

    Чтобы узнать, посолен ли борщ, достаточно опустить в него два электрода, а затем пустить по ним ток. Если появится запах хлора — значит, борщ уже посолен :)

    В физике есть такое понятие как «эффект наблюдателя»: если над системой ведется наблюдение, то оно вносит изменение в ее поведение. Очень интересно этот эффект проявляется в организации работы команд разработчиков (да и в любых производственных процессах). Как только мы начинаем считать любые метрики, мы вносим изменения в поведения команды и отдельных ее членов.

    «Не навреди»


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

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

    А между тем, это как ни парадоксально, это очень точная метрика. Два программиста в команде правят примерно одинаковое количество строчек за один и тот же промежуток времени. Конечно, необходимо много условностей (схожие задачи, наличие стандартов кодирования, например, максимальная длина метода, отсутствие дублирования, рефакторинг и так далее), но все же метрика достаточно точная… если не использовать ее как оценку производительности.

    Можно попробовать сократить количество дефектов в нашем продукте, для чего считать, сколько багов сделал каждый разработчик. Лучших разработчиков будем награждать бонусами, а к худшим разработчикам — применять санкции. Все просто и прозрачно. Но на деле получиться по другому: разработчики будут спорить по каждому багу с тестировщиками, появится боязнь и желание избегать рисков, как результат отсутствие инициативы и нежелание делать поставленные задачи («Меньше задач, меньше багов»). Очень неплохой топик есть на хабре на эту тему «Живут, как тестировщик с программистом» за авторством Юлии Нечаевой.

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

    Что же делать?


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

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

    При внедрение метрик, как и любых других инноваций, очень неплохо использовать цикл Деминга: Plan-Do-Check-Act, чтобы у вас была возможность получить фидбек от команды и внести изменения в случае необходимости.

    Вкусненькие ссылки

    Share post

    Comments 50

      0
      > Далеко за примерами ходить не надо. Все знают понятие «индусский код»: как только разработчикам начинают платить за количество написанный строчек кода
      > А между тем, это как ни парадоксально, это очень точная метрика.

      Я с вами очень и очень не согласен.
      Возьмите любой фреймворк и решите задач с его использованием.
      Теперь решите задачу без этого фреймворка. Кода у вас будет больше, а писать решение вы будете дольше.

      При том что у каждого есть свои наработки и этакий самописный фреймворк для личного пользования.
        0
        В прочем к общей мысли статьи притензий не имею. Это на случай чтобы кому-то не вздумалось мерить эффективность «негласно» количеством строк.
          +10
          Вы неверно поняли автора, как мне кажется. Суть сводится к тому, что при таком подходе, даже использую фреймворк — можно написать кучу кода, который в реальности не нужен. И заметьте, что написать if (f==f), времени много не нужно.
            0
            Вся проблема в том, что не каждый управленец может отличить одно от другого и в этом случае совет становится вредным. Для того, чтобы понять, что это количество строк действительно имеет смысл, а не программер быдлокодит, надо делать ревизию кода.
              0
              Ну так о чем и речь :) Этим же и знаменит «индусский код», если бы количество строчек считали те, кто реально понимает в чем их смысл… но к сожалению машины пока этого делать не научились.
                +1
                На самом деле обычный «инспектор» любой современной IDE быстро покажет как минимум половину хрени в таком индусском коде (что где бессмысленно написано, где можно сократить и т.п.).
                Так что останется только писать «реальные» куски быдлокода, вдумываясь при написании, чтобы такой инспектор их пропускал. А уж если разработчик этим будет заниматься — в пору его уволить…
            +2
            Там важное уточнение: … необходимо много условностей (схожие задачи, наличие стандартов кодирования, например, максимальная длина метода, отсутствие дублирования, рефакторинг и так далее), но все же метрика достаточно точная… если не использовать ее как оценку производительности.
          • UFO just landed and posted this here
              0
              Пример из жизни: на сайте (или в диалоговом окне) слово «Вы» написано с большой буквы. Дефект? :)
              • UFO just landed and posted this here
                  0
                  В спецификации написано с большой буквы, а в корпоративной политике с маленькой…
                  • UFO just landed and posted this here
                      +1
                      Как раз они будут руководство нецелесообразностью, а метриками (кол-во багов одному идет в минус, другому в плюс). В итоге могут потерять несколько часов (и не только своих), вместо того, чтобы прийти к консенсусу за минуту :)
              –1
              > Но, к сожалению, не все так просто: как только мы вводим метрику, поведение команды
              > начинает меняться. Команда и каждый ее член начинает подстраиваться под
              > введенную нами метрику.
              То, что начинает меняться — это очень хорошо.
              То, что начинает меняться не в ту сторону, в какую хочется — это плохо.
              Выход прост — критерии измерений должны быть известны вам и не известны команде.
              Тут хороший пример — рейтинг на Хабре.
              Вы знаете, что он считается, но точно не знаете, как.
                +1
                Как раз смысл в том, что у метрик есть побочные эффекты, которые не так очевидны. И их можно не увидеть до внедрения.
                А вариант того, что команда не знает метрик, по которым оценивается их эффективность, на мой вгляд не очень хорош, как раз тем, что команда не получает фидбека и не понимает, насколько эффективно она работает.
                  0
                  Тут всё крепко зависит от порядков в той или иной компании.
                  Разные конторы — разные фидбеки, их уровень детализации и прозрачности.
                  Иногда от излишних знаний в этой части бывают изрядные проблемы.
                  Как вариант — пресловутый «индийский код».
                +4
                Вместо «не навреди» надо мерять те метрики, которые не приведут к суб-отимизации по метрике, а к оптимизации на финальной фазе (всем потоке создания ценности — lean-style): например число довольных продуктом заказчиков, долгосрочно получаемый за продукт профит\ресурсы, lead time. (ц) вольный пересказ Деминга.
                  +1
                  Абсолютно согласен. Могу добавить только то, что по системам/субсистемам есть очень много интересных мыслей у Гольдрата.
                    0
                    Хорошая мысль.

                    Но довольные заказчики, как и всё остальное — такая же «оптимизируемая» метрика. Специально обученный человек садится на телефон и обзванивает заказчиков, в том числе потенциальных:
                    — Здравствуйте, вы довольны нашим продуктом?
                    — Эта проблема уже решается. А ещё?
                    — Эта проблема будет решена в следующей версии. А ещё?
                    — Эта проблема есть во всех аналогах, но мы работаем над ней. А ещё?
                    — То есть в целом вы довольны, спасибо.

                    В любом случае лучше здравого смысла пока ещё ничего не придумали.
                    +2
                    А борщ, остыл…
                      0
                      На самой своей первой работе был как раз тестировщиком. И как раз «мерили» нас количеством найденных багов. Но не только количеством.

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

                      Вполне нормальная схема.
                        0
                        А при такой схеме «не выгодно» ли забивать на мелкие баги, а искать только баги с большим весом? :)
                          0
                          ну собственно вес — это функция в т.ч. и приоритета. Для продукта тоже выгодно, если тестировщик будет находит больше багов бОльшего приоритета.
                        +1
                        > цикл Деминга: Plan-Do-Check-Act
                        Кажется, Деминг и говорил, про то, что надо убрать все показатели для исполнителей, и оставить их менеджменту. К девелоперам не надо применять метрики, и к людям вообще, по-моему их надо применять к проекту, к процессу, к отделу, к компании наконец.
                          0
                          Собственно, у меня пост про командные метрики. Индивидуальные метрики еще более опасными могут быть :)
                            0
                            Я скорее к тому, что исполнителям вообще не надо знать/думать о метриках. Кроме сроков, пожалуй.
                          0
                          В компаниях где мне доводилось работать эффективность измеряется количеством оплачиваемых часов. Понятное дело, что это ни к каким реалистичным планам и большей эффективности не приводит. Вопрос в том, какими могут быть те метрики или способы, которые улучшают сам процесс вместо улучшения отчетности.
                            0
                            Идеальных метрик не бывает, всегда будет метрика лучше, чем текущая. В остальном я с вами соглашусь
                            0
                            Статья как будто бы о наблюдении и измерении, а на самом деле об оплате труда и наказаниях. Это совсем разные вещи.

                            Если действительно хотите измерить, то не надо орать об этом. Просто сделайте это, причём максимально незаметно.

                            Кстати, метод кнута и пряника — это действительно не самый эффективный метод повышения производительности. Кому интересно, советую поизучать такую тему как «Эмоциональный интеллект».
                              0
                              «Эмоциональный интеллект» — лежит на столе. Спасибо за напоминание!
                                0
                                Скорее статья о том, как не надо использовать метрики для «наказаний» :)
                                  +1
                                  Согласен.
                                  Кстати, как раз вспомнил ещё пример. В одной компании менеджеров по продажам стали штрафовать и премировать за количество звонков. В результате многие менеджеры стали делать много совершенно бесполезных звонков. Даже бесполезных для себя.
                                    0
                                    Похожая история в одной из ссылок из поста: local.joelonsoftware.com/wiki/Измерения_продуктивности
                                      0
                                      Примечательно, что статья по ссылке так же не соответствует своему названию, как и этот топик. Слово «измерить» принимает значение «премировать и штрафовать».

                                      Вся ирония в том, что я только сейчас заметил, что Вы автор топика и сами иронично подметили его несоответствие названию и подмену смыла понятию «измерить».
                                        0
                                        И где я это «подметил»? :) Название означает, что благодаря таким наблюдениям, можно внести нежелательные последствия в работу команды.
                                        Метрики обычно используются не для «премировать и штрафовать», а для повышения эффективности работы команды, в том числе и при помощи их анализа.
                                          +1
                                          «Скорее статья о том, как не надо использовать метрики для «наказаний» :)»

                                          А вот с этим я не согласен: «Как только мы начинаем считать любые метрики, мы вносим изменения в поведения команды и отдельных ее членов.»
                                          Измерять и считать можно не принося изменений.
                                0
                                Я на практике вижу эффективной систему метрики сложности задач, времени исполнения и качества исполнения. Руководитель проекта оценивает задачи и раздает их девелоперам, девелоперы в свою очередь тоже ставят задачи друг другу, но важность и сложность задач определяет руководитель проекта. Тестировщики ставят задачи снова таки проходя этап оценки сложности у руководителя проекта. В итоге собирается статистика по количеству задач, сложности задач, затраченному времени и качеству выполнения. Исходя из этого можно рассчитать оплату труда. У нас например есть ставка у каждого, но в зависимости от выполнения тех или иных задач насчитывается бонус, который рассчитывается по вышеприведенным критериям.
                                  0
                                  Работает?
                                    0
                                    Да. На удивление очень хорошо работает. Все видят работу друг-друга и я еще не видел что бы возникали конфликты на почве нечестного разделения труда и задач. Это конечно больше заслуга руководителя проекта, но он руководствуется именно теми метриками что я написал. Помогает ему в этом такой продукт как Jira, но кроме продукта нужно умение оценивать сложность задач и назначать их правильно. Это он умеет.
                                      0
                                      Я почему спросил: когда руководитель проекта сам оценивает задачи и раздает их девелоперам, у него не очень много времени на стратегические задачи…
                                        0
                                        Согласен полностью. Поскольку у нас проект разросся в еще несколько веток, то добавился еще один руководитель проекта (он же один из девелоперов) на новые ветки, что позволило частично разгрузить первого руководителя проекта и разделить задачи как старые так и новые. Я бы целую статью написал о том как у нас процесс организован начиная с теории и заканчивая практикой и используемым вспомогательным ПО, но по сути дела таких статей много и моя будет касаться только отдельного случая и будет ни о чем много для кого.
                                  +3
                                  Проблема таких постов — «ни-о-чем». Краткая суть «У вас проблема». Что делать? Ответ «Думайте о рыбе».
                                    –1
                                    Если эта тема вам не близка, можно просто не читать :) А то получается, ежики плакали, но продолжали есть кактус :)
                                      0
                                      Я начал читать в ожидании чуда, но его не случилось, к сожалению пока еще не могу распознать смысл текста, не прочитав его =)
                                      0
                                      Поддерживаю, очередной пост из серии «жизнь сложна, простых решений не бывает».
                                      +1
                                      В физике есть такое понятие как «эффект наблюдателя»: если над системой ведется наблюдение, то оно вносит изменение в ее поведение
                                      Было бы кстати очень интересно почитать также про физическое понятие. Например, как корпускуляно-волновой дуализм проявляет свои свойства при «эффекте наблюдателя»…
                                        0
                                        Я как метафору использовал :) А вот какой метафорой может быть корпускуляно-волновой дуализм пока слабо представляю :)
                                        0
                                        Есть такое, да.
                                          +2
                                          Простая ассоциация — поисковики стараются ранжировать контент по его качеству, чтобы выдавать его на первом месте, как самый полезный, пользователям… И сразу появились «тунеядцы» под названием SEO-онанизаторы, прошу прощения, оптимизаторы, которые реально наносят вред здравой идее метрик полезности интернет-контента :-)

                                          Борис, спасибо за статью. Есть над чем задуматься. А, как известно, половина успеха — это поставить правильный вопрос :-)
                                            0
                                            Количество строк кода — не метрика вообще. Тоесть формально, она что-то измеряет, но непонятно что.

                                            Есть распространенное название для разного рода метрик в упралении — KPI, или «ключевые индикаторы ЭФФЕКТИВНОСТИ», а количество строк кода не имеет ничего общего с эффективностью.

                                            Отсюда следует, что главный принцип не «не навреди», а «реши, зачем меряешь», или, на шаг веперед, «определи, какие решения хочешь принимать».

                                            На мой взгляд — индивидуальные метрики в разработке вообще мало осмыслены. Только групповые. Например, безбажность кода применима не к программисту лично а к связке программист+тестер, так как с точки зрения управления не сделаная ошибка или исправленная — одно и то же, если на это ушло одинаковое количество времени (в этом примере я упрощаю).

                                            Only users with full accounts can post comments. Log in, please.