CC BY
2
EDN: NBHCXQ
Э.В. Кузьмина - к.пед.н., доцент кафедры «Системного анализа и обработки информации», Кубанский государственный аграрный университет, Краснодар, Россия, [email protected],
E.V. Kuz'mina - candidate of pedagogical sciences, associate professor of the Department of systems analysis and information processing, Kuban State Agrarian University, Krasnodar, Russia;
Н.Г. Пьянкова - к.п.н., доцент кафедры «Математика и информатика», Финансовый университет при Правительстве Российской Федерации (Краснодарский филиал Финуниверситета), Краснодар, Россия, [email protected],
N.G. Pyankova - Candidate of Pedagogical Sciences, Associate Professor in the Department of Mathematics and Informatics, Financial University under the Government of the Russian Federation (Krasnodar branch), Krasnodar, Russia.
СОВЕРШЕНСТВОВАНИЕ ПРОЦЕССА УПРАВЛЕНИЯ ПРОЕКТОМ РАЗРАБОТКИ ПРОГРАММНОГО ПРОДУКТА IMPROVING THE SOFTWARE PRODUCT DEVELOPMENT PROJECT MANAGEMENT PROCESS
Аннотация. В настоящее время гибкие методологии разработки программного обеспечения заняли ведущие позиции при организации проектной работы и управлении проектами. Разработано много гибких методов управления проектами разработки программного обеспечения. Организации разработчики программного обеспечения испытывают необходимость в рекомендациях по применению гибких методов разработки в зависимости от исходных условий. В настоящей статье предлагается методика гибридного подхода к управлению проектами на основе фреймворков Scrum и Kanban для организаций внедряющих собственное программное обеспечение. Описан опыт внедрения гибридной методики в деятельность организации, характеризующейся быстрой сменяемостью требований к функциям информационной системы и одновременно высоким ожиданиям качества. Представлены и проанализированы результаты эксперимента на основе предложенных показателях эффективности методики.
Abstract. Currently, flexible software development methodologies have taken leading positions in organizing project work and project management. Many flexible methods of managing software development projects have been developed. Software development organizations need recommendations on the use of flexible development methods depending on the initial conditions. This article proposes a methodology for a hybrid approach to project management based on the Scrum and Kanban frameworks for organizations implementing their own software. The experience of implementing a hybrid methodology in the activities of an organization characterized by rapid change of requirements for the functions of an information system and at the same time high quality expectations is described. The results of the experiment based on the proposed performance indicators of the methodology are presented and analyzed.
Ключевые слова: проектная деятельность, повышение эффективности, разработка программного обеспечения, Agile, Scrum, Kanban, кумулятивная методика.
Keywords: project activities, efficiency improvement, software development, Agile, Scrum, Kanban, cumulative methodology.
Введение
На современном этапе конкурентоспособность компаний во многом зависит от применения информационных технологий, поэтому своевременная покупка и внедрение программных продуктов во многом определяют возможности компаний решать свои задачи, избегая возможных рисков.
В свою очередь разработка программного обеспечения (ПО) - это выгодный бизнес, позволяющий получать IT-разработчикам высокую прибыль. Для того чтобы максимизировать свою прибыль IT-компании должны выполнять свои обязательства перед заказчиками своевременно в полном объеме, минимизируя затраты. Разработка программных продуктов в IT-компании осуществляется, как правило, на основе проектной деятельности. Своевременность завершения проекта и качество полученного результата во многом зависит от умения руководителей компании управлять процессом разработки, их способностью собрать работоспособную команду разработчиков, мотивированных на результат.
На сегодня существует большое количество различных методик, которые позволяют адаптировать процесс управления проектом разработки ПО под требования современного рынка. В зависимости от масштаба и особенностей проекта в настоящее время предлагается использовать классические или гибкие методы управления жизненным циклом ПО. Классические методы реализованы через методологию Waterfall, а гибкие методы представлены в методологии Agile [3].
Авторы работ по управлению проектами в сфере разработки программного обеспечения обосновывают применение различных методик Agile [6]. Однако кумулятивные методики, основанные на комплексном использовании методов Agile встречаются крайне редко и как правило, не являются основой для сертификации проектной деятельности. В связи с этим необходимо рассмотреть возможность использования кумулятивной методики на основе методологий гибкой разработки приложений SCRUM и Kanban. Разработать метрики для ее внедрения и оценки.
Постановка задачи Методология Waterfall обычно используется IT-компаниями в том случае, если требования к будущей информационной системе заранее хорошо известны и не требуется демонстрация результатов до завершения проекта. По причине того, что в реальной жизни IT-компании редко сталкиваются с такими заказами, то чаще для управления проектами выбираются методы методологии Agile. Основным плюсом методов гибкой разработки является скорость выполнения проекта. Для управления проектом можно применить фрейм-ворки Scrum и Kanban. Эти фреймворки могут применяться, как по отдельности, так и в сочетании. Авторами были определены наиболее существенные отличия фреймворков Scrum и Kanban, которые необходимо учитывать при разработке методологии управлением проектом. Во-первых, у данных фреймворков - изначально различное назначение: у Scrum - собственно разработка ПО, у Kanban - управление потоками работ. Во-вторых, у Scrum используются с определенной периодичностью функциональные спринты, а у Kanban - используется непрерывный функциональный поток. В-третьих, для Scrum характерно передача функциональных знаний через обмен опытом на спринтах, а для Kanban - визуальное представление и передача информации. В-четвертых, различаются действия для управления работами. В Scrum - это планирование спринтов, митинги с демострацией продукта и обменом опытом, итерации на предыдущие этапы. В Kanban - визуализация всего потока работ, вы-
деление незавершенных работ в потоке их ограничение, продолжение потока. В-пятых, различаются роли в командах проекта в зависимости от фреймворка. Точнее в Scrum имеются роли: владелец продукта, scrum-мастер, команда разработчиков и тестировщиков. В свою очередь в Kanban роли не задаются, а распределяются по функциям в потоке работ. В шестых, методологии разделяются по гибкости. Scrum - более жесткая методология, которая позволяет вносить изменения до начала очередного спринта. Kanban позволяет вносить изменения в любой момент.
Таким образом, данные методологии хорошо проработаны. Понятны их различия и возможность применения [4]. Однако описание пошаговых методик совместного использования нескольких фреймворков Agile в одном проекте в настоящее время отсутствуют. Это требует проведения эксперимента в рамках проекта разработки ПО c использованием совместных методик и оценки эффективности предлагаемого подхода.
База исследования Рассмотрим совершенствование системы управления ИТ-проектами на основе фреймворков Scrum и Kanban. В качестве эмпирической базы будет выступать ИТ-компания ООО «IT-ЛОГ», которая занимается разработкой и внедрением собственной информационной системы для автоматизации логистической деятельности. Для управления своими проектами компания использовала стандартный фреймворк Scrum. В соответствии со Scrum ежедневные встречи имели следующую структуру. На утренней встрече в понедельник осуществлялось планирование спринта аналитиками и тимлидами в течение 4 часов, затем спринт запускался. На вечернем ежедневном митинге в течение 15 минут докладывались результаты. Далее ежедневно в течение недели реализовывались утренние, координационные и вечерние митинги. На утренние и вечерние митинги с участием команды отводилось по 15 минут, на координационные митинги с участием руководства, аналитиков и тимлидов отводилось по 1 часу. В конце спринта, как правило, к концу второй недели отводились на подготовку релиза 4 часа, на выпуск релиза на продуктовую базу 1 час, на демонстрацию выпущенного функционала 1 час, на управление ретроспективой - 45 минут. Ежедневные утренние, координационные и вечерние митинги сохранялись. Таким образом, встречи в соответствии с фреймворком Scrum за время спринта, рассчитанного на две недели, занимают 20 и более часов.
В разработке было задействовано несколько команд, они были разделены на виртуальные. Например, есть направления учета документации или обслуживающих справочных данных, при этом другой стороной является сам процесс автоматизации логистики. Команды не были разделены по функционалу, каждый бизнес-аналитик или разработчик должен был знать всю систему или каждый раз иметь на ознакомление время, чтобы реализовать свою доработку. Система была разделена на маленькие компоненты и за ними закрепляли ответственных, но изменять их мог каждый рядовой сотрудник. Таким образом, на митингах очень много времени уделялось анализу, чтобы выяснить, кто и какой кусок будет дорабатывать, более того, иногда возникали ситуации, когда не хватало экспертизы и приходилось сначала освежить знания по уже существующим архитектурным решениям, а после приступать к планированию и анализу новых поступающих функций на разработку.
Методика исследования
В качестве методики исследования был принят эксперимент. ООО «ИТ-ЛОГ» старается оптимизировать свою деятельность, поэтому использует метод гибкой разработки приложений SCRUM. В рамках эксперимента был предложен проект разработки приложений на основе SCRUM и Kanban. Исследование состояло из нескольких этапов. На первом этапе были выявлены проблемы, возникающие у команды разработки с использованием методики SCRUM, которые не позволяют сдать проект в соответствии с графиком и заданным финансированием. На втором этапе был разработан пилотный проект, позволяющий ликвидировать недостатки SCRUM в проектной деятельности на основе SCRAM. Пилотный проект в основе содержал кумулятивное использование фрейморков SCRUM и Kanban. В ходе эксперимента выявленные недостатки в работе команды разработки программного обеспечения были соотнесены с пунктами выполнения методики SCRUM. К данным пунктам были применены положения методики Kanban, если это позволял технологический процесс. Проблема внедрения новой кумулятивной методики заключается в изменении действующего технологического процесса разработки ПО на основе гибкой методологии. Для решения проблемы была составлена пошаговая методика изменений перед внедрением новых методов разработки с использованием Kanban.
Для проведения эксперимента использовался текущий проект и пилотный (экспериментальный) проект. В реальных условиях реализовать экспериментальный проект затруднительно, так как организовать работу двух команд над одинаковыми проектами невозможно. Поэтому были приняты некоторые допущения и отобраны измеримые характеристики проектов. К измеримым характеристикам проектов были отнесены: технология разработки ПО, количество сотрудников на проекте, количество задач, объем работ в человеко-часах, количество согласованных с клиентом функций. В соответствии с логикой разработки информационной системы общий проект был разделен на два виртуальных. В основу разделения были положены направления логистики. За разные направления логистики отвечают прикрепленные к ним бизнес-аналитики. Каждый аналитик развивает свою сторону для потребностей клиентов. Ранее в организации при этом, использовался основной и общий трудовой ресурс разработчиков и тестировщиков. На планировании трудовые ресурсы старались поделить на все направления поровну. При организации эксперимента было выделено два комплексных логистических направления. Первое направление составило базовый проект, второе направление составило пилотный проект. По выделенным метрикам данные два проекта имели схожие показатели.
На первом этапе исследования выделялись проблемы проектной работы. В ходе анализа основного процесса ООО «IT-ЛОГ», был сформирован ряд проблем, из-за которых организации не удается достичь максимального результата в текущих условиях и с указанными ранее ресурсами.
Первая проблема - это цикличность выдачи инкремента продукта с новым функционалом. На момент обследования, публикация обновлений происходила 1 раз в 1-2 месяца. Это очень большой срок, чем меньше инкремент и чем чаще он выпускается, тем лучше [7]. При длительном сроке инкремента со временем накапливается большой объем нового или измененного функционала, который становится тяжело поддерживать и отслеживать. Идеальный вариант, это 1 раз в 1-2 недели. При этом, если посмотреть на время проведения обновления продукта, оно отводится на внерабочий временной отрезок, что нарушает и размывает границы работы и личной жизни, что в итоге превращается в еще одну проблему.
Вторая проблема - стабильность продукта. Этот вывод был сделан исходя из показателей количества ошибок, приходящих от пользователей через службу поддержки или их оценки и обратные отзывы. Никакого автоматического тестирования не предусмотрено, всё тестируется вручную или отдается на откуп пользователям.
Третья проблема, это трудозатраты с точки зрения времени. Например, на каждое планирование спринта уделяется от 3 до 5 часов, это при том, если нет искажений глубины знаний продукта. Возникали ситуации, когда необходимо проводить дополнительное планирование в середине спринта, из-за нехватки компетенций или возникших в процессе других обстоятельств. Идеальный вариант, уделять планированию 1 -2 часа и запускать спринт [2]. Другой пример, это ежедневные митинги по утрам и вечерам, которые расходуют много полезного времени у команд. Так как сотрудники не участвуют в решениях и оценке задач, то все решения сводятся к опыту руководителей или лиц на лидирующих должностях, которые порой не учитывают наличие необходимой компетенции у сотрудников, отсутствует учет велосити каждой команды.
Велосити - это показатель способности превратить бэклог продукта в работоспособный функционал за определенный отрезок времени или определенную стоимость. Результаты анализа велосити представлены на burndown-диаграмме сгорания спринта (рисунок 1). По своей сути, эта диаграмма отображает проделанную работу, сгорание задач за период. На диаграмме зеленым цветом отмечены запланированные трудовые часы по задачам, а красным - количество закрытых задач с фактическим отображениям трудозатрат. Данный рисунок демонстрирует неправильное планирование трудовых и временных ресурсов, Например, были не учтены возможности квалификации сотрудников.
Четвертая проблема включает в себя внутри-командное устройство. Ответственность размыта за выдачу результата, так как нет единой точки слияния нескольких команд по общей пользовательской истории. Например, когда бэкендовая (сервер) и фронтовая (интерфейс) части реализованы, но никто не проверил интеграцию, в итоге история поступила на тестирование еще до проверки работоспособности [8]. Тут страдает отдел тестирования. Или если рассмотреть пример ведения истории компонентов продукта, через GitFlow, в каждой команде свои правила и принципы, в итоге появляется хаос при изменении состава команды, так как становится сложно разобраться помимо самого кода, ещё и в специфике ведения проектов [5].
Burndown Chart LuizTools
1Я/03/2Д 70/03/7Д 32/03/24 2Л/03/2Л JS/ПЧ/ЗЛ
Рисунок 1 - Диаграмма сгорания задач до внедрения изменений
Пятая проблема. Если рассмотреть правила проведения встреч, оценок, можно заметить, насколько искусственно поднимается значимость сотрудников, обладающих «сакральными» знаниями продукта или своей части ответственности [1]. Например, тимлид команды, на котором всё держится, уходит в отпуск. Становится сложно заменить его даже на время, потому что рядовые сотрудники не обладают полной информацией, сотрудники в принципе мало вовлечены в сам продукт, что является ещё одной проблемой.
Вовлеченность всей команды в создание продукта, как показатель страдает. Это соответствует низкому уровню заинтересованности и оценки понимания того, что и для чего делается. Если рассмотреть процесс, можно заметить, что рядовые сотрудники участвуют только в этапе производства, их полномочия ограничены, они даже не участвуют в планировании и оценки будущих задач. Отсюда появляются такие проблемы, как неправильное планирование трудозатрат.
Шестая проблема. Отсутствие единой документации, одни и те же понятия могут читаться по-разному в отдельных командах. Информацию приходится собирать по крупицам на разных источниках вики-инструмента. Отсюда страдает процесс онбординга сотрудников, он становится дороже [9]. Несомненно, например ведущие тимлиды просвещают нового сотрудника в процесс производства продукта, но желательно иметь какую-то дополнительную точку входа, для последующего возвращения к ней.
Результаты эксперимента
Для определения значимости выявленных проблем был проведен анализ ошибок разрабатываемого программного продукта, зафиксированных командой тестировщиков. А также проведен анализ оценок пользователей.
На рисунке 2 указана сводная информация по количеству ошибок и средней оценке пользователя по продукту. Как видно, ошибок очень много, при этом средняя оценка приложения пользователями едва превышала показатель 3 балла.
о -,-,-,-,-,-,-,-,-,-,
апр.23 май.23 нюн.23 нюл.23 авг.23 сен.23 окт.23 ноя.23 дек.23 янв.24
Рисунок 2 - Диаграмма ошибок и проблем до изменений
Исходя из выше сказанного, можно сделать вывод, что все проблемы взаимосвязаны, так или иначе они влияют друг на друга. Для их решения мы выдвинем основные критерии и показатели эффективности, которые позволят использовать своё решение для максимального достижения целей.
Показатели эффективности разделим на несколько логических блоков, каждый из которых будет соответствовать общим чертам выявленных проблем. Ключевое изменение будет заключаться в изменении расписания встреч и митингов, для увеличения времени на более важные аспекты процесса, например разработку или тестирование. По сравнению с предыдущим графиком спринта, убираются ежедневные митинги команд, на которые затрачивалось от 30 до 60 минут рабочего времени. Нет необходимости в такой частоте встреч, потому что большую часть информации можно получить из инструмента трекинга задач, понять над чем работает тот или иной участник, в каком статусе. Если обратить внимание на график, часть координационных встреч урезаны, в разные дни включают разных ролевых участников. Митинги команд в условиях удаленной работы сводятся больше к синхронизации в виде чата и сообщений.
Сокращается время планирования спринта, с 4 часов до 2-х. Оно разбивается на две части. В первой части собирается руководство и владельцы продуктов, обсуждают проекты, выделяют главное, расставляют приоритеты в зависимости от тех или иных показателей/потребностей. Затем во второй части приходят тимлиды команд на встречу, для установки трудозатрат и общего понимания, что будет включено в спринт, и в каком направлении будет происходить работа.
Добавляются новые две встречи во вторую неделю спринта для пересмотра бэклога. В состав участников встречи, как видно из рисунка, входят тимлиды, владельцы продуктов и по желанию члены остальной команды. Такие встречи необходимы для оценки историй из бэклога, общего понимания развития продукта, внесения изменений и пожеланий, а может быть и корректировки планов. На таких встречах обычно владельцы продуктов показывают и подробно рассказывают о будущих функциях, выслушивают команду, вносят коррективы, дробят на более мелкие истории [10]. Ведь чем меньше истории, тем меньше инкремент проекта, тем больше шансов внести новый функционал и вывести его для клиентов.
Встречи для подготовки и публикации релиза перенесены на -1 день, вместо четверга смещены на среду. Это необходимо для того, чтобы в запасе у команды оставалось 2 дня на исправления возникших ошибок, недочетов или нештатных ситуаций. К тому же, всем будет комфортнее выдавать релиз за несколько дней до выходных, чтобы не происходили переработки членов команды.
Ретроспектива и демонстрация результатов спринта остаются на своих прежних временных метках, они не нуждаются в сдвиге. Они сделаны для того, чтобы вся команда могла синхронизироваться по продукту и увидеть общий результат.
Ещё одно важное внедрение в управление проектом - это кросс-функциональная команда. Для того, чтобы оперативно и без ошибок достигать поставленных целей, необходимо временно менять структуру команд, делать их ориентированными на определенную функцию или направление. Одним словом, если необходимо быстро и в срок разработать большой и сложный функционал, собирается отдельная команда. Схематично кросс-команда представлена на рисунке 4.
Рисунок 4 - Формирование кросс-функциональной команды
При планировании спринта всегда необходимо знать мощность команды. Велосити показывает, какой объем работы выполняет команда за определенный период времени. Технология расчета была сформирована на основе коллективного опыта. Пример результатов расчета представлен в таблице 1.
Таблица 1 - Расчет велосити команд текущего и пилотного проектов
Показатель Команда текущего проекта Команда пилотного проекта
A Кол-во человек в команде 4 2
B Рабочих часов в день (с учетом различных перерывов в течение дня) 7 7
C Кол-во дней в спринте 10 10
D Кол-во отпускных дней в команде 0 10
F Митинги тимлидов % плюсом 50% 50%
G Кол-во джуниоров 0 1
H % производительности джуниоров 50% 50%
I Общий % загрузки на спринт без учета поддержки 70% 80%
G Итого трудозатрат (в днях) на спринт 21,4 3,5
Колонка «Итого трудозатрат» сообщает команде о предельной загрузке в днях, выше которой не стоит планировать трудозатраты на спринт, значение данного показателя рассчитывается по формуле:
G =
(1-F)*I + (A-1-G)*I + G*H*I В
*-*(В *A-D)
А
8
(1)
Количество рабочих часов за день берем 7, а не 8, по причине того, что мы учитываем перерывы отдыха или момента отвлечения сотрудника от работы.
Таким образом, получаем число в человеко-днях, которое команда может потратить на развитие продукта. Для упрощения расчетов, не учитывается условие, какой сотрудник уходит в отпуск, будь это тимлид или джуниор. Это допущение нужно предусмотреть отдельно.
Выпуск релиза по графику спринта попадает под сдвиг на минус один день по встрече подготовки и публикации релиза. Так у команды будет запас времени исправить всплывающие ошибки клиентов, получить обратную связь по новому функционалу. Для более слаженного и удобного выпуска новой версии продукта, в течение спринта создается история с номером версии релиза, в которой команды создают задачи, необходимые для выполнения в день релиза. Например, это могут быть миграции базы данных, или заполнение первоначальным данных в каком-либо сервисе системы. Практика показывает, это очень удобно и легко отслеживается, плюс сохраняется история работ по релизу, в которой всегда можно вернуться.
Для внесения изменений в компонент контроля стабильности системы, была выбрана платформа «SonarQube». Это платформа с открытым исходным кодом, разработанная «SonarSource», для непрерывной оценки качества кода путем статического анализа. Иначе говоря, она не выполняет код, а лишь просматривает его и делает это очень тщательно. Завершив сканирование кода, SonarQube формирует отчет, который можно посмотреть в GUI через браузер, сделать вывод о потенциальных ошибках, качестве кода, процента покрытия функционала автоматизированными тестами и т.д.
Если ранее ретроспектива спринта сводилась к тому, чтобы открыть документ Excel и заполнить там строчки для каждого о том, что нравится, а что не нравится, что является менее творческим и привлекательным для команды, то в этот раз был внедрен инструмент «Miro», который хорошо себя зарекомендовал в компании.
После внедрения изменений в текущую методологию управления проектом, были сформированы и обновлены новые показатели эффективности.
В первую очередь, это график сгорания спринтов, который представлен на рисунке 6.
График стал более сглаженный, чем ранее. Синий показатель находится ниже, либо наравне с зеленым, что говорит нам о том, что задачи выполняются в срок и не выходят за рамки контрольных точек по заранее спланированному спринту.
Кроме того были сокращены релизы. Релизы стали включать в себя более мелкие истории, а соответственно и частота обновления выросла. Это привело к тому, что стало меньше историй (или совсем исчезли вне плана), что говорит о том, насколько эффективно собран релиз, который учитывает внеплановые ситуации.
Рисунок 6 - Диаграмма сгорания спринта после внедрения изменений
На рисунке 7 указана сводная информация по количеству ошибок и средней оценке пользователя по продукту в пилотном проекте.
Рисунок 7 - Диаграмма ошибок и проблем с учетом изменений
Исходя из графика, следует сделать вывод, что в процессе внедрения изменений в процесс управления проектом была выполнена колоссальная работа над ошибками, количество проблем уменьшилось, а средняя оценка пользователя выросла на 1.1 пункта.
Последний показатель демонстрирует оценку вовлеченности всей команды в продукт, на рисунке 8.
Из-за множества интересных нововведений, вовлечений каждого члена команды в продукт, оценки команды стали более высокими и лишь доказывают эффективность кастомизации методики.
Рисунок 8 - Диаграмма оценок ретроспективы и вовлеченности в пилотном проекте Заключение
Кумулятивная методика на основе фреймворков SCRAM и Kanban разработана для проектов по разработке программного обеспечения с целью выполнения или сокращения сроков разработки, уменьшения количества ошибок, повышения удовлетворенности клиента. Эксперимент внедрения кумулятивной методики SCRAM и Kanban показывает, что данная методика подходит для больших проектов и организаций разработчиков со сложной. разветвленной структурой или организаций, которые занимаются разработкой ПО для собственных нужд, как правило это крупные предприятия со сложной структурой. Проекты, для которых может быть рекомендована данная кумулятивная методика - это проекты, которые нацелены на разработку программных продуктов, требования к которым заранее не известны, т.е меняются в результате взаимодействия с заказчиком. Применение данной методики также рекомендовано для проектов, у которых клиент не знает окончательных рамок и функций. Поэтому использование методики предполагает тщательное взаимодействие с заказчиком. Отсутствие коммуникации с заказчиком может нейтрализовать все преимущества кумулятивного подхода с использованием двух фрейворков Agile: SCRAM и Kanban. Эксперимент показал, что внедрение нового подхода требует периода адаптации, в особенности, если предыдущая методология разработки была сертифицирована. Однако исследуемые показатели производительности, скорости разработки, удовлетворенности клиентов в экспериментальном проекте выше, чем в текущем. Эксперимент по применению кумулятивной методики SCRAM и Kanban показал значительное снижение количества ошибок, что ведет к сокращению затрат и является фактором улучшения производительности разработки. Представленные результаты имеют теоретическое и практическое значение. Они могут быть использованы для совершенствования кумулятивной методологии Agile с использованием фреймворка XP, а также могут быть использованы организациями для совершенствования собственной методологии разработки программного обеспечения.
Источники:
1. Using the Technology of Collecting and Analyzing Structured Information for the Forming Mechanisms of Professional Adaptation Among Students of Engineering Disciplines / E. V. Kuz'mina, N. G. Pyankova, N. V. Tretyakova, L. V. Kukharenko // Proceeding of the International Science and Technology Conference "FarEastCon 2021", Vladivostok, 05-08 октября 2021 года. - Vladivostok: Springer Nature Switzerland AG, 2022. - P. 571-581. - DOI 10.1007/978-981-16-8829-4_55. - EDN UMYSSF.
2. Аксенова, Ж. А. Проблемы оценки системы внутреннего контроля организации / Ж. А. Аксенова, О. В. Ищенко, В. В. Салий // Деловой вестник предпринимателя. - 2020. - № 1(1). - С. 8-11. - EDN ZGPWTO.
3. Бражина, П. Д. Преимущества Kanban методологии при разработке программного обеспечения / П. Д. Бражина, Э. В. Кузьмина // Виртуозы науки : Сборник тезисов Международной научно-практической конференции студентов и молодых учёных за 2023 г, Краснодар, 06-15 ноября 2023 года. - Краснодар: Кубанский государственный аграрный университет им. И.Т. Трубилина, 2024. -С. 392-394. - EDN UFELZA.
4. Исследование операций: системный анализ и моделирование : Учебное пособие / С. М. Силинская, Н. Ю. Нарыжная, Н. Г. Пьянкова, Э. В. Кузьмина. - Краснодар : ФГБУ "Российское энергетическое агентство" Минэнерго России Краснодарский ЦНТИ- филиал ФГБУ "РЭА" Минэнерго России, 2020. - 128 с. - EDN RVHMFD.
5. Кузьмина, Э. В. Информационные технологии бизнес-аналитики в обслуживании пользователей / Э. В. Кузьмина // Ученые записки (Алтайская государственная академия культуры и искусств). - 2017. - № 2(12). - С. 129-131. - EDN SFJMHA.
6. Минина, Е. А. Системный анализ и многокритериальная оценка инновационных проектов экспертными методами / Е. А. Минина, В. В. Тарасова, О. Д. Чигидин // Экономика и предпринимательство. - 2018. - № з(92). - С. 1052-1057. - EDN YWWGDU.
7. Мусатов, И. С. Случайные процессы в моделировании бизнес-процессов. Стохастическое моделирование / И. С. Мусатов, И. М. Яхонтова // Информационное общество: современное состояние и перспективы развития : Сборник материалов VI международного форума, Краснодар, 28-30 декабря 2015 года / Редакционная коллегия: Попова Е.В., Замотайлова Д.А., Курносов С.А., Рахметова Р.У., Рогачев А.Ф., Тинякова В.И., Темирбулатов П.И., Тамбиева Д.А., Топсахалова Ф.Н-Г., Улезько А.В. - Краснодар: Кубанский государственный аграрный университет имени И.Т. Трубилина, 2016. - С. 29-32. - EDN VMKGQT.
8. Пьянкова, Н. Г. Педагогические условия совершенствования подготовки бакалавров экономики к инновационной профессиональной деятельности / Н. Г. Пьянкова, В. М. Матвиюк // Научно-методический электронный журнал "Концепт". - 2014. - N° T20. - С. 1741-1745. - EDN SJEUGR.
9. Пьянкова, Н. Г. Современный рынок программного обеспечения для управления персоналом / Н. Г. Пьянкова // Кайгородовские чтения. Культура, наука, образование в информационном пространстве региона : сборник материалов XVI Всероссийской научно-практической конференции: к 50-летию Краснодарского государственного института культуры, Краснодар, 14 апреля 2016 года / Краснодарский государственный институт культуры. Том Выпуск 16. - Краснодар: Краснодарский государственный институт культуры, 2016. - С. 128-132. - EDN WJMHTP.
10. Сидоренко, В. С. Возможности адаптации типовой модели подготовки информатиков для социально-культурной сферы / В. С. Сидоренко, Э. В. Кузьмина // Культурная жизнь Юга России. - 2011. - № 4(42). - С. 88-89. - EDN OKIAEX.
EDN: HHKYSL
М.А. Мартояс - старший преподаватель кафедры менеджмента, Кубанский государственный аграрный университет, Краснодар, Россия, [email protected],
M.A. Martoyas - Senior Lecturer, Department of Management, Kuban State Agrarian University, Krasnodar, Russia;
З.А. Хачак - ассистент кафедры менеджмента, Кубанский государственный аграрный университет, Краснодар, Россия, [email protected],
Z.A. Khachak - Assistant of the Department of Management, Kuban State Agrarian University, Krasnodar, Russia;
А.В. Гросу - обучающийся факультета управления, Кубанский государственный аграрный университет, Краснодар, Россия, [email protected],
A.V. Grosu - student of the Faculty of Management, Kuban State Agrarian University, Krasnodar, Russia;
Е.А Лепигова - обучающийся факультета управления, Кубанский государственный аграрный университет, Краснодар, Россия, [email protected],
E.A. Lepekhova - student of the Faculty of Management, Kuban State Agrarian University, Krasnodar, Russia.
ИССЛЕДОВАНИЕ ПРИМЕНЕНИЙ ТЕХНОЛОГИЙ САМОМЕНЕДЖМЕНТА В ПРОФЕССИОНАЛЬНОЙ ДЕЯТЕЛЬНОСТИ ГОСУДАРСТВЕННЫХ ГРАЖДАНСКИХ СЛУЖАЩИХ
ДЕПАРТАМЕНТА ИМУЩЕСТВЕННЫХ ОТНОШЕНИЙ КРАСНОДАРСКОГО КРАЯ STUDY OF APPLICATION OF SELF-MANAGEMENT TECHNOLOGIES IN PROFESSIONAL ACTIVITIES OF STATE CIVIL SERVANTS OF THE DEPARTMENT OF PROPERTY RELATIONS OF KRASNODAR REGION
Аннотация.Динамика социально-экономического развития в современной России обуславливает необходимость поиска качественно новых подходов к осуществлению профессиональной деятельности в различных отраслях. Высокими темпами трансформаций характеризуется не только рыночная среда, но и различные социальные системы. Для того, чтобы системно увеличивать эффективность профессиональной деятельности, сотрудникам современных организаций необходимо применение технологий самоменеджмента. Технологии экономии временных ресурсов имеют актуальность в процессе функционирования органов государственной власти. Авторами был проведен анализ применения технологий самоменеджмента в деятельности государственных гражданских служащих Департамента имущественных отношений Краснодарского края, ориентированных на экономию рабочего времени, формирование временных резервов. В ходе проведения исследования было выявлено, что применение технологий самоменеджмента позволяют не только оптимизировать деятельность сотрудников, но и увеличить их мотивацию к труду. Авторами сделаны выводы о целесообразности адаптации технологий самоменеджмента к осуществлению профессиональной деятельности государственных гражданских служащих.
Abstract.The dynamics of socio-economic development in modern Russia necessitates the search for qualitatively new approaches to the implementation of professional activities in various industries. Not only the market environment, but also various social systems are characterized by high rates of transformation. In order to systematically increase the efficiency of professional activities, employees of modern organizations need to use self-management technologies. Technologies for saving time resources are relevant in the process of functioning of government bodies. The authors analyzed the use of self-management technologies in the activities of state civil servants of the Department of Property Relations of the Krasnodar Territory, focused on saving working time, forming time reserves. In the course of the study, it was revealed that the use of self-management technologies allows not only to optimize the activities of employees, but also to increase their motivation to work. The authors concluded that it is expedient to adapt self-management technologies to the implementation of professional activities of state civil servants.
Ключевые слова: технология самоменеджмента, профессиональная деятельность, социально-экономическая среда, ресурс, время, активность.
Keywords: self-management technology, professional activity, socio-economic environment, resource, time, activity.
Современное социально-экономическое пространство характеризуется не только высокой степенью динамичности, но и постоянным нарастанием информационных потоков. В соответствии с этим, на сегодняшний день можно говорить о формировании информационного общества, где информация является весьма ценным ресурсом. Однако, наряду с информацией, целесообразно отметить значимость временного ресурса как фундамента для осуществления профессиональной деятельности работниками различных категорий. Даже специализированные отрасли экономики, например, функционирование зернового подкомплекса, зависит от эффективности расходования временных и иных ресурсов [6]. Предпринимательская деятельность как основа современной рыночной экономики полностью зависит от ресурсного обеспечения [7].
