Без нормального ТЗ…. Техническое задание аутсорсеру: что внутри и кто его пишет

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

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

В этом материале расскажем, из чего состоит техническое задание для подрядчика, кто должен его писать и почему «сделайте как у конкурентов» — это не ТЗ.

База

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

Строгих требований к виду и формату у технического задания нет. Это может быть как документ в Google Docs, так и страницы в Confluence или Notion. Формат, объём и даже наполнение ТЗ остаются на усмотрение клиента и подрядчика. Главное, чтобы в результате все друг друга поняли и остались довольны.

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

В чем сила ТЗ

Техническое задание одинаково важно как для заказчика, так и для подрядчика.
Оно поможет:

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

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

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

Из чего состоит ТЗ

Сначала определимся, что не является техническим заданием.

• Ссылки на проекты конкурентов. Референсы — необходимая часть технического задания, но не всё. Метод «сделайте как у конкурентов» не учитывает особенности работы продукта заказчика, бюджет и сроки.
  ‍
• Ссылка на стандарты. ГОСТ 34 или ISO 9001 — важные документы для разработки информационных систем в госсекторе или продуктов с критической информационной инфраструктурой. Информация из стандартов может дополнить технические требования в ТЗ, но она ничего не говорит о самом продукте.
  ‍
• Простое поручение. «Сделайте сайт» — это не техническое задание, а команда, которую подрядчик может выполнить любым удобным для себя образом.
  ‍

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

Что должно быть в ТЗ

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

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

• Общими.
• Функциональными. Какие функции, разделы и страницы должны быть у продукта. 
• Техническими. Например, требования к безопасности, интеграции с другими сервисами клиента, производительность.
• Требования к дизайну. Например, соответствие брендбуку. 
• Бизнес-требования. Например, данные об аналитике и отчётности или управлении клиентскими данными.

3. Функциональная спецификация интерфейса
В этой части ТЗ рассказываем, из чего состоит интерфейс будущего продукта и как он работает. Например, если наш продукт — мобильное приложение для покупки квартир, то вместе с прототипом интерфейса добавляем описание, где отвечаем на вопрос, по какому принципу упорядочены квартиры в макете каталога.

4. Use cases
Пользовательский сценарий позволяет описать, как потенциальные клиенты будут взаимодействовать с продуктом. Чем больше пользовательских сценариев описано — тем ниже риск ошибки при разработке. Описание сценария должно содержать: 

• Понятный заголовок. Например: «Удаление аккаунта».
• Перечисление всех участников. Например: «система» и «пользователь».
• Описание сценария. Например: «Пользователь нажал на кнопку “Удалить аккаунт”», «Система открыла форму подтверждения удаления аккаунта». 
• Результат. Например: «Аккаунт удалён».

5. Референсы
Ссылки на другие понравившиеся продукты помогают клиенту точнее сформулировать ожидания и видение, а исполнителю — лучше понять клиента.

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

Чего не должно быть в ТЗ

• Размытых формулировок. Стоит избегать формулировок, которые можно трактовать неоднозначно. Например, опытный дизайнер и продавец в магазине могут по-разному воспринять понятие «красивый дизайн». Компетентный подрядчик задаст вопрос по каждой неоднозначной формулировке. Лучше заменить все оценочные и субъективные характеристики на предельно ясные, в идеале — оцифрованные.
  ‍
• Неизвестных слов. В каждой компании есть специфические термины, которые нельзя просто загуглить. Если в компании есть глоссарий — его нужно предоставить исполнителю. Аналогичная ситуация может возникнуть и с обратной стороны — технические термины исполнителя могут быть непонятны клиенту, и их нужно уточнять, чтобы избежать недопониманий.

Кто должен составлять ТЗ

На этот вопрос нет универсального ответа. Но есть несколько вариантов:

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

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

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

А можно без ТЗ?

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

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

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

TL;DR

• Техническое задание — это документ, который может быть написан в свободном формате, но с однозначным формулировками.
  ‍
• Информация о проекте и его целях, требования и use cases должны быть описаны в любом техническом задании.
  ‍
• Качественное ТЗ с чётко прописанными критериями, планом тестирования и передачи проекта помогает управлять расходами.
  ‍
• Хорошо, если в работе над ТЗ участвуют и заказчик, и исполнитель.
  ‍
• Не все проекты и не все компании нуждаются в работе по строгому ТЗ. Гибкие методы управления проектами эффективно комбинируются с не слишком детализированным ТЗ.
  ‍
• Излишне подробное ТЗ — не гарантия качественного результата. По ходу работы требования могут меняться, и это нормально.

‍

Этот материал опубликован на vc.ru

‍