Исследование влияния применения составляющих элементов гибких методологий на успех ИТ-проекта

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

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



Глава 2. Проведение анкетного опроса и построение регрессионной модели

2.1 Описание методологии исследования

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

Анкетный вопрос решает следующие задачи:

Сбор данных по экспертам из разных индустрий и разными проектными ролями;

Экономия времени для респондента приводит к росту количества в полученных ответов;

Формализованность результатов;

Минимизация влияния исследователя на ответы респондента.

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

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

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

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

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

Проведение анкетного опроса

2.2 Описание анкетного опроса

В период октябрь - ноябрь 2019 года было проведен анкетный опрос на тему «Использование гибких методик в управлении ИТ-проектами». Анкета была посвящена поиску влияния отдельных элементов гибких методологий на успех проекта на практических примерах. Одна анкета покрывала один ИТ-проект и состояла из разделов:

Сведения о респонденте;

Сведения о компании, для которой осуществлялся проект;

Сведения о проекте;

Использование гибких методологий в управлении проектами;

Успех проекта.

Подробное содержание анкеты можно увидеть в Приложении 1.

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

Количественные результаты анкетного опроса

Характеристика респондента, компании, проекта

По статистике наиболее частый ответ среди респондентов по опыту лет в управлении проектами (далее - УП) составил 2-5 лет (37% ответов), 5-7 лет (27%) и менее 2 лет (23%) (см. Рис.5). Наиболее частая роль среди респондентов - менеджер проекта (50% ответов) (см. Рис 6). Так, в среднем ответы будут представлять мнение руководства проекта со средним опытом работы на 2-4 проектах.

Рис. 5. Опыт работы в УП среди респондентов, %

Рис 6. Самая частая роль на проекте среди респондентов, %

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

Российского происхождения (см. Рис. 7);

Являющейся крупным предприятием (см. Рис. 8);

Возрастом более 10 лет (см. Рис. 9).



Рис. 7. Происхождении компании проекта респондента, %

Рис. 8. Персонал компании проекта респондента, %

Рис. 9. Возраст компании проекта респондента, %



Рис. 10. Отрасль компании проекта респондента, %

Отрасль компании в большинстве случае представлена финансовым сектором (40% ответов) и ИТ- и телеком- компаниями (27%), что ожидаемо, т.к. ИТ-проекты с использованием гибких методологий начались именно в таких компаниях (см. Рис. 10) (Agile Alliance, 2010).

Чтобы оценить уровень открытости к использованию гибких методологий и наличие экспертов в области, что является одним из главных факторов успешного использования гибких методов и методик, респондентам предлагалось выбрать оценку, в большей степени выражающую согласие с приведенными утверждениями (1 - абсолютно не согласен, 2 - не согласен, 3 - затрудняюсь ответить, 4 - согласен, 5 - абсолютно согласен):

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

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

Далее представлена статистика по описанию проекта, в котором использовались гибкие методологии. 

Рис 11. Размер бюджета проекта респондента, %

Рис 12. Размер команды проекта респондента, %

Проекты выборки в большей степени характеризуются крупным бюджетом, более 15 млн. руб. (см. Рис.11), небольшой командой в количестве менее 50 человек (44% ответов) (см. Рис. 12), что объясняется высокой квалификацией и востребованностью специалистов с одной стороны и спецификой использования гибких методологий, состоящей в организации небольших кросс-функциональных команд, - с другой стороны.

По статистике в 60% случаев команда проекта была распределенной. Чаще всего удаленно работают разработчики и технические специалисты (см. Рис.13). Современные способы связи позволяют поддерживать эффективную и постоянную коммуникацию и привлекать экспертов из разных регионов. Длительность проекта в 60% случаев составила 1 год, что характерно для ИТ-проекта средней сложности (см. Рис.14) (Reddy, 2016).

Рис 13. Местоположение команды проекта, %

Рис 14. Длительность проекта, %

Использование элементов гибких методологий

Далее речь пойдет об использовании отдельных гибких методик для УП. Респондентам предлагалось выбрать гибкие методики, которые были использованы на проекта (см. Рис.15).

Наиболее часто используемые методики, выделенные оранжевым цветом на Рис. 15, а именно: Бэклог, Стэнд-ап, Пользовательские истории, Спринт, Канбан-доска и Ретроспектива - будут использованы в дальнейшем для построения регрессионной модели.

Фокус-группе, состоящей из 7 экспертов в области УП предлагалось определить пары гибких методик, наиболее часто используемых вместе в УП. Далее респондентам предлагалось выбрать пары, которые были использованы на описываемом проекта. Была получена следующая статистика (см. Рис. 16).

Рис 15. Частота использования гибкой методики

Рис 16. Частота использования пар гибких методик

Как видно на Рис. 16, наиболее часто используемые пары, а именно ТОП-4 из 12, пересекаются с наиболее популярными отдельно используемыми гибкими методиками. Можно ожидать, что при регрессионном анализе будут выявлены пары и, возможно, тройки наиболее часто используемых гибких методик. Успех проекта

Один из разделов опроса состоял в оценке успеха проекта, в управлении которым использовались гибкие методики. Респондентам предлагалось сначала выбрать характеристики успеха проекта, входящие в официальные критерии успеха, а потом оценить все по 5-ти балльной шкале Лайкерта с обозначениями: 1 - абсолютно не согласен, 2 - не согласен, 3 - затрудняюсь ответить, 4 - согласен, 5 - абсолютно согласен.

Рис 17. Частота использования критерия успеха проекта

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



Рис. 18. Оценка успеха проекта

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

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

Техника	Срок	Бюджет	Качество	Объем	Заказчик	Пользователь	Команда	Прибыль	Не знаю/не использую	Сумма
Бэклог	15	8	12	19	10	7	6	0	6	77
Пользовательские истории	7	6	14	13	9	13	9	4	6	75
Спринт	21	6	10	10	9	8	12	2	7	78
Стэнд-ап	18	0	13	9	6	2	13	0	4	61
Оценка ПИ в очках	7	4	7	11	2	1	6	0	14	38
Scrum-роли	3	2	10	6	4	3	11	0	12	39
Ретроспектива	4	0	14	4	9	5	17	1	5	54
Канбан-доска	19	2	10	16	5	3	11	0	7	66
Ограничение по количеству задач на одной стадии	9	5	15	7	3	2	10	0	7	51
Игра в планирование	6	3	3	3	7	6	9	1	18	38
Парное программирование	2	0	9	3	2	1	6	0	18	23
Разработка через тестирование	4	1	10	5	1	2	6	0	17	29
Быстрая обратная связь	8	3	10	4	11	11	12	3	8	62
Непрерывная интеграция	10	1	7	5	7	5	5	2	15	42
Рефакторинг	2	3	10	2	1	0	2	1	20	21
Небольшие, но частые релизы	9	3	10	6	8	6	5	2	12	49
Стандарты написания кода	6	2	13	5	0	1	6	0	13	33
Коллективное владение кодом	5	1	12	5	0	0	6	0	16	29
Простой дизайн	4	0	8	0	4	5	3	0	16	24
Системная метафора	1	0	4	1	0	1	5	0	21	12
Фиксированный рабочий день для разработчиков	2	3	1	1	1	0	10	1	15	19
Короткие итерации (1-2 нед.)	11	3	6	6	4	6	6	1	11	43
Планирование по требованию	3	1	4	2	4	3	3	0	19	20
Планирование «по корзинам»	5	2	3	2	4	1	3	0	21	20
«Заморозка функций»	4	3	2	5	2	2	3	1	22	22
Сортировка оставшихся задач	7	2	6	11	3	1	5	0	16	35

Влияние использования гибких техник на критерии успеха проекта

Из данной статистики можно сделать несколько важных выводов:

Респонденты, по большей части являющиеся менеджерами проекта, не осведомлены о влиянии той или иной техники на успех проекта (см. столбец «Не знаю/не использую» на Рис. 16).

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

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

В препоследнем разделе респонденты должны были оценить по шкале Лайкерта, как тот или иной фактор может помешать эффективному использованию гибких методологий. «Стоп-факторы» были выявлены при анализе литературы выше. Результаты представлены на Рис. 20:



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

Наиболее важными «стоп-факторами» были выделены:

Неготовность руководства;

Консервативная культура компании;

Отсутствие необходимых экспертов.

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

Качественные результаты анкетного опроса

В ходе сбора данных анкетного опроса респондентам предлагалось оставить комментарии в открытой форме на тему УП при помощи гибких методик. Некоторые мнения относительно применения элементов гибких методологий повторялись в нескольких ответах, а именно:

Итеративный подход позволяет уменьшить издержки по внесению изменений в требования.

Гибкие методологии позволяют быстро реагировать на внешние изменения рынка.

Гибкость в планировании позволяет вовремя и полно учитывать обратную связь заказчика и конечного пользователя.

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

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

2.3 Построение регрессионной модели

Описание регрессионной модели

В качестве регрессионной модели будет использована линейная МНК-модель, построенная с помощью языка программирования Python (код указан в Приложении 2). Будет построено две модели - с присвоением разных весов каждому показателю успеха проекта в зависимости от частоты его упоминания и с присвоением одинакового веса - 1.

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

, где c - оценка критерия от 1 до 5

, где w - вес критерия, c - оценка критерия от 1 до 5

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

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

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

Оценка наличия экспертов в штате в области УП по гибким методологиям

Результаты регрессионного анализа

Здесь и далее приведены результаты модели два (с регрессантом success 2). Результаты консистентны с результатами модели один, приведенной в Приложении 3. На первой итерации регрессионного анализа были получены следующие результаты:

Рис. 21. Результаты первой итерации регрессионного анализа.

Гипотеза о незначимости регрессии отвергается на любом адекватном уровне значимости. R^2 составляет 68%, что говорит о нормальной объясняющей силе регрессии. Количество наблюдений - 30, что позволяет сделать допущение о нормальном распределении наблюдений.

Как видно из Рис. 16, на 5%-ном уровне значимости оказались значимыми дамми-переменные standup, kanban и переменная openness, которые будут использованы на следующей итерации.

Результаты второй итерации представлены на Рис.22.



Рис. 22. Результаты второй итерации регрессионного анализа.

Регрессия по-прежнему остается значимой, хотя R^2 немного уменьшился - до 58% (см. Рис.18). Все переменные оказались значимыми. Прежде чем интерпретировать результаты, проведем несколько статистически тестов.

Проверка на гетероскедастичность, мультиколлинеарность и на ненормальность остатков

Прежде всего был проведен тест на мультиколлинеарность. Фактор инфляции дисперсии (VIF) для всех переменных меньше 5, что говорит об отсутствии мультиколлинеарности (см. Рис.23).

Рис. 23. Показатель VIF для регрессии.

Для проверки гипотезы о том, что остатки данного ряда имеют нормальное распределение, была использована статистика Жака-Бера, которая составила 0,31. Нулевая гипотеза о нормальности распределения остатков не отвергается на любом адекватном уровне значимости (p-value = 0,86).

С помощью теста Бройша-Пагана было исследовано наличие гетероскедастичности. P-value составило 0,16, то есть нулевая гипотеза о гомоскедастичности не отвергается на 15% уровне значимости.

Итоговое уравнение регрессии выглядит следующие образом:

,

Проинтерпретируем результаты:

Коэффициент в размере около 3,6 при дамми-переменных свидетельствует о том, что при использовании Стэнд-апа или Канбан-доски консолидированная переменная успеха проекта увеличивается на 2-3 балла.

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

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

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

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



Глава 3. Рекомендации и дальнейшее исследование

3.1 Практические рекомендации

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

Практические рекомендации можно разделить на две составляющие:

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

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

В таблице ниже приведено, какие действия выполняет проектная команда при реализации проекта и на что необходимо обратить внимание с точки зрения того, как это выполняется. При подготовке таблицы был использован практический опыт реализации ИТ-проекта при помощи гибких методологий (внедрение ИТ-системы в страховую компанию, а также кейсы компаний КиноПоиск, Вымпелком, Sokolov, HeadHunter, ЦИАН и др.) (на основе данных компании ScrumTrek):

Таблица 3 Действия проектной команды и специфические характеристики их выполнения

№	Что мы делаем	Как мы это делаем
1	Выбор критериев успеха проекта	- Привлечение всех стейкхолдеров в формирование понятия «успех данного проекта» - Включение не только количественных, но и качественных показателей - Трансляция выбранного подхода внутри команды
2	Формирование методологии проекта	- Обучение команды, включая руководство, бизнес-пользователей - Привлечение экспертов - Использование Стэнд-апа, Канбан-доски
3	Открытость к изменениям	- Выводы на основе собранных метрик и собранной обратной связи - Вовлечение руководства/экспертов для реализации изменений в процессе реализации проекта
Окончание Таблицы 3
4	Следование гибкой культуре	- Наличие коммуникации между всеми участниками проекта - Постоянное улучшение процессов - Прозрачность выполнения проекта
5	Сбор данных о выполнении проекта	- Проведение «работы над ошибками» - фиксация и поиск решения ошибок, допущенных в проекте - Управление знаниями - сбор полезных практик, успешных шаблонов хранения данных
6	Транслирование опыта внутри компании	- Коммуникация внутри компании - Реализация схожих проектов с опытной командой

По итогам Главы 2 были выделены две практики, гарантированно эффективные для реализации ИТ-проекта - Стэнд-ап и Канбан-доска. Данные техники часто выполняются неправильно, что приводит к их неэффективности. Далее буду описаны основные ошибки в использовании данных техник и предложены рекомендации по их исправлению.

3.2 Практическое применение практики Стэнд-ап

Основные ошибки (как мы это делаем) при использовании практики Стэнд-ап заключаются в следующем:

Слишком большое количество участников

Каждый участник должен быть активно вовлечен и отвечать на три вопроса - Что я делал вчера? Что я делаю сегодня? Какие препятствие мне мешают? Если на встрече есть «слушатели», то встреча проходит неэффективно, т.к. проходит рабочее время людей, не нужных на Стенд-апе. По этой причине в Стэнд-апе участвуют только руководители команд, скрам-мастер, если он есть, и бизнес-эксперты. Количество участников ограничивается до 6.

Иерархичное, а не линейное взаимодействие участников

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

Гибкий формат встречи

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

Практическое применение практики Канбан-доска

Основные ошибки (как мы это делаем) при использовании практики Канбан-доска заключаются в следующем:

Отсутствие ограничений на количество задач на одной стадии

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

Отсутствие всех задач проекта на Канбан-доске

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

Отсутствие обратной связи - анализа своей работы и работы команды

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

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

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

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

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

Примеры практического применения гибких практик при управлении ИТ-проектам при помощи специализированного ПО представлены ниже:

Рис. 23. Демонстрация интерфейса ПО Atlassian Jira

Источник: официальный сайт Atlassian

Рис. 24. Демонстрация интерфейса ПО Microsoft Azure DevOps Server

Рис. 25. Демонстрация интерфейса ПО VersionOne



Источник: официальный сайт Collab.Net

Рис 26. Демонстрация интерфейса ПО Microsoft Excel, настроенного в виде Канбан-доски

Источник: Примеры адаптации и использования Microsoft Excel для прикладных бизнес-задач Vertex42 Blog

3.3 Дальнейшее исследование

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

Несмотря на достаточно большой опыт изучения темы в академическом мире, проектный менеджер испытывает трудности в 1) ознакомлении с методологией, 2) выяснением того, наиболее ли эффективно будет именно эта методология на проекте, 3) с внедрением методологии на проекте и в компании.

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

Региона проекта/компании;

Индустрии проекта;

Возраста компании;

Соотношения частного и государственного капитала в компании;

Характеристик заказчика

И др.

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

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

От чего зависит эффективность применения гибких методологий?

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

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

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

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



Заключение

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

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

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

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

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



Библиография

1. Кент Бек: Экстремальное программирование -- Питер, 2002. 224 с.

2. Anderson, D. Kanban-Successful Evolutionary Change for Your Technology Business - WA: David J. Anderson & Associates Inc, Seattle, 2010.

3. Highsmith, J. Agile Project Management: Creating Innovative Products - Addison-Wesley, Upper Saddle River (NJ), 2010.

4. Ladas, C. Scrumban: Essays on Kanban Systems for Lean Software Development - Modus Cooperandi Press. 2009

5. Project Management Institute. A Guide to the Project Management Body of Knowledge - Third Edition, Project Management Institute Inc., 2004.

6. Project Management Institute. A Guide to the Project Management Body of Knowledge - Fourth Edition, Project Management Institute Inc., 2008.

7. Project Management Institute. A Guide to the Project Management Body of Knowledge - Fifth Edition, Project Management Institute Inc., 2013.

8. Reddy, A. Scrumban [R]Evolution- Get the most out of Agile, Scrum and Lean Kanban - Pearson, 2016.

9. Schwaber, K.; Beedle, M. Agile software development with Scrum - Prentice Hall, 2002.

10. Smite, D., Moe, N.B., Agerfalk, P.J. Fundamentals of agile distributed software development. Agility Across Time and Space. - Springer-Verlag, Berlin, Heidelberg. 2010

11. Stephens, M., Rosenberg, D. The irony of extreme programming. - MA: Dr Dobbs journal. Apress L.P. 2004.

12. Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time. - Crown Publishing Group. 2014.

13. Никулина Т.Ю. Факторы успеха проектов разных типов в зависимости от применения различных элементов гибких методологий // Курсовая работа. 2019

14. Agarwal, N., Rathod, U. Defining “success” for software projects: An exploratory revelation // International Journal of Project Management. 2006. Vol. 24 (4). P. 58-70.

15. Akif, R., Majeed, H. Issues and Challenges in Scrum Implementation // International Journal of Scientific & Engineering Research. 2012. Vol. 3 (8).

16. Alami, A. Why do Information Technology Projects Fail? // Procedia Computer Science. 2016. Vol. 100, P. 62-71.

17. Albert, M., Balve, P., Spang, K. Evaluation of project success: a structured literature review // International Journal of Managing Projects in Business. 2017. Vol. 10 (4). P. 796-821.

18. Al-Tmeemy, S. M. H. M., Abdul-Rahman, H, Harun, Z. Future criteria for success of building projects in Malaysia // International Journal of Project Management. 2011. Vol. 29 (3). P. 337-348.

19. Atkinson, R. Project management Cost time and quality, two best guesses and a phenomenon, it's time to accept other success criteria // International Journal of Project Management. 1999. Vol. 17 (6). P. 337-342.

20. Baccarini, D. The logical framework method for defining project success // Project Management Journal. 1999. Vol. 30 (4). P. 25-32.

21. Baccarini, D., Collins, A. The concept of project success - what 150 Australian project managers think // Australian Institute of Project Management (AIPM) Conference: Perth 2004, 10-12th October, 2004.

22. Boehm, B., Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed // Boston, MA: Addison-Wesley, 2004.

23. Chang, A., Chih, Y. Y., Chew, E, Pisarski, A. Reconceptualising mega project success in Australian Defence: Recognising the importance of value co-creation // International Journal of Project Management. 2013. Vol. 31 (8). P. 1139-1153.

24. Chow, T., Cao, D.B. A survey study of critical success factors in agile software projects // The Journal of Systems and Software. 2008. Vol. 81. P. 961-971.

25. Cohn, M., Ford D. Introducing an agile process to an organization // IEEE Computer. 2003. Vol. 36 (6). P. 74-78.

26. Collins, A., Baccarini, D. Project Success. A Survey // Journal of Construction Research. 2004. Vol. 5 (2). P. 211-231.

27. Collyer, S., Warren, C. M. J., Hemsley, B., Stevens, C. Aim fire aim - project planning styles in dynamic environments // Project Management Journal. 2010. Vol. 41 (4). P. 108-121.

28. Cusumano, M.A., Selby, R.W. How Microsoft Builds Software // Communications of the ACM. 1997. Vol. 40 (6).

29. Davis, K. Different stakeholder groups and their perceptions of project success // International Journal of Project Management. 2014. Vol. 32 (2). P. 189-201.

30. Davis, K. An empirical investigation into different stakeholder groups perception of project success // International Journal of Project Management. 2017. Vol. 35 (4). P. 604-617.

31. Diallo, A., Thuillier, D. The success dimensions of international development projects: the perceptions of African project coordinators // International Journal of Project Management. 2004.Vol. 22. P. 19-31.

32. Dvir, D., Raz, T., Shenhar, A. An empirical analysis of the relationship between project planning and project success. International Journal of Project Management. 2003. Vol. 21 (2). P. 89-95.

33. Hдllgren, M., Maaninen-Olsson, E. Deviations, ambiguity and uncertainty in a project-intensive organization // Project Management Journal. 2005. Vol. 36 (3). P. 17-26.

34. Hassan, M. M., Bashir, S., Abbas, S. M. The Impact of Project Managers' Personality on Project Success in NGOs: The Mediating Role of Transformational Leadership // Project Management Journal. 2017. Vol. 48 (2). P. 74-87.

35. Highsmith, J. Adaptive software development, Agile Software Development. Ecosystems // Addison-Wesley Professional, Indianapolis, 2002. IN, 309-321.

36. Hussein, B. A., Ahmad, S. B. S., Zidane, Y. J. T. Problems Associated with Defining Project Success // Procedia Computer Science. 2015. Vol. 64. P. 940-947.

37. Ika, L. A. Project Success as a Topic in Project Management Journals // Project Management Journal. 2009. Vol. 40 (4). P. 6-19.

38. Jugdev, K., Mьller, R. A Retrospective Look at Our Evolving for Project Success // Project Management Journal. 2005. Vol. 36 (4). P. 19-32.

39. Khan, K., Turner, J. R., Maqsood, T. Factors that influence the success of public sector projects in Pakistan // In Proceedings of IRNOP 2013 Conference. 2013. P. 1-25.

40. Lee G., Xia W. Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility // MIS Quarterly. 2010. Vol. 34(1). P. 87-114.

41. Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D., et al. Agile software development in large organizations // Computer. 2004. Vol. 37 (12). P. 26-34.

42. Martens, M. L., Carvalho, M. M. Sustainability and Success Variables in the Project Management Context: An Expert Panel // Project Management Journal. 2016. Vol. 47 (6). P. 24-43.

43. Mazur, A. K., Pisarski, A. Major project managers' internal and external stakeholder relationships: The development and validation of measurement scales // International Journal of Project Management. 2015. Vol. 33 (8). P. 1680-1691.

44. Mir, F. A., Pinnington, A. H. Exploring the value of project management: Linking Project Management Performance and Project Success // International Journal of Project Management. 2014. Vol. 2 (2). P. 202-217.

45. Misra, S.C., Kumar, V., Kumar U. Identifying some important success factors in adopting agile software development practices // Journal of Systems and Software. 2009. Vol. 82 (11). P. 69-90.

46. Moe, N.B., Dingsoyr, T., Dyba, T. A teamwork model for understanding an agile team: a case study of a Scrum project // Information and Software Technology. 2010. Vol. 52, P. 480-491.

47. Moe, T. L., Khang, D. B. Success Criteria and Factors for International Development Projects: A Life-Cycle-Based Framework // Project Management Journal. 2008. Vol. 39 (1). P. 72-84.

48. Mьller, R., Jugdev, K. Critical success factors in projects: Pinto, Slevin, and Prescott - the elucidation of project success // International Journal of Managing Projects in Business. 2012. Vol. 5 (4). P. 757-775.

49. Mьller, R., Turner, R. The Influence of Project Managers on Project Success Criteria and Project Success by Project Type // European Management Journal. 2007. Vol. 25 (4). P. 298-309.

50. Ohno, T. Toyota Production System - beyond large-scale production // Productivity Press. 1988. Vol. 1, P. 29.

51. Pankratz, O., Basten, D. Ladder to success - eliciting project managers' perceptions of IS project success criteria // International Journal of Information Systems and Project Management. 2014. Vol. 2 (2). P. 5-24.

52. Serrador P. Pinto, J.K. Does Agile work? -- A quantitative analysis of agile project success // International Journal of Project Management. 2015. Vol. 33. P. 1040-1051.

53. Serrador, P., Turner, R. The Relationship Between Project Success and Project Efficiency // Project Management Journal. 2015. Vol. 46 (1). P. 30-39.

54. Sheffield J., Lemйtayer, J. Factors associated with the software development agility of successful projects // International Journal of Project Management. 2013. 31. 459-472.

55. Shenhar, A. J., Dvir, D., Levy, O., Maltz, A. C. Project success: A multidimensional strategic concept // Long Range Planning, 2001. Vol. 34 (6). P. 699-725.

56. Sipper, D., Bulfin, R.L. Variations of the kanban system: Literature review and classification // International Journal of Production Economics. 2010. Vol. 125(1). P. 13-21.

57. Stankovic D., Nikolic, V., Djordjevic, M., Cao, D.-B. A survey study of critical success factors in agile software projects in former Yugoslavia IT companies // The Journal of Systems and Software. 2013. Vol. 86, P. 1663-1678.

58. Thomas, G. Fernбndez, W. Success in IT projects: A matter of definition? // International Journal of Project Management. 2008. Vol. 26 (7). P. 733-742.

59. Todoroviж, M. L., Petroviж, D. И., Mihiж, M. M., Obradoviж, V. L., Bushuyev, S. D. Project success analysis framework: A knowledge-based approach in project management // International Journal of Project Management. 2015. Vol. 33 (4). P. 772-783.

60. Tonelli AO, De Souza Bermejo, P.H., De Azevedo Santos, M., Zambalde, A.L., Silva de Oliveira, M., Antonialli, L.M., editors. Agile practices to accelerate the delivery of software: a quantitative study with software professionals // 46th Hawaii International Conference on System Sciences. 2013.

61. Turk, D., France, R., Rumpe, B. Limitations of Agile Software Processes // Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering. .2002.

62. Vallona, R., Josй da Silva Estбcioc, B., Prikladnickic, R., Grechenigb, T. Systematic literature review on agile practices in global software development // Information and Software Technology. 2018. Vol. 96. P. 161-180.



Приложение

Анкета «Использование гибких методик в управлении ИТ-проектами»

Раздел 1. Общая информация.

Сведения о респонденте

Укажите, пожалуйста, Ваш опыт работы в области управления проектами:

Менее 2 лет

2-5 лет

5-7 лет

7-10 лет

Более 10 лет

Укажите, пожалуйста, в какой роли Вам приходится чаще всего участвовать в проектной деятельности в Вашей компании (выберите наиболее подходящий вариант):

Представитель высшего руководства организации

Руководитель функционального подразделения

Менеджер проекта

Спонсор проекта

Администратор проекта

Заказчик проекта

Исполнитель (член команды проекта)

Другая роль (укажите какая именно)

Сведения о компании (для/в которой осуществлялся проект)

Укажите название компании (если возможно)

Компания является…

Российской

Зарубежной

Компанией со смешанным капиталом

Какова численность персонала компании?

Менее 15 человек (микро-предприятие)

15 - 100 (малое предприятие)

101 - 250 человек (среднее предприятие)

250+ человек (крупное предприятие)

Сколько лет компания существует на рынке?

Менее 2 лет

2-5 лет

5-7 лет

7-10 лет

Более 10 лет

В какой отрасли преимущественно работает компания, в которой Вы трудитесь:

Строительство

Энергетика

ИТ- и телеком

Образование

Консультирование

Финансовый сектор

Нефтегазовый сектор

Другое (укажите)__________________________________________________________

Выберите оценку, в большей степени выражающую Ваше согласие с приведенными утверждениями (1 - абсолютно не согласен, 2 - не согласен, 3 - затрудняюсь ответить, 4 - согласен, 5 - абсолютно согласен)

Компания (в т.ч. руководство) открыто к использованию гибких методологий по УП	1	2	3	4	5
Компания имеет опыт в использовании гибких методологий, в штате есть эксперты в области гибких методологий	1	2	3	4	5

Сведения о проекте

Бюджет проекта:

Малый (< 5 000 000 р.)

Средний (больше 5 000 000 р., меньше 15 000 000 р.)

Крупный (больше 15 000 000 р.)

Численность команды проекта:

Менее 50 человек

50-100 человек

100-500 человек

Более 500 человек

Локация команды:

Одна локация

Распределенная команда

Продолжительность проекта:

Менее 0,5 года

0,5 -1 год

1-2 года

2-5 лет

Более 5 лет

Раздел 2. Использование гибких методологий в управлении проектами

Отметьте «Х» элементы гибких методологий, которые были использованы на проекте:

1	SCRUM	2	KANBAN	3	XP
	Бэклог		Канбан-доска		Игра в планирование
	Пользовательские истории		Ограничение по количеству задач на одной стадии		Парное программирование
	Спринт				Разработка через тестирование
	Стэнд-ап				Быстрая обратная связь
	Оценка ПИ в очках				Непрерывная интеграция
	Scrum-роли				Рефакторинг
	Ретроспектива				Небольшие, но частые релизы
					Стандарты написания кода
					Коллективное владение кодом
					Простой дизайн
					Системная метафора
					Фиксированный рабочий день для разработчиков
					Другое:

*XP - Extreme Programming

4	SCRUMBAN	5	Другая гибкая методология
	Короткие итерации (1-2 нед.)
	Планирование по требованию
	Планирование «по корзинам»
	«Заморозка функций»
	Сортировка оставшихся задач

Отметьте «Х» пары элементов гибких методологий, использованных в проекте:

Стэнд-ап - Канбан-доска

Стэнд-ап - Спринт

Стэнд-ап - Ретроспектива

Бэклог (рассчитанный по ПИ) - Канбан-доска

Пользовательские истории - Канбан-доска

Спринт - Канбан-доска

Ретроспектива - Спринт

Ретроспектива - Канбан-доска

Скрам-роли - Канбан-доска

Парное программирование - Канбан-доска

Спринт - Непрерывная интеграция

Непрерывная интеграция - Канбан-доска

Другое_______________________________

Раздел 3. Успех проекта

Выберите оценку, в большей степени выражающую Ваше согласие с приведенными утверждениями (1 - абсолютно не согласен, 2 - не согласен, 3 - затрудняюсь ответить, 4 - согласен, 5 - абсолютно согласен).

Отметьте «Х» пункты, входящие в официальные критерии успеха проекта:

	Проект был реализован в плановый срок	1	2	3	4	5
	Проект был реализован в рамках планового бюджета	1	2	3	4	5
	Фактический объем проекта соответствовал плановому (был не меньше) планового	1	2	3	4	5
	Качество продукта проекта соответствовало заявленному (было не ниже заявленного)	1	2	3	4	5
	Заказчик удовлетворен результатом проекта	1	2	3	4	5
	Конечный пользователь удовлетворен результатом проекта	1	2	3	4	5
	Команда удовлетворена проектом (процессом реализации и результатом)	1	2	3	4	5
	Прибыльность проекта соответствовала плановой	1	2	3	4	5
	Другое:	1	2	3	4	5
		1	2	3	4	5
		1	2	3	4	5

Поставьте «Х» в пересечении практики и критерия, если, на Ваш взгляд, использование данной практики влияет на достижения критерия.



	Срок	Бюджет	Качество	Объем	Удовлетворенность заказчика	Удовлетворенность пользователя	Удовлетворенность команды	Прибыльность	Не знаю/ не влияет
SCRUM
Бэклог
Пользовательские истории
Спринт
Стэнд-ап
Оценка ПИ в очках
Scrum-роли
Ретроспектива
KANBAN
Канбан-доска
Ограничение по количеству задач на одной стадии
XP
Игра в планирование

Подобные документы

• Формирование и оценка деятельности команды проекта строительной организации

  Рассмотрение теоретических основ формирования команды проекта. Исследование особенностей управления командами проектами объектов недвижимости. Изучение организационных характеристик и анализ проектной деятельности строительной организации ЖК "Волга".
  
  курсовая работа [322,8 K], добавлен 19.05.2015
  

• Субъекты и объекты управления проектами

  Изучение объектов и субъектов в управлении проектов, а также их взаимодействия в процессе реализации проекта. Методы руководства и руководящие меры по обеспечению выполнения проекта. Жизненный цикл проекта и его фазы. Основные участники проекта.
  
  контрольная работа [24,5 K], добавлен 18.02.2017
  

• Особенности управления проектами в области разработки программного обеспечения

  Эволюция подходов к управлению программными проектами, современные тенденции и перспективы, критерии успешности. Оценка успешности проекта разработки программного обеспечения. Особенности организации проектной команды. Жизненный цикл проекта, фазы.
  
  курсовая работа [2,8 M], добавлен 10.01.2015
  

• Управление виртуальными проектами

  Виртуальные команды: понятие, типы и преимущества. Cтили лидерства и роль информационных технологий в управлении виртуальными командами. Особенности влияния трансформационного и транзакционного стилей управления на успех проекта и членов команды.
  
  дипломная работа [1,9 M], добавлен 02.12.2017
  

• Исследование влияния команды проекта на величину отклонения по срокам

  Специфика консалтинговых проектов. Разработка системно-динамической модели сроков консалтингового проекта, включающей закон Брукса. Проектирование организационной модели консалтингового проекта, включающей процессы управления сроками и командой проекта.
  
  дипломная работа [3,3 M], добавлен 10.02.2017
  

• MSF - дисциплина управления проектами

  Анализ отличительных особенностей управления проектами MSF. Интеграция и синхронизация планов проекта. Организация процедур, систем управления и мониторинга проектных изменений. Планирование ресурсов, формирование проектной команды, разрешение конфликтов.
  
  презентация [974,1 K], добавлен 25.05.2014
  

• Применимость проектной методологии в IT-стартапах

  Проведение исследования основных международных и локальных стандартов по управлению проектами в информационных технологиях. Характеристика сравнения стартапа и организаций малого бизнеса. Главные особенности внедрения гибких методологий в IT-стартапы.
  
  дипломная работа [522,1 K], добавлен 22.08.2017
  

• Теоретические основы управления проектами

  Стратегическое значение современных методов и средств управления проектами. Характеристика основных методов управления проектами. Фазы жизненного цикла проекта. Фаза разработки коммерческого предложения. Формальное и детальное планирование проекта.
  
  контрольная работа [30,3 K], добавлен 04.02.2010
  

• Основные функции управления проектами

  Сущность и требования к проектам в социальной работе. Фазы жизненного цикла проекта. Анализ создания и системы управления основными функциями проекта на примере проекта ГБОУ ЦВР "Раменки". Основные пути эффективного внедрения социального проекта.
  
  курсовая работа [51,4 K], добавлен 14.11.2016
  

• Управление проектами

  Сущность понятия "проект". Связь методологии управления проектами с другими управленческими дисциплинами. Разница между менеджером и владельцем. Источники успеха руководителя. Рычаги управления проектами. Жизненный цикл и фазы инвестиционного проекта.
  
  презентация [930,4 K], добавлен 21.11.2011
  

• Характерные черты процесса управления проектами

  Определение проекта, его черты и признаки. Характеристики, отличающие проект от других видов деятельности. Признаки классификации проектов. Процессы управления проектом, его жизненный цикл и фазы выполнения. Отличие управления проектами от менеджмента.
  
  курсовая работа [2,4 M], добавлен 05.11.2011
  

• Управление циклом проекта

  Качественные характеристики жизненного цикла проекта, его фазы и стадии, место в управлении проектами. Модели проектного цикла, их виды, отличительные особенности. Исследование проектного цикла на примере создание воздуховода для болида формулы 1.
  
  курсовая работа [2,3 M], добавлен 08.12.2010
  

• Формирование и развитие команды проекта

  Исследование сущности проектного менеджмента и командообразования проекта. Изучение основных принципов и организационных аспектов формирования эффективной команды. Выявление типичных ошибок формирования команды проекта на предприятии ООО "Нефтегазмонтаж".
  
  аттестационная работа [1,7 M], добавлен 23.01.2016
  

• Управление созданием офиса проекта

  Классификация базовых понятий управления проектами. Отличие проекта от производственной системы. Жизненный цикл и фазы проекта. Процессы управления проектом, исполнения и контроля, анализа. Примерная команда проекта, его внешнее и внутреннее окружение.
  
  курсовая работа [266,4 K], добавлен 17.11.2013
  

• Формирование и развитие команды инвестиционного проекта

  Характеристика принципов и стадий развития команды проекта - совокупности работников, которые осуществляют функции управления проектом и персоналом проекта. Стадии жизненного цикла команды. Планирование работы, контроль и координация деятельности команды.
  
  реферат [171,1 K], добавлен 08.09.2010
  

• Основные элементы и участники проектов

  Базовые понятия управления проектами и принципиальная модель, раскрывающая их взаимосвязь. Цель, стратегия, результат и управляемые параметры проекта, его окружение. Организационные структуры управления проектами. Основные фазы жизненного цикла проекта.
  
  лекция [1,1 M], добавлен 31.10.2013
  

• Управление командой проекта

  Планирование управления человеческими ресурсами. Набор команды проекта. Развитие команды проекта. Совершенствование компетенций, взаимодействие членов команды и общих условий работы команды. Использование коучинга в работе современного менеджера.
  
  контрольная работа [150,1 K], добавлен 06.10.2016
  

• Инженерный менеджмент и информационные технологии

  Определение понятия "проект". Характеристики проекта как объекта управления. Функции управления проектами. Список компетенций менеджера программного проекта. Выработка концепции реализации проекта, ее апробация и экспертиза. Жизненный цикл проекта.
  
  презентация [104,7 K], добавлен 14.08.2013
  

• Основы управления проектами

  Управление проектами как средство эффективного развития объектов управления. Обязанности владельца и менеджера проекта. Признаки и вероятные причины его плохого исполнения. Возможные пути совершенствования. Эффект влияния проекта на организацию.
  
  контрольная работа [867,7 K], добавлен 20.06.2009
  

• Характеристика процедуры формирования команды в инновационном проекте

  Теоретические положения формирования команды инновационного проекта. Основные психологические характеристики управления командой проекта. Пример практического формирования команды на примере ООО "Научно-производственное объединение "Байкал-Биосинтез".
  
  курсовая работа [73,2 K], добавлен 20.04.2015
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам