CC BY
149УДК 005.8:65.015
МЕТОДИКА ОЦЕНКИ ВКЛАДА УЧАСТНИКОВ ПРОЕКТНОЙ КОМАНДЫ В ДОСТИЖЕНИЕ ЦЕЛЕЙ ИТ-ПРОЕКТА
Никулина Наталья Олеговна
к.т.н., доцент кафедры автоматизированных систем управления, e-mail: [email protected] Малахова Анна Ивановна
к.т.н., доцент кафедры автоматизированных систем управления, e-mail: [email protected] ФГБОУ ВО «Уфимский государственный авиационный технический университет»,
450008, г. Уфа, ул. К. Маркса, 12 Баталова Валерия Игоревна ведущий специалист отдела тестирования управления разработки ПО, e-mail: valeral evr@ gmail.com ООО ИК «СИБИНТЕК», 450047, г. Уфа, ул. Бакалинская, 9/8 Аннотация. Конкурентоспособность ИТ-компании, основной деятельностью которой является разработка и внедрение программного обеспечения, в современных условиях определяется ее возможностью реализовывать несколько проектов одновременно, предоставляя потребителям качественный продукт в минимальные сроки с минимальными затратами. Однако особенности разработки программного обеспечения (нематериальность конечного продукта, зависимость от взаимоотношений между участниками команды проекта, сжатые сроки и ограниченное число ресурсов), не позволяют эффективно отслеживать ход выполнения проекта с помощью общепринятых методик. Поэтому необходима разработка альтернативного инструмента оценки состояния ИТ-проектов, а также способа своевременного выявления причин изменения отдельных показателей проектов. Проблема может быть решена путем совместного применения методов процессного и проектного управления в рассматриваемой предметной области. В частности, предлагается разработать систему сбалансированных показателей ИТ-компании, опираясь не только на показатели структурных подразделений, но и на показатели ИТ-проектов. В свою очередь, система сбалансированных показателей каждого ИТ-проекта увязывается с функциональной структурной декомпозицией работ каждой из итераций разработки ПО, ведущейся с использованием Scrum-методологии. Это позволяет на уровне отдельных показателей ИТ-проекта установить роль и вклад каждого из участников проектной команды в достижение оперативных целей проекта и стратегических целей ИТ-компании в целом. Предлагаемая методика применима для установления приоритетов параллельно выполняющихся проектов с целью своевременного перераспределения ресурсов, а также обоснования распределения бюджета ИТ-компании по проектам вплоть до отдельных сотрудников с учетом системы грейдов в рамках профессионального стандарта проектных ролей.
Ключевые слова: ИТ-проект, сбалансированная система показателей, проектная команда, структурная декомпозиция работ проекта, ключевые показатели эффективности, матрица ответственности, роли участников проектной команды.
Цитирование: Никулина Н. О., Малахова А. И., Баталова В. И. Методика оценки вклада участников проектной команды в достижение целей ИТ-проекта // Информационные и математические технологии в науке и управлении. 2021. № 2 (22). С. 94 - 104. DOI:10.38028/ESI.2021.22.2.010
Введение. Главной целью любой компании является предоставление потребителю наиболее качественного продукта в минимальные сроки с минимальными затратами. Симбиоз этих условий дает лучший результат как для компании, так и для заказчика. Однако в процессе реализации проекта необходимо отслеживать соблюдение множества ограничений, что представляет особую сложность для некоторых предметных областей, например, для консалтинговой компании, занимающейся разработкой и поддержкой
программного обеспечения (ПО) и использующей гибкие методологии разработки. Высокая степень неопределенности, присущая ИТ-проектам, не позволяет на ранних этапах спланировать все работы заранее, а затем отслеживать состояние проекта с помощью известных методик, нашедших широкое применение в промышленном производстве и строительстве (например, методики оценки освоенного объема). Часто дело осложняется необходимостью отслеживания состояния параллельно выполняющихся проектов, каждый из которых проходит свой жизненный цикл в соответствии со спиральной моделью. Поэтому необходим альтернативный инструмент оценки состояния проектов, а также способ выявления причин изменения отдельных показателей проектов.
Жизненный цикл ИТ-проектов, вне зависимости от предназначения ПО, состоит из следующих этапов: разработка, модификация функциональности, интеграция, сопровождение. Сотрудники привлекаются для решения поставленных задач согласно своей проектной роли в соответствии с применяемой в ИТ-компании методологией разработки на срок реализации проекта, указанный в договоре с заказчиком. Стремление руководства компании снизить издержки, высокая текучесть кадров зачастую приводят к невозможности обеспечить каждый из проектов высококвалифицированными трудовыми ресурсами в полном объеме. Поэтому ключевые сотрудники, хорошо изучившие предметную область и имеющие опыт работы на аналогичных проектах, привлекаются в несколько проектов одновременно. Таким образом, многие сотрудники работают в режиме многозадачности, что отрицательно сказывается на производительности сотрудника: время, посвящаемое создающей стоимость работе, быстро сокращается, когда человек занимается более чем двумя задачами одновременно (рис.1) [1]. В основном это связано с тем, что значительное количество энергии и времени затрачивается на переключение между задачами, погружение в контекст задачи и взаимодействие с участниками разных проектных команд.
Однако степень данного влияния очень индивидуальна и зависит как от характера человека и его навыков тайм-менеджмента, так и от уровня сложности проектов. Для одного сотрудника может быть вполне комфортным выполнение задач на трех-четырех проектах одновременно, в то время как для другого участие в двух параллельных
Число одновременно выполняемых задач J J 1
1 о проектах уже становится
Рис. 1. Влияние многозадачности на г j
непосильной задачей.
производительность труда
При этом необходимость участия одного сотрудника в нескольких проектах одновременно в любом случае приводит к его перегрузке, что негативным образом влияет на показатели каждого проекта.
В соответствии с вышесказанным, целью исследования является разработка методики анализа влияния загрузки сотрудника на ключевые показатели эффективности (KPI - Key Performance Indicators) одновременно выполняемых им проектов. Результаты такого анализа необходимы для одного из основных этапов организации поддержки принятия коллективных решений - определения взаимодействующих проектов и расстановки приоритетов в случае выявления конфликтов за выделяемые ресурсы [2]. Применение методики позволит связать
изменения значений KPI по проектам сотрудника с общей загрузкой сотрудника, что даст лицу, принимающему решения (ЛПР), информацию о необходимости перераспределения ресурсов между проектами в пользу улучшения состояния одного или нескольких проектов.
1. Общие принципы разработки ИТ-проектов в консалтинговой компании. Вначале необходимо определиться с тем, каким образом фиксировать деятельность сотрудников на параллельных проектах по разработке ПО. В большинстве своем в проектных командах применяются гибкие методологии разработки семейства Agile [3], чаще всего Scrum. Применение этой методологии позволяет за фиксированные небольшие промежутки времени, называемые спринтами (sprints), предоставлять заказчику работоспособный продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет [4]. Согласно Scrum, в проектной команде выделяются следующие роли: владелец продукта, скрам-мастер, команда создания продукта. Команда продукта в идеале должна представлять из себя взаимозаменяемых специалистов, то есть, внутри команды должна быть только одна роль - developer. Других должностей, ролей, подкоманд быть не должно. Однако зачастую полное следование принципам Scrum в данном аспекте невозможно, так как каждый из работников, являющихся членом команды продукта, имеет основную квалификацию, соответствующую профессиональным стандартам и зафиксированную в трудовых договорах и штатном расписании ИТ-компании (разработчик, тестировщик, аналитик). Каждый участник проекта может иметь как профессиональную, так и организационную роль, поддерживающую процесс [5]. Например, в одном проекте сотрудник может занимать роли архитектора системы и разработчика, а в другом - только разработчика или тестировщика. Таким образом, на каждом из этапов в итерации разработки сотрудник вносит свой вклад в соответствии с ролями, которые он выполняет в проекте.
Проектная команда разрабатывает функциональность итерационно в рамках спринтов. Так или иначе, спринт имеет типовую структуру и чаще всего сводится к классическим последовательным этапам жизненного цикла ПО. Деятельность в рамках этих этапов можно описать с помощью функциональной структурной декомпозиции работ (СДР, или WBS -Work Breakdown Structure) - представления проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции [6, 7]. СДР разрабатывается на стадии инициации проекта и предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей. Возможно построение СДР в различных аспектах - продуктовом, функциональном, организационном либо смешанном. Функциональный подход с точки зрения планирования деятельности наиболее интересен, поскольку в качестве элементов СДР выбираются операции технологического цикла производства продукта проекта. Далее для каждого из элементов СДР назначается длительность, сроки, ограничения, а также ресурсы. В предлагаемой статье описывается СДР для типовой итерации по разработке ПО, а в качестве ресурсов приведены вышеописанные проектные роли.
2. Методика оценки вклада участников проектной команды в достижение целей ИТ-проекта. Разрабатываемая методика включает алгоритм определения влияния загрузки сотрудника на состояние его проектов. Приведенные в методике показатели и элементы, а также количественные значения характерны для исследуемого объекта. Для применения в реальных условиях требуется конфигурирование и настройка под конкретный проект с учетом методов управления, принятых в ИТ-компании.
Рис. 2. Система сбалансированных показателей типового проекта по разработке ПО
Шаг 1. Составить систему сбалансированных показателей (ССП) [8] типового для рассматриваемой ИТ-компании проекта по разработке ПО (рис. 2). ССП представляет собой трехуровневую иерархию целей проекта: уровня компании, уровня проектного менеджмента, уровня исполнителей задач [9]. Необходимо выделить цели каждого уровня и определить ключевые показатели эффективности, отражающие ход достижения цели
Шаг 2. Составить функциональную СДР для итерации разработки ПО в соответствии с применяемой методологией (в данном случае, Scrum). На рис. 3 представлена функциональная СДР одной итерации разработки ПО, включающей работы, выполняемые циклично с периодичностью 2 недели.
Рис. 3. Функциональная СДР одной итерации разработки ПО
Шаг 3. Составить перечень проектных ролей. Выделение проектных ролей возможно с различных точек зрения [4, 10].
С одной стороны, важно определить функциональные обязанности каждого участника проектной команды, связанные с определенной профессиональной деятельностью -образованием, специализацией, полученными знаниями и навыками. С этой точки зрения существуют следующие роли, которые исполняют участники проектных команд в ИТ-компаниях: архитектор системы, тимлид команды аналитики, аналитик, тимлид команды разработки, программист, тестировщик, эксперт.
С другой стороны, существует разделение обязанностей участников проектной команды с точки зрения организации процесса проектирования и разработки ПО. Этот набор ролей определяется выбранной методологией разработки ПО. В случае использования наиболее популярной методологии Scrum перечень ролей будет следующим:
• владелец продукта (Product Owner) - отвечает за список требований к продукту и результат работы команды;
• скрам-мастер (Scrum Master) - отвечает за организацию эффективного процесса разработки;
• команда создания продукта (Development Team) - самоорганизующаяся кросс-функциональная команда, которая на выходе каждой итерации создает потенциально продаваемый вариант продукта.
Шаг 4. Определить тип и степень ответственности отдельных проектных ролей за каждый из элементов функциональной СДР.
Необходимо выделить набор типов ответственности для элементов СДР в соответствии со спецификой рассматриваемого проекта. Для каждого из типов ответственности необходимо определить степень ответственности различных проектных ролей. В рамках данного исследования выделен перечень степеней ответственности (табл. 1). В модель расчета введены следующие ограничения:
• для каждого элемента СДР определены по одному ответственному, исполнителю, контролеру, а также выделены два консультанта - владелец продукта и скрам-мастер;
• для типа ответственности Наблюдатель определен вес 0.
Таблица 1. Степень ответственности за элементы СДР
Тип Описание Доля участия в КР1
О Ответственный - полностью отвечает за исполнение этапа/задачи, вправе принимать решения по способу реализации; 0,4
И Исполнитель - решает задачу, не несет ответственности за выбор способа её решения, но отвечает за качество и сроки реализации; 0,3
Кр Контролер - контролирует выполнение задач, несет ответственность; 0,2
К Консультант - оказывает консультации в ходе решения задач проекта по мере обращения к нему, не несет ответственности; 0,1
Н Наблюдатель - находится в курсе решения задач проекта, не вмешиваясь в его ход, не несет ответственности. 0
Далее необходимо определить, какую ответственность каждая из ролей несет за отдельные элементы функциональной СДР (табл. 2). Для упрощения расчетов принято, что на элементах СДР зафиксированы по одному ответственному, исполнителю, контролеру. Также принято, что на каждом из элементов СДР выделены два консультанта - владелец продукта и скрам-мастер, так как они должны быть вовлечены в процесс на каждом этапе разработки.
Таблица 2. Матрица ответственности на элементах СДР.
№ Участники (роли на проекте)
Элемент СДР Владелец продукта Команда создания продукта
Тимлид команды аналитики Аналитик Архитектор системы Тимлид команды разработки Разработчик Тестировщик Эксперт предметной области Скрам-мастер
1 Анализ требований Кр О И К Н Н Н Н Кр
2 Проектирование Кр К Н О И Н Н Н Кр
3 Разработка Кр Н Н К О И Н Н Кр
4 Тестирование Кр Н Н Н К И О Н Кр
5 Поставка обновлений Кр К Н Н О И Н Н Кр
6 Техническая поддержка Кр Н О К К И К Н Кр
Цели KPI Доля вклада в KPI на каждом этапе СДР |
1 VP- 1 уровень 3 уровень Анализ требований Проектирование Разработка Тестирование Поставка обновлений Техническая поддержка
о f S X л ч я X О X Й" £ X £ Увеличение количества функциональности Улучшение проектной интеграции Аккуратность оценки задачи 0,8 0,2 - - ■
Время сгорания [burnout time) 1 - - - -
Улучшение взаимодействия с заинтересованными сторонами Доля времени, посвященного общению с заказчиком 0,7 0,3 - - -
Время от появления идеи доугверндения требований 0,8 0,2 - -
Повышение квалификации трудовых ресурсов Квалификация сотрудника на проекте [число реализованных у.е. функциональности -у.е.дефектов) - - 1 - - -
Риски Снижение возможности возникновения рисков Повышение качестеа функциональности Коэффициент технического долга - 0,1 0,5 0,3 - -
Плотность дефектоЕ - - 1 - - -
Количество дефектов, попэеших в релиз - ■ - 1 ■ ■
Повышение стабильности требований Индекс стабильности бэклога спринта 0,5 0,4 - - ■ ■
с о О Доля функциональных доработок по причине появления новых требований 1 - - - - -
а ■и к 5 6 о Ресурсы Снижение количества используемых ресурсов Снижение расходов на материалы Количество бумажных дубликатое документоЕ 0,5 0,2 од - -
Доля документов общего доступа от общего числа документоЕ 0,5 0,2 - од - -
5 2 X Я 6 Улучшение внутри командного взаимодействия Улучшение проектных коммуникаций Эффективностьпотока ОД ОД ОД од ОД ОД
и т 2 4J Е Z Доля времени совместной работы, % ат времени спринта ОД 0,2 ОД од ОД ОД
Сроки Снижение времени реализации и поставки функциональности Повышение эффективности С1 и СО Время от коммитинга к развертыЕанию [CTD-CommitTo Deploy) - - 0,5 од од -
Э Z а Уменьшение времени исправления дефектов Время исправления дефекта важности "Критический" - 1 - -
а с Время исправления дефекта важности "Высокий" - - 1 - - -
Время исправления дефекта важности "Средний" - 1 - -
Время исправления дефекта важности "Низкий" - - 1 - - -
Повышение производительности команды разработки Время выполнения у.е. функциональности [StoryPoint) - 1 - -
Стоимость Сн ижен и е стой мости реализации и поставки функциональности Снижение расходов на лицензии Расход на лицензии на ly.e. функциональности [StoryPoint) 0,2 - 0,5 - од -
Снижение расходов на содержание команды Расход на содержание команды на ly.e. функциональности [StoryPoint) ОД 0,2 ОД од од ОД
Сн ижен и е трудо затр ат Расходы на трудозатраты на 1 у.е. (StoryPoint) 0,2 0,2 од од од од
Рис. 4. Доля вклада в КР1 на каждом из этапов итерации разработки ПО
Шаг 5. Определить вклад в проектные КР1 на каждом из этапов/элементов СДР. Оценка вклада в КР1 на разных этапах итерации разработки ПО (рис. 4) проводится экспертным путём, так как для каждого проекта эти значения могут быть индивидуальными. Сумма вкладов на каждом из этапов СДР (общий вклад в КР1) должна быть всегда равна 1. Пример экспертной оценки для типового проекта приведен в табл. 3.
Шаг 6. Вычислить коэффициенты участия каждой из проектных ролей в отдельных КР1 проекта.
Зная долю участия в КР1 в соответствии с типом ответственности, а также вклад в КР1 на каждом из этапов разработки, становится возможным вычислить коэффициент участия проектных ролей в конкретных КР1 (1):
^уч в КР1 = 3=1(^1 х (1)
где Wi - доля вклада в КР1 на /-ом этапе (рис. 4);
Л - доля участия типа ответственности проектной роли в формировании КР1 (таблица 1).
В результате определяются коэффициенты участия проектных ролей в формировании проектных КР1. В качестве примера в табл. 3 приведен расчет вклада проектных ролей в два КР1.
Таблица 3. Коэффициенты участия проектных ролей в КР1
№ Участники (роли на проекте)
КР1 Владелец продукта Команда создания продукта
Тимлид команды аналитики Аналитик Архитектор системы Тимлид команды разработки Разработчик Тестировщик Эксперт предметной области Скрам-мастер
1 Аккуратность оценки задачи 0,1 0,34 0,24 0,16 0,06 - - - 0,1
2 Время от коммитинга к развертыванию 0,1 0,02 - 0,06 0,34 0,3 0,08 - 0,1
Шаг 7. Проанализировать зависимость значений КР1 отдельных проектов от общего количества закрепленного за сотрудником КР1 всех проектов.
Владение информацией о том, какие роли выполняет сотрудник на каждом из параллельных проектов, позволяет оценить его загрузку и значения связанных КР1. Так, например, сотрудник был занят в двух проектах, а затем его привлекли в третий проект, причем для выполнения двух проектных ролей одновременно. За сотрудником закреплены определенные КР1 по каждой из его ролей на определенных этапах. С течением времени можно заметить отрицательную динамику: увеличение количества КР1 для этого сотрудника приводит к более низким значениям его КР1 на одном из старых проектов. Эта информация помогает ЛПР вовремя среагировать и пересмотреть распределение ресурсов в пользу наиболее приоритетных проектов.
Заключение. Выбор КР1 и установление связи между ними имеет смысл в контексте достижения целей ИТ-компании, поэтому разработанная система сбалансированных показателей, представленная в виде стратегической карты (рис. 2), должна регулярно пересматриваться и корректироваться в зависимости от согласованной оценки
краткосрочных, среднесрочных и долгосрочных целей. Цели ИТ-компании достигаются за счет выполнения ИТ-проектов и поддерживающих их бизнес-процессов [11], в связи с чем неизбежны конфликты за ограниченные человеческие ресурсы. Предлагаемая методика оценки вклада участников проектной команды в достижение целей ИТ-проектов применима для:
• выявления необходимости приоритизации параллельно-выполняющихся проектов для своевременного перераспределения ресурсов;
• распределения бюджета по проектам и отдельным сотрудникам: например, премирование за достижение определенных значений КР1 в соответствии с коэффициентом вклада в этот показатель;
• разработки системы градации в рамках профессионального стандарта проектных ролей; например, назначение уровней в соответствии с достигнутым значением/порогом КР1.
Благодарности. Работа выполнена при поддержке РФФИ (проект № 19-08-00937 «Методы и модели интеллектуальной поддержки принятия решений при управлении программными проектами, реализуемыми в среде производственных предприятий»).
СПИСОК ЛИТЕРАТУРЫ
1. Clark, K. B., and S. C. Wheelwright. Managing New Product and Process Development: Text and Cases. NY: Free Press. 1993. 896 p.
2. Черняховская Л. Р., Малахова А И., Никулина Н. О., Баталова В. И. Информационно-аналитическая поддержка принятия коллективных решений с использованием интеллектуальных технологий // Информационные технологии в управлении: труды XIII Всеросс. мультиконференции по проблемам управления. СПб: АО «Концерн «ЦНИИ «Электроприбор». 2020. С. 88-91.
3. Кон М. Agile. Оценка и планирование проектов. М.: Альпина Паблишер. 2018. 418 с.
4. Сазерленд Дж. Scrum. Революционный метод управления проектами. М.: Манн, Иванов и Фербер. 2016. 186 с.
5. Хелдман К. Профессиональное управление проектом. М. Лаборатория знаний. 2016. 760 с. :ил.
6. Павлов А.Н. Эффективное управление проектами на основе стандарта PMI PMBOK 6th Edition. М.: Лаборатория знаний. 2019. 270 с. :ил.
7. A Guide to the Project Management Body of Knowledge (PMBoK Guide) / Project Management Institute. 2017. Pensylvanya: Sixth Edition. PMI Publications. 2017.
8. Каплан Р., Нортон Д. Сбалансированная система показателей. От стратегии к действию. ЗАО «Олимп-Бизнес». Москва. 2003. 210 с.
9. Черняховская Л.Р., Малахова АИ., Никулина Н.О. Применение методологии BSC для управления проектами в IT-компаниях // Управление экономикой: методы, модели, технологии: Труды XVIII Международной научной конференции. Уфа: УГАТУ. 2018. С.385-390.
10. Арчибальд Р. Управление высокотехнологичными программами и проектами. М.: ДМК Пресс; Компания АйТи. 2006. 472 с.
11. Бармина О.В., Никулина Н.О. Интеллектуальная система управления взаимодействием бизнес-процессов в проектно-ориентированных организациях // Онтология проектирования. 2017. Т. 7. №1(23). С. 514-524. DOI: 10.18287/2223-95372017-7-1-514-524.
UDK 005.8:65.015
A METHODOLOGY OF ASSESSING THE EFFORTS OF THE PROJECT TEAM MEMBERS IN ACHIEVING THE GOALS OF THE IT PROJECT
Natalya O. Nikulina
candidate of technical sciences, associate professor of the automated management systems department, e-mail: [email protected] Anna I. Malakhova candidate of technical sciences, associate professor of the automated management systems department, e-mail: [email protected] Ufa State Aviation Technical University, 450008, Ufa, K. Marx Str. 12, Valeriya I. Batalova leading specialist in testing unit of the software development department, e-mail: valeral evr@ gmail.com SIBINTEK IC LLC, 450047, Ufa, Bakalinskaya Str. 9/8,
Annotation. Competitiveness of the IT company, whose main activity is software development and implementation, in modern conditions is determined by its ability to implement several projects simultaneously, providing consumers with a high-quality product in the shortest possible time with minimal costs. However, the peculiarities of software development (immateriality of the final product, dependence on relationships between the project team members, tight deadlines and limited number of resources) do not allow effective monitoring of the project progress using generally accepted methods. Therefore, it is necessary to develop an alternative tool for assessing the status of the IT projects, as well as a way to identify timely the reasons for changes in individual project indicators. The problem can be solved by joint application of the methods of process and project management in considered subject area. In particular, it is proposed to develop a balanced scorecard of the IT company, based not only on the indicators of structural divisions, but also on the indicators of the IT projects. In turn, an each IT project balanced scorecard is linked to the functional structural works decomposition of each of the software development iterations, conducted using Scrum methodology. This allows at the level of the IT project individual indicators to determine the role and efforts of each of the project team members to achieving the operational goals of the project and the strategic goals of the IT company as a whole. Proposed methodology is applicable for setting priorities for parallel projects in order to reallocate resources in a timely manner, as well as for justifying the distribution of the IT company's budget for the projects up to individual employees, taking into account the grading system within the professional standard of project roles.
Keywords: IT project, balanced scorecard, project team, structural decomposition of project works, key performance indicators, responsibility matrix, project team members roles
Acknowledgements. The work is supported by the grant of the Russian Foundation for Basic Research № 19-08-00937 "Models and methods of intellectual decision making support in software project management realized on manufacturing enterprises".
REFERENCES
1. Clark, K. B., and S. C. Wheelwright. Managing New Product and Process Development: Text and Cases. NY: Free Press. 1993. 896 p.
2. Chernyakhovskaya L. R., Malakhova A. I., Nikulina N. O. and Batalova V. I. Informatsionno-analiticheskaya podderzhka prinyatiya kollektivnykh resheniy s
ispol'zovaniyem intellektual'nykh tekhnologiy [ Information and analytical collective decision making support using intelligent technologies] // Informatsionnyye tekhnologii v upravlenii: trudy XIII Vseross. mul'tikonferentsii po problemam upravleniya = Information technologies in management: Proceedings of the All-Russian multi-conferences on management problems (MCMP-2020). Saint-Petersburg: JSC "Concern Central Research Institute "Electropribor". 2020. Pp. 88-91 (in Russian)
3. Kon M. Agile. Otsenka i planirovaniye proyektov [Agile. Project evaluation and planning]. M.: Al'pina Pablisher = Moscow: Alpina Publisher. 2018. 418 p.
4. Sutherland J. Scrum. Revolyutsionnyy metod upravleniya proyektami [Scrum. The revolutionary method of project management]. M.: Mann, Ivanov i Ferber = Moscow: Mann. Ivanov and Ferber. 2016. 186 p (in Russian)
5. Kheldman K. Professional'noye upravleniye proyektom [Professional project management]. M. :Laboratoriya znaniy = Moscow: Knowledge Laboratory. 2016. 760 p (in Russian)
6. Pavlov A. N. Effektivnoye upravleniye proyektami na osnove standarta PMI PMBOK 6th Edition [Effective Project Management based on the PMI PMBOK 6th Edition Standard]. M.: Laboratoriya znaniy = Moscow: Knowledge Laboratory. 2019. 270 p (in Russian)
7. A Guide to the Project Management Body of Knowledge (PMBoK Guide) / Project Management Institute. 2017. Pensylvanya: Sixth Edition. PMI Publications. 2017.
8. Kaplan R., Norton D. Sbalansirovannaya sistema pokazateley. Ot strategii k dey-stviyu. ZAO «Olimp-Biznes» [Balances Scoredcard. From strategy to action. CJSC "OlympBusiness"] M.. 2003. 210 p (in Russian)
9. Chernyakhovskaya L. R., Malakhova A. I., Nikulina N. O. Primeneniye metodologii BSC dlya upravleniya proyektami v IT-kompaniyakh [Application of the BSC methodology for project management in IT companies] // Primeneniye metodologii BSC dlya upravleniya proyektami v IT-kompaniyakh = Managing the economy: methods, models, technologies: Proceedings of the XVIII International Scientific Conference. Ufa: UGATU = Ufa: USATU. 2018. Pp. 385-390 (in Russian)
10. Archibald Russel D. Upravleniye vysokotekhnologichnymi programmami i proyektami [Management of high-tech programs and projects]. M.: DMK Press; Kompaniya AyTi = M.: DMK Press. 2006. 472 p (in Russian)
11. Barmina O.V., Nikulina N.O. Intellektual'naya sistema upravleniya vzaimodeystviyem biznes-protsessov v proyektno-oriyentirovannykh organizatsiyakh [Intelligent system for interactive business processes management in project-oriented organizations] // Ontologiya proyektirovaniya = Ontology of designing. 2017. 7(1): 514-524. DOI: 10.18287/2223-95372017-7-1-514-524 (in Russian)
