Зачем в IT-разработке нужно техническое задание: первый шаг на пути к цифровому продукту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Материал подготовлен компанией INOSTUDIO