Техническое задание: как описать задачу, чтобы получить нужное

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

Структура, которая работает

1. 01Цель: какую проблему решаем и что изменится в работе компании после запуска.
2. 02Роли: кто пользуется системой и что каждому из них доступно.
3. 03Сценарии: последовательность шагов для каждой роли от начала до завершения задачи.
4. 04Данные: какие сущности храним, какие поля обязательны, что с чем связано.
5. 05Интеграции: с какими системами обмениваемся данными и в какую сторону.
6. 06Ограничения: сроки, нагрузка, требования к хранению данных, устройства пользователей.
7. 07Критерии приёмки: проверяемые утверждения, по которым работа считается выполненной.

Как писать критерии приёмки

Критерий приёмки — утверждение, которое можно проверить и получить однозначный ответ. Формулировка «форма должна работать быстро» проверке не поддаётся. Формулировка «после отправки формы заявка появляется в списке администратора в течение пяти секунд» — поддаётся.

Описание данных экономит больше всего времени

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

Заказ
  номер            обязательное, уникальное
  клиент           ссылка на клиента, обязательное
  статус           новый / в работе / выполнен / отменён
  сумма            считается из позиций, не вводится вручную
  адреса доставки  от одного до нескольких
  комментарий      необязательное, до 1000 символов
  создан           дата и время, заполняется системой

Позиция заказа
  заказ            ссылка на заказ
  товар            ссылка на товар
  количество       целое, больше нуля
  цена             фиксируется на момент заказа, не берётся из товара

Чего в задании быть не должно

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

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

Задание как живой документ

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