XII Международная студенческая научная конференция Студенческий научный форум - 2020

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

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

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

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

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

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

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

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

Компании, в которых разработка программного продукта ведется для собственных нужд (так называемая «in-house»-разработка), выбирают один из двух вышеописанных подходов. Если потребности будущих пользователей программного продукта понятны и требования сформулированы, то удобнее выбрать структуру руководитель проекта + команда. Если же требования не сформулированы и внутренняя разработка осуществляется как стартап, то целесообразно использовать структуру с менеджером продукта.

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

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

Р исунок 1. Диаграмма Исикавы, отображающая причины нарушения обязательств по ИТ-проекту.

Источниками проблем ИТ-проектов, которые могут привести к нарушению обязательств разработчиков, могут являться:

• руководитель проекта;

• команда;

• заказчик (внешний заказчик в случае заказной разработки, внутренний заказчик в случае in-house разработки, пользователи в случае стартапа);

• внешняя среда.

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

К причинам со стороны внешней среды можно отнести:

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

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

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

К причинам со стороны заказчика можно отнести:

завышенные ожидания и отсутствие критериев удовлетворенности продуктом;

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

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

К причинам со стороны команды можно отнести:

ошибки при оценке сроков выполнения задач.

В свою очередь, причинами ошибок в сроках является:

высокий уровень неопределенности требований на ранних этапах проекта;

уникальность задач, характерная для ИТ-проектов;

неоправданный оптимизм разработчиков, не учитывающих негативные сценарии;

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

отсутствие готовности к изменениям проекта в ходе работы.

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

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

отсутствие навыков управления рисками;

отсутствие влияния на реалистичность ожиданий заказчика;

отсутствие управления изменениями;

недостаток коммуникаций с командой;

ошибки при оценке ресурсов.

Для управления проблемами, связанными с руководством проекта, рекомендуется повышение квалификации руководителя проекта. Например, изучение и применение им «Свода знаний по управлению проектами» (англ. Project Management Body Of Knowledge), являющегося признанным стандартом по управлению проектами и содержащим описание десяти областей знаний, которыми должен владеть руководитель проекта.

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

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

Автор выражает благодарность доценту кафедры прикладной информатики и информационных технологий НИУ «БелГУ», к.т.н. В. И. Ломазовой за научное руководство выполнением данной работы.

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

1. Ломазов В.А., Ломазова В.И., Нехотина В.С. ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ ПРИ ОЦЕНИВАНИИ ИТ-ПРОЕКТОВ//Международный журнал прикладных и фундаментальных исследований. 2015. № 3-2. С. 170-173.

2. К. Геворкян Чем отличается продакт-менеджер от проджект-менеджера [Электронный ресурс] URL https://netology.ru/blog/product-or-project (дата обращения: 15.01.2020).

3. Николаенко В.С. Разработка принципов управления ИТ-проектом // Вестник Томского государственного университета. 2015. № 390. с. 155-160. DOI 10.17223/15617793/390/27.

4. А. Орлов Матрица доверия и прозрачности [Электронный ресурс] URL https://stratoplan.ru/blog/management-tools-reports (дата обращения: 15.01.2020).

5. М.В. Бахиркин, A.С. Зинченко, А.П. Кирпичников, В.Н. Лукин, Д.П. Ткаченко Модель динамической оценки стоимостных, временных и функциональных показателей процесса проектирования и разработки программ и программных систем // Вестник Казанского технологического университета. 2014. 19 том 17 с. 284-289

Код для цитирования: Скопировать