Гибкие методы управления проектами

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

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

Содержание

Введение

Глава 1. Теоретические предпосылки и основные принципы гибких методов управления проектами

1.1 Основные понятия Agile и их специфика

1.2 Инструменты Agile методов

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

Глава 2. Разработка алгоритма определения методологии управления проектами для ИТ-компаний

2.1 Сравнительный анализ внедрения традиционных и Agile методов

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

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

Глава 3. Применение алгоритма определения гибкой методологии управления проектами на примере ИТ-компаний Пермского края

3.1 Описание выборки

3.2 Применение алгоритма на практике

3.3 Оценка эффективности внедрения гибкого управления в компанию Геликон Про

Заключение

Список литературы



Аннотация

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

Abstract

This work is devoted to the development of selection Agile tool for IT companies. Many companies have been successful in flexible management, but there are some companies that are now starting to use Agile and they need to understand what methodology to use. In IT-field managers who have not moved to Agile project management yet, ask a question: How to determine the readiness of the company to adopt agile methods. What technologies and methods should be used to implement Agile project management methods, depending on the characteristics of the organization. In this paper we define the criteria for the company's readiness for the introduction of Agile and create an algorithm with the recommendations for the project manager. The results of the algorithm were tested in an IT company. The analysis showed the effectiveness of the algorithm in comparison with competitor, that did not implement Agile.



Введение

Исследования GAO показали, что большинство успешных проектов - это те, которые следовали гибким принципам разработки [GAO Software Development, 2012, p 4]. Методы, основанные на традиционных моделях, не всегда являются наилучшими, в частности, при управлении изменениями, быстрой реализации проекта или даже удовлетворении потребностей рынка.

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

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

Степень разработанности темы в отечественной и мировой науке.

Вопросами гибкого управления занимались следующие авторы: Cohne M., Dyba T., Dingsyr T., Greenwood A., Henson M., Highsmith J., Hiranabe K., Johnson J., Boucher D. K., Connors K., Robinson J., Narasimhan R., Swink M., Kim Wook S., Palme S. R., Felsing J. M., Poppendieck T., Schwaber K., Sliger M., а также и у российских авторов Вольфсон Б., Борисов С., Плеханова А. Внедрением гибких методов в организации было описано у таких авторов, как Christopher M., Murph C., Yusuf Y. Y., Adeleye E. O., Zhang Z., Sharifi H. A.. вопросом участия стейкхолдеров гибком управлении рассмотрели следующие авторы: Beringer C., Jonas D., Kock A., Davis K., Jepsen A., Eskerod P., Воропаев В. Формирование и особенности команды проекта описали в своих работах такие авторы, как Cockburn A., Ghosh G., Kerth N., Yves L. Doz, Kosonen M. И у российского автора Галкина Т.

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

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

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

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

Изучить гибкие методы и их особенности

Проанализировать методы управления проектами в Agile

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

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

Изучить особенности ИТ проектов, которые внедрили Agile

Определить особенности проектной деятельности в ИТ-компаниях

Выделить методы управления Agile для различных типов проектов

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

Апробировать алгоритм выбора инструмента гибкого управления на ИТ-компаниях

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

В работе был определен объект данной работы как: проектное окружение ИТ-компании, которое необходимы для внедрения гибких методов.

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

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

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

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

Выявить приверженцев Agile среди менеджеров высшего уровня.

Убедиться, что в команду входят сотрудники с опытом в Agile.

Создать небольшие функциональные команды.

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

Степень формализации

Степень сложности внесения изменений

Системное решение проблем

Степень коллективной ответственности

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

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

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

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

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

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

Структура работы. Данная работа состоит из введения, трех глав в основной части и заключения. Объем диссертации составляет 76 страниц. Исследовано около 50 источников, из которых 35 на английском и 15 на русском. В работе содержится 17 рисунков и 4 таблицы.

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

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

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

гибкий проект agile инструмент



Глава 1. Теоретические предпосылки и основные принципы гибких методов управления проектами

1.1 Основные понятия Agile и их специфика

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

Учитывая специфику применения гибких методов в 2001 году ведущие специалисты IT отрасли разработали манифест применения Agile методов. Он включает в себя четыре пункта [Вольфсон, 2012, с. 5]:

Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.

Сотрудничество с заказчиком важнее согласования условий контракта.

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

Многие исследователи давали определение понятия Agile для разработки программного обеспечения, однако данные методы можно применять не только в IT сфере. PMBOK выделяет гибкие методы управления, как нестандартные, которые могут применяться в инновационных проектах [PMBOK 5, 2013, с. 11]. Из этого можно выделить, что гибкие методы это набор последовательных действий направленных на разработку продукта, ориентированных на использование итеративного взаимодействия, динамическое формирование требований и обеспечение их реализации в результате постоянной работы внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля [Sliger, 2012, p. 7].

Также в манифесте гибких методов выделены основополагающие принципы [Вольфсон, 2012, с. 6]:

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

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

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

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

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

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

Работающий продукт - основной показатель прогресса.

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

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

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

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

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

Из самого определения видно, что гибкие методы нацелены на непосредственное общение участников лицом к лицу. Большинство гибких проектов проводят в одной комнате. В такой комнате команда проекта проводит встречи и совещания с заказчиками, на которых обсуждается, что уже сделано, и что надо сделать на следующем этапе. Таким образом, весь проект делиться на несколько коротких циклов, которые легко контролировать. Каждый цикл включает в себя цели и задачи, а также ожидаемый результат. Циклы продумывают по пяти функциям менеджмента: планирование, организация, мотивирование, координация и контроль. После завершения каждого цикла результаты фиксируются в документах. В данном случае подразумевает не полное документирование как в традиционных методах управления. Фиксируется решение возникшей проблемы или результат работы. После чего, команда оценивает проделанную работу и расставляет приоритеты на следующий цикл [Johnson J., 2001, p. 5].

Большинство гибких методов минимизируют риски за счет своей системы деления проекта на несколько небольших циклов - интеракции. И проект становится похожим на программу, которая состоит из нескольких небольших проектов, нацеленных на достижение одной цели. Poppendieck отметил, что малые проекты имеют больший процент успеха, чем большие. Он выделил ряд преимуществ [Poppendieck, 2003, p. 3]:

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

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

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

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

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

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

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

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

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

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

1.2 Инструменты Agile методов

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

Основные инструменты Agile методов:

Scrum (Ken Schwaber)

Экстремальное программирование XP (Kent Beck)

Kanban (David Anderson)

Crystal (Alistair Cockburn)

Методы разработки динамических систем - Dynamic System Development Method (Dane Faulkner)

Driven Development (Jeff DeLuca)

Рассмотри каждый из инструментов подробно.

Scrum один из наиболее популярных инструментов гибких методов. Scrum является адаптивным и эмпирическим методом, который используют в проектной деятельности с 1995 года [Amani M., 2013, p. 160]. Данный метод может быть использован на любом по размеру проекте. Он имеет простую реализацию, благодаря которой повышается производительность команды и снижается время на бумажную работу. Scrum содержит в себе идею простоты, поэтому она не включает в себя многоуровневые подходы. Он имеет три основных вопроса [Murph, 2004, p. 5]:

Что вы сделали в течение последних 24 часов? - информация о проделанной работе в предыдущий день.

Что вы планируете делать в ближайшие 24 часа? - перспективы работы, которую планируют сделать.

Что вам мешает работать в течение 24 часов? - какие ограничения могут возникнуть при выполнение работы.

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



Рис. 1 Основной процесс Scrum

Он начинается с требований и приоритетов владельца продукта, из которых формируется первоначальное виденье продукта. Команда проекта планирует свою деятельность, опираясь на сформированные требования. Команда выполняет задания, и каждый день проводит совещания, где обсуждают основные три вопроса. Владелец продукта принимает активное участие в проекте. В рамках Scrum между командой проекта и владельцем продукта формируется обратная связь, которая показана на рисунке 2 [Schwaber, 2004, p. 9].



Рис. 2 Обратная связь в рамках Scrum

Таким образом, команда постоянно совершенствует продукт, улучшая его и внося новые требования к нему. Сами встречи строго ограничены по времени - 15 минут [Schwaber, 2004, p. 9]. Такие совещания не занимают много времени и члены команды полностью сфокусированы на своем задании. На этих совещаниях часто используют визуальное представления. Менеджеру проекта легко контролировать развитие проекта, потому что каждый день обсуждается проделанная работа, план на день и возможные ограничения.

ХР или экстремальное программирование заключается в постоянной интеграции, то есть постоянное повторение [Christopher, 2000, p. 37). Метод заключает в том, что команде проекта дается первоначальные требования заказчика, а команда проекта разрабатывает и планирует самостоятельно, опираясь на опыт и предыдущие практики (рис. 3) [Sourajeet R., 2010, p. 277].



Рис. 3 Общая схема ХР

Данный метод основан на опыте и знаниях членов команды. Используя данный подход необходимо сформировать команду специалистов, которые могут работать слажено вместе. Однако менеджеру проекта необходимо отслеживать ход проекта. ХР включает в себя тестирование продукта проекта. В конце каждого тестирования пишется отчет [Sourajeet R., 2010, p. 280]. Таким образом, продукт постоянно тестируется и улучшается. Однако данный метод требует интенсивной работы и часто функции выполняются попарно разными членами проекта. Попарное выполнение задач дает возможность улучшения продукта и минимизирует процент ошибки [Jahangiri T., 2015, p. 2].

Kanban появилось из философии Lean Technology, которая руководствуется девизом «точно в срок». Kanban в переводе с японского означает «карты или знак». Данный метод включает в себя карточки с заданиями, которые крепятся на информативную доску. Задания устанавливает команда проекта или менеджер проекта. Чтобы менеджеру отслеживать ход проекта, доска делиться на 3 столбца, как показано на рисунке 4: что надо сделать, что делается и что сделано. По мере выполнения заданий карточки перемещаются со столбца «надо сделать» на столбец «сделано». Существует и другой способ визуализации - карточки с заданием передвигаются по столбцам, в которых написаны даты.

Рис. 4 Пример Kanban

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

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

В Kanban время проекта сначала разбивается на «Реализацию», дальше делится на «Итераций», и каждой итерации разбиваются в «Дни» [Hiranabe, 2007, p. 2]:

Реализация, как правило, длится от 1 до 6 месяцев. Это точка синхронизации всей команды, так что все в команде должны быть заинтересованы в этом.

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

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

Задачи тоже делятся на уровни. Есть три уровня детализации для задач. Здесь высшем уровнем являются «Функции», каждая функция разбивается на «Истории», каждая история делится на «Задачи» [Hiranabe, 2007, p. 3]:

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

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

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

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



Рис. 5 Связь между временем и заданиями в Kanban

Crystal это легковесная гибкая методология, созданная Алистером Кокберном [Cockburn, 2004, 14]. Она предназначена для небольших команд в 6-8 человек для разработки некритичных бизнес-приложений. Как и все гибкие методологии Crystal больше опирается на людей, чем на процессы и артефакты.

Crystal использует семь методов [Cockburn, 2004, p. 14]:

Частая поставка продукта

Улучшения через рефлексию

Личные коммуникации

Чувство безопасности

Фокусировка

Простой доступ к экспертам

Качественное техническое окружение

В данной системе команда состоит из 6-8 совмещенных разработчиков, работающих в системах, которые не жизненно-важных для организации. Crystal методологий сосредоточиться на эффективности и жизнедеятельности в качестве компонентов безопасности проекта [Bellomo S. et al, 2015, p. 5].



Рис. 6 Общая схема Crystal

В данном методе важным принципом является частая поставка продукта, улучшение через рефлексию и личные коммуникации. Остальные четыре принципа являются дополняющими, но тоже необходимые для управления проектом [Ramon J. et al, 2014, p. 11].

Dynamic Systems Development Method (DSDM) - это итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя или потребителя [Greenwood, 2008, p. 2]. Цель метода - сдать готовый проект вовремя и уложиться в бюджет, но в то же время, регулируя изменения требований к проекту во время его разработки [Greenwood, 2008, p. 2].

Данный метод включает в себя девять принципов [Bannister F., 2014, p. 119]:

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

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

Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей встрече.

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

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

Любые изменения во время разработки - обратимы.

Требования устанавливаются на высоком уровне прежде, чем начнётся проект.

Тестирование интегрировано в жизненный цикл разработки.

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

Методология DSDM включает в себя три стадии, которые изображены на рисунке 7 [Greenwood, 2008, p. 3]:

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

Жизненный цикл проекта представляет собой реализацию проекта и включает в себя пять этапов.

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

Жизненный цикл проекта включает в себя пять стадий [Greenwood, 2008, p. 3]:

Определение реализуемости

Экономическое обоснование

Создание функциональной модели

Проектирование и разработка

Реализация

Рис. 7 Общая схема DSDM

Driven development интерактивная методология для разработки и постоянного улучшения продукта. Этот метод похож на предыдущий, но отличается порядком ведения разработки продукта (рис. 8). Разработка ведется в пять этапов [Palme, 2002, p. 23]:

Построение модели

Создание списка функций

Планирование реализации функций

Создание архитектуры для функций

Реализация функций



Рис. 8 Общая схема driven development

Как и во всех методах, в этой модели заказчик принимает активное участие на всех этапах. В проекте команда постоянно тестирует продукт и предоставляет результаты заказчику [Jetzek T., 2015, p. 9]. Таким образом, выявляются ошибки и доработки продукт, тем самым его улучшая. Команда проекта разделяет функции и создается иерархия задач, которую необходимо выполнить. Такое разделение позволяет легко контролировать проект.

Существуют и другие методы управления в Agile. Общего среди всех будет постоянный контакт с заинтересованными лицами, короткий канал обратно связи и разделение работы проекта на интеракции. Еще общей чертой является постоянное тестирование продукта в конце каждой интеракции [Черных. Е., 2008, с. 2]. Таким образом, гибкие методы могут реагировать на изменение окружающей среды или внедрять внутренние разработки в течение проекта с минимальными затратами.



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

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

Mike Cohn свел в таблице 1 обязанности владельцев процессов в гибком управлении проектами [Cohn, 2003, p. 37].

Таблица 1.

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

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

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

Успех проекта зависит не только от навыков менеджера проекта, но и от компетенций членов команды. Многопрофильная работа в команде является одним из критериев успеха в гибких проектах. Многопрофильная команда должна состоять из всех заинтересованных сторон. Это включает в себя спонсоров проекта, эксперты, пользователей, дизайнеры, разработчики. Важно, что все различные интересы представлены в команде. Сложность заключается не только в формировании команды, но и в оценке каждого ее члена. Чтобы не возникла проблема «зайца» в проекте, который вложился незначительно, а был оценен наравне с остальными, Ghosh критерии отбора участников проекта [Ghosh, 2004, p. 18]:

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

Имеет право и возможность выполнять задачу

Поддержка руководителя

Опытный и знающий свою область

Представляет своих коллег

Располагает временем, чтобы участвовать в проекте

Хочет внести свой ??вклад в успех

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

Работа в команде может быть продуктивной, если члены команды понимают цели и стремятся к их достижению. Поэтому важно, чтобы они на самом деле представляли различные аспекты проблем или решений проекта и знали о своей собственной роли в команде. Ghosh выделил основные роли в гибких проектах [Ghosh, 2004, p. 19]:

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

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

Пользователи могут предложить улучшения. Также они могут участвовать как тестировщики продукта.

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

Менеджер проекта координирует команду.

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

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

Стоит учесть, что команда формируется и проходит определенные стадии жизненного цикла, который представлен на рисунке 6. Жизненный цикл команды начинается с ее формирования и заканчивается самоорганизацией команды. На каждой стадии есть свои проблемы, которые могут быть препятствиями при переходе к следующему этапу жизненного цикла. Жизненный цикл команды состоит из четырех этапов [Уэбстер, 2008, с. 272]: формирование, становление, нормализация, взаимодействие и расформирование (рис. 9).

Рис. 9 Жизненный цикл команды проекта

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

Формирование - члены команды начинают привыкать друг к другу, определяются роли и формируется определенные навыки работы вместе [Уэбстер, 2008, с. 273].

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

Нормализация - команда готова принимать совместные решения, поскольку уровень доверия повысился. Конфликты уменьшаются, члены команды утвердили свои полномочия и власть [Уэбстер, 2008, с. 273].

Взаимодействие - команда полностью погружается в проект и перестает конфликтовать. Достигается взаимодействие и взаимопонимание между членами команды. Вследствие чего, команда может самостоятельно ставить себе цели и задачи, а также принимать решения [Уэбстер, 2008, с. 273].

Расформирование - Данная стадия возникает тогда, когда изменяется структуры управления проекта, завершаются отдельные стадий проекта, изменяется объем и вид работ, заменяются работники из-за профессионального несоответствия или дополнительно привлекаются новые специалисты, приглашаются временные эксперты [Уэбстер, 2008, с. 274]. После этой стадии команда расформировывается. Не всегда эта стадия наступает, когда проект завершатся. Менеджер проектов может расформировать и собрать новую команду исполнителей вне зависимости от стадии проекта. Потому что могут возникнуть ситуации, когда надо заменить состав всей или части команды из-за несоответствия знаний исполнителей задачи проекта. На этой стадии необходимо менеджеру проекта корректно провести «прощание» сотрудников с будущими перспективами вновь собрать эту же команду.

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

На каждом этапе есть барьеры, через которые команда должна пройти или она не сможет перейти к следующей стадии жизненного цикла. Вольфганг Крюгер выделили несколько барьеров на каждом этапе жизненного цикла команды [Крюгер, 2005, с. 34].

Барьеры на этапе формализации:

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

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

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

Барьеры на этапе становления:

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

Барьеры на этапе нормализации:

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

Проблемы с менеджментом. Этот барьер вытекает из первого давление со сроками. Менеджер должен уметь планировать работы команды. Однако в Agile-проектах сроки и объем работ определяются неточно и могут варьироваться в зависимости от желания потребителя или заказчика. Поэтому менеджер проектов должен быть максимально вовлечен в работу команды. Ему следует быть на всех совещаниях команды и стараться отслеживать продвижение продукта в проекте. Потому что таким образом он сможет управлять временем и объемами трудозатрат подзадач.

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

Барьеры на этапе взаимодействия:

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

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

Барьеры на этапе расформирования:

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

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

Исследователи еще не пришли к единой типологии команд. По мнению Д. Макинтош-Флетчер, существует два основных типа команд: кросс-функциональные и интактные команды [Уэбстер, 2008, с. 281].

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

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

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

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

В таблице 2 представлена матрица типов команд по Д. Макинтош-Флетчер [Галкина, 2003, c. 150].

Таблица 2

Матрица типов команд по теории Д. Макинтош-Флетчер

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



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