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

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

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Выпускная квалификационная работа - бакалаврская работа

Особенности управления проектами в крупных российских IT компаниях

по направлению подготовки «Управление проектами»

образовательная программа 38.03.02 «Менеджмент»

Колосков Илья Владимирович

Научный руководитель

к.э.н., доцент Царьков Игорь Николаевич

Москва, 2018



Оглавление

Введение

Глава 1. Особенности управления IT-проектами

1.1 Гибкие методологии как основной тренд в управлении IT проектами

1.2 Разновидности жизненного цикла IT проекта

1.3 Описание гибких методологий. Сравнение с водопадной моделью

1.4 Успех IT-проектов

1.5 Качество командной работы как фактор успеха IT-проектов

1.6 Описание методологии Scrum

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

Глава 2. Эмпирическое исследование

2.1 Кейс компании «Яндекс»

2.2 Методология исследования

2.2.1 Общее описание методологии

2.2.2 Составление опроса и формулирование гипотез

2.3 Анализ результатов

2.3.1 Описательная статистика

2.3.2 Тест надежности переменных

2.3.3 Анализ корреляций

2.3.4 Построение модели множественной линейной регрессии

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

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

Глава 3. Рекомендации по улучшению командной работы

3.1 Повышение эффективности коммуникаций

3.2 Стимулирование взаимной поддержки и сплоченности

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

Заключение

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

Приложение

Введение

управление тренд командный сплоченность

В настоящий момент сфера разработки программного обеспечения (ПО) является одной из наиболее стремительно развивающихся, в ней наблюдается постоянное внедрение технологических и управленческих инноваций. Потребность в них вызвана высоким темпом технического прогресса, успевать за которым возможно лишь производя продукты максимально быстро и эффективно. В ответ на данный вызов был разработан новый класс методологий управления проектами под названием agile, что русскоязычной литературе переводится как «гибкие». Данные методологии объединены общей философией и принципами, направленными на организацию наиболее эффективного процесса разработки продуктов. Принципы agile сильно контрастируют с классической водопадной моделью. Наблюдается смещение акцента с документации и регламентов на людей и их взаимодействие, а строгое следованию плану перестает быть важным, уступая свою роль способности быстро реагировать на изменения, вносящиеся по ходу проекта. Данные методологии широко распространились и за пределами сферы IT. Согласно исследованию, проведенному в 2017 году Project Management Institute [37], 71% опрошенных организаций использует гибкие подходы (иногда, часто или всегда). Говоря же о сфере информационных технологий, применение agile является повсеместным.

Со времен своего возникновения гибкие методологии были тщательно изучены не только практиками, но и теоретиками: на данный момент количество научных работ, посвященных этой теме, измеряется тысячами. Тем не менее, не все аспекты гибкого управления проектами по разработке ПО получили достаточную освещенность. Как уже было сказано выше, одной из их ключевых особенностей agile методологий является возросшая важность межличностного взаимодействия. Однако несмотря на то, что гибкие методы разработки ПО акцентируются на коллективной работе больше, чем традиционные методы разработки [19], влияние качества совместной работы на успех проекта в гибких командах изучено недостаточно [24].

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

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

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

· Провести мини-интервью с сотрудниками «Яндекса» для дополнения имеющихся знаний и получения представления о функционировании гибких методологий непосредственно в данной компании;

· Создать опрос, основанный на полученных теоретических знаниях и результатах интервью;

· Провести опрос на выборке из сотрудников «Яндекса»;

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

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

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

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



Глава 1. Особенности управления IT-проектами

1.1 Гибкие методологии как основной тренд в управлении IT проектами

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

Безусловно, гибкость масштабного IT-проекта, задействующего огромное количество ресурсов, будет существенно ниже, чем у проекта по созданию мобильного приложения, реализуемого маленькой командой. Однако прогресс в данной сфере идет настолько стремительно, что проекты по разработке сложных многофункциональных систем длительностью в несколько лет устаревают в процессе реализации, если в них постоянно не вносить изменения[1]. Таким образом, в сфере информационных технологий гибкость необходима при управлении проектами различного масштаба.

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

Использование гибких методологий в IT-сфере на данный момент является повсеместным. Опрос 601 специалиста в этой области, проведенный в 2017 году, показывает, что гибкие методологии в той или иной степени используют 91% респондентов, 24% из которых делают это в гибридном виде с традиционными. [36]

Рисунок 1. Распространенность agile в IT-сфере

Эффективность этого подхода также подтверждается на практике. Вышедший в 2015 году CHAOS Report, опубликованный the Standish Group демонстрирует этот факт. В докладе было изучено более 10000 IT-проектов с 2011 по 2015 год. Как мы видим в таблице, представленной ниже, вне зависимости от размера проекта, те из них, которые были реализованы с использованием agile имеют значительно больший процент успешных и меньший процент провальных. [32]



Рисунок 2. Успешность проектов в зависимости от методологии.

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

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



1.2 Разновидности жизненного цикла IT проекта

Первой существующей методологией в сфере разработки ПО была так называемая «Code-and-Fix» [7], в некоторой степени напоминающая agile, однако имеющая ряд существенных недостатков по сравнению с ним. Алгоритм работы в данной модели заключался в следующем: получить понимание потребностей заказчика; начать программировать; получить некие результаты, продемонстрировать их заказчику; получить обратную связь и внести изменения в код. Данная последовательность действий повторяется до тех пор, пока заказчик не будет удовлетворен качеством конечно продукта. Это достаточно сильно напоминает итерации, существующие в agile, но отличия заключаются в следующем:

· В Сode-and-Fix отсутствовали практики постоянного тестирования и интеграции кода, что приводило к постоянно растущему числу ошибок;

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

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

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

Первой из пришедших на смену стала модель водопада (waterfall model). Ее подробное описание появилось в статье Ройса в 1970 году [21]. Смысл данного подхода заключается в том, что процесс делится на упорядоченные фазы, выполняемые строго последовательно. Название «водопад» появилось из-за внешнего вида диаграммы, изображающей модель:

Рисунок 3. Водопадная модель жизненного цикла.

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

· понятная и простая структура процессов, удобная для команд с небольшим опытом;

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

· удобство планирования ресурсов, рисков и времени;

· стабильность задач продукта от начала до завершения;

· высокая степень масштабируемости проекта.

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

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

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

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

Рисунок 4. Спиральная модель жизненного цикла

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

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

Вышеназванные модели легли в основу нового, гибкого класса методологий.

1.3 Описание гибких методологий. Сравнение с водопадной моделью

Делая вывод из прошлой главы, можно сказать, что в IT-сфере на протяжении всей ее истории люди стремились сделать разработку продуктов наиболее эффективной. В результате в феврале 2001 года в штате Юта, США, была проведена встреча IT-специалистов и консультантов для обсуждения «легковесных» методов разработки, объединяющих основные принципы итеративной и спиральной модели. На этой встрече было принято решение назвать такие методологии общим термином «agile» (гибкий). В то же время был создан фундаментальный документ: «Манифест гибких методологий развития». В нем были зафиксированы ключевые принципы и ценности, которые формируют основу для гибкого управления IT-проектом. Фактически, они стали оппозицией существующим стандартам, поэтому их можно визуализировать следующим образом:



Рисунок 5.. Визуализация ценностей манифеста гибкой разработки [2]

Так, новые методологии полностью переставили акценты с документации на коммуникацию, принеся жесткую дисциплину в жертву адаптивности.

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

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

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

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

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

Ш Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

Ш Простота -- искусство минимизации лишней работы -- крайне необходима.

Ш Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд». [34]

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

1.4 Успех IT-проектов

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

Как и в случае с обычными проектами, здесь работает проектный треугольник. Даже взяв во внимание тот факт, что сфера IT довольна непредсказуема и превышение сроков и бюджета здесь является распространенной практикой, эти показатели все равно должны учитываться при оценке успешности реализации проектов. [4] Однако ключевым критерием в софтверных проектах является качество конечного продукта, ради которого могут приноситься в жертву время и дополнительные ресурсы. Так, ряд исследователей [20] концептуализировали успех в трех измерениях.

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

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

· Удовлетворенность клиентов, поскольку это один из основополагающих принципов развития гибких информационных систем, как это было предложено в Agile Manifesto.

Несколько иной подход, охватывающий дополнительные измерения, были предложен исследователями Мартином Хогелем и Хансом Георг Геменденом [10].

Помимо вышеназванного, они также выделили показатель «Team member success». Данная модель является более полной, так как раскрывает не только результаты, связанные непосредственно с выполнением задачи, но и не менее важные результаты, связанные с членами команды.

Ниже приведено описание всех составляющих.

Таблица 1. Параметры успеха проекта

Конструкт	Подконструкт	Описание
Успех проекта	Качество (effectiveness)	Степень, в которой команда оправдывает ожидания относительно качества продукта (стабильность, функциональность и др.)
	Сроки и бюджет (efficiency)	Степень, в которой команда оправдывает ожидания относительно соблюдения сроков и бюджета.
Успех команды	Удовлетворенность работой	Степень, в которой члены команды мотивированы участвовать в будущих командных проектах
	Обучение	Степень, в которой члены команды улучшили свои навыки и приобрели новые знания

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



1.5 Качество командной работы как фактор успеха IT-проектов

Идея о важности командной работы для успеха IT-проектов разделяется многими исследователями. В нескольких исследованиях изучалось влияние качества совместной работы на успех проекта в разработке программного обеспечения [10;13;25]. В данных работах была найдена значимая взаимосвязь между показателями, описывающими качество командной работы и рассмотренными ранее показателями успеха IT-проектов. Более того, еще ряд исследований [16] выявил высокую значимость командной работы для проектов, осуществляемых по гибким методологиям.

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

Рисунок 6. Модель эффективного использования гибких методологий.



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

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

Коммуникации.

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

Координация.

Мэлоун и Кроустон [15] описывают координацию как «управление зависимостями между действиями». Такие зависимости включают общие ресурсы, назначения задач и отношения между подзадачами и задачами. Координация означает, что команды должны разработать и согласовать общую целевую структуру задач, которая имеет достаточно четкие подцели для каждого члена команды. В гибких командах задачи выбираются или делегируются при планировании новой итерации. В ходе итерации некоторые из «пользовательских историй» (требований) приоритезируются. Одна «пользовательская история» часто делится на несколько задач. Рабочая нагрузка задачи оценивается, и каждая из них выбирается одним или несколькими членами команды.

Вклад участников команды.

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

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

Взаимная поддержка.

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

Усилия.

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

Сплоченность.

Общим определением сплоченности команды является «динамический процесс, который отражается в тенденции группы держаться вместе и оставаться единой в достижении своих целей» [17]. Муллен и Коппер [18] различают три аспекта сплоченности команды: приверженность задачам команды, межличностное притяжение среди членов команды и групповая гордость/командный дух. В опросе 31 команды разработчиков, сплоченность команды была признана доминирующим фактором, оказывающим наибольшее влияние на работу команды [12]. Согласно Agile Manifesto, люди и их взаимодействия ставятся превыше процессов и инструментов, таким образом ценность сплоченности команды повышается.

В ходе исследования, направленного на выявление связи вышеперечисленных конструктов с параметрами успешности проектов в agile, наиболее значимую взаимосвязь с успехом проекта продемонстрировали факторы «Коммуникация», «Взаимная поддержка» и «Сплоченность» [14]. Именно эти факторы и станут основой для исследовательских гипотез, которые будут сформулированы перед началом эмпирического исследования.

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

1.6 Описание методологии Scrum

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

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

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

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

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

Инкримент продукта - новая функциональность продукта, созданная по результатам спринта.

Основные роли в скрам:

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

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

Команда Разработки -- кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта. [5]

О команде, как об главном участнике проекта, следует сказать еще несколько важных вещей. Одной из важнейших особенностей гибких команд является высокая степень самостоятельности и, как следствие, ответственности: члены команды сами оценивают элементы бэклога и решают, сколько смогут выполнить за итерацию, самостоятельно отслеживают свой прогресс и отвечают за результат проделанной работы непосредственно перед Владельцем продукта. Именно поэтому внедрение agile должно происходить только в слаженных коллективах, ведь как гласит один из принципов Agile Manifesto: «лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды». Размещение команды в одном месте также является немаловажным фактором для гибкой работы, ведь чем эффективнее происходит взаимодействие, тем более быстро и качественно члены команды реагируют на изменения по ходу работы.

Говоря о ключевых идеях Scrum, в книге под названием «A Guide to the Scrum Body of Knowledge» выделяются 6 основополагающих принципов данной методологии:

Ш Сотрудничество

Ш Эмпирический контроль процесса

Ш Временные рамки

Ш Самоорганизация

Ш Ценностная приоритезация

Ш Итеративная разработка [6]

Непосредственный процесс планирования в Scrum, строящийся на этих принципах, можно описать следующей схемой:

Рисунок 7. Процесс планирования в Scrum.

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



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

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



Глава 2. Эмпирическое исследование

2.1 Кейс компании «Яндекс»

В данной главе будет рассмотрена деятельность по управлению проектами в крупных российских IT-компаниях на примере «Яндекса».

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

· Компания является репрезентативной с точки зрения внешних параметров - ведет деятельность в сфере информационных технологий на российском рынке, численность сотрудников компании составляет 6271 на 2016 год;

· В компании на протяжении долгого времени используются гибкие методологии разработки [30, 31].

«Яндекс» - технологическая компания, которая строит интеллектуальные продукты и услуги, основанные на компьютерном обучении. С 1997 «Яндекс» предоставляет услуги поиска информации мирового уровня. Кроме того, компанией были созданы ведущие на рынке транспортные сервисы и навигационные продукты, а также другие мобильные приложения, имеющие аудиторию в миллионы пользователей по всему миру. «Yandex NV» зарегистрирована на NASDAQ с 2011 года.

Yandex как компания появилась в 2000 году, через три года после запуска веб-портала yandex.ru. На данный момент у Яндекса есть офисы и представительства в девяти странах. На внутреннем рынке России, доля всего трафика поиска составляет 54,8% [29]. Компания также работает в Беларуси, Казахстане и Турции. Более 90% интернет-пользователей в России, проживающих в городах с населением 700 000 и более, используют услуги Яндекса [27].

Кроме того, «Яндекс» является лидером в своем сегменте - он возглавил рейтинг самых дорогих российских интернет-компаний по версии Forbes со стоимостью $12,38 млрд долларов [26].

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

· Поисковые - Яндекс.Поиск;

· Мультимедийно-поисковые - Яндекс.Картинки, Яндекс.Видео, КиноПоиск, Яндекс.Музыка;

· Картографические - Яндекс.Карты, Яндекс.Навигатор, Яндекс.Метро, Яндекс.Транспорт;

· Рыночно-поисковые - Яндекс.Афиша, Яндекс.Такси, Яндекс.Маркет;

· Справочно-информационные - Яндекс.Погода, Яндекс.Переводчик;

· Рекламные и статистические - Яндекс.Метрика, Яндекс.Директ;

· Для бизнеса - Яндекс.Касса, Яндекс.Телефония;

· Персонализированные - Яндекс.Почта; Яндекс.Деньги; Яндекс.Дзен.

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

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



2.2 Методология исследования

2.2.1 Общее описание методологии

Проведенное исследование можно разделить на 4 этапа:

Рисунок 8. Методология исследования

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

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

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

На четвертом этапе были подготовлены методические рекомендации по улучшению качества командной работы.



2.2.2 Составление опроса и формулирование гипотез

Для изучения зависимости успеха проекта от качества командной работы был адаптирован опросник [14].

Оригинальный опросник включал в себя 6 конструктов, описывающих качество командной работы, а также 2 конструкта, описывающие успех проекта. В качестве ролей в команде исследователи выделили «лидеров команды», «Владельцев продукта» и «членов команды». По результатам предварительного интервью с сотрудниками компании «Яндекс» было принято решение заменить должность «лидер команды» на «Scrum-мастер». В его обязанности в команде входит контроль за эффективным соблюдение всех принципов этой гибкой методологии (организация митингов, планирование спринтов, ежедневные скрам-митинги), а также за организацию эффективных коммуникаций в команде. Именно поэтому его мнение о качестве командной работы и успешности реализации проектов является крайне важным для рассмотрения.

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

На основании информации, изученной в первой главе, были сформулированы 6 гипотез:

H1. Переменная «Успех команды» зависит от переменной «Коммуникации».

H2. Переменная «Успех команды» зависит от переменной «Взаимная поддержка».

H3. Переменная «Успех команды» зависит от переменной «Сплоченность».

H4. Переменная «Успех проекта» зависит от переменной «Коммуникации».

H5. Переменная «Успех проекта» зависит от переменной «Взаимная поддержка».

H6. Переменная «Успех проекта» зависит от переменной «Сплоченность».

2.3 Анализ результатов

2.3.1 Описательная статистика

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

Таблица 2. Размер команды.

Размер команды	Процент респондентов
Менее 5	7,1
5-10	17,9
11-15	50
Более 15	25

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

Рассмотрим опыт сотрудников в сфере IT.



Таблица 3. Опыт работы в IT

Опыт работы в IT	Процент респондентов
От 1 до 3 лет	32,1
От 3 до 5 лет	60,7
Более 5 лет	7,1

Из таблицы можно явно увидеть, что подавляющее большинство респондентов работают в сфере информационных технологий не менее 3 лет (60,7%), а некоторые и более 5 (7,1%). Респонденты, работающие менее 1 года в выборке не представлены.

Говоря об опыте работы с гибкими методологиями, в выборке доминирует показатель от 1 до 3 лет (57,1%), а почти треть респондентов имеет опыт работы с agile (более трех лет), что позволяет говорить об опытности членов команд и глубоком внедрении гибких методологий в их деятельность.

Таблица 4. Опыт работы с гибкими методологиями.

Опыт работы с agile	Процент респондентов
Менее 1 года	10,7
От 1 до 3 лет	57,1
От 3 до 5 лет	32,1

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



Таблица 5. Роли в команде

Роль в команде	Процент респондентов
Scrum-мастер	25
Владелец продукта	21,4
Член команды (разработчик, тестировщик и др.)	53,6

2.3.2 Тест надежности переменных

В качестве переменных для анализа будут использоваться конструкты, составленные из нескольких переменных, поэтому необходимо произвести тест их валидности. Наиболее распространенным способом для этого является нахождение коэффициента Альфа Кронбаха. Данный показатель оценивает внутреннюю согласованность переменных и измеряется в значениях от 0 до 1, где 0 - полностью не согласованы, 1 - полностью согласованы. Таким образом, чем выше значение, тем конструкт более согласован. Единого стандарта порога отсечения нет, однако наиболее популярное пороговое значение - 0,7. В таблице представлены результаты для составных переменных:

Таблица 6. Тест надежности переменных

Название переменной	Количество показателей	Альфа Кронбаха
Коммуникации	10	,909
Координация	3	,717
Взаимная поддержка	6	,826
Старание	4	,888
Сплоченность	6	,857
Вклад участников	3	,792
Успех команды	7	,844
Успех проекта	9	,909

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



2.3.3 Анализ корреляций

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

Таблица 7. Корреляции Пирсона

Переменная		Успех команды	Успех проекта
Коммуникации	Корреляция Пирсона	,342(**)	,710(**)
	Знч.(2-сторон)	,000	,000
Координация	Корреляция Пирсона	,339	,308(*)
	Знч.(2-сторон)	,176	,010
Взаимная поддержка	Корреляция Пирсона	,724(**)	,339(*)
	Знч.(2-сторон)	,000	,020
Старание	Корреляция Пирсона	,318(*)	,282
	Знч.(2-сторон)	,040	,218
Сплоченность	Корреляция Пирсона	,695(**)	,604(**)
	Знч.(2-сторон)	,001	,000
Вклад участников	Корреляция Пирсона	,367	,290(*)
	Знч.(2-сторон)	,112	,032

**Корреляция значима на уровне 0.01 (2-сторон.).

* Корреляция значима на уровне 0.05 (2-сторон.).

Согласно таблице критических значений корреляции Пирсона, уровень значимости для двустороннего критерия при p<0,05 и выборке 28 человек составляет 0,37. Таким образом, значимыми в данной таблице можно считать корреляции между переменными «Успех команды» и «Взаимная поддержка» (0,724), «Успех команды» и «Сплоченность» (0,695), «Успех проекта» и «Коммуникации» (0,710), «Успех проекта» и «Сплоченность» (0,604). Кроме того, переменные «Успех команды» и «Успех проекта» также коррелируют между собой на статистически значимом уровне, что говорит о наличии связи между внешними и внутренними проявлениями деятельности команд.

2.3.4 Построение модели множественной линейной регрессии

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

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

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

Модель	R	R квадрат	Скорректированный R квадрат	Стд. ошибка оценки	Дурбин-Уотсон
1	,861(a)	,741	,720	,29772	1,741

a Предикторы: (константа) Взаимная_поддержка, Сплоченность b Зависимая переменная: Успех_команды

В данной модели нас интересует скорректированный R квадрат, показывающий долю дисперсии зависимой переменной, объясняемой рассматриваемой моделью зависимости и использующий несмещенную оценку дисперсии. Показатель в 0,72 является достаточно высоким, особенно учитывая малый размер выборки.

Для проверки этого условия об отсутствии автокорреляции проводится тест Дурбина--Уотсона. В ходе проведения этого теста рассчитывается коэффициент, значение которого лежит в диапазоне от 0 до 4. Если значение коэффициента близко к среднему (т.е. к 2), это означает, что автокорреляция отсутствует, т.е. остатки появляются случайным образом. В данном случае, значение данного коэффициента является приемлемым.

Анализ ANOVA показывает, что модель является значимой, так как гипотеза об одновременном равенстве нулю всех коэффициентов при факторах регрессионной модели не подтверждается (Знч<0,05).

Таблица 9. ANOVA

Модель		Сумма квадратов	ст.св.	Средний квадрат	F	Знч.
1	Регрессия	6,340	2	3,170	35,766	,000(a)
	Остаток	2,216	25	,089
	Итого	8,556	27

a Предикторы: (константа) Взаимная_поддержка, Сплоченность b Зависимая переменная: Успех_команды

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

Таблица 10. Коэффициенты модели

Модель	Нестандартизованные коэффициенты	Стандартизованные коэффициенты	t
	B	Стд. ошибка	Бета		Знч.
1	(Константа)	,035	,485		,072	,943
	Сплоченность	,558	,208	,491	2,678	,013
	Взаимная_поддержка	,418	,188	,408	2,221	,036

a Зависимая переменная: Успех_команды

Из данной таблицы видно, что обе независимые переменные являются значимыми (знч<0,05).

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

Успех команды = 0.035+0.558*(Сплоченность)+0.418*(Взаимная поддержка)

Данное уравнение означает, что при увеличении переменной «Сплоченность» переменная «Успех команды» увеличивается на 0,558, а при увеличении значения переменной «Взаимная_поддержка» на 1, на 0,418, соответственно. Все это позволяет говорить о том, что данные переменные довольно полно описывают зависимую переменную, позволяя предсказывать ее с большой долей вероятности.

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

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

Модель	R	R квадрат	Скорректированный R квадрат	Стд. ошибка оценки	Дурбин-Уотсон
1	,809(a)	,654	,626	,36492	2,028

a Предикторы: (константа) Коммуникации, Сплоченность b Зависимая переменная: Успех_проекта

Скорректированный R квадрат составляет 0,626, что также является значимым показателем. Коэффициент Дурбин-Уотсона является приемлимым. Модель, как и в первом случае, можно считать значимой, согласно анализу ANOVA.

Таблица 12. ANOVA

Модель		Сумма квадратов	ст.св.	Средний квадрат	F	Знч.
1	Регрессия	6,285	2	3,142	23,596	,000(a)
	Остаток	3,329	25	,133
	Итого	9,614	27

a Предикторы: (константа) Коммуникации, Сплоченность b Зависимая переменная: Успех_проекта



Коэффициенты модели представлены ниже.

Таблица 13. Коэффициенты

Модель	Нестандартизованные коэффициенты	Стандартизованные коэффициенты	t
	B	Стд. ошибка	Бета		Знч.
1	(Константа)	,217	,576		,376	,710
	Коммуникации	,399	,167	,389	2,386	,025
	Сплоченность	,529	,176	,489	2,997	,006

a Зависимая переменная: Успех_проекта

Из данной таблицы также видно, что обе независимые переменные являются значимыми (знч<0,05).

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

Успех проекта =0.217+0.399*( Коммуникация)+0.529*( Сплоченность).

Таким образом, обе модели продемонстрировали статистическую значимость: 72% дисперсии показателя «Успех команды» описывается переменными «Сплоченность» и «Взаимная поддержка», а 62% дисперсии «Успеха проекта» переменными «Коммуникации» и «Сплоченность».

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

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

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

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

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

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

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



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

В данной главе было проведено исследование особенностей гибкого управления проектами в крупных IT-компаниях на примере «Яндекса». На основании проанализированных в первой главе научных исследований, а также мини-интервью с сотрудниками компании, был составлен опрос, в котором приняло участие 28 респондентов. По результатам анализа полученных данных было выявлено, что успех проекта и успех команды коррелируют с такими показателями качества командной работы, как коммуникации, взаимная поддержка, сплоченность. Эти данные подтвердили 4 из 6 заявленных гипотез и продемонстрировали согласованность с другими исследованиями на данную тему.



Глава 3. Рекомендации по улучшению командной работы

3.1 Повышение эффективности комм...