Техническое задание на сайт: кто готовит?

Техническое задание на сайт: кто готовит?

— Но вы же утвердили техническое задание?!

— Техническое задание?

Мы думали, ТЗ — это «точка зрения», и у нас их несколько...

Старая бородатая шутка

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

Вариант №1: техническое задание на сайт готовит заказчик

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

Когда ресурс готов, обнаруживается, что серьезные кейсы и веселые публикации про прошедший корпоратив идут одним списком. Потому что для формы публикаций в ТЗ не заданы атрибуты категорий. А еще в блок «Похожих статей» выводятся отнюдь не похожие материалы. Причина та же — в ТЗ не прописано, по какому алгоритму определять тематическую схожесть статей. Дальше — больше. Процесс оформления заказа расписан детально, но не указано, что делает сайт, если не заполнено одно поле или заказ не подтвержден СМС. Что система покажет пользователю? Где и как менеджер увидит незавершенный заказ?

Вопросы при разработке ТЗ

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

Ситуация может развиваться в двух направлениях:

1. Неучтенные моменты обнаружили при разработке. Печально, но не смертельно. Меняется техзадание и смета, отодвигается срок сдачи. Стоимость проекта в 99% случаях оказывается больше запланированной.

2. Недоработки ТЗ повлияли на работоспособность ресурса после сдачи проекта (сайт «ложится» на 10 тыс. посетителях, дублирующиеся в 2-4 категориях товары с разными URLами ухудшают ранжирование в поисковиках и пр.). Все плохо. Нужны не косметические правки, а полномасштабный ремонт.

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

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

Вариант №2: техническое задание на сайт делает исполнитель

Стандартная схема разработки ТЗ на сайт в исполнении разработчика выглядит следующим образом:

  1. Заказчик обрисовывает, как он видит сайт, описывает задачи.
  2. Исполнитель уточняет данные, возможно, дает заполнить бриф.
  3. Разработчик составляет ТЗ, согласовывает с заказчиком.
  4. В соответствии с ТЗ разрабатывает сайт.

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

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

Вариант №3: создание техзадания третьей стороной

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

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

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

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

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

Есть проект? Свяжитесь с нами.
Дальше: Развитие корпоративного сайта
Напишите нам
Загрузка...
Спасибо
Загрузка...