Без нормального ТЗ… Техническое задание аутсорсеру: что внутри и кто его пишет
«Придумайте красивый дизайн», «хочу хороший сайт», «сделайте приложение для Android». Это варианты запросов, с которыми клиенты приходят к подрядчикам. Дизайнер, разработчик, флорист — любой подрядчик может столкнуться с туманными формулировками клиента.
Такие пожелания — неплохая отправная точка для начала сотрудничества. Однако чтобы работа над проектом шла эффективно и комфортно для обеих сторон, понадобится техническое задание.
Андрей Головин, руководитель группы управления проектами arcsinus рассказывает, из чего состоит техническое задание для подрядчика, кто должен его писать и почему «сделайте как у конкурентов» — это не ТЗ.
База
Техническое задание — документ, который содержит основные требования к проекту. ТЗ — своего рода руководство для подрядчика.
Строгих требований к виду и формату у технического задания нет. Это может быть как документ в Google Docs, так и страницы в Confluence или Notion. Формат, объём и даже наполнение ТЗ остаются на усмотрение клиента и подрядчика. Главное, чтобы в результате все друг друга поняли и остались довольны.
При работе над сложными цифровыми продуктами может понадобиться несколько разных ТЗ, например, одно — для разработчиков, другое — для дизайнеров. Опытные подрядчики используют бриф для опроса клиентов и шаблон технического задания.
В чем сила ТЗ
Техническое задание одинаково важно как для заказчика, так и для подрядчика. Оно поможет:
- Оценить профессионализм исполнителя. Внимание к деталям, глубина уточняющих вопросов, оценка сроков разработки — во время подготовки ТЗ всё это покажет уровень компетентности подрядчика и его заинтересованность в проекте.
- Закрепить чёткое описание продукта и требований к нему. Разработка цифрового продукта требует месяцев усердного труда целой команды специалистов, а также ресурсов со стороны клиента. В процессе коммуникации стороны могут неверно истолковать пожелания друг друга.
Зафиксированные письменные требования — гарантия того, что команда создаёт именно тот продукт, который нужен, и не будет тратить ресурсы на исправление ошибок, допущенных на этапе обсуждения продукта. Документ также убережёт клиента и подрядчика от разногласий и незапланированных изменений в концепции.
- Регулировать бюджет. Стоимость проекта и конечный результат напрямую зависят от качества ТЗ и прописанных в нём целей проекта, которые разделяют заказчик и исполнитель. В техническом задании можно подробно описать и оценить каждый этап работы: так клиент увидит, за что платит, а подрядчик поймёт, какие ресурсы потребуются.
- Упростить приёмку работ. С чётким ТЗ на руках клиенту будет проще принять готовый продукт и оценить его функциональность.
Из чего состоит ТЗ
Сначала определимся, что не является техническим заданием.
- Ссылки на проекты конкурентов. Референсы — необходимая часть технического задания, но не всё. Метод «сделайте как у конкурентов» не учитывает особенности работы продукта заказчика, бюджет и сроки.
- Ссылка на стандарты. ГОСТ 34 или ISO 9001 — важные документы для разработки информационных систем в госсекторе или продуктов с критической информационной инфраструктурой. Информация из стандартов может дополнить технические требования в ТЗ, но она ничего не говорит о самом продукте.
- Простое поручение. «Сделайте сайт» — это не техническое задание, а команда, которую подрядчик может выполнить любым удобным для себя образом.
«Нужно сделать сайт-визитку: на главной странице должен быть номер телефона и логотип, сайт должен корректно работать как на десктопе, так и на мобильном телефоне. Бюджет 100 тысяч рублей, сайт нужен через месяц», — это больше похоже на поручение с элементами технического задания.
Что должно быть в ТЗ
1. Информация о продукте. Указываем, для чего нужен продукт, какие у него цели и кто будет им пользоваться. Стоит поделиться нюансами работы компании, её целями и планами на будущий продукт, особенностями целевой аудитории — любыми деталями, которые помогут исполнителю лучше понять бизнес и продукт.
2. Требования к продукту. Чем сложнее цифровой продукт, тем более подробным может быть раздел требований к нему. Требования к продукту могут быть:
- Общими.
- Функциональными: какие функции, разделы и страницы должны быть у продукта.
- Техническими: требования к безопасности, интеграции с другими сервисами клиента, производительность.
- Требованиями к дизайну: соответствие брендбуку.
- Бизнес-требованиями: данные об аналитике и отчётности или управлении клиентскими данными.
3. Функциональная спецификация интерфейса. В этой части ТЗ рассказываем, из чего состоит интерфейс будущего продукта и как он работает. Например, если наш продукт — мобильное приложение для покупки квартир, то вместе с прототипом интерфейса добавляем описание, где отвечаем на вопрос, по какому принципу упорядочены квартиры в макете каталога.
4. Use cases. Пользовательский сценарий позволяет описать, как потенциальные клиенты будут взаимодействовать с продуктом. Чем больше пользовательских сценариев описано — тем ниже риск ошибки при разработке. Описание сценария должно содержать:
- Понятный заголовок. Например: «Удаление аккаунта».
- Перечисление всех участников. Например: «система» и «пользователь».
- Описание сценария. Например: «Пользователь нажал на кнопку “Удалить аккаунт”», «Система открыла форму подтверждения удаления аккаунта».
- Результат. Например: «Аккаунт удалён».
5. Референсы. Ссылки на другие понравившиеся продукты помогают клиенту точнее сформулировать ожидания и видение, а исполнителю — лучше понять клиента.
6. Порядок приёмки. В этом разделе определяем временные рамки и процедуру передачи готового проекта. Также можно описать, с помощью каких инструментов будут проводиться тесты работоспособности системы при передаче продукта.
Чего не должно быть в ТЗ
- Размытых формулировок. Стоит избегать формулировок, которые можно трактовать неоднозначно. Например, опытный дизайнер и продавец в магазине могут по-разному воспринять понятие «красивый дизайн». Компетентный подрядчик задаст вопрос по каждой неоднозначной формулировке. Лучше заменить все оценочные и субъективные характеристики на предельно ясные, в идеале — оцифрованные.
- Неизвестных слов. В каждой компании есть специфические термины, которые нельзя просто загуглить. Если в компании есть глоссарий — его нужно предоставить исполнителю. Аналогичная ситуация может возникнуть и с обратной стороны — технические термины исполнителя могут быть непонятны клиенту, и их нужно уточнять, чтобы избежать недопониманий.
Кто должен составлять ТЗ
На этот вопрос нет универсального ответа. Но есть несколько вариантов:
1. ТЗ — на исполнителе. Клиент ставит общую задачу, а исполнитель изучает заказчика, его целевую аудиторию и конкурентов, запрашивает дополнительные данные у клиентов, готовит требования.
2. Заказчик и исполнитель вместе составляют ТЗ. Заказчик — специалист в своей области, и он может не знать всех технических деталей разработки цифровых продуктов. В таком случае над техническим заданием стоит работать вместе: клиент расскажет, зачем ему продукт и как он будет им пользоваться, а исполнитель предложит заполнить бриф и назначит дополнительные интервью для согласования нюансов.
3. Заказчик самостоятельный. Иногда клиент точно знает, чего хочет, и обращается к заказчику с уже готовым техническим заданием. Это позволяет быстрее рассчитать стоимость и сроки работы. Однако ни одной из сторон не стоит полностью отстраняться от работы над ТЗ — чем лучше коннект между заказчиком и исполнителем на этапе планирования работы, тем меньше белых пятен.
А можно без ТЗ?
Можно. Иногда процесс работы над продуктом довольно долгий, и вектор развития продукта может меняться. В этом случае жёсткое техническое задание не подойдёт для работы над проектом. Кроме того, чтобы составить качественное ТЗ для сложного проекта, нужно много времени.
В результате после первого релиза может выясниться, что время на разработку ТЗ было потрачено впустую — например, если у заказчика изменились требования к проекту. В таком случае можно работать над проектом итеративно, используя гибкие методологии: скрам и канбан.
Но и в этом случае не стоит пренебрегать ТЗ. Точное, пусть и небольшое, техническое задание — гарантия того, что каждая новая версия продукта обойдётся без неприятных сюрпризов.
TL;DR
- Техническое задание — это документ, который может быть написан в свободном формате, но с однозначным формулировками.
- Информация о проекте и его целях, требования и use cases должны быть описаны в любом техническом задании.
- Качественное ТЗ с чётко прописанными критериями, планом тестирования и передачи проекта помогает управлять расходами.
- Хорошо, если в работе над ТЗ участвуют и заказчик, и исполнитель.
- Не все проекты и не все компании нуждаются в работе по строгому ТЗ. Гибкие методы управления проектами эффективно комбинируются с не слишком детализированным ТЗ.
- Излишне подробное ТЗ — не гарантия качественного результата. По ходу работы требования могут меняться, и это нормально.