В этой статье мы опишем, что должно включать в себя техническое задание на веб-сервис, сложный сайт или интернет магазин, и почему.

Всё началось с того что на большие интернет-проекты нам начали присылать техзадания, написанные на 25-40 листах А4. Раньше мы всегда отдавали ТЗ на прочтение и оценку разработчикам, но когда в неделю приходит 3 или 4 подобных документа, даже на то, чтобы их внимательно прочитать, выписать список вопросов и понять чего в этом документе не хватает, может уйти вся неделя, а то и больше.

Вторая проблема заключалась в том, что клиенты, которые готовят технические задания самостоятельно, описывают в основном front-end и динамику страниц, не касаясь административной части, ролей на проекте, серверов, требований по нагрузке и прочего, что необходимо, чтобы качественно оценить разработку. 

Мы решили эту задачу сделав чеклист проверки техзадания: документ, в котором описано какие разделы ТЗ должны быть, что они должны включать в себя и почему. Детализацию по разделам и ссылку на скачивание нашего чеклиста смотрите ниже.

Как выглядит чеклист ТЗ во время заполнения

Основные разделы техзадания

Мы поняли, что ТЗ на разработку сервиса, крупного сайта, спецификация на онлайн-каталог, тех. задание на интернет-магазин в целом при правильной проработке должны будут содержать один и тот же минимальный набор разделов.

Общая информация о проекте

  • Концепция продукта – потребность или проблема, которую продукт решает, общая логика решения, целевая аудитория;
  • Цели и задачи проекта – коротко описать, какие есть конкретные цели проекта в цифрах (KPI): достичь траффика 10 000/мес, увеличить продажи на 20% и так далее;
  • Словарь терминов, использованных в ТЗ – названия особых систем клиента, технические термины, у которых в контексте данного техзадания может быть свое значение;
  • Перечень документов, на основании которых создается проект – ссылки на внешние документы, прототипы, исходники дизайна, для того чтобы не искать по телу документа;
  • Карта разделов или страниц проекта – в формате дерева или хотя бы просто иерархического спика для того чтобы было сразу понятен объем разрабатываемого ресурса.

Для чего это нужно описывать: разработчики должны понимать с чем они будут работать, для кого создается ресурс, какие цели перед ним ставятся, чтобы максимально использовать свой опыт.

Встречается возражение, что "мы не будем описывать для чего и для кого этот проект, это коммерческая тайна, нас интересует только реализация". Даже если это проект для ЦРУ, ФБР, СБУ или других служб госбезопасности, нужно рассказать разработчику ваши цели, чтобы он смог включиться и работать над проектом не просто как "руки". Риски утечки конфиденциальной информации решаются путем подписания Договора о неразглашении (NDA). 

Прототип и дизайн

  • Прототип или мокапы – для любого современного интернет-проекта разработка прототипа или мокапов является необходимым и очень ускоряет процесс и точность оценки;
  • Дизайн – если уже готов на данный момент, то прикрепить ссылку на исходные файлы макетов отдельным архивом;
  • Описание динамики страниц – как должен реагировать интерфейс при нажатии на различные элементы управления, эффекты, появление всплывающих окон и подсказок и т.п. Обычно эту часть клиенты описывают легче всего;
  • Требования к мобильной или адаптивной версии – на каких устройствах предполагается работа с этим проектом – платформы, браузеры.

Приложить прототип или мокапы обычно недостаточно для оценки и разработки сложного проекта. Дизайн, особенно без адаптивной версии, тоже не достаточный для того чтобы оценивать проект. Динамичный прототип, с хорошо оформленным описанием и ссылками на дизайн соответствующих страниц, помогает увидеть и воспринять всё взаимодействие с продуктом.

Функциональная часть проекта

  • Информационная архитектура проекта должна быть описана структура сущностей проекта – сущностей базы данных, объекты системы, основные функции ядра, роли пользователей проекта;
  • Функциональная спецификация под прототип – помимо динамики страниц, описанной выше, должно быть описано какие алгоритмы или какие функции ядра системы вызываются;
  • Описание бэк-офиса – функционал для администратора, контент-менеджера и других – как будет построено администрирование и наполнение проекта;
  • Интеграции с внешними и внутренними системами – какие данные передаются, куда, в каком виде, например, если используется API сторонних систем, то как именно;
  • Тестирование ресурса – на каких устройствах, платформах, браузерах и при каких условиях будет тестироваться проект;
  • Требования по безопасности ресурса – общие или специальные требования к безопасности;
  • Требования по нагрузке и серверам – какую нагрузку должен выдерживать проект и на каких серверах размещаться.

Это как раз самая техническая часть проекта, которую в большинстве случаев клиент не может описать самостоятельно. Её нужно писать вместе с профильными специалистами.

Организационная часть проекта

  • Роли в проекте со стороны Заказчика и Исполнителя, и распределение ответственности – кто, поименно, участвует в проекте с обеих сторон, кто за что отвечает.
  • Идеология проекта – общее описание основных принципов, которых и Заказчик, и Исполнитель договорились придерживаться на проекте
  • Порядок приемки работ – как будут приниматься работы, как трактуются неточные формулировки, порядок исправления ошибок и недочетов
  • Порядок запуска проекта – как конкретно, в какое время и при соблюдении каких условий происходит запуск. Какой процесс запуска проекта и как это синхронизировано с рекламой и другими сферами деятельности проекта.

Это один из самых важных разделов, который позволяет не поссориться на проекте и успешно довести проект до запуска.

Специфика, которая зависит от проектов

Помимо общих разделов проекты в зависимости от целей и масштаба имеют свою специфику.

Разделы технического задания на разработку портала или сервиса

Разделы по серверам обязательно дополняются конкретными параметрами серверов (CPU, RAM, HDD), интерфейсы доступа и сертификаты (SSH, FTP/SFTP, SSL), операционная система на сервере, окружение, системы, расширения, которые должны быть установлены (apache/nginx/iis/...).

Техническая часть дополняется требованиями к документации разработки: как документируется код, как собирается вся документация о проекте. 

Тестирование дополняется написанием тест-кейсов, использованием автоматических тестов, unit-тестов, непрерывной интеграцией и так далее.

Специфика техзадания на разработку большого сайта и интернет-магазина

Для больших проектов нужно сразу в тех. задании делать SEO-проектирование и описывать требования к первичной внутренней оптимизации и базовым требованиям к коду для поисковых систем.

  • правила генерации URL
  • правила автогенерации TDH: title, description, h1
  • генерация карты сайта (sitemap.xml)
  • микро-разметка (семантическая разметка)

Также обязательно описываются системы доставки и оплаты, особенно если используются API для расчета стоимости доставки, "безопасная сделка" и другие современные механизмы.

Если есть требования к платформе разработке или конкретной системе управления сайтом или магазином они также должны быть указаны.

ТЗ на разработку сайта или магазина на новой платформе, когда уже есть существующий

Если интернет-проект перезапускается, нужно обратить особое внимание на перенос контента и сохранение существующих позиций в поисковиках. Здесь должно быть описано как это будет достигаться и что конкретно нужно сохранить со старого сайта:

  • сохранение url или 301-редиректы
  • сохранение TDH или автогенерация новых
  • редиректы с бэклинков
  • перенос контента, особенно если контента много и нужен перенос с помощью парсера или используя старый дамп базы
  • Правила наполнения и внесения нового контента на сайт, какие alt,title,description указывать для картинок и так далее

Важно также указать будет ли сайт оставаться на существующем VPS или хостинге, или переезжать на новый хостинг или сервер.

Готовый чеклист технического задания

Готовый чеклист технического задания доступен в форматах Google Spreadsheet(онлайн-таблица, заполните форму ниже) и MS Excel (вышлем по запросу).

Бонус №1: признаки неправильного техзадания. В версии чеклиста, доступной для скачивания мы также внесли признаки плохого техзадания.

Бонус №2: послезаполнения чеклиста, мы считаем общий балл качества вашего техзадания от -5 (всё очень плохо) до 5 (прекрасно).

Если этот материал был вам полезным, будем благодарны за комментарии и репост в соцсетях. Если у вас есть что дополнить - напишите нам!

UPD: расшарив этот материал в соцсетях мы начали получать отклики "это вы хотите полететь космос, а не создать ТЗ на сайт" и второй по популярности "заказчик это сделать не может сам".

Да, этот чеклист целесообразен в первую очередь для сложных проектов, разработка которых стоит десятки тысяч долларов. И цена ошибки здесь велика. И мы не ждем, что это будет делать собственник бизнеса. Зачастую на таких проектах у заказчика уже есть команда из маркетолога, SEO-специалиста, внутреннего менеджера проектов, и для нас собрать по чеклисту основные требования не сложно. Международные компании когда приглашают в тендер на разработку веб-проектов, присылают RFP (Request For Proposal), который содержит то, что здесь указано и даже больше, например матрицу коэффициентов при выборе подрядчика. Очевидно, что они не готовы делать выбор подрядчика по цене, сформированной за несколько часов на основании описания на 2-3 страницах, и осознают, что без качественного материала для оценки, цена которую назовут в начале будет сильно отличаться от итоговой стоимости проекта. 

Когда компания или предприниматель обращается к нам с идеей, мы разрабатываем техзадание как часть этапа проектирования, который начинается с создания прототипа.

11.10.2016
Рейтинг: 0 / 5 (0)