Главное Авторские колонки Вакансии Образование
532 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Техническое задание: для чего нужно и как составить

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

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

Сразу скажем — не всем проектам нужно ТЗ. Некоторым достаточно составить Product Vision Видение продукта — отправная точка любого IT-проекта. Оно даёт представление о цифровом решении, его целях и задачах.

Возьмём к примеру работу со стартапами. Клиент приходит с идеей и не знает, как её реализовать технически. Разработка стартапа начинается с MVP (минимально жизнеспособного продукта), потому что неизвестно, «взлетит» он или нет. Ещё одна особенность стартапа — изменчивость. Цифровое решение может не раз меняться на ходу, поэтому техзадание может стать неактуальным. Таким проектам на помощь приходит Product Vision — описали видение проекта и начали разрабатывать, тестировать, получать обратную связь и поэтапно развивать продукт.

В чём польза ТЗ для заказчика

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

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

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

Определение компетентности подрядчиков. Если клиент видит понятное и структурированное техзадание, то с подрядчиком можно продолжить сотрудничество. Если видит неразбериху и не понимает, что в документе описано, то это заставляет задуматься о надёжности компании-разработчика. Через техзадание можно «прощупать» подрядчика и оценить его компетентность.

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

В нашей практике встречаются два варианта: клиент приходит с ТЗ или мы пишем ТЗ, опираясь на запрос клиента. Рассмотрим каждый вариант.

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

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

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

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

А что если использовать готовый шаблон из Интернета

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

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

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

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

На что обратить внимание при приёме ТЗ

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

Однозначные формулировки

Формулировку «Сделать красивый сайт» исполнитель и заказчик могут понять по-разному. Чтобы не было разночтений, лучше избегать прилагательных «красивый», «хороший», «качественный», «быстрый» и абстрактных примеров «Сайт должен загружаться быстро». Быстро — это как? Такие предложения каждый человек может трактовать по-своему. Чем точнее описано техзадание, тем лучше получится результат.

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


Глоссарий

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


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

Примеры

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

Что должно быть в техзадании

Рассмотрим структуру ТЗ на примере сайта. Но этот же принцип работает с любым цифровым продуктом — мобильным приложением, сервисом, корпоративным порталом или CRM-системой.

Компания и цель создания сайта

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

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

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

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

Может показаться излишним указывать, что сайт должен быть адаптивным, то есть работать в любых браузерах (Google Chrome, Yandex, Opera и т. д.) и на разных видах устройств (компьютеры, ноутбуки, телефоны, планшеты). Но лучше перестраховаться и описать всё. Техзадание — это документ, по которому вы будете принимать работу.

Структура сайта

Структура — это основа сайта. В ней прописывают, какие разделы и страницы планируются на сайте. Оформить структуру проекта можно с помощью списка со вложенностью или схемы.


Содержание каждой страницы

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


Пользовательские сценарии

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

Для описания сценариев IT-продуктов используют следующий шаблон: действие пользователя — ответ сайта.

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

Представим блог с подпиской на рассылку и посмотрим, как ведёт себя пользователь и как «отвечает» ему сайт.


Контент

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

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

Дизайн

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

  1. палитра цвета;
  2. допустимые и недопустимые цветовые сочетания;
  3. основной и второстепенный шрифт;
  4. тематика изображений.

В техническом задании прописывается, как подрядчики будут отдавать результаты работ по дизайну — в виде мудборда, вайрфреймов, кликабельного прототипа, самих макетов, UI-kit’а или дизайн-системы. Также фиксируется количество итераций для правок при приёме дизайна и сроки ответа заказчика.

Процесс создания техзадания

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

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

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

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

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

  1. цель и задача проекта;
  2. показатели, которые необходимо достичь за счёт разрабатываемого продукта или услуги;
  3. требования к оптимизации, продвижению и наполнению продукта контентом;
  4. требования к техническим характеристикам продукта;
  5. функциональные и нефункциональные требования в зависимости от того, какая потребность стоит на повестке;
  6. требования или предпочтения к технологическому стеку разработки проекта;
  7. сроки оказания услуги;
  8. условия гарантийного обслуживания;
  9. требования к необходимой технической документации при сдаче товара/работ/услуг;
  10. другие необходимые требования, которые не противоречат закону 44-ФЗ.

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

Вместо заключения

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

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

Наш приоритет — сделать так, чтобы цифровой продукт работал на цели вашего бизнеса.

Оригинал статье размещён на нашем сайте https://inostudio.com/blog/articles-develop/tekhnicheskoe-zadanie-dlya-chego-nuzhno-i-kak-sostavit/

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.