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

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

На нашем сайте 31 июля 2026 года нашли потерю поля с описанием сцены при сохранении новости. Снаружи это выглядело как правка одного поля. По коду выяснилось, что поле перечисляли вручную в разных местах и исправить нужно все пути сохранения.

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

Что исполнитель должен проверить до обещания цены? Нужно найти участок изменения, запустить проект и увидеть, как он связан с соседними частями. По снимку экрана нельзя узнать, сохраняет ли система данные в одном месте или повторяет это действие в нескольких.

В истории с полем новости проверка изменила границы правки: исправить отдельный экран было недостаточно. Поле свели в общий способ подготовки данных для сохранения. Это пример из кода vibecoding.ru, а не оценка заказного проекта.

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

Что получить вместе с предварительной ценой? Объяснение, какой результат исполнитель оценил, на каком состоянии проекта и что пока считает верным без проверки. Такая оценка помогает выбрать следующий шаг. Мартин Фаулер предлагает начинать именно с решения, ради которого нужна оценка.

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

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

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

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

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

Можно ли взять скорость машины и умножить её на стоимость часа? Для чужого проекта это не даст проверяемой сметы. В открытом журнале машины опубликован ряд из 115 собственных задач, срез на 27 августа 2026 года. Он измеряет путь от реплики владельца в чате до мержа изменения.

По этому ряду медиана составляет около 25 минут, но 41 задача заняла час или больше. Длинный хвост включает смотры с владельцем; автономные ветки конвейера исключены. Это время прохождения собственной задачи, а не чистое время написания кода и не обещание срока заказчику.

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

Машина работает в среде с заранее записанными правилами. На живом /open 8 октября указаны 387 тысяч строк спецификаций и 391 тысяча строк кода. Эти близкие объёмы показывают, сколько контекста накоплено у собственного проекта; число строк не определяет цену изменения.

В неизвестном коде сначала предстоит восстановить часть такого контекста. ИИ-агент может быстро подготовить правку, но инженер должен проверить, что он нашёл действующее поведение и не пропустил соседний путь. Поэтому переносить наши 25 минут на ваш проект нельзя.

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

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

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

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

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

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

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

Как сопоставить цену одной доработки с агентным потоком? Сначала сравните одинаковый принимаемый результат и состав работ. Разовая оценка относится к этому изменению. Месячная цена относится к периоду работы и сама по себе не отвечает, сколько будет стоить завершение всего проекта.

На 8 октября 2026 года подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц. Инженер ведёт машину агентов: одна задача в работе, следующая ждёт в очереди, изменения передают в ветку заказчика. Цена месяца фиксирована; цена завершения всего проекта из неё не следует.

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

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

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

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

1. Ограничьте принимаемый результат до обсуждения цены.

2. Проверьте затронутый код и отделите подготовку от изменения.

3. Получите вместе с оценкой допущения и условия её пересмотра.

4. Включите проверки и приёмку в состав работы.

5. После приёмки сохраните расхождения и используйте их в следующей оценке.