Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

Согласно исследованиям, проводимым компанией CNewsAnalytics, среди 100 крупнейших ИТ-компаний России, более 80% занимаются разработкой и поддержкой программного обеспечения [1]. Данные за 2013-2015 гг. показывают, что выручка поставщиков ИТ-решений в России растет, несмотря на кризис [2]. Однако в связи с сокращением бюджетов, выделяемых производственными и торговыми компаниями на оптимизацию бизнеса и внедрение информационных систем, системные интеграторы вынуждены сокращать и свои расходы, оптимизируя деятельность, чтобы продолжать успешно конкурировать на рынке. Это значит, что пристальное внимание будет уделяться эффективному использованию и планированию ресурсов.

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

На сегодняшний день методологии управления проектами и методологии разработки программного обеспечения предлагают четыре основных подхода к распределению задач в команде: традиционный экспертный (задачи распределяет руководитель), командные методы организации планирования и распределения задач (Scrum, Poker Planning, Kanban) и методы, основанные на алгоритмах распределения ресурсов. Перечисленные подходы рассматривают процесс распределения задач в направлении от руководителя к подчиненным. В последние 5-10 лет, развитие получает новый подход: тендерный метод распределения задач в команде, который становится актуален тем, что позволяет исполнителям принять непосредственное участие в планировании и выборе задач на исполнение. На сегодняшний день разработаны алгоритмы, основанные на теории аукционов, симулирующие метод: определение победителя, определение выигрыша [3, 24]. Методологическая основа метода с точки зрения применения его на практике недостаточно проработана, нет четких рекомендаций по организации процесса распределения задач с использованием аукциона. Основные разработки в этом направлении принадлежат Крылову С.В., сформулировавшему основные принципы тендерного метода распределения задач в команде.

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

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

Объектом исследования является процесс распределения задач в команде разработчиков программного обеспечения. Предметом исследования является теория аукционов в качестве метода распределения задач.

Цель выпускной квалификационной работы - разработать методику распределения задач на основе теории аукционов.

Разрабатываемая методика ориентирована преимущественно на функциональных менеджеров (в сферах программирования, веб-проектирования, дизайна и пр.) и менеджеров проекта, отвечающих за срок и стоимость разработки.

Для достижения поставленной цели были выделены следующие задачи:

1. Анализ стандартов, методологий и методов, касающихся распределения задач в команде и организации проектной деятельности. В результате требуется получить перечень подходов, которые можно будет использовать для разрабатываемой методики, и перечень ограничений, которые необходимо учесть.

2. Изучение и анализ теории аукционов, степень ее проработки в сфере управления человеческими ресурсами, на основе опубликованных статей и научных исследований.

3. Подготовка команды и инструмента для проведения эксперимента, применения методики и сбора статистики.

4. Анализ полученных на основе эксперимента результатов, расчет результатов эксперимента.

5. Разработка методики распределения задач путем организации аукциона с учетом результатов эксперимента. Постановка задачи на автоматизацию процесса планирования и распределения задач в команде.

В первой главе настоящей работы будет рассмотрена теоретическая и методологическая составляющая исследования: определение понятия аукциона, изучение подходов к распределению задач и анализ их достоинств и недостатков; описание существующей методики распределения задач методом проведения аукциона. Вторая глава посвящена анализу применения тендерного метода в Компании, с помощью проведения эксперимента: описание подготовки к проведению эксперимента и анализ результатов его проведения. По результатам эксперимента было проведено интервью с целью определения качественных требований к тендерному методу. Результатом исследования является разработанная методика распределения задач в команде, которая подробно описана в третьей главе.

1. Анализ предметной области

Данная глава посвящена исследованию теоретических и практических научных разработок на стыке управленческого менеджмента в сфере управления ИТ-проектами и одного из направлений теории игр - теории аукционов. Для систематизации знаний были проанализированы методологии управления проектами и модели разработки программного обеспечения. Результатом исследования является набор рекомендаций и ограничений для разработки методики распределения задач в команде разработчиков.

1.1 Постановка проблемы

тендерный разработчик программный

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

Под распределением задач понимается соотношение работ по задаче и исполнителя. Назначение исполнителя на задачу возможно при условии, что исполнитель обладает достаточными навыками для выполнения задачи. Выделяются следующие методы распределения задач: традиционный экспертный (задачи распределяет функциональный руководитель), командный (чаще всего из гибких методологий разработки, Scrum, Poker Planning), эвристический (алгоритмы построения расписаний, распределения ресурсов).

Основным на сегодняшний день является экспертный подход к принятию решения о распределении задач: руководитель функциональной группы имеет в подчинении ограниченное количество специалистов, при поступлении новой задачи передает ее на исполнение одному или нескольким исполнителям с учетом своего представления об их навыках и квалификации, с учетом сроков выполнения и прочими факторами. Однако в условиях непрерывно появляющихся задач, ограниченного числа специалистов руководитель может допускать ошибки и распределять задачи таким образом, что не будут максимально задействованы навыки каждого или наоборот, загрузка высококвалифицированных специалистов будет значительно отличаться от развивающихся сотрудников. Как показал расчет загрузки персонала (время выполнения задач по проектам к общему числу рабочих часов за месяц) за 2014 год в Компании, в рамках которой проводилось исследование, фактическая загрузка высококвалифицированного разработчика составляет 104-120% в месяц, основного состава разработчиков от 63% до 83%. При этом выполнение 43% задач превышают сроки, запланированные на их реализацию.

Руководитель группы, который распределяет задачи между сотрудниками может не учесть всех факторов, влияющих на результат выполнения задачи. Это влияет как на результат работы отдельного специалиста, так и на результат выполняемого проекта. Более того, производительность исполнителей периодически падает, так как отсутствует необходимый уровень мотивации и заинтересованности. Централизованное распределение задач между исполнителями не дает возможность специалистам проявить себя, выбирать задачи самостоятельно. В связи с этим возникает потребность в пересмотре принципов планирования специалистов на проектах и метода распределения задач между ними.

Таким образом, проблема, которая должна быть решена в ходе исследования звучит следующим образом: отсутствие личной мотивации и заинтересованности исполнителей выполнять работу на проектах быстро по причине централизованного распределения задач и назначения максимально возможного времени на исполнение.

1.2 Анализ методов распределения задач в команде

Для оценки методологической составляющей процесса распределения задач в команде на проекте необходимо изучить основные стандарты по управлению проектами. По стандарту ГОСТ Р 54869-2011 управление проектом - это планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленных на эффективное достижение целей проекта [4]. Исходя из определения стандарты и методологии управления проектами должны содержать ряд рекомендаций по процессу планирования и управления человеческими ресурсами, в том числе предоставлять перечень лучших практик по организации распределения задач. В ходе исследования были обзорно изучены популярные методологии управления проектами: PMI (PMBoK), PRINCE2, P2M, ГОСТ Р 54869-2011 [5].

Методология управления проектами, разработанная институтом управления проектами (PMI), изложена в своде знаний управления проектами (PMBoK). Особенность методологии заключается в рассмотрении управления проектами как совокупности процессов, сгруппированных по девяти областям знаний. Распределение задач в проекте является частью процесса руководства и управления проекта. Среди прочего, процесс включает в себя подбор, подготовку и управление командой проекта, налаживание и управление каналами коммуникаций как внешними, так и внутренними. Предполагается, что задачи распределены заранее, а их перечень и исполнители указаны в плане проекта. Однако, специфика итеративных проектов по разработке программного обеспечения не позволяет в полной мере распределить задачи на этапе планирования. Данный тезис, однако, не противоречит применимости методологии в подобного рода проектах, так как методы управления подходят для задачи распределения работ. Основными методами и инструментами являются экспертная оценка и совещания. Таким образом, либо руководитель назначает сотрудников на выполнение задания, либо все решается коллегиально. Еще одним инструментом является использование информационных систем, однако свод знаний не дает четких разъяснений на счет задействования программных продуктов в принятии решений [6].

Методология Prince 2 помимо проектного менеджера предполагает наличие руководителя команды. Проектный менеджер дает распоряжение о распределении пакета задач. Руководитель команды распределяет задачи равномерно, пишет план работ по пакету, контролирует работу исполнителей и отчитывается перед менеджером. Очевидно, данный вид взаимодействий свойственен большим проектам. Методология не дает четкого указания по директивному распределению задач руководителем команды и определяет его как посредника между менеджером и командой, и ее представителем. Соответственно, его основная задача состоит в передаче информации без искажений и отстаивание интересов команды. По сути, метод распределения задач остается на усмотрение самой команды. За процедуру отвечает руководитель команды проекта [7].

ГОСТ Р 54869-2011 также не дает четких инструкций по распределению задач в проекте. Требованию к проекту, как и в PMBoK, описаны через призму процессного подхода. Очевидно, процедура распределения задач включена в процесс планирования персонала, выходом которого является определенное количество назначенных на проект сотрудников, их полномочия, ответственность и обязанности. Соответственно, данный процесс и предполагает распределение задач. Стандарт не раскрывает содержания процесса, ровно, как и методов распределения задач [8].

Японский стандарт P2M разделяет управление проектами на сферы деятельности. Основной чертой организационного управления проектом является гибкость, способность менеджера быстро реагировать на изменения как в окружении проекта, а так и внутри. Организационная составляющая должна быть высоко адаптивной, что свидетельствует о допущении данной методологией распределения задач в ходе реализации проекта. Принятие решений, в том числе и о назначении на выполнение задачи, должно происходить по заведомо обусловленным и принятым правилам. Размытая формулировка дает основания полагать, что источником решения может выступать менеджер, при соответствующем одобряемом стиле лидерства, или же группа. Пространство для трактовки данного положения позволяет предположить, что методы, используемые при принятии решений, выбираются на усмотрение руководителя и команды при обоюдном одобрении их применения. Методология делает акцент на моральном благополучии задействованных в проекте специалистов. Они должны быть мотивированны, приветствовать стиль лидерства и осознавать цели [9].

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

Одной из наиболее известных методологий является MSF (Microsoft Solution Framework). Она основана на лучших практиках разработки в Microsoft. В методологии описана модель проектной команды, в основе которой лежит распределение ролей на кластеры: управление программой, разработка, тестирование, управление выпуском, удовлетворение заказчика, управление продуктом. В малых проектах один специалист может обладать несколькими ролями, однако они не должны конфликтовать. Качество распределения ролей является важной предпосылкой к успешной процедуре распределения задач. Конфликтующие роли могут получать конфликтующие задачи, что скажется на показателях проекта. В случае с большими проектами, команда проекта делится на вышеперечисленные кластеры, а во главе кластера встает руководитель. Полномочия проектного менеджера распределены между руководителями кластеров, а сам менеджер не назначается. Соответственно, и распределение задач происходит в кластерах, с учетом плана проекта, с тем, чтобы кластеры работали организованно и слаженно. Основным требованием при планировании и решении задач является соблюдение компромиссов, то есть баланса между ресурсами проекта, реализуемыми возможностями и календарным графиком. Решения принимаются на основе построения матрицы компромиссов [10].

На основе данной методологии получила развитие гибкая методология разработки программного обеспечения (MSF for agile Software Development). Суть методологии сводится к представлению проекта как набора итераций со стандартными процедурами планирования и разработки в каждой из них. Данная методология предполагает наличие девяти аспектов. Во-первых, исполнители должны четко осознавать цель проекта и понимать свою роль в достижении данной цели. Видение себя частью системы требует от участника понимания функционирования системы в целом. Также, каждая заинтересованная сторона должна иметь своего представителя в проекте для защиты интересов. Участие в проекте - привилегия, за которую сотрудники должны испытывать гордость. Все задачи должны быть выполнены своевременно. Все участники имеют равные права и одинаковую значимость для проекта, как и ответственность. Команда несет ответственность, кроме прочего, за эффективное использование ресурсов, что требует от них хозяйского отношения. Обучение должно проводиться непрерывно. В совокупности, эти аспекты влияют на приверженность команды качеству.

Основными принципами данной методологии являются:

· Партнерство с заказчиками. Учет интересов заказчиков на каждой стадии реализации проекта играет ключевую роль в создании ценности.

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

· Инкрементная выдача результатов. Частая демонстрация результатов позволяет своевременно скорректировать продукт в соответствии с требованиями заказчика. Такая модель позволяет долгое время поддерживать работоспособность команды, разбить проект на несколько итераций и работать на достижение целей итерации в краткосрочной перспективе, что шаг за шагом приведет к реализации цели проекта.

· Инвестиции в качество. Участники проекта должны представлять интересы заказчика, а управление качеством должно быть неотъемлемой частью проекта. В плане должны быть предусмотрены итерации на исправление дефектов.

· Широкие полномочия участников проекта. Участники проекта профессионалы и требуют к себе должного отношения. Атмосфера доверия и долга перед коллегами является мотиватором для своевременного выполнения задач.

· Четкая подотчетность. Каждый исполнитель подотчетен коллективу и отчитывается по результатам своей работы на совещании.

· Учет любого опыта. Нацеленность на саморазвитие исключает жесткую критику. Даже ошибки являются источником полезного опыта. Соответственно они подвергаются обсуждению.

· Свободное общение. Свободный доступ и обмен информацией медлу участниками проекта и с заказчиком позволяет нивелировать риски связанные с ограниченностью информации.

· Гибкость и готовность к переменам. Гибкость обусловлена стремительно меняющейся внешней средой: изменение потребностей заказчиков и постоянное совершенствование программного обеспечения и возможностей программирования [11].

Распределение задач происходит в процессе планирования итерации. За каждую итерацию возможно реализовать ограниченное число работ. Первоначально создается план, включающий элементы сценариев. Далее, план передается бизнес-аналитику для создания сценариев. Сценарии, в последствии делятся на задачи, которые распределяют между собой разработчики. В последствии производится более четкая оценка затрат, использующаяся для равномерного распределения задач.

Данная методология является базовой для таких методов как Scrum и Poker Planning и является наиболее оптимальной для рассмотрения и опоры при анализе распределения задач в проекте.

Методы, применяемые при распределении задач описаны лишь в двух из рассмотренных методологиях. Экспертный метод предложен в PMBoK. Scrum и Poker Planning являются продолжением итеративной модели MSF. Однако, в литературе также существует метод Kanban, адаптированный для управления проектами, и подход к распределению задач с точки зрения планирования ресурсов (эвристические алгоритмы распределения). Рассмотрение данных методов поможет определить возможность внедрения метода аукционов в проекты по разработке и модификации программного обеспечения.

Экспертный метод

К экспертным методам в текущей работе отнесены методы распределения задач руководителем группы разработчиков (в ряде методологий Team Leader) или руководителем функционального отдела, в зависимости от организационной структуры компании. Распределение задач основывается на знаниях и навыках руководителя, как распределителя ресурсов по Г. Минцбергу [12]. В основе данного метода лежат представления руководителя о задаче с одной стороны и о сотруднике с другой. Зачастую задача оценивается с учетом ее критичности в проекте, уровня сложности и ответственности, возлагаемой на работника посредством данной задачи. На выполнение задачи подбирается работник с учетом его знаний, умений и навыков, а также с учетом его мотивационного признака. В таблице №1 «Распределение задач экспертным методом» проиллюстрирована примерная матрица распределения задач на основе экспертного метода. Руководитель оценивает задачу как простую, стандартную или сложную. Далее он определяет степень ответственности, возлагаемой на работника данной задачей. Также ведется оценка критичности задачи на основе метода критического пути.

Таблица 1. Распределение задач экспертным методом

	начинающий	средний уровень ЗУНК	высокий уровень ЗУНК	начинающий	средний уровень ЗУНК	высокий уровень ЗУНК
	Х	Y
Простая	Минимальная	Не критичная	О			О
Стандартная				О
Сложная					О
Простая	Стандартная			О		О
Стандартная					О
Сложная							О
Простая	Максимальная				О		О
Стандартная							О
Сложная								О
Простая	Минимальная	Критичная		О
Стандартная					О
Сложная							О
Простая	Стандартная				О
Стандартная							О
Сложная								О
Простая	Максимальная				О
Стандартная							О
Сложная								О

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

В соответствии с теорией Д. Макгрегора [13], все работники делятся на два мотивационных типа. Работники Х ленивые и избегают труда. Они требуют постоянного контроля и принуждения. Такие работники чаще всего избегают ответственности. Соответственно, им необходимо поручать задачи, выполнение которых легко проконтролировать и которые наделяют работника минимальной ответственностью. Работники Y, наоборот, высокомотивированы, не боятся ответственности, чувствуют свой вклад в общее дело и готовы стараться ради общего успеха. Им можно поручать более сложные задания, наделять большей ответственностью и меньше контролировать.

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

Недостатком метода является излишняя зависимость от руководителя, которая проявляется в директивном назначении задач, которое может противоречить желаниям и установкам работников. Зависимость от руководителя приводит к возникновению непредвиденных ошибок, спровоцированных неравномерным распределением задач. Человеческий фактор, как риск проекта, при использовании данного метода усиливается.

Командные методы

Командные методы распределения задач в проекте используются при распределении задач между равноценными высокомотивированными специалистами, которые имеют представление об общем объеме работ, условиях выполнения конкретных задач и роли каждого в проекте. Наиболее известными методами, используемыми в проектах в сфере информационных технологий, являются Scrum и Покер планирование (Poker Planning), ввиду их применимости в гибкой модели разработки программного обеспечения. Особенность этих методов состоит в том, что планирование времени на задачи и контроль хода исполнения проводится в виде командных совещаний.

Метод Scrum является частью более общей методологии Scrum, в основе которой находится представление о проекте как о наборе итераций - спринтов (Sprint). Спринт - итерация, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени, длительность одного спринта варьируется от 2 до 4 недель. В методологии Scrum планирование проекта производится как на начальном этапе, где создается общий бэклог (Backlog) проекта, содержащий требования к проекту, так и в начале каждого спринта - бэклог спринта. Бэклог спринта, в свою очередь, представляет набор историй спринта - описания функции, исполнителя и цели. Разработка бэклога спринта происходит путем совещания в два этапа. На первом этапе, руководитель и команда определяют функции, необходимые для выполнения в спринте. Функции дробятся таким образом, чтобы временные затраты на работу не превышали рабочего дня. Длительность задач оценивается экспертным методом. На втором этапе проходит обсуждение функций и наполнение бэклога спринта. На этом же этапе происходит распределение задач в команде. Исполнитель закрепляет за собой задачу посредством истории спринта [14].

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

Покер планирование основывается на Scrum методе, однако процесс оценки задач изменен во избежание эффекта привязки. Членам команды раздаются карточки с числами (чаще с числами Фибоначчи), которые отражают оценку специалистом длительности задачи. Важным показателем является выбор карточки с большим, или меньшим числом в случае, если специалист определяет время, не указанное в карточке. Менеджер проекта представляет коллективу содержание задачи. Далее, каждый член команды делает выбор и выкладывает карту рубашкой вверх. После того, как все определили время, участники по очереди переворачивают карты и мотивируют свой выбор. Узнав мнение каждого участника, менеджер запускает процедуру обсуждения, в результате которого принимается общее решение о затратах по времени [15].

На основе данного метода, команда может принимать решение о назначении специалиста на задачу, основываясь на близости оценки члена команды к общепризнанной, качестве его аргументов и наличии свободного времени на задачу. Метод позволяет распределить задачи таким образом, чтобы у исполнителей был минимальный лаг между задачами, а сами исполнители были наиболее заинтересованы в решении.

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

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



Канбан

Метод Канбан не является чисто командным методом распределения задач, равно как и цель использования метода выходит за рамки эффективного распределения ресурсов в проекте. Канбан, являясь частью масштабной философии бережливого производства, впервые внедренной Тайити Оно в Тойоте в 1980х годах. Бережливое производство призвано избавить процесс создания ценности от непроизводственных затрат, считающихся излишними. Основным принципом философии является тянущая производственная система, где производство на каждом этапе ориентируется на потребности следующего. Канбан (карточки) в этом процессе является средством информирования предыдущего этапа производства о потребностях последующего и отчета о движении материальных ресурсов.

Дальнейшее развитие Канбан приняло в сфере управления проектами и приняло вид гибкой методологии разработки программного обеспечения. Последовательность действий в проекте принимает вид производственного процесса с соответствующими этапами. В зависимости от специфики проекта, набор этапов может меняться. При проведении проекта в соответствии с данным методом изначально определяется набор задач и их очередность. Задачи должны быть сформулированы в таком виде, чтобы они выполнялись на всех этапах работы. Отличительным признаком данного метода является отсутствие требований ко времени исполнения задач. К примеру, внедрение ERP системы, где задачей может служить внедрение конкретного модуля. Доска, проиллюстрированная на рисунке №1 «Канбан-доска команды» является инструментом визуализации работы. Задачи выполняются последовательно. После завершения работ по задаче на одном этапе, она передается на другой. Контроль в процессе необходим лишь для отслеживания бесперебойности передачи задач от этапа к этапу. Количество задач, которые могут реализовываться на каждом из этапов определяется квалификацией специалистов и их количеством.

Рисунок 1. Канбан-доска команды

Таким образом, распределение задач в проекте ведется по функциональному признаку, а постоянную занятость команды обеспечивает тянущая система передачи задач и правильно подобранное максимальное количество одновременно реализуемых задач [16-17].

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

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

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

Таким образом, использование метода должно быть частью реализации Lean-management в проектной сфере, иначе проект будет конфликтовать с внешней средой, а невыполнение некоторых методик управления в проекте может фатально отразиться на продукте и времени проекта.

Эвристические методы

Эвристическими методами называются логические приемы и методические правила научного исследования и изобретательского творчества, которые способны приводить к цели в условиях неполноты исходной информации и отсутствия четкой программы управления процессом решения задачи. В основе эвристического метода лежит как правило алгоритм или математическая модель. Примерами могут являться следующие алгоритмы: эвристический алгоритм распределения заданий между исполнителями (процессорами) [18], метод сопряженных взаимодействий [19], алгоритмы построения расписаний, в том числе генетические алгоритмы. В этом случае объектом упорядочивания являются задачи, которые необходимо расположить таким образом, чтобы минимизировать время выполнения работ или их стоимость. В качестве ограничений обычно выступают бюджет, время и последовательность каждой задачи. Исполнители задач выступают в качестве ресурсов.

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

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

1.3 Метод проведения аукционов

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

Определение понятия аукцион

Аукцион - это способ или процедура покупки-продажи товара или группы товаров. По определениям зарубежных словарей, например, Oxford Advanced Learner's Dictionary, аукцион - это процедура публичной продажи товара покупателю, предложившему наибольшую цену. Цель аукциона - как можно быстрее продать-купить товар, следуя простым правилам [20]. Характерными признаками аукциона являются [21]:

· уникальность и / или неделимость продаваемого товара;

· определенные правила продажи, отсутствие дискриминации, неденежные стратегии продажи;

· изменение цены в ходе аукциона в зависимости от изменения спроса покупателей.

Несмотря на то, что все аукционы демонстрируют публичный конкурентный характер, существуют различия между аукционами, которые связаны с тем, как происходит предложение цен и как они принимаются. Формально предложение цены на аукционе характеризуется двумя параметрами: формой, в которой делается предложение цены, и последовательностью правил предложения цены. Это значит, что предложение цены может происходить в письменной, визуальной или устной форме. В каждом случае такие предложения цены могут быть сделаны в частном порядке (при этом цена объявлена публично, в то время как личность участника может быть скрыта) или публично. В свою очередь последовательность обычно управляется принципом повышения или понижения цены. Однако существуют также аукционы, где предложения цены происходят одновременно. Таким образом, эти переменные порождают ряд возможных типов. Чаще всего используется и обсуждается следующая типология:

1. Английские аукционы, где предложения цены происходят открыто в восходящем порядке с победой высшего предложения.

2. Голландские аукционы, где предложения цены делаются открыто в нисходящем порядке с победой первого и обычно единственного предложения.

3. Японские аукционы (менее распространенные), где одновременно делаются открытые предложения цены, и аукционист выбирает высшее предложение цены, которое он слышал от участников.

4. Аукционы с закрытыми предложениями, где участники представляют на рассмотрение предложения цены, которые открываются одновременно, при этом побеждает высшее предложение цены.

5. Аукционы второй цены, которые являются вариацией предыдущего типа, где, однако, участник, предложивший самую высокую цену, побеждает, выплачивая цену второго наибольшего предложения [22].

Свойства аукционов:

· Эффективны. Они размещают товары наилучшим образом, создавая максимальную ценность от сделки, товар достается тому, кто готов заплатить больше всех.

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

· Явно и быстро определяют цену.

· Используются практически везде. популярная область экономических исследований [23].

Распределение задач методом проведения аукциона

Применение теории аукционов для распределения задач в команде является относительно новой темой исследования, соответственно представленной на эту тему литературы, на данный момент не достаточно, а сама тема изучена плохо. Свара Коппарти (Swara S. Kopparty) рассматривает модель распределения задач, через призму полезности для менеджера, ведущего аукцион, и исполнителя. Полезность менеджера снижается с увеличением ставки по времени. Полезность исполнителя увеличивается обратно пропорционально полезности менеджера. Цель аукциона заключается в поиске равновесия полезностей. Упрощенная модель содержит время в качестве меры и ставок. Однако, автор не исключает определения других показателей в качестве ставки [24]

В работе представлены алгоритмы математического моделирования процесса аукциона, расчета победителя и полезности. Предлагается модель для распределения целостных и делимых задач, разработанная по принципам динамического программирования. Динамическое программирование - метод решения задач путем составления последовательности из подзадач таким образом, что:

· первый элемент последовательности (возможно несколько элементов) имеет тривиальное решение;

· последний элемент этой последовательности - это исходная задача;

· каждая задача этой последовательности может быть решена с использованием решения подзадач с меньшими номерами [25].

Таким образом, комплексные задачи делятся на неделимые целостные и обрабатываются в последовательности. Для последних описан алгоритм оптимального распределения задач и математическая модель определения победителя. В работе автор также отражает результаты симуляции процесса проведения аукциона и проводит верификацию модели. Была доказана эффективность разработанных в работе алгоритмов.

Существующая модель распределения задач методом проведения аукциона

Отправной точкой для текущего исследования является подход, разработанный Крыловым С.В. [26]. Основной целью является распределение задач между исполнителями с максимальной эффективностью. Под эффективностью автор понимает личную заинтересованность исполнителя в выборе и выполнении задачи. Идея использовать личную мотивацию специалиста при распределении задач в команде возникла из модели взаимодействия работодателя и удаленных разработчиков - фрилансеров. Работодатель заинтересован в выполнении работ за минимальные сроки и минимальную цену, достаточную для взятия в работу фрилансером.

Мотивирующим фактором для исполнителя должна стать оплата труда, рассчитанная на основе личного вклада специалиста в проект. Для этого каждая задача должна иметь стоимость - вес.

Модель разработки программного обеспечения в данном методе - итеративная. Менеджер определяет период рабочей итерации, конечный список задач и самостоятельно или совместно с экспертами вес каждой задачи. Под итерацией понимается период разработки программного обеспечения. Пусть длительность итерации равна T_rep, рассчитывается в днях. Тогда, верхняя граница доступных ресурсов рассчитывается следующим образом:

,

где E - это количество разработчиков, - количество уже занятых на данный период ресурсов в чел./дн.

Если , где Z - общее количество задач за период, - требуемые всех задач j ресурсы за период, то выполнение плана невозможно.

Вес каждой задачи W_task зависит от трех основных параметров: коэффициента значимости K (субъективного фактора, отражающего значимость выполнения задачи на данном этапе реализации проекта), средней ставки оплаты разработчика B_eng и продолжительности задачи T_task. Продолжительность задачи рассчитывается по формуле: , тогда вес задачи имеет вид:

Далее список задач выставляется на аукцион. Разработчики делают ставки на каждую задачу в днях, зная свой личный лимит рабочих дней в текущей итерации. В случае, когда двое и более разработчиков указывают одинаковое минимальное время на выполнение задачи, аукцион может быть продолжен. Исполнители, указавшие минимальное количество дней на выполнение задачи, в качестве ставки снижают личный вес задачи W_task до тех пор, пока не определится минимальный вес, за который разработчик готов взять задачу в работу.

По окончанию разработки менеджер проводит приемку задач. Если разработчик выполнил все свои задачи в рамках итерации, ему засчитываются веса по всем задачам. Вес задач, которые не были выполнены вовремя, по усмотрению менеджера присваивается или не присваивается разработчику, а задача переходит на следующую итерацию.

По итогам отчетного периода проводится оценка вклада каждого исполнителя в работу:

.

Если , то имеет место перевыполнение плана, а значит, работник заслуживает поощрения. В случае, когда - план не выполнен.

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

В ходе изучения тендерного метода распределения задач, описанного выше, возникло большое количество вопросов:

· Как должен поступить менеджер, если задачу никто не выбирает?

· Какие задачи стоит или не стоит выносить на аукцион?

· Следует ли отслеживать загрузку персонала?

· Как будут развиваться сотрудники, у которых меньше опыта в реализации задач (следовательно, и в аукционе они будут проигрывать)?

· Как мотивировать сотрудников на выполнение задач, если бюджет по проекту уже превышен?

Для того, чтобы ответить на эти вопросы и проанализировать, было принято решение провести эксперимент, в рамках которого воспользоваться ядром метода - проведением аукциона для выбора исполнителя и срока работы по задаче.

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



2. Проведение эксперимента

Вторая глава посвящена анализу проведенного эксперимента в Компании, занимающейся модификацией и внедрением бизнес-систем. Группе разработчиков в количестве четырех человек было предложено в рамках одного из проектов Компании изменить существующий метод распределения задач (руководителем группы разработчиков) на метод проведения аукционов на задачи.

Основная роль эксперимента в исследовании - доработать существующий алгоритм распределения задач в команде, основанный на теории аукционов. Временные рамки эксперимента: 6 ноября 2014 - 29 апреля 2015.

2.1 Компания как площадка исследования

Описание компании

Компания Complex Software Group, в рамках которой проводилось исследование (далее - Компания), входит в ИТ-холдинг, основанный в 1996 году. Сферой деятельности компании является продажа программного обеспечения и оказание услуг по его внедрению. Компания является партнером ряда отечественных и зарубежных производителей программного обеспечения, с помощью которого организации различных отраслей и масштабов бизнеса могут поднять на новый качественный уровень процессы управления [27]. Компания является проектоориентированной, в число сотрудников компании входят команды специалистов, способные обеспечить модификацию и внедрение новых бизнес-систем клиенту (далее - Заказчик).

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

Организационная структура компании

Организационная структура компании - матричная. Функционально специалисты подчиняются руководителям групп-отделов, но при этом являются членами команды под руководством руководителей проектов. По решению генерального директора в ноябре 2013 года утвердился следующий порядок постановки задач в иерархии Компании: руководитель проекта формирует перечень задач для каждой функциональной группы на период, а руководитель группы распределяет задачи между своими подчиненными самостоятельно. Это решение позволило избежать конфликтов, которые возникали между руководителями проектов из-за личных предпочтений при выборе исполнителей и между несогласованными приоритетами по задачам разных проектов.

Таким образом, с декабря 2013 года по май 2015 года действовала следующая организационная структура:

Рисунок 2. Организационная структура Компании

Актуальность проблемы для Компании

По результатам расчета средней загрузки персонала (отношение времени выполнения задач по проектам к общему числу рабочих часов за месяц), проведенному в сентябре 2014 года в Компании, фактическая загрузка высококвалифицированного разработчика составляет 104-120% в месяц, основного состава разработчиков от 63% до 83%. В коллективе при этом наблюдалось изменение эмоциональной атмосферы: крайняя степень усталости сотрудников, нежелание работать, несмотря на то, что реализация задач по проекту оплачивается в соответствии со временем, фактически затраченным на выполнение поставленных задач.

Учет выполнения задач и затраченного времени на их реализацию ведется на внутреннем портале Redmine. Redmine - это открытое серверное веб-приложение для управления проектами и задачами. Продукт позволяет в том числе вести bug tracking, иными словами отслеживать ошибки. Функционал портала позволяет планировать и ставить задачи в рамках нескольких проектов, вести планирование и учет времени, затраченного на задачу, разграничить права доступа к проектам и компонентам портала на основе ролей [28].

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

Использование портала в Компании для управления задачами на проектах началось в декабре 2013 года, что позволило проанализировать различия между плановым и фактическим временем выполнения задачи. Расчет завершенных задач, поставленных разработчикам, показал, что за январь-октябрь 2014 года 45% задач - 130 из 288 превышают сроки, запланированные на их реализацию. При этом уровень профессиональной подготовки разработчика по мнению руководителя группы соответствовал уровню сложности поставленной задачи. В ходе обсуждения сложившейся ситуации, а также по результатам подсчетов, автором данной работы было предложено руководителю группы разработчиков провести эксперимент и попробовать применить другой метод распределения задач.

2.2 Концепция метода

Для того чтобы изменить подход к распределению задач, руководитель группы разработчиков (еще до старта исследования автором данной работы) решила применить основы методологии Scram. Первое совещание, которое стало началом первого спринта, было проведено 15 сентября 2014 года. На этом совещании руководитель группы был проведен инструктаж и первое планирование задач, сразу по нескольким проектам. Новый подход к распределению задач содержал следующие элементы Scrum:

· Итеративная модель разработки - были выделены спринты и список задач на период спринта.

· Коллективная оценка времени на выполнение задачи.

· Ведение бэклога спринта и проекта в целом.

· Проведение совещания перед стартом спринта.

· Проведение совещания по итогам спринта.

· Ежедневное совещание (одно, утром).

В соответствии с намеченным планом и философией Scrum было проведено три спринта (15-26.09.2014, 29.09-10.10.2014, 13-31.10.2014). Однако по причине того, что совещания перед стартом и по итогам спринта стали занимать больше времени, руководитель группы разработчиков для сокращения времени на обсуждение самостоятельно к третьему спринту начала выставлять оценку времени на исполнение задачи и распределять задачи между разработчиками. В концепции применяемого метода остались принципы выделение периода спринта, ведение бэклога и ежедневные утренние совещания. Метод распределения задач между исполнителями так и не изменился, степень личной мотивации разработчиков осталась на прежнем уровне.

По причине того, что методология Scrum не принесла ожидаемых изменений, был проведен анализ преимуществ и недостатков других методов распределения задач, описанный в п. 1.2 Главы 1. По итогам анализа ни один из методов полностью не удовлетворяет требованиям внутренней структуры Компании, поэтому было принято решение за основу взять один из существующих методов и адаптировать его к реалиям Компании.

Для того, чтобы в полной мере описать методику необходимо провести исследование-эксперимент, определить проблемы, получить обратную связь от участников эксперимента, доработать или модифицировать метод. По этой причине в ноябре 2014 года автором данной работы было предложено применить подход к распределению задач методом проведения аукционов на одном из проектов, находящихся на этапе разработки решения. За основу была взята существующая модель проведения и анализа аукциона, разработанная Крыловым С.В., описанная в п. 1.3.3 Главы 1.

Постановка задачи на проведение эксперимента

Цели эксперимента - исследовать применение метода аукционов для распределения задач в группе разработчиков, проанализировать эффект его применения для дальнейшей доработки или модификации самого метода. Для анализа результатов эксперимента были выдвинуты следующие гипотезы: