ТЗ для программиста пример: готовый образец задания и критерии приёмки

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

Что такое ТЗ для программиста и когда оно спасает

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

Хорошее ТЗ особенно нужно, когда задача касается не isolated-кнопки, а работающего продукта:

• Новая функция в существующей системе. Нужно не сломать смежные модули, учесть права, статусы, интеграции и историю данных.
• Интеграция с внешним сервисом. Важно описать формат обмена, обработку таймаутов, ретраев, дублей, ключей и тестовых контуров.
• Доработка API или базы данных. Здесь критичны backward compatibility, миграции, индексы, нагрузка и контракты для клиентов.
• Исправление бага с бизнес-последствиями. Мало «починить», нужно понять причину, диапазон затронутых данных, план отката и мониторинг.
• Передача задачи между командами. Если код писали разные разработчики, ТЗ становится языком согласования: что уже есть, что нужно, где границы и кто принимает результат.

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

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

Специфика ниши программиста: 5 особенностей, которые влияют на ТЗ

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

1. Программисту нужен контракт, а не описание желания

Фраза «сделай быстрый поиск» не является требованием. В ТЗ нужно описать контракт: какие параметры принимает система, какие возвращает, какие ошибки возможны, как ведёт себя при пустом вводе, длинном запросе, отсутствии прав, недоступном сервисе и параллельных изменениях. Для API это метод, путь, схема запроса/ответа, коды состояний, лимиты, версионирование. Для UI — состояния экранов, валидации, disabled-элементы, loading, error, empty. Для фоновых задач — триггер, идемпотентность, ретраи, dead letter, метрики.

Хороший приём — писать требования в формате: «При входных данных X система должна вернуть Y; при ошибке Z показать A и залогировать B». Такой стиль снижает число трактовок и помогает тестировщику сразу собрать чекалист.

2. Definition of Done важнее описания фичи

Многие заказчики думают, что задача готова, когда код написан. Для программиста готовность обычно включает: реализацию, unit-тесты, интеграционные тесты, проверку на staging, code review, обновление документации, миграции, флаги, мониторинг, план откатa и передачу релиза. Если в ТЗ нет Definition of Done, исполнитель может сдать «работает у меня», а заказчик будет ждать «работает в проде».

В ТЗ стоит отдельно перечислить, что входит в Done: например, «PR открыт, тесты зелёные, review пройден, миграция проверена на копии прод-данных, метрики добавлены, инструкция обновлена, feature flag выключен по умолчанию».

3. Краевые случаи и данные решают больше, чем интерфейс

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

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

4. Среда, доступы и откат — часть задачи, а не «потом»

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

Отдельный блок — откат. Любое изменение в проде должно иметь план возврата: feature flag, миграция down, совместимость со старой версией, процедура экстренного выключения, уведомления дежурному. В ТЗ нужно указать, кто отвечает за деплой, кто согласует релизное окно и при каких условиях откат обязателен.

5. AI ускоряет код, но не снимает ревью, безопасность и ответственность

В 2026 году разработчики активно используют AI-ассистентов: генерация boilerplate, объяснение чужого кода, написание тестов, рефакторинг, подсказки по API, поиск уязвимостей. Это ускоряет рутину. Но AI не отвечает за бизнес-логику, корректность миграций, защиту персональных данных, лицензионную чистоту зависимостей, производительность на реальных объёмах и соответствие стандартам компании.

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

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

1. Цель: какую бизнес-проблему решает код

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

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

2. Требования: функциональные, нефункциональные, данные и безопасность

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

Функциональные требования — что система должна делать:

• пользовательские сценарии: создание, редактирование, удаление, поиск, фильтрация, экспорт;
• правила бизнес-логики: статусы, переходы, ограничения, проверки;
• интеграции: запросы, ответы, обработка ошибок, ретраи;
• уведомления: каналы, шаблоны, частота, отписка;
• права и роли: кто что видит и может изменять.

Нефункциональные требования — как система должна работать:

• производительность: время ответа, RPS, объём данных, лимиты;
• надёжность: доступность, идемпотентность, обработка сбоев;
• масштабируемость: рост нагрузки, горизонтальное расширение;
• безопасность: аутентификация, авторизация, шифрование, PII, audit log;
• наблюдаемость: логи, метрики, трейсы, алерты.

Требования к данным — с чем работает система:

• источники истины, схемы, форматы, валидации;
• миграции, история изменений, мягкое удаление;
• тестовые данные, анонимизация, объёмы для нагрузочного теста;
• правила обработки дублей, конфликтов и устаревших записей.

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

В ТЗ для программиста нужен явный список границ. Например: «Входит: backend-эндпоинт, фильтрация по 4 параметрам, пагинация, права ролей, unit- и интеграционные тесты, обновление Swagger, feature flag. Не входит: редизайн админки, мобильное приложение, историческая миграция данных за 2019 год, настройка дашбордов в BI, оптимизация смежного отчёта».

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

4. Сроки: этапы, код-фриз, ревью и релизное окно

Для программиста срок — это не одна дата «сдать через неделю». Нужен план: оценка, разработка, самопроверка, code review, тестирование, staging, релиз, мониторинг. Отдельно укажите код-фриз, окно деплоя, ответственного за релиз и условия переноса.

Хорошая практика — фиксировать зависимости: доступы к песочнице внешнего сервиса, предоставление тестовых данных, согласование API-контракта, решение по миграции. Если зависимость не закрыта, этап не должен считаться просроченным. Для крупных задач полезно заранее разложить работу по вехам через план для ТЗ.

5. Критерии приёмки: как понять, что код готов

Критерии приёмки должны быть сценарными и проверяемыми. Не «работает нормально», а:

• при фильтрации по статусу «оплачен» возвращаются только заказы с этим статусом;
• при пустом результате показывается понятное сообщение, а не ошибка 500;
• пользователь без права на просмотр чужих подразделений видит только свои данные;
• при 100 тысячах записей ответ приходит не дольше 1,5 секунды на staging;
• повторный запрос с теми же параметрами не создаёт дублей;
• все новые эндпоинты покрыты тестами и описаны в OpenAPI;
• feature flag позволяет выключить функцию без редеплоя.

Если критерии зафиксированы, приёмка перестаёт быть спором о вкусе и становится проверкой соответствия задаче.

6. Формат передачи: что заказчик получает после разработки

Код нельзя принять, если не переданы артефакты. В ТЗ нужно указать состав передачи:

• ссылка на PR или коммиты в согласованной ветке;
• описание изменений: что добавлено, что изменено, что удалено;
• результаты тестов: unit, integration, e2e, нагрузочные при необходимости;
• инструкция по локальному запуску и миграциям;
• обновлённая документация: API, схема БД, runbook, changelog;
• доступы к staging, тестовые учётные записи, примеры запросов;
• план откатa и условия использования feature flag;
• список известных ограничений и технических долгов, если они есть.

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

7. Правки: что считается багом, а что изменением требований

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

В ТЗ стоит зафиксировать: баги устраняются в рамках задачи, изменения объёма оформляются письменно с пересчётом срока и стоимости. На Workink такие договорённости удобно фиксировать в чате заказа: переписка имеет силу ТЗ и помогает отделить правку от новой работы без долгих споров.

Готовый пример ТЗ

Ниже — рабочий пример ТЗ для программиста на доработку админ-панели. Его можно адаптировать под backend, frontend, мобильную разработку, 1С, интеграцию или внутренний сервис. Главное — сохранить структуру: контекст, контракт, границы, тесты, среда, приёмка и передача.

Задача: добавить фильтрацию и поиск заказов в админ-панели поддержки.

Контекст: оператор поддержки тратит в среднем 40 секунд на поиск заказа по номеру и статусу. Сейчас поиск работает только по точному номеру, без фильтра по дате, сумме и менеджеру. При 120 тысячах заказов страница загружается дольше 4 секунд.

Цель: сократить среднее время поиска заказа оператором до 10 секунд и исключить выдачу заказов из других подразделений.

Пользователи и роли: оператор видит заказы своего подразделения; руководитель подразделения видит все заказы подразделения; администратор видит все заказы. Обычный клиент не имеет доступа к этой странице.

Текущее поведение: на странице «Заказы» есть поле поиска по номеру. Фильтры отсутствуют. Пагинация 20 записей. Сортировка по дате создания descending. Права частично проверены на фронте, но не на бэкенде.

Ожидаемое поведение:

• добавить фильтры: статус, период создания, сумма от/до, менеджер, способ оплаты;
• поиск должен работать по номеру заказа, email клиента и последним 4 цифрам телефона;
• фильтры комбинируются между собой;
• результат сортируется по дате создания descending, с возможностью переключения на сумму;
• пагинация 20/50/100 записей;
• при отсутствии результатов показывать сообщение «Ничего не найдено. Попробуйте изменить фильтры»;
• при ошибке сервера показывать понятное сообщение и кнопку «Повторить».

API-контракт: GET /admin/orders с параметрами page, limit, status, date_from, date_to, amount_min, amount_max, manager_id, payment_method, query. Ответ: items, total, page, limit, sort. Коды: 200 успех, 400 невалидные параметры, 403 нет прав, 422 семантическая ошибка фильтра, 500 внутренняя ошибка.

Backend-требования: проверка прав на сервере; индексация по created_at, status, manager_id; ограничение максимальной глубины пагинации; защита от SQL-инъекций и переполнения; логирование медленных запросов; метрика времени ответа.

Frontend-требования: состояние загрузки, ошибка, пустой результат; сброс фильтров; сохранение параметров в URL; доступность с клавиатуры; корректная работа на разрешении от 1280 px и мобильной версии админки при наличии.

Данные и миграции: миграция для добавления индексов; проверка на копии прод-данных объёмом не менее 150 тысяч заказов; обратная миграция обязательна.

Нефункциональные требования: 95% запросов отвечают не дольше 1,5 секунды при 100 одновременных операторах на staging; CPU не выше 70% при пиковой нагрузке; ошибки 5xx не более 0,1% на тестовом прогоне.

Безопасность и данные: телефон и email маскировать в логах; не выводить полные персональные данные в публичных ошибках; доступ к API только по авторизованной сессии админки.

Тесты: unit-тесты на сервис фильтрации; интеграционные тесты API с проверкой прав, пагинации, пустых значений и невалидных параметров; e2e-тест основного сценария поиска; нагрузочный тест на 100 виртуальных пользователей.

Feature flag и откат: новую фильтрацию включать под флагом admin_orders_filters. При проблемах флаг выключается без редеплоя. План откатa: revert миграции индексов, если они вызывают деградацию, и возврат к старой версии API.

Definition of Done: PR открыт и пройден ревью; тесты зелёные; миграция проверена на staging; документация OpenAPI обновлена; метрики и логи добавлены; feature flag описан в runbook; операторы получили короткую инструкцию; известное ограничение — поиск по телефону только по последним 4 цифрам — зафиксировано в UI.

Не входит: редизайн всей админки, экспорт в Excel, сохранение пресетов фильтров, мобильное нативное приложение, изменение модели данных заказа, доработка смежного модуля возвратов.

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

Критерии приёмки результата для программиста

Задачу можно принимать, если выполнены измеримые условия. Ниже — базовый набор критериев, который подходит для большинства разработки-задач.

• Поведение системы соответствует ТЗ. Все согласованные сценарии работают: успех, ошибка, пустой результат, отсутствие прав, повторная отправка, параллельные изменения.
• API и данные совместимы. Контракт не ломает существующих клиентов, миграции проходят обратно, схема данных согласована, тестовые примеры актуальны.
• Тесты покрывают критичные риски. Есть unit- и интеграционные тесты для бизнес-логики, проверки прав, ошибок внешних сервисов и краевых значений. При необходимости есть e2e и нагрузочный тест.
• Нефункциональные показатели достигнуты. Время ответа, нагрузка, потребление ресурсов, ошибки, лога и метрики соответствуют цифрам из ТЗ. Проверка выполнена на контуре, приближенном к прод.
• Безопасность обеспечена. Авторизация и аутентификация работают на сервере, PII не утекает в логи и ошибки, зависимости не имеют критичных уязвимостей, секреты не закоммичены.
• Наблюдаемость настроена. Есть логи, метрики, трейсы или алерты для критичных операций. Ошибки не «проглатываются» молча.
• План откатa существует и проверен. Feature flag, миграция down, revert-стратегия или инструкция для дежурного позволяют быстро вернуть систему в рабочее состояние.
• Документация обновлена. OpenAPI, README, runbook, changelog, схема БД или инструкция по эксплуатации приведены в соответствие с изменениями.
• Code review пройден. Код понятен команде, соответствует стилю проекта, не содержит лишних зависимостей, магических чисел и дублирования без обоснования.
• Артефакты переданы. Ссылка на PR, результаты тестов, доступы к staging, тестовые данные, инструкции и список известных ограничений переданы заказчику или команде.

Вопросы для уточнения до старта

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

• Какую бизнес-метрику должно улучшить изменение и к какому сроку?
• Кто пользователи и какие роли имеют доступ к функции?
• Какие сценарии обязательны, а какие можно отложить на второй этап?
• Есть ли существующий API, экран или модуль, который нельзя сломать?
• Какие данные являются источником истины и где хранятся?
• Нужны ли миграции, обратные миграции и проверка на объёме прод-данных?
• Какие внешние сервисы участвуют и есть ли доступы к песочнице?
• Как система должна вести себя при таймауте, дубле, частичном успехе и отмене?
• Какие требования к скорости, нагрузке, доступности и безопасности?
• Нужны ли feature flag, мониторинг, алерты и runbook?
• Где будет проходить приёмка: local, staging, preview-окружение?
• Кто пишет тесты, кто выполняет code review, кто утверждает релиз?
• Какие артефакты должны быть переданы: PR, документация, схемы, инструкции?
• Что считается багом, а что изменением требований после согласования?
• Есть ли юридические ограничения: персональные данные, лицензия, секретность, аудит?
• Используются ли AI-инструменты и кто проверяет сгенерированный код?

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

Чек-лист готовности ТЗ

Перед тем как передавать задачу программисту, пройдитесь по короткому чек-листу. Если хотя бы два пункта не закрыты, ТЗ лучше дополнить.

• Цель сформулирована через бизнес-эффект и метрику, а не через «сделай удобно».
• Описаны пользователи, роли, сценарии и границы доступа.
• Зафиксирован контракт: API, данные, состояния, ошибки, совместимость.
• Перечислены краевые случаи: пусто, много, параллельно, недоступно, повторно.
• Указаны нефункциональные требования: скорость, нагрузка, безопасность, наблюдаемость.
• Определены среда разработки, тестовые данные, доступы и порядок приёмки.
• Прописаны Definition of Done, артефакты передачи и план откатa.
• Разведены баги, правки и новые задачи, согласован порядок изменений.

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

Риски и типовые споры при постановке задачи программисту

Три ситуации, в которых чаще всего возникают конфликты между заказчиком и исполнителем:

• «Работает у меня, но не в проде». Причина — нет требований к среде, данным и нагрузке. Профилактика: указать staging, объём тестовых данных, метрики производительности и условия приёмки.
• «Мы просили одно, а сделали другое». Причина — описан только happy path. Профилактика: добавить сценарии ошибок, прав, пустых значений, повторных запросов и совместимости.
• «Задача затянулась из-за мелочей». Причина — размыт объём и Definition of Done. Профилактика: зафиксировать, что входит, что не входит, какие тесты обязательны и когда задача считается закрытой.

Как заказать программиста на Workink

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

Платформа снижает типовые риски разработки:

• Безопасная сделка: деньги находятся в резерве до приёмки работы. Вы платите за результат, а не за обещание написать код.
• Комиссия 11% за заказ и 0% за вывод: прозрачные условия без удержания при выводе средств.
• Доработки бесплатно до соответствия ТЗ: если реализация не соответствует согласованным требованиям, исполнитель дорабатывает результат.
• Договорённости в чате имеют силу ТЗ: всё, что вы обсудили по API, тестам, срокам, доступам и правкам, фиксируется в переписке и защищает обе стороны.

Если вы заказчик, начните с сильного ТЗ: цель, контракт, edge cases, нефункциональные требования, приёмка и передача. Если вы программист, просите эти данные до старта — они защищают от бесконечных «а можно ещё вот так» и помогают сдать задачу без споров на финальном этапе.

Найти исполнителя Разместить заказ Защита покупателей