Вы – умница! Знаете, что для создания сайта, необходимо сделать техническое задание (ТЗ). В этой статье рассматриваем, как сделать ТЗ на создание сайта или портала. В конце статьи вы получите нашу рыбу ТЗ, которую мы постоянно развиваем и улучшаем.
Важный момент, мы говорим о сложных сайтах, а не сайтах, сделанных с помощью сборки на WordPress или других CMS (системах управления сайтом). Мы говорим о порталах, биржах, CRM, онлайн-сервисах и так далее.
Зачем нужно ТЗ на создание сайта?
Если вы задумались построить дом, то имеет смысл нарисовать его план. Портал – это штука не менее сложная, чем дом. Почему же некоторые считают, что крупный сайт можно сделать без технического задания? Просто по обрывкам фраз или “как Youdo.ru”. ТЗ снижает риски, уменьшает бюджет и сроки проекта, улучшает аппетит, снимает бессонницу… Если вы работаете без ТЗ – фундамент вашего проекта строится на болоте.
Скажем так, лучше плохое ТЗ, чем вообще без него. ТЗ – это ваши ожидания относительно процесса и результата создания сайта. Если нет ожиданий, то что вы будете требовать от разработчика в итоге?
Более подробно проблему о необходимости и специфике ТЗ на разработку сайта мы разобрали в другой статье.
Содержание технического задания
Я не буду говорить о ГОСТе и детальных спецификациях по ГОСТу. На мой субъективный взгляд, гораздо важнее в точности описать то, что вам нужно, нежели придерживаться некоторых правил оформления.
Что является самым важным для ТЗ?
Раздел Цели и общее описание проекта. Здесь указываем реальные цели, которых должен добиться исполнитель при выполнении этого ТЗ. Очень кратко, просто для того, чтобы понять, в чем суть проекта.
Раздел Термины и определения. Не нужно забивать его общими понятиями типа “сайт”, “хорошо”, “плохо”. Здесь должны быть термины предметной области (например, “Обналичивание чеков”), с которыми предстоит познакомиться разработчикам, а также специфические термины, которых может не знать заказчик (например, “DNS-зона”). Термины и определения должны встречаться не только в этом разделе, а использоваться в ТЗ! Не создавайте мертвые термины, которые не планируете использовать.
Раздел Общие моменты по взаимодействию. Здесь мы проявляем различные ожидания по взаимодействию. Например, что все, что не описано в ТЗ – это доп (дополнительные работы; доработка, не включенная в ТЗ), который оплачивается отдельно. Заказчик должен сразу это понимать, а не делать изумленный взгляд, когда ему сообщают, что реализовать кабинет Исполнителя в системе – отдельный доп, которого нет в текущем ТЗ.
Раздел Структура сайта и структура данных. Важнейший раздел, где описывается скелет будущего проекта. Прописываем все страницы, карту адресов и краткое описание, что будет на странице. Это по сути задает некоторые границы проекта.
Структура данных описывает основные сущности, связи между сущностями и атрибуты сущностей. Например, сущность Заказ, имеет атрибуты – Стоимость, Товары, Дата заказа и др.
Раздел Требования к страницам. Здесь описываются конкретные требования к каждой странице. Главное слово “конкретные”. Очень опасно писать неконкретику в этом разделе – это порождает споры и недопонимание на этапе сдачи проекта. “Я думал, что это входит”, “а мы поняли это так-то…”.
В нашей практике был случай, когда лет 7 назад в ТЗ была прописана безобидная фраза “Интеграция с 1С”. Такого автора ТЗ можно смело увольнять – при такой постановке задачи заказчик вправе интегрировать все, что угодно из 1С. Нужно конкретно указать какие данные будут передавать из 1С (в одну сторону или в обе). Без этих деталей есть риск возникновения принципиальных разногласий.
Так что же описывать в разделе Требований к страницам? Во-первых, как работают кнопки, что выводится на странице, критерий вывода, ограничения по правам доступа, привести макет страницы (об этом позже), полезно также указать, что не входит в состав страницы для прояснения взаимных ожиданий.
Раздел Общие требования к сайту. Здесь необходимо описать требования к безопасности, верстке, дизайну, SEO, быстродействию, используемым технологиям и другим параметрам. Если вы что-то забыли, то считайте, что этого нет. Не описали требования к поисковой оптимизации – исполнитель сделает, как ему проще. А переделывать всегда сложнее, поэтому лучше сразу заложить требования в ТЗ и реализовать их. В нашей рыбе ТЗ вы найдете эти элементы.
Разделы про Различные процессы. Здесь имеется в виду в первую очередь Регламент внедрения сайта в эксплуатацию. Также сюда можно отнести настройку сервера, процессы приемки этапов. Чем точнее прописаны эти процессы, тем проще будет взаимодействие между заказчиком и исполнителем. Раз прописано и согласовано – значит надо делать. Отсутствие вариативности в этом плане – это хорошо.
Раздел про Требования к заказчику. Да, заказчик тоже должен участвовать в проекте. И надо явно обозначить его роль. Чем точнее эта роль и чем лучше заказчик осознает свои обязанности в проекте, тем больше шансов на успех проекта. Наверно кто-то подумает “вообще обнаглели. Заказчику вешают какие-то обязанности”. Можно и так сказать, но сознательный разработчик-исполнитель должен понимать, что ему не нужна в портфолио мертвая работа. Если заказчик себя плохо проявляет в начале проекта в плане общего менеджмента, то, вероятнее всего, проект быстро загнется, а исполнитель просто потратит время на неперспективный проект.
ТЗ на создание сайта и макеты (прототип)
И последнее, что непременно должно быть в современном ТЗ – это макеты.
Макеты – это схематичное отображение графического интерфейса портала.
Существуют программы, которые позволяют делать интерфейс интерактивным, т.е. кликать по кнопкам, переходить между страницами. Макеты сильно облегчают понимание. Рекомендую делать описание требований после согласования макетов, а не наоборот. Набросали макет, посмотрели в колле по скайпу, скорректировали, утвердили и можно описывать требования уже в текстовом виде.
Вот пожалуй и все, что нужно рассказать про ТЗ на создание сайта с человеческим лицом (не по ГОСТУ).
Так, а где рыба ТЗ? Рыба ТЗ на разработку сайта: https://web-automation.ru/wp-content/uploads/2017/11/ТЗ-Web-Automation.docx. Здесь учтены многие дополнительные нюансы, о которых мы не упомянули. Она составлена в таком плане, чтобы максимально прояснить ожидания по проекту.
Более глубокие знания о разработке ТЗ можно получить на нашем курсе создания технического задания.
P. S. Рекомендуем прочитать статью о стоимости услуг разработки ПО, которая подробно рассматривает вопрос ценообразования программирования и нюансы работы специалиста IT.