Блок 7 · Урок 4 из 4

Ставить ТЗ и принимать работу

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

⏱ ≈ 8 минут 📋 ТЗ, приёмка, тесты 🎯 цель: ставить задачу с критериями и принимать результат по списку

Зачем это вам

Это главный навык заказчика — и финальная тема всего курса. Всё, что вы изучили раньше: слои приложения, API, безопасность, деплой, ошибки и git, — нужно именно для того, чтобы здесь, в разговоре с агентом, говорить конкретно и понимать, что он делает. Когда агент говорит «сформулируй критерии приёмки» или «напиши тесты» — это не магия, а рабочий инструмент. После этого урока вы будете знать, что за этим стоит, и сможете использовать его сознательно.

Суть

Хорошее ТЗ — это цель плюс проверяемый список «готово, если…»

«Сделай кнопку входа» — плохое ТЗ (техническое задание — документ, описывающий, что нужно сделать). «Кнопка входа: при верном пароле переходит на дашборд, при неверном — показывает ошибку под полем, кнопка недоступна во время запроса» — хорошее.

Хорошее ТЗ состоит из трёх частей. Первая — цель и контекст: зачем это нужно, не просто «что сделать». Агент с контекстом выбирает лучшее решение сам. Вторая — критерии приёмки (acceptance criteria — список проверяемых условий «готово, если…»): каждый пункт проверяется отдельно, результат однозначен. Третья — границы: что явно не входит в задачу и какие есть ограничения (без новых внешних сервисов, без изменений в базе, к такому-то числу).

Чем точнее критерии — тем меньше ситуаций «агент сделал, но не то». Размытое ТЗ агент трактует как хочет: не потому что плохой, а потому что у него нет другой информации.

📌 Правило проверки ТЗ: если каждый пункт критериев можно проверить за минуту — «зашёл с верным паролем, получил доступ», «ввёл пустое поле, увидел ошибку» — ТЗ готово к работе.

Приёмка результата

Проходите по списку, а не «смотрите на глаз»

Когда агент сдаёт работу, не оценивайте общее впечатление — берите свой список критериев и проходите по каждому пункту. Работает ли это при верном вводе? А при неверном? А при пустом поле? А если нет интернета?

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

Тесты — автоматическая приёмка

Тест — это ваш критерий «готово», записанный в код

Тест (test) — это код, который сам проверяет, что приложение делает то, что должно. Пример: «при неверном пароле функция входа возвращает ошибку». Вы не проверяете руками — проверяет код, автоматически.

Зачем это заказчику? Потому что тесты — это ваши критерии приёмки, записанные так, что их можно запустить в любой момент. После каждой правки агент запускает тесты и видит, не сломал ли что-то старое. Это называется регрессия — когда новая правка ломает то, что раньше работало. Тесты регрессию и ловят.

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

📌 Практически: «зелёные тесты» (все прошли) = прежнее поведение не сломалось. «Красные тесты» = что-то отвалилось. Это объективно, без разночтений.

Аналогия, которую можно пересказать

Заказ ремонта у подрядчика

«Сделайте красиво»— расплывчатое ТЗ: получите что угодно
ТЗ с размерами и сроком— цель плюс критерии приёмки: конкретно и проверяемо
Проход по списку при приёмке— проверка результата по критериям, не «на глаз»
Чек-лист, приложенный к договору— тесты: записанные критерии
Прогнать чек-лист после каждой правки— автотесты ловят регрессии

Плохой заказ: «сделайте красиво» — получите что угодно. Хороший: «кухня 12 м², розетки здесь, плитка такая, готово к первому числу». Приёмка — не «вроде ничего», а проход по списку: каждая розетка работает? плитка ровная? Тесты — чек-лист, приложенный к договору: после каждой доработки снова прогнали весь список, убедились, что ничего не отвалилось. Чем чётче «готово, если…», тем меньше споров и переделок.

Запомните одно

Внятные критерии приёмки — это и есть управление агентом

Вы прошли весь курс: поняли, как устроен веб, где живут данные, как работают API, что делает фронтенд, как не сгореть на безопасности, как доставить приложение и читать его ошибки. Всё это — чтобы здесь сказать агенту конкретно, что нужно, и принять результат не «на глаз», а по списку. Грамотный заказчик — это тот, кто знает достаточно, чтобы сформулировать критерии. Теперь вы знаете.

Что это даёт на практике

Фраза агента → что он имеет в виду

«Сформулируй критерии приёмки»
Перечисли проверяемые «готово, если…» — конкретные условия, по которым можно однозначно сказать, что задача выполнена.
«Напиши тесты на это»
Зафиксируй нужное поведение автопроверкой — чтобы после любой будущей правки это работало так же.
«Проверь, что ничего не сломалось»
Прогоним тесты на регрессии — убедимся, что новая правка не задела то, что раньше работало.
«Что вне рамок задачи?»
Обозначь, что явно НЕ нужно делать сейчас — это помогает агенту не уходить в сторону.

ТЗ (техническое задание) — что нужно, зачем и в каких границах.

Критерии приёмки (acceptance criteria) — проверяемый список «готово, если…».

Приёмка — проверка результата по критериям, включая граничные случаи.

Тест (test) — код, автоматически проверяющий нужное поведение.

Регрессия — когда новая правка ломает то, что работало раньше; тесты её и ловят.

Проверьте себя

Четыре вопроса с мгновенной проверкой

1. Что делает ТЗ хорошим?

2. Что такое критерии приёмки?

3. Зачем заказчику тесты?

4. Что такое регрессия?

Куда мы шли

Программа курса — 7 блоков