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

Оригинал опубликован вот здесь.

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

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

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

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

—  исполнитель тратит больше ресурсов на согласования и отчетность, чем на саму разработку

—  система создана, соответствует ТЗ, но почему-то не востребована пользователями

—  работы завершены, но после приемки остались шероховатости, которые нужно как-то устранять.

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

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

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

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

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

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

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

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

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

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

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

2.Испытания

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

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

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

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

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

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

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

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

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

3.Обучение

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

Что важно учитывать.

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

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

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

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

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

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

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

4.Внедрение

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

Положение — это организационно-распорядительный документ, который определяет:

—  назначение системы (для автоматизации каких процессов предназначена)

—  задачи и функции системы (для ведения каких реестров/регистров используется, какие госуслуги/госфункции покрывает и прочее)

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

—  структуру системы (архитектура, программное и аппаратное обеспечение, структура подсистем/модулей)

—  характеристики информации (срок хранения, технологии хранения, порядок защиты информации, типы — общедоступная, ДСП, гостайна и др.)

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

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

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

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

«Исполнитель должен разработать проект Регламента работы сотрудников ведомства в Системе и проект Положения о Системе. Проект Положения о Системе должен включать описание следующих пунктов: ...»

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

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

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

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

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

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

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