Новости
Статьи
Почему без ТЗ – ХЗ | ТЗ на разработку сайта
23.08.2018
На стадии проектирования менеджер IT-компании, так или иначе, сталкивается с написанием технического задания на разработку сайта. Однако часто не относится к нему с должным вниманием. Для чего нужно техническое задание, почему его нельзя игнорировать и как его оформить, читайте в нашей статье.
Зачем и кому нужно техническое задание?
Действительно, зачем? Требования клиента услышаны и записаны. Встреча заканчивается одобрительными кивками с улыбками на лице. Гармония. Полное понимание. После составления сметы и озвучивания конечного бюджета проекта.
Веб-студия сопротивляется и не хочет уменьшать полученные цифры. Заказчик не понимает выставленный ценник, начинает ставить условия... Менеджер хватается за голову. Используя все свое дипломатическое искусство, пытается объяснить, что входит, а что не входит в обязанности компании и почему получились такие цифры. Напряжение нарастает. Тут как раз и вспоминается тот упущенный этап при проектировании сайта. То самое техническое задание, которое разрешило бы все разногласия.
Есть ТЗ - всё равно результат ХЗ
Обычно digital-агентство пишет техническое задание до начала разработки ресурса. Подтвержденное на первом этапе техническое задание, по ходу работы может корректироваться. Как правило, в нем прорабатываются важные моменты, формируется единое видение проекта заказчика и веб-студии.
ЧЕМУ ВЕРИТЬ: ТЕСТАМ ИЛИ МНЕНИЯМ?
Из чего стоит техническое задание на разработку сайта
Каким же образом решает разногласия техническое задание, что в нем такого особенного написано? Давайте разберем по пунктам.
Начнем с небольшого экскурса в историю. В далеком 1978 году, советские умы, создали и написали ГОСТ 19.201-78 ТЗ на программное обеспечение, через 9 лет появился еще один любопытный документ ГОСТ 34.602-89 ТЗ на автоматизированную систему. И внимание. До сих пор эти ГОСТы никто не отменял, и во многом написанные сейчас технические задания схожи с тем, что предлагают эти документы. Более чем двадцатипятилетний период, разделяющий современных разработчиков и авторов документов, конечно, внес свои коррективы. Но для выполнения государственных заказов некоторые компании до сих пор пользуются ГОСТОМ 34 . Представленный нами список пунктов, конечно, не истина в последней инстанции, но вполне служит ориентиром для написания подобного рода документов.
1. Цель ресурса
Здесь нужно четко обозначить задачи, которые выполняются ресурс. Информирование ли это о новостях компании, продажа ли товара через интернет или что- либо другое. Чем четче будут поставлены задачи, тем легче будет ориентироваться дальше команде разработчиков.
В этом пункте задачи формируются в конкретные технические средства, которые будут реализованы на сайте. Работа основного функционала фиксируется, механизм поэтапно прописывается. Так, например, функция «оформить заказ» - базовая для интернет-магазинов, пошагово расписывается в ТЗ.
3. Термины и определения
Крепкая основа понимания заказчика и исполнителя. Важно объяснять не все узкоспециализированные термины, а именно те, которые используются в работе.
4. Структура сайта
Это одна из главных частей технического задания. В этом пункте ТЗ описывается модель будущего сайта: количество страниц, связи, переходы, содержимое страниц в виде блоков. Для наглядности многие веб-студии рисуют прототип. Это значительно облегчает диалог с заказчиком.
5. Требования к надежности
Эти требования фиксируются для крупных, посещаемых, многостраничных сайтов, чтобы предотвратить их возможную поломку.
6. Требования к серверу
В зависимости от сайта, выбирается определенный вид хостинга, либо виртуальный сервер с определенными характеристиками.
7. Наполнение контентом
Здесь оговариваются объемы контента, которые готова предоставить компания – подрядчик для работы компании. Как правило, оговаривается минимум, необходимый для запуска сайта.
8. Сдача и приемка. Тестирование продукта.
В этом пункте оговариваются финансовые отношения компаний: определяются условия, при которых заказчик расплачивается за работу. Будет ли это одноразовый платеж, поэтапный, какой будет тестовый период сайта, и как будут вноситься доработки в уже принятый сайт.
Оформление ТЗ
Допустим, необходимая информация собрана. Осталось ее оформить и преподнести заказчику. Лучше это сделать при личной встрече, предварительно отправив документ заказчику для ознакомления. Заказчик вносит правки в документ и утверждает его. Как правило, после этого стадия предпроекта завершается, и web-студия приступает к работе. При возникновении дополнительных работ, компания-разработчик сообщает об этом компании-заказчику, поясняя причину возникших доработок.
На этапе проектирования заказчика в первую очередь интересует функционал , при помощи которого он добьется своей бизнес-цели. Благодаря прототипированию сайта, можно без лишних слов и терминов продемонстрировать работу установленного на сайте функционала. Для экономии времени в техническое задание помещаются скриншоты прототипа, которые наглядно показывают работу того или иного сервиса.