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

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

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

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

Когда клиент впервые обращается к нам за разработкой, он по понятным причинам хочет хотя бы примерно понимать, во сколько ему всё это обойдётся. Но на консультации мы можем лишь обозначить «вилку». А после формирования максимально подробного техзадания уже можно точно сказать, сколько стоит создать сайт. Собственно, смета и формируется по его итогам и в дальнейшем не меняется. Если потом клиенту хочется что-то поправить, добавить, перекрасить, то все изменения мы фиксируем и оцениваем отдельно.

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

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

  • решить, какой сайт нужен — одностраничник, интернет-магазин, каталог и т. п.;

  • понять, для кого он и какие задачи должен выполнять;

  • определить, каким видится будущий проект, что нравится и что не нравится на примерах других сайтов;

  • описать конкретные измеримые требования к итоговому результату.

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

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

  • Цели и задачи проекта

Какой сайт хочет клиент и для чего.

  • Состав работ

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

  • Требования к сайту и программному обеспечению

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

  • Структура

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

  • Информационные блоки

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

Пример описания информационного блока и требований к нему
Пример описания информационного блока и требований к нему
  • Пользовательские сценарии

По каким схемам посетители будут взаимодействовать с ресурсом. Эти схемы помогают не упустить важный функционал. Часто разработчики выносят описание пользовательских сценариев в отдельную документацию (Customer journey map). Юзеркейсы полезны на этапе тестирования системы – тестировщик берет их в качестве основы для написания тест-кейсов.

  • Сущности

Описание объектов, которые будут на сайте, и связей между ними. Мы пробовали разные форматы описания сущностей, прижились таблицы. В таблице можно описать рабочее название сущности, её содержания (поля) и требования к каждому полю: формат, ограничения, вид в административной панели.

Пример описания сущности «Акция» из проекта корпоративного сайта
Пример описания сущности «Акция» из проекта корпоративного сайта
  • Интеграции и функциональные возможности

Какими должны быть административная панель, «личный кабинет», по какому принципу будет осуществляться обмен данными с внешними сервисами.

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

Чек-лист идеального ТЗ

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

1. ТЗ внятное.

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

2. ТЗ понятное.

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

3. В ТЗ есть детальное описание функционала.

Сразу должно быть понятно, что и как работает. Как добавлять на сайт новые тексты? Что будет, если загрузить изображение, размер которого превышает заданные параметры? Всё это нужно проговорить и прописать ещё до начала работ.

4. ТЗ содержит технические требования к работе интерактивных механизмов, структуру будущего сайта и его составных частей.

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

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

Поделитесь, как вы подходите к разработке ТЗ: также подробно все описываете или вам достаточно более краткого варианта?

Комментарии (4)


  1. ZodDZverev
    22.09.2021 05:34
    +1

    Главная мысль текста: неважно, как вы делаете ТЗ, но ТЗ должен делать ваш менеджер. А не заказчик.

    Даже если у заказчика уже есть какое-то там своё ТЗ, надо его переписать заново вместе с заказчиком с нуля. И не просто прочитать по зуму вместе и уточнить: а вот тут чего имели в виду, а вот тут чего имели?

    А прям физически переписать по своим стандартам от и до.

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

    И кстати, качественное ТЗ — это половина проекта. Ну, не всегда, но почти всегда. И поэтому ТЗ СТОИТ ДЕНЕГ. И поэтому ТЗ можно писать даже месяц или даже год иногда. Да, ничего страшного. Каждый час, потраченный на ТЗ — это минус 5 часов разработки. И минус 10 часов переделок. А то и 50 часов, в зависимости от запущенности.

    Понятно, что звучит это не аджайл. Но аджайл, кстати, тоже не отрицает ТЗ.


    1. Alente1 Автор
      22.09.2021 05:38
      +1

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


  1. E_BEREZIN
    28.09.2021 12:22
    +1

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

    1. Прототип (в несколько итераций)

    2. Дизайн после согласования прототипа (в несколько итераций)

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

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


    1. Alente1 Автор
      28.09.2021 12:36
      +1

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

      Но при написании ТЗ после разработки дизайна есть большая вероятность выйти из бюджета, который клиент готов потратить на эту самую разработку. (К сожалению, пока не все клиенты готовы работать по T&M и просят давать точную оценку проекта на этапе прототипов, поэтому иногда вынуждены делать ТЗ до дизайна).

      Про примеры значений и пользовательского интерфейса – отличная рекомендация, спасибо!