Программные продукты и системы

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

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

-      формирование единого понимания всеми участниками проекта его целей и задач;

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

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

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

-      возможность контроля исполнения основных показателей проекта (сроков, бюджета и качества проекта);

-      достижение запланированных результатов в установленные сроки и в рамках выделенного бюджета.

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

В данной статье описана функциональная модель взаимодействия участников проекта «Электронное правительство» (ЭП) в Челябинской области: компании «ЛАНИТ-Урал» и Южно-Ураль­ского государственного университета (ЮУрГУ) с использованием свободно распространяемой системы управления проектами Redmine.

Особенности проекта

Проект ЭП, являющийся частью Федеральной целевой программы «Информационное общество», направлен на реализацию такого способа взаимодействия заявителя с органами государственной власти (федеральными, региональными и органами местного самоуправления), при котором в случае отсутствия необходимости личного присутствия и бумажного документооборота процедуры сбора сведений, подготовки и принятия решений с целью оказания государственных услуг основываются на удаленном электронном взаимодействии, то есть с использованием средств информационно-коммуникационных технологий [8].

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

1. Большое количество участников и заинтере­сованных сторон проекта (на примере Челябин­ской области):

-      заказчик – Министерство информационных технологий и связи области;

-      функциональный заказчик – региональные органы исполнительной власти (РОИВ) и органы местного самоуправления (ОМСУ);

-      генеральный подрядчик и единый оператор инфраструктуры ЭП – ОАО «Ростелеком»;

-      агент по внедрению;

-      разработчики ведомственных информационных систем – 12 компаний;

-      разработчик программной инфраструктуры;

-      правительство области;

-      неправительственные организации, регулирующие внедрение ЭП на федеральном (20) и региональном (5) уровнях.

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

-      роли заказчика и функционального заказчика выполняются различными государственными учреждениями;

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

-      сложная схема договорных отношений;

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

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

4. Нереалистичные ожидания заказчика и регу­лярные изменения требований со стороны функ­циональных заказчиков.

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

Технологический цикл производства продукта

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

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

1. Анализ и дизайн – обследование процесса и регламентов оказания государственной услуги, определение требований к автоматизированной системе, разработка технических решений на из­менение формы Единого портала государствен­ных и муниципальных услуг (ЕПГУ) и на межве­домственное взаимодействие в рамках оказания данной услуги. Участники со стороны исполни­теля работ – руководитель проекта, аналитик, архитектор.

2. Реализация автоматизированной системы – разработка вэб-формы для ЕПГУ, настройка про­цесса оказания услуги в Системе исполнения рег­ламентов (СИР), разработка сервисов, выполня­ющих обмен данными между ведомственными информационными системами и Единой системой межведомственного электронного взаимодействия (СМЭВ). Реализацию сервисов в ведомственных информационных системах выполняют, как правило, разработчики этих систем. Участники со стороны исполнителя работ – руководитель проекта, аналитик, архитектор, программист, тестировщик.

3. Интеграционное тестирование – прогон и отладка всего процесса оказания государственной услуги совместно с Функциональным заказчиком и устранение замечаний. Участники со стороны исполнителя работ – руководитель проекта, аналитик, программист, тестировщик.

4. Внедрение – регистрация сервисов в СМЭВ, вывод разработанных вэб-форм на ЕПГУ, разработка технической документации и обучение пользователей работе с системой. Участники со стороны исполнителя работ – руководитель проекта, аналитик, программист, тренер.

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

Анализируя данную ситуацию, руководством проекта было принято решение упорядочить и систематизировать работу путем регламентации основных процессов, а также внедрения и активного использования системы управления проектами. За методологическую основу был взят подход, описанный в своде знаний по управлению проектами PMI PMBoK [10].

В силу большого количества участников проекта одной из первых задач, которую предстояло решить, было выявление и выстраивание коммуникаций между заинтересованными сторонами проекта. В результате была сформирована орга- низационная структура проекта с четким рас- пределением ответственности и полномочий для различных его участников (см. рис.). Другая важнейшая задача – регламентация и стандартизация жизненного цикла разработки программного обеспечения для автоматизации процессов оказания государственных услуг, что позволило ясно увидеть потребности в ресурсах на весь срок про- екта. Именно эти мероприятия дали возможность выявить риск нехватки ресурсов в определенные моменты времени реализации проекта, что обусловило начало сотрудничества между ЛАНИТ-Урал и ЮУрГУ. Разработанный типовой план реализации услуги с четким указанием задач, последовательности их выполнения, ответственных лиц и ожидаемого результата позволил однозначно распределить функции между группами разработки.

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

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

В результате анализа рынка существующих автоматизированных систем управления проектами и задачами была выбрана система Redmine, являющаяся открытым серверным приложением для управления проектами, создания и ведения задач, распространяемым согласно GNU General Public License.

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

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

Центральным объектом системы является задача. Для проекта ЭП было заведено несколько типов задач соответственно жизненному циклу реализации ПО, описанному выше: аналитика, разработка новых услуг, исправление ошибок, улучшение и внесение изменений, техническая поддержка.

Каждая задача характеризуется следующими признаками:

-      статус (в работе, доработка, тестирование, закрыта временно, закрыта, ожидание информации, отклонена);

-      приоритет (низкий, нормальный, высокий, срочный, немедленный);

-      дата начала;

-      дата окончания;

-      плановая дата;

-      затраченное время;

-      назначена (Ф.И.О. сотрудника, исполня­ющего данную задачу).

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

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

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

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

-      отклонение в точности планирования сроков снизилось с 15–20 % на момент, предшествующий внедрению проектного управления, до 7 % в течение полугода после внедрения изменений;

-      отклонение по стоимости – с 20–30 % до 7 %;

-      отклонение качества – с 3–5 % до 4 %;

-      отклонение содержания – с 5 % до 2 %;

-      доля верно спрогнозированных рисков – с 75 % до 80 %.

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

Литература

1. Коровкина Н.Л., Трушкина Е.П. Разработка модели количественной оценки уровня зрелости управления ИТ-проектами // Бизнес-информатика. 2010. № 4 (14). С. 12–20.

2. Арчибальд Р. Управление высокотехнологичными программами и проектами; [пер. с англ. Е.В. Мамонтова; под ред. А.Д. Баженова, А.О. Арефьева]. 3-е изд. М.: Комп. АйТи; ДМК Пресс, 2010. 464 с.

3. Абмлер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста; [пер. с англ. Л. Каллиникова]. СПб: Питер, 2005. 412 с.

4. Павлова В.А., Тимофеева М.В. Использование информационных технологий в управлении проектами. Research Journ. of Intern. Studies. 2013. № 7–3. С. 49.

5. Климов Б.А., Романов Д.Ю. Анализ систем документооборота в проектах по разработке программного обеспечения // Бизнес-информатика. 2010. № 2 (12). С. 15–23.

6. Марон A.И., Марон М.А. Информационный подход к организации контроля проектов // Бизнес-информатика. 2012. № 4 (22). С. 54–60.

7. Сурыгина И.Ю. Эффективность использования информационных систем управления бизнес-проектами // Электротехнические и информационные комплексы. 2008. № 1. С. 66–76.

8. Системный проект формирования в Российской Федерации инфраструктуры Электронного правительства. Технологический портал. URL: http://smev.gosuslugi.ru/portal/api/files/get/ 652 (дата обращения: 01.09.2013).

9. Боев А.Е. Применение принципов проектного управления при реализации проекта «Электронное правительство». Опыт «ЛАНИТ-Урал». URL: http://www.mininform74.ru/Files/ DiskFile/Forum%20IO%202012/%D0%91%D0%BE%D0%B5%D0%B2%20%D0%B4%D0%BE%D0%BA%D0%BB%D0%B0%D0%B4%20%D0%9B%D0%A3.pdf (дата обращения: 20.01.2014).

10. Даве В., Кестел Д. и др. Руководство к своду знаний по управлению проектами (Руководство PMBOK); [пер. с англ.]. 5-е изд. М.: Моск. отдел. PMI, 2013. 614 c.