Полезный чек-лист разбора ТЗ отвечает на конкретный вопрос: достаточно ли известных условий, чтобы оценить работу и подготовить следующий шаг. Он не должен автоматически выдавать решение «участвовать» по нескольким знакомым словам. Ниже — структура, которую можно применить к поставке, услуге или выполнению работ.
Предмет и ожидаемый результат
Выпишите, что заказчик получает в конце. Различайте процесс и результат: «оказывать поддержку» и «обеспечить указанные показатели» могут означать разный объём ответственности. Сохраните формулировку источника, затем кратко объясните её своими словами.
Проверьте состав поставки или работ. Есть ли монтаж, настройка, обучение, расходные материалы или передача документации? Если они указаны в приложении, добавьте ссылку на приложение. Не считайте задачу ограниченной только заголовком закупки.
Количество и характеристики
Соберите позиции, количества и единицы измерения. Отдельно отметьте минимальные, максимальные и ориентировочные значения. Не складывайте числа разных типов: количество объектов, месяцев обслуживания и обращений описывает разные измерения работы.
Для характеристик укажите способ проверки. Формулировка «совместимость с существующей системой» требует сведений о системе. Если они не опубликованы в прочитанном наборе, зафиксируйте вопрос. ИИ не должен угадывать конфигурацию оборудования заказчика.
Сроки, место и взаимодействие
У даты должен быть контекст: подача предложения, начало работ, завершение этапа или приёмка. Для относительных сроков сохраните событие, от которого начинается отсчёт. Не превращайте условие «после заявки заказчика» в календарную дату без самой заявки.
Проверьте адреса, выезды, график, время реакции и участие сотрудников заказчика. Для ИТ-работ отдельно оцените условия удалённого исполнения. Возможность подключаться удалённо не исключает обязательного присутствия на отдельных этапах.
Приёмка и подтверждающие документы
Найдите описание того, как проверяется результат: документы, испытания, отчёты или иные подтверждения, прямо названные в материалах. Не добавляйте собственный список обязательных документов как требование заказчика.
Сопоставьте приёмку с составом работ. Если ТЗ требует несколько этапов, а проект договора описывает один итоговый акт, сохраните оба условия для проверки. Разбор должен показать расхождение, а не молча исправить документ.
Рабочая матрица
| Пункт | Что записать |
|---|---|
| Требование | Точная суть условия без расширения |
| Основание | Цитата, файл и блок текста |
| Наше подтверждение | Известный факт о возможностях команды |
| Неизвестно | Что нужно получить или уточнить |
| Ответственный | Кто проверит вопрос до решения |
Для состояния используйте понятные значения: подтверждено, не подтверждено, требуется уточнение. «Не подтверждено» не всегда означает несоответствие: иногда у команды просто ещё нет нужного документа или сведений для проверки.
Пример задания
Разбери ТЗ по предмету, объёму, характеристикам, срокам, месту, взаимодействию и приёмке. Собери матрицу требований с цитатами. Неизвестные характеристики нашей команды не заполняй предположениями. Для каждого вопроса предложи, какие сведения нужны, и укажи затронутый пункт документа. Отдельно перечисли непрочитанные приложения.
Затем добавьте реальные сведения о своей компании отдельным шагом и проверьте их релевантность. Не загружайте избыточные персональные или коммерчески закрытые данные только ради полного заполнения таблицы. Для первичного разбора часто достаточно перечня возможностей и ограничений.
Финальная проверка
Перед использованием матрицы откройте оригинал и проверьте самые значимые строки. Особое внимание уделите словам «не менее», «не более», «за исключением» и ссылкам на приложения. Потерянное отрицание способно изменить смысл требования.
Дополните техническую матрицу финансовыми условиями и отдельно проверьте требования к участнику и критерии оценки. Сохраните дату и идентификаторы файлов, чтобы не использовать старый чек-лист после обновления документации.