Работа с госзаказчиком в IT: документы, коммуникация и контроль проекта

Работа с госзаказчиком в IT отличается не количеством совещаний, а ценой незафиксированной договорённости. В коммерческом проекте стороны иногда могут быстро изменить приоритеты и оформить решение позже. В государственном контракте объём, сроки, порядок приёмки и основания для изменений заданы гораздо жёстче.

Меня зовут Геннадий Коротков. До веб-студии я десять лет работал на государственной службе и занимался закупками по 44-ФЗ. Ниже — практический взгляд со стороны команды, которой нужно не только разработать систему, но и доказуемо исполнить контракт.

Короткий ответ: устойчивый проект с госзаказчиком строится на трёх контурах — контракт, рабочий процесс и доказательства исполнения. Если хотя бы один из них существует только «в голове», риск спора растёт.

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

Что меняется при работе по 44-ФЗ

Для подрядчика главный документ — не презентация и не протокол первой встречи, а подписанный контракт с приложениями. По статье 34 44-ФЗ условия контракта связаны с извещением, документацией и заявкой участника, а существенные условия нельзя свободно менять по ходу проекта.

Исполнение включает приёмку, оплату и взаимодействие сторон. Статья 94 44-ФЗ отдельно требует от исполнителя своевременно сообщать достоверную информацию о ходе работ и возникающих сложностях. Значит, «мы обсудили это по телефону» — слабая основа для управления риском.

Практически это означает:

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

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

Что проверить до подачи заявки

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

1. Результат должен быть проверяемым

Разберите каждое требование технического задания на три вопроса:

1. Что именно должно быть создано или настроено?
2. Каким способом заказчик проверит результат?
3. Какой документ или артефакт подтвердит выполнение?

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

2. Зависимости должны иметь владельцев и сроки

IT-проект почти всегда зависит от действий заказчика: предоставить API, доступ к серверу, справочники, шаблоны документов, тестовые данные, учётные записи или решение по спорному сценарию.

Для каждой зависимости заранее определите:

• кто предоставляет материал;
• в каком формате;
• к какой дате;
• что делает команда, если срок нарушен;
• влияет ли задержка на общий график.

Если зависимость не видна в плане, позже она превращается в спор «кто кого ждал».

3. Экономика должна учитывать не только разработку

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

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

4. Порядок приёмки нужно читать до начала работ

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

Как организовать старт проекта

На установочной встрече не стоит заново «придумывать ТЗ». Задача встречи — превратить контракт в управляемый план.

После старта у обеих сторон должны появиться:

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

Мы обычно ведём задачи на Kanban-доске: у каждой задачи есть ответственный, статус, срок, комментарии и ссылка на результат. Это не заменяет контрактную переписку, но делает ход проекта прозрачным и позволяет заранее увидеть блокировку.

Полезный ритм — короткий регулярный отчёт по фактам:

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

Как разделить рабочую и официальную коммуникацию

Хорошо работает двухуровневая схема.

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

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

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

Официальное письмо лучше строить так:

1. Ссылка на пункт контракта или ТЗ.
2. Наблюдаемый факт без оценок.
3. Влияние на этап или срок.
4. Предлагаемый законный вариант действий.
5. Решение, которое ожидается от заказчика, и дата ответа.

Один документ — один основной вопрос. Так адресату проще подготовить содержательный ответ, а цепочка решений остаётся читаемой.

Как показывать прогресс, чтобы приёмка не стала сюрпризом

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

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

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

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

Что делать, если заказчик просит изменить функциональность

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

Уточнение помогает однозначно реализовать уже существующее требование и не меняет результат.

Исправление устраняет несоответствие согласованному требованию.

Изменение добавляет новый сценарий, меняет объём, срок, архитектуру или критерии приёмки.

Дальше команда:

1. Сопоставляет запрос с контрактом и ТЗ.
2. Оценивает влияние на сроки, стоимость, безопасность и смежные функции.
3. Письменно описывает варианты в допустимых границах.
4. Передаёт юридическую часть специалисту по закупкам.
5. Не начинает спорную работу, пока основание не оформлено надлежащим образом.

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

Как сообщать о риске

Плохое сообщение: «API до сих пор нет, сроки срываются».

Рабочее сообщение содержит пять элементов:

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

Не преувеличивайте и не угрожайте. Задача фиксации — сохранить управляемость проекта и дать заказчику возможность принять решение вовремя.

Как разбирать конфликт

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

1. Зафиксировать предмет разногласия одной фразой.
2. Собрать относящиеся к нему пункты контракта, ТЗ, протоколы и результаты.
3. Определить, что признают обе стороны.
4. Описать варианты решения и последствия.
5. Провести встречу с людьми, у которых есть полномочия.
6. Оформить итог в предусмотренном канале.

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

Красные флаги для IT-подрядчика

Остановитесь и проведите дополнительную проверку, если:

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

Чек-лист устойчивого проекта

Перед стартом убедитесь, что команда может ответить «да» на вопросы:

• Мы понимаем границы результата и способ его проверки?
• У каждого внешнего доступа есть владелец и срок?
• Решения и риски фиксируются в согласованном канале?
• Заказчик регулярно видит промежуточный результат?
• Требования связаны с задачами и доказательствами выполнения?
• Изменения отделяются от исправлений?
• Команда знает процедуру приёмки и комплект документов?
• Юрист проверяет спорные действия до их совершения?

Главный принцип прост: в работе с госзаказчиком прозрачность — это не дополнительный сервис, а часть исполнения. Хороший подрядчик заранее показывает прогресс, вовремя сообщает о препятствиях и оставляет понятный документальный след.

Если нужен независимый разбор требований, архитектуры и плана до начала разработки, посмотрите услугу IT-консалтинга и предпроектной аналитики. Для сложного продукта также полезен материал о том, как описать бизнес-процесс до автоматизации.

---

Теги: Госзакупки, 44-ФЗ, Управление IT-проектами, Госзаказчик, Приёмка Дата публикации: 27 января 2025 Дата обновления: 25 сентября 2026