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

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

Между переменными «Удовлетворённость заказчиков» и «Контроль», а также «Удовлетворённость заказчиков» и «Время на принятие решений»есть статистически значимая корреляция, однако она не слишком сильная, поэтому переменные можно включить в модель.

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

Таблица 7. Основные параметры регрессии

Сводка для моделиb
Модель	R	R-квадрат	Скорректированный R-квадрат	Стандартная ошибка оценки	Дурбин-Уотсон
1	0,819a	0,670	0,594	0,7165	,923
a. Предикторы: (константа), Контроль, Время на принятие решений, Удовлетворённость заказчиков
b. Зависимая переменная: Проект был успешно выполнен

Так как выборка исследования не большая, более правильным будет опираться на скорректированный R²= 0,594. Это довольно высокий показатель. Модель статистически значима, о чём говорит анализ ANOVA, значит можно сделать вывод, что модель можно перенести на генеральную совокупность. Таким образом, практически 60% дисперсии генеральной совокупности объясняется представленной моделью.

Коэффициенты модели и их значимость представлены ниже

Таблица 8. Основные коэффициенты регрессионной модели.

Коэффициентыa
Модель	Нестандартизованные коэффициенты	Стандартизованные коэффициенты	т	Знач.
	B	Стандартная Ошибка	Бета
1	(Константа)	-,183	,768		-,239	,815
	Удовлетворённость заказчиков	,554	,193	,592	2,874	,013
	Время на принятие решений	,214	,166	,228	1,290	,220
	Контроль	,156	,173	,170	,901	,384
a. Зависимая переменная: Проект был успешно выполнен

Касательно коэффициентов стоит отметить несколько моментов:

Константа модели не значима, другими словами нет статистически обоснованных причин заявлять, что она отлична от 0. В модель, таким образом, её можно не включать. Переменные «Время на принятие решений» и «Контроль» также не обнаружили статистической значимости. Это говорит о том, что нет оснований полагать, что их уникальный вклад для генеральной совокупности не равен 0.

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

Ещё одной проблемой модели является тот факт, что остатки не соответствуют кривой нормального распределения. (Смотри приложение 2) Это обусловлено недостаточной выборкой.

Построим уравнение регрессии:

Y = -0.183 + 0.554*(Ind1) + 0.214*(Ind3) + 0.156*(Ind8)

Таким образом, при увеличении значения переменной «Удовлетворённость заказчиков» на 1, переменная «Успешность проекта» увеличивается на 0,554, и так далее.

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

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

Таблица 9. Дополнительные регрессионные модели

Модель	Уравнение регрессии	Скорректированный R2	Значимость регрессии (ANOVA)
Ind 1	Y = 0.429+0.732*(Ind1)	0.585	0.000
Ind 3	Y = 1.714 + 0.482*(Ind3)	0.216	0.035
Ind 8	Y = 1.788 + 0.485*(Ind8)	0.233	0.029

Где Ind 1 - Ориентация на удовлетворённость заказчиков , Ind 3 - Время на принятие решений , Ind 8 - Контроль

Для переменной «Удовлетворённость заказчиков». Уравнение регрессии: . Скорректированный R²для этой модели равен …, что незначительно меньше показателя для модели с 3 переменными, таким образом можно сделать вывод, что добавление 2 других переменных практически не вносит улучшения в модель.

При этом для 2 других отдельно регрессия тоже значима, а в совместной модели нет. Это говорит о мультиколлинеарности.

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

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

2.5 Интерпретация результатов

В результате анализа данных, полученных в ходе опроса менеджеров проектов в IT, были обнаружены статистически значимые для генеральной совокупности связи между независимыми переменными: «Удовлетворённость заказчиков», «Время на принятие решений», «Контроль» и успешностью проекта. Остальные 12 факторов не обнаружили подобной зависимости, однако нельзя достоверно сказать и об её отсутствии, из-за ограничений выборки.

Ориентация на удовлетворённость заказчиков ПОМЕНЯТЬ ВЕЗДЕ

Данный показатель обнаружил наиболее сильное влияние на успешность проекта. Такой результат полностью согласуется с выводами других исследований (Misra, Kumar, & Kumar, 2009). В важности данного фактора для agile методологий нет сомнений, он является одним из 12 принципов, обозначенных в (“Manifesto for Agile Software Development,” n.d.).

Время на принятие решений

Сильная связь этой переменной и успешности проекта также не вызывает сомнений и соотносится с другими исследователями (Misra, Kumar, & Kumar, 2009). Быстрота принятия решений - одна ключевых идей гибких методологий. Она является логичным следствием упрощения документации, преобладания личной коммуникации и других особенностей, которые и делают эти методологии гибкими. Поэтому неудивительна сильная связь этого параметра с успехом.

Контроль

Качественный контроль является ещё одной из основ agile. Нельзя переоценить важность постоянного улучшения для гибкого подхода. Оценка после и во время осуществляется в основном не для того, чтобы наказать кого-либо из команды, а для работы над ошибками. Сама идея работы итерациями предполагает последовательное улучшение. Точно также и команда развивается от проекта к проекту. В такой ситуации учёт только количественных показателей не подходит, так как он не даёт полного представления о совершённых ошибках. К такому же выводу пришли и другие исследователи: (Boehm & Turner, 2003), (Misra, Kumar, & Kumar, 2009).

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

Выводы по главе

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

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

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

· Ориентация на потребителя (заказчика)

· Качественный контроль деятельности команды

· Быстрое принятие решений

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

3.1 Советы по переходу на agile методологию

Ориентация на удовлетворённость потребителя - один из ключевых принципов Agile. Успешное внедрение методологии - единственный вариант привить команде данный принцип.

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

При проведении в жизнь таких серьёзных и комплексных изменений полезным инструментом будет цикл Шухарта (Деминга) PDCA. Он заключается в 4 фазах:

· Планирование

· Исполнение

· Проверка

· Корректировка

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

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

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

· Shu - «Соблюдать». Первая ступень, которая предполагает строгое следование методологии, работе «по книжке»

· Ha - «Прорываться». Вторая ступень, предполагающая отступление от правил и традиций, их нарушение. Предполагает понимание методологии и её адаптацию для конкретной ситуации.

· Ri - «Отделяться». Третья и наивысшая ступень, предполагающая отделение, отступление от принципов и практик, создание новых, собственных.

Организация должна пройти все этапы, постепенно совершенствуясь и познавая agile. Итогом является выход за рамки конкретных методологий Scrum, Kanban и других, построение собственной, уникальной методологии, системы ценностей и практик.

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

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

Одним из таких инструментов является нулевая итерация (iteration zero). Данный подход заключается в использовании первой итерации не для разработки, а для предварительной подготовки. При переходе с традиционной методологии на agile подход данная итерация может быть использована для перевода привычного плана в backlog проекта, который представляет собой список необходимых технических заданий и свойств проекта на данный момент. По результатам нулевой итерации не производится законченного продукта, а создаются необходимые и достаточные условия для старта реализации. Не стоит воспринимать этот метод как полноценное проработку и планирование как в традиционной методологии. В данном случае все приготовления сводятся к минимально необходимым действиям, так как всё поменяется по ходу реализации проекта. Со временем команда может постепенно сокращать время нулевой итерации до тех пор, пока не сможет отказаться от неё полностью.

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

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

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

3.2 Рекомендации по проведению качественной ретроспективы

Результаты исследования подтвердили связь применения качественных методов контроля и успешности agile проекта.

Как правило, в agile методологиях контроль и оценка деятельности команды осуществляется во время ретроспективы. Первоначально ретроспектива осуществлялась после каждой итерации. В это время команда собиралась, чтобы разобрать итоги итерации, выявить проблемы и определить методы их решения. Однако на практике часто оказывается, что проведение ретроспективы в конце затруднено: у команды недостаточно времени, многие проблемы решены уже в ходе итерации. Поэтому иногда более подходящим является подход, который используют многие agile консультанты и практикующие менеджеры - непрерывной (continuous) ретроспективы. Основная идея такого подхода к ретроспективе - перенести процесс на ежедневные «stand-up» собрания: визуализировать каким-либо способом проблемы и процесс реализации и решать их на месте. Существует множество разных методов визуализации, наиболее примечательные - Value stream mapping, Доска идей.

Value stream mapping (VSM) - метод, который пришёл из lean management. Представляет собой некоторую схему событий и этапов, которые проходит продукт, до того момента как попадёт к потребителю. Данный метод позволяет визуализировать процесс создания бизнес-ценности продукта. Как правило, данный подход используют в производстве, однако он очень хорош и для разработки программного обеспечения. Создание бизнес-ценности - краеугольный камень agile, поэтому визуализация данного процесса даёт команде хорошее представление о том, что происходит в проекте. Достаточно просто «прикрепить» появившуюся проблему к конкретному месту возникновения на VSM, чтобы можно было получить представление о том, какое место занимает процесс, на котором возникла проблем, и какие последствия это несёт. Имея такую информацию можно в режиме реального времени решать проблемы на ежедневных собраниях.

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

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

Для проведения ретроспективы хорошими инструментами являются разработанные Элияху Голдраттом для Теории ограничений системы (ТОС) дерево текущей реальности, диаграмма разрешения конфликта, дерево будущей реальности.

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

.

Рисунок 5. Дерево текущей реальности

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

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

Рисунок 6. Диаграмма разрешения конфликтов

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

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

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



3.3 Саморегулируемая команда как способ ускорить процесс принятия решений

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

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

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

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

3.4 Ситуационный подход в практике управления проектами

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

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

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

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

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

Рекомендации для будущих исследований

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

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

Выводы по главе

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

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

· Организация перехода на гибкие методологии:

o Нулевая итерация

o Вывести команду на разговор в ретроспективе

· Применение эффективных методов ретроспективы:

o Непрерывная ретроспектива

§ Value stream mapping

§ Доска идей

o Методы из ТОС

§ Дерево текущей реальности

§ Диаграмма решения конфликтов

§ Дерево будущей реальности

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



Заключение

Результатом данной работы является шаг в сторону понимания факторов, необходимых для успешного управления проектами в IT. Было проведено исследование, целью которого было определить ключевые факторы успеха проекта. Выводом можно считать обнаружение статистически значимых предикторов успешности проекта: «Ориентации на удовлетворённость потребителя», «Быстрое принятие решений», «Качественный контроль». Для исследования был составлен опросник по итогам анализа литературы и неструктурированных интервью с менеджерами. Опрос проводился онлайн на тематических ресурсах и социальных сетях. Выборка исследования составила 17 человек. Данная выборка является небольшой, но достаточной, чтобы сделать некоторые выводы о КФУ проекта. Анализ результатов осуществлён с помощью SPSS: посчитаны коэффициенты корреляции и построены регрессионные модели для объяснения связи переменных.

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

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

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

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



Список использованной литературы

1. Детмер У. Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию. М.: «Альпина Паблишер», 2010. -- 448 с.

2. Эшби У.Р. Введение в кибернетику. Москва: , 2015. Вып. Ленанд. 432 с.

3. A Guide to The Project Management Body of Knowledge. - PMI, 2008.

4. Cockburn A. Agile Software Development. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002.

5. Cohen D., Lindvall M., Costa P. An Introduction to Agile Methods. , 2004. 1 с.

6. Coplien J.O., Harrison N.B. Organisational patterns of agile software development. Upper Saddle River, NJ, USA: Pearson Prentice Hall, 2004. 432 с.

7. Wysocki R.K. Effective Project Management?: Traditional, Agile, Extreme. Indianapolis, IN: Wiley, 2012.

8. Кожевникова Е. Этнокультурные факторы проектной деятельности в России: проблемы и инструменты // Управление проектами и программами (часть 2). 2013. Т. 3. № 35. С. 218-226.

9. Abbas N., Gravell A.M., Wills G.B. Historical roots of agile methods: Where did «Agile thinking» come from? : Springer Verlag, 2008. 94-103 с.

10. Baird A., Riggins F.J. Planning and sprinting: Use of a hybrid project use of a hybrid project use of a hybrid project management methodology within a CIS capstone course // J. Inf. Syst. Educ. 2012. Т. 23. № 3. С. 243-258.

11. Boehm B., Turner R. Using risk to balance agile and plan-driven methods // Computer. 2003. Т. 36. № 6. С. 57-66.

12. Daniel D.R. Management information crisis // Harvard Bus Rev. 1961. № September-October. С. 111-121.

13. Dybе T., Dingsшyr T. Empirical studies of agile software development: A systematic review // Information and Software Technology. 2008. Т. 50. № 9-10. С. 833-859.

14. Faulkner W., Badurdeen F. Sustainable Value Stream Mapping (Sus-VSM): Methodology to visualize and assess manufacturing sustainability performance // Journal of Cleaner Production. 2014. Т. 85. С. 8-18.

15. Fernandes G., Ward S., Araъjo M. Improving and embedding project management practice in organisations - A qualitative study // International Journal of Project Management. 2015. Т. 33. № 5. С. 1052-1067.

16. Fernandez D.J., Fernandez J.D. Agile project management - Agilism versus traditional approaches // J. Comput. Inf. Syst. 2008. Т. 49. № 2. С. 10-17.

17. Fortune J., White D. Framing of project critical success factors by a systems model // International Journal of Project Management. 2006. Т. 24. № 1. С. 53-65.

18. Hofstede G. Cultural dimensions for project management // International Journal of Project Management. 1983. Т. 1. № 1. С. 41-48.

19. Howell D., Windahl C., Seidel R. A project contingency framework based on uncertainty and its consequences // International Journal of Project Management. 2010. Т. 28. С. 256-264.

20. Keil M., Lee H.K., Deng T. Understanding the most critical skills for managing IT projects: A Delphi study of IT project managers // Information and Management. 2013. Т. 50. № 7. С. 398-414.

21. Larsen M.A., Myers M.D. When success turns into failure: A package-driven business process re-engineering project in the financial services industry // Journal of Strategic Information Systems. 1999. Т. 8. № 4. С. 395-417.

22. Livermore J.A. Factors that significantly impact the implementation of an agile software development methodology // Journal of Software. 2008. Т. 3. № 4. С. 31-36.

23. Maylor H. и др. From projectification to programmification // International Journal of Project Management. 2006. Т. 24. № 8. С. 663-674.

24. Misra S.C., Kumar V., Kumar U. Identifying some important success factors in adopting agile software development practices // J Syst Software. 2009. Т. 82. № 11. С. 1869-1890.

25. Nandhakumar J. Design for success?: Critical success factors in executive information systems development // European Journal of Information Systems. 1996. Т. 5. № 1. С. 62-72.

26. Owen R., Koaskela L., Henrich G. Is agile project maangement applicable to construction? Santiago Chile: , 2006.

27. Rockart J.F. Chief executives define their own data needs. // Harv Bus Rev. 1979. Т. 57. № 2. С. 81-93.

28. Shenhar A.J. One size does not fit all projects: Exploring classical contingency domains // Manage. Sci. 2001. Т. 47. № 3. С. 394-414.

29. CHAOS Summary 2010, The Standish Group International [Электронный ресурс]. URL: http://www.standishgroup.com/ (дата обращения: 24.02.2015)

30. Manifesto for Agile Software Development [Электронный ресурс]. URL: http://www.agilemanifesto.org/ (дата обращения: 10.02.2015).

31. The World Values Survey [Электронный ресурс]. URL:www.worldvaluessurvey.org



Список иллюстраций

Рисунок 1. Окружение проекта

Рисунок 2. Проектный треугольник

Рисунок 3. График Неопределённость - последствия

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

Рисунок 5. Дерево текущей реальности

Рисунок 6. Диаграмма разрешения конфликтов

Таблица 1Сравнение россиян с жителями США.

Таблица 2. Исследовательские гипотезы

Таблица 3. Описательная статистика - количество работников в организации

Таблица 4. Описательная статистика- опыт работы с использованием гибких методологий

Таблица 5. Анализ валидности переменных

Таблица 6. Корреляция переменных

Таблица 7. Основные параметры регрессии

Таблица 8. Основные коэффициенты регрессионной модели.

Таблица 9. Дополнительные регрессионные модели



Приложение 1. Вопросник

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

Моя компания работает в области:

1. Связанной с компьютерами (Software, Hardware и прочие)

2. Телекоммуникации

3. Финансы

4. Недвижимость

5. Образование

6. Медиа и развлечения

7. Туризм

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

9. Консалтинг

10. Юридические услуги

11. Продажи

12. Медицина

13. Электрооборудование

14. Другое

Количество работников

1. 10-20

2. 21-40

3. 41-100

4. 101-500

5. 501-1000

6. Более 1000

Количество человек в моей команде

1. Менее 5

2. 5-10

3. 11-20

4. 21-40

5. Более 40

Моя роль в команде

1. Проджект менеджер

2. Разработчик

3. Тестировщик

4. Другая

Опыт работы в сфере ИТ

1. Менее 1 года

2. 1-3 года

3. 3-5 лет

4. Более 5 лет

Опыт работы с Agile

1. Нет опыта

2. Менее года

3. 1-3 года

4. 3-5

5. Более 5 лет

Выберите любой проект из тех, что были выполнены с использованием принципов Agile методологий (Scrum, XP, Kanban, Lean)

Оцените, насколько высказывание соотносится с реальным проектом

От 1 до 5, где

1 - Совсем не соотносится

5 - Полностью совпадает

Удовлетворённость потребителя

· Мы высоко ценим удовлетворённость наших потребителей

Взаимодействие с потребителем

· Потребители близко взаимодействуют с командой проекта

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

Принятие решений

· У нас получается принимать важные решения в ходе проекта быстро

Распределённость команды

· Члены команды работают в одном месте

Размер команды

· Мы работаем в маленьких командах до 20 чел

Корп культура

· Наша организация борется за быструю коммуникацию

· В нашей организации царит атмосфера доверия

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

· Наша организация ориентирована на потребителей

· Наша организация поощряет быстрое получение обратной связи от клиентов

· Наша организация поощряет изменения в требованиях по ходу проекта

· Решение о применении Agile практик принималось совместно руководством и командой проекта

Планирование

· Планирование осуществляется внутренними планами без серьёзной документации

Контроль

· Применяется качественный метод оценки (не количественный)

Техническая компетентность

· Наша команда состоит из технически подкованных и опытных людей

Личные характеристики

· Большинство членов команды:

o Обладают сильными коммуникационными навыками

o Честные

o Умеют работать в коллективе

o Ответственные

o Готовы учиться

Коммуникация и переговоры

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

· Коммуникация, в основном, личная

· Между людьди, находящимися близко

· В одном часовом поясе

Обучение

· Члены команды всегда готовы учиться новому, в том числе друг от друга.

Проект

· Проект был успешен

Каждый член команды хорошо осознаёт свою роль и функции внутри проекта

У команды и руководства имелось чёткое видение, какого результата проект должен достичь

Мы используем специальное ПО для удобства управления и коммуникации внутри команды. (Basecamp, Microsoft Project и другие)

Команда проекта и руководство компании регулярно обмениваются информацией о ходе реализации проекта



Приложение 2. Диаграммы остатков регрессии



Приложение 3. Результаты опроса

1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22
5	5	5	5	1	5	5	5	3	4	3	5	1	1	4	3	1	2	2	4	1	1
4	4	2	3	2	4	3	3	1	2	2	1	2	3	1	3	3	4	3	4	4	1
3	4	5	4	3	4	4	2	3	5	4	2	3	4	2	5	2	5	3	4	3	5
4	5	5	3	2	5	4	4	5	5	5	2	4	3	4	4	4	3	4	4	4	1
5	4	5	5	1	5	3	4	4	1	4	1	1	3	4	4	3	3	4	4	4	1
5	5	5	5	5	5	5	5	5	4	3	4	3	5	5	5	5	5	5	5	3	5
4	5	3	3	1	5	5	4	4	5	5	4	5	2	5	3	3	3	4	3	4	2
1	1	4	1	1	5	5	3	3	1	3	1	1	3	2	5	4	3	3	3	3	1
4	5	3	3	1	5	5	4	4	5	5	4	5	2	5	3	3	3	4	3	4	2
4	5	4	5	2	4	3	3	5	3	3	3	4	2	4	5	3	4	4	3	4	4
4	5	4	4	3	5	5	5	5	5	5	5	5	4	4	4	3	5	4	4	4	4
2	3	3	3	3	5	3	3	3	4	3	3	3	3	3	4	4	5	4	4	3	5
3	5	3	5	3	4	5	4	4	3	4	2	4	2	2	5	3	5	4	5	4	5
2	2	5	5	1	1	3	4	4	2	4	3	1	3	3	4	3	2	2	3	3	1
4	5	5	4	4	5	5	4	5	5	5	4	4	3	5	5	3	5	5	4	4	1
3	4	3	2	3	5	4	5	4	4	4	2	3	3	4	4	2	4	4	3	4	5
3	5	3	4	5	5	5	4	5	4	5	4	4	4	4	5	3	4	4	3	4	5



Приложение 4. Расшифровка для результатов опроса

Формулировка вопроса	Номер
Проект был успешно выполнен	1
Мы высоко ценим удовлетворённость наших потребителей	2
Заказчики постоянно взаимодействуют с командой и активно участвуют в ходе реализации проекта	3
У нас получается принимать важные решения в ходе проекта быстро	4
Все члены команды работают в одном месте (офисе и тп.)	5
Мы работаем в маленьких командах до 20 чел	6
Наша организация старается, чтобы коммуникация внутри команды была быстрой	7
В нашей организации царит атмосфера доверия	8
Менеджеры в нашей организации поддерживают решения разработчиков (поощряют самостоятельность)	9
Потребители - главная ценность нашей организации	10
Наша организация поощряет быстрое получение обратной связи от клиентов	11
Наша организация поощряет изменения в требованиях по ходу проекта	12
Решение о применении Agile практик принималось совместно руководством и командой проекта	13
При работе мы опираемся на внутренние, неформальные планы (а не на жёсткие задокументированные)	14
Применяется качественный метод оценки результатов проекта (не количественный)	15
Наша команда состоит из технически подкованных и опытных людей	16
Большинство членов команды обладают навыками хорошей коммуникации	17
Большинство членов команды честные	18
Большинство членов команды умеют работать в коллективе	19
Большинство членов команды готовы учиться	20
Большинство членов команды ответственные	21
Команда и ВСЕ люди, с которыми приходится взаимодействовать, находятся в одном часовом поясе	22
Команда проекта и руководство компании регулярно обмениваются информацией о ходе реализации проекта	23
Мы используем специальное ПО для удобства управления и коммуникации внутри команды. (Basecamp, Microsoft Project и другие)	24
У команды и руководства имелось чёткое видение, какого результата проект должен достичь	25
Каждый член команды хорошо осознаёт свою роль и функции внутри проекта	26

Размещено на Allbest.ru

...