Как составить техническое задание

Что такое техническое задание?

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

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

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

Зачем нужно техническое задание?

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

Зачем еще нужно ТЗ? Разберем по пунктам:

1. Защита от недопониманий

С ТЗ вы не услышите «я думал, что так» или «мы с вами не так договаривались». Все спорные моменты решаются на основе написанного. Своего рода, страховка от недобросовестных подрядчиков.

2. Смена исполнителя без потери качества

Если вы недовольны работой текущего исполнителя, ТЗ позволяет легко передать проект другому, не теряя при этом в качестве. Новый исполнитель сразу поймет, что от него требуется, и вам не придется тратить время на объяснения с нуля.

3. Контроль прогресса и результата

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

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

4. Экономия времени и денег

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

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

{{cta_op_banner}}

5. Структурирование мыслей

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

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

Стандарты составления технического задания

Один из самых авторитетных стандартов — ISO/IEC/IEEE 29148-2018. Он разработан Международной организацией по стандартизации и подходит для самых разных проектов, будь то разработка программного обеспечения, проектирование сложных технических систем или создание контента.

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

ГОСТ 19

ГОСТ 19 — это серия стандартов, разработанных в СССР и, впоследствии, в России. В контексте технического задания, нас в первую очередь интересует ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».

В чем особенность:

• Ориентация на комплексные проекты.

Изначально разработан для крупных, комплексных проектов, где требовалось четкое разделение ответственности и строгая документация.

• Жесткая структура.

Предписывает очень четкую и подробную структуру ТЗ, включая обязательные разделы (общие сведения о проекте, основания для разработки, назначение разработки, требования к программному обеспечению, к документации, к приемке и контролю, экономические показатели и состав работ).

• Формализованный подход.

Использует формализованный язык и требует строгого соблюдения установленных правил оформления.

• Учет нормативных требований.

Акцент на соответствие нормативным документам и стандартам, действующим в России.

• Может быть избыточным.

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

• Трудоемкость.

Разработка ТЗ по ГОСТ 19 требует квалифицированных специалистов.

IEEE STD 830-1998

‍IEEE Std 830-1998 или «Рекомендации для спецификации требований к программному обеспечению» — стандарт, разработанный Институтом инженеров электротехники и электроники (IEEE). Чем отличается:

• Гибкая структура.

Предлагает гибкую структуру, которую можно адаптировать под конкретный проект (в отличие от строгости ГОСТ 19).

• Акцент на атрибуты требований.

Присваивает каждому требованию такие атрибуты, как:
→ Уникальный идентификатор.
→ Приоритет.
→ Источник.
→ Статус.
→ Версия.

• Разделы.

Рекомендует разделение ТЗ на следующие разделы:
→ Введение.
→ Общее описание (обзор проекта, контекст, предположения).
→ Специфические требования (функциональные, нефункциональные, интерфейсные).
→ Дополнения (глоссарий, ссылки).

• Простота понимания.

Ориентирован на то, чтобы требования были понятны как заказчику, так и исполнителю.

• Международное применение.

Широко используется в международной практике разработки программного обеспечения.

ISO/IEC/IEEE 29148

‍Стандарт охватывает управление требованиями на протяжении всего жизненного цикла проекта. В чем особенность:

• Управление требованиями.

Фокусируется на процессах управления требованиями, а не только на самом документе ТЗ. Это включает в себя процессы сбора, анализа, документирования, проверки, отслеживания и изменения требований.

• Итеративный процесс.

Требования могут уточняться и изменяться в ходе проекта.

• Трассировка (запись последовательности действий) требований.

Акцентирует важность связи между требованиями, их реализацией и тестированием.

• Различные виды требований.

Рассматривает различные виды требований, включая:
→ Бизнес-требования.
→ Пользовательские требования.
→ Системные требования.
→ Программные требования.

• Разделение на уровни.

Предлагает разделять требования по уровням, от высокоуровневых (описывающих общие цели) до низкоуровневых (описывающих конкретные функции).

• Включает в себя лучшие практики.

Объединяет лучшие практики из других стандартов, таких как IEEE Std 830 и другие стандарты ISO/IEC.

• Ориентирован на управление изменениями.

Подчеркивает важность управления изменениями требований на протяжении всего жизненного цикла проекта.

Кто составляет техническое задание?

Заказчик

В идеале, именно заказчик — основной инициатор и составитель технического задания. Почему именно он?

1. Четкое понимание потребностей.

Заказчик лучше всех понимает свои бизнес-цели, потребности целевой аудитории и то, каким должен быть конечный результат.

2. Знание предметной области.

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

3. Владелец бюджета.

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

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

Исполнитель

Бывают ситуации, когда эта роль переходит к исполнителю. Рассмотрим, как тогда происходит процесс создания ТЗ исполнителем.

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

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

Надо также понимать, где это все реализовывать. А точнее, куда записывать техническое задание, чтобы всем было удобно и понятно.

Мы советуем не полагаться на чаты или отдельные документы. Сообщения легко могут потеряться, а документы магическим образом удалиться. Чтобы все хранилось надежно, выбирайте онлайн-сервисы. Например, сервис Shtab.

На платформе можно поставить ТЗ двумя способами. Первый, если задача небольшая, воспользуйтесь шаблоном карточки. Вам остается только заполнить ее.

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

Если проект более объемный, можно использовать «Страницы», они очень похожи на те, что в Notion.

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

Совместно

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

1. Обсуждаем всё до мельчайших деталей, пока не достигнем полной ясности.

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

2. ТЗ — живой документ.

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

3. Спрашивайте: зачем.

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

Этапы разработки технического задания

ТЗ можно представить в виде фундамента проекта. Если фундамент кривой, дом рухнет. Поэтому к ТЗ нужно подходить как к серьезной инженерной задаче.

Разберем примерный алгоритм действий.

Бриф

Бриф — инструмент, который помогает заказчику самому понять, какой результат необходим. На этом этапе нужно копать глубже.

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

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

Сбор пожеланий заказчика

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

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

Консультация со специалистами

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

Например, вместо «сделаем сложную анимацию на главной странице», говорите: «рассмотрим несколько вариантов анимации, оценим их стоимость и влияние на производительность сайта».

Составление ТЗ

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

Пример: вместо «сделать форму обратной связи», пишите: «форма обратной связи должна содержать поля: имя, email, телефон, сообщение. Кнопка отправки должна быть подписана "Отправить сообщение"».

Согласование

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

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

Подписание

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

1. Зафиксируйте процесс внесения изменений.

Если в процессе работы возникнет необходимость внести изменения в ТЗ, это нужно делать официально.

2. Регулярно сверяйтесь с ТЗ.

Помните, что ТЗ — ваш ориентир. Регулярно сверяйтесь с ним, чтобы убедиться, что вы двигаетесь в правильном направлении.

Рекомендации по составлению ТЗ

Дайте исполнителю общую информацию

В начале кратко опишите цели проекта, его целевую аудиторию и общую концепцию. Это поможет исполнителю понять контекст и принимать более обоснованные решения.

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

Используйте однозначные формулировки

Избегайте расплывчатых фраз и субъективных оценок.

{{pc}}

{{/pc}}

{{mobile}}

{{/mobile}}

Укажите конкурентов

Приведите примеры аналогичных проектов или сервисов. Так исполнитель поймет рынок и поможет определить ваши сильные и слабые стороны.

PS. Это не копирование, а ориентир.

Дайте определение используемых терминов

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

Например, UX (User Experience) – опыт взаимодействия пользователя с продуктом.

Ведите историю правок

Создайте раздел «История изменений» и фиксируйте все правки. Каждая правка должна содержать дату, описание изменения и кто ее внес.

Так вы отследите ход работы и избежите путаницы.

Укажите технические требования

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

Например, «Приложение должно быть разработано на React Native и поддерживать iOS 13+ и Android 8+».

Опишите требования к проверке итогового проекта

Укажите критерии, по которым будет оцениваться готовый продукт. Опишите, как будет проводиться тестирование, какие параметры проверяться, и кто будет принимать работу.

Например, «Тестирование сайта включает функциональную проверку ключевых сценариев, совместимость на Windows/macOS, iOS/Android устройствах в браузерах Chrome, Firefox, Safari, Edge, с разрешениями 1920x1080, 1366x768, 375x667, 768x1024».

Когда ТЗ не нужно

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

Помимо этого, можно использовать Agile — это про итерации, гибкость и адаптацию к изменениям. Вместо жесткого ТЗ с самого начала, Agile-команды используют бэклог (список задач) и создают пользовательские истории. ТЗ в Agile может быть кратким, на уровне общего видения, а детали прорабатываются и уточняются в процессе работы.

Также можно попробовать метод Waterfall (водопад). Он предполагает последовательное выполнение этапов, где каждый следующий этап начинается только после завершения предыдущего.

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

Заключение

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

• Опишите общую информацию о проекте.
• Используйте однозначные формулировки.
• Укажите конкурентов для ориентира.
• Дайте определения используемым терминам.
• Ведите историю правок.
• Опишите технические требования.
• Определите критерии проверки.