Кабы схемку, аль чертеж, мы б затеяли вертеж...
Тит Кузьмич и Фрол Фомич
Нужно ли ТЗ сайту? Сегодня это один из самых спорных вопросов веб-разработки.
Разумеется, вопрос решается сам собой, когда речь идет о таком сайте, беглый осмотр которого может занять час-полтора, а количество обслуживающих его модулей не пересчитать по пальцам рук. Разработчики таких ресурсов прекрасно знают цену «схемкам» и «чертежам», и знают, что действительно «правильным» ТЗ становится только в финале проекта.
Но если сайт, в техническом плане, вполне обыкновенный, и объем не слишком... Как здесь быть?
Часть веб-разработчиков считают, что ТЗ однозначно нужно всем сайтам, и тратят на его разработку много времени и сил, а в итоге — значительную долю бюджета проекта.
Есть и другая часть разработчиков, которые тоже считают, что нужно, но их подход к разработке ТЗ весьма формалистичный. ТЗ у них, в лучшем случае, напоминает развернутую смету, а в худшем — это несколько страниц с разреженным текстом, которые они могут приложить практически к любому своему сайту. Такое ТЗ, иногда, предоставляется бесплатно.
И, наконец, явное меньшинство веб-разработчиков уверены, что ТЗ это напрасная трата сил и средств, и что без него вполне можно обойтись. Мол, достаточно грамотно составленного договора и детальной сметы, а в остальном — хороший менеджмент и качественная работа.
Еще, на моей памяти был случай, когда заказчик вдруг потребовал ТЗ от исполнителя, после того, как уже были представлены и рассмотрены эскизы. Вот уж, действительно, неисповедимы пути...
Систематисты и стихийщики
Поставим вопрос несколько иначе: «Нужно ли проектировать сайт?»
Думаю, что все сайтостроители на этот вопрос ответят: «Да».
Как ни крути, какой подход не используй, все равно, сайт надо сначала: и прикинуть, и оценить, и обосновать. Сайты вообще сперва придумывают, а уж потом делают. Трудно себе представить, как можно строить сайт, не представляя его себе.
Опытные веб-разработчики сводят весь смысл существования сайта к решению поставленных перед ним задач. Проектируется такой сайт обычно по принципу «убрать все лишнее». То есть, в начале совместными усилиями с заказчиком придумывается некоторый перенасыщенный сверх-сайт (благо, опыт одних и фантазия других позволяют), а потом, взглянув на предварительную смету такого сайта, приходят к более прозаичному, но реально необходимому варианту без излишеств.
Таким образом, вопрос о необходимости проектирования сайта однозначно решен. Другое дело, что проектируют все по-разному.
У одних, проектирование это полноценный этап, который идет в самом начале работы над сайтом. Назначается ответственный — главный проектировщик (обычно, это менеджер проекта), оцениваются трудозатраты и сроки на весь этап. Ответственный, кроме того, что сидит (или ходит из угла в угол), придумывая «что и как», также обеспечивает участие в процессе непосредственных разработчиков будущего сайта: дизайнеров, веб-технологов, программистов и т. д.
Хороший проектировщик, сразу же, старается вовлечь в процесс проектирования и заказчика, а не готовить ему сюрприз на подпись.
У других, проектирование — достаточно стихийный и по-настоящему творческий процесс. Проектированием здесь также занимаются все участники разработки, но не в одно отведенное время, не все вместе разом, и даже не по очереди. То есть, например, в начале менеджер с заказчиком до чего-то договорились, потом дизайнер сел придумал, потом заказчик не принял, и предложил иначе, потом менеджер, потом дизайнер, а потом веб-технолог и снова дизайнер, и даже бухгалтеру еще осталось на завершающих документах.
Конечно, в любом стихийном мероприятии есть свой стихийный лидер. Но все-таки, организовывает стаю не наличие в ней вожака, а инстинкт ее участников. Интересно, сколько нужно времени команде веб-разработчиков, чтобы у них сформировался «проектировочный» инстинкт, и наступила самоорганизация?
Легко предположить, что, относительно необходимости ТЗ, первые будут «за» (ну, по крайней мере, не будут слишком возражать), а вторые, скорее всего — «против».
Заинтересованный читатель здесь может почувствовать, что автор пытается протолкнуть свою точку зрения, намеренно утрируя картину. А ничуть. Мне довелось работать и у тех, и у других, так что, утрирую конечно, но не слишком. А проталкивать свою точку зрения буду позже.
При «систематическом» подходе (тот, что был в первом примере), ТЗ это вопрос нескольких часов, за которые главный проектировщик соберет в один документ все то, что было придумано и согласованно. Даже, если ТЗ составлено не будет, в головах участников останется представление о том, что нужно делать. И кроме того, процесс проектирования, так или иначе, где-то фиксируется, рисуются схемы, делаются наброски и т. д. Все это будет лежать на столах (или в папке «info»), и вряд ли до момента сдачи сайта отправится в корзину.
При «стихийном» подходе (второй пример), в принципе, не совсем ясно, кто должен садиться писать ТЗ. И, самое главное, когда его надо садиться писать: в начале — не актуально, в середине — не до этого, в конце — никому не нужно.
Естественно, так как оба эти подхода, в настоящий момент, используются (второй, конечно, гораздо реже), и тот и другой имеют свои плюсы и минусы.
Рассмотрим все по-порядку.
ТЗ на ТЗ
Не буду рассказывать о плюсах систематического подхода. Думаю, что всем веб-разработчикам они очевидны. Если, все же, интересно мое мнение, вы можете ознакомиться с ним здесь. Рассмотрим минусы.
Систематическое проектирование — дорогое удовольствие. Это основной минус, который, пожалуй, ставит под сомнение все плюсы этого подхода.
Для начинающих сайтостроителей, которые с трудом выползают на самоокупаемость производства, проектировать «как положено» — непозволительная роскошь. Как правило, у таких компаний слабый, или же, напрочь отсутствующий менеджмент проектов (нанять — дорого, вырастить свой — не из кого). Выходит, что организовывать проектирование, по-просту, не кому.
Руководство начинающей веб-студии, как правило, сосредоточено на привлечении клиентов (и плюс еще сто дел), у него совсем не остается времени на развитие технологий производства. «Делаем как-то, и ладно».
Кроме того, при тех бюджетах, на которые удается заключить договора начинающим компаниям, приходится экономить буквально на всем и, в первую очередь, на времени. Какие доводы не приводи, что «семь раз отмерь», инстинкт самосохранения заставляет, все же, садиться и «пилить-строгать» сразу после получения аванса. Хорошо, что результат, в большинстве случаев, устраивает заказчика. Все-таки, сейчас заказчики уже ориентируются, что, у кого можно купить, и за какие деньги.
Если же говорить о компаниях, которые уже вышли на определенный уровень, и нашли свое место на рынке, то здесь существует другая проблема: на сегодняшний день нет никаких общепринятых методов проектирования сайта.
Большое, казалось бы, счастье, что не надо получать лицензию на свою деятельность, а также следить за соответствием сайта некому ТУ или ГОСТу, оборачивается печальной действительностью — у каждого свое собственное мнение о том, как сделать хороший сайт. Причем, от проекта к проекту, это мнение меняется.
Каждый раз, затевая проектирование как этап, приходится перебирать, уточнять, а то и придумывать заново все методы и технологии не только сайтостроения, но и самого проектирования. И это — головная боль не только проект-менеджера, но и всей компании в целом. На подходах и приступах проект может затянуться на неопределенное время. Все зависит от того, «насколько этот новый сайт не похож на те, что мы делали раньше».
При таком раскладе никаких бюджетов, скорее всего, не хватит. И проектирование превращается в хронически убыточный этап, испытывающий терпение владельцев компании. Чаще всего, дело заканчивается тем, что на очередной итерации, проектирование прекращается волевым решением «сверху», и вход идет план «б», то есть, «все что не успели — разберемся по ходу дела».
В общем, ситуация с минусами такова, что рад бы в ней ошибаться. Но, конечно, есть и оптимистичные мысли.
Разглядывая пять разных ТЗ, для того, чтобы понять как делать шестое, появляется идея, после шестого, сразу написать седьмое ТЗ. ТЗ на ТЗ. И в нем, с холодной головой, постараться собрать все то хорошее, что удалось найти за прошедшие месяцы-годы.
Вот только вопрос. Делать его для себя, ночами, по всем правилам конспирации? Или делать его для всех, хотя, никто и не просил. Ругать будут, но может, кто-то дельное посоветует из своего опыта.
Школа супер-дизайнеров
Как я уже говорил, «стихийное» проектирование используется, в основном начинающими веб-разработчиками по объективным причинам. Они бы, может и рады проектировать более организованно, только кто им даст?!
Самое интересное, что есть компании, которые в веб-сфере отнюдь не новички, но они сознательно отказываются от всяких ТЗ и проектируют только по крайней необходимости, а то и вовсе не выделяют на это рабочего времени. Это «стихийщики» по убеждениям.
«Зачем писать ТЗ, которое никто не читает?», — первый довод который они приводят. И ведь правы, черт возьми.
«Я бы почитал», — говорю, но уже знаю, что мне будет сказано в ответ:
«Поэтому, ты сайтов у нас не заказываешь».
Это верно, и если бы я заказал, они бы отказались.
Редкий случай, когда заказчик читает ТЗ, и уж совсем большая редкость — желание заказчика понять это ТЗ.
Здесь множество причин, одна из которых, все то же отсутствие стандартных или общепринятых методов разработки. ТЗ, разработанное одной веб-студией, будут неделю разбирать в другой и не факт, что все расшифруют. Что же говорить о заказчике, получившему такое ТЗ на подпись.
ТЗ, написанное популярным языком, реально ли вообще? Если да, то точно не в ближайшее время.
«Нашего заказчика прежде всего интересует, как сайт будет выглядеть в конечном итоге, поэтому мы после договора, несем показывать эскизы», — второй веский довод.
И в этом они правы. Дело в том, что этап эскизов, до сих пор самый решающий во всем проекте, и поэтому самый нервозный, как для разработчика, так и для заказчика. Эскиз главной страницы решает если не всю судьбу проекта, то, по крайней мере, сильно влияет на его дальнейшее течение и во многом предопределяет задачи интеграции и наполнения контентом.
Сайты, сделанные в таких компаниях, чаще всего, отличаются особыми изысками в графическом оформлении. Красивая графика сайта, обычно обыгрывающая одну общую идею (концепцию, как говорят веб-дизайнеры), позволяет достаточно эффективно решать задачи связанные с имиджем продукта, услуги или бренда заказчика. Благодаря такой специфике, эти веб-разработчики редко испытывают недостаток в заказах, их портфолио блещет красотой, а клиенты не скупятся на хорошие бюджеты. Красота стоит денег, с этим не поспоришь.
Разумеется, у этих компаний и интеграция на хорошем уровне, и над контетном они работают прежде, чем разместить его на сайте. Но все же, большая часть бюджета сайта расходуется именно на идею оформления и графику (иногда, еще и анимацию), а все остальное — просто не должно портить впечатление.
«Проекты длятся по полгода, а иногда и больше. За это время любое ТЗ потеряет актуальность. Каждый раз его переделывать — немыслимо дорого, а во что бы то ни стало пытаться следовать всем изначальным договоренностям — значит быть негибкими по отношению к клиенту», — убедили окончательно.
Я бы еще добавил, что отсутствие ТЗ, в определенном смысле, привязывает заказчика к разработчику. Не то чтобы это следствие какой-то злой корысти со стороны разработчика. Скорее всего, здесь дело в хорошем менеджменте и особых доверительных отношениях, которые, через некоторое время успешной совместной работы, устанавливаются между сторонами проекта. В общем: «Несите эскиз, а там посмотрим, насколько мы с вами друзья».
С ТЗ все ясно, его в этих компаниях редко делают. А, что касается проектирования, то основная работа в этом направлении ложится на плечи дизайнеров (еще, конечно, на менеджеров, но в гораздо меньшей степени). Дизайнер — ключевая фигура в таких компаниях, и он вовсе не только рисует-оформляет, существенная часть работы по управлению проектом также лежит на нем.
Дизайнеры ставят конкретные задачи перед сайтом (общие формулировки задач они получают от менеджеров), доступными им средствами находят методы их решения, инструктируют всю команду и следят за всей последующей реализацией проекта.
Бывает это так. Вот садится дизайнер, думает, например, над корневой страницей каталога сайта. Придумывает так, чтобы было и красиво, и функционально, и удобно. Картинки здесь, ссылки тут, краткие описания и т. д. Показывает клиенту, клиенту — нравится. Потом идет к веб-технологу и объясняет как это нужно верстать, потом, программисту — как это должно работать. Смотрит, что получилось, показывает клиенту, ругается на всех... Следующая итерация.
При обнаружении ошибок, или при изменении исходных данных клиентом, именно дизайнеры первыми оценивают случившееся, вносят корректировки в то, что уже было сделано, и при этом еще думают, как сделать так, чтобы эти изменения не сильно отразились на всех последующих этапах. Это и есть ходячие ТЗ, которые держат весь проект в голове, и часто видят его в кошмарных снах.
Любой дизайнер, проработавший в таких условиях 2-3 года, становится супер-дизайнером. Настоящим профессионалом веб-разработки. А если не становится — бросает все это дело и, если здоровье еще не окончательно подорвано, устраивается в другую, более спокойную веб-студию.
В заключение речи о «сознательных стихийщиках», хочу выразить большое уважение к этим немногим компаниям. Их путь к звездам весьма тернист, но принципы их благородны. Риски высоки, но каждый завершенный проект — это повод выпить ящик шампанского.
Супер-дизайнеры, рано или поздно, из таких компаний будут уходить, и многие из них откроют свои собственные компании. Быть может, очень хорошие компании.
На этой радостной ноте, можно было бы и закончить статью (букв и так уже слишком много), но в самом ее начале я еще упомянул про «формальный» подход к ТЗ. Правда, сказать об этом хорошего нечего. К сожалению, «формалистов» в проектировании сегодня очень много, а хочется, чтобы было значительно меньше.
Типовое ТЗ
Причины существования «формалистичного» подхода мне кажутся достаточно очевидными. С одной стороны это желание сэкономить, а с другой — выглядеть в глазах клиентов «не хуже других», соответствовать некому общему стереотипу солидной веб-студии, у которой все с документами и на фирменных бланках.
Два, в общем-то, вполне разумных желания, в своем сочетании, дают неразумный результат. Если не хватает денег на то, чтобы выглядеть, всегда можно наскрести на то, чтобы пустить пыль в глаза. Так появляются сначала типовые КП, потом типовые ТЗ и, как результат, сайты: редко — хорошие типовые, часто — очень плохие. Часто плохие, потому, что далеко не всегда заказчику действительно нужен сайт «в точности как вот этот». Да и сами веб-разработчики не особенно охотно предлагают своим клиентам типовые готовые решения, так как их бюджет очень мал.
Вообще, готовые решения вещь очень хорошая. Такие сайты в комплекте с темами оформления, как правило, разрабатываются профессионалами, и всегда выглядят достойно.
Последнее время, стали активно развиваться различные интернет-сервисы, а также некоторые бесплатные CMS, позволяющие без особого труда и специальных знаний создать типовой сайт самостоятельно, не прибегая к помощи веб-разработчиков.
Конечно, пока еще рано говорить о «бесплатном сайте за 10 минут, каждому», все-таки, большинство людей еще не слишком уверенно чувствуют себя в интернете. Простота таких сервисов и CMS, весьма относительна. Мне — просто, а человеку который не знает, как прикрепить файл к email-сообщению — нереально сложно.
В большинстве случаев, при очень скромном бюджете, заказчику нужно «как там, но немного по-другому». Вот это самое «немного по-другому», на деле оказывается «совсем по-другому», и типовое решение превращается в недоделанное нетипичное.
Требуемые отличия от типового сайта, как правило, нисколько не отражаются в «формальном» ТЗ. Такое ТЗ, вообще, мало, что отражает. Оно может содержать даже 15-20 страниц (с титульным листом, оглавлением и колонтитулами почти в треть страницы), но быть совершенно неинформативным.
Изначальные создатели готовых решений иногда снабжают их документацией, но она, в основном, не предназначена для широкого круга лиц. Полезной она может быть только специалисту. Поэтому для заказчика составляется некое описание внешнего вида типового варианта, и при этом закрываются глаза на все ограничения его применимости. Мало кто задается вопросом, во что выльется проблема несоответствия этого ТЗ тем задачам, которые были обозначены заказчиком и поставлены перед сайтом.
Ситуация, в которой оказываются разработчик и заказчик с таким ТЗ «на руках», конечно, не всегда заканчивается конфликтом сторон. Опять же, здесь стоит упомянуть, что заказчики редко вникают в суть предложенного ТЗ и подписывают его после беглого просмотра заголовков.
Возникающие спорные ситуации, обычно, решаются в пользу заказчика. Даже если заказчик явно не прав, делают так как он хочет, потому, что вступать в спор — дороже. Да и вообще, никто из команды разработки не имеет внятного представления о том, на чей стороне здесь правда. «Делаем как обычно, а на привередливость клиента у нас есть запас бюджета».
Плохо дело становится, если все же случился конфликт, и стороны начали апеллировать к подписанным документам. Не буду описывать картину в деталях, ее легко представить.
Еще хуже, если конфликт закончился разрывом отношений и заказчик с наработками и готовым ТЗ обратился в другую компанию, будем считать, что действительно другую. Эта компания получив ТЗ и, глядя на то, что уже сделано, долго пытается убедить клиента, что это ТЗ никуда не годится и работать по нему нельзя. Очень сложно убедить заказчика, который уже «натерпелся» от веб-разработчиков, что предлагаемый другой подход не обернется такой же неудачей.
Здесь я вовсе не призываю объявить войну «формалистам». Если будет надо, она будет объявлена и без меня. Все-таки, рынок решает «кому жить», а не мнение одного человека. И очень хорошо, что это так.
Надеюсь, что время, как всегда, расставит все по своим местам. «Систематисты» придут к общим стандартам, «стихийщики» к ручной работе за большие деньги, а «формалисты» соберут такие базы готовых решений, что всякая реальная потребность в проектировании у них просто отпадет.
Написал Александр Ефременко, 22 декабря 2009