Как организовать управление ИТ-проектом по 223-ФЗ?

Управление разработкой и закупочная процедура живут в разном темпе.

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

Задача руководителя проекта — соединить эти два подхода ещё до публикации закупки.

Ответ за 30 секунд:

223-ФЗ даёт заказчику больше возможностей для настройки договора, чем жёсткая модель государственного контракта.

Но источник этой гибкости — не само слово Agile.

Положение о закупке и документация должны заранее определять:

• порядок исполнения договора;
• допустимый механизм его изменения;
• модель цены;
• этапность;
• критерии приёмки.

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

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

Шаг 1. Определите рамку проекта

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

Зафиксируйте:

• бизнес-цель;
• пользователей;
• основные процессы;
• обязательные интеграции;
• критичные требования безопасности;
• инфраструктурные ограничения;
• минимальный конечный результат.

Это стабильная часть.

Далее выделите функциональность, приоритет которой может меняться.

Например:

• дополнительные отчёты;
• второстепенные интеграции;
• интерфейсные доработки;
• порядок реализации пользовательских сценариев.

Так появляется контролируемый бэклог.

Почему нельзя просто написать «работаем по Agile»?

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

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

Поэтому договор должен заранее отвечать:

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

Тогда change request становится частью процедуры, а не перепиской двух руководителей в мессенджере.

Шаг 2. Выберите модель цены

223-ФЗ позволяет положению о закупке предусматривать разные механизмы ценообразования.

Для ИТ это особенно полезно.

Твёрдая цена

Подходит, если результат достаточно подробно известен заранее.

Например, внедрение уже существующей системы с фиксированным перечнем работ.

Цена этапа

Удобна, когда проект делится на самостоятельные релизы.

Каждый этап имеет:

• результат;
• срок;
• цену;
• критерии приёмки.

Цена единицы и максимальная цена договора

Подходит для потока заранее классифицированных задач.

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

Но единица должна быть понятной и проверяемой.

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

Шаг 3. Постройте этапную приёмку

Для разработки безопаснее принимать результат постепенно.

Вместо одного акта в финале проекта предусмотрите несколько этапов.

Например:

Аналитика и проектирование

Принимаются:

• требования;
• архитектура;
• прототипы;
• спецификации интеграций.

Разработка

Принимаются отдельные рабочие модули или релизы.

Интеграционное тестирование

Проверяются взаимодействие систем, нагрузка и сценарии обмена.

Ввод в эксплуатацию

Передаются финальная версия, документация, необходимые права и исходные материалы.

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

Как описать критерии приёмки?

Требование должно позволять ответить «выполнено или нет».

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

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

Вместо «минимальное количество ошибок» определить категории дефектов.

Хороший договор отделяет субъективное впечатление заказчика от формальных условий приёмки.

Шаг 4. Создайте процедуру изменения требований

Любая новая задача должна проходить один маршрут.

Например:

1. Регистрация change request.
2. Описание причины.
3. Оценка трудоёмкости.
4. Анализ влияния на срок.
5. Проверка принадлежности к предмету договора.
6. Определение изменения бэклога.
7. Оформление решения.

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

Иногда она потребует изменения договора.

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

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

Если при исполнении договора меняются объём, цена или срок относительно итогового протокола, заказчику также нужно учитывать обязанности по отражению изменений в ЕИС.

Что изменилось для закупки ПО?

С первого января две тысячи двадцать пятого года национальный режим по 223-ФЗ регулируется в том числе статьёй 3.1-4 закона и постановлением Правительства № 1875.

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

Причём понятие закупки ПО для этих целей широкое.

Оно охватывает не только покупку лицензии, но в предусмотренных постановлением случаях также облачные сервисы и работы по разработке, модернизации или модификации, если в результате заказчик получает права использования либо их объём расширяется.

Проверяйте реестр до закупки

Российское происхождение программы подтверждается номером записи в реестре российского ПО.

Если подходящего решения в российском или евразийском реестре нет либо имеющиеся программы объективно не соответствуют требованиям, постановление предусматривает механизм обоснования неприменения запрета.

Такое обоснование нужно строить на функциональных, технических и эксплуатационных требованиях, а не на предпочтении конкретного бренда.

Учитывайте доверенное ПО

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

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

Поэтому реестровую запись теперь имеет смысл проверять не только на факт присутствия продукта, но и на дополнительные сведения в ней.

Шаг 5. Урегулируйте интеллектуальные права

ИТ-договор без подробного раздела о правах создаёт риск зависимости от одного подрядчика.

Если система разрабатывается по заказу, нужно прямо указать:

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

Гражданский кодекс по-разному регулирует программу, создание которой прямо является предметом заказа, и произведение, которое возникло при исполнении другого договора.

Поэтому лучше не оставлять этот вопрос на толкование после завершения проекта.

Как не попасть в зависимость от разработчика?

Предусмотрите передачу не только работающей программы.

Заказчику могут понадобиться:

• исходный код;
• инструкции сборки;
• схема архитектуры;
• описание API;
• структура базы данных;
• документация администратора;
• инструкции развёртывания;
• перечень зависимостей;
• ключевые настройки.

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

Если договор предусматривает обеспечение

ИТ-проект по 223-ФЗ может предусматривать обеспечение заявки или исполнения договора в соответствии с положением и условиями закупки.

Если исполнителю требуется независимая гарантия, её можно оформить через FINLEO Банковские гарантии.

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

Типовые ошибки ИТ-заказчика

Пишет ТЗ как окончательную спецификацию продукта, хотя требования ещё формируются.

В результате реальные изменения начинаются сразу после старта.

Пишет слишком широкое ТЗ.

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

Не описывает change request.

Каждая новая задача превращается в переговоры о цене и сроках.

Оставляет приёмку субъективной.

Заказчик считает результат плохим, а исполнитель показывает акт и формально выполненное ТЗ.

Не регулирует права на код.

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

Поздно проверяет национальный режим.

Подход к закупке приходится менять уже после подготовки документации.

Чек-лист перед публикацией ИТ-закупки

Проверьте:

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

Как совместить Agile и 223-ФЗ?

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

Юридически устойчивый Agile-контракт работает наоборот: его рамка описана очень точно, а гибкость находится внутри заранее установленных правил.

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