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