— Но вы же утвердили техническое задание?!
— Техническое задание?
Мы думали, ТЗ — это «точка зрения», и у нас их несколько...
Старая бородатая шутка
В одной веб-студии техническое задание ждут от заказчика. В другой делают сами. В третьей предлагают скачать из интернета. Истина где-то рядом: лучшее ТЗ получается у тех, кто собаку съел на развитии и поддержке сайтов. Расскажем почему.
Вариант №1: техническое задание на сайт готовит заказчик
Отойдем от стереотипа, что заказчик ничего не понимает в сайтах. У нашего гипотетического заказчика уже есть интернет-магазин, пару лет назад он согласовывал техническое задание, оплачивал разработку и все это время сам управляет ресурсом. Продвинутый такой клиент… Сейчас собирается запускать второй сайт и уверен, что знает, каким он должен быть и как будет работать. В ТЗ подробно описывает, например, структуру публикаций в блоге, тщательно указывая, где и как должны отображаться похожие материалы.
Когда ресурс готов, обнаруживается, что серьезные кейсы и веселые публикации про прошедший корпоратив идут одним списком. Потому что для формы публикаций в ТЗ не заданы атрибуты категорий. А еще в блок «Похожих статей» выводятся отнюдь не похожие материалы. Причина та же — в ТЗ не прописано, по какому алгоритму определять тематическую схожесть статей. Дальше — больше. Процесс оформления заказа расписан детально, но не указано, что делает сайт, если не заполнено одно поле или заказ не подтвержден СМС. Что система покажет пользователю? Где и как менеджер увидит незавершенный заказ?
Опыта разработки и эксплуатации одного, двух и даже трех сайтов недостаточно, чтобы детально описать, как должен работать четвертый ресурс. Где-то что-то обязательно будет забыто, пропущено.
Ситуация может развиваться в двух направлениях:
1. Неучтенные моменты обнаружили при разработке. Печально, но не смертельно. Меняется техзадание и смета, отодвигается срок сдачи. Стоимость проекта в 99% случаях оказывается больше запланированной.
2. Недоработки ТЗ повлияли на работоспособность ресурса после сдачи проекта (сайт «ложится» на 10 тыс. посетителях, дублирующиеся в 2-4 категориях товары с разными URLами ухудшают ранжирование в поисковиках и пр.). Все плохо. Нужны не косметические правки, а полномасштабный ремонт.
В обоих случаях результатом совместной работы становится негатив. Заказчик считает, что, увеличивая время работы за «такие мелочи», разработчики пытаются его «кинуть». Исполнитель, работая строго по ТЗ, воспринимает корректировки как «хотелки» и отказывается работать бесплатно. Компромисс возможен, но при любом исходе будут пострадавшие. Либо исполнитель доработает сайт в ущерб себе, либо заказчику придется увеличивать бюджет разработки.
Вариант №2: техническое задание на сайт делает исполнитель
Стандартная схема разработки ТЗ на сайт в исполнении разработчика выглядит следующим образом:
- Заказчик обрисовывает, как он видит сайт, описывает задачи.
- Исполнитель уточняет данные, возможно, дает заполнить бриф.
- Разработчик составляет ТЗ, согласовывает с заказчиком.
- В соответствии с ТЗ разрабатывает сайт.
Логичная схема. Но, составляя ТЗ на сайт, исполнитель делает это со своей точки зрения. Она может быть профессиональной, технически грамотной, но без учета специфики бизнеса клиента.
Вариант №3: создание техзадания третьей стороной
Третья сторона — независимый эксперт. Его задача — понять идею клиента и переложить ее на технически грамотный язык разработчика.
Составляя ТЗ на сайт, подрядчик думает не только о проекте, но и о бизнесе клиента. Кто покупатели? Что они будут делать на сайте? А что, если бизнес расширит географию? Очевидные и возможные риски, варианты защиты... С таким подходом получается посмотреть на ресурс глазами покупателя, оценить удобство управления со стороны клиента, возможности модернизации и масштабирования в качестве технического эксперта. Более того, не будучи заинтересован в раздувании бюджета на разработку, подрядчик предлагает оптимальные с точки зрения трудозатрат и функциональности решения, варианты конфигурации.
Ему не приходится выбирать между дешевым и хорошим. Он делает то, что отвечает задаче клиента.
Еще одно достоинство этого варианта — возможность сравнить стоимость услуг нескольких агентств и сменить команду разработки, если что-то не срослось. Проверено: когда новому подрядчику передают четко формализованное техзадание, он быстрее втягивается в рабочий процесс и сроки сдачи проекта не страдают.
И да, мы составляем технические задания на сайт для сторонних разработчиков. Знаем, где соломку подстелить и на чем заострить внимание, чтобы клиент получил не просто красивую страничку в интернете, а рабочий бизнес-инструмент.