“Простое и понятное ТЗ в тендере, это открытый призыв к авантюристам. Они могут откликнуться с минимальными затратами, сыграть на количестве участников и забить стоимость вниз. Если вы не предусмотрите технический барьер, вас обманут сразу или позже, через урезание услуг и подмену технологий. Вот как можно исключить обман.”
Проблема с ТЗ на примере концепции ‘информационные системы’
Большинство технических заданий в тендерах начинаются с общих фраз. Например, «Поставка информационной системы». Этот термин скрывает реальную техническую базу: речь может быть о веб-приложении, распределённой сети, внутреннем сервисе, коллекции баз данных или о смешении всего этого вместе.
Подрядчик, который отвечает на такое ТЗ, имеет очевидное преимущество: он не обязан раскрывать технологии. Поэтому он может пообещать построить всё на технологиях, которые ему дешевле всего приобрести, даже если они мало соответствуют реальным задачам клиента.
Попробуйте задать ему прямой вопрос: что такое «информационная система» в вашем понимании? Он скажет: это приложение, которое работает на сервере и отвечает на запросы. Затем вы спросите: какие компоненты использует эта система? Вспомните хотя бы три основных компоненты любой современной ИС: серверные вычислительные узлы (compute), хранилище данных (storage) и средства передачи данных (network). Подрядчик может говорить о них как о единой неразделимой сущности, и это создает уязвимость.
Вас могут убедить, что «система» будет работать на одном стандартном сервере, который технически — только compute. И именно compute будет доминировать в разговоре. Тогда storage останется абстрактным понятием, а network, это просто «провод».
Если вы согласитесь, подрядчик построит систему из тех серверов, которые ему дешевле всего приобрести. Это может быть офисный сервер с низкими характеристиками хранения и пропускной способности. При этом он выполнит условия ТЗ: информационная система будет поставлена. Но её технические недостатки станут вашей проблемой после поставки.
Этот пример показывает, почему общие термины в ТЗ делают вас лёгкой целью для манипуляций.
Базовый инструмент против манипуляций: привязка к классификациям
Один из самых простых способов защититься от обмана — использовать классификации, которые уже приняты в отрасли и имеют техническое содержание. Для российского IT-рынка это прежде всего классификации ФСТЭК и ГОСТов.
Если в вашем ТЗ вы требуете, например, «систему обработки персональных данных», важно указать не только название функции, но и класс защиты по требованиям ФСТЭК или 152-ФЗ. Указать класс, это не просто юридическая формальность. Это техническое требование, которое заставляет подрядчика раскрывать методы реализации.
Классы защиты (например, КС1, КС2, КС3 в терминах ФСТЭК) предполагают конкретные требования к криптографическим средствам, методам управления доступом, средствам контроля и аудита. Если подрядчик говорит, что он выполнит защиту, но не раскрывает, какие криптографические алгоритмы он использует или как реализует управление доступом, он не может претендовать на соответствие классу.
Теперь попробуйте составить ТЗ так: > Система обработки персональных данных должна соответствовать классу защиты КС2. В описании решения поставщик обязан указать: криптографические алгоритмы и их соответствие ГОСТ; методы управления доступом (RBAC, ABAC или другие) и их реализацию; средства аудита действий пользователей и их техническую базу.
Подрядчик, который хочет участвовать в тендере, должен раскрыть эти детали в предложении. Если он не раскрывает, вы можете отклонить предложение на формальном основании — неполное соответствие ТЗ.
Это первый барьер против манипуляций: техническое содержание классификаций. Он работает, потому что классификации имеют формальные критерии проверки.
Ловушка производительности: требования к пропускной способности и нагрузке
Общие требования к производительности — ещё одна точка для обмана. Например: «система должна поддерживать 1000 пользователей». Это требование можно исполнить технически разными способами: система может обслуживать 1000 пользователей, но с задержкой в 10 секунд на каждый запрос. Или она может обслуживать 1000 пользователей одновременно, но при этом перестать работать при скачках нагрузки.
Чтобы избежать этой ловушки, нужно детализировать требования производительности в три слоя:
- Средняя нагрузка.
- Пиковая нагрузка.
- Время реакции системы.
Укажите эти параметры в ТЗ как обязательные для раскрытия в предложении поставщика.
Пиковая нагрузка, это самая важная деталь, которую обычно замалчивают. Подрядчик может построить систему, которая хорошо работает на средних значениях, но при скачке нагрузки (например, в момент запуска нового функционала или в период высокой активности пользователей) начинает давать ошибки или полностью блокируется. Это не будет нарушением ТЗ, если в ТЗ нет требования к пиковой нагрузке.
Пример требования: > Система должна обеспечивать обработку транзакций с средней нагрузкой 500 транзакций в секунду, пиковой нагрузкой — 2000 транзакций в секунду в течение не менее 5 минут. Время реакции системы на 95% транзакций в условиях средней нагрузки не должно превышать 2 секунд.
Такое требование даёт вам возможность проверить архитектуру решения поставщика. Если его архитектура не предусматривает механизмов масштабирования для пиковых нагрузок (например, горизонтального масштабирования или использования очередей), он не сможет гарантировать выполнение этого пункта.
Теперь поставщик не может просто сказать «система поддерживает нагрузку». Он должен раскрыть, как именно система будет справляться с пиковой нагрузкой: через увеличение количества узлов, через оптимизацию кода, через использование распределённых вычислений. Если он этого не раскрывает, его предложение технически неполное.
Уязвимость в сроках и этапах поставки
ТЗ часто включает сроки поставки, но не включает этапы поставки с проверочными критериями. Это позволяет поставщику затягивать реализацию, скрывать проблемы и поставлять систему в неполном виде на последнем этапе.
Чтобы исключить эту уязвимость, разбивайте поставку на этапы с техническими критериями завершения каждого этапа. Каждый этап должен иметь свой набор проверок, которые вы можете выполнить самостоятельно или с помощью независимого аудитора.
Пример этапов:
- Этап проектирования архитектуры — критерий завершения: предоставление полной схемы архитектуры с описанием всех компонентов и их взаимодействия.
- Этап разработки базовых модулей — критерий завершения: работоспособность ключевых модулей на тестовом окружении с выполнением базовых операций.
- Этап интеграции и тестирования — критерий заверсия: успешное прохождение нагрузочных тестов и тестов безопасности.
Указание таких этапов создает промежуточные точки контроля. Если поставщик не может завершить этап проектирования (например, не предоставляет схему), вы можете остановить проект до начала разработки, без финансовых потерь на последующих этапах.
Этапы также позволяют вам оценивать прогресс технически, не только по календарным датам. Это важно, потому что поставщик может формально соблюдать сроки, но при этом не достигать технических целей этапа. Если в ТЗ указаны технические критерии завершения этапа, вы можете требовать их выполнения как обязательного условия для перехода к следующему этапу.
Технические критерии вместо субъективных оценок
Большинство ТЗ оцениваются по субъективным критериям: «удобство интерфейса», «надежность системы», «современность технологий». Эти критерии легко подменяются.
Чтобы не попасть в эту ловушку, переводите субъективные требования в технические критерии. Например:
- «Удобство интерфейса» → «Поддержка стандартных паттернов взаимодействия (например, шаблон CRUD для административных функций) и наличие документации по API».
- «Надежность системы» → «Наличие механизмов резервирования (replication) для критических данных и автоматического восстановления после сбоев (failover)».
- «Современность технологий» → «Поддержка стандартных протоколов взаимодействия (например, REST API для внешних интеграций) и использование актуальных, но стабильных версий фреймворков (с указанием конкретных версий или диапазонов версий)».
Такое преобразование не только делает оценку объективной, но и вынуждает поставщика раскрывать конкретные технологии. Если поставщик говорит, что использует «современные технологии», но не указывает версии фреймворков или протоколы, вы можете считать его предложение неполным.
Один из эффективных методов — включить в ТЗ таблицу технических критериев с обязательством поставщика заполнить её в своём предложении.
Пример таблицы:
| Критерий | Ожидаемое значение | Обязательность для раскрытия в предложении |
|---|---|---|
| Механизм резервирования данных | Репликация на отдельный носитель с периодичностью не более 5 минут | обязательное |
| Средства мониторинга доступности | SLA 99.9%, инструменты мониторинга (например, Prometheus + Grafana) с оповещениями | обязательное |
| Версии используемых фреймворков | Актуальные стабильные версии, не ниже указанных в приложении к ТЗ | обязательное |
Если поставщик не заполняет эту таблицу или заполняет её неполно, его предложение можно отклонить как не соответствующее ТЗ.
Риск подмены технологий: требование раскрытия стека
Один из самых частых способов обмана — подмена технологий после начала проекта. Поставщик может согласовать использование одних технологий, но в процессе разработки перейти на другие, менее надёжные или менее совместимые с вашей средой.
Чтобы предотвратить это, требуйте в ТЗ раскрытие полного стека технологий с указанием конкретных продуктов, версий и их ролей в системе. Стек должен включать:
- Операционные системы на серверах (с указанием дистрибутивов и версий).
- Базы данных (с указанием типа: SQL/NoSQL, конкретного продукта и версии).
- Фреймворки и языки программирования (с указанием версий).
- Средства обеспечения безопасности (например, средства шифрования, системы управления доступом).
- Инструменты мониторинга и управления.
Пример требования: > Поставщик обязан предоставить полный стек технологий, используемых в системе. Стек должен включать: операционные системы (например, Ubuntu 22.04 LTS), базы данных (например, PostgreSQL 15), фреймворки (например, Django 4.2), средства безопасности (например, модуль шифрования ГОСТ), инструменты мониторинга (например, Zabbix 6). Любое изменение стека после начала проекта должно быть согласовано с заказчиком и документально подтверждено.
Если поставщик раскрывает стек, вы можете оценить его совместимость с вашей текущей инфраструктурой и его соответствие стандартам (например, использованию ГОСТ для шифрования). Если он не раскрывает стек, вы не сможете оценить риски, связанные с технологиями.
Это требование также создаёт юридическую основу для контроля изменений: если поставщик меняет стек без согласования, это становится нарушением договора.
Проблема скрытых зависимостей и интеграций
Системы почти никогда работают изолированно. Они зависят от внешних сервисов, API, библиотек или данных третьих сторон. В ТЗ часто отсутствуют требования раскрывать эти зависимости.
Поставщик может построить систему, которая технически работает, но зависит от внешнего API, который может стать недоступным. Или он может использовать библиотеки, которые имеют ограничения по лицензиям, создавая юридические риски для вас.
Чтобы избежать этого, включите в ТЗ раздел «Внешние зависимости и интеграции». В этом разделе поставщик должен указать:
- Все внешние API, которые система использует, с указанием их публичности (публичные или приватные) и условий доступности.
- Библиотеки и сторонние компоненты с указанием их лицензий (особенно важно для открытых лицензий, которые могут требовать раскрытия кода).
- Данные третьих сторон, которые система обрабатывает, с указанием источников и условий их использования.
Пример требования: > Поставщик обязан раскрыть все внешние зависимости системы: API сторонних сервисов, библиотеки и компоненты с открытым исходным кодом, данные третьих сторон. Для каждой зависимости должно быть указано: как система её использует, условия её доступности (например, SLA внешнего API) и лицензионные ограничения (например, требование раскрытия кода при использовании библиотеки под GPL).
Это требование позволяет вам оценить риски недоступности внешних компонентов и юридические риски лицензий. Если поставщик скрывает зависимости, вы можете столкнуться с неожиданными проблемами после поставки системы.
Критерии приемки как финальный барьер
Критерии приемки, это последний этап, на котором вы можете предотвратить обман. Если критерии приемки сформулированы нечётко, поставщик может поставить систему, которая формально соответствует ТЗ, но не соответствует вашим реальным потребностям.
Чтобы сделать критерии приемки эффективными, они должны быть:
- Технически проверяемыми.
- Независимо исполняемыми (вы или третья сторона можете проверить их без помощи поставщика).
- Полными (охватывают все ключевые функции системы).
Пример критериев приемки:
- Все функции системы, указанные в ТЗ, работают в тестовом окружении с использованием реальных данных.
- Система проходит нагрузочные тесты по критериям средней и пиковой нагрузки, указанных в ТЗ.
- Система соответствует требованиям безопасности (например, классу защиты КС2) по результатам аудита независимой лаборатории.
- Предоставлена полная документация: архитектурная схема, руководства пользователя и администратора, документация API.
Если критерии приемки включают пункт о независимом аудите безопасности, поставщик не сможет скрыть проблемы защиты. Если критерии включают нагрузочные тесты, поставщик не сможет поставить систему, которая не справляется с пиковой нагрузкой.
Важно указать, что приемка системы будет считаться успешной только после выполнения всех критериев. Это исключает возможность частичной приемки, когда поставщик поставляет систему с недоделанными функциями, ожидая, что вы примете её из-за срочности.
Что не нужно делать в ТЗ
Несколько распространённых ошибок, которые ослабляют ТЗ и делают его уязвимым для обмана:
- Использовать только общие термины без технической конкретики. Как было показано ранее, это позволяет поставщику выбирать самые дешевые и не всегда подходящие технологии.
- Не включать критерии промежуточных этапов. Это позволяет поставщику затягивать разработку и скрывать проблемы до последнего момента.
- Оставлять критерии приемки субъективными. Это позволяет поставщику манипулировать оценкой на основе впечатлений, не технических результатов.
- Не требовать раскрытия стека технологий и зависимостей. Это создает риски подмены технологий и зависимости от нестабильных внешних компонентов.
- Формулировать требования производительности без деталей пиковой нагрузки и времени реакции. Это позволяет поставщику поставить систему, которая не справляется с реальными нагрузками.
Если вы избегаете этих ошибок, ваше ТЗ становится инструментом не только для описания требований, но и для контроля исполнения.