17/07/2017
✅ Зачастую этап составления технического задания при разработке веб-проектов игнорируется многими заказчиками и исполнителями. Именно это становится причиной разочарования и обманутых ожиданий после реализации.
Чтобы помочь клиентам и специалистам понять, что собой являет полное техническое задание на веб-проект (будь то разработка интернет-магазина, сайта-каталога и т.п.), мы сделали проверочный чек-лист, что должно включать ТЗ. ↘
В процессе работы мы поняли, что практически любое техническое задание при правильном подходе должное содержать один и тот же минимальный набор разделов. Конечно, в зависимости от конкретики проекта некоторые пункты могут опускаться:
✔ 1) Общая информация о проекте
✒ Концепция продукта – потребность или проблема, которую продукт решает, общая логика решения, целевая аудитория;
✒ Цели и задачи проекта – коротко описать, какие есть конкретные цели проекта в цифрах (KPI): достичь трафика 10 000/мес, увеличить продажи на 20% и так далее;
✒Словарь терминов, использованных в ТЗ – названия особых систем клиента, технические термины, у которых в контексте данного техзадания может быть свое значение;
✒ Перечень документов, на основании которых создается проект – ссылки на внешние документы, прототипы, исходники дизайна, для того чтобы не искать по телу документа;
✒ Карта разделов или страниц проекта – в формате дерева или хотя бы просто иерархического списка для того чтобы было сразу понятен объем разрабатываемого ресурса.
Для чего это нужно описывать: разработчики должны понимать с чем они будут работать, для кого создается ресурс, какие цели перед ним ставятся, чтобы максимально использовать свой опыт.
✔ 2) Прототип и дизайн
✒ Прототип или мокапы – для любого современного интернет-проекта разработка прототипа или мокапов является необходимым и очень ускоряет процесс и точность оценки;
✒ Дизайн – если уже готов на данный момент, то прикрепить ссылку на исходные файлы макетов отдельным архивом;
✒ Описание динамики страниц – как должен реагировать интерфейс при нажатии на различные элементы управления, эффекты, появление всплывающих окон и подсказок и т.п. Обычно эту часть клиенты описывают легче всего;
✒ Требования к мобильной или адаптивной версии – на каких устройствах предполагается работа с этим проектом – платформы, браузеры.
Приложить прототип или мокапы обычно недостаточно для оценки и разработки сложного проекта. Дизайн, особенно без адаптивной версии, тоже не достаточный для того чтобы оценивать проект. Динамичный прототип, с хорошо оформленным описанием и ссылками на дизайн соответствующих страниц, помогает увидеть и воспринять всё взаимодействие с продуктом.
✔ 3) Функциональная часть проекта
✒ Информационная архитектура проекта должна быть описана структура сущностей проекта – сущностей базы данных, объекты системы, основные функции ядра, роли пользователей проекта;
✒ Функциональная спецификация под прототип – помимо динамики страниц, описанной выше, должно быть описано какие алгоритмы или какие функции ядра системы вызываются;
✒ Описание бэк-офиса – функционал для администратора, контент-менеджера и других – как будет построено администрирование и наполнение проекта;
✒ Интеграции с внешними и внутренними системами – какие данные передаются, куда, в каком виде, например, если используется API сторонних систем, то как именно;
✒ Тестирование ресурса – на каких устройствах, платформах, браузерах и при каких условиях будет тестироваться проект;
✒ Требования по безопасности ресурса – общие или специальные требования к безопасности;
✒ Требования по нагрузке и серверам – какую нагрузку должен выдерживать проект и на каких серверах размещаться.
Это как раз самая техническая часть проекта, которую в большинстве случаев клиент не может описать самостоятельно. Её нужно писать вместе с профильными специалистами.
✔ 4) Организационная часть проекта
✒ Роли в проекте со стороны Заказчика и Исполнителя, и распределение ответственности – кто, поименно, участвует в проекте с обеих сторон, кто за что отвечает.
✒ Идеология проекта – общее описание основных принципов, которых и Заказчик, и Исполнитель договорились придерживаться на проекте
✒ Порядок приемки работ – как будут приниматься работы, как трактуются неточные формулировки, порядок исправления ошибок и недочетов
✒ Порядок запуска проекта – как конкретно, в какое время и при соблюдении каких условий происходит запуск. Какой процесс запуска проекта и как это синхронизировано с рекламой и другими сферами деятельности проекта.
Это один из самых важных разделов, который позволяет не поссориться на проекте и успешно довести проект до запуска.
