Создать сайт или ХЗ?

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

Стоит начать с того, что существует разные подходы:

Объём такого документа может составлять более ста страниц, а на его оформление может уходить неделя и более. Конечно, клиент хочет чтобы мы взяли проект в работу в день его обращения, а ещё лучше – вчера. Но, по нашему опыту, составление хорошего ТЗ происходит быстрее и обходится дешевле, чем работа без него.

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

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

В таком случае мы по функциональным решениям предлагаем варианты, а по дизайну просим предоставить референсы: что заказчику нравится и что не нравится. Ссылки на референсы прописываются в ТЗ. Если этого не сделать, то мы получаем несколько совершенно разных представлений результата – у каждого участника своё. Поэтому стоит составить единый документ, с которым будем сверять результат работы. При этом важно:

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

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

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

У нас была такая ситуация. Заказчик просил сделать на сайте закрытый раздел для специалистов. Сроки поджимали, и на оформление техзадания просто не было времени. Вместо него клиент показал пример такого раздела: «Сделайте мне, как здесь». На первый взгляд задача была понятна. Мы пошли навстречу клиенту и взялись.

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

Объясню, почему плох подход «сделайте мне, как здесь». Итоговый продукт должен работать на задачи и аудиторию клиента. Даже если пример взят из той же ниши, могут быть различия. От понимания менеджером, дизайнером, разработчиком ситуации заказчика зависит результат. Например, одному из наших клиентов было важно с помощью сайта отстроиться от основного конкурента. Пожелание сделать сайт «не как у него» мы отразили в ТЗ и учитывали в работе.

Бывает, что и в техзадание вносятся правки. Допустим, у дизайнера появилась классная идея по оформлению. Согласовываем её с заказчиком и заключаем дополнительное соглашение. Но любое изменение в задаче увеличивает срок выполнения на 2-3 дня.

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

Наш пример не считаем идеальным и универсальным. Вы можете разработать свой шаблон. Вовсе не обязательно расписывать его на сто страниц.. Объём не всегда является показателем качества. Получится меньше – хорошо. Главное, чтобы в ТЗ были отражены перечисленные выше данные.

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

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

Наш полный бриф можно посмотреть тут – Бриф на разработку сайта

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

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

Вот список наиболее критичных замечаний:

«В техзадании желательно отразить максимум информации о сайте»

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

«Определение целей и задач проекта, это один из важнейших этапов»

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

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

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

Дальше пойдут основные моменты из наших технических заданий, все мы вам показать не можем по понятным причинам (интеллектуальная собственность), но «вырезки» важных пунктов будут опубликованы.

Аудитория

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

Категории пользователей

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

Структура

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

Прототип

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

Сайты образцы

В этой задаче нам поможет конкурентный шпионаж помните фразу «кради как художник» все до нас уже придумали, но бесспорно можно сделать лучше! Если первый вариант не подходит на помощь приходят такие прекрасные ресурсы как www.awwwards.com и www.behance.net. Здесь собраны десятки тысяч идей которые можно использовать как референс для вашего проекта, ах да еще можно и тут посмотреть наше портфолио).

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

А для самых внимательных читателей мы оставим ссылку на реальное ТЗ тут.

Выводы

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

Команда «Пиксель Плюс» для подготовки этой статьи собирала истории от проджект-менеджеров и разработчиков. Мы получили много откликов и мнений, наверняка, учли не всё. Значит, будем готовить материал для новой статьи.