Гибкие методы управления проектами
Изучение специфики гибких методов управления проектами, взаимоотношений команды, менеджера и заинтересованных сторон при их внедрении. Разработка алгоритма выбора инструментов Agile в ИТ-компаниях на основании анализа различных условий реализации проекта.
| Рубрика | Менеджмент и трудовые отношения |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 31.10.2016 |
| Размер файла | 2,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Стейкхолдеры обычно ведут себя так, как того требует рынок. Mostashari A. и McComb S. проводили исследование о том, как стейкхолдеры работают в гибкой системе проекта [Mostashari, 2011, p. 7). Они определили, что стейкхолдеры готовы работать в гибкой системе и даже придерживаются идеи быть включенными в процессы проекта. Beringer C. и его коллеги провели эмпирическое исследование по статьям, которые описывают взаимоотношения между командой проекта и стейкхолдерами. Они выделили закономерности и сгруппировали их по критериям в таблицы. Критерии включали в себя отношение стейкхолдеров к традиционному ведению проекта и гибкому. Оказалось, что стейкхолдеры предпочитают вести проект по методологии Agile, поскольку процессы в работе становятся более понятными и простыми [Beringer C., et al, 2013, p. 830]. В гибком управлении проектами стейкхолдеры могут повлиять на проект и изменить его направление. При этом стейкхолдеры ведут себя так, как установлено правилами рынка. К такому выводу пришли и другие авторы, которые исследовали поведение стейкхолдеров в проекте с гибким управлением. Поскольку многие стейкхолдеры могут быстро адаптироваться к гибкой культуре Agile [Jepsen A., 2009, p. 335]. Многие проекты были успешными, когда заинтересованные лица становились участниками проекта. В таком проекте можно быстрее получить обратную связь на разных этапах создания продукта и принимать решения коллективно вместе с заказчиком, потредителем и другими заинтересованными лицами [Davis K., 2014, p.189].
Таким образом, можно сказать, что выбор гибкого управления зависит от команды проекта и ее окружения. Поскольку стейкхолдеры предпочитают участвовать в проекте как его часть и готовы принимать изменения окружающей среды. Выбор подходящего инструмента для проекта необходимо основывать на основе среды реализации проекта и возможностей команды. Поскольку некоторые инструменты предполагают четкие требования к команде или предоставляют алгоритм организации проектной деятельности, от которого нельзя отклоняться или метод не будет так эффективно работать, как предполагается. Также не маловажную роль в организации проектного управления играет формирования команды проекта. Менеджеру стоит учитывать на какой стадии жизненного цикла команда проекта и мониторить барьеры каждого этапа.
Глава 2. Разработка алгоритма определения методологии управления проектами для ИТ-компаний
2.1 Сравнительный анализ внедрения традиционных и Agile методов
На быстроразвивающемся рынке с высокой неопределенностью традиционные методы управления могут быть неэффективными. И на сегодняшний момент многие проектные менеджеры используют Agile методы управления проектами, у которых есть ряд преимуществ по сравнению с традиционными методами.
Mishele Sliger сравнивала традиционные и Agile методы управления проектами в таблице 3 [Sliger, 2012, p. 3].
Таблица 3
Сравнение традиционных и Agile методов
|
Критерии сравнения |
Традиционные методы |
Agile методы |
|
|
Планирование |
Планирование, что должно получиться по окончанию проекта. |
Планирование с учетом будущих изменений. |
|
|
Контроль |
Использование директив менеджмента для контроля работ проектов. Организация контрольных точек. |
Контроль осуществляется через адаптацию команды проекта к окружающей среде: самоорганизующаяся команда, накапливания опыта с предыдущих проектов. |
|
|
Изменения |
Применение теории управление изменениями. |
Личный опыт членов проекта и других проектов дает поэтапное внедрение изменений в проект. |
Однако автор говорит о том, что гибкие методы имеют те же составляющие, что и традиционные методы управления. Автор выделила 4 составляющих, которые приведены в таблице 4: планирование, выполнение работ в проекте, управление проектом и управление изменениями
Таблица 4
Сравнение составляющих традиционных и гибких методов
|
Составляющие |
Традиционные методы |
Agile методы |
|
|
Планирование |
Планирование развития проекта |
Планирование реализации и циклов повторения |
|
|
Работы в проекте |
Выполнение плана |
Повторяющиеся циклы |
|
|
Управление |
Организация, управление, мониторинг, контроль |
Сотрудничество, постоянное обучение и развитие, содействие с заинтересованными лицами |
|
|
Управление изменениями |
Контроль изменениями |
Постоянная обратная связь и накапливание опыта |
Сравнивая два подхода к управлению проектами можно сказать, что гибкие методы имею особенности применения. Гибкий метод управления проектами проводится в маленьких группах, желательно чтобы все члены команды находились в одном здании. При этом количество документации сведено к минимуму, поскольку команда полагается на неформальное общение, которое уменьшает затраты времени на составление документов. Команда сдает продукт пошагово, что позволяет контролировать процесс на разных стадиях разработки, а также вносить изменения в сам продукт. Команда ориентируется на достижение поставленной цели, иногда цели могут меняться из-за изменений потребностей рынка.
Ключевыми элементами Agile, которые являются основой гибких методов управления проектами, являются: визуальный контроль, близкое расположение всех участников проекта, разработка продукта на тестировании, постоянная адаптация, совместная разработка, руководство и сотрудничество, перевод фокуса с затрат на прибыль, накопление опыта [Dyba, 2008, p. 833]. Рассмотрим каждый из них подробнее.
Визуальный контроль. Этот метод основан на карточках, которые выше были описаны в методе Kanban [Dyba, 2008, p. 833]. Таким образом, команда может быстро и наглядно получить необходимую информацию о состоянии проекта, и какие элементы продукта были изменены или разрабатываются.
Близкое расположение всех участников проекта. Гибкие методы управления проектами подразумевает близкое нахождение разработчиков, менеджера проекта, заказчика и потребителя. Поскольку происходит неформальное общение среди всех участников и возможны совещания по новым изменениям в продукте, то потребуется присутствие всех заинтересованных сторон [Highsmith J., 2000, p. 4].
Разработка продукта на тестах. В случаи, когда сложно определить требования, то разработка продукта основывается на постоянном тестировании. Потребитель или заказчик тестирует продукт на протяжении его разработки, и может изменить или точнее определить свои требования [Dyba, 2008, p. 833].
Постоянная адаптация. Из-за быстроменяющейся окружающей среды многие технологии могут измениться во время разработки продукта, тем самым приходится менять первоначальные цели и задачи, чтобы выпустить актуальный продукт [Dyba, 2008, p. 835].
Совместная разработка. Члены команды обмениваются мнениями о продукте, поднимая на обсуждение следующие вопросы: какие работы уже выполнены, какие работы следует выполнить, какие препятствия будут на следующем этапе и какие улучшения можно произвести [Highsmith J., 2000, p. 4]. Таким образом, члены команды работают не только над отдельный функцией проекта, а рассматривают проект с разных сторон и создать общую картину о продукте. Но учитывая тот факт, что в команду входят специалисты, то имею общую картину о продукте, каждый специалист выполняет свою роль.
Руководство и сотрудничество. В гибких методах контроль как функция перестает быть строго регламентированной. Поскольку команда стремиться выполнить задание с высоким качеством на всех этапах разработки продукта [Dyba, 2008, p. 836]. Потребитель участвует в разработке продукта, поэтому осуществляется контроль от начала проекта и до его окончания.
Перевод фокуса с затрат на прибыль. Фокус с производства продукта переводится на рыночную значимость [Dyba, 2008, p. 838]. Таким образом команда стремиться не уменьшить затраты на производство, а повысить выручку.
Накопление опыта. Из-за близкого и неформального общения могут возникнуть инновационные решения, которые в последующих проектах могут быть использованы [Dyba, 2008, p. 840]. Также в такой системе специалисты обмениваются опытом и знаниями, и повышают свой уровень.
В связи с особым отношением к работе в гибких методах управления проектами, планирование характеризуется особыми свойствами. Таким образом, в определении гибкого планирования выделяются следующие свойства [Highsmith J., 2002, p. 223]:
Сосредоточенность больше на планировании, а не на составление плана. Имеется в виду, что первоначальный план составляется обобщенно на весь проект и происходит точное планирование задач каждую встречу участников команды.
Положительно относится к изменениям. Изменения дают толчок к новым идеям и возможность более точно отвечать на потребности потребителей или предугадать будущие.
Результаты в планах легко изменить. Это свойство вытекает из предыдущего.
Планирование на протяжении всего проекта. Имеется в виду, что планирование происходит каждую интеракцию. Поэтому можно сказать, что планирование происходит на протяжении всего проекта.
Dyba выделил достоинства и недостатки внедрения гибких методов. Поскольку реализовать изменения в Agile быстрее и дешевле, однако размывается понимание достижения желаемых выгод, потому что неясно какой будет результат. Для успешного внедрения гибких методов организация должна понимать основные цели нововведения и подходят ли им эти методы. Большинство проблем, возникающих в гибких проектах, обусловлено тем, что организации не понимают основных целей гибкости. Некоторые организации считают, что использование гибких методов сокращает время и затраты проекта, но это не всегда там. Для многих организаций гибкость требует значительных изменений организационной культуры и процессов, которые нельзя осуществить одним лишь внедрением гибкой методики. Что в свою очередь выливается в огромные внутренние затраты на изменение.
Сначала рассмотрим недостатки процесса внедрения гибких методов управления проектами.
Неэффективная реализация гибких методов обычно осуществляются проектными группами, желающими сразу же взяться за производство продукта, обходясь без составления многочисленных документаций. Они убеждают своих линейных руководителей в выгодах, но не разъясняют выгоды коммерческим потребителям или членам других производственных групп. В результате формируется плохая коммуникация, и участие важнейших коммерческих пользователей отсутствует. Члены проектной группы работают независимо, то есть самостоятельно, в отличие от совместного производства продукта для клиента в комплекте [Dyba, 2008, p. 841]. Процессы гибкой методики (например, совещания для информирования о состоянии дел, графики прогресса разработки и митинг) выполняются ежедневно, но главные проблемы остаются нерешенными.
Некорректное использование гибких методов обусловлено желанием фирмы сократить расходы, сроки и документооборот. Организация не придерживается полностью ценностей Agile. Вкладываются средства в коммуникацию и обучение, но игнорируются инструменты и техники, необходимые для обеспечения гибкости. Формируются группы специалистов разного профиля, но им не разрешается принимать ключевые решения на консультациях с ключевыми заинтересованными лицами и потребителями [Dyba, 2008, p. 842].
Последний недостаток гибких методов заключается в том, что проводятся регулярные проверки проекта на каждой интеракции, но полностью, на основании полученных результатов, команда не устраняет ограничения проекта, и главные проблемы остаются. Проект сдается заказчику, но опыт получается отрицательным, и в последующих проектах уже не используется. То есть накопленные знания для дальнейшей работы над другими проектами не будут использоваться [Dyba, 2008, p. 842].
Теперь рассмотри положительные стороны внедрения гибких методов.
Успешно внедренные гибкие методы являются результатом сотрудничества фирмы и отдела ИТ, удовлетворяющее потребностям организации [Dyba, 2008, p. 845]. Такое изменение вкладывается в организационные изменения, требуемые для получения выгод.
Заинтересованные лица, потребители, члены группы и высшее руководство обучаются, и формируется сбалансированная группа специалистов разного профиля. Вкладываются средства в инструменты и техники, требуемые для поддержки гибкой методики (стандарты, непрерывная компоновка, разработка на основе тестирования, парное программирование и т.д.) с целью создания платформы для дальнейших проектов [Dyba, 2008, p. 845].
Регулярные проверки проекта рассматриваются как возможности для улучшения, а не как точку контроля. Изменение принимается и планируется, поэтому, когда появляются изменения, то легко воспринимаются участниками проекта. Правильно организованный процесс внедрения долгосрочных изменений приносит дополнительную выгоду [Dyba, 2008, p. 846].
Хорошая реализация гибкой концепции является трудной задачей для любой организации. Она требует внутренних изменений подхода к проектной деятельности. Она подвергает сомнению традиционную структуру «руководитель - группа» и основывается на решениях немногих уполномоченных людей, в отличие от большого комитета. Она требует от проектных групп постоянно акцентировать внимание на своих ошибках и совместно работать над их устранением [Dyba, 2008, p. 847].
Гибкие методы обеспечивают повторяющуюся, своевременную и качественную сдачу проекта, приоритет которой определяется на основе реальной потребности рынка. Agile формирует высокомотивированных, многофункциональных и уполномоченных людей, сосредоточенных на достижении общей цели [Dyba, 2008, p. 848]. Они создают базу для долгосрочной успешной сдачи проектов путем разработке стандартов, постоянной интеграции, разработки на основе тестирования и объединение разработок продукта.
Таким образом, гибкие методы требуют не только готовность персонала принять изменения, но и серьезных организационных изменений. Из сравнения традиционных и гибких методов видно, что внедрение Agile повлечет за собой организационные изменения и обучение необходимыми навыками менеджера проекта и команды. Также не каждая компания готова нести большие издержки по внедрению гибких методов и переобучению персонала. Однако не все инструменты Agile методов могут быть использованы в организации. Организации могут быть иметь различную сферу деятельности, размер, рынок, структуру и другие особенности. Поэтому не все инструменты из гибких методов управления проектами могут быть применены в конкретной организации.
2.2 Особенности управления проектами в ИТ-компаниях на российском рынке
Каждая сфера имеет свои особенности ведения проектами. Это зависит от степени конкуренции на рынке, скорости изменений рынка, степень вмешательства государства в отношения между организациями, также зависит от барьеров входа на рынок и возможности создания альянсов на рынке. Таким образом, можно выделить основные черты проектной деятельности на рынке информационных технологий в России. Поскольку исследование будет проводиться на российском рынке, то имеет смысл оговорить это фактор. Не секрет, что российские компании пытаются сэкономить на предпроектной деятельности. Многие заказчики не готовы оплачивать работу аналитиков на подготовку функционального и программного технического задания. Поскольку заказчик ориентируется на функционал своего будущего продукта, а исполнители начинают создавать продукт на основании программного технического задания, потому что они черпают необходимую техническую информацию именно из этого документа [Управление ИТ -проектами…, 2014]. И только отдел тестирования сопоставляет функционал, описанный в техническом задании, с тестируемой функцией. Однако из-за отсутствия или неполного технического задания могут возникнуть ошибки или неверное исполнение задачи. Что в свою очередь увеличивает временные и денежные затраты. Также на экономии предпроектной деятельности многие компании не прописывают риски проекта, что в последующем вырастает в конфликт между исполнителем и заказчиком. Проблему многие решают внутри проекта. Но иногда конфликт решается только в судебном порядке, что естественно приводит к негативному отношению между сторонами. По мнению многих менеджеров проектов, недостаточное внимание к проекту на предпроектном этапе, приводит на последующих этапах к таким негативным последствиям, как срыв сроков окончания фазы проекта или всего проекта в целом, увеличение изначально запланированного бюджета, привлечение в процессе работы над проектом дополнительных ресурсов или передача на аутсорсинг часть разработки продукта, чтобы уложиться в срок [Колесов К., 2013, c. 272]. Также в российской практике встречается, что заказчик чрезмерно администрирует деятельность команды. Это связано с тем, что нет единой системы работы менеджера проекта, команды и заказчика. Некоторые компании интуитивно понимают, что необходимо применять еженедельные встречи команды проекта с заказчиком, другие понимают что нужно стандартизировать разработку продукта и поделить на более мелкие задачи [Борисов и др., 2014, с. 625]. Однако бывает, что компания соединяет несколько методологий по ведению проекта.
ИТ проекты отличают от других проектов, тем что в проекте могут участвовать и государственные и частные компании в роли заинтересованных лиц или заказчиков. Бывают проекты, которые выполняются несколькими организациями и весь проект поделен на части, где команда выполняет свою часть и не имеет понятия, чем занимается другая команда и кому вообще заказчик передал этот функционал. Если в проекте участвует государство, то ТИ-компания должна следовать определенным регламентам по разработке продукта. Такая формализация может увеличить время и затраты выполнения задач. Также в государственных компаниях уделяют большое внимание соответствию ГОСТам [Воропаев В., 2014, c. 98].
Также ошибка, выявленная во время разработки проекта и его последующего представления пользователю, становится известна всем участникам проекта. Поскольку может произойти неверное исполнение функции в продукте или отключение сервера. Такую ошибку увидит любой человек, который в данный момент пользовался продуктом. Таким образом скрыть ошибку или исправить ее, не вызывая всеобщего внимания, очень сложно [Ципес Г.б 2006, с. 236].
Особое внимая следует уделить бюджетной части ИТ проектов. Если рассматривать крупные проекты, то менеджер несет ответственность за огромные суммы. И небольшая ошибка в управлении или разработке может увеличить бюджет в разы. Поэтому менеджер постоянно контролирует и мониторить проект. Он должен понимать все стадии проекта и видеть дальнейшее его развитие, чтобы вовремя сообщить о предстоящих проблемах [Миславская Е., 2010, c. 3].
Часто ИТ проекты реализуются удаленно, команда может быть собрана из разных точек мира. Менеджер владеет соответствующими знаниями и умениями. Поскольку ему необходимо не только мониторить и контролировать ход проекта, но и мотивировать сотрудников на удаленной работе. Вовремя сообщать о предстоящей работе. А самое главное в таких проектах уметь просчитать все возможные риски. Риски в данном случае связаны не только с изменением требований, а с тем, что удаленные работники могут отказаться от выполнения работ или выполнить некачественно. Менеджер в таком случае находит замену работнику в максимально короткие сроки [Пигалов В., 2011, с. 64].
Из вышеописанной особенности вытекает еще одна особенность ИТ проектов - организация коммуникаций. Как было описано, что работы проекта могут быть выполнены силами других компаний на аутсорсинге, но еще и удаленно. В таком случае члены команды могут общаться на разных языках в силу географического расположения членов команд. Например, создание дизайна бизнес приложения могут разрабатывать в России, а его разработку осуществляется силами иностранных программистов. Но бывает, что члены команды находятся в разных регионах России, но понятийный аппарат у них разный. Могут возникнуть конфликты внутри команды, поскольку работники говорят об одном и том же, но разными словами [Уланов С., 2011, с 645].
Также одной из особенностей ИТ проектов является то фактор, что основная деятельность основала на человеческих ресурсах. Поскольку разработку технического задания осуществляется аналитиком, а код программы пишет программист, только характеристики машины необходимы для того, чтобы разработанный продукт работал. Поэтому основным ресурсом является человеческий капитал [Кузнецов А., 2011, с. 206].
Возникают сложности в передачи знаний и сохранении его внутри компаний. В России еще недостаточно разработаны нормативные документы по защите интеллектуальных прав или информационных ресурсов. Поэтому компаниям сложно отстоять свои права на ИТ рынке. Но также среди компаний ведется борьба за разработчиков с опытом. Потому что такие работники принесут не только новые идеи, но и поднимет статус самой компании из-за новых разработок [Мыльников Л., 2011, с. 2]. Сам рынок ИТ еще не до конца развит и в нем все больше появляются новые идеи. Разработчики постоянно изучают новые методы разработки и новые специализированные программные продукты. Многие разработчики изучают смежные сферы программирования, чтобы понимать разработку продукта от его самого начала и сдачи заказчику.
2.3 Разработка алгоритма выбора гибкой методологии в определенных условиях реализации проекта
Руководители проектов научились допускать гибкость в своих методологиях управления проектами. В частности, многие исследования показали, что большинство успешных проектов, которые следовали Agile принципам, доказывая при этом, что методы, основанные на моделях, не всегда являются наилучшими, в частности, при управлении изменениями, срочной реализации проекта или даже удовлетворении потребностей рынка.
Но до того как начать внедрять гибкие методы, стоит расммотреть как эти методы влияют на процесс, продукт и людей.
Влияние на процесс
Процессы имеют второстепенное значение в случае с гибкими методами. Быстрые и короткие итерации двигают проект вперед, тем самым позволяя получить высокий уровень гибкости при изменении курса проекта. Более того, вместо многочисленной документаций, диктуемых требованиями и планами, большая часть документации заключается в обмене информацией между членами команды. Разработка плана и конечный продукт зачастую подвергаются изменениям до этапа выпуска [Yusuf Y. et al, 2014, p. 545].
Влияние на продукт и его качество
Высшим приоритетом является удовлетворение потребностей клиента с предоставлением простой, но работающей версии продукта. Продукт улучшается с каждой итерацией до того момента, как вся желаемая функциональность будет там, где она должна быть. Простота предоставляет больше гибкости при запросах к изменению, особенно потому, что пользователи и спонсоры со временем выдвигают новые требования [Zhang Z., 2000, p. 495].
Влияние на людей
Ключевой принцип гибкой разработки - люди и их способность к общению важнее процессов и инструментов - делает акцент на общении и сотрудничестве членов проектной команды . Руководитель делает акцент на то, насколько хорошо участники проекта смогут выполнить задачи. Командная работа не может быть переоценена при гибком процессе, так как каждый член может быть частью группы пользователей, менеджеров и разработчиков. Для того, чтобы действительно добиться успеха, менеджер проектов должен разрешать членам команды быть причастными к различным процессам разработки продукта, спокойно общаться и концентрироваться на целях команды [Kerth N., 2001, p. 57].
Хотя изначально было установлено, что гибкие методы дают лучшие результаты тогда, когда команды находятся рядом, опыт аутсорсинговых провайдеров показал, что и в их бизнесе нашлось применение данным методам, например, в случае с оффшорными аутсоринговыми моделями [Narasimhan, 2006, p. 440]. Где нормой является сотрудничество и доступное общение, а не дислокация места работы.
Сотрудничество в Agile относится к непосредственному и частному взаимодействию команд.
Yves L. Doz и Kosonen Mikko выделили в своем исследовании, что команда в гибких методах действует по принципу «As One». Авторы провели исследование включив различные компании, в выборку вошли 12 компаний. Они выделили 4 правила в своем исследовании, которым должен придерживаться менеджер проекта в рамках «As One» [Yves et al., 2010, p. 370].
Убедиться, что все заинтересованные лица, участвующие в проектах привержены к Agile подходу.
Таким образом, каждый понимает вклад в проект. А другие заинтересованные лица, которые не принимают прямое участие, могу осуществлять функцию контроля.
Выявить приверженцев Agile среди менеджеров высшего уровня.
Это позволяет внедрять гибкие методы в верхних уровнях. И формализует процесс перехода на гибкое управление проектами.
Убедиться, что в команду входят сотрудники с опытом в Agile.
Эта практика подчеркивает важность включения в команду тех, кто имеет опытом в применении Agile. Хотя обучение является неотъемлемой частью гибких методов, практический опыт помогает членам команды узнать и отрегулировать сложные вопросы. Также обучить гибким методам менеджеров без опыта Agile.
Создать небольшие функциональные команды.
Команда может формироваться от 7 до18 человек. Однако внутри могут формироваться функциональные группы. Команда не должна чрезмерно полагаться на навыки одного работника.
Данные особенности внедрения будут использованы в составлении рекомендация для каждого инструмента гибкого управления. Проанализированные сферы влияния гибкого управления будут включены в критерии готовности принять компанией данную методологию. Что в последующем поможет создать алгоритм выбора инструментов гибкого управления для ИТ проектов. Однако, как и было сказано выше, каждый проект имеет свои особенности.
Сложно выбрать из многообразия инструментов именно тот, который подойдет для проекта. Каждый проект уникален, и трудно описать все многообразие проектов. Однако, чтобы начать применять тот или иной инструмент гибкого управления, необходимо понять - готова ли компания работать в гибкой системе. На основе принципов и влияния Agile на организацию были разработаны основные критерии готовности организации принять дынную методологию.
Степень формализации - параметр включает в себя бюрократию в проекте. Если в проекте необходимо заполнять большое количество бумаг, выполнять различное множество регламентов, то проект меньше подходит для гибкого управления.
Степень сложности внесения изменений - если рынок быстро изменяется и компания может принимать такие быстрые решения по изменениям разработки продукта, то можно считать, что проект принимает принцип гибкого управления.
Системное решение проблем - команда применяет специальные методы решения проблем или есть показатели по выбору решения, то такие действия относятся к Agile.
Степень коллективной ответственности - имеется в виду, что команда принимает участие на всех этапах проекта и есть прозрачность в организации проектной деятельности.
Гибкие методы еще зависят от менеджера проекта, команды и типа проекта, то есть, как организован процесс, и какой будет продукт.
Как отмечает Mittal S. разработчики делятся на тех, кто использует традиционные методы и на тех, кто предпочитает гибкие методы. Вторые ориентированы на применение продвинутых технологий, чтобы исследовать и предоставить как можно быстрее продукт [Mittal, 2011, p. 159]. То есть менеджеры используют либо гибкие методы управления проектами, либо традиционные.
Kniberg H. Отметил что для Scrum-команды необходима кросс-функциональная команда, состоящая из специалистов разных профилей. В этом случае команда является полностью ответственной за результаты проекта и никто, кроме команды не может вмешаться в процесс разработки [Kniberg H., 2009]. Кроме того Gibson и Smilor отметили, что ИT проект является сложным, трудным процессом, даже если это происходит в разных функциях в рамках одной организации, а проблемы усиливаются, когда границы организации пересекаются. Кроме того, системы электронного управления являются гетерогенными, состоит из ряда дисциплин и большого количества подсистем для сбора, хранения и передачи данных [Gibson D. et al., 1992, p. 41]. Для инструментов Kanban и Crystal характерны узкопрофильные команды или интактные. Поскольку эти инструменты предполагают работу специалистов. Другие инструменты не предполагают какие либо требования к команде проекта. Однако для Scrum характерна работа команды вместе с пользователями над проектом и свободные от других проектов. Когда ХР позволяет членам команды работать над разными проектами и не требует вовлеченности пользователей. Инструмент Kanban тоже, как и Crystal, не требует вовлеченности пользователей. Однако метод Crystal позволяет быстро адаптировать инструмент под определенную команду, но при этом инструмент требует высокой определенности будущего проекта. В DSDM и Driven Development команда проекта принимает все важные решения самостоятельно, пользователь вовлечен в проект и члены команды не работают над другими проектами. Но в Driven Development требуют большие усилия для внедрения изменений, поскольку этот метод сильно нагружен бумажной работой, по сравнению с другими Agile методами.
Стоит сказать о том, что ИТ-компании разделяют проекты на внешние и внутренние, а внешние разделяют еще на два типа: где компания является подрядчиком и субподрядчиком. Разберем каждый тип проекта по отдельности. Если проект организуется внутри компании, то самое необходимое, что нужно знать о команде, работает ли команда над одним проектом или несколькими. Поскольку если команда работает над одним внутренним проектом, то правильней всего использовать инструмент Kanban. А если команда проекта задействована над несколькими проектами, то в таком случае необходимо использовать инструмент Scrum. Scrum позволит членам команды работать над разными задачами и быстро переключатся между проектами.
Внешние проекты разделяются на выполнение работ по договору подряда или субподряда. Для компании это разные виды работ и соответственно разные типы команд. Работы выполняемые по договору подряда предполагают длительные взаимоотношения между сторонами и стороны отвечают за все процессы, которые есть в проекте от начальной фазы до последней. В то время как договор субподряда предполагает, что компания выполняет часть работ по проекту и отвечает только за отдельную часть в проекте, а основную ответственность несет на себе другой участник проекта.
Сначала разберем проекты по договору подряда. И первым что необходимо определить это включенность команды в другие проекты. Если команда выполняет работы и в других проектах, то следует выбирать между методом ХР или Scrum, решающим фактором будет готовность команды к масштабным изменениям бизнес-процессов. Если команда готова к таким изменениям, то необходимо использовать метод Scrum, а если нет, то ХР.
Если команда проекта работает над одним проектом по договору подряда, то следующим шагом для менеджера необходимо понимает насколько четкий и подробный план проекта. Если проект имеет подробное техническое задание с прописанными функциональными и техническими подробностями, то логичнее всего использовать метод DSDM, Driven Development. Но DSDM можно применять, если команда проекта уполномочена возможность принимать важные решения самостоятельно. В случае если нет четкого плана проекта и техническое задание описано только на функциональном уровне, то следует применить инструмент Scrum.
Следующий тип проекта, это когда команда выполняет работы по субподряду. В этом случае играет важную роль вовлеченность пользователей в проект, поскольку от этого зависит самостоятельность команды и ее скорость выполнения работ. Если пользователь вовлечен в проект и команде на субподряде необходимо взаимодействовать с ним, то самым оптимальным вариантом будет инструмент Scrum, поскольку будут встречи с потребителем и четкое понимание, когда начинается работа команды и когда она заканчивается, при этом не мешая другим командам в проекте. Если в проекте пользователь не взаимодействует с командой, то необходимо понимать есть ли четкое задание для команды проекта или оно описано уровне идеи и не разработано до мелочей. Если имеется четкий план действий, при этом работы будут выполняться в короткий срок, то эффективнее всего использовать инструмент Сrystal, поскольку он имеет возможность быстро адаптировать методологию под команду. Но в противном случае применяется метод ХР.
Дерево решений алгоритма можно увидеть на рисунке 10, где во-первых, необходимо узнать владеет ли менеджер проекта инструментами Agile. Потому что ему необходимо организовывать команду и быть примером для подражания для всей команды. Если менеджер не владеет инструментами, то ему необходимо изучить их или найти другие методы управления проектом.
Если менеджер знает инструменты Agile, то следующим для него заданием будет определить тип проекта: внешний или внутренний. При варианте внутренний проект, остается определить возможности команды. Команда полностью погружена в один внутренний проект, то наиболее подходящим инструментом будет Kanban с его карточной системой. Но команда проекта может выполнять несколько проектов, то в этом случае менеджеру следует организовать работу команды по методике Scrum. Деление на более мелкие задачи и еженедельные встречи позволит контролировать работу команды на нескольких проектов, и быстро внести изменения в проект.
Другой вариант, проект внешний. В данном случае может быть два выбора: проект по договору подряда или субподряда. Имеется в виду, что команда выполняет требования заказчика по договору подряда и полностью ответственна за выполнение всего проекта. А по договору субподряда, команда выполняет часть функций по проекту другой команды, то есть другая команда передала некоторые свои работы на аутсорсинг. Если тип проекта внешний по договору подряда, то остается определить сколько проектов у команды: несколько - инструмент Scrum, один - необходимо определить область влияния команды. В случае, когда команда может принимать важные решения, необходимо использовать инструмент DSDM, в противоположном случае инструмент Driven Development.
По договору субподряда пользователь-заказчик может быть вовлечен в процесс реализации функции, наилучшим вариантом будет Scrum. Если пользователь не принимает участи в реализации функции, то необходимо определить команда работает по четкому плану. То есть команде предоставили полный план действий и техническое задание для реализации функции. В такой ситуации менеджер наилучшим вариантом будет организовать работу команды по методологии Crystal. В противоположной ситуации использовать инструмент ХР.
На основании сравнительного анализа гибких и традиционных методов, который помог определить особенности влияния методов Agile на организацию и команду. В связи с тем, что ИТ-компании часто выполняют разного рода работы, проектные и текущие бизнес-процессы. Команда достаточно гибкая, как и сама компания. Однако постоянные разработки в области ИТ усложняют работу команды в проекте. Заказчик часто меняет свои требования или у проекта нет четного плана, поскольку проект является инновационным.
Менеджер проектов должен успевать за всеми изменениями и стараться просчитывать последующие шаги команды. Но забота менеджера заключается не только в быстроизменяющейся среде проекта, но и в каких условиях работает сама команда. Поскольку бывают проекты в которых команда выполняет только часть работ по проекту, следующие работы выполняет другая команда. Но и в таком случае бывает, что требования к выполненным работам поменялись, и менеджер должен это учитывать и в такой ситуации. Таким образом, были проанализированы наиболее типичные особенности проектов и проведен их анализ. Из анализа были выделены основные типы проектов в зависимости от того, какие работы выполняет команда проекта. Таким образом, удалось соотнести инструменты Agile и особенности проектов в ИТ-компаниях.
Сам алгоритм предназначен для ИТ-компаний, которые хотят перейти на гибкое управление проектами. Алгоритм предназначен для подбора инструмента гибкого управления в зависимости от условий, в которых работает команда. В алгоритме включены типы проектов, команд и самих заказчиков.
Глава 3. Применение алгоритма определения гибкой методологии управления проектами на примере ИТ-компаний Пермского края
3.1 Описание выборки
На момент написания работы тестирование прошли 3 компании с полным циклом. Полный цикл разработки продукта в ИТ-компаниях понимается, что компания разрабатывает продукт заказчику и внедряет его. Внедрение может быть выполнено несколькими способами: внедрение на территории заказчика; обучение на территории исполнителя; разработка специальных инструкций, установщиков, обучение одного из заказчиков, чтобы он обучил своих пользователей самостоятельно. Тестирование прошли две компании конкуренты, которые занимаются разработкой продуктов для бизнеса или интернет заказы. Они получили одинаковый результат, поскольку имеют одинаковую организацию команд и работают на одном ИТ-рынке. Последняя компания занимается разработкой компьютерных игр. Данная компания получила в конце теста другой ответ - Kanban. Поскольку занимается внутренними проектами и получает основную кастомизацию от покупок платных продуктов в игре.
Все тестируемые компании по окончанию первого опроса о готовности компании принять гибкое управление склонялись к положительному ответу, это показано на рисунках 11,12,13. Корреспонденты по шкале от -5 до 5 отмечали степень формализации, сложности внесения изменений, системности принятия решения и коллективной ответственности
Рис. 11 Решение компании Геликон Про о готовности принять гибкое управление
Рис. 12 Решение компании Прогноз о готовности принять гибкое управление
Рис. 13 Решение компании Wargaming о готовности принять гибкое управление
У всех компаний степень формализации на уровне заполнения необходимых для работы документов: техническое задание; договор, акты между заказчиком и исполнителем; промежуточное фиксирование выполненных задач во внутренней системе отчетности. Команды проекта могли изменять набор необходимых документов в проекте в зависимости от ситуации. Каждая команда может внести изменения в продукт в зависимости от требований заказчика или рынка, при этом потратив минимум усилий. Это обосновано тем, что в команде работают профессионалы и готовы применять новые методы по оптимизации работы или продукта. В каждой компании проблемы решались либо мозговым штурмом, либо совещанием между команды проекта и заинтересованными лицами. Каждая компания отвечает критерию коллективной ответственности. Поскольку все проекты ведутся открыто для команды проект, каждый ее член может рассказать о проекте и степени разработанности продукта.
Все компании частично использовали гибкое управление, поскольку максимально хотели отвечать на вызовы рынка и заказчика. Например, компания Геликон Про и Прогноз устраивают еженедельные собрания по 15 минут среди менеджеров проектов и начальниками отделов, чтобы установить приоритеты на работы и ресурсы компании, обсуждаются проблемы с нехваткой ресурсов и перераспределение работников на другие из-за того что он свободен или не сможет выполнить работу. В компании Wargaming имеют собственную внутреннею систему отчетности, в которой можно поставить приоритет задачи или ее статус у каждого из работников. Тем самым менеджер может отслеживать в режиме online ход проекта. Каждая из компаний пытается оптимизировать свой продукт или найти решения по его улучшению. В каждой компании есть отдел тестирования, где проверяет функциональная и программная проверка продукта. Также эти отделы вносят свои предложения по улучшению функционала или новые решения в сам функционал.
Однако данный алгоритм применим не ко всем компаниям ИТ отрасли и имеет несколько ограничений:
Алгоритм предназначен только для компаний работающих в ИТ сфере. Поскольку исследование было направлено на сферу информационных технологий и рассмотрены особенности именно на особенности данного рынка. Другие сферы тоже могут использовать гибкое управление проектами, но они имеют другие характеристики и особенности.
Типы проектов построены на основе ИТ проектах по отношению к самой команде. Это относится к проектам по договору подряда и субподряда. Другие компании могут использовать аутсорсинг, который противоположен данной точке зрения. Также понимание внутренних и внешних проектов может быть различно в проектах разных сфер деятельности. Поэтому следует понимать, что данный алгоритм направлен на возможности и ограничения самой команды проекта. В каких условиях будет работать команда. У команды могут быть ограничения по договору субподряда или полное вовлечение во внутренний проект компании. Другие исследователи могут рассмотреть данный вопрос с другой точки зрения.
Стоит отметить, что алгоритм предназначен для организаций, которые готовы принять гибкое управление, и имеют определенные характеристики для необходимости внедрения инструментов Agile. Если организация готова реагировать на быстроизменяющуюся окружающую среду, вся команда несет ответственность за разработку продукта, имеются у команды навыки системного решения проблем, бюрократия не на высоком уровне, то организация может применить гибкое управление в проекте. Но не стоит забывать, что внедрение нового в организацию влечет за собой какие-либо затраты - временные, финансовые и другие, к которым менеджер и руководство должно быть готовым.
3.2 Применение алгоритма на практике
На основании алгоритма был создан тест, по окончанию которого были даны рекомендации для каждого инструмента. Тест состоит из простых вопросов, которые требуют выбор одного ответа из двух противоположностей. Рекомендации включали в себя название инструмента и первоначальных действий, которые необходимо сделать, чтобы команда могла работать с выбранным инструментом. Были предложены следующие рекомендации.
Scrum
Организуйте работу в небольшой кроссфункциональной команде, которая содержит всех необходимых специалистов для вашего проекта. Выделите scrum-мастера, который будет отвечать за соблюдение процессов в команде и конструктивную атмосферу. Требования разбейте на небольшие части, ориентированные на пользователей или функции, которые максимально независимы друг от друга, в результате чего получите беклог продукта. Затем элементы беклога проранжируйте по приоритетам и произведите относительную оценку объемов каждого. Выделите отдельного человека - владельца продукта, который будет отвечать за требования и их приоритеты, с которым будут взаимодействовать все заинтересованные лица. Всю работу ведите короткими (от 1 до 4 недель) фиксированными итерациями - спринтами, представляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок. Команда согласно своей скорости и ограничениям набирает задачи на неизменяемую по времени итерацию. Каждый день проводится scrum-митинг по 15 минут, на котором команда синхронизирует свою работу и обсуждает проблемы, появившиеся во время работы. В процессе работы члены команды берут в работу элементы беклога согласно приоритету. В конце каждого спринта проводите обзор встреч, чтобы получить обратную связь от владельца продукта, и дальнейшее развитие спринта, чтобы оптимизировать Ваши процессы. После этого владелец продукта может изменить требования и их приоритеты и запустить новый спринт.
XP
ХР или экстремальное программирование заключается в постоянной интеграции, то есть постоянное тестирование. Метод заключает в том, что команде проекта дают первоначальные требования заказчика, а команда проекта разрабатывает и планирует самостоятельно, опираясь на свой опыт и предыдущие практики. Данный метод основан на опыте и знаниях членов команды. Поэтому необходимо сформировать команду из квалифицированных работников, которая сможет работать слажено вместе. Менеджеру проекта необходимо постоянно мониторить ход проекта. ХР включает в себя частое тестирование продукта проекта и в конце каждого тестирования пишется отчет. Таким образом, продукт постоянно улучшается. Данный метод требует интенсивной работы членов команды и часто функции выполняются попарно разными членами проекта - попарное программирование.
Crystal
Это легковесная гибкая методология, которая предназначена для небольших команд в 6-8 человек. Как и все гибкие методологии Crystal больше опирается на людей, чем на процессы и артефакты, поэтому методику можно изменять и подстраивать под Вашу команду проекта. Crystal использует семь методов:
1. Частая поставка продукта заказчику
2. Улучшения продукта через рефлексию членов команды
3. Личные коммуникации команды и заинтересованных лиц
4. Чувство безопасности - проверка продукта внутри команды
5. Фокусировка на четкий план проекта, где видны точки критичности разработки
6. Простой доступ к экспертам
7. Качественное техническое окружение - заранее приготовлены автотесты для продукта
Dynamic Systems Development Method
Методология DSDM основана на подходе RAD (Rapid Application Development). Самая последняя версия DSDM называется DSDM Atern, о которой можно узнать из любого другого источника.
Существует 9 принципов DSDM, которым необходимо следовать в Вашем проекте [Вольфсон, 2012, c. 12].
Вовлечение пользователя - это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.
Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством.
Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей.
Главный критерий - как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.
Разработка - итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.
Любые изменения во время разработки - обратимы.
Требования устанавливаются на высоком уровне прежде, чем начнётся проект.
Тестирование интегрировано в жизненный цикл разработки.
Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.
Чтобы успешно использовать DSDM, необходимо чтобы был выполнен ряд предпосылок. «Во-первых, необходимо организовать взаимодействие между проектной командой, будущими пользователями и высшим руководством. Во-вторых, должна присутствовать возможность разбиения проекта на меньшие части, что позволит использовать итеративный подход» [Вольфсон, 2012, c. 13]. DSDM состоит из трёх последовательных стадий: предпроектная стадия, стадия жизненного цикла проекта и постпроектная стадия. Стадия жизненного цикла проекта - самая продуманная и детально разработанная из всех остальных. Она состоит из пяти этапов, которые формируют итеративный, гибкий подход к разработке продукта.
Driven Development
Основной целью данной методологии является разработка работающего программного продукта по его функциям.
Разработка ведется в пять этапов:
1. Построение модели
2. Создание списка функций
3. Планирование реализации функций
4. Создание архитектуры для функций
5. Реализация функций
Первые два процесса относятся к началу проекта. Последние три осуществляются для каждой функции. Разработчики в FDD делятся на «хозяев классов» и «главных программистов». Главные программисты привлекают хозяев классов к работе над очередным свойством. Работа над проектом предполагает частые сборки и делится на итерации, каждая из которых предполагает реализацию определенного набора функций.
Kanban
Метод управления разработкой, реализующий на основе японского принципа «точно в срок» и способствующий равномерному распределению нагрузки между работниками. При данном подходе, весь процесс разработки прозрачен для всех членов Вашей команды. Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу.
Kanban является наглядной системой разработки, которая показывает, что необходимо производить, когда и сколько.
Метод требует от команды соответствующего уровня самоорганизации и дисциплины:
1. Визуализируйте производственный процесс. Для этого обычно используют доску, размеченную по этапам работы над задачей. Конечно, более продвинутым вариантом будет использовать плазму/проектор, и выводить туда состояние проекта.
1. Ограничивайте количество незавершенной работы (WIP, Work In Progress). У каждого столбца-состояния команда указывает максимальное количество задач, которые могут в нем находиться. Таким образом, минимизируется переключение между задачами и связанные с этим потери при производстве.
2. Оптимизируйте процесс. Необходимо отслеживать среднее время задачи и уменьшать его.
Но не стоит забывать про жизненный цикл команды. Поскольку при формировании команды могут возникнуть барьеры, описанные в предыдущей главе: новая команда, привычка к роли, привычка к документации, проблемы с общением, давление со сроками, проблемы с менеджментом, проблемы с некомандным поведением, креативность и оценка времени.
3.3 Оценка эффективности внедрения гибкого управления в компанию Геликон Про
По результатам тестирования для команды компании Геликон подходит инструмент Scrum, потому что команда выполняет несколько проектов одновременно и чаще всего это внешние проекты. В компании есть свои внутренние задачи или внеплановые работы, которые заказчик просит выполнить как можно раньше. Чаще всего такие работы связаны с ошибками продукта у заказчика, с внедрением новой функции в продукт либо у заказчика и компании договор сопровождения продукта, где исполнитель обязуется выполнять определенный перечень работ на время действия договора. Из-за этого менеджер проектов старается расписать работы на каждую неделю, обговаривая занятость каждого ресурса с другими менеджерами проектов. Совещание по планированию работ занимают 10-20 минут, на них обсуждаются организационные моменты, нагрузка на работников, возможные риски и другие вопросы.
Также для компании Прогноз по результатам тестирования был ответ Scrum. Команда компании Прогноз тоже выполняет несколько проектов одновременно и срочные заказы по сопровождению продукта. В компании есть внутренняя система постановки и отслеживания задач. Прогноз является компанией конкурентом для Геликон. Они могут выполнять одинаковые работы по ИТ-разработкам и команды по проектами имеют одинаковые навыки. Компании поделили рынок Пермского края по своим возможностям и загруженности работников. Понимая, что весь рынок захватить будет очень сложно, в Перми находится около 70 ИТ-компаний и 130 тысячи компаний являются их потенциальными клиентами. Только 3% из них являются клиентами Прогноз, 2% клиентами Геликон. Обе компании работают не только на пермском рынке, но и участвуют в тендерах других городов.
Подобные документы
Стратегическое значение современных методов и средств управления проектами. Характеристика основных методов управления проектами. Фазы жизненного цикла проекта. Фаза разработки коммерческого предложения. Формальное и детальное планирование проекта.
контрольная работа [30,3 K], добавлен 04.02.2010Усовершенствование процессов управления проектами нефтегазовой отрасли Азербайджана. Управление проектами и процессный подход при бурении нефтяных скважин. Разработка рекомендаций по усовершенствованию процессов управления проектом "Азери-Чираг-Гюнешли".
дипломная работа [2,9 M], добавлен 25.09.2013Сущность и актуальность управления проектами. Методы исследования и обоснования инвестиций в проекте. Управление рисками и стоимостью проекта. Организация финансирования проекта, торги и контракты. Планирование и формы структуры управления проектами.
реферат [57,0 K], добавлен 14.02.2011Принципы построения организационных структур управления проектами. Организационная структура и система взаимоотношений участников проекта. Современные методы и средства организационного моделирования проектов. Современный и традиционный инструментарий.
курсовая работа [692,2 K], добавлен 27.05.2014Управление проектами как средство эффективного развития объектов управления. Обязанности владельца и менеджера проекта. Признаки и вероятные причины его плохого исполнения. Возможные пути совершенствования. Эффект влияния проекта на организацию.
контрольная работа [867,7 K], добавлен 20.06.2009Анализ отличительных особенностей управления проектами MSF. Интеграция и синхронизация планов проекта. Организация процедур, систем управления и мониторинга проектных изменений. Планирование ресурсов, формирование проектной команды, разрешение конфликтов.
презентация [974,1 K], добавлен 25.05.2014Общие принципы построения организационных структур управления проектами. Связи между должностями и структурными подразделениями. Система взаимоотношений участников проекта. Взаимодействие функциональной структуры с проектными при помощи посредников.
презентация [828,8 K], добавлен 25.06.2015Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.
дипломная работа [2,4 M], добавлен 20.08.2017Проекты, реализуемые в различных областях и разными специалистами. Жизненный цикл проекта. Основные функции и подсистемы управления проектами. Организационные структуры управления проектом. Обоснование целей проекта и способов их удовлетворения.
курсовая работа [1,3 M], добавлен 20.09.2013Определение понятия "проект". Характеристики проекта как объекта управления. Функции управления проектами. Список компетенций менеджера программного проекта. Выработка концепции реализации проекта, ее апробация и экспертиза. Жизненный цикл проекта.
презентация [104,7 K], добавлен 14.08.2013
