Как правильно писать техническое задание на разработку веб-сайта
Всем привет, мы веб-студия Mad Design - специализируемся на разработке веб-проектов. Около 75% наших клиентов, при обращении к нам, не предоставляют вообще никакого ТЗ на разработку веб-сайта, около 20% пишут как могут, и оставшиеся 5% приходят к нам с подробным ТЗ (спасибо вам большое!). Эта статья для тех, кто хочет самостоятельно написать ТЗ для…
Практически всё предложенное ТЗ сосредоточено на функциональных требованиях и выглядит "заточенным" под интересы разработчика.
Иерархическая структура, логотип и цветовая гамма, продвижение и реклама - то, что мы умеем и любим при натягивании сайта на готовые шаблоны и CMS. А вот что мы не любим (и часто не умеем) - это бизнес-требования, особенно нефункциональные.
Для сайта важнейшей является нефункциональная сторона. И если заказчик не сформулирует свои бизнес-требования к характеристикам качества, то может жестоко за это поплатиться.
Например:
Производительность - ожидаемая скорость загрузки и отрисовки страниц, ожидаемое количество посетителей среднее и пиковое.
Надёжность - процент отказов, способы восстановления при сбоях, допустимый процент времени вынужденных простоев, а также какими средствами надёжность будет контролироваться.
Защищённость - как будут защищены данные пользователей и заказчика на разных этапах их обработки.
Ну и далее по списку, например, стандарта ISO 25010.
Очень актуальная на сегодняший день тема - соответствие законодательству. В первую очередь, поддержка требований закона о персональных данных и GDPR. Если на сайте что-то продаётся, то ещё и способы реализации 54-ФЗ.
Отдельно нужно сказать о юзабилити, которое в зависимости от назначения сайта, может быть важнейшим конкурентным преимуществом (или, наоборот, причиной провала). Если оно важно, то в ТЗ должно быть расписано, в каких сценариях ему нужно уделять особое внимание, какие показатели предполагается использовать для его оценки, и как они будут проверяться.
Разработчику, понятно, фиксация таких нефункциональных требований обычно не очень выгодна, потому что может в разы увеличить стоимость разработки и сопровождения.