Готовим ТЗ на госсистему: 5 практических советов

Разработка автоматизированных информационных систем регламентируется ГОСТами (в первую очередь 19 и 34) и множеством нормативных правовых актов. На государственные информационные системы всегда распространяются более строгие требования. О них много написано в открытых источниках, поэтому в данной статье мы дадим несколько практических советов. Мы рассмотрим этапы работ, когда на первый план выходит организация совместной работы заказчика и исполнителя.

Рекомендации будут полезны в первую очередь представителям ИТ-подразделений органов власти, которые занимаются подготовкой технических заданий (ТЗ). Они применимы ко всем классам государственных информационных систем – сайтам, электронному документообороту, межведомственному взаимодействию, системам оказания госуслуг, реестровым системам и пр.

Написание хорошо продуманного ТЗ - непростая задача (фото - nextgov.com)

Непродуманное ТЗ может привести к тому, что:

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

Далее мы разберем, что нужно закладывать в ТЗ, чтобы не попасть в похожие ситуации. В рекомендациях мы будем учитывать сложные ситуации, когда в силу тех или иных причин заказчик и исполнитель ограничены в ресурсах. Пример типовой сложной ситуации: заказчик в течение полугода согласовывал мероприятие по развитию системы с Минкомсвязи России, затем еще месяц согласовывал документацию внутри своего ведомства, затем - публикация конкурса, подведение результатов, заключение государственного контракта. На исполнение работ осталось 2-3 месяца, а то и менее. А это конец года, когда приближаются дедлайны по всем проектам. Витрина данных НОТА ВИЗОР для налогового мониторинга 2.1 т

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

На собственном опыте и опыте коллег по цеху мы расскажем о рисках, связанных с непродуманными требованиями. Мы исполнили множество разных ТЗ и рекомендации по конкретным формулировкам взяты из лучших практик государственных заказчиков.

Согласования

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

Пункт о том, что заказчик согласовывает отчет, означает необходимость визы ответственного лица на титульном листе или листа согласования внутри отчета с подписями различных сторон. Сразу возникает много вопросов: «кого ставить?», «почему именно я должен согласовывать эти документы?» и других.

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

В случае, если заказчиком является ИТ-подразделение, а пользователями системы – профильные структурные подразделения, это повлечет необходимость и в их визах на таких документах. А собрать их сложно, если учесть все бюрократические процедуры, отсутствие нужных сотрудников из-за отпусков или командировок, нежелание сотрудников ставить свои визы на непонятной технической документации. К тому же, в условиях жестких дедлайнов, особенно в конце года, заказчик просто не в силах обеспечить нужные согласования в срок. Это может поставить весь проект «на паузу».

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

Используйте следующие формулировки для включения в ТЗ:

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

• Исполнитель за 5 рабочих дней до окончания соответствующих этапов направляет на адрес электронной почты заказчика, указанный в договоре, промежуточные версии отчетов.
• В случае поступления от заказчика замечаний и рекомендаций по их доработке, исполнитель вносит соответствующие корректировки и учитывает данные замечания и рекомендации в итоговых версиях отчетов.

Испытания

Испытания – один из наиболее важных этапов работ по созданию или развитию системы. Он позволяет проверить ее на соответствие ТЗ и получить обратную связь от пользователей перед ее внедрением (вводом в промышленную эксплуатацию). Согласно ГОСТу есть 3 вида испытаний – предварительные, опытная эксплуатация и приемочные испытания. В идеале на все эти испытания нужно от 1,5 месяцев и более, в зависимости от масштаба работ. Вспоминаем типовую сложную ситуацию, описанную выше. Что же делать?

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

В ситуации с короткими сроками мы рекомендуем исключать предварительные испытания. В самых критичных ситуациях можно оставлять только проведение приемочных испытаний, хотя это противоречит ГОСТу. Если на такой приемке вы столкнетесь с продуктом, в котором множество изъянов, то остается возможность назначить проведение повторных приемочных испытаний, к моменту которых исполнитель должен устранить выявленные на первичной приемке несоответствия. Здесь самое главное - грамотно рассчитать сроки, которые отводятся на приемочные испытания в ТЗ, чтобы при необходимости уложить в них и повторные.

Успех испытаний во многом зависит от программы и методики испытаний (ПМИ). Мы рекомендуем формулировать ТЗ таким образом, чтобы каждое требование можно было включить как отдельный пункт в ПМИ, проверить его путем демонстрации. Избегайте субъективных или абстрактных формулировок: например, «Система должна обеспечивать удобные для пользователя интерфейсы». Здесь возникает вопрос, что понимать под удобством. Думайте о том, как исполнитель будет вам показывать реализацию этих требований. Это поможет избежать лишних споров внутри и вопросов о качестве и объеме выполненных работ согласно ТЗ у проверяющих органов.

Мы рекомендуем использовать следующие формулировки для включения в ТЗ:

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

Мы НЕ рекомендуем формулировать требования следующим образом:

Дизайн интерфейса должен содержать минимально необходимое количество графических элементов и обеспечивать как можно большую скорость загрузки

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

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

-(не указаны, какие типовые задачи должны быть автоматизированы)

Какое решение здесь уместно: например, добавить в текст ТЗ конкретные требования или дать возможность определить эти требования на этапе технического проектирования:

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

Обучение

Обучение обычно проводится на этапе опытной эксплуатации. Зачастую заказчик и исполнитель организовывают процесс полномасштабного обучения работе в новой или доработанной системе позже, когда прошли приемочные испытания, а на этапе опытной эксплуатации испытывают систему на ограниченном круге пользователей. Такая организация преследует одну единственную цель – снизить нагрузку на ответственных сотрудников, не использовать их как подопытных кроликов и не мешать им работать, пока идет процесс ввода системы в действие.

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

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

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

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

Следование данным рекомендациям поможет осуществить безболезненное внедрение системы, минимизировать отторжение сотрудниками нового формата работы.

Однако не стоит использовать слово «обучение» в тексте ТЗ. Создание и развитие государственных информационных систем проходит по 242 виду расходов. Обучение – это иной вид расходов (244). Вместо этого используйте понятия «консультации», можете конкретизировать какие – очные или дистанционные.

Мы рекомендуем использовать следующие формулировки для включения в ТЗ:

Исполнитель должен провести консультации сотрудников по работе с системой. Во время проведения консультаций представитель исполнителя должен рассказать содержательный материал и ответить на вопросы пользователей системы. По итогам проведения консультаций исполнитель должен предоставить отчет.

Внедрение

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

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

Регламент – это, скорее, рабочий документ, который должен быть как «инструкция для пилота». Именно в нем распределяются зоны ответственности, устанавливаются требования к последовательности и результатам деятельности, срокам. Например, устанавливается порядок обработки в системе заявлений, поступивших в ведомство в электронном или бумажном виде, порядок ведения реестров, порядок отправки запросов в СМЭВ или обработки полученных запросов и т.д. Регламент должен быть небольшим (5-10 страниц) и максимально простым.

Требование о разработке проекта положения было бы странно включать в ТЗ, поскольку это работа чиновников, но помощь исполнителя при его подготовке все же нужна. Поэтому мы рекомендуем прописать эту работу в ТЗ обтекаемо, например, назвать такой документ «Описанием системы». А разработку проекта регламента можно спокойно переложить на плечи исполнителя как часть работ по эксплуатационной документации.

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

Используйте следующие формулировки для включения в ТЗ:

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

Гарантия качества

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

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

Мы рекомендуем использовать следующую формулировку для включения в ТЗ:

Гарантийный срок выполненных работ (оказанных услуг) составляет не менее 12 (двенадцати) месяцев. Указанный срок исчисляется со дня подписания Заказчиком акта сдачи-приемки выполненных работ (оказанных услуг). Если в период гарантийного срока обнаружатся дефекты или недостатки выполненных исполнителем работ (оказанных услуг), то исполнитель обязан их устранить своими силами и за свой счет, в возможно короткие сроки. Гарантийный срок в этом случае продлевается соответственно на период устранения дефектов, недостатков.

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