ТЗ для программиста: что дать исполнителю и какие вопросы задать до старта

Вам прислали «нужно допилить модуль» — и ни слова про входные данные, окружение и то, как проверить результат. Вы начинаете разбираться, задаёте вопросы, а заказчик отвечает «ну там всё понятно, разберись». Знакомо? В доработке кода, в отличие от нового проекта, почти всё держится на деталях: неучтённый краевой случай или отсутствие доступа к тестовому окружению превращаются в часы бесплатной отладки. Разбираем двойную подачу: что заказчик должен дать в ТЗ программисту и какие вопросы задать самому исполнителю, чтобы не переделывать за свой счёт.

Что такое ТЗ для программиста и чем плох «допили на глаз»

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

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

Хорошее ТЗ отвечает на вопрос: что именно принимает метод, что возвращает, как ведёт себя в ошибках и как проверить, что всё работает? Если на это есть ответ — вход, выход, краевые случаи, тесты — задача поставлена.

Структура ТЗ для программиста

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

1. Задача и контекст

Что нужно сделать и зачем: какую бизнес-проблему решает доработка. В каком модуле или сервисе работаем. Контекст помогает принять правильные решения там, где ТЗ не покрывает все детали.

2. Входные и выходные данные

Что принимает метод или функция и что возвращает: форматы, типы, структуры. Пример входного запроса и ожидаемого ответа. Это основа корректной реализации.

3. Окружение и стек

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

4. Поведение и краевые случаи

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

5. Объём: что входит и не входит

Чёткие границы задачи: что делаем в рамках этой доработки, а что — отдельная задача. Это защищает от расползания объёма и споров о том, входило ли «ещё вот это».

6. Критерии приёмки

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

7. Формат передачи

Как сдаётся результат: ветка в репозитории, pull request, код-ревью, документация. Нужны ли тесты и в каком объёме. Как происходит слияние.

8. Правки

Сколько кругов правок входит в задачу и что считается правкой, а что — новой задачей. Фиксируйте письменно.

Раздел ТЗ: что писать и частые ошибки

Мини-пример: фрагмент ТЗ на доработку

Чтобы было понятнее, вот как может выглядеть реальный фрагмент ТЗ на доработку метода:

Задача: доработать метод создания заказа — добавить валидацию суммы.

Вход: JSON с полями «user_id», «amount», «items». Выход: объект с «order_id» или код ошибки.

Поведение: при сумме больше нуля заказ создаётся и возвращается «order_id». При сумме меньше или равной нулю метод возвращает код 422 и пишет ошибку в лог, заказ не создаётся.

Краевые случаи: пустой список товаров — код 400; отсутствует «amount» — код 400.

Покрыть юнит-тестами: корректный заказ, отрицательная сумма, пустые товары.

Передача: ветка от основной, pull request с код-ревью.

Такое ТЗ позволяет сразу написать код и тесты, а заказчику — проверить результат по конкретным сценариям.

Что уточнит хороший программист

Если вам прислали размытую задачу, не начинайте кодить сразу. Задайте вопросы — это защита вашего времени:

• Какую бизнес-проблему решает доработка и какой ожидаемый результат?
• Какие форматы входных и выходных данных, есть ли примеры?
• Какие краевые случаи учесть: пустые значения, ошибки, лимиты?
• Какое окружение и как получить доступ к тестовой среде и репозиторию?
• Нужны ли тесты и в каком объёме?
• Как сдать результат: ветка, pull request, код-ревью?

Зафиксируйте ответы в переписке заказа. На Workink такая переписка имеет силу ТЗ — если потом заказчик скажет «я хотел по-другому», у вас будет подтверждение изначальных договорённостей.

Чек-лист перед стартом кода

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

Если хотя бы на два пункта нет ответа — сначала уточните, потом приступайте. Так вы защитите себя от бесплатных переделок.

Что дальше

Хорошее ТЗ — это не каприз, а способ сэкономить время обеим сторонам. На Workink заказчик и программист фиксируют договорённости в чате заказа — такая переписка имеет силу ТЗ, а деньги защищены безопасной сделкой до приёмки. Комиссия — 11% за заказ и 0% за вывод.

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