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