Копаев Г.В.

эксперт (на момент выполнения проекта – сотрудник компании-подрядчика)

Для получения качественного результата в проекте по разработке информационной системы важна качественная работа всех участников. Эта прописная истина соблюдается далеко не всегда. Одна из причин – отсутствие правильной методологии исполнения работ. Для ИТ-компании подрядчика (внешнего или внутреннего) существует ряд подходов – waterfall, agile, scrum, множество инструментов управления проектом. А вот методика работы заказчика, особенно государственного, обсуждается мало. По окончании реализации одного из государственных проектов по созданию информационной системы, назовём её «Надзор», удалось познакомиться с методологией управления SEMAT (Software Engineering Method and Theory, Метод и теория разработки программного обеспечения). В результате возникла идея описать указанный проект в соответствии с теорией, акцентируя внимание на специфику госсектора. По мере возможности методология переводилась в технологию – даны таблицы для заполнения, указана последовательность действий руководителя проекта со стороны заказчика. При этом типовое содержание работ, знакомое каждому руководителю проекта, намеренно пропускалось, материал и так получился обширным.

1. Формализованное описание проекта

Наименование проекта – выполнение работ по созданию системы «Надзор».

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

Срок исполнения проекта – 3 месяца!

2. Методология

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

При знакомстве с методологией использовались следующие источники:

https://essence.ivarjacobson.com/sites/default/files/field_iji_file/article/essenceofsoftwareengineering.pdf;
http://sewiki.ru/SEMAT – русскоязычное описание подхода, с уклоном для применения в инженерных системах;
ESSENCE User Guide (http://semat.org/essence-user-guide) – есть хорошие определения, которые помогают понять идею технологии;
https://essence.ivarjacobson.com/sites/default/files/field_iji_file/article/essence_pocket_guide_0.pdf – хороший материал, краткая выжимка для тех, что чуть-чуть разобрался;
Essence – Kernel and Language for Software Engineering Methods, Version 1.2 (http://semat.org/documents/20181/57862/formal-18-10-02.pdf/866c80c0-cdc8-488b-bcf8-0c67cb60b5d7) – подробное описание методологии.

Пояснение. В исходной методологии есть несколько значимых пробелов. Первый из них – название методологии! В указанных документах мы не нашли названия! Есть намёк на название SEMAT (Software Engineering Method and Theory, Метод и теория разработки программного обеспечения), но это, скорее общее направление мысли. Тем не менее было принято решение использовать его, применяя в тексте синоним «рассматриваемая название методология», «методология разработки программного обеспечения».

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

1.1 Альфы

Выделяются следующие Альфы (т.е. сущности, за которыми мы следим):

Стейкхолдеры.
Возможности.
Определение системы.
Программная система (Воплощение системы).
Команда.
Работа.
Технология.

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

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

Возможности, Обстоятельства, Условия (Opportunity) – обстоятельства, которые делают возможным разработку системы. Если в коммерческом секторе основной драйвер связан с заработком и / или экономией заказчика, то в государстве – это общественная польза. В данном проекте ключевое обстоятельство, запустившее проект в эти сроки, с конкретным уклоном – это требования законодательства по автоматизации контрольно-надзорной деятельности и давление Минцифры России по соблюдению данных требований. Отметим, что автор не раз сталкивался с ситуацией, когда нормативное требование существует, но отсутствие контроля (давления) за исполнением нормативных требований не способствует запуску проектов. Название «возможность» путало даже автора данной статьи, поэтому будем параллельно с ним использовать термины «обстоятельства» и «условия».

Определение системы (Requirements) – описание системы. На привычном нам языке это документы – Концепция, Техническое задание, Частные технические задания, рабочая документация.

Программная система, Воплощение системы (Software System) – система, состоящая из программного обеспечения, аппаратного обеспечения и данных.

Команда (Team) – группа людей с необходимыми компетенциями, активно участвующих в разработке, обслуживании, поставке или поддержке конкретной программной системы. Термин «Команда» используется в двух ипостасях: менеджеры – «Управленческая команда» (руководитель проекта со стороны ДИТ, ключевой эксперт со стороны Службы и руководитель от Компании-разработчика) и все специалисты, задействованные в проекте, – «Команда». Команда, как и другие отслеживаемые сущности эволюционирует в ходе проекта.

Работа (Work) – собственно работа над проектом.

Технология, Способ работы (Way-of-Working) – набор практик и инструментов, используемых командой для руководства и поддержки своей работы.

Взаимодействие компонент можно посмотреть на рисунке 8: Figure 8.2 – The Kernel Alphas (http://semat.org/documents/20181/57862/formal-18-10-02.pdf/866c80c0-cdc8-488b-bcf8-0c67cb60b5d7) и на рисунке по адресу http://sewiki.ru/Категория:Альфы.

1.2 Этапы проекта

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

Таблица 1 Перечень этапов

№	Этап	Результирующие документы
1	Идея	Аналитическая записка, презентация, концепция
2	Замысел
2.1.	Разработка требований	Техническое задание (ТЗ)
2.2	Определение стоимости контракта	НМЦК (начальная (максимальная) цена контракта)
2.3	Конкурсные процедуры	Договор с победителем конкурса
3	Проектирование	ЧТЗ
4	Изготовление	ПМИ, рабочая документация
5	Разворачивание	Акт ввода в эксплуатацию
6	Эксплуатация
7	Вывод из эксплуатации

Пояснения. Этап «Understand the Requirements» (Понимание требований) рассматриваемой методологии разделён на два – «Идея» и «Замысел». Такое разбиение кажется более технологичным. Раскрытие этапа «Замысел» на подэтапы «Разработка требований», «Определение стоимости контракта» и «Конкурсные процедуры» используется только в данной таблице для привязки к процедурам контрактования по 44ФЗ и 223 ФЗ.

1.3 Ключевая идея

Для ознакомления с проектом мы будем проходить описание Альф для каждого этапа проекта. Визуализация распределения Альф по календарному плану и отношение их между собой представлено в Таблице 2 (с учётом требований ГОСТов, требований законов о закупках).

Таблица 2 Наложение Альф на план выполнения проекта

	Стейкхолдеры	Возможности (условия)	Определение системы (документы)	Программная система (Воплощение системы)	Команда	Работа	Технология
Идея	3.1.1. Определить стейкхолдеров	3.1.2. Выявить условия реализации проекта	3.1.2. Разработать Концепцию	3.1.4. Выявить критерии выбора архитектуры	3.1.5 Наметить состав команды	3.1.6 Инициировать работу	3.1.7 Определить технологии управления
Замысел	3.2.1 Назначить представителей Стейкхолдеров	3.2.2 Проверить возможность реализации каждой потребности каждого стейкхолдера	3.2.3 Описать границы системы	3.2.4 Оценить предлагаемую систему	3.2.5 Доформировать команду	3.2.6 Сформировать уточнённый календарный план	3.2.7 Зафиксировать технологии взаимодействия
Проектирование	3.3.1 Вовлечь стейкхолдеров	3.3.2 Установить пользу (ценность) решения и критерии успеха	3.3.3 Согласовать определение системы (ЧТЗ)	3.3.4 Оценить предлагаемую систему	3.3.5 Выявлять и уменьшать потраченную впустую работу команды	3.3.6 Отслеживать ход работ	3.3.7 Внедрить технологии взаимодействия
Изготовление	3.4.1 Контроль согласия стейкхолдеров с создаваемой системой	3.4.2 Контролировать соответствие создаваемой системы исходным предпосылкам	3.4.3 Убедиться, что описания системы приемлемы	3.4.4 Контролировать, что система пригодна для использования	3.4.5 Выявлять и уменьшать потраченную впустую работу команды	3.4.6 Контролировать прогресс работы	3.4.7 Отслеживать используемые технологии
Разворачивание	3.5.1 Контролировать удовлетворённость стейкхолдеров готовностью системы для разворачивания	3.5.2 Контролировать полезность системы	3.5.3 Контролировать качество документации для эксплуатации	3.5.4 Проверить готовность системы	3.5.5 Способствовать подключению новых членов команды	3.5.6 Контролировать перенос системы в среду заказчика и начало эксплуатации	3.5.7 Использовать технологии передачи системы в эксплуатацию
Эксплуатация	3.6.1 Отследить удовлетворенность стейкхолдеров использованием системы	3.6.2 Проконтролировать получение выгоды	3.6.3 Отслеживать и компенсировать недостаточность документации	3.6.4 Контролировать согласованный уровень использования	3.6.5 Трансформировать команду	3.6.6 Поставить технологию технической поддержки	3.6.7 Зафиксировать окончание работы по созданию системы
Вывод из эксплуатации	3.7.1 Проверить, что стейкхолдеры согласны с выводом системы из эксплуатации	3.7.2 Проверить, что условия существования системы закончились	3.7.3 Создавать документы по системе не требуется	3.7.4 Снять программную систему с поддержки	3.7.5 Полностью высвободить команду	3.7.6 Зафиксировать окончание работ	3.7.7 Сформулировать и зафиксировать уроки

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

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

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

2. Описание проекта

Повторюсь, что в рассматриваемом проекте SEMAT не использовался, но в качестве иллюстрации методологию будет полезно рассмотреть на живом примере.

2.1 Этап «Идея»

2.1.1 Определить стейкхолдеров

Напомним, Стейкхолдер – это заинтересованные стороны (человек или организация), чьи действия или решения могут влиять на успешность создания системы.

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

Предварительное условие – идея системы возникла, она обсуждена двумя-тремя руководителями. Принято решение оформить разговор в текст.

Согласно методологии на начальном этапе необходимо достичь следующих результатов по стейкхолдерам:

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

(В кавычки здесь и далее будем ставить перевод текста методологии с минимальным собственным уточнением).

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

В данном проекте выделяются следующие стейкхолдеры (роли даны согласно http://sewiki.ru/Стейкхолдер):

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

Влияющие стейкхолдеры:

Пользователь (Внешние пользователи) – контролируемые организации. Непосредственно в проекте они не участвовали, их требования к системе моделировались на основе нормативной базы – отраслевого кодекса и требований «Электронного правительства» (авторизация по ЕСИА, использование электронной подписи, минимальный объём сдаваемых документов, имеющихся в органах власти). «Моделирование роли» – разрешённый приём в методологии SEMAT.
Потенциально мог влиять ещё профильный орган власти в качестве Регулирующего органа, но на момент проекта его требования не были проявлены.

Можно предложить воспользоваться следующей формой для закрепления результата анализа:

Таблица 3 Ключевые стейкхолдеры и их потребности

1. Организация (стейкхолдер)	2. Гипотеза, что они хотят	3. Лицо, принимающее решение (ЛПР), должность	4. ЛПР, ФИО	5. Как руководителю проекта проверить гипотезу
Минцифры России	Добиться автоматизации КНД. Реализовать требования импортозамещения			Прочитать документацию к ТОР КНД. Побеседовать с экспертом Минцифры России в сфере автоматизации КНД. Провести интервью с ЛПР из Минцифры или прочесть чужое интервью ЛПР.
Служба надзора	Увеличить производительности труда сотрудников за счёт автоматизации процессов и автоматического получения / передачи сведений в другие системы Обеспечить руководство отчётами о текущем состоянии работ			Провести интервью с несколькими ключевыми сотрудниками Службы. Вывить сервисы «Электронного правительства», с которыми надо интегрироваться.
Контролируемые организации	Упростить взаимодействие со Службой в электронном виде	Отсутствует, можно смоделировать его поведение		Прочитать требования отраслевого кодекса. Прочитать требования 210 ФЗ. Прочитать требования к взаимодействию с внешними пользователями в документации к ТОР КНД

Задача первичного заполнения таблицы лежит на руководителе проекта от Заказчика (в данном случае – сотруднике ДИТ). Сначала он должен заполнить графы «1.Организация» – «4. ЛПР ФИО», а затем проверить эти гипотезы. Примеры методов по проверке указаны в графе «5. Как руководителю проекта проверить гипотезу».

2.1.2 Выявить условия реализации проекта

Обстоятельства инициации проекта следующие:

Необходимость соответствия нормативным требованиям к контрольно-надзорной деятельности вообще и автоматизируемым видам надзора в частности;
Настойчивость Минцифры России в автоматизации указанных требований, активном использовании инфраструктуры «Электронного правительства» и интеграции с Типовым облачным решением Контрольно-надзорной деятельности (ТОР КНД);
Необходимость упрощения взаимодействия контролируемых организаций со Службой надзора;
Необходимость увеличения производительности труда сотрудников Службы надзора.

Подчеркнём, что окно возможности для создания информационной системы открылось за счёт воли федерального ведомства (Минцифры России) по автоматизации контрольно-надзорной деятельности. Внутренние потребности функционального заказчика по увеличению производительности своего труда существуют всегда, но редко приводят к немедленному запуску проектов.

2.1.3 Разработать Концепцию

Рассмотрим контрольные вопросы / задачи (в кавычках приведён перевод из англоязычных источников).

«Зафиксировать, что первоначальный набор заинтересованных сторон согласен с тем, что система должна быть создана». Необходимость системы очевидна из целого ряда нормативных требований по цифровизации контрольно-надзорной деятельности и отраслевых документов.
Автору статьи доводилось сталкиваться с системами (к счастью, только на уровне Концепции), у которых нет явно выраженных выгодоприобретателей и учёта их интереса. Такого рода описания имеют характерные фрагменты «За всё хорошее против всего плохого» и/или представление о выгодах пользователей донельзя абстрактно. В данном проекте необходимость новой системы стейкхолдерам очевидна, а выгоды конкретны.
«Выявить заинтересованные стороны, которые будут использовать новую систему». Пользователями системы выступают сотрудники и руководство Службы и контролируемые организации.
«Определить заинтересованные стороны, которые будут финансировать первоначальную работу над новой системой». Первоначальные спонсоры системы – Служба и ДИТ.
«Выяснить, что существует явная возможность для решения этой проблемы в рамках новой системы».

Обратите внимание на технологию работы – здесь и далее постоянно насыщается форма «Таблица 3 Ключевые стейкхолдеры и их потребности».

Рекомендуем пункты таблицы подробнее раскрыть, например, следующим образом:

«Упростить взаимодействие со Службой в электронном виде

Контролируемые организации

1. Как выполняется сейчас:

А) Уведомление Организацией направляется по почте;

Б) Документы Организации передаются лично или по почте

2. Что даст система:

А) Организация сможет направлять уведомление через Личный кабинет, авторизовавшись с использованием ЕСИА

Б) Документы будут подписываться Службой с использованием электронной подписи и направляться Организации через Личный кабинет.»

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

2.1.4 Выявить критерии выбора архитектуры

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

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

Пока определяется только верхний уровень – подход к архитектуре. Для любой государственной системы, нацеленной на взаимодействие с гражданами и бизнесом, есть базовые ограничения, понятия – импортозамещение, модуль интеграции со СМЭВ, идентификация пользователя средствами ЕСИА и использование электронной подписи. В 2020 году стала модной тема микросервисной архитектуры; автоматизация процессов намекает на использование BPMS, необходимость создания аналитических отчётов подразумевает использование BI.

Выбор языка и других технологий почти всегда находится на стороне стейкхолдера «Разработчик», определяемого по итогам конкурса. Из наблюдений – в некоторых крупных госкорпорациях приняты ограничения по использованию конкретных технологий, что обусловлено требованием служб технической поддержки (обслуживать 5 видов Linux, 4 вида СУБД и т.д. достаточно накладно). В отличие от госкомпаний в требованиях, формируемых региональными ИТ-министерствами, обычно ограничений меньше. IT-шники субъектов РФ обслуживают очень много разных функциональных заказчиков, зоопарк используемых технологий – их привычная среда.

2.1.5 Наметить состав команды

«Миссия команды была определена с точки зрения возможностей и результатов.
Ограничения на работу команды известны.
Механизмы для роста команды существуют.
Состав команды определен.
Определяются любые ограничения на то, где и как выполняется работа.
Обязанности команды изложены в общих чертах.
Уровень приверженности команды ясен.
Определены необходимые компетенции.
Размер команды определён.
Определены правила управления.
Выбрана модель лидерства.»

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

2.1.6 Инициировать работу

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

Превратим несколько абстрактные контрольные вопросы методологии в действия. На основании Концепции, понимая требования стейкхолдеров, формируется план / дорожная карта проекта. В неё вносятся как формальные даты (конкурсные процедуры, подписание договора, разработка ЧТЗ и т.д.), так и промежуточные даты, важные для стейкхолдеров. Конечная версия плана должна быть согласована со стейкхолдерами.

У автора (выполнявшего роль подрядчика) был опыт игнорирования явно высказанного ограничения от инициатора проекта по дате промежуточного результата. На требование представителя стейкхолдера выдать результат через 2 месяца, мною было сказано: «В эти сроки невозможно успеть сделать систему». Итог был печален – к моменту передачи проекта в опытную эксплуатацию инициатор уже уволилась (быстрый старт был нужен ей для отстаивания своей позиции в организации), отличный проект был формально сдан, но сразу заброшен Заказчиком. Если бы тогда удалось продемонстрировать хотя бы прототип, возможно, ИТ-ландшафт одной из отраслей был бы более серьёзным.

2.1.7 Определить технологии управления

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

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

2.2 Этап «Замысел»

2.2.1 Назначить представителей Стейкхолдеров

Раскроем контрольные вопросы методологии.

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

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

2.2.2 Проверить возможность реализации каждой потребности каждого стейкхолдера

«Потребность в решении была подтверждена.

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

Отметим один из контрольных вопросов: «По меньшей мере одно программное решение было предложено». На момент принятия решения существовало Типовое облачное решение Контрольно-надзорной деятельности (ТОР КНД), два-три альтернативных решения в части автоматизации специализированного надзора.

Добавим на данный этап специфику российского госсектора: формирование НМЦК – начальной (максимальной) цены контракта. В данной точке определяется будущая система и порядок её стоимости. У региональных Служб надзора в 2020 году реально был выбор из двух альтернатив:

Выполнение минимальных требований (контроль за контрольно-надзорной деятельностью и формализованная автоматизация деятельности). Часть регионов выбрала такой подход, из него следовала настройка для региона Типового облачного решения контрольно-надзорной деятельности. При этом в одном проекте удовлетворялись нужды десятка функциональных заказчиков субъекта РФ (разных видов надзора).
Упор на максимальную экономию времени сотрудников Службы надзора за счёт полноценной автоматизации его деятельности.

Итак, для руководителя проекта на данном этапе необходимо:

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

2.2.3 Описать границы системы

Контрольные вопросы:

«Определены заинтересованные стороны, участвующие в разработке новой системы.
Заинтересованные стороны договариваются о назначении новой системы.
Понятно, что такое успех новой системы.
Заинтересованные стороны имеют общее понимание масштабов предлагаемого решения.
То, как будут описаны требования, уже согласовано.
Механизмы управления этими требованиями уже существуют.
Схема расстановки приоритетов ясна.
Выявляются и учитываются ограничения.
Предположения четко сформулированы.»

Успехом системы по госконтракту всегда является полное исполнение Технического задания, представленного в конкурсной процедуре. Кроме того, система должна «прижиться» на уровне пользователей и руководства Службы.

Определение масштаба системы – очень важная точка. Согласно типовому сценарию внедрения ТОР КНД реализовывалась в первую очередь автоматизация отчётной деятельности, как указано выше («3.2.2 Возможность. Нужно решение»), и минимальная настройка внутренних процессов. Здесь же масштаб, объём можно описать так:

Детально автоматизируются ключевые бизнес-процессы;
Автоматизируется ведение основных реестров учёта (объектов и субъектов надзора);
Создаётся конструктор отчётов и с его помощью разрабатывается до 25 отчётов;
Создаётся Личный кабинет внешнего пользователя, подключаемый к ЕСИА;
Проводится интеграция с Единым государственным реестром проверок, другими государственными системами через СМЭВ и с региональной геоинформационной системой;
Создаётся «Конструктор» для реализации новых процессов надзора.

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

В качестве механизмов управления требованиями мы можем посоветовать использовать упоминавшийся документ «Ключевые стейкхолдеры, их потребности и функции системы». Системы вида jira и confluence не обязательны, если заказчик не имеет производственных подразделений внутри себя.

«Ограничения и допущения» – бюджет проекта и сроки реализации. «Предположения» в госсекторе формулируются в конкурсной документации, а именно – Техническом задании, критериях выбора разработчика, условиях договора. Конкурсные процедуры проводятся как раз на этом подэтапе. Подскажем, что содержание разделов документа «Ключевые стейкхолдеры, их потребности и функции системы» переходит в раздел «Требования к функциям (задачам), выполняемым системой» Технического задания.

2.2.4 Оценить предлагаемую систему

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

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

Исполнитель для реализации требований предложил создавать реестры путём программирования «в лоб», для модуля бизнес-процессов использовать собственную BPM-систему, для интеграции – Интеграционный шлюз. Решение по модулю «Конструктор аналитических отчётов» было не очевидно в начале подготовки Разработчиком конкурсных предложений. С января 2020 года компания-разработчик начали применять Metabase BI, а буквально за несколько недель до подачи заявки у компании появился опыт использования Pentaho BI (в варианте, удовлетворяющем требованиям импортозамещения). В результате было принято решение сделать ставку в проекте именно на этот продукт. В последствии верность выбора была подтверждена.

Зачастую указанные контрольные вопросы переносятся на этап «Проектирование». В данном случае они были растянуты на два этапа – «Замысел» и «Проектирование».

2.2.5 Доформировать команду

«Понимаются индивидуальные обязанности.
Набрано достаточно членов команды, чтобы позволить работе продвигаться вперед.
Каждый член команды понимает, как организована команда и какова их индивидуальная роль.
Все члены команды понимают, как выполнять свою работу.
Члены команды встретились (возможно, виртуально) и начинают узнавать друг друга.
Члены команды понимают свои обязанности и то, как они согласуются со своими компетенциями.
Члены команды принимают работу.
Выявляются любые внешние сотрудники (организации, команды и отдельные лица).
Определены механизмы командной коммуникации.
Каждый член команды обязуется работать в команде, как определено.»

По итогам конкурсных процедур в команду проекта были включены представители Разработчика. Окончательно определена ответственность членов расширенной команды. Интенсивно общались между собой системные администраторы и специалисты по безопасности: выяснялись правила доступа, открывались порты, согласовали порядок обновления релизов на площадке заказчика. Миллион вопросов взаимодействия решала «Управленческая команда». Коммуникации между участниками были выстроены на базе корпоративной ВКС, используемой ДИТом.

Ключевой вопрос на данном этапе – сопоставление уровня зрелости команды Заказчика и команды Разработчика. Слишком большой разрыв делает реализацию проекта затруднительной.

2.2.6 Сформировать уточнённый календарный план

Исходный перевод названия пункта – «Все предварительные условия для начала работ выполнены». Вопросы из исходной методо��огии:

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

Представляется, что правильнее акцентировать действия руководителя проекта на формировании календарного плана. Поэтому даём следующую интерпретацию:

Необходимо доопределить ключевые вехи и сформировать уточнённый календарный план с их учётом (возможно, в формате чек-листа с запасом времени на согласование).
Сформировать подход к организационному обеспечению с учётом опыта команд разработчика и заказчика.

В данном проекте активно использовался документ «Описание процесса создания и внедрения», представленный Разработчик согласно конкурсным требованиям и включавший следующие разделы:

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

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

2.2.7 Зафиксировать технологии взаимодействия

«Члены команды работают вместе как единое целое.

Команда работает как единое сплоченное целое.
Общение внутри команды открытое и честное.
Команда сосредоточена на достижении миссии команды.
Члены команды знают друг друга.»

Для плодотворной работы необходимо зафиксировать и контролировать правила взаимодействия – порядок ведения документов, прохождение документов по официальным и неофициальным каналам с учётом всех стейкхолдеров. В данном проекте было принято, что протокол совещаний вела руководитель проекта со стороны Разработчика. С одной стороны, это отнимало массу времени, а с другой стороны было проще вычленять существенные договорённости. На данном этапе желательно всем членам Управленческой команды начинать активно отслеживать перечень согласованных функций системы. Велика опасность неконтролируемого расширения требований со стороны функционального заказчика.

Единственным дискуссионным местом являлась интеграция с другими государственными системами. Служба ратовала за принцип «Интеграция всегда», компания-разработчик: «Интеграция всегда, когда интегрируемая система работоспособна». Для согласования использовались два метода:

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

2.3 Этап «Проектирование»

Для привязки к привычной терминологии обозначим формализованную суть этапа – разработка и согласование Частного технического задания.

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

2.3.1 Вовлечь стейкхолдеров

«Стейкхолдеры заинтересованных сторон активно участвуют в работе и выполняют свои обязанности:

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

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

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

2.3.2 Установить пользу (ценность) решения и критерии успеха

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

Ценность решения для Службы надзора заключается в снижении издержек на выполнение рутинных операций сотрудниками Службы и понимании картины работ руководством, выполнении нормативных требований в части сбора и передачи сведений о внешнем пользователе без его участия. Для контролируемой организации ценность заключается в снижении издержек на взаимодействие со Службой, возможности перехода на безбумажную работу. Ценность для Минцифры России заключается в том, что ещё один субъект РФ автоматизирует свою деятельность в рамках общего подхода. Ценность для ДИТ состоит в удовлетворен��и требований Службы и внешних пользователей.

Критерии успеха:

Заметное снижение трудозатрат сотрудников Службы на ключевых процессах. Отсутствие значительных потерь времени на работы в системе, не приносящие пользу сотруднику.
Получение оперативной отчётности руководством Службы в любой момент.
Возможность юридически значимого получения предписаний и уведомлений контролируемыми организациями через Личный кабинет.
Работоспособность решения в целом, активное получение и передача сведений через Систему межведомственного взаимодействия, возможность интеграции с ТОР КНД – для Минцифры России.
Реализация базовых возможностей системы для надзора – для ДИТ.

2.3.3 Согласовать определение системы (ЧТЗ)

«Требования обеспечивают последовательное описание основных характеристик новой системы.

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

«Происхождение и логическое обоснование требований совершенно ясно» – опрашиваются руководители на предмет списка отчётов, происходит уточнение описаний процессов, реестров, справочников, шаблонов документов, правил расчета показателей. В госсекторе исходные данные зафиксированы в массе документов – есть законы, Административные регламенты, описания интеграционных видов сведений (в них указана детальная структура данных), структура ряда отчётов нормативно закреплена.

«Требования передают основные характеристики поставляемой системы» – это выражается в частных технических заданиях: ЧТЗ на процессы, ЧТЗ на реестры, ЧТЗ на формы подачи заявок с Единого портала госуслуг (gosuslugi.ru). Интеграционные сервисы СМЭВ покрыты большим количеством документов, к ним надо просто подключаться.

Уже в ходе проекта стали выявляться приоритеты в нём – значимым являлось «удобство использования» (экспертно определяемое функциональным заказчиком), основное время обсуждения функциональный заказчик уделял наиболее частым процессам.

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

2.3.4 Оценить предлагаемую систему

Состояние этой Альфы и контрольные вопросы переходят с предыдущего этапа. Проводится углублённое ознакомление с программным обеспечением Разработчика, проверка ПО на соответствие требованиям.

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

2.3.5 Выявлять и уменьшать потраченную впустую работу команды

И снова мы приводим собственное название работы, исходное выглядит так – «Команда работает эффективно и результативно».

«Команда последовательно выполняет свои обязательства.
Команда постоянно адаптируется к меняющимся условиям.
Команда выявляет и решает проблемы без посторонней помощи.
Эффективный прогресс достигается с минимальными предотвращаемыми отступлениями и переработками.
Потраченная впустую работа и потенциал для потраченной впустую работы постоянно устраняются.»

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

В случае наличия конфликтов необходим поиск их источников и устранение.

2.3.6 Отслеживать ход работ

«Начаты опытно-конструкторские работы.
Ход работ отслеживается.
Работа разбивается на практические рабочие элементы с четкими определениями проделанной работы.
Члены команды принимают задания и выполняют их.»

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

2.3.7 Внедрить технологии взаимодействия

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

Базовые технологии подготовки / требования к документам описаны в ГОСТах и методических рекомендациях Минцифры России, опубликованных на Технологическом портале СМЭВ3.

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

Уже на этом этапе важны технологии контроля отставания и управления мерами для ликвидации отставания.

2.4 Этап «Изготовление»

В целом это самый длинный этап проекта, он состоит из большого количества разного рода работ.

2.4.1 Контроль согласия стейкхолдеров с создаваемой системой

«Представители стейкхолдеров в согласии» – этап начинается с подписанных на предыдущем шаге частных технических заданиях. В описании SEMAT приводятся следующие контрольные вопросы:

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

Необходимо и далее проверять, что каждый представитель ключевых стейкхолдеров считает, что рождающаяся система удовлетворяет всем их требованиям. При этом апелляция должна идти не к фразе «А мне надо!», а к документу «Ключевые стейкхолдеры, их потребности и функции системы», ТЗ и ЧТЗ. Хотя, устоять перед напором функциональных заказчиков бывает невероятно сложно. Руководители проекта (со стороны заказчика и подрядчика) должны контролировать, изменяются ли требования стейкхолдеров, и документировать любые изменения требований. По окончании этапа необходимо проследить, что есть соответствие между требованиями и системой.

2.4.2 Контролировать соответствие создаваемой системы исходным предпосылкам

«Согласовано, что решение может быть произведено достаточно быстро и дёшево, чтобы соответствовать возможностям.

Решение обрисовано в общих чертах.
Представители заинтересованных сторон довольны своим участием в работе.
Есть признаки, что решение может быть разработано и развёрнуто в рамках ограничений.
Риски, связанные с решением, приемлемы и управляемы.
Грубая оценка цены решения меньше, чем ожидаемая польза от реализации возможности.
Причины для разработки решения понимаются всеми членами команды.
Ясно, что реализация возможности жизнеспособна.»

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

Новые возможности, которые становятся видны по мере выхода релизов могут вскружить голову участникам проекта. Вот только ограничения проекта (сроки, финансы, требуемая квалификация, исходные предпосылки создания системы) должны удерживать в реальном мире, иначе текущие стейкхолдеры могут не получить результата. Если открывающиеся возможности требуют объёмных изменений, то останавливайте их инициатора: «Давай мы сначала сделаем то, что написано в ТЗ» (этой фразой обычно тормозили мои несвоевременные идеи). Если требования поступают от заказчиков, записывайте их в «список пожеланий для развития проекта».

2.4.3 Убедиться, что описания системы приемлемы

«Требования описывают систему, которая является приемлемой для заинтересованных сторон.

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

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

Требования проверяемы – в переводе на привычный язык это означает, что документ «Программа и методика испытаний» разработана.

2.4.4 Контролировать, что система пригодна для использования

«Система пригодна для использования и демонстрирует все качественные характеристики.

Система может эксплуатироваться стейкхолдерами-пользователями.
Функциональность, предоставляемая системой, была протестирована.
Эффективность системы приемлема для заинтересованных сторон.
Уровни дефектов приемлемы для заинтересованных сторон.
Система полностью документирована.
Содержание релиза известно.
Добавленная стоимость, предоставляемая системой, ясна.»

На данном этапе происходила разработка собственно приложения на базе продемонстрированных компонент и разработанных ЧТЗ на процессы, формы на портале госуслуг, реестры, отчёты и интеграции. Для каждого вида перечисленных сущностей существует своя методика разработки. Компания-разработчик не очень любит использовать слово agile, но очень любит регулярно демонстрировать разработанные компоненты, сценарии и получать обратную связь. Особенно такой подход важен для процессов – в них всегда найдутся исключения, особые ситуации и несуразности. ЧТЗ в данном случае снимает только часть рисков. Самая предсказуемая часть системы – это интеграция с «Электронным правительством». Тем не менее была зона неопределённости – ГЭПС (Государственная электронная почтовая система), обоим ИТ-участникам не приходилось ранее работать с этой системой.

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

2.4.5 Выявлять и уменьшать потраченную впустую работу команды

Также, как и на предыдущем этапе необходимо выявлять действия, пожирающие ресурсы команды.

2.4.6 Контролировать прогресс работы

Обычная работа в ходе проекта.

2.4.7 Отслеживать используемые технологии

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

2.5 Этап «Разворачивание»

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

2.5.1 Контролировать удовлетворённость стейкхолдеров готовностью системы для разворачивания

«Минимальные ожидания представителей стейкхолдеров были достигнуты.

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

В переводе на привычный язык – перед разворачиванием системы в продуктивный контур достигается согласие о соответствии системы ТЗ, ЧТЗ согласно Программе и методике испытаний (ПМИ).

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

Отдельной проблемой почти всегда является появление сообщений «я думал, что здесь будет вот такая функция». В одном из проектов за неделю до разворачивания системы компании-разработчику была поставлена задача подключиться не к геоинформационной системе, указанной в ТЗ и ЧТЗ, а к другой! В указанном случае удалось справиться (повезло), но как системно решать данную проблему не понятно. При этом дополнительные задачи на данном этапе практически всегда сильно увеличивают себестоимость.

Важнейший момент – это переход в опытную и промышленную эксплуатации системы. Роль представителя функционального заказчика многократно возрастает. Он должен организовать свой коллектив на изменение порядка ведения ежедневных работ с использованием системы, отвечать перед сотрудниками и руководителями за успех проекта / системы. На этом этапе часть людей «ломается». Оказывается, что у сотрудника функционального заказчика не достаточно прав для представления проекта в своей организации. Эта болезнь проявляется в привлечении новых участников со стороны функционального заказчика на этапе разворачивания: «Надо показать юристам, надо рассказать руководству, ...». Некоторые представители функционального заказчика начинают безустанно добавлять требования к системе, оттягивая начало эксплуатации.

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

2.5.2 Контролировать полезность системы

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

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

Соответствует нормативным требованиям к контрольно-надзорной деятельности вообще и к автоматизируемым видам надзора в частности;
Удовлетворяет требованиям Минцифры России;
Упрощает взаимодействие внешних пользователей со Службой надзора;
Увеличивает производительность труда сотрудников Службы.

2.5.3 Контролировать качество документации для эксплуатации

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

2.5.4 Проверить готовность системы

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

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

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

2.5.5 Способствовать подключению новых членов команды

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

2.5.6 Контролировать перенос системы в среду заказчика и начало эксплуатации

Ключевые задачи – контролировать перенос системы (последней версии системы) в продуктивную среду заказчика, готовность всех составляющих проекта.

2.5.7 Использовать технологии передачи системы в эксплуатацию

Данный этап является одним из самых комплексных, несмотря на короткие сроки. Руководители проекта должны контролировать множество технологий (разворачивание, обучение, приёмка работ) и иметь навыки психолога.

Важно помнить, что здесь набирает силу страшный враг проекта – фантазии, высказываемые в условиях отсутствия опыта эксплуатации. Часть команды работает с реальным воплощением системы, другая оперирует неясными картинами. Хуже всего, если фантазии проявляет руководство функционального заказчика, которое может своей властью помешать окончанию доделки цельной системы. Технологией противодействия хаосу является документ «Ключевые стейкхолдеры, их потребности и функции системы». Именно сравнение новых идей с исходными может помочь Заказчику получить задуманное, а подрядчику удержать требования под контролем. Если у руководителя проекта со стороны Разработчика хватает силы воли, записывайте все хотелки в список пожеланий на развитие, а не ломайте систему.

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

2.6 Этап «Эксплуатация»

2.6.1 Отследить удовлетворенность стейкхолдеров использованием системы

«Система удовлетворяет или превышает минимальные ожидания стейкхолдеров.

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

Руководитель проекта со стороны заказчика должен отслеживать удовлетворенность от использования системы стейкхолдерами в начале этапа эксплуатации.

2.6.2 Проконтролировать получение выгоды

«Эксплуатация или продажа решения создаёт осязаемые выгоды:

Решение начало приносить пользу для стейкхолдеров.
Профиль возврата инвестиций по меньшей мере так хорош, как ожидалось.»

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

Однако наблюдение за процессом эксплуатации поразило – ключевая выгода формулируется пользователями иначе. Они наибольшее внимание уделяют автоматическому формированию документов по шаблону. Здесь получается прямая выгода – экономия 30 минут на оформление каждого экземпляра типового документа! Вот её можно переводить в финансовые термины.

2.6.3 Отслеживать и компенсировать недостаточность документации

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

2.6.4 Контролировать согласованный уровень использования

«Система полностью поддерживается на согласованном уровне обслуживания (в соответствии с SLA)». Происходит фиксация запросов на изменение (для нового проекта) на основе запросов пользователей.

2.6.5 Трансформировать команду

Описание из методологии (Документ «Essence – Kernel and Language for Software Engineering Methods». Table 8.6 – Checklist for Team. Раздел «Performing») оказалось полностью не соответствующим нашему пониманию, поэтому дадим своё.

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

Схожие трансформации происходят на стороне ИТ-команды Заказчика.

На стороне функционального заказчика команда экспертов перестаёт активно работать над проектом. Она может использоваться для оценки и подготовки предложений по развитию системы.

2.6.6 Поставить технологию технической поддержки

Представляется, что ключевой технологией на данном этапе становится технология технической поддержки – ITSM (IT Service Management). Для её воплощения используйте систему класса Service Desk.

2.6.7 Зафиксировать окончание работы по созданию системы

«Обязанности команды были переданы или выполнены.
Члены команды доступны для назначения в другие команды.
Группа больше не предпринимает никаких усилий для завершения миссии.»

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

2.7 Этап «Вывод из эксплуатации»

2.7.1 Проверить, что стейкхолдеры согласны с выводом системы из эксплуатации

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

2.7.2 Проверить, что условия существования системы закончились

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

2.7.3 Создавать документы по системе не требуется

Никакие новые документы не создаются.

2.7.4 Снять программную система с поддержки

«Система была заменена или прекращено её использование.
Система больше не поддерживается.
Нет никаких «официальных» заинтересованных сторон, которые все еще используют эту систему.
Обновления системы больше производиться не будут.»

2.7.5 Полностью высвободить команду

«Обязанности команды были переданы или выполнены.
Члены команды доступны для назначения в другие команды.
Группа больше не предпринимает никаких усилий для завершения миссии.»

2.7.6 Зафиксировать окончание работ

«Все оставшиеся домашние задания были завершены, и работа была официально закрыта.

Извлеченные уроки были детализированы, записаны и обсуждены.
Были предоставлены метрики.
Все было заархивировано.
Бюджет был сверен и закрыт.
Команда была освобождена.
Нет нерешенных, незавершенных задач.»

Обращаем ��нимание на выполнение следующей задачи: необходимо проконтролировать, что все важные данные переведены в другую систему или явно более не нужны. Автору как-то довелось увидеть, как накопленные юридически значимые данные уходили на утилизацию (дисковый массив подлежал форматированию)! В том случае система выводилась из эксплуатации в связи с передачей функций другой организации, имевшей свою аналогичную систему. Но данные-то могли потребоваться, в том числе в ходе проверок.

2.7.7 Сформулировать и зафиксировать уроки

«Технологии больше не используются.
Уроки извлечены и доступны для дальнейшего использования.»

3. Заключение

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

Акцентируем внимание на новых идеях, которые удалось открыть для себя в ходе интерпретации исходной методологии:

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

Данная статья не могла бы быть написана без активной поддержки Евгении Александровны Дровняшиной и Михаила Юрьевича Гордеева

Использование SEMAT (Software Engineering Method and Theory) для управления ИТ-проектами в госсекторе