Как описать доработку сайта для оценки в часах

Опиши результат глазами того, кто будет пользоваться

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

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

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

Какие вводные влияют на часы

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

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

Назови зависимости. Функция может ждать новую форму, работу CRM, выпуск на продакшен или согласование дизайна. Для каждой укажи, кто отвечает и что должно быть готово. Сложно оценить объём, если задача требует работы другой команды, но её роль неизвестна. Такие зависимости полезно обсуждать до начала, чтобы точная оценка опиралась на доступные возможности, а не на ожидание, что всё получится автоматически.

Раздели основной сценарий и исключения

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

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

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

Пример оценки на калькуляторе

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

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

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

Что запросить в оценке

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

В ZEVY доработки оцениваются по ставке 8 000 ₽/час. Для первой оценки полезно описать задачу именно в таком виде. Можно начать с короткого анализа, если причину или возможности платформы пока не видно. После него проще согласовать сценарий, часы и способ приёмки. Так разговор о стоимости опирается на конкретный результат, который можно проверить на рабочем сайте.

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

Как вести задачу после согласования

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

Минимальный пример, с которого можно начать

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

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