Как написать техническое задание
Перейти к содержимому

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

  • автор:

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

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

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

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

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

За составление ТЗ может отвечать, как заказчик, так и исполнитель. Иногда техническое задание пишется совместно. Рассмотрим все три варианта.

ТЗ пишет заказчик

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

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

ТЗ пишет исполнитель

Если за составление технического задания берется компания-подрядчик, то схема работы будет такая:

  1. Исполнитель узнает у заказчика общую задачу.
  2. Затем исполнитель составляет бриф с уточняющими вопросами и отправляет его заказчику.
  3. После того, как заказчик ответил на все вопросы, исполнитель на их основе составляет техническое задание.
  4. Готовый документ исполнитель отправляет заказчику на согласование.

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

Исполнитель и заказчик составляют ТЗ совместно

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

Инструкция по созданию технического задания

В этом разделе объясняем:

  • Как правильно составлять ТЗ
  • Что должно быть указано в техническом задании
  • Как оформить техническое задание

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

  • Подробное описание проекта, его цель. Все участники должны понимать, что из себя представляет проект, какие у него цели и задачи.
  • Основные требования к продукту. В этом разделе перечисляются все требования, согласно которым исполнитель реализует проект.
  • Этапы и сроки выполнения работы. Благодаря этому пункту заказчик знает, что и когда будет готово, поэтому сможет контролировать процесс разработки.
  • Порядок приемки проекта. В этом разделе представлены стандарты, по которым заказчик будет оценивать качество выполненной работы.
  • Приложения к техническому заданию. Дополнительная информацию к проекту. Обычно включает стоимость, технические регламенты, нормативно-правовые акты и т.д.

Общие рекомендации по составлению ТЗ

При написании ТЗ важно учитывать общие рекомендации.

  1. Выбирайте однозначные формулировки, когда пишете текст, чтобы не возникло недопонимания.
  2. Создайте глоссарий с расшифровкой сложных терминов. Это поможет исполнителю быстрее разобраться в ТЗ, если сфера деятельности компании-заказчика ему не знакома.
  3. Расскажите исполнителю, чем занимается ваша компания. Эта информация поможет исполнителю лучше вникнуть в проект.
  4. Перечислите конкурентов и добавьте ссылки на похожие проекты. Анализ аналогичных продуктов поможет в реализации проекта.

Стандарты

При составлении технического задания вы можете ориентироваться на международные и отечественные стандарты. В России действуют два ГОСТа, которые регламентируют разработку ТЗ:

  • ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению»

  • ГОСТ 34.602-89 «Комплекс стандартов на автоматизированные системы. Технические задание на создание автоматизированной системы»

Среди международных стандартов можно выделить ISO/IEC/IEEE 29148-2018. Он устанавливает требования к техническому заданию на разработку ПО и других сложных систем.

Как составить ТЗ для сайта: главные пункты

Рассмотрим упрощенный пример, как написать техническое задание на разработку сайта.

  1. Напишите, чем занимается компания-заказчик, кто ее клиенты, опишите основную задачу сайта.
  2. Объясните сложные термины.
  3. Опишите технические требования: какая CMS нужна, требования к хостингу, адаптивности, кроссбраузерности.
  4. Опишите структуру сайта: какие разделы и страницы нужны.
  5. Напишите, какие элементы должна содержать каждая страница, как будут располагаться объекты на странице.
  6. Составьте сценарий, как пользователи будут двигаться по сайту.
  7. Подготовьте контент для сайта: тексты, видео, изображения и т.д.
  8. Напишите, какой дизайну вы хотите использовать на сайте.
  9. Составьте поэтапный план сдачи сайта с указанием сроков.
  10. Опишите процесс приемки сайта.

Когда можно обойтись без технического задания

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

Заключение

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

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

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

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

На первый взгляд кажется, что исполнитель должен сам понять, как оставить клиента счастливым. «И пусть сам крутится, ведь он профессионал, я ему деньги плачу, все решит без меня».

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

А на выходе получаете неприятный осадок от зря потраченных денег.

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

1. В вашем техническом задании должны содержаться максимально конкретные цели

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

2. Не скупитесь на слова

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

Приведу пример из заказа по копирайтингу:

Так не надо Так хорошо
Нужен продающий текст о компании. Должен передавать наш статус и профессионализм. Хотим рассказать о компании: о нашем производстве — оборудовании, заботе об экологии.
Сделайте мне логотип, чтобы вау-эффект и luxury. Нужен простой двухмерный логотип для протеинового батончика. Нельзя использовать красный цвет. Пример — VP Lab.

3. Дайте примеры

Покажите исполнителю варианты вашей мечты и самые ужасные идеи, которые вам кажутся чудовищными. Это могут быть готовые решения от конкурентов, сногсшибательные варианты из международных практик — главное, задать фокус исполнителю «как надо / как не надо делать». И исходя из ваших возможностей и желаний это позволит продумать подходящий вариант. Помните о реализме — не приводите в пример тексты Nike или сервисы Google, если у вас скромный бюджет и совсем другие цели. Ваша задача — найти «золотую середину» между качеством и ценой.

4. Не игнорируйте исполнителя — отвечайте

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

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

Несколько примеров сложных и узкопрофильных заданий, которые очень часто размещают на биржах

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

Поэтому вам важно помнить следующее: постарайтесь встать на один уровень с исполнителем. Не надо знать деталей, важно понимать типовые задачи, а именно:

  • Сформировать семантическое ядро по высокочастотным и низкочастотным запросам, то есть использовать не самые распространенные слова, по которым могут гуглить ваш магазин, а чуть уже. Например, если у вас онлайн-магазин по продаже одежды, то по слову «одежда» или «платье» ваш запрос будет тяжелее продвинуть. Вернее, ваш магазин, конечно, найдется на десятой странице, но тратить время — себя не уважать. А вот по запросу «красное платье в горох» ваш запрос окажется выше. Подобные фразы или слова фрилансеры формируют самостоятельно.
  • Подготовить карту сайта для поискового робота.
  • Прописать robots.txt для индексации в Google и «Яндекс».
  • Сделать перелинк сайта, то есть связать страницы сайта или из других источников гиперссылками.
  • Прописать метатеги для каждой страницы.
  • Подготовить список рекомендаций по улучшению сайта.

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

Ниже — не лучший пример ТЗ:

В задании должны обязательно отражаться следующие требования:

  • улучшить показатели конверсии пользователей в покупатели;
  • найти ошибки, недоработки и баги на сайте;
  • проанализировать элементы структуры: работу ссылок, фильтров, удобство перемещения по сайту;
  • проанализировать контент-наполнение сайта на логичность;
  • протестировать конверсионные пути;
  • проверить скорость загрузки сайта, адаптивность.

Эти моменты стоит обязательно отразить в ТЗ, потому что хороший фрилансер не отреагирует просто на «переделайте сайт, чтобы сразу в душу запал».

Как писать ТЗ: инструкция по составлению грамотного техзадания

Как писать ТЗ: инструкция по составлению грамотного техзадания

ТЗ - часть многоуровневого процесса разработки

Техническое задание (сокращенно ТЗ) — это документ с подробными требованиями к проекту. Обычно в нем указывают цель, последовательность и методы выполнения работ, порядок согласования реализованных задач и другие нюансы. По сути, ТЗ — инструмент коммуникации между заказчиком и исполнителем. Он должен исключать двусмысленность и недопонимание в их взаимодействии. Техническое задание — это то, с чего начинается качественный функциональный продукт. По крайней мере, если таковым является само ТЗ. Если документ будет составлен непрофессионально и без должного внимания, результат окажется соответствующим. Учитывая характер целевой аудитории блога и общие тренды, скорее всего, имеет смысл описывать технические задания конкретно на цифровые продукты. Во многом так и будет, но нельзя забывать, что и самые обычные, «аналоговые», продукты тоже требуют документации. Они требовали её ещё до появления самого интернета. Поэтому для расширения кругозора и для пользы представителей нецифровых отраслей, стоит приводить отсылки и к оффлайн-проектам.

Для чего нужно техническое задание?

Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя. Фактически это инструкция для разработчиков, конструкторов и других непосредственных создателей конечного продукта. Но по сути техническое задание, определяя жёсткие требования к каждой детали, делает сотрудничество заказчика и исполнителя безопаснее и комфортнее. Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся. Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно. Техническое задание — основа как простых односложных продуктов, так и высоконагруженных систем. В каждом случае сценарии функционирования должны быть предусмотрены. Любое действие пользователя должно быть предугадано, и ответом на него должен быть полезный результат. Именно для того, чтобы работа с конечным продуктом вызывала положительный отклик пользователя и решала его задачи, необходимо проработать идею и детали проекта на самой ранней стадии.

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

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

Заказчик

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

Исполнитель

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

Совместно

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

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

Главные требования к техническому заданию — это продуманность и полнота. Так как составители не всегда способны им следовать, были разработаны общие стандарты разработки ТЗ. В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Из названия легко понять, что это общегосударственные стандарты, образцы разработки технических заданий на территории России. Эти два ГОСТа имеют отношение только к программным комплексам — к сайтам, приложениям и системам автоматизации. Другие ТЗ придется писать по совершенно другим правилам.

ГОСТ

ТЗ по ГОСТу актуальны для госзаказов

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

  • Введение;
  • Основания для разработки;
  • Назначение разработки;
  • Требования к программе или программному изделию;
  • Требования к программной документации;
  • Технико-экономические показатели;
  • Стадии и этапы разработки;
  • Порядок контроля и приемки;
  • Приложения.

Более новый стандарт — ГОСТ 34, но он новее всего на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

Текст технического задания строится по структуре:

  • Общие сведения;
  • Назначение и цели создания (развития) системы;
  • Характеристика объектов автоматизации;
  • Требования к системе;
  • Состав и содержание работ по созданию системы;
  • Порядок контроля и приемки системы;
  • Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
  • Требования к документированию;
  • Источники разработки.

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

ISO/IEC/IEEE 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

ISO IEEE - современный стандарт составления техзаданий

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

  • Введение. Информация о компании, которая пригодится при работе над проектом, назначение продукта или системы, содержание, обзор функций и пользователей.
  • Ссылки на референсы. Примеры продуктов конкурентов, которые можно использовать для анализа слабых и сильных сторон, интересных решений.
  • Системные требования. Требования к юзабилити и производительности системы, состоянию, физическим характеристикам, окружению и безопасности, правилам. Для приложений — требования к внешним интерфейсам, к производительности, структуре БД, функциям и юзабилити.
  • Тестирование и проверка. Процедуры тестирование по каждому из пунктов предыдущего раздела.
  • Приложения. Термины, схемы, история правок.

Услуги

Читайте также:

Метод «тыка» в контекстной рекламе: как достичь целевых показателей экспериментальным путем

Метод «тыка» в контекстной рекламе: как достичь целевых показателей экспериментальным путем

Порядок документирования требований

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

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

Бриф

В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.

Бриф обращён к заказчику и не предполагает жёстких финальных требований или детального описания результата. Выверенной должна быть только структура опросника. В него могут входить такие пункты, как:

  • Цель и назначение продукта;
  • Предполагаемый бюджет;
  • Целевая аудитория.

Вопросов на которые отвечает заказчик, может быть до 20–30, но не более, иначе это становится большой нагрузкой. Задача брифа в том, чтобы получить общее направление для обсуждения.

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

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

Виджет обратного звонка для сайта

  • Повысьте конверсию сайта на 30%
  • Новым клиентам 50 минут в подарок

Технико-коммерческое предложение

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

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

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

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

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

Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.

Требования всегда подлежат обоюдному согласованию

Техническое задание

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

Технический проект

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

В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).

Бесплатно Электронная книга

23 действующих способа сделать свой маркетинг круче, быстрее, эффективнее, чем сейчас Получить бесплатно

Эксплуатация

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

Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.

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

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

Правильное ТЗ составляют по универсальному шаблону:

Дайте подрядчику общую информацию

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

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

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

Распишите сценарии использования продукта

Сценарий нужен для понимания принципа работы продукта. Например, если область работы касается IT, сценарий отвечает на вопрос «Как будет вести себя пользователь?» и дает понимание главных функций сайта.

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

В начале документа создайте таблицу со столбцами “дата”, “описание”, “автор”. В ней записывается история изменений документа, благодаря которой легко понять, на каком этапе возникло то или иное требование, дополнение, противоречие.

Составляйте список терминов и сокращений

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

Прописывайте каждую деталь

Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещен сайт, какие у него параметры: ёмкость, оперативная память и другие.

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

Продумывайте детали

Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.

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

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

Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете.

Сквозная аналитика Calltouch

  • Анализируйте воронку продаж от показов до денег в кассе
  • Автоматический сбор данных, удобные отчеты и бесплатные интеграции

Как составить техническое задание: правила, приемы, этапы

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

Какое решение? Многое зависит от сферы, для которой составляется техзадание. Однако есть универсальные правила, которых необходимо придерживаться. Они касаются как оформления документа, так и его содержания.

В статье рассказывается:

  1. Суть и задачи технического задания
  2. Что сделать до составления технического задания
  3. Стандарты составления технического задания
  4. Кто составляет техническое задание
  5. Структура технического задания
  6. Этапы составления технического задания
  7. Роль технического задания в IT-методологиях
  8. Конкретизация задач в техническом задании
  9. Пример технического задания
  10. Ошибки при составлении ТЗ

Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.
Бесплатно от Geekbrains

Суть и задачи технического задания

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

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

Составление технического задания является неотъемлемой частью процесса реализации проектов, поскольку этот документ одновременно решает несколько задач:

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

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

Что сделать до составления технического задания

Для создания качественного ТЗ на IT-продукт необходимо сформировать функциональные и бизнес-требования. Это и есть основа технического задания.

Поговорим об этом детальнее.

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

Узнай, какие ИТ — профессии
входят в ТОП-30 с доходом
от 210 000 ₽/мес
Павел Симонов
Исполнительный директор Geekbrains

Команда GeekBrains совместно с международными специалистами по развитию карьеры подготовили материалы, которые помогут вам начать путь к профессии мечты.

Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее будущее!

Скачивайте и используйте уже сегодня:

Павел Симонов - исполнительный директор Geekbrains

Павел Симонов
Исполнительный директор Geekbrains

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

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

Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка

Только проверенные нейросети с доступом из России и свободным использованием

ТОП-100 площадок для поиска работы от GeekBrains

Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽

Получить подборку бесплатно
Уже скачали 23672

Вот пример бизнес-требований:

  • Выполнить настройку фильтрации каталога товаров, которая позволит пользователям осуществлять поиск по ключевым запросам, таким как тип товара, бренд, производитель, цвет и т.д.

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

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

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

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

  • введение;
  • основания для создания конкретного продукта;
  • назначение для разработки;
  • требования к конечному IT-продукту;
  • требования к программным документам;
  • технические и экономические показатели;
  • стадии, этапы создания продукта;
  • правила контроля реализации и приёмки работ;
  • приложения.
  • введение – сфера использования, ссылки, обзоры, формулировки и определения;
  • детальное описание проекта – характеристики, функции, ограничения, допущения, взаимодействие итогового IT-продукта;
  • требования к функционалу, производительности, интерфейсам;
  • нефункциональные требования;
  • ограничения;
  • приложения;
  • алфавитный указатель.
  • введение, а именно обзор и назначение проекта;
  • соответствующие термины;
  • системные требования, касающиеся функций, операций, интерфейса, производительности и юзабилити;
  • физические характеристики;
  • требования по соответствию правилам безопасности;
  • правила;
  • сокращения и аббревиатуры.

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

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

Варианты могут быть следующими:

Заказчик может составить ТЗ самостоятельно

Некоторые руководители предпочитают, чтобы заказчик предоставил подробное техническое задание и запросил оценку работ.

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

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

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

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

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

Для вас подарок! В свободном доступе до 05.11 —>
Скачайте ТОП-10 нейросетей, которые помогут облегчить
вашу работу
Чтобы получить подарок, заполните информацию в открывшемся окне

Разработка ТЗ подрядчиком и совместное составление техзадания имеют отличие в подходе. К примеру, вам нужен интернет-магазин:

  • Коллаборация. Подрядчик получает установку от клиента на предмет формата сайта (он должен красиво отображаться на десктопе и на любых других устройствах, клиенты могут открыть в нем ЛК и накапливать баллы). Исполнитель собирает дополнительную информацию, например, о том, как долго должны сберегаться баллы, каким образом они будут использоваться. Затем он фиксирует полученные данные в документ – ТЗ.
  • Разработка подрядчиком. Клиент дает установку – создать интернет-магазин. Исполнитель с помощью бизнес-аналитика осуществляет сбор и структурирование требований к будущему проекту, проводит изучение ЦА и конкурентов, предлагает включить в техзадание требование по отображению веб-сайта на экранах телевизоров, так как потенциальные покупатели предпочитают делать заказы именно таким образом.

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

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

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

Дарим скидку от 60%
на курсы от GeekBrains до 05 ноября
Уже через 9 месяцев сможете устроиться на работу с доходом от 150 000 рублей

Одни в 2-3 предложениях могут выразить основную идею и ожидают, что подрядчик придумает все остальные детали. Например:

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

Некоторые же подробно описывают каждый пункт, тщательно работая над структурой:

  • Нужен качественный SEO текст по тематике «Пассивный заработок на криптовалюте» объемом 9000 – 10000 символов без пробелов. Уникальность – 100 %, заспамленность – 45 %, вода – до 20%. Употребить слово «криптовалюта» не менее 10 раз. Все представленные ключевые запросы равномерно распределить по тексту. Работу сдать в Word.

Ниже мы детально остановимся на пунктах, составляющих базовый шаблон техзадания.

Технические аспекты

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

При составлении ТЗ для написания текстов сюда относятся такие параметры:

  • число символов в одном абзаце;
  • количество вхождений ключевых запросов;
  • шрифт – вид и размер;
  • требования к структуре – заголовки, подзаголовки;
  • требуемые форматы – цитаты, нумерованные и маркированные списки, таблицы и так далее.

В техзадание для IT-продуктов входят следующие характеристики:

  • выбор системы управления информацией – Joomla, WordPress и другие;
  • число всплывающих окон;
  • выбор типа framework – Angular, React;
  • ширина конкретных частей страниц;
  • место расположения формы обратной связи;
  • другие сопутствующие функции.

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

Маркетинговые стратегии

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

Данный вопрос возвращает нас к этапу «текст создаётся для человека, а не для поисковых машин», который мы часто встречаем в ТЗ для копирайтеров. Этим заказчик выражает свое требование к созданию органичного, легко читаемого текста, не изобилующего ключевыми фразами для SEO-оптимизации. При этом совершенно неважно, каким образом писатель будет достигать данной задачи.

Планирование разработки продукта

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

Этапы работы

В ТЗ можно обозначить все этапы работ, в том числе промежуточные дедлайны. В частности, это относится к большим проектам. К примеру, в web-разработке подобный план может быть представлен так:

  • Разработка идей, плюс дополнение имеющегося плана действий.
  • Презентация начального прототипа.
  • Одобрение первой экспериментальной версии продукта.
  • Проверка корректности работы продукта.
  • Работа по созданию дизайна.
  • A/B-тестирование элементов CTA и визуальных компонентов.

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

Прочие аспекты

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

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

Общий бюджет проекта, равно как и срок реализации, прописываются заранее.

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

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

Этапы подготовки ТЗ Описание каждого этапа
Предоставление подрядчику общих данных Исполнитель должен иметь четкое представление о сфере деятельности компании заказчика и о его ЦА. Это поможет ему лучше вникнуть в задачу, которую перед ним ставит клиент, и не допустить элементарных ошибок. Озвучивая идею, следует остановиться на особенностях и конкурентных преимуществах будущего продукта.
Предоставление списка основных конкурентов Техническое задание должно включать ссылки на аналогичные проекты, а также дополнительное описание. Так подрядчику будет легче дать оценку хорошим примерам похожих разработок и исключить вероятные сложности при реализации. Более того, анализ особенностей чужих похожих продуктов помогает создать свое оригинальное решение.
Указание вероятных сценариев использования итогового продукта Наличие сценария облегчает понимание особенностей работы будущего продукта. К примеру, если сфера использования затрагивает IT, то сценарий должен отвечать на вопрос: «Каким образом будет вести себя пользователь?» и давать представление об основном функционале приложения/вебсайта.
Ведение журнала правок В самом начале ТЗ создайте табличку с графами «автор», «дата», «описание». Вносите в неё соответствующие изменения. Это поможет следить за статистикой возникновения тех или иных противоречий, требований, дополнений.
Составление перечня сокращений и терминов Это является основным правилом грамотного составления техзадания. Вначале основного текста размещается словарь, включающий специализированные необщеупотребимые термины. Отдельное внимание стоит уделить словам и аббревиатурам, используемым только в рамках данного проекта.
Конкретизация деталей Понятие вебсайта включает не только код, но и мощности, составляющие основу его работы. Первым делом стоит определиться с сервером для размещения продукта, предварительно проанализировав его параметры (оперативная память, емкость и т.д.).

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

Роль технического задания в IT-методологиях

Водопадная модель разработки ПО

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

Только до 2.11
Скачай подборку материалов, чтобы гарантированно найти работу в IT за 14 дней
Список документов:

ТОП-100 площадок для поиска работы от GeekBrains

20 профессий 2023 года, с доходом от 150 000 рублей

Чек-лист «Как успешно пройти собеседование»

Чтобы зарегистрироваться на бесплатный интенсив и получить в подарок подборку файлов от GeekBrains, заполните информацию в открывшемся окне

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

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

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

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

Желательно (не обязательно) использовать основные языки системного моделирования при создании диаграмм для техзадания. Главное, чтобы пользователь мог четко различить, что они изображают.

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

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

Методология Agile

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

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

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

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

В Agile-методологии любые изменения в первоначальных требованиях не являются критическими. Обе стороны изначально готовы к возможному внесению изменений в проект.

Agile-методология также использует различные инструменты проектирования, как и Waterfall (водопадная модель), но уже не на этапе составления техзадания, а в процессе разработки продукта.

Agile-методология не требует жесткого фиксирования пользовательского интерфейса, сценариев и алгоритмов взаимодействия с пользователем. А техническое задание представляет собой общее описание итогового IT-продукта, помогающее сформировать общее представление о том, что в итоге будет достигнуто.

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

Гибкая методология разработки не требует точной предварительной оценки стоимости работ. Обычно окончательная цена IT-продукта зависит от фактических часов, потраченных специалистами на работу.

Конкретизация задач в техническом задании

  • Заголовок задачи должен давать ответ на вопрос «Что нужно сделать?»

Примеры хороших заголовков:

  • Создать дизайн анимированных баннеров для Facebook/Instagram и Google для .
  • Исправить отображение страницы/pricing в мобильной версии.

Примеры плохой постановки задач:

  • Баннеры для
  • Верстка на странице цен

Смысл заключается в том, что ответ на вопрос «Что нужно сделать?» предполагает действие и мотивирует его выполнить. Правильно сформулированная задача должна показать видимый результат.

При понимании итогового результата исполнитель меньше прокрастинирует и решительно настроен как можно быстрее к ней приступить и выполнить.

  • Формулировка задачи должна указывать на примерный объём предстоящих работ
  • Создать ХХ ресайзов дизайна для площадок .
  • Сделать адаптивную вёрстку ЛК для .

Суть состоит в том, что при очень объёмной задаче исполнитель не понимает, с чего ему лучше начать её реализовывать, что ведет к стрессу и прокрастинации. Необходимо обозначить конкретный объём работ с подзадачами (для масштабных проектов).

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

Пример технического задания

Давайте рассмотрим реальный пример техзадания, которое предназначено для веб-разработчика и касается доработки полей в CMS. В данном ТЗ содержатся следующие пункты с конкретными требованиями:

  • Основная задача проекта – доработка полей в CMS.
  • Исходные данные: неразбериха с тем, какие поля отвечают за тот или иной функционал, в каком шаблоне они находятся. В результате возникли проблемы с оптимизацией данных элементов.

Давайте рассмотрим подробнее.

Существует два вида страниц: записи и конкретно страницы.

  • Пример записей – https://
  • Пример страниц – https://

Вот пример того, как разные типы могут иметь различные поля:

  • Для записей существует такой вариант поля.
  • Для страниц подобного поля не существует.

Что необходимо выводить, какие поля нужны:

  • Заголовок окна браузера (Title).
  • Описание страницы (Description).
  • Основной заголовок страницы (H1).
  • Название страницы в breadcrumbs (хлебных крошках).
  • Короткое название, отображающееся в верхнем меню на веб-сайте.
  • Название страницы в админке.

Следующие элементы требуют создания отдельных полей:

  • Title.
  • Description.
  • H1.
  • Название страницы в breadcrumbs.
  • Создание понятных названий для понимания предназначения конкретного поля.
  • Группировка полей на странице для редактирования.
  • Заголовок окна браузера (Title).
  • Описание страницы (Description).
  • Основной заголовок страницы (H1).
  • Название страницы в breadcrumbs (хлебных крошках).
  • Выяснить, откуда взято название в меню сайта.
  • Выяснить, откуда взято название страницы в админке.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *