Техническое задание на сайт: что оно должно фиксировать до разработки

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

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

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

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

Почему списка страниц и функций недостаточно

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

Что нам подходит?

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

Документ может выглядеть завершённым. Но главный вопрос всё ещё остаётся без ответа:

Что должно помочь человеку различить три направления и выбрать подходящее?

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

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

Недостаток здесь не в количестве подробностей.

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

Что должно стать ясным до подготовки ТЗ

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

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

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

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

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

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

Чем бриф отличается от технического задания

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

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

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

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

Бриф помогает начать разбираться в задаче. ТЗ фиксирует результат этого понимания.

Какие договорённости должно закреплять ТЗ

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

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

Размер ТЗ сам по себе ничего не говорит о его качестве.

Важнее, можно ли из документа понять:

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

Какую задачу должен решать сайт

Исходное пожелание может звучать так:

Создать современный сайт с тремя страницами услуг.

Из него понятно, что предлагается сделать, но неизвестно зачем.

Более обоснованная формулировка:

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

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

Что именно должно быть создано

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

Вернёмся к компании с тремя услугами.

Само решение создать отдельные страницы ещё не объясняет их роль.

Одно из возможных требований может звучать так:

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

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

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

В каких границах выполняется работа

Привычные формулировки могут скрывать разный объём проекта.

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

Если это не уточнено, заказчик и исполнитель могут считать согласованными разные объёмы работы.

Одинаковое название работы не создаёт общей договорённости, если стороны вкладывают в него разный смысл.

Как будет оцениваться результат

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

Например:

После отправки формы человек видит подтверждение, а данные поступают ответственному сотруднику по согласованному каналу.

Здесь понятно, что должно произойти и как проверить выполнение.

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

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

Чем требование отличается от пожелания

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

Например:

Описание услуги должно быть понятным.

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

Более содержательная формулировка:

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

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

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

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

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

Он знает контекст компании, её процессы, ограничения и ожидания от проекта.

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

Поэтому ТЗ обычно становится результатом совместной работы.

Формат может различаться, но задача документа остаётся одной — согласовать основу для реализации.

Может ли в ТЗ оставаться неопределённость

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

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

Открытый вопрос сам по себе не делает документ слабым.

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

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

Когда техническое задание готово к разработке

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

Если понимание различается, документ ещё не может выполнять свою роль.

Готовность ТЗ не означает, что проект больше не изменится.

Она означает, что разработка начинается с уже понятой задачи, а не с попытки выяснить её по ходу работы.