Учебная работа. Теория аукционов

Теория аукционов

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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], алгоритмы построения расписаний, в том числе генетические алгоритмы. В этом случае объектом упорядочивания являются задачи, которые необходимо расположить таким образом, чтобы минимизировать время выполнения работ или их стоимость. В качестве ограничений обычно выступают бюджет, время и последовательность каждой задачи. Исполнители задач выступают в качестве ресурсов.

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

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

.3 метод проведения аукционов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

,

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.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.

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

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

·Гипотеза 1 — производительность команды не ухудшится.

·гипотеза 2 — производительность команды повысится.

·Гипотеза 3 — исполнители будут выбирать только интересные для них задачи.

·Гипотеза 4 — неинтересные задачи никто не захочет брать в работу.

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

·гипотеза 6 — в аукционах будут выигрывать только самые опытные специалисты.

·Гипотеза 7 — метод позволяет полностью избежать диктата руководителя.

·Гипотеза 8 — метод аукционов применим в Компании, в рамках которой проводилось исследование.

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

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

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

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

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

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

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

.Руководитель группы разработчиков создает новые задачи на портале Redmine, указывает тип задачи (Ошибка / Улучшение / Поддержка / задача), имя задачи, описание, статус (Новая), назначена (группа разработчики), Начата (указывается дата окончания аукциона, время окончания аукциона всегда 11:00 по договоренности), Оценка времени (указывается максимально допустимое время на выполнение задачи в часах).

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

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

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

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

2.3 Сводный анализ результатов

Для исследования применения метода каждого из этапов должен быть зафиксирован результат. Этапы и результаты представлены в Таблице 2 «Этапы эксперимента».

Таблица 2. Этапы эксперимента

№ этапаЭтапРезультатПодробное описание1Организационное собрание по прояснению деталей метода.Перечень выдвинутых гипотез и предположений.П. 2.2.1 Постановка задачи на проведение эксперимента2Адаптация существующего подхода к компании-участнику эксперимента.Описание концепции метода распределения задач путем проведения аукциона. Алгоритм проведения аукциона.П. 2.2.2 Описание первичного алгоритма проведения аукциона3Применение метода на практике.Реестр задач за период применения метода.Сводные данные по выполнению задач на проектах4Проведение интервью.текст интервью.Интервью с участниками эксперимента5Анализ полученных результатов.Выводы по проведенному эксперименту. перечень ограничений, уточнений и дополнительных рекомендаций.Сводный анализ результатов

Каждый из запланированных этапов был пройден и подробно описан в тексте данной работы.

Общая информация об эксперименте:

Временные рамки: 6 ноября 2014 года — 29 апреля 2015 года.

Проект: Проект №4.

Число участников: 4 человека. 1 руководитель группы разработчиков и 3 разработчика.

анализ хода эксперимента

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

первый аукцион был пробным и открытым. На аукцион было вынесено три задачи по разработке. В аукционе принимало участие три человека. Аукцион был проведен сразу после организационного собрания, каждый принимал участие, находясь на своем рабочем месте. Руководитель группы разработчиков создала разговор в системе Skype, в который включила всех участников аукциона. На портале Redmine были созданы три задачи, с указанием группы пользователей «разработчики», ссылки на задачи были отправлены по Skype. Аукцион начался.

Первые ставки были не в виде числа часов, а в виде условных предложений, например, «Смогу сделать к 19:00, итого 5 часов»; «Мне в 18:00 надо уйти, 4 часа». Несмотря не то, что на собрании было оговорено, что ставки в часах, разработчики посчитали нужным аргументировать свои ставки. Более того, третий разработчик не стал писать свою ставку по одной из задач совсем, так как увидела, что не сможет сделать ставку ниже уже предложенных. По опыту проведения первого аукциона были сделаны следующие выводы:

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

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

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

Таблица 3. Таблица индивидуальных ставок

ТемаЗадачаПриоритетОценка времениСтавкаотчеты по исполнительской дисциплине#»justify»>В ходе определения исполнителя по результатам проведения аукциона была отмечена следующая закономерность: на более объемные по трудозатратам задачи разработчики чаще ставили время, соответствующее оценке руководителя или на 1-2 часа меньше. При этом фактически затраченное время превышало оценку исполнителя.

По результатам двух аукционов, проведенных описанным выше способом, были сделаны следующие выводы:

·участник аукциона не должен знать крайний срок и оценку времени руководителем до завершения аукциона, чтобы сделать наиболее объективную ставку;

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

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

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

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

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

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

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

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

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

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

анализ реестра задач

В качестве исходных данных для проведения анализа использовался реестр задач по проектам №2, №3, №4, назначенных группе разработчиков за период с октября 2013 года по апрель 2015 года.

Анализируемый период был разделен на два логических промежутка: «До» — с октября 2013 по февраль 2015 — применение экспертного метода на проектах №2, №3, №4 (на проекте №4 только до октября 2015), «После» — с ноября 2014 по апрель 2015 — применение тендерного метода распределения задач (только по проекту №4). задачи в реестре упорядочены по дате создания.

Проекты №2, №3 отражают действительность без применения методики распределения. Проект №4 является экспериментальным, в результате чего, часть задач по этому проекту отражается в периоде «До», остальные в периоде «После». Перед расчетом показателей данные реестра были отфильтрованы и проработаны.

.Все фамилии, имена и названия проектов были переименованы для проведения анализа, не нарушающего соглашения о неразглашении, подписанного автором данной работы в Компании.

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

.В реестр не попали задачи, выполнение которых не было завершено (статус «Отменена» или готовность не «100%»), задачи в работе (статус «В работе» и «обратная связь») и задачи, которые не были взяты в работу (статус «Новая», пуст исполнитель или затраченное время 0). В итоге в реестре отражены задачи со статусом «Решена» и «Закрыта», с заполненным исполнителем из группы разработчиков.

.К фактическому перечню столбцов были добавлены столбцы вычислений для построения графиков сравнения изменений соответствия оценок менеджера и исполнителя за периоды «До» и «после»:.дельта оценки менеджера и затраченного времени на задачу в часах «До»;.дельта оценки менеджера и затраченного времени на задачу в часах «После»;.дельта оценки исполнителя и затраченного времени на задачу в часах «До»;.дельта оценки исполнителя и затраченного времени на задачу в часах «После»;.превышение плана по оценке менеджера в процентном соотношении «До»;.превышение плана по оценке исполнителя в процентном соотношении «после».

В таблице 4 «Результаты эксперимента по выполнению задач» приведены значения итоговых показателей анализа данных.

Общее количество задач за период с октября 2013 по май 2015 — 537 шт. Из них 339 — отнесены к периоду «До», 198 — к периоду «после».

По результатам применения тендерного метода наблюдаются следующие изменения:

·Доля несвоевременно выполненных задач по оценке менеджера снизилась на 21% (С 43% до 22%).

·доля несвоевременно выполненных задач при планировании исполнителем снизилась на 14% (С 33% до 19%).

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

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

По результатам применения метода аукционов итоговые показатели изменились следующим образом:

Таблица 4. Результаты эксперимента по выполнению задач

ПоказательМенеджерИсполнительДоПослеДоПослеОбщее количество задач339198339198Количество задач, выполненных своевременно11485125120Процент% задач, выполненных своевременно34%43%37%61%количество задач, выполненных раньше срока776910469Процент% задач, выполненных раньше срока23%35%31%35%Количество задач, выполненных позже срока1474411237Процент% задач, выполненных позже срока43%22%33%19%

Рисунок 3. Статистика по задачам, выполненным за период с 12.2013 по 04.2015 в абсолютном выражении, при планировании менеджером

рисунок 4. Статистика по задачам, выполненным за период с 12.2013 по 04.2015 в относительном выражении, при планировании менеджером

рисунок 5. Статистика по задачам, выполненным за период с 12.2013 по 04.2015 в абсолютном выражении, при планировании исполнителем

рисунок 6. Статистика по задачам, выполненным за период с 12.2013 по 04.2015 в относительном выражении, при планировании исполнителем

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

С другой стороны, не стоит забывать о возможности Хоторнского эффекта. Этот эффект стал результатом глобального эксперимента в Hawthorne Western Electric Company. Целью эксперимента было определить влияния различных параметров среды на производительность труда. Начиная с весны 1932 года эксперты по производительности провели ряд испытаний. Они увеличивали освещённость и заметили, что производительность увеличилась. затем они снизили освещённость и заметили, что производительность увеличилась ещё больше. Тогда было выдвинуто предположение, что если отключить свет совсем, производительность «выбьет потолок». Это означает, что влияние оказывает не изменение, но сам его факт. Участникам эксперимента было известно, что за ними наблюдают, им было приятно, что на них обратили пристальное внимание, их интриговала новизна. Это явление получило название эффекта Хоторна (Hawthorne Effect) [29-30]. иными словами, люди работают лучше, когда знают, что за ними наблюдают или когда пробуют что-то новое в ходе трудовой деятель.

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

анализ интервью

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

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

По результатам интервью методика также должна включать:

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

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

.Условия применения тендерного метода, включающие тип проекта, этапы проектов, допустимые размеры команд, возможность или невозможность применения распределенными командами.

.рекомендации по программно-техническому обеспечению процесса распределения задач.

Проверка гипотез

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

Таблица 5. Результаты доказательства гипотез

№ГипотезаДоказана?Основание1Производительность команды не ухудшится.ДаПроцент задач, выполненных вовремя, увеличился с 57% до 67% на основании расчетов по реестру задач.2Производительность команды повысится.ДаПроцент задач, выполненных вовремя, увеличился с 57% до 67% на основании расчетов по реестру задач3Исполнители будут выбирать только интересные для них задачиНетЕсли специалист свободен, то он участвует в аукционе в любом случае — анализ задач и вопрос интервью №4.4Неинтересные задачи никто не захочет брать в работу.НетАнализ реестра задач и проведенное интервью, вопрос №4.5Оценка времени исполнителем на выполнение задачи за период будет стремиться к факту.ДаПри построении линии тренда интервал последних значений практически совпадает осью абсцисс.6В аукционах будут выигрывать только самые опытные специалисты.НетОпытные специалисты стараются брать задачи посложнее — анализ реестра задач.7Метод позволяет полностью избежать диктата руководителя.Не доказанаКонфликтные ситуации и задачи высокой важности распределял руководитель группы в ходе эксперимента.8Метод аукционов применим в Компании, в рамках которой проводилось исследованиеДаПо результатам интервью метод требует доработки.

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

3. Разработка методики распределения задач

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

·Как выделить итерации разработки в рамках нескольких проектов.

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

·Какие задачи рекомендуется выносить на аукцион.

·Какие правила проведения аукциона.

·Как распределять задачи, которые не были вынесены на аукцион.

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

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

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

Структура методики должна включать в себя следующие разделы:

.Цель и назначение методики

.Термины и условные обозначения

.Условия применения методики

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

.Перечень рекомендаций по организации этапов процесса.

Цель методики — организовать процесс распределения задач в рамках нескольких проектов.

назначение методики — методика позволяет исполнителям выбирать задачи самостоятельно в рамках своих компетенций. Методика позволяет исполнителям одновременно работать на нескольких проектах.

Условия применения методики

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

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

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

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

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

·В проектах, рамки которых позволяют организовать полноценное применение тендерного метода: должны включать этап разработки или модификации программного решения длительностью более месяца (4 недель) для возможности организации итеративного процесса разработки.

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

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

Роли процесса:

Участники процесса распределяются согласно ролям, приведенным в таблице 6 Роли процесса.

Таблица 6. Роли процесса

п/пНаименование ролиОписание роли1.руководитель проектаСотрудник организации, выполняющий функции организации и управления проектами. Является инициатором процесса проведения аукциона. Принимает решения по составу, срокам и результатам итераций проекта.2.Менеджермежду исполнителями, как правило, подчиненными ему. определяет состав, сроки и результаты итераций проектов. Является организатором аукционов.3.Специалист группы разработчиковРазработчик, который является исполнителем задачи; определяется по результатам проведения аукциона или назначается при определенных условиях менеджером группы разработчиков.4.СистемаПрограммное решение автоматического определения оптимальных значений (Исполнителей) по заданным параметрам.

Описание процесса:

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

.Инициация проекта.

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

·Если предполагается проведение запланированного аукциона, формирует перечень требований к разработке / модификации для формирования плана-графика работ и определения состава итераций по нему (п. 2).

.Определение состава, сроков и результатов итераций по проекту в части разработки.

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

.Согласование состава, сроков и результатов итераций по проекту в части разработки.

Руководитель проекта получает на рассмотрение перечень итераций, разработанный МГР:

·Если замечания по срокам завершения, составу, результатам итераций отсутствуют, согласует перечень, далее МГР приступает к организации и проведению аукциона.

·Если сроки завершения, состав, результаты итераций требуют корректировки, возвращает МГР перечень на корректировку.

.Определение состава задач на итерацию. Формирование реестра задач, выносимых на аукцион.

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

.Организация и проведение аукциона

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

·Если определены все исполнители, задачи передаются в работу (п. 8).

·Если определены не все исполнители, в системе задаются параметры для расчета оптимального распределения задач между исполнителями с учетом их квалификации, навыков, загрузки (п. 6).

.Определение оптимальных исполнителей по заданным критериям.

С учетом введенных менеджером группы разработчиков параметров система выполняет расчет. Результаты передаются МГР для принятия решения (п. 7).

.Принятие решения по распределению задач.

МГР анализирует расчет, выполненный системой и принимает решение по распределению задач между исполнителями с учетом собственного экспертного мнения:

·После того как исполнители определены, задачи передаются в работу (п. 8).

·В случае, если решение не было принято, МГР инициирует проведение очередного аукциона (п. 5).

.Исполнение задач в рамках итерации

специалисты группы разработчиков получают задания, назначенные им в качестве исполнителей по итогам аукциона. далее МГР проверяет выполненные задания (п. 9).

.Проверка качества и объема выполненных задач.

МГР оценивает качество и объем выполненных задач, при необходимости формирует рекомендации и требования по доработке.

.Оценка результатов итерации.

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

·Если задачи выполнены в полном объеме, процесс завершается.

·Задачи, требующие выполнения, переносятся на следующий аукцион (п. 5).

·

Рисунок 7. Схема процесса распределения задач в команде

3.3 перечень рекомендаций по организации этапов процесса

Подготовка к внедрению метода

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

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

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

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

Определение итераций по проектам

руководитель проекта формирует план-график работ, консультируясь по вопросам разработки с менеджером группы разработчиков. Поскольку за основу взята итеративная модель разработки, проект в каждой фазе развития проходит повторяющийся цикл PDCA (англ. plan-do-check-act): Планирование — Реализация — Проверка — Оценка. При условии, что этап разработки по трудоемкости составляет более четырех недель его необходимо разделить на итерации таким образом, чтобы длительность каждой итерации составляла 2-4 недели и по результатам каждой итерации была готова некоторая функциональная часть проекта. Требуется также в итерацию включить время на проверку, иными словами, на тестирование разработанного функционала. По результатам итерации должна проводиться оценка результатов и с точки зрения проекта в целом, и с точки зрения личного вклада каждого исполнителя в проект.

Определение состава задач на каждую итерацию

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

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

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

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

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

, где

· итоговый вес задачи;

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

· — длительность задачи, рассчитывается по формуле , где — это трудоемкость задачи (соответствует максимально заложенной в бюджет проекта трудоемкости), — количество исполнителей;

·K — коэффициент критичности выполнения задачи в срок (например, 80%, когда задача находится на критическом пути и увеличение сроков ее выполнения может привести к увеличению сроков всего проекта), степени ее важности. Коэффициент рекомендуется понимать как процент удорожания задачи для исполнителя.

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

Помимо веса и срока задачи необходимо определить ее приоритет по сравнению с другими задачами в рамках итерации. Это требуется сделать для того, чтобы сообщить разработчикам порядок выполнения тех или иных задач. например: 30, 50, 80 (при шкале 10-100); или: низкий, Нормальный, Высокий, Срочный, Немедленный.

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

Готовой задаче присваивается статус «Аукцион». Рекомендуемые статусы задачи: Новая, Аукцион, В работе, Решена, Обратная связь, Закрыта.

рисунок 8. Жизненный цикл задачи

Проведение аукциона

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

За время, отведенное на аукцион, участники аукциона изучают задачи и делают свою ставку — срок выполнения задачи в единицах измерения, определенных ранее (например, в часах). Ставки участников на время проведения аукциона никому не доступны. Как только все участники аукциона сделают свои ставки на все доступные по уровню квалификации задачи или по достижению времени окончания аукциона определяется победитель аукциона и срок выполнения задачи.

Все разработчики должны сделать ставку на все доступные по уровню его квалификации задачи.

Победитель определяется следующим образом:

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

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

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

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

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

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

Оценка результатов итерации

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

Заключение

В ходе исследования методов распределения задач между исполнителями в литературе и на основе проведенного эксперимента была проделана работа по сбору и анализу базовых принципов управления командой разработчиков. Был проведен анализ стандартов управления проектами (PMI (PMBoK), PRINCE2, P2M, ГОСТ Р 54869-2011), методов организации работ в команде и методов распределения задач в рамках проектной деятель. По результатам анализа методов Scrum, Poker Plannig, Канбан, экспертного подхода и эвристических алгоритмов распределения ресурсов был сделан вывод об их недостаточной эффективности при использовании в организациях с матричной структурой. На основе полученных данных был составлен перечень требований к методу распределения задач.

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

·Производительность команды не ухудшится — производительность команды не ухудшилась.

·Производительность команды повысится — производительность команды увеличилась.

·Оценка времени исполнителем на выполнение задачи за период будет стремиться к факту — к апрелю 2015 года разница между планом исполнителя и фактом не превышала 1 часа.

·Метод аукционов применим в Компании, в рамках которой проводилось исследование — применима упрощенная модель, а также разработанная по дополнительным требованиям полноценная модель.

Были опровергнуты и учтены в разработанной методике следующие гипотезы:

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

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

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

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

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

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

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

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

Библиографический список

1)РейтингCNews100: Крупнейшие ИТ-компании россии 2011 // Cnews.ru: издание о высоких технологиях URL: #»justify»>2)Обзор: ИТ в ритейле 2015 // Cnews.ru: издание о высоких технологиях URL: #»justify»>3)Yiftachel P., Hadar I., Peled D., Farchi E., Goldwasser D. The Study of Resource Allocation among Software Development Phases: An Economics-Based Approach. // Advances in Software Engineering, vol. 2011, 2011 //URL: #»justify»>4)ГОСТ Р 54869-2011. Проектный Менеджмент. Требования к управлению проектом: Национальный стандарт российской Федерации ГОСТ Р 54869-2011: введен 22-12-2011/ Федеральное Агентство по Техническому Регулированию и Метрологии. — М.: Стандартинформ. 2011 г. — 6 с.

5)Презентация: Национальные стандарты по управлению проектами, программами и портфелями // PMPractice.ru: Группа Компаний Проектная Практика URL: #»justify»>6)руководство к своду знаний по управлению проектами (руководство PMBOK). Четвертое издание: Project Management Institute. — Pennsylvania, 2008 — pp. 463.

7)What is PRINCE2? // Prince2.com: PRINCE2 official web-Site URL: #»justify»>8)ГОСТ Р 54869-2011. Проектный Менеджмент. Требования к управлению проектом: Национальный стандарт российской Федерации ГОСТ Р 54869-2011: введен 22-12-2011/ Федеральное Агентство по Техническому Регулированию и Метрологии. — М.: Стандартинформ. 2011 г. — 10 с.

9)Shigenobu Ohara. P2M: A Guidebook of Project & Program Management for Enterprise Innovation. Project Management Association of Japan. Vol.1 — 2005. — p. 93

10)Microsoft Corporation. гибкая методология разработки программного обеспечения — М.: «русская редакция, 2008. 127 с.

11)Якимчук С. MSF — философия создания IT-решений или голые амбиции лидера // IT Manager. — 2004.

12)Минцберг Г., Куинн Дж.Б., Гошал С. Стратегический процесс / Пер. с англ. Под ред. Ю.Н. Каптуревского. — СПб.: Питер, 2001. — 688 с.

13)Кравченко А.И. История менеджмента. — 5-е изд. — М.: Академ, 2005.

14)Schwaber K., Sutherland J. The Definitive Guide to Scrum: The Rules of the Game. — Scrum. Org and ScrumInc., 2013.

15)Grenning G., Planning Poker or How to avoid analysis paralysis while release planning // URL: #»justify»>16)Scotland K. Aspects of Kanban // Software Development Magazine — Programming, Software Testing, Project Management, Jobs. — 2014.

17)Канбан в IT (Kanban Development), 2009 // Habrahabr.ru URL: #»justify»>18)Ефимкин К.Н. Эвристический алгоритм распределения заданий // Препринты ИПМ им. М.В. Келдыша. 2009. №42. 16 с. URL: #»justify»>19)Виттих, В.А. метод сопряженных взаимодействий для управления распределением ресурсов в реальном масштабе времени / В.А. Виттих, П.О. Скобелев // Автометрия, 2009. — №2.

20)OxfordDictionaries.com: Language matters URL: #»justify»>21)Савватеев А.В. Теория аукционов: наиболее значимые достижения // mipt.ipu.ru: Кафедра проблем управления МФТИ URL: #»justify»>22)Smith Ch. Auctions: From Walras to the Real World // Explorations in Economic Sociology / Ed. R. Swedberg. New York: Russell Sage, 1993. РР. 313 — 341.

23)Математика аукционов. Лекции в яндексе // habrahabr.ru URL: #»justify»>24)Koppaty S.S. Modelling Task Allocation with Time using Auction Mechanisms: thes. Bachelor of Arts — Harvard College, Cambridge, Massachosetts, 2012 //URL: #»justify»>25)Динамическое программирование // acmp.ru: Школа программиста URL: #»justify»>26)Крылов С.В., Тендерный метод распределения задач в команде, 2015.

27)csgro.ru: официальный сайт компании Complex Software Group URL: #»justify»>28)redmine.org: Redmine official web-Site //URL: #»justify»>29)Jeffery, D.R., and M.J. Lawrence. «Managing Programming Productivity» Journal of Systems and Software, Vol. 5, No. 1 (January 1985)

30)Parsons, H.M. What Happened at Hawthorne? Science, Vol. 183 (March 8,1974), pp. 922-932

Учебная работа. Теория аукционов