При реализации ИТ-проектов в госсекторе в первую очередь используется ГОСТ серии 34, который учитывает специфику и особенности деятельности государственных органов разных уровней, позволяет четко планировать последовательность работ. Документ не заслуживал бы «камешка в свой огород», если бы не ряд проектов в области разработки программного обеспечения и информатизации госучреждений. Соблюдать ГОСТовские требования при выполнении таких проектов – значит ставить палки в колеса тому, кто берется за их реализацию, и неэффективно расходовать бюджетные средства.
Предписанная ГОСТом жесткая модель реализации (планирование, проектирование, подготовка документации, реализация, внедрение) не подходит для краткосрочных проектов, разработки ИТ-инструментов и систем по заказу госучреждений в условиях динамично меняющегося законодательства. Зачастую по ходу реализации проекта, создания программного обеспечения приходится вносить существенные изменения в первоначальный план, что возможно при использовании гибких методологий, в частности Agile.
Напомним, процесс разработки программного обеспечения по методике Agile предусматривает серию коротких циклов работ, так называемых итераций. Их продолжительность, как правило, не превышает двух недель. Каждая итерация – проект в миниатюре. При соблюдении того же порядка действий (планирование, анализ требований, проектирование, кодирование, тестирование и документирование), но на коротком временном отрезке, удается свести к минимуму возможные риски. По завершении каждой итерации заказчик и исполнитель пересматривают приоритеты дальнейшей работы.
В процессе проектирования ИТ-системы обычно выясняется, в каких ее функциях действительно заинтересован заказчик, а в каких потребность отсутствует либо перестанет существовать, как только изменится нормативная база. Кроме того, регулярное общение по ходу проекта заказчика и исполнителя – один из принципов гибких методик – позволяет если не отказаться от письменной документации, то значительно уменьшить ее объем, что также имеет большое значение для рационального расходования средств и ресурсов.
Применима ли такая методология при реализации ИТ-проектов в госсекторе? Ответ на этот вопрос искали участники конференции «Гибкие методики при реализации госпроектов», организованной Аналитическим центром при Правительстве Российской Федерации. Представители компаний, которые внедряют такие методики, и госучреждений, имеющих опыт их использования, анализировали проблемы, препятствующие переходу на гибкие методологии в госсекторе.
По словам одного из участников конференции, государство выступает в роли неквалифицированного заказчика, для которого главная головная боль – управление рисками. Боясь получить не то, что требуется, защищаясь от рисков, чиновники вводят предварительные этапы работы и «бумажные» процедуры, прежде чем перейти собственно к разработке ИТ-системы. Победа в конкурсе на выполнение проекта для госструктуры нередко оборачивается большой головной болью уже для исполнителя работ. Если для сотрудников компании-исполнителя важно создать продукт, то для представителей госорганов – сдать контракт, сопроводив работу над ним тоннами документации (всегда будет что показать руководству и проверяющим).
Что же делать? Для поиска алгоритма решения проблемы и выработки предложений относительно судьбы гибких методик в рамках реализации проектов по заказу госорганов организаторы конференции применили метод мозгового штурма. Участники мероприятия, объединенные в тематические мини-группы, спорили, предлагали и отвергали идеи, а модераторы каждой дискуссионной группы по ходу фиксировали интеллектуальные находки, способные посодействовать продвижению современных методик в госсекторе.
Общими усилиями был составлен перечень предложений. В частности, в контракты на разработку программного обеспечения по заказу госорганов нужно внести изменения. Ответственность за исполнение проекта должна быть обоюдной. Выбранная методология ведения проекта должна стать одним из существенных условий контракта, как и обязанность заказчика предложить группу экспертов. При этом у исполнителя должно быть право требовать смены экспертов в случае необходимости. Как мотивировать экспертов к участию в проекте? В качестве радикальной меры в ходе дискуссии предлагалось финансово поощрять экспертов, совмещающих основные и факультативные обязанности (сумма вознаграждения должна быть фиксированной).
Другой вариант – ввести персональную ответственность экспертов за результаты проекта, разместить их фото на портале госоргана. Еще один способ мотивации – система стимулирующих показателей с учетом роли каждого эксперта в реализации проекта. Кстати, такой подход действует в Белгородской области в рамках системы проектного управления. Муниципальный служащий может стать членом проектной команды и при успешном совмещении обязанностей с основной деятельностью рассчитывать на премиальное вознаграждение. Это лишь некоторые предложения, которые, по мнению участников дискуссии, помогут повысить эффективность реализации проектов по заказу госорганов.
Для продвижения гибких методик при реализации госпроектов необходимо разработать методические рекомендации. Примерно два десятка экспертов – участников сессии мозгового штурма – изъявили желание продолжать работу в этом направлении и оставили свои контакты для связи организаторам дискуссии и конференции. Вслед за методическими рекомендациями возможно появление нового стандарта. При этом у госзаказчиков должна быть возможность выбора методологии реализации проекта. Предстоит серия мероприятий, в ходе которых все заинтересованные стороны получат возможность представить свои точки зрения по данному вопросу. Если задуманное удастся реализовать, можно надеяться, что эффективность расходования бюджетных средств на информатизацию в госсекторе существенно повысится.
