Тезис против антитезиса. Часть 2.

Декабрь 20, 2009
|

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

Школа супер-дизайнеров

Как я уже говорил, «стихийное» проектирование используется, в основном начинающими веб-разработчиками по объективным причинам. Они бы, может и рады проектировать более организованно, только кто им даст?!

Самое интересное, что есть компании, которые в веб-сфере отнюдь не новички, но они сознательно отказываются от всяких ТЗ и проектируют только по крайней необходимости, а то и вовсе не выделяют на это рабочего времени. Это «стихийщики» по убеждениям.

«Зачем писать ТЗ, которое никто не читает?», — первый довод который они приводят. И ведь правы, черт возьми.

«Я бы почитал», — говорю, но уже знаю, что мне будет сказано в ответ:

«Поэтому, ты сайтов у нас не заказываешь».

Это верно, и если бы я заказал, они бы отказались.

Редкий случай, когда заказчик читает ТЗ, и уж совсем большая редкость — желание заказчика понять это ТЗ.

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

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

«Нашего заказчика прежде всего интересует, как сайт будет выглядеть в конечном итоге, поэтому мы после договора, несем показывать эскизы», — второй веский довод.

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

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

Разумеется, у этих компаний и интеграция на хорошем уровне, и над контетном они работают прежде, чем разместить его на сайте. Но все же, большая часть бюджета сайта расходуется именно на идею оформления и графику (иногда, еще и анимацию), а все остальное — просто не должно портить впечатление.

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

Я бы еще добавил, что отсутствие ТЗ, в определенном смысле, привязывает заказчика к разработчику. Не то чтобы это следствие какой-то злой корысти со стороны разработчика. Скорее всего, здесь дело в хорошем менеджменте и особых доверительных отношениях, которые, через некоторое время успешной совместной работы, устанавливаются между сторонами проекта. В общем: «Несите эскиз, а там посмотрим, насколько мы с вами друзья».

С ТЗ все ясно, его в этих компаниях редко делают. А, что касается проектирования, то основная работа в этом направлении ложится на плечи дизайнеров (еще, конечно, на менеджеров, но в гораздо меньшей степени). Дизайнер — ключевая фигура в таких компаниях, и он вовсе не только рисует-оформляет, существенная часть работы по управлению проектом также лежит на нем.

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

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

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

Любой дизайнер, проработавший в таких условиях 2-3 года, становится супер-дизайнером. Настоящим профессионалом веб-разработки. А если не становится — бросает все это дело и, если здоровье еще не окончательно подорвано, устраивается в другую, более спокойную веб-студию.

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

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

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

Типовое ТЗ

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

Два, в общем-то, вполне разумных желания, в своем сочетании, дают неразумный результат. Если не хватает денег на то, чтобы выглядеть, всегда можно наскрести на то, чтобы пустить пыль в глаза. Так появляются сначала типовые КП, потом типовые ТЗ и, как результат, сайты: редко — хорошие типовые, часто — очень плохие. Часто плохие, потому, что далеко не всегда заказчику действительно нужен сайт «в точности как вот этот». Да и сами веб-разработчики не особенно охотно предлагают своим клиентам типовые готовые решения, так как их бюджет очень мал.

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

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

Конечно, пока еще рано говорить о «бесплатном сайте за 10 минут, каждому», все-таки, большинство людей еще не слишком уверенно чувствуют себя в интернете. Простота таких сервисов и CMS, весьма относительна. Мне — просто, а человеку который не знает, как прикрепить файл к email-сообщению — нереально сложно.

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

Требуемые отличия от типового сайта, как правило, нисколько не отражаются в «формальном» ТЗ. Такое ТЗ, вообще, мало, что отражает. Оно может содержать даже 15-20 страниц (с титульным листом, оглавлением и колонтитулами почти в треть страницы), но быть совершенно неинформативным.

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

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

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

Плохо дело становится, если все же случился конфликт, и стороны начали апеллировать к подписанным документам. Не буду описывать картину в деталях, ее легко представить.

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

Здесь я вовсе не призываю объявить войну «формалистам». Если будет надо, она будет объявлена и без меня. Все-таки, рынок решает «кому жить», а не мнение одного человека. И очень хорошо, что это так.

Автор записи: Александр Ефременко

Twitter Facebook Flickr