Какие вводные нужны для оценки отдельного модуля без готового ТЗ

Подготовлено 23 октября 2026 года

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

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

Начните с результата, а не с количества часов

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

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

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

Покажите обязательный минимум вводных

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

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

Отделите известное от допущений

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

У допущения должны быть понятные последствия. Например: «Предварительно рассматриваем получение документа через существующий интерфейс. Если такого способа нет, состав пересматривается». Это полезнее, чем спрятать неизвестность внутри одной суммы.

Назовите зависимости и окно ресурса

Дата, к которой клиенту нужен результат, и дата, на которую исполнитель подтвердил ресурс, — разные сведения. Желание начать на следующей неделе ещё не означает, что команда зарезервирована. Эти условия нужно сверять отдельно.

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

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

Сравнивайте варианты одинакового состава

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

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

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

Что получит клиент после первого разговора

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

Одно действие пользователя:
Нужный результат и принимающий:
Что входит и что исключено:
Существующие системы и интерфейсы:
Безопасный пример:
Как проверим результат:
Подтверждённые вводные:
Допущения и их влияние:
Что неизвестно и кто уточняет:
Желаемая дата клиента:
Подтверждённый ресурс исполнителя, если есть:
Следующий согласованный шаг:

Эту карточку можно использовать для обсуждения отдельного участка системы. Заполните известное и оставьте честные вопросы вместо предположений. Готовое ТЗ не является обязательным условием обращения.