Проблемы управления IT-проектами на крупном предприятии и пути их решения

Аннотация. В настоящее время развитая система управления проектами является одним из важнейших факторов конкурентоспособности любого предприятия. В данной статье рассматриваются проблемы управления IT-проектами на одном из крупных предприятий России и возможность решения их с помощью гибкой методологии управления проектами Scrum. В статье раскрыты понятия «IT-проект» и «управление проектами». Проведен анализ IT-проектов предприятия и системы управления ими. Также проведено сравнение гибких методологий Scrum и Kanban. Обоснованы причины и приведены результаты внедрения методологии Scrum на рассматриваемом предприятии.

Ключевые слова: IT-проект, управление проектами, гибкие методологии управления проектами, каскадная методология, Scrum, Kanban.

В настоящее время роль информационных технологий в мире неоспоримо велика. Любое современное предприятие в той или иной степени использует их в своей деятельности. Понятие «информационные технологии» тесно связано с понятием «IT-проект», так как IT-проект – это «целенаправленная деятельность временного характера» [1], в рамках которой создаются или используются некоторые информационные технологии. Реализация IT-проектов на предприятии является необходимым условием для его эффективного развития.

IT-проекты, как и любые другие проекты, нуждаются в тщательном управлении. Под управлением проектами подразумевается «приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту» [3]. Развитая система управления проектами является одним из важнейших факторов конкурентоспособности предприятия.

В качестве объекта исследования было выбрано одно крупных предприятий России. На рассматриваемом предприятии реализуются IT-проекты двух типов: глобальные, которые затрагивают все предприятие в целом (например, внедрение системы электронного документооборота) и локальные, в реализации которых задействованы только отдел-исполнитель и отдел-заказчик (например, разработка программы для проведения инженерных расчетов). Для проектов обоих типов применяется традиционная каскадная модель управления IT-проектами: проект разбивается на последовательность фаз (определение требований, проектирование, реализация, тестирование, внедрение, поддержка), каждая из которых начинается после успешного завершения предыдущей фазы [5].

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

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

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

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

Среди причин неудачной реализации можно выделить следующие:

· заказчик не может четко сформулировать цель IT-проекта и меняет свои пожелания в процессе реализации проекта;

· управление IT-проектами осуществляется не менеджерами проектов, а руководителями структурных подразделений, которые в основном имеют техническое образование и не повышали свою квалификацию в области управления проектами;

· низкий уровень коммуникации заказчика и исполнителя;

· проблемы с финансированием;

· проблемы с определением сроков реализации IT-проекта;

· неудачно сформированная команда IT-проекта;

· отсутствие современного программного обеспечения для управления IT-проектами.

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

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

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

· возможность получения результатов только в конце проекта. Часто случается, что при использовании каскадной модели управления IT-проектами приводит к тому, что заказчик получает продукт, который не соответствует его ожиданиям.

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

На сегодняшний момент многие признанные мировые компании отдают предпочтение гибким методологиям управления IT-проектами (Agile-методологиям). Главными ценностями гибких методологий являются:

·      люди и их взаимодействие, а не процессы и инструменты;

·      готовый продукт, а не документация по нему;

·      сотрудничество с заказчиком, а не жесткие контрактные ограничения;

·      реакция на изменения, а не строгое следование плану [6].

Для рассмотрения возможности внедрения гибкой методологии управления IT-проектами были выбраны две популярные методологии: Scrum и Kanban.

Scrum – это гибкая методология, в основе которой лежит итерационный подход планирования и выполнения проекта. IT-проект делится на равные спринты (Sprint). Оптимальная продолжительность спринта от 2 недель до месяца. В начале каждого спринта команда проекта формирует список задач (Sprint Backlog), которые необходимо выполнить. Задачи спринта выделяются из общего списка задач проекта (Product Backlog). В процессе работы над каждым спринтом команда проводит ежедневные короткие встречи, на которых обсуждаются результаты, планы и проблемы. Контроль встреч проводится скрам-мастером (Scrum Master). Реализация задач спринта осуществляется командой общими усилиями, то есть команда многопрофильная. После завершения очередного спринта у команды готова рабочая версия продукта с некоторым функционалом, которая может быть передана заказчику или владельцу продукта (Product Owner). Каждый спринт завершается обсуждением возможностей оптимизации работы для улучшения работы в новом спринте [4].

Kanban – это также гибкая итерационная методология. Kanban предполагает визуализацию структуры процесса разработки на реальной или виртуальной доске (Kanban в переводе с китайского – «видимая доска»). Доска разделяется на столбцы, например, «в планах», «разработка», «тестирование», «релиз», «готово». Для реализации проекта выделяются отдельные задания, помещаемые в начале в столбец «в планах». Карточки с заданиями по мере готовности перемещаются между столбцами доски. За каждой карточкой закрепляется человек, занимающийся разработкой. Команда проекта – узкопрофильная, но могут быть многопрофильные команды. Методология Kanban является довольно демократичной, предоставляя разработчикам практически полную свободу [2].

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

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

· Kanban-команда должна обладать высочайшим уровнем самоорганизации, чего добиться от команды, ранее работавшей по каскадной методологии, будет проблематично;

· команды разработчиков предприятия многопрофильные;

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

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

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

Результатами использования методологии Scrum IT-отделом рассматриваемого предприятия в течение года стали:

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

· увеличение скорости разработки;

· повышение командного духа внутри отдела;

· повышение самоорганизации команды;

· стремление следовать за лидерами отдела со стороны менее квалифицированных членов команды;

· налаженная коммуникация с заказчиками;

· повышение степени удовлетворенности заказчиков, что положительно сказалось на имидже отдела и количестве новых IT-проектов;

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

· частый выпуск промежуточных релизов;

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

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