Техническое задание позволяет создать продукт, который будет соответствовать целям и потребностям заказчика. Даже небольшие тексты с фриланс-бирж не будут выполнять задачу, если писать их без ТЗ. Что уж говорить о более масштабных продуктах, таких как сайты — там ТЗ может состоять из десятков, а то и сотен страниц.
ТЗ может быть настолько большим и сложным
Что такое техническое задание. Это детальное описание требований для реализации проекта или продукта. В больших проектах ТЗ может быть документом, зафиксированным в договоре и обладающим юридической силой. У сложного продукта может быть несколько ТЗ: например, при разработке сайта могут использовать отдельные ТЗ для разработчиков и для дизайнеров.
Кто составляет ТЗ. Техническое задание может составляться как заказчиком, так и исполнителем. Если проект сложный, ТЗ создает исполнитель, потому что заказчик не будет разбираться в тонкостях создания продукта. Для понимания задачи исполнитель собирает всю необходимую информацию от заказчика и учитывает ее при составлении ТЗ.
Когда ТЗ не нужно. Можно обойтись без ТЗ, если исполнитель хорошо погружен в проект, знаком с его особенностями и уже работал с заказчиком над схожими задачами. Будет проще внести небольшие коррективы в готовый продукт.
Далее в статье:
полезные функции, которые выполняет техническое задание;
5 принципов создания качественного ТЗ;
структура технического задания на примере ТЗ для мобильной разработки;
стандарты, которые регулируют написание ТЗ.
Также в блоге Workspace есть готовые гайды по составлению ТЗ:
Если вы прочтете статью и решите, что вам необходима помощь в составлении ТЗ — создайте задачу для специалистов на Workspace. При разработке сложных проектов отдельное создание ТЗ будет оправданным — с ним можно обратиться к разным исполнителям и узнать стоимость их услуг. На Workspace зарегистрировано более 17 000 digital-агентств и десятки тысяч специалистов. Опубликуйте задачу, собирайте отклики и выберите лучшего исполнителя. Workspace — тендерная площадка № 1 в сфере digital.
Демонстрация сложности и стоимости продукта. Клиент видит, за какие труды он платит и сколько ресурсов нужно для их выполнения. Он с меньшей вероятностью будет подозревать исполнителя в завышении стоимости.
Фиксация требований к продукту в документе. Исполнитель получает защиту от спонтанных переделок, а заказчик получает уверенность в том, что исполнитель сделает что нужно. Если ТЗ прикреплено к договору на разработку сайта или договору на разработку мобильного приложения, обе стороны получают юридическую защиту.
Демонстрация компетентности исполнителя. Хорошее техническое задание показывает, что исполнитель разбирается в своем деле. Заказчик не переживает, а исполнитель получает плюс к репутации.
ТЗ может быть самостоятельным продуктом. Заказчик может обратиться с ТЗ к другой команде, а исполнитель может заработать на продаже ТЗ.
Теперь расскажем о принципах, которые делают качественное ТЗ таковым.
Если вы заказчик и пишете ТЗ самостоятельно, держите в голове цель, которую собираетесь решить при помощи продукта.
Пример: вы хотите приобрести рекламный пост в Telegram-канале про интернет-маркетинг. Ваша цель — продажа онлайн-курса по управлению проектами. Вы знаете его УТП: курс дешевле, чем у конкурентов, в нем есть приглашенные известные эксперты, а еще он максимально прикладной. Всю эту информацию нужно отправить автору Telegram-канала, чтобы он ничего не упустил и создал наиболее эффективный пост. Ваши уточнения, которые помогут достичь цели, будут являться техническим заданием.
Уточняющие вопросы для комментария эксперта в статье — тоже небольшое техническое задание. Они помогли мне достичь нужной цели
Если продукт сложный, у заказчика не будет достаточно экспертизы для самостоятельного написания ТЗ — его составлением займется исполнитель. От заказчика потребуется информация о бизнесе, целях продукта, рынке и конкурентах — без этого ТЗ тоже не составить. Для получения недостающих сведений исполнитель будет проводить брифинг клиента. Про брифы у нас есть полноценная статья: «Что такое бриф, чем он помогает, секреты создания эффективного брифа + 12 готовых примеров».
Читайте также:
Срок окупаемости интернет-проекта: что это такое и как его рассчитать
Подробные условия выполнения конкретных задач в ТЗ нужны для того, чтобы исполнитель не сделал «поворот не туда». Условия в техническом задании лишь отсекают ненужные решения. Перегружать ТЗ избыточной информацией тоже не стоит.
Скриншот из технического задания, в котором объясняется принцип работы алгоритма по оптимизации изображений на будущем сайте. Скриншот взят из ТЗ Ozhgibesov Agency
Не используйте в техническом задании субъективные оценочные суждения. Например, качественные прилагательные, такие как «быстрый», «модный».
Точные требования в ТЗ должны быть измеримыми, чтобы не осталось разночтений.
Плохо:
«сайт должен выдерживать большую нагрузку»;
«дизайн лендинга должен быть модным»;
«нужен яркий логотип».
Хорошо:
«сайт должен выдержать одновременное посещение 5 000 человек»;
«лендинг нужно выполнить во flat-дизайне: на его подложке нужно использовать 3D-шейпы и геометрические паттерны»;
«логотип нужно выполнить в 3 оттенках оранжевого цвета от PANTONE:
В требовании к скорости загрузки сайта указаны измеримые показатели. Скриншот взят из ТЗ Ozhgibesov Agency
Читайте также:
Инструкция: как самостоятельно провести юзабилити-аудит сайта
Одних измеримых требований недостаточно, чтобы отразить концепцию будущего проекта. Для наглядности в техническом задании стоит использовать иллюстрации, концепты и примеры. Они помогут сориентироваться не только заказчику, но и специалисту.
Концепт-арты главного героя компьютерной игры Death Stranding, с которых потом срисовали персонажа
При прочтении ТЗ не должно вызывать недопонимания ни у заказчика, ни у исполнителя. Скорее всего, в нем будет использовано много сложных формулировок: от обеих сторон. В любом деле есть свои термины и профессионализмы, которые не будут понятны человеку без экспертизы. Непонятные формулировки нужно либо объяснять на месте, либо создать для их расшифровки глоссарий.
Профессионализм «главное зеркало» расшифровывается, чтобы смысл работы мог понять заказчик. Скриншот взят из ТЗ Ozhgibesov Agency
Далее разберем примерную структуру с пунктами, которые встретятся в технических заданиях для создания сложных продуктов в digital.
В качестве примера будем использовать структуру ТЗ для мобильного приложения, потому что это сложный продукт. У разных агентств структура технического задания может отличаться, но в общем и целом она будет примерно такой.
Цель проекта.
Тут указывается основная цель разработки: например, предоставление сервиса или решение определенной проблемы.
Описание текущей ситуации на рынке.
Раздел описывает существующие решения конкурентов, их недостатки и необходимость в разработке продукта.
Целевая аудитория приложения.
Здесь перечисляются основные пользовательские группы, их потребности и предпочтения.
Функции приложения.
Тут указывают возможности приложения с раскрытием их особенностей.
Описание пользовательских сценариев.
В этом разделе представляются типичные сценарии использования приложения: от регистрации пользователя до выполнения целевых действий.
Пример схемы пользовательского сценария приложения. Взят из видео на YouTube
Интерфейс и пользовательское взаимодействие.
Здесь описывается, как пользователь будет взаимодействовать с приложением, его интерфейсом, элементами управления и визуальным оформлением.
Требования к базе данных и хранению данных.
Тут указываются требования к архитектуре СУБД, а также способы хранения и обработки информации.
Интеграция с другими системами или сервисами.
Если приложение должно взаимодействовать с другими системами или сервисами, тут описывают требования и протоколы интеграции.
Требования к безопасности.
Здесь раскрывают такие функции, как защита данных пользователей, обработка личной информации и защита от несанкционированного доступа.
Читайте также:
Чек-лист перед запуском сайта: что нужно проверить и как
Общие принципы дизайна.
Тут описывают визуал, цветовая палитра и типографика приложения.
Идентичность бренда и стиль оформления.
Если приложение связано с определенным брендом или компанией, указываются требования к включению брендированных элементов и соблюдению айдентики.
Навигация и структура информации.
В этом разделе описывается реализация навигации и структура экранов для обеспечения качественного пользовательского опыта.
Адаптивный дизайн и поддержка разных устройств.
Тут определяют требования к версиям приложения для различных устройств и разрешений экранов.
Технологический стек и языки программирования.
Здесь указывают используемые инструменты, фреймворки и языки программирования для разработки мобильного приложения.
Архитектура приложения.
В этом разделе перечисляют требования к организации компонентов приложения: пользовательскому интерфейсу, бизнес-логике, базе данных и интеграциям.
Пример схемы архитектуры приложения. Взят из видео на YouTube
Поддерживаемые платформы.
Здесь детализируются требования к поддержке ОС, на которых будет работать приложение.
Система управления версиями.
В этом разделе указаны требования к системе контроля версий, которая будет использоваться для управления кодом приложения.
Тестирование и отладка.
Для качественной работы приложения нужно определить требования для его проверки тестировщиками.
Читайте также:
Чем занимается тестировщик в IT: задачи специалисты по тестированию в 2023 году
Поддержка и обновление приложения.
Здесь указывают требования к поддержке и обновлению приложения после его выпуска: планы выпуска новых версий и исправлений дефектов.
Этапы проекта и сроки выполнения.
Для каждого из этапов разработки устанавливаются дедлайны. Также определяется продолжительность этапов разработки и их зависимости этапов друг от друга.
Роли и ответственности участников команды.
Здесь описывают роли разработчиков, дизайнеров, тестировщиков и других участников команды, а также их ответственности и обязанности.
Контрольные точки проекта.
Определяются промежуточные результаты и вехи проекта, чтобы контролировать прогресс разработки.
Пример определения контрольных точек проекта в программе «1С:Документооборот 8»
Идентификация и анализ рисков.
Здесь перечисляют потенциальные риски, связанные с разработкой приложения и вероятность их наступления. Также разрабатываются стратегии по их предотвращению или смягчению.
Планы мониторинга и контроля качества.
Для контроля разработки устанавливаются процессы и инструменты, которые позволяют отслеживать контроль качества приложения в разных фазах разработки.
Планы резервного копирования и восстановления.
Здесь описываются требования и планы резервного копирования данных, а также возможности их восстановления в случае сбоев или потери информации.
Распределение ресурсов и бюджетные ограничения.
В этом разделе определяются требования к распределению ресурсов: финансов, персонала и инфраструктуры, и устанавливаются бюджетные рамки.
План оплаты и условия контракта.
В ТЗ могут быть указаны детали оплаты работ по проекту и условия контракта между заказчиком и исполнителем.
Правовые и коммерческие соглашения.
Здесь определяются правовые и коммерческие аспекты, такие как лицензирование, авторские права, соглашения о конфиденциальности и ответственности сторон.
Конфиденциальность и защита данных.
Требования и меры по обеспечению конфиденциальности данных пользователей и защите информации также могут входить в ТЗ.
Правила изменения и утверждения ТЗ.
В этом разделе устанавливаются правила для внесения изменений в ТЗ и процедуры утверждения изменений.
Дополнительная информация и ресурсы.
Здесь будет любая дополнительная информация: ресурсы, иллюстрации, кастдевы, и ресерчи, которые пригодятся при разработке приложения.
Технические спецификации и диаграммы.
Тут включаются дополнительные технические спецификации, которые помогут лучше понять требования к приложению.
Примеры пользовательского интерфейса.
Могут быть предоставлены примеры или макеты пользовательского интерфейса для наглядного представления того, как должно выглядеть приложение.
Макеты дизайна мобильного приложения, выполненные в Figma. Взято из видео на YouTube
Стандартизация не прошла мимо технических заданий. Расскажем о двух стандартах, которые регулируют написание ТЗ.
ISO 29148:2018 — международный стандарт, который определяет процесс постановки требований на разработку ПО. Он охватывает все этапы жизненного цикла разработки: от анализа требований до проверки их соответствия. Стандарт определяет рекомендации по работе с требованиями, включая их классификацию, анализ, документирование и верификацию. Также этот стандарт включает рекомендации по взаимодействию с заинтересованными сторонами: заказчиками, пользователями и заинтересованными лицами проекта.
ГОСТ
Как вы считаете, можно ли обойтись в разработке без технического задания?
Подпишитесь на ежемесячную рассылку Workspace
Отлично! Мы отправили письмо на указанный вами электронный ящик с инструкцией по подтверждению.
Если письмо с подтвержением вашего e-mail не будет получено в течение 10 минут, пожалуйста, проверьте папку СПАМ в соответствующем почтовом ящике.
