Техническое задание: как написать ТЗ, понятное исполнителю

Нечёткая формулировка возвращается спором на сдаче

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

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

• Названы пользователи и результат для каждого.
• Работа отделена от соседних изменений сайта.
• Приёмка описана до реализации.

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

Цель объясняет, зачем нужны требования

Сначала опишите потерю или задачу, которую решает новая работа. Список функций без цели трудно сокращать и оценивать. Он быстро растёт.

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

• Проблема описана через действие человека.
• Ожидаемый результат достижим в выбранном объёме.
• Каждое обязательное поле имеет назначение.

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

Границы защищают первую версию

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

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

• Перечислены затронутые страницы.
• Назван получатель данных.
• Отдельно отмечены исключённые изменения.
• Зависимости от доступов и материалов видны в плане.

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

Требование состоит из события и результата

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

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

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

• Условие отделено от действия.
• Результат виден или доступен для воспроизведения.
• У каждого пункта есть признак сдачи.

Ошибки описывают вместе с успешным действием

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

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

• Пустое обязательное поле даёт понятную подсказку.
• После исправления доступен повтор.
• После сбоя связи введённые данные остаются доступными для повтора.
• Повторное нажатие не создаёт неконтролируемые копии.

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

Данные, роли и аналитика получают точные названия

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

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

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

• Место приёма названо однозначно.
• Ответственный видит нужные данные.
• Событие аналитики связано с выбранным результатом.

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

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

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

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

• Образец связан с приложениями.
• Ограничения относятся к реальному объёму.
• Отсутствующие сведения помечены как требующие решения.

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

Когда нужен стандарт и как менять документ

Формат ТЗ выбирают по предмету работы и договорённостям. Для создания автоматизированных систем существует отдельный стандарт. Его область применения ограничена.

В карточке Росстандарта ГОСТ 34.602-2020 указаны требования к составу и содержанию ТЗ на автоматизированную систему. Там же документ имеет статус действующего и дату введения в действие. Это основание обсуждать подходящий формат с исполнителем, когда разрабатывается такая система: для небольшой маркетинговой задачи стороны сначала определяют предмет и состав результата, а затем выбирают документ, который поможет принять именно эту работу. Для формы сайта важнее полнота результата и приёмки, чем внешнее сходство с большим документом.

Изменения ведут версиями с понятным основанием: если добавлено новое поле или место получения данных, стороны оценивают влияние на работу и дату сдачи. Молчаливое редактирование общей страницы документа лишает исполнителя отправной точки и затрудняет разбор, что именно было принято к выполнению.

• Текущая версия названа явно.
• Изменение описывает причину и затронутые требования.
• Решение о стоимости и сроке связано с изменением объёма.

Прочитайте задание глазами принимающего сотрудника

Самостоятельная проба проста: попробуйте провести сдачу по написанному документу. Для каждого требования найдите действие и ожидаемый итог. Спорные слова выпишите рядом.

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

• Можно повторить успешное и неуспешное действие.
• Назван человек, который принимает результат.
• Оставшиеся вопросы собраны отдельным списком.

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