CC BY
4DOI: 10.12731/2070-7568-2023-12-3-74-91 УДК 311
Научная статья |
Математические, статистические и инструментальные методы в экономике
ВЫБОР МЕТРИК ДЛЯ КОМАНД ПРОГРАММИСТОВ, РАБОТАЮЩИХ В УСЛОВИЯХ ВЫСОКОЙ НЕОПРЕДЕЛЁННОСТИ
Е.В. Клинков
Состояние вопроса. Существует много книг о том, как разрабатывать ПО, чуть меньше источников о том, как управлять командами разработчиков ПО, и совсем мало о том, как оценивать работу разработчиков ПО. В рамках данной статьи были проанализированы существующие практики выбора метрик для оценки работы scrum-команды разработчиков ПО и предложены обобщённые правила, применение которых позволит реализовать принцип Парето в вопросе выбора и применения метрических показателей.
Методы исследования. В процессе исследования использовались такие общенаучные методы, как анализ отечественной и иностранной тематической литературы, сравнительный анализ, индукция и аналогия.
Результаты. Результатом статьи является упорядоченный набор действий, применение которых позволяет наиболее эффективно оценить работы scrum-команды разработчиков ПО. Целевая аудитория статьи широкая. Менеджеры разного уровня (от менеджера команды или scrum-мастера до руководителя департамента) могут использовать описанный подход для формирования метрик своих подразделений. Разработчики смогут лучше понять, как руководители видят их работу и учитывать это в своей работе.
Заключение. Типовые задачи разработчика ПО подразделятся на технические этапы. При выделении метрики для оценки эффективности каждого этапа может повыситься риск локальных оптимизаций. Кроме того, если зона ответственности руководителя смещается от целого к частному, от эффективности компании к эффективности подразделения, то риск выбора неверных метрик кратно повышается. Метрики, которые оценивают частичный результат, рассматриваются как неверные - они относятся к части функционала, подразделению в рамках компании и т.п. В результате повышается вероятность принятия управленческого решения в соответствии
с интересами подразделения, а не компании или продукта в целом. По этой причине использования частных метрик следует избегать.
Ключевые слова: scrum; команда; метрики; оценка эффективности Для цитирования. Клинков Е.В. Выбор метрик для команд программистов, работающих в условиях высокой неопределённости //Наука Красноярья. 2023. Т12, №3. С. 74-91. DOI: 10.12731/2070-7568-2023-12-3-74-91
Original article |
Mathematical, Statistical and Instrumental Methods in Economics
CHOOSING METRICS FOR SOFTWARE DEVELOPER'S SCRUM TEAMS
E.V. Klinkov
Background. There are many books about software development, slightly fewer books about software development team s management, and very little about work metrics of software development teams. Existing developers scrum team metrics definition practices were analyzed in this article and common rules were proposed. Application of the rules will allow implementing the Pareto principle in the choosing and using of metrics in developer's scrum teams.
Methods. General scientific methods such as the analysis of Russian-language and foreign thematic literature, comparative analysis, induction and analogy were used.
Results. The result of the article is an ordered action plan, using ofwhich makes it possible to most effectively evaluate the work of the developer's scrum team. The target audience of the article is wide. Managers of different levels (from the team manager or scrum master to the head of the department) can use the described approach to create metrics for their departments. Developers will be able to better understand how managers see their work and take this into account in their work.
Conclusion. Software developer typical tasks are divided into technical stages. When allocating metrics to evaluate the effectiveness of each stage, the risk of local optimizations increased. In addition, if the area of responsibility of the manager shifts from the whole to the part, from the efficiency of the company to the efficiency of the business unit, then the risk of choosing the wrong metrics increases many times. Metrics that evaluate a partial result are considered incorrect - they relate to a part of the functionality, a division within the company, etc. As a result, the likelihood of making a management decision in accordance with the interests of the division, rather than the company or the product as a whole, increases. For this reason, the use of private metrics should be avoided.
Keywords: scrum; team; metrics; performance evaluation
For citation. Klinkov E.V. Choosing Metrics for Software Developer s Scrum Teams. Krasnoyarsk Science, 2023, vol. 12, no. 3, pp. 74-91. DOI: 10.12731/20707568-2023-12-3-74-91
Введение
Несмотря на революционность информационно-компьютерных технологий, подходы к управлению процессом создания и компьютеров и программного обеспечения были в значительной степени заимствованы из промышленности. Теория потока, «правило 6 сигм» и «5 почему?» прекрасно работают как на производственной линии, так и в командах разработчиков ПО [12]. Они используются для решения сугубо прикладных задач: составления планов, мониторинга их реализацией, анализа полученных результатов и их корректировки при необходимости. Эти методы образуют классический цикл Шухарта - Деминга [25]. Однако, применение существующих, хотя и востребованных, практик и методик все меньше удовлетворяет разработчиков.
Для определения достижения результатов, отслеживания производственного процесса и выработки управленческих решений для его (процесса) корректировки необходимо подобрать соответствующие метрические показатели.
Хронологически в начале работы над проектом руководитель определяет те задачи, которые должны быть решены под его руководством, затем определяет, какие управленческие решения ему возможно придётся принять на основе полученных результатов и выбирает метрики, на основании которых он будет проверять достижение результата. Оценка результата разработки ПО состоит из двух частей - объективной (соответствие согласованным функциональным требованиям) и субъективной (когда пользователи дают своё экспертное заключение, например, на предмет удобства использования ПО). Без данных оценок использование ПО может привести к ошибкам в принятии управленческих решений и, как следствие, к финансовым, репутационным и другим потерям.
Эти требования к эффективному управлению разработкой ПО обусловили цель данной работы.
Цель исследования: обзор существующих метрических показателей и способов их выбора при работе scrum команд разработчиков ПО [2] в условиях высокой неопределённости.
В соответствии с описанной последовательностью действий составляются задачи, необходимые для достижение поставленной цели: 1) опреде-
ление типовых задач, для которых необходимы метрики, 2) оценка метрик как триггеров выполнения этих действий, 3) составление списка типовых управленческих решений, которые должны быть приняты на основе решения этих задач, 4) оптимизация выбранных метрик на основе полученных результатов и принятых решений. Под оптимизацией метрик будем понимать изменение их качественного и/или количественного состава. Данный шаг является необязательным. Он проводится в случае, если выявлено подозрение на некорректность метрик, их недостаточность или избыточность.
Материалы и методы
Информационная база исследования сформирована на основе публикаций по проблемам разработки метрик для оценки деятельности организаций (включая оценку эффективности деятельности разработчиков ПО). При проведении исследования нами использовался общенаучный метод анализа и синтеза.
Результаты исследования
Существует много книг о том, как разрабатывать ПО, чуть меньше источников о том, как управлять командами разработчиков ПО, и совсем мало о том, как оценивать работу разработчиков ПО.
В англоязычной литературе имеются работы, в которых содержится обзор применения метрик как таковых, например, Jerry Z. Muller «The Tyranny of Metrics» [6]. Но большинство публикаций ограничиваются определёнными условиями: чаще всего, выбором фреймворка, как например, в работе [8]. В русскоязычной литературе сложилась похожая ситуация. Широко используется книга Питера Брукса «Метрики для управления ИТ-услугами» [5], которая является руководством по проектированию, созданию и использованию метрик и KPI в качестве механизма управления IT-услугами. За основу взят ряд принципов ITIL (IT Infrastructure Library -библиотека книг, описывающих лучшие практики на тему инфраструктуры информационных технологий [1, 7]) и стандарт ISO20000). Руководство «Бизнес-аналитика: ни шагу без Яндекса.Метрики!» содержит обзор по применению конкретного инструмента для конкретной цели: Яндекс Метрики для анализа конверсии и выручки сайта, эффективности рекламы, аудитории сайта и поведения посетителей.
Кроме того, существует достаточно большое количество статей, в которых содержится обзор, как самих метрик, так и способов их сбора, анализа и возможного применения, с поправкой на условия применения. Например,
статья «Метрики в SAFe»[4], содержит описание использования Scaled Agile Framework (SAFe) на различных уровнях - от уровня компании до уровня команды программистов[3].
В связи с большим количеством метрических показателей и возможных вариантов их применения, большинство опубликованных работ сводится к описанию выбора метрик (одной или многих) и условий их успешного (значительно реже, неудачного) применения. В целом, принципы и подходы к выбору метрических показателей недостаточно освещены в литературе, что частично восполняется в рамках данной статьи.
Кому и зачем это нужно?
Метрика в организационном управлении - численный показатель качества, эффективности процесса, обладающий свойствами функции расстояния. Другими словами, это переменная, измеренная на интервальной шкале. От правильного выбора метрик во многом зависит качество управленческих решений [13, 24], и по этой причине в менеджменте уделяется большое внимание разработке показателей, которые описывают бизнес-процессы организаций, а также формированию методик расчета этих показателей [17, 18, 23].
«Нельзя управлять тем, что невозможно измерить, но всего, что измеримо, можно достичь» - этот принцип отлично работает на конвейере или на заводе. При попытке оценить работу программиста или архитектора программного обеспечения возникают вопросы. Творческую работу не измерить количеством строчек кода или разработанных алгоритмов, равно как размером программы в мегабайтах или количеством страниц написанной документации.
Согласно Гражданскому кодексу Российской Федерации основной целью деятельности коммерческих компаний, в том числе, занимающихся разработкой ПО, является извлечение прибыли (ГК, статья 50, п.1), в силу чего основным показателем эффективности деятельности бизнеса является его прибыль или стоимость [13, 14, 15, 16, 22]. Если дела у компании идут хорошо, и основная цель выполняется, то вопросов ни у кого не возникает. Кризис и снижение продаж (и, как следствие, прибыли) являются основаниями для анализа и переоценки текущих процессов и результатов. Для ухода от субъективных оценок начинают использовать научные подходы к оценке процессов и результатов - их оцифровывают с помощью метрических показателей и анализируют с помощью методов статистического анализа [19, 20, 21].
Кроме кризисных компаний, потребность в таком анализе возникает у компаний с большим периодом окупаемости инвестиций. В сфере информационных технологий это чаще всего относится к разработке инновационных решений и крупных, корпоративных аппаратно-программных комплексов. Даже, если прибыль и способы её получения устраивают собственников и руководителей, это не повод отказываться от оценки происходящего. Ведь иногда «приходится бежать со всех ног, чтобы только остаться на том же месте! Если хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!» (Л. Кэррол - «Алиса в Зазеркалье»).
Анализ проблем: плохие метрики
Задачи, с которыми приходится сталкиваться руководителям команд разработчиков ПО на разных периодах своей трудовой деятельности, разнообразны. Если вчера это было развитие магистральных сетей связи, то сегодня - специализированное ПО для геологов-разведчиков, а завтра -создание ПО для интернет-магазинов.
Одним из путей, по которому часто идут руководители, различных по должностям разного уровня, квалификации и профильных знаний, - это адаптация собственного опыта к новым реалиям. Ожидаемый результат -работать не хуже, а лучше по отношению к предыдущему месту работы или задачам. Ещё сложнее, если в качестве вводного требования указывается необходимость улучшить некоторые, сформированные заранее метрики. Тем не менее, случаются ситуации, когда применение практик, хорошо себя зарекомендовавших ранее, приносит негативный результат.
Разнообразие решаемых задач требует их классификации. Среди огромного количества видов и способов классификации явлений и процессов обратим внимание на модель Кеневин [26]. Назначение этой модели - помочь человеку, принимающему решение, определиться с тем, в рамках какой среды он действует и в каких рамках ему нужно принять решение. Суть модели в том, что она делит окружающий мир на простые, сложные, комплексные и хаотические системы, особо выделяя промежуточные состояния, когда система переходит из одного состояния в другое.
Каждая из выделенных систем характеризуется определённым типом взаимосвязи между входными и выходными данными, причиной и следствием, степенью неопределённости и наличием опыта решения подобных задач. Работа в простых системах сводится к определению, какую именно типовую задачу следует решить. Наличие свободных ресурсов, опытной команды и понятного результата определяет формулу принятия решения:
«определяем - классифицируем - реагируем». Работа в сложных системах так же сводится к определению типа решаемой задачи, но отличается отсутствием опыта (или даже экспертизы) у команды. Характерным свойством сложных систем является необходимость привлечения узко квалифицированного специалиста. Формула принятия решения в сложных системах: «определяем - анализируем - реагируем». В комплексных системах изначально неизвестен конечный результат. У команды может быть опыт работы в похожих условиях, но итоговый результат будет определен эмпирически, через анализ промежуточных итераций и конечного результата. Формула принятия решения в комплексных системах: «измеряем - определяем - реагируем». Одним из распространенных типов объектов являются хаотичные системы. В таких системах новым является абсолютно всё, соответственно, отсутствует опыт команд и видение итогового результата. Наиболее подходящий пример таких систем — это инновационные проекты. Формула принятия решения в данном случае: «действуем - определяем - реагируем». Она определяется отсутствием возможности использовать эмпирический путь - опыт пока не наработан. Хаотичное состояние системы является краткосрочным, так или иначе, система мигрирует в одно из более устойчивых состояний.
Перенесение методов управления, характерных для одной системы, на условия другой системы является одним из основных источников принятия неверных решений. Вместе с методами управления переносят и способы оценки прогресса/достижения результата - метрики. Как следствие, руководители попадают в ситуацию, когда аналитика процесса является «заложником» используемых метрик: для нового процесса выбираются метрики, зарекомендовавшие себя ранее, но без учёта новых условий. В качестве примера, рассмотрим работу с параметром «velocity» в scram команде. Команда из пяти программистов выполняла Х очков историй («story-point») за двухнедельный спринт. После подключения в команду ещё двух человек и окончания периода шторминга команда стала стабильно (то есть в течении 5 и более спринтов) выполнять Х + 10 очков историй. Так как команда была продуктовой (результатом её труда - инкрементом - был продукт, которым пользовались конечные потребители), то количество выполненных очков историй было пропорционально количеству реализованных пользовательских историй и, как следствие, удовлетворённости пользователей. У руководителя (владельца продукта) сложилось мнение, что связь между количеством реализованных очков историй и эффективностью/качеством результата прямо-пропорциональная. Перейдя к решению новой задачи, руководитель взял на вооружение эту метрику и постарался увеличить количество очков историй, реализуемых командой.
Разница с предыдущим местом работы заключалась в том, что команда не являлась продуктовой в чистом виде. Над продуктом работали более десяти команд и увеличение вклада одной из них в общий результат оказалось не очевидным для руководителя. В попытке реализовать наибольшее количество задач команда перестала обращать внимание на операционные и функциональные связи с другими командами. Это проявлялось в том, что брались за задачи менее приоритетные, но с большей оценкой в очках историй, или рассматривали в качестве низкоприоритетной задачи запросы на ревью (проверки) кода от других команд.
Хорошие метрики
Мы привели пример плохого опыта и плохой метрики. Для определения хороших метрик уточним тип системы, в отношении которой вырабатывается метрика. Если речь идёт о конвейерном производстве, то оптимизация каждого элемента, как в примере выше, приведёт к улучшению работы в целом. Такой локальный оптимум будет возможен и экономически оправдан. В случае интеллектуального, творческого труда, локальная оптимизация приведёт к обратному эффекту. В хаотичных системах основной метрикой является скорость реакции на изменения. Другие качественные и количественные параметры начинают измеряться, когда система приходит в более стабильное состояние. Вторая часть проблемы — это сами метрики. Количество рекомендуемых метрик, согласно различным источникам [3, 4, 5, 6, 7, 8] для agile команд, находится в пределах 50, но их может быть и больше. Обычно метрики и их количество определяются опытом руководителя, его квалификацией и здравым смыслом. Выделяются ситуации, когда метрики определяются не необходимостью, а используемыми в компаниях инструментами в соответствии с расхожим выражением: «исторически сложилось», которое нужно запретить во всех компаниях, претендующих на успех. Анализ инструментов, используемых для сбора метрик, является самостоятельным вопросом и не входит в задачи данной статьи. Нас интересует ответ на вопрос, как же выбрать из 50 или 100 метрик 5-10 своих, которые нужны именно для конкретной решаемой задачи. Обратимся к законам взаимодействия со сложными системами, сформулированными Расселом Эйкаффом [9, 10]:
- для оптимизации системы нужно суб-оптимизировать один или несколько её элементов;
- если вы оптимизируете элементы системы, то вы суб-оптимизируете систему;
- элементы системы объединяются в группы, которые подчиняются первым двум законам.
Рассмотрим процесс проведения проверки кода (code review) несколькими (две и более) командами программистов, работающими над одним продуктом. Для оптимизации всей системы (общего продукта) необходимо деоптимизировать элементы системы (команды программистов). Каждый из разработчиков должен быть так недозагружен, чтобы при появлении запроса на проверку кода сразу его обработать.
Зависимость от весов оптимизируемых элементов отсутствует, так как итоговую ценность представляет вся система в целом, а не её части. Если одна или несколько команд имеют больший вес в общем продукте, то оптимизация работы только этих команд не приводит к оптимизации общего продукта. Необходим результат работы каждой команды.
Применение законов Эйкаффа противоречит принципу утилизации ресурсов, которым часто руководствуются при распределении задач между сотрудниками и сроков. При этом решается вопрос наличия очередей и задержек, а также увеличивается качество кода. Также сокращается область выборки, т.е. количество метрик, среди которых нужно определить целевые. Для команд, работающих в условиях высокой неопределённости в комплексных системах применимы метрики, которые оценивают систему в целом, а не локальные максимумы её компонент.
1 2 3
KPI
Подразделение 1
Задача 1
Задача 2
Задача 3
KPI
Подразделение 2
Задача 4
1
Задача 5
Задача 6
2
KPI (]pȣ>iis3
3
Рис. 1. Схема работы компании (составлено автором)
Для примера рассмотрим работу трёх подразделений одной компании и попробуем оценить их работу с помощью метрик. Примем следующие обозначения: ВО - время ожидания, ВР - время работы, ВПК - время переключения контекста, ЖЦЗ - время жизненного цикла задачи, ЖЦЗ = (ВР 1 + ВР 2 + ВР 3) + (ВО 1 + ВО 2 + ВО 3). Оценим работу подразделения по изменению ЖБЗ.
Пока решались атомарные задачи, а ВО было небольшим по сравнению с ВР (меньше 10%) ожиданием пренебрегали - ЖБЗ ~ (ВР 1 + ВР 2 + ВР 3). В сложных современных системах воздействие времени выросло. Кроме ВО, связанного непосредственно с блокировками (когда задача не может быть взята в работу до окончания работ по другой задаче), стало необходимо учитывать время на переключение контекста и количество блокированных команд. Таким образом, вес ВР остался функцией от ВР, а вес ВО стал функцией от ВО, которое включает время на переключение контекста и выявления количества заблокированных команд. ЖЦЗ = (ВР 1 + ВР 2 + ВР 3) + (ВПК 1 + ВПК 2 + ВПК 3) + (ВО 1 + ВО 2 + ВО 3).
Могут быть ситуации, когда ЖЦЗ может быть зафиксирован. Если мы не можем повлиять на ВО, а только на ВР, уменьшается качество результата и возникает (и даже увеличивается) риск появления ошибок.
Типовые задачи, метрики и решения
Результатом работы команды программистов является написанное ПО. У ПО могут быть разные функциональные назначения, технические параметры (время работы, количество используемых ресурсов, точность получаемого результата, т.п.), разные способы доставки до пользователя, но общее назначение едино - выполнение требований, зафиксированных в ТЗ (или любом другом способе постановки задачи). Поэтому независимо от того, сколько промежуточных этапов проходит ПО на пути от заказчика к пользователю (соответствуют они ГОСТу или коммерческому ТЗ), имеет смысл измерять только конечный продукт и его соответствие требованиям заказчика и потребностям пользователя. Любые управленческие решения, которые могут быть приняты, должны быть направлены на повышение эффективности общего процесса, без скатывания к локальным оптимизациям.
Типы метрик
Существует большое количество метрик. В соответствии с законом рынка, когда спрос рождает предложение, были придуманы и предложе-
ны метрики, которые позволяют показать локальную эффективность и игнорировать общую. Для того, чтобы сделать правильный выбор, имеет смысл разделить все метрики на группы и соотнести с потенциальными целями компаний-заказчиков:
• метрики - характеристики процесса;
• метрики - характеристики продукта;
• метрики удовлетворённости пользователей;
• метрики качества.
Метрики первой группы должны позволяют понять, насколько хорошо выполняется тот или иной процесс. Метрики этой группы наилучшим образом подходят для простых систем, с устоявшимися процессами, предполагающими стабильность, а не регулярные изменения. Как правило, они используются при высокой степени автономности этапов процесса и низкой операционной связанности.
Метрики второй группы показывают степень готовности продукта в целом. Метрики этой группы подходят для систем, в которых путь достижения результата изменялся и может изменяться и в дальнейшем. Как следствие этого, фиксация и оптимизация локальных участков может привести к деоптимизации системы в целом.
Таблица.
Типы метрик и их характеристики
Тип метрик Группа Владелец Формула
Прогресс выполнения (Implementation progress) Продукт/ Процесс Менеджер релиза/ Менеджер продукта Прогресс = Выполненные элементы/Запланированные элементы
Время выполнения (Lead Time) Продукт Владелец продукта Время = Количество итераций от момента начала работы до момента окончания работы
Загрузка команды (Team Load) Процесс Лидер команды/ линейный менеджер Загрузка = количество (шт.) планируемой работы за период/ среднее количество (шт.) выполненной работы за эталонный период (квартал, полугодие, год)
Время жизни ошибки (Bug life cycle Duration) Качество Менеджер по качеству/менеджер по ошибкам Время = Дата закрытия ошибки - дата создания ошибки
Источник: составлено автором на основе [5, 11] и собственных разработок.
Метрики третьей группы подходят для систем, в рамках которых продукты и/или услуги предоставляются в виде сервиса (техподдержка, сопровождение, т.п.).
Метрики четвёртой группы используются для оценки соответствия полученных результатов тем стандартам качества, которые приняты в кампании.
Основные типы метрик представлены в таблице.
Представленный в таблице список типов метрик не полон. Он может и должен дополняться, исходя из реалий каждой компании. Не имеет принципиального значения, какие и сколько метрик используются; важно, чтобы выбранные метрики соответствовали целям и задачам команды и компании.
Сбор метрик
Кроме важности и актуальности самих метрик, их соответствия выбранной цели компании, значимую роль играет возможность и удобство сбора метрик в автоматическом режиме. Если метрика показывает актуальное значение необходимого параметра, отвечает запросу бизнеса, используется при принятии решения, но при этом для её сбора и поддержания в актуальном состоянии требуется время, сопоставимое с реализацией другой задачи, вероятность того, что она скоро перестанет поддерживаться в актуальном состоянии, стремится к нулю: Р (х Ц t2) = 0, при t = t , где х - метрика, Р - вероятность поддержания метрики в актуальном состоянии, t - время необходимое на сбор метрики, ^ - время необходимое на выполнение актуальной задачи, по итогам которого собирается метрика.
Как уже отмечалось ранее, обзор инструментов сбора и анализа метрических показателей не является темой данной работы. Однако, подчеркнем, что возможность автоматизированного сбора и поддержания в актуальном состоянии метрических показателей для систем с высокой степенью неопределённости, является обязательным.
Анализ метрик
Анализ метрических показателей проводится на основании полноты и достоверности.
Полнота метрик означает, что количество собранных метрик и временной интервал, в течение которого метрики были собраны, достаточны для принятия необходимого управленческого решения.
Достоверность означает, что собранные метрики не имеют намеренных искажений, искажений при сборе и обработке данных.
Полные и достоверные метрические данные анализируются, например, с помощью методов статического анализа. Данный вопрос также не входит в состав данной работы.
Принятие решений
Основное предназначение метрик следует из определения метрики, - оценка качества и эффективности процесса. Крайне редко оценка метрик может производиться мгновенно, по факту изменения метрики. Например, если увеличилось количество ошибок в исходном коде, которые не прошли непрерывную интеграцию, или произошла поломка критического оборудования, которое значительно увеличивает CAPEX (CAPital Expenditure - капитал, использующийся компаниями для приобретения или модернизации физических активов (жилой и промышленной недвижимости, оборудования, технологий)). В большинстве случаев для того, чтобы принять решение, необходимо следить за динамикой изменения значений метрических показателей.
Сбор и анализ метрических показателей нацелены на принятие управленческих решений. Но бывают ситуации, когда по разным причинам управленческое решения принять нельзя. Сложность организационной модели (моделей) и текущая зрелость организации могут не совпадать. Предполагаемая организационная модель может быть адекватной с функциональной точки зрения, однако сложившиеся реалии могут помешать компании завершить реализацию такой модели. В такой ситуации сбор метрик становится бесполезным и даже вредным с экономической точки зрения.
Без достаточных для понимания знаний и навыков, а также без поддержки руководством, тех метрик, которые аналитики определили, как необходимые, усилия на их сбор и анализ будут нести убытки и пойдут во вред компании. Нередко приходится делать выбор между двумя и более вариантами, отдавая предпочтение тем метрикам, которые имеют наибольшую вероятность реализации в текущих условиях или в условиях возможных изменений.
Заключение
Вопрос выбора и применения метрических показателей в большинстве публикаций описывается фрагментарно и узконаправленно. Общие принципы и подходы к выбору метрических показателей освещены в литературе недостаточно. Как было показано в статье, выбор метрик и оценка их эффективности включают:
1. Определение типа среды, в рамках которой действует компания.
2. Согласованность оптимизации подсистемы с оптимизацией системы в целом.
3. Возможности автоматизированного сбора метрик.
4. Профессиональный анализ полученных данных.
5. Принятие решений, на основе проведённого анализа. Автоматизированный сбор метрик и анализ полученных данных являются отдельными большими вопросами. Их анализ не входит в состав данной работы.
Оптимизацией выбора метрических показателей предлагается считать набор действий, направленных на создание необходимого и достаточного набора метрических показателей, связанных с общим результатом продукта и компании и способных стать основой принятия эффективного управленческого решения, возникнет необходимость корректировки.
При выборе метрик для оценки сотрудника, подразделения или компании в целом часто используется только предыдущий опыт руководителя команды программистов и, реже, руководителей организации или компании. Такой подход несёт риск несоответствия предыдущего опыта новым условиям.
Типовые задачи разработчика ПО подразделятся на технические этапы (проектирование, разработка, тестирование, т.д.). При выделении метрики для оценки эффективности каждого этапа может повыситься риск локальных оптимизаций. Кроме того, если зона ответственности руководителя смещается от целого к частному, от эффективности компании к эффективности подразделения, то риск выбора неверных метрик кратно повышается. Метрики, которые оценивают частичный результат, рассматриваются как неверные - они относятся к части функционала, подразделению в рамках компании и т.п. В результате повышается вероятность принятия управленческого решения в соответствии с интересами подразделения, а не компании или продукта в целом. По этой причине использования частных метрик следует избегать.
Список литературы
1. Давыдов С. Что значат метрики для Agile команд? https://habr.com/ru/ post/419683/ (дата обращения 23.02.2023)
2. Лоскутникова Н. Модель «Кеневин» - теория запутанности или новый инструмент решения задач? https://kachestvo.pro/kachestvo-upravleniya/ mstmmenty-menedzhmenta/model-kenevm-teoriya-zaputarmosti-ffl-novyy-instrument-resheniya-zadach/ (дата обращения 23.02.2023)
3. Трещилов А. Основные метрики ART на старте. https://scrumtrek.ru/blog/ enterprise-agility/4885/osnovnye-metriki-art-safe-na-starte/ (дата обращения 23.02.2023)
4. Хохрин К. Метрики в SAFe. https://scrumtrek.ru/blog/enterprise-agility/2013/ safe-metrics/ (дата обращения 23.02.2023)
5. Брукс П. Метрики для управления ИТ-услугами. Москва: Альпина Бизнес Букс, 2008. 283 с.
6. Jerry Z. Muller, The Tyranny of Metrics, 2018, Princeton University Press, 240 p.
7. Kalkura A. What Does Metrics Mean For Agile Teams. https://www. knowledgehut.com/blog/agile/what-does-metrics-mean-for-agile-teams (дата обращения 23.02.2023)
8. Maurya A. Scaling Lean: Mastering the Key Metrics for Startup Growth, 2016, Portfolio, 304 p.
9. Ramos C., Pavlicenko I. Creating Agile Organizations, 2022, Addison-Wesley Professional, 480 p.
10. Russell L. Ackoff, Herbert J. Addison, Sally Bibb, Management F-laws: How Organizations Really Work, 2007, Triarchy Press, 180 р.
11. Scrum.org, Evidence-based management guide. https://scrumorg-website-prod. s3.amazonaws.com/drupal/2018-09/EBM_Guide%20September%202018.pdf (дата обращения 23.02.2023)
12. Долженко Р.А. Сущность и оценка эффективности использования оптимизационных технологий «Лин» и «Шесть сигм» // Вестник Омского университета. Серия: Экономика. 2014. № 1. С. 25-33.
13. Богатырева С.В. Экономическая эффективность как основа формирования управленческих решений / С. В. Богатырева, А. Б. Титов, М. Ю. Куприянова // Экономика и менеджмент систем управления. 2016. № 2-1(20).
С. 116-122.
14. Вертакова Ю.В. Оценка и управление стоимостью предприятия : учебное пособие / Ю. В. Вертакова, О. Е. Пирогова, В. А. Плотников. Курск : Юго-Западный государственный университет, 2017. 160 с.
15. Пирогова О.Е. Возможности применения методов оценки конкурентоспособности в системе управления стоимостью торгового предприятия // Теория и практика сервиса: экономика, социальная сфера, технологии. 2015. № 4(26). С. 60-64.
16. Пирогова О.Е. Фундаментальная стоимость - основа формирования системы управления развитием торгового предприятия // Экономика и управление. 2015. № 5(115). С. 49-55.
17. Степанова Т.В. Оценка социально-экономической эффективности обслуживания в сфере общественного питания // Образование, экономика, общество. 2013. № 5-6(39-40). С. 55-57.
18. Бойко И.А. Проблема положительного социального эффекта цифро-визации бизнес-процессов / И. А. Бойко, А. В. Захаренко, С. Е. Барыкин // Неделя науки СПбПУ : Материалы научной конференции с международным участием. Институт промышленного менеджмента, экономики и торговли. В 3-х частях, Санкт-Петербург, 18-23 ноября 2019 года. Том Часть 2. Санкт-Петербург: Федеральное государственное автономное образовательное учреждение высшего образования «Санкт-Петербургский политехнический университет Петра Великого», 2019. С. 431-434.
19. Тушавин В.А. Развертывания функции качества для процессов технической поддержки информационных систем // Актуальные проблемы экономики и управления. 2014. № 4(4). С. 94-97.
20. Тушавин В.А. Методы оценки комплексного показателя качества в сфере услуг // Экономика и менеджмент систем управления. 2014. № 4-1(14). С. 202-208.
21. Тушавин В.А. Робастный подход к оценке комплексного показателя качества ИТ-услуг // Системы управления и информационные технологии. 2014. № 4(58). С. 92-95.
22. Митяшин Г.Ю. Применение концепции совокупной стоимости владения к анализу жизненного цикла спортивного сооружения / Г. Ю. Митяшин, Е.
B. Стельмашонок // Экономика и предпринимательство. 2020. № 4(117).
C. 747-751. https://doi.Org/10.34925/ElP.2020.117.4.162
23. Котляров И.Д. Проблемы оценки эффективности аутсорсинга // Вестник Института экономики Российской академии наук. 2017. № 6. С. 87-99.
24. Богатырева С.В. Генезис классической формулы экономической эффективности в принятии управленческих решений / С. В. Богатырева, А. Б. Титов, М. Ю. Куприянова // Международный технико-экономический журнал. 2017. № 2. С. 55-62.
25. Долженко Р.А. Стратегия развития производственных систем в области управления процессами и управления деятельностью организации в современных условиях развития маркетингового подхода / Р. А. Долженко, А. А. Гусакин // Актуальные проблемы современности: наука и общество. 2020. № 4(29). С. 26-33.
26. The Cynefin Framework. https://thecynefin.co
References
1. Davydov S. What do metrics mean for Agile teams? https://habr.com/ru/ post/419683/
2. Loskutnikova N. The Kenevin model - a theory of entanglement or a new tool for solving problems? https://kachestvo.pro/kachestvo-upravleniya/instru-menty-menedzhmenta/model-kenevin-teoriya-zaputannosti-ili-novyy-instru-ment-resheniya-zadach/
3. Treshchilov A. Basic ART metrics at the start. https://scrumtrek.ru/blog/enter-prise-agility/4885/osnovnye-metriki-art-safe-na-starte/
4. Khokhrin K. Metrics in SAFe. https://scrumtrek.ru/blog/enterprise-agility/2013/ safe-metrics/
5. Bruks P. Metriki dlya upravleniya lT-uslugami [Metrics for IT service management]. Moscow, Alpina Business Books, 2008, 283 p.
6. Jerry Z. Muller, The Tyranny of Metrics, 2018, Princeton University Press, 240 p.
7. Kalkura A. What Does Metrics Mean For Agile Teams. https://www.knowledge-hut.com/blog/agile/what-does-metrics-mean-for-agile-teams
8. Maurya A. Scaling Lean: Mastering the Key Metrics for Startup Growth, 2016, Portfolio, 304 p.
9. Ramos C., Pavlicenko I. Creating Agile Organizations, 2022, Addison-Wesley Professional, 480 p.
10. Russell L. Ackoff, Herbert J. Addison, Sally Bibb, Management F-laws: How Organizations Really Work, 2007, Triarchy Press, 180 p.
11. Scrum.org, Evidence-based management guide. https://scrumorg-website-prod. s3.amazonaws.com/drupal/2018-09/EBM_Guide%20September%202018.pdf
12. Dolzhenko R.A. Vestnik Omskogo universiteta. Seriya: Ekonomika, 2014, no. 1, pp. 25-33.
13. Bogatyreva S.V., Titov A.B., Kupriyanova M.Yu. Ekonomika i menedzhment sistem upravleniya, 2016, no. 2-1(20), pp. 116-122.
14. Vertakova Yu.V. Otsenka i upravlenie stoimost'yu predpriyatiya : uchebnoe posobie [Estimation and management of enterprise value: textbook] / Yu. V. Vertakova, O. E. Pirogova, V. A. Plotnikov. Kursk: Southwestern State University, 2017, 160 p.
15. Pirogova O.E. Teorzya ipraktika servisa: ekonomika, sotsial'naya sfera, tekh-nologii, 2015, no. 4(26), pp. 60-64.
16. Pirogova O.E. Ekonomika i upravlenie, 2015, no. 5(115), pp. 49-55.
17. Stepanova T.V. Obrazovanie, ekonomika, obshchestvo, 2013, no. 5-6(39-40), pp. 55-57.
18. Boyko I.A., Zakharenko A.V., Barykin S.E. Nedelya nauki SPbPU: Materialy nauchnoy konferentsii s mezhdunarodnym uchastiem. Institutpromyshlennogo menedzhmenta, ekonomiki i torgovli. V3-kh chastyakh, Sankt-Peterburg, 18-23 noyabrya 2019goda. Tom Chast'2 [SPbPU Science Week: Materials of a scientific conference with international participation. Institute of Industrial Management, Economics and Trade. In 3 parts, St. Petersburg, November 18-23, 2019. Volume Part 2]. St. Petersburg: Peter the Great St. Petersburg Polytechnic University, 2019, pp. 431-434.
19. Tushavin V.A. Aktual'nye problemy ekonomiki i upravleniya, 2014, no. 4(4), pp. 94-97.
20. Tushavin V.A. Ekonomika i menedzhment sistem upravleniya, 2014, no. 4-1(14), pp. 202-208.
21. Tushavin V.A. Sistemy upravleniya i informatsionnye tekhnologii, 2014, no. 4(58), pp. 92-95.
22. Mityashin G.Yu., Stel'mashonok E.V. Ekonomika ipredprinimatel'stvo, 2020, no. 4(117), pp. 747-751. https://doi.org/10.34925/ElP.2020.117.4.162
23. Kotlyarov l.D. VestnikInstituta ekonomikiRossiyskoy akademii nauk, 2017, no. 6, pp. 87-99.
24. Bogatyreva S.V., Titov A.B., Kupriyanova M.Yu. Mezhdunarodnyy tekhniko-eko-nomicheskiy zhurnal, 2017, no. 2, pp. 55-62.
25. Dolzhenko R.A., Gusakin A.A. Aktual'nye problemy sovremennosti: nauka i obshchestvo, 2020, no. 4(29), pp. 26-33.
26. The Cynefin Framework. https://thecynefin.co
ДАННЫЕ ОБ АВТОРЕ
Клинков Евгений Владимирович, аспирант
Санкт-Петербургский государственный экономический университет наб. канала Грибоедова, 30-32А, г. Санкт-Петербург, 191023, Российская Федерация Evgeny_klinkov@mail.ru
DATAABOUT THE AUTHOR Evgeny V. Klinkov, graduate student
UNECON - Saint Petersburg State University of Economics
30-32A, Griboedov canal emb., St. Petersburg, 191023, Russian Federation
Evgeny_klinkov@mail.ru
Поступила 18.06.2023 Received18.06.2023
После рецензирования 10.08.2023 Revised10.08.2023
Принята 21.08.2023 Accepted21.08.2023
