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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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. Таблица индивидуальных ставок

Тема	Задача	Приоритет	Оценка времени	Ставка
Отчеты по исполнительской дисциплине	http://srv-direct:8082/redmine/issues/465	Нормальный	45
Заполнение номера ЭД и РКК	http://srv-direct:8082/redmine/issues/492	100	3,5

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

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

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

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

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

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

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 является экспериментальным, в результате чего, часть задач по этому проекту отражается в периоде «До», остальные в периоде «После». Перед расчетом показателей данные реестра были отфильтрованы и проработаны.

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

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

3. В выборке оставлены только те столбцы данных, которые требуются для анализа.

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

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

a. дельта оценки менеджера и затраченного времени на задачу в часах «До»;

b. дельта оценки менеджера и затраченного времени на задачу в часах «После»;

c. дельта оценки исполнителя и затраченного времени на задачу в часах «До»;

d. дельта оценки исполнителя и затраченного времени на задачу в часах «После»;

e. превышение плана по оценке менеджера в процентном соотношении «До»;

f. превышение плана по оценке исполнителя в процентном соотношении «После».

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

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

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

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

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

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

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

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

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

Показатель	Менеджер	Исполнитель
	До	После	До	После
Общее количество задач	339	198	339	198
Количество задач, выполненных своевременно	114	85	125	120
Процент% задач, выполненных своевременно	34%	43%	37%	61%
Количество задач, выполненных раньше срока	77	69	104	69
Процент% задач, выполненных раньше срока	23%	35%	31%	35%
Количество задач, выполненных позже срока	147	44	112	37
Процент% задач, выполненных позже срока	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]. Иными словами, люди работают лучше, когда знают, что за ними наблюдают или когда пробуют что-то новое в ходе трудовой деятельности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководитель проекта сообщает менеджеру группы разработчиков (МГР) об инициации нового проекта или поступлении обращений по текущим проектам и передает МГР необходимые данные:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, где

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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



Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) РейтингCNews100: Крупнейшие ИТ-компании России 2011 // Cnews.ru: издание о высоких технологиях URL: http://www.cnews.ru/reviews/free/2011/rating/rating1.shtml (дата обращения: 05.05.2015).

2) Обзор: ИТ в ритейле 2015 // Cnews.ru: издание о высоких технологиях URL: http://www.cnews.ru/reviews/new/retail_2015/articles/vyruchka_postavshchikov_it_v_ritejl_rastet_nesmotrya_na_krizis/ (дата обращения: 05.05.2015).

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: http://www.hindawi.com/journals/ase/2011/579292/ (дата обращения: 02.04.2015).

4) ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом: Национальный стандарт Российской Федерации ГОСТ Р 54869-2011: введен 22-12-2011/ Федеральное Агентство по Техническому Регулированию и Метрологии. - М.: Стандартинформ. 2011 г. - 6 с.

5) Презентация: Национальные стандарты по управлению проектами, программами и портфелями // PMPractice.ru: Группа Компаний Проектная Практика URL: http://www.pmpractice.ru/img/12.09.20102_prezen.pdf (дата обращения: 10.05.2015).

6) Руководство к своду знаний по управлению проектами (Руководство PMBOK). Четвертое издание: Project Management Institute. - Pennsylvania, 2008 - pp. 463.

7) What is PRINCE2? // Prince2.com: PRINCE2 official web-site URL: http://www.prince2.com/what-is-prince2 (дата обращения: 20.05.2015).

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: http://renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf (дата обращения: 19.04.2015).

16) Scotland K. Aspects of Kanban // Software Development Magazine - Programming, Software Testing, Project Management, Jobs. - 2014.

17) Канбан в IT (Kanban Development), 2009 // Habrahabr.ru URL: http://habrahabr.ru/post/64997/ (дата обращения: 19.04.2015).

18) Ефимкин К.Н. Эвристический алгоритм распределения заданий // Препринты ИПМ им. М.В. Келдыша. 2009. №42. 16 с. URL: http://library.keldysh.ru/preprint.asp? id=2009-42

19) Виттих, В.А. Метод сопряженных взаимодействий для управления распределением ресурсов в реальном масштабе времени / В.А. Виттих, П.О. Скобелев // Автометрия, 2009. - №2.

20) OxfordDictionaries.com: Language matters URL: http://www.oxforddictionaries.com/definition/english/auction (дата обращения: 15.04.2015).

21) Савватеев А.В. Теория аукционов: наиболее значимые достижения // mipt.ipu.ru: Кафедра проблем управления МФТИ URL: http://mipt.ipu.ru/sites/default/files/page_file/%D0% A1% D0% B0% D0% B2% D0% B2% D0% B0% D1% 82% D0% B5% D0% B5% D0% B2.pdf (дата обращения: 17.04.2015).

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: http://habrahabr.ru/company/yandex/blog/246399/ (дата обращения: 17.12.2014).

24) Koppaty S.S. Modelling Task Allocation with Time using Auction Mechanisms: thes. Bachelor of Arts - Harvard College, Cambridge, Massachosetts, 2012 //URL: http://www.eecs.harvard.edu/econcs/pubs/Kopparty_thesis.pdf (дата обращения 12.12.2014).

25) Динамическое программирование // acmp.ru: Школа программиста URL: http://acmp.ru/article.asp? id_sec=1&id_text=1331 (дата обращения: 01.02.2015).

26) Крылов С.В., Тендерный метод распределения задач в команде, 2015.

27) csgro.ru: официальный сайт компании Complex Software Group URL: http://www.csgro.ru/kompaniya.html (дата обращения: 01.05.2015).

28) redmine.org: Redmine official web-site //URL: http://www.redmine.org/ (дата обращения: 13.03.2015)