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