Найти тему

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

Оглавление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше полезного и интересного читайте в блоге Nowmedia