[Управление разработкой, Управление проектами, Управление персоналом] Почему не стоит пытаться ускорять разработку при помощи метрик (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Если вам приходилось руководить разработкой программного продукта, вы наверняка задумывались — как помочь команде двигаться быстрее? И как вообще понять, насколько быстро вы движетесь?
Для ответа на подобные вопросы кажется логичным прибегнуть к метрикам. В конце концов, мы уже давно и успешно используем их для самих программных продуктов. Есть метрики быстродействия, нагрузки на продакшен-сервера, аптайма. Есть также продуктовые метрики, основанные на поведении пользователей — вроде конверсии и удержания. Польза метрик заключается не только в более ясном понимании текущего состояния, но и, что важнее, в предоставлении обратной связи. Вы делаете изменение, призванное что-то улучшить, и по метрикам видите, насколько значительное улучшение (или ухудшение) получилось. Народная программистская мудрость гласит: каждая оптимизация производительности программы должна начинаться с измерения, и в этом есть большой смысл.
Раз мы можем успешно применять метрики к самим программным продуктам, почему бы не применить их к скорости разработке этих продуктов? Мы могли бы в таком случае пробовать какие-то улучшения в процессах и наглядно видеть, помогают ли они двигаться быстрее. Да и проблема определения справедливой зарплаты для программистов тоже бы упростилась. Какие метрики можно было бы использовать?
У нас нет хороших метрик для этого
Скорость разработки — это выполненный объем работы в единицу времени. Время мы можем измерить, тут все просто. А вот как измерить выполненный объем работы? Попытки сделать это начались много десятилетий назад, вместе с зарождением самой индустрии программирования. Однако каждый раз, когда показатель начинали использовать как цель для улучшения, обязательно что-то шло не так. Например:
- Количество строк кода. Это, наверное, старейшая метрика, которую уже окончательно никто не воспринимает всерьез. Если так оценивается объем работы, это приводит к замусориванию избыточным кодом, а разработчики начинают предпочитать самые простые задачи, избегая сложных проблем;
- Количество коммитов. Разработчики будут стараться дробить свои коммиты на более мелкие и, опять же, избегать сложных проблем;
- Количество выполненных задач. Стимулирует дробить задачи на более мелкие. Каждая проблема, даже незначительная, будет оформлена в виде задачи. Помимо этого, создает стимул срезать углы, если это приводит к скорейшему закрытию задач;
- Количество багов или процент багов. Метрика не объема, но качества работы. Если поставить ее как цель, разработчики будут бояться вносить изменения, а также будут неохотно рапортовать об ошибках, которые они нашли сами;
- Оценка задач в часах или сторипойнтах. Если продуктивность команды измеряется в единицах, которые она сама же и оценивает, нетрудно догадаться, к чему это приведет — со временем, оценки начнут завышаться;
- … и так далее.
Разработчики сообразительны и креативны, и они специализируются на решении сложных задач. Какую бы метрику вы им ни дали, они найдут самый простой способ улучшить показатели, но, скорее всего, он не будет иметь ничего общего с реальным объемом и качеством выполняемой работы. Будут ли они использовать эти “читерские” способы? Необязательно, это зависит от конкретной ситуации, в том числе от того, насколько сильный стимул вы создадите. Но они совершенно точно будут осознавать, что оценка их продуктивности слабо связана с принесением пользы. Это не только демотивирует, но и отвлекает от выполнения реальной работы.
Но почему?
Почему для улучшения свойств программных продуктов метрики прекрасно работают, но для измерения выполненной программистами работы — нет? Может, это какой-то заговор программистов? На самом деле, если мы посмотрим за пределы разработки ПО, то увидим и другие примеры, в одних из которых метрики работают хорошо, а в других — нет.
Примеры, когда метрики хорошо работают — массовое промышленное производство или продажи. Пусть будет производство и продажа кружек. Вы можете измерять объем производимой продукции — количество кружек в единицу времени, ее качество (процент брака), себестоимость одной кружки. В продажах — объем продаж, наценку. Эти метрики вполне успешно используются в управлении. Например, начальнику производства можно поставить задачу снижения процента брака при сохранении себестоимости, а начальнику отдела продаж — увеличения объема продаж при сохранении цены. Улучшения этих показателей принесут пользу бизнесу, так что их можно считать и показателями эффективности труда людей, которые за это отвечают.
Пример когда метрики не работают — оценка научной деятельности. Ученые производят исследования, которые потом публикуются в виде научных работ. В этой области тоже есть свои численные метрики — количество работ, количество цитирований, статистическая значимость результатов и др. Можно ли сказать, что ученый, выпустивший 10 научных работ, принес миру в два раза больше пользы, чем ученый, выпустивший 5 работ? Вряд ли, потому что ценность их трудов может сильно отличаться, и при этом даже на субъективном уровне бывает сложно понять, какой труд был более ценным. Проблема “накрутки” цитирований и публикаций широко известна в научной среде, так что, к сожалению, они не считаются надежными показателями ценности. Есть также и проблема манипуляций со статистической значимостью.
Два главных критерия
Вне зависимости от контекста у хорошо работающих метрик есть две общие черты:
- Прямая (а не косвенная) связь с ценностью;
- Точность, то есть метрика основана на измерении количества каких-то единиц ценности и эти единицы равны между собой;
Давайте посмотрим еще раз на примеры, которые мы рассматривали выше:
Метрики для массового производства и продаж удовлетворяют обоим критериям. В производстве кружек ценностью выступает продукция — сами кружки. Связь прямая, предприятию как раз и нужно производить кружки. А раз производство массовое, то единицы ценности (кружки) равны между собой. Если же мы говорим о продажах, то единицами ценности становятся деньги. Целью деятельности предприятия является получение прибыли, поэтому связь с ценностью, опять же, прямая. А поскольку каждый вырученный доллар равен другому, мы можем строить точные метрики.
В оценке научных трудов эти критерии соблюсти не удается. Мы не можем найти единицу измерения, которая бы напрямую определяла ценность научного труда, потому что все научные труды уникальны. По-другому быть и не может, просто исходя из самой сути науки — открывать новые знания. Ученому нет никакого смысла писать еще один научный труд, который бы в точности повторял другой. Каждая научная работа должна нести что-то новое.
Поскольку метрик, напрямую измеряющих ценность научного труда, мы найти не можем, то нам остаются только косвенные — например, количество публикаций и цитирований. Проблема с косвенными метриками в том, что они плохо коррелируют с ценностью и, как правило, легко подвержены “читерству”. Если вы начинаете использовать такую метрику в качестве цели, то вы сами создаете стимул ее искусственно накручивать.
Вернемся к измерению производительности программистов
Что у нас там было? Строчки кода, количество коммитов, задач, оценка задач в часах или сторипойнтах… Если вы попробуете проверить эти метрики на соответствие двум главным критериям, вы увидите, что ни одна из них им не соответствует:
- Нет прямой связи с ценностью. Мы не поставляем нашим клиентам строчки кода, человеко-часы или сторипойнты. Пользователям нет никакого дела, сколько коммитов мы сделали или сколько задач закрыли;
- Они не являются точными. Коммит коммиту рознь, одна строчка кода не равноценна другой, задачи тоже разные, а человеко-часы и сторипойнты оценены субъективно, поэтому также будут отличаться.
Так что нет ничего удивительного, что ни одна из этих метрик не работает — они же все косвенные и неточные.
А почему нет метрик, которые были бы напрямую связаны с ценностью труда программиста? По тем же причинам, почему их нет и у ученых. Программисты, как и ученые, постоянно создают что-то новое. Они не пишут в точности один и тот же код повторно — в этом нет смысла. Ранее написанный код можно переиспользовать разными способами, выделить его в отдельный модуль или библиотеку, ну, или просто скопировать, на худой конец. Поэтому каждый рабочий день у программистов уникален. Даже если они и решают похожие задачи, они решают их каждый раз в разном контексте, в новых условиях.
Работа программистов — это штучное производство, а не массовое. Они не производят одинаковых повторяющихся результатов, поэтому отсутствует база для измерения. Метрики, которые так хорошо работают в массовом производстве или продажах, здесь не работают.
А нет ли чего-то более современного, основанного на исследованиях?
Конечно, сегодня уже никто всерьез не говорит об измерении труда программиста строчками кода. Должны же быть какие-то более современные метрики, основанные на исследованиях, верно?
Есть и такие. В книге 2018-го года “Accelerate” авторы приводят результаты исследования 2000 организаций из разных отраслей. Авторы пытались выяснить, какими метриками можно было бы оценивать эффективность:
Источник: Nicole Forsgren, Jez Humble, and Gene Kim, “Measuring Performance,” in Accelerate: The Science behind DevOps: Building and Scaling High Performing Technology Organizations
Здесь приведены четыре метрики. Давайте посмотрим, какие из них связаны с ценностью и могут быть точно измерены:
- Частота поставок в продакшен. Я понимаю, почему эту метрику привели здесь. Чем чаще вы поставляете код в продакшен, тем лучше отлажен процесс поставки. Более продуктивные команды обычно поставляют код чаще. Однако корреляция не означает причинности. Вряд ли это напрямую связано с ценностью для клиента. Людям нужно, чтобы продукт решал их задачи, а не чтобы он как можно чаще менялся. Метрика также не является точной, потому что поставка поставке рознь. В одной поставке могли быть сделаны серьезные изменения, в другой — тривиальные;
- Lead time — время, в течение которого удовлетворяется запрос клиента. Эта метрика лучше связана с ценностью для клиента, поскольку мы говорим об изменениях в продукте, о которых он сам просил. Она не является при этом точной, потому что, опять же, изменения изменениям рознь — сложность их реализации может отличаться на порядки;
- Время восстановления после сбоя (MTTR) — если ваша программа не работает, клиенты грустят, так что связь с ценностью присутствует, и это хорошо. Но есть и недостатки. Во-первых, метрика не учитывает частоту сбоев. Частые сбои с быстрыми восстановлениями тоже будут расстраивать ваших клиентов, но MTTR этого не покажет. Во-вторых, она является неточной, ибо сбои бывают разные. Некоторые очень серьезные, другие — нет;
- Процент изменений, в процессе внесения которых возникали сбои. Связь с ценностью имеется в основном в ситуациях, когда пользователи устанавливают обновления самостоятельно. Если, согласно прошлому опыту, обновления несут существенный риск, люди будут бояться их устанавливать. Как говорят пользователи некоторых дистрибутивов Linux, “не было печали — апдейтов накачали”. В случае SaaS-продуктов связь с ценностью более слабая. Пользователям неважно, по какой причине у вас возник сбой — из-за изменений, сбоя у вашего провайдера, высокой нагрузки или чего-то еще. Им важно, чтобы ваш сервис всегда работал. Как и другие метрики выше, эта тоже не является точной по той же самой причине — изменения изменениям рознь. Одни серьезные, другие — нет.
Итого: ни одна из этих четырех метрик не является точной, и не всегда у них прослеживается четкая связь с ценностью для клиента. Есть ли в этом случае возможность для “читерства”? Конечно. Поставляйте тривиальные малорисковые изменения как можно чаще, и все метрики, кроме Lead time, будут выглядеть прекрасно.
Что касается Lead time — даже если опустить тот (немаловажный) факт, что она неточная, упор на нее приведет к приоритезации самых простых хотелок клиента и задвиганию в дальний угол всего, о чем клиент явно не просил — обычно это рефакторинги, тесты, да и просто любые улучшения, о которых он сам не подумал.
Поэтому я бы не рекомендовал использовать эти метрики в качестве целей.
Но может, мы найдем новые метрики?
Вы, конечно, можете сказать: “Подождите, если годных метрик пока еще не найдено, это же не значит, что их вообще быть не может! Мы люди умные, поднапряжемся и что-нибудь придумаем”. Увы, боюсь, не выйдет. Существует фундаментальная причина, почему в этой области нет хороших метрик. Как мы уже говорили выше, хорошие отвечали бы двум главным критериям:
- Прямая (а не косвенная) связь с ценностью;
- Точность, то есть метрика основана на измерении количества каких-то единиц ценности, и эти единицы равны между собой.
Прямую ценность мы точно измерить не можем, потому что все результаты труда программистов отличаются, они никогда не производят ничего в точности одинакового. Это штучное производство по уникальным, не повторяющимся заданиям. А раз нет ничего повторяющегося, то и базы для сравнения и измерения тоже нет. Нам остаются только косвенные показатели, но поскольку они плохо связаны с ценностью и подвержены читерству, полагание на них наносит ущерб.
Можно ли улучшить области, для которых нет хороших метрик?
Метрики очень удобны, потому что предоставляют обратную связь. Вы делаете какие-то изменения в процессе и можете наглядно видеть, привели они к улучшениям или нет. Если же метрик нет, то обратная связь становится не такой явной и может даже создаваться ощущение, что вы двигаетесь вслепую. Есть известное высказывание, приписываемое Питеру Друкеру:
Вы не можете управлять тем, что не можете измерить.
Только это неправда. Согласно Институту Друкера, Питер Друкер на самом деле не питал иллюзий, что для любой деятельности можно найти метрику, и никогда не говорил таких слов. Не все, что ценно, можно измерить, и не все, что можно измерить, представляет ценность.
Сложности с метриками вовсе не означают, что ничего нельзя улучшить. Некоторые компании выпускают софт значительно быстрее других, и причем без ущерба качеству. Значит, есть какие-то существенные отличия, и значит, улучшения должны быть возможны.
Резюме
Улучшить ваш программный продукт при помощи метрик можно и нужно. Метрики быстродействия, нагрузки, аптайма или продуктовые метрики, вроде конверсии и удержания клиентов, — ваши друзья.
Однако пытаться при помощи метрик ускорять сам процесс разработки не стоит, по причине отсутствия годных метрик. Показателей в этой области понапридумывали много, но, к сожалению, все они косвенные или неточные, а чаще то и другое сразу, поэтому при попытках их использовать в качестве целей получается только вред.
Но не расстраивайтесь — надежда есть! Отсутствие хороших метрик для скорости разработки — это грустненько, но это не значит, что улучшения в скорости невозможны. Еще как возможны. Мы даже построили целый стартап на идее, что это возможно. Одна из вещей, которую можно улучшить, это коммуникация между разработчиками и менеджментом. По ссылке выше приведены примеры, как улучшить коммуникацию, и объясняется, почему на этом стоит сделать фокус.
На этом все, пишите в комментариях, что вы думаете. Удачных вам деплоев, даже по пятницам.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Denis Stebunov
===========Похожие новости:
- [Управление проектами] Подготовка к PMP по шагам
- [Data Mining, Визуализация данных, Управление персоналом, Карьера в IT-индустрии] Thank you points: сетевой анализ социальных связей внутри DataArt
- [Работа с 3D-графикой, CAD/CAM, Управление проектами] Цифровизация управления проектами
- [Управление проектами, Развитие стартапа, Управление продуктом] Что делать, если у стартапа денег на счету меньше, чем на 1 год (перевод)
- [GTD, Читальный зал] Успешный успех: как победить прокрастинацию, узнать свои желания, поставить четкие цели и достичь их
- [Управление проектами, Управление персоналом, Карьера в IT-индустрии] Как увеличить собственную стоимость и значимость на рынке. Личный бренд и нетворкинг в карьерных маневрах
- [Управление проектами, Agile, Управление продуктом] Предназначение. To fit or not to fit
- [Программирование, .NET, Управление персоналом, Карьера в IT-индустрии, Интервью] Заметки про интервью на разработчика
- [Управление проектами] Проекты в контролируемой среде или краткий пересказ PRINCE2
- [Управление персоналом, Читальный зал] Гипертимезия и эволюция в IT
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_upravlenie_personalom (Управление персоналом), #_upravlenie_razrabotkoj (управление разработкой), #_upravlenie_proektami (управление проектами), #_upravlenie_ljudmi (управление людьми), #_metriki (метрики), #_produktivnost (продуктивность), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 02:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
 Если вам приходилось руководить разработкой программного продукта, вы наверняка задумывались — как помочь команде двигаться быстрее? И как вообще понять, насколько быстро вы движетесь? Для ответа на подобные вопросы кажется логичным прибегнуть к метрикам. В конце концов, мы уже давно и успешно используем их для самих программных продуктов. Есть метрики быстродействия, нагрузки на продакшен-сервера, аптайма. Есть также продуктовые метрики, основанные на поведении пользователей — вроде конверсии и удержания. Польза метрик заключается не только в более ясном понимании текущего состояния, но и, что важнее, в предоставлении обратной связи. Вы делаете изменение, призванное что-то улучшить, и по метрикам видите, насколько значительное улучшение (или ухудшение) получилось. Народная программистская мудрость гласит: каждая оптимизация производительности программы должна начинаться с измерения, и в этом есть большой смысл. Раз мы можем успешно применять метрики к самим программным продуктам, почему бы не применить их к скорости разработке этих продуктов? Мы могли бы в таком случае пробовать какие-то улучшения в процессах и наглядно видеть, помогают ли они двигаться быстрее. Да и проблема определения справедливой зарплаты для программистов тоже бы упростилась. Какие метрики можно было бы использовать? У нас нет хороших метрик для этого Скорость разработки — это выполненный объем работы в единицу времени. Время мы можем измерить, тут все просто. А вот как измерить выполненный объем работы? Попытки сделать это начались много десятилетий назад, вместе с зарождением самой индустрии программирования. Однако каждый раз, когда показатель начинали использовать как цель для улучшения, обязательно что-то шло не так. Например:
Разработчики сообразительны и креативны, и они специализируются на решении сложных задач. Какую бы метрику вы им ни дали, они найдут самый простой способ улучшить показатели, но, скорее всего, он не будет иметь ничего общего с реальным объемом и качеством выполняемой работы. Будут ли они использовать эти “читерские” способы? Необязательно, это зависит от конкретной ситуации, в том числе от того, насколько сильный стимул вы создадите. Но они совершенно точно будут осознавать, что оценка их продуктивности слабо связана с принесением пользы. Это не только демотивирует, но и отвлекает от выполнения реальной работы. Но почему? Почему для улучшения свойств программных продуктов метрики прекрасно работают, но для измерения выполненной программистами работы — нет? Может, это какой-то заговор программистов? На самом деле, если мы посмотрим за пределы разработки ПО, то увидим и другие примеры, в одних из которых метрики работают хорошо, а в других — нет. Примеры, когда метрики хорошо работают — массовое промышленное производство или продажи. Пусть будет производство и продажа кружек. Вы можете измерять объем производимой продукции — количество кружек в единицу времени, ее качество (процент брака), себестоимость одной кружки. В продажах — объем продаж, наценку. Эти метрики вполне успешно используются в управлении. Например, начальнику производства можно поставить задачу снижения процента брака при сохранении себестоимости, а начальнику отдела продаж — увеличения объема продаж при сохранении цены. Улучшения этих показателей принесут пользу бизнесу, так что их можно считать и показателями эффективности труда людей, которые за это отвечают. Пример когда метрики не работают — оценка научной деятельности. Ученые производят исследования, которые потом публикуются в виде научных работ. В этой области тоже есть свои численные метрики — количество работ, количество цитирований, статистическая значимость результатов и др. Можно ли сказать, что ученый, выпустивший 10 научных работ, принес миру в два раза больше пользы, чем ученый, выпустивший 5 работ? Вряд ли, потому что ценность их трудов может сильно отличаться, и при этом даже на субъективном уровне бывает сложно понять, какой труд был более ценным. Проблема “накрутки” цитирований и публикаций широко известна в научной среде, так что, к сожалению, они не считаются надежными показателями ценности. Есть также и проблема манипуляций со статистической значимостью. Два главных критерия Вне зависимости от контекста у хорошо работающих метрик есть две общие черты:
Давайте посмотрим еще раз на примеры, которые мы рассматривали выше: Метрики для массового производства и продаж удовлетворяют обоим критериям. В производстве кружек ценностью выступает продукция — сами кружки. Связь прямая, предприятию как раз и нужно производить кружки. А раз производство массовое, то единицы ценности (кружки) равны между собой. Если же мы говорим о продажах, то единицами ценности становятся деньги. Целью деятельности предприятия является получение прибыли, поэтому связь с ценностью, опять же, прямая. А поскольку каждый вырученный доллар равен другому, мы можем строить точные метрики. В оценке научных трудов эти критерии соблюсти не удается. Мы не можем найти единицу измерения, которая бы напрямую определяла ценность научного труда, потому что все научные труды уникальны. По-другому быть и не может, просто исходя из самой сути науки — открывать новые знания. Ученому нет никакого смысла писать еще один научный труд, который бы в точности повторял другой. Каждая научная работа должна нести что-то новое. Поскольку метрик, напрямую измеряющих ценность научного труда, мы найти не можем, то нам остаются только косвенные — например, количество публикаций и цитирований. Проблема с косвенными метриками в том, что они плохо коррелируют с ценностью и, как правило, легко подвержены “читерству”. Если вы начинаете использовать такую метрику в качестве цели, то вы сами создаете стимул ее искусственно накручивать. Вернемся к измерению производительности программистов Что у нас там было? Строчки кода, количество коммитов, задач, оценка задач в часах или сторипойнтах… Если вы попробуете проверить эти метрики на соответствие двум главным критериям, вы увидите, что ни одна из них им не соответствует:
Так что нет ничего удивительного, что ни одна из этих метрик не работает — они же все косвенные и неточные. А почему нет метрик, которые были бы напрямую связаны с ценностью труда программиста? По тем же причинам, почему их нет и у ученых. Программисты, как и ученые, постоянно создают что-то новое. Они не пишут в точности один и тот же код повторно — в этом нет смысла. Ранее написанный код можно переиспользовать разными способами, выделить его в отдельный модуль или библиотеку, ну, или просто скопировать, на худой конец. Поэтому каждый рабочий день у программистов уникален. Даже если они и решают похожие задачи, они решают их каждый раз в разном контексте, в новых условиях. Работа программистов — это штучное производство, а не массовое. Они не производят одинаковых повторяющихся результатов, поэтому отсутствует база для измерения. Метрики, которые так хорошо работают в массовом производстве или продажах, здесь не работают. А нет ли чего-то более современного, основанного на исследованиях? Конечно, сегодня уже никто всерьез не говорит об измерении труда программиста строчками кода. Должны же быть какие-то более современные метрики, основанные на исследованиях, верно? Есть и такие. В книге 2018-го года “Accelerate” авторы приводят результаты исследования 2000 организаций из разных отраслей. Авторы пытались выяснить, какими метриками можно было бы оценивать эффективность:  Источник: Nicole Forsgren, Jez Humble, and Gene Kim, “Measuring Performance,” in Accelerate: The Science behind DevOps: Building and Scaling High Performing Technology Organizations Здесь приведены четыре метрики. Давайте посмотрим, какие из них связаны с ценностью и могут быть точно измерены:
Итого: ни одна из этих четырех метрик не является точной, и не всегда у них прослеживается четкая связь с ценностью для клиента. Есть ли в этом случае возможность для “читерства”? Конечно. Поставляйте тривиальные малорисковые изменения как можно чаще, и все метрики, кроме Lead time, будут выглядеть прекрасно. Что касается Lead time — даже если опустить тот (немаловажный) факт, что она неточная, упор на нее приведет к приоритезации самых простых хотелок клиента и задвиганию в дальний угол всего, о чем клиент явно не просил — обычно это рефакторинги, тесты, да и просто любые улучшения, о которых он сам не подумал. Поэтому я бы не рекомендовал использовать эти метрики в качестве целей. Но может, мы найдем новые метрики? Вы, конечно, можете сказать: “Подождите, если годных метрик пока еще не найдено, это же не значит, что их вообще быть не может! Мы люди умные, поднапряжемся и что-нибудь придумаем”. Увы, боюсь, не выйдет. Существует фундаментальная причина, почему в этой области нет хороших метрик. Как мы уже говорили выше, хорошие отвечали бы двум главным критериям:
Прямую ценность мы точно измерить не можем, потому что все результаты труда программистов отличаются, они никогда не производят ничего в точности одинакового. Это штучное производство по уникальным, не повторяющимся заданиям. А раз нет ничего повторяющегося, то и базы для сравнения и измерения тоже нет. Нам остаются только косвенные показатели, но поскольку они плохо связаны с ценностью и подвержены читерству, полагание на них наносит ущерб. Можно ли улучшить области, для которых нет хороших метрик? Метрики очень удобны, потому что предоставляют обратную связь. Вы делаете какие-то изменения в процессе и можете наглядно видеть, привели они к улучшениям или нет. Если же метрик нет, то обратная связь становится не такой явной и может даже создаваться ощущение, что вы двигаетесь вслепую. Есть известное высказывание, приписываемое Питеру Друкеру: Вы не можете управлять тем, что не можете измерить.
Только это неправда. Согласно Институту Друкера, Питер Друкер на самом деле не питал иллюзий, что для любой деятельности можно найти метрику, и никогда не говорил таких слов. Не все, что ценно, можно измерить, и не все, что можно измерить, представляет ценность. Сложности с метриками вовсе не означают, что ничего нельзя улучшить. Некоторые компании выпускают софт значительно быстрее других, и причем без ущерба качеству. Значит, есть какие-то существенные отличия, и значит, улучшения должны быть возможны. Резюме Улучшить ваш программный продукт при помощи метрик можно и нужно. Метрики быстродействия, нагрузки, аптайма или продуктовые метрики, вроде конверсии и удержания клиентов, — ваши друзья. Однако пытаться при помощи метрик ускорять сам процесс разработки не стоит, по причине отсутствия годных метрик. Показателей в этой области понапридумывали много, но, к сожалению, все они косвенные или неточные, а чаще то и другое сразу, поэтому при попытках их использовать в качестве целей получается только вред. Но не расстраивайтесь — надежда есть! Отсутствие хороших метрик для скорости разработки — это грустненько, но это не значит, что улучшения в скорости невозможны. Еще как возможны. Мы даже построили целый стартап на идее, что это возможно. Одна из вещей, которую можно улучшить, это коммуникация между разработчиками и менеджментом. По ссылке выше приведены примеры, как улучшить коммуникацию, и объясняется, почему на этом стоит сделать фокус. На этом все, пишите в комментариях, что вы думаете. Удачных вам деплоев, даже по пятницам. =========== Источник: habr.com =========== =========== Автор оригинала: Denis Stebunov ===========Похожие новости:
Управление разработкой ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 21-Май 02:09
Часовой пояс: UTC + 5