Чёткое понимание задачи без технического задания есть только у компаний, которые работают в рамках ГОСТов и других общепризнанных стандартов качества. Если в сфере вашей работы нет чётких норм, то для оптимального результата лучше отобразить свои требования к продукту в техническом задании. О том, что это такое, кому нужно, а кому нет, и что в нём должно быть, расскажем в статье.
Техническое задание (ТЗ) — это документ с подробным описанием требований к цифровому решению. Разработка ТЗ помогает заказчику сформулировать и зафиксировать, каким он хочет видеть конечный продукт. А команда разработчиков оценивает затраты на реализацию проекта с предложенными характеристиками и понимает, как выглядит результат в глазах заказчика.
Сам термин «техническое задание» используют во многих сферах и интерпретируют так, как удобно. Приведём пример из обычной жизни. Фраза «Покрась забор в зелёный цвет» — это техническое задание? Нет, скорее, это общее видение конечного продукта. В данном случае правильное ТЗ будет выглядеть так: «Покрась забор краской фирмы „Мамкин маляр“ оттенка „Юный крокодил“ в два слоя толщиной 3 мм. Начинай красить от калитки и заканчивай на стыке со столбом. Срок высыхания слоёв — не менее 4 часов. Окончание работ — через сутки».
Соответственно, техническим заданием мы называем документ, в котором отражены цели, требования, технологии и методы выполнения работ, порядок согласования промежуточных и итоговых результатов, сроки выполнения задачи, конечное видение продукта от заказчика.
Техническое задание облегчает коммуникацию между заказчиком и исполнителем, а в спорных ситуациях позволяет обратиться к прописанным в ТЗ требованиям, чтобы разрешить ситуацию. Лучшее решение — если техническое задание станет приложением к основному договору.
Всё зависит от того, какой проект разрабатываете. Если это небольшая задача, вы уверены в исполнителе и считаете, что не будет неправильного толкования ваших требований, то можно договориться без подробного ТЗ.
Если нужно разработать технически сложный продукт, который предполагает серьёзное финансирование, лучше составить подробное ТЗ с указанием всех важных требований. То же касается технического задания для творческих проектов — например, дизайнерские задачи важно зафиксировать, чтобы исполнитель точно сделал то, что нужно заказчику.
Не всегда ТЗ помогает упростить задачу и сделать результат эффективно и в краткие сроки. Бывает, что техническое задание ограничивает, запутывает и мешает подрядчику.
В каких ситуациях это возможно:
В некоторых проектах вместо ТЗ достаточно составить Product Vision. Видение продукта — отправная точка любого ИТ-проекта. Оно даёт представление о цифровом решении, требованиях к нему, его целях и задачах.
Учитывайте, что работа без ТЗ несёт вполне конкретные риски. Прежде, чем принимать решение работать без фиксации подробных требований, оцените возможный ущерб от невыполненной или выполненной неправильно работы.
Техническое задание — это инструмент, который помогает разработке цифрового решения. Если компания готовит подробное ТЗ для своего продукта, она сразу решает несколько задач.
Оценивает бюджет. Рассчитать стоимость нешаблонных цифровых решений навскидку невозможно. Сначала нужно определиться, какие требования к продукту, и исходя из этого определить, что нужно разработать — сайт, приложение, сервис или портал. Потом понять, как решение будет работать и какие функции выполнять. И только на основе полученной информации определить сроки и бюджет. ТЗ как раз решает эту задачу.
Структурирует информацию. Компания приходит за разработкой с конкретными требованиями к цифровому продукту. Причём требования могут составлять разные подразделения — технические специалисты, команда маркетинга, аналитики, коммерции. И каждое подразделение преследует свои цели. Цифровое решение должно объединять и выполнять все эти требования. Благодаря ТЗ вся полученная информация выстраивается в чёткие задачи и фиксируется в документе.
Определяет компетентность подрядчиков. Через ТЗ можно «прощупать» подрядчика и оценить его компетентность. Часто компании, которые обращаются за ТЗ к стороннему исполнителю, планируют продолжить с ним сотрудничество и поручить им реализацию продукта. Если заказчик видит понятное и структурированное техническое задание, то с подрядчиком можно продолжить сотрудничество. Если видит неразбериху и не понимает, что в документе описано, то это заставляет задуматься о надёжности компании-разработчика.
Страхует от недобросовестных подрядчиков. Если компании-заказчику не нравится работа подрядчика уже на стадии реализации продукта, можно заменить команду. Новые исполнители на основе хорошего ТЗ быстро разберутся с задачей и вольются в процесс. Кроме того, техническое задание позволяет «держать руку на пульсе» контролирующим структурам, у которых может не быть технического бэкграунда — готовую разработку можно проверить на соответствие требованиям ТЗ.
В нашей практике встречаются два основных варианта и третий смешанный:
И ещё один момент. Не обязательно пытаться использовать в ТЗ технические формулировки, можно описать продукт своими словами. Тут как раз на помощь приходит Product Vision, о котором мы писали выше. Достаточно прийти с документом, где будут зафиксированы основные требования и пожелания.
Если вы хотите попробовать самостоятельно написать техническое задание, воспользуйтесь алгоритмом из нашего гайда. Он будет полезен для специалистов без технического бэкрграунда.
Можно попробовать взять за основу техническое задание из тех, что выкладывают в сети. Но нужно учесть некоторые моменты.
Во-первых, существует огромное количество шаблонов, и отыскать среди них подходящий под ваши требования сложно. Придётся перечитывать множество ТЗ и пытаться собрать по кускам что-то своё.
Во-вторых, каждое цифровое решение компании создают под свои цели. И если взять готовый шаблон технического задания из Интернета, можно скопировать чужие цели и забыть про свои.
В-третьих, в шаблоне может быть много лишних пунктов, которые вашей компании не нужны. И наоборот, может не хватать тех требований, без которых вашему проекту не обойтись.
Компании, которые специализируются на подготовке ТЗ, сначала уточняют задачи клиента и цель создания конечного продукта. Затем они пишут техническое задание исходя из собранных сведений и требований.
Вспомним основное назначение технического задания — обе стороны должны правильно понимать друг друга. Из этого следует несколько рекомендаций, которые в этом помогут.
Формулировку «Сделать красивый сайт» исполнитель и заказчик могут понять по-разному. Чтобы не было разночтений, лучше избегать прилагательных «красивый», «хороший», «качественный», «быстрый» и абстрактных примеров «Сайт должен загружаться быстро». Быстро — это как? Такие предложения каждый человек может трактовать по-своему. Чем точнее описано техзадание, тем лучше получится результат.
Вместо спорных формулировок используйте однозначные.
Опять же, ТЗ работает с обеими сторонами — клиентом и исполнителем. Соответственно, ни для кого не должно быть непонятных слов. Поэтому специфические термины разработки лучше вынести в глоссарий. Не стоит использовать сложные определения, намного понятней будет, если писать человеческим языком, как в инфостиле у Ильяхова.
Этот же принцип работает и в другую сторону. Если в вашем бизнесе есть специфические термины, которые могут вызвать вопросы у исполнителя, лучше их пояснить. IT-компания — специалист в области разработки, и тонкости вашего бизнеса могут быть не очевидны. Поэтому лучше вынести в глоссарий сложные термины разработки и специфические термины бизнеса.
Всё, что можно продемонстрировать, лучше продемонстрировать. В процессе работы над техническим заданием можно опираться на существующие цифровые решения. Покажите заказчику похожие решения и продукты, которые вам нравятся. Такие референсы помогают наглядно показать, что вы хотите. А IT-компания поймёт, в каком направлении работать. Например, на одном сайте использован классный шрифт — покажите это на скриншоте. На другом сайте нравится дизайн — прикрепите скрин. На третьем сайте нравится вёрстка — снова скрин. Чем наглядней будет представлена задача, тем легче её реализовать.
Возьмём за основу пример технического задания на разработку сайта. Но этот же принцип работает с любым цифровым продуктом — мобильным приложением, сервисом, корпоративным порталом, порталом для обучения сотрудников или CRM-системой.
Все участники работы над проектом должны понимать, чем занимается компания и кто её целевая аудитория. Без этой информации невозможно создать сайт, который будет решать вашу бизнес-задачу.
В самом начале ТЗ должно быть указано название компании, род деятельности, потребности клиентов. Обозначается задача, которую будет выполнять сайт или приложение, и описывается планируемая функциональность. Важно сразу обозначить, что вы хотите — корпоративный портал, интернет-магазин или сервис по обработке изображений. Тогда исполнители с самого начала сфокусируются на конкретной задаче, и вы не получите сайт-визитку вместо интернет-магазина.
В этом пункте необходимо указать всё, что влияет на работу сайта. Описать требования к CMS, рекомендации по выбору хостинга, скорость загрузки страниц сайта, его устойчивость к большому потоку посетителей и защита от спама.
Может показаться излишним указывать, что сайт должен быть адаптивным, то есть работать в любых браузерах (Google Chrome, Yandex, Opera и т. д.) и на разных видах устройств (компьютеры, ноутбуки, телефоны, планшеты). Но лучше перестраховаться и описать всё. Техническое задание — это документ, по которому вы будете принимать работу.
Структура — это основа сайта. В ней прописывают, какие разделы и страницы планируются на сайте. Оформить структуру проекта можно с помощью списка со вложенностью или схемы.
Всем участникам процесса необходимо понимать, как будут выглядеть страницы сайта. Для этого можно описать, из каких элементов будет состоять каждая страница. Или представить информацию более наглядно с помощью вайрфреймов. Вайрфреймы — это схемы расположения контента на страницах. А можно использовать оба варианта — описать и продемонстрировать.
Следующий этап — описать, как пользователи будут двигаться по сайту. При работе с простыми лендингами, где путь пользователя однозначен и очевиден, этот шаг можно пропустить. Но в более сложных решениях это поможет разработчикам понять, как выстраивать логику цифрового решения.
Для описания сценариев IT-продуктов используют следующий шаблон: действие пользователя — ответ сайта.
Например, если пользователь совершает одно действие, то сайт отвечает ему так. А если пользователь совершает другое действие, то сайт отвечает ему иначе. И таким образом прописываются все возможные сценарии использования программного решения.
Представим блог с подпиской на рассылку и посмотрим, как ведёт себя пользователь и как «отвечает» ему сайт.
Вопрос подготовки контента поднимается на этапе переговоров и составления технического задания. Необходимо решить, кто будет готовить тексты, картинки и видеоматериалы. Это можете быть вы, а может быть исполнитель. Если контент готовится на стороне исполнителя, необходимо дополнительно описать к нему требования.
Размещение контента — ещё один вопрос, который прописывается в ТЗ. Одна компания-разработчик самостоятельно добавляет контент на сайт, другая оставляет шаблонный текст, а корректный контент размещает клиент, третья обучает клиента добавлению и корректировке контента. Варианты могут быть разные, и нужно договориться и осветить этот момент в техническом задании.
На этапе обсуждения проекта вы проговариваете, какое настроение и какой эмоциональный отклик будет передавать сайт или приложение. Здесь как раз в качестве референсов можно показывать существующие цифровые решения.
Если есть фирменный стиль, то дизайн сайта продумывается с учётом брендбука. Если айдентики нет, то обсуждаются и фиксируются требования к дизайну:
В техническом задании прописывается, как подрядчики будут отдавать результаты работ по дизайну — в виде мудборда, вайрфреймов, кликабельного прототипа, самих макетов, UI-kit’а или дизайн-системы. Также фиксируется количество итераций для правок при приёме дизайна и сроки ответа заказчика.
Создание технического задания — это первый шаг разработки. Здесь большое значение имеет совместная работа заказчика и специалистов, которые составляют ТЗ. Чаще всего это взаимодействие происходит через интервьюирование, которое носит итерационных характер — встреч может быть несколько. Задача компании — понять ваши ожидания к будущему цифровому решению.
На встречах выясняют требования к проекту: цели, задачи, функциональность, необходимость интеграций. После того как вся информация собрана, команда разработки приступает к подготовке ТЗ. Системный аналитик проектирует архитектуру цифрового решения, технический лидер продумывает техническое воплощение задач. Далее команда встречается с клиентом, презентует, согласовывает и утверждает результат. Когда ТЗ готово, можно переходить непосредственно к разработке.
В процессе подготовки технического задания участвует вся будущая команда: аналитик, менеджер проекта, дизайнер, ведущий разработчик проекта. Срок составления ТЗ в среднем занимает от двух недель до двух месяцев, это зависит от объёма и сложности цифрового продукта.
ТЗ для государственных закупок требуют особого внимания, так как при его написании необходимо следовать 44-ФЗ, требованиям Антимонопольной службы и законодательству о техническом регулировании. Заказчики должны прозрачно и точно прописывать в техническом задании требования. Тогда подрядчики смогут оценить объём и уровень сложности работы и подготовить предложение.
Закон 44-ФЗ не регламентирует, что должно содержаться в ТЗ, но оно должно давать чёткое понимание о задачах заказчика.
Поэтому важно описать в техническом задании следующие пункты:
При составлении ТЗ для тендера необходимо помнить, чем конкретнее заказчик пропишет вышеперечисленные пункты, тем меньше поступит запросов на разъяснение от потенциальных участников закупочной процедуры. Также этим снимается фактор «отпугивания» — на этапе первичного рассмотрения техническое задание с большим количеством «тёмных пятен» настраивает специалистов на негативный лад. Проанализировать ТЗ, составить список вопросов на разъяснение — это время, которое сейчас самый дорогой ресурс.
Прежде всего техническое задание — это инструмент, который должен помогать разработке цифрового решения. Если есть готовое ТЗ, мы его изучим и сориентируем вас по сроку и бюджету. Если есть только видение проекта, мы сможем работать и с ним. Или поможем оформить его в техническое задание.
Если для ваших задач не подходит ТЗ и необходима гибкая разработка, мы скажем вам об этом и будем разрабатывать проект по спринтам. То есть разделим работу на небольшие временные промежутки, в конце которых будем презентовать конкретный результат.
Наш приоритет — сделать так, чтобы цифровой продукт работал на цели вашего бизнеса.
