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

Что значит «описать через результат», а не через бренд

На практике в закупках выделяют три вида описания. Функциональное (ориентированное на результат) определяет, какую функцию или роль должен выполнять товар и какой результат получить, не предписывая способ достижения. Техническое или конструкторское описание фиксирует физические характеристики — размер, тип материалов, производительность. Между ними — описание через показатели работоспособности: что изделие должно уметь в цифрах.

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

Для услуг и работ разница та же: описание результата («обеспечить непрерывный мониторинг и реагирование на инциденты по регламенту») вместо перечня «как именно делать». Чем больше заказчик описывает «как», тем выше его ответственность за выбор решения и тем меньше у поставщика гибкости.

• Функциональное — что должно быть достигнуто и как это проверить
• Описание работоспособности — какие числовые возможности обязательны
• Техническое/конструкторское — физические параметры, чертежи, материалы
• Смешанное — функция плюс уточняющие технические условия

Что говорит закон: функциональные характеристики и запрет товарных знаков

Правило Федерального закона № 44-ФЗ (статья 33) обязывает описывать объект закупки через функциональные, технические и качественные характеристики, а также эксплуатационные характеристики при необходимости. В описание нельзя включать требования или указания на товарные знаки, фирменные наименования, патенты и страну происхождения, если они ведут к ограничению числа участников.

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

Часть 2 статьи 33 требует, чтобы документация содержала показатели, по которым определяется соответствие, с максимальными и (или) минимальными значениями и значениями, которые не могут изменяться. Часть 3 прямо запрещает требования к производителю товара, к квалификации и деловой репутации участника, если иное не предусмотрено законом. Это значит: «подходит только продукт известного вендора» — не описание объекта, а скрытое ограничение.

Для закупок по 223-ФЗ действует сходный запрет: нельзя устанавливать такие характеристики, которым в совокупности соответствует продукция одного производителя; при указании на товарный знак добавляют «или эквивалент». Нормы и практика могут уточняться, поэтому перед тендером проверьте актуальную редакцию закона и позицию контрольного органа.

• Функциональные, технические и качественные характеристики — база описания по 44-ФЗ
• Товарный знак — только «или эквивалент», совместимость или запчасти
• Показатели: «не менее», «не более» либо неизменяемые значения
• Требования к производителю и «репутации» участника запрещены

Рецепт функционального требования: функция + условие + измеримый показатель

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

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

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

• Каждая функция — это глагол-действие, условие и измеримый результат
• Границы задавайте словами «не менее», «не более»; неизменяемые параметры обоснуйте
• Термины и показатели — из регламентов и стандартов, иначе нужна мотивировка
• Убирайте размытые и абсолютные формулировки из текста

Где «описание результата» работает, а где нужен гибрид

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

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

Оцените риск и сложность объекта: для простых товаров достаточно функциональных характеристик с показателями; для сложных систем нужен гибрид «функция + технические условия совместимости + метрики производительности». Принятый уровень детализации стоит зафиксировать в методике оценки до публикации извещения.

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

Приёмка, метрики и управление контрактом: как проверить достижение результата

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

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

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

• Задание переходит в контракт: пропишите порядок приёмки и её критерии
• Для услуг задайте KPI: время реакции, сроки устранения, отчётность
• Определите источник данных, периодичность и формат отчётов
• Целевые значения проверьте на рынке и при необходимости уточните до тендера

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

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

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

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

• Средство защиты — через эффект: обнаружение, изоляция, оповещение, журналы
• Стандарты и сертификаты — как ориентир с эквивалентностью, а не барьер
• Услуги мониторинга — через сроки реакции, зоны ответственности и отчётность