Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Главное Свежее   Проекты
Рекомендуем
Продвинуть свой проект
3 233 10 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Чеклист: что должно включать в себя техническое задание на сервис, сайт, интернет-магазин

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

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

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

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

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

b_58247ec9b6d05.jpg

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

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

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

  • Концепция продукта – потребность или проблема, которую продукт решает, общая логика решения, целевая аудитория;
  • Цели и задачи проекта – коротко описать, какие есть конкретные цели проекта в цифрах (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 можно получить на странице нашего блога (внизу) http://evergreens.com.ua/ru/articles/checklist-tz....

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

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

+12
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Подбираем рекоммендации...
Комментарии
Первые Новые Популярные
Toque Advertising
Рекламная обсерватория toqueadvertising@inbox.ru https://vk.com/toquecopywrite
Максим Лунин
Такое чувство, что мы говорим не о сайте, а о коллайдере)

Если кроме шуток. Непонятен вот этот пункт:

"Прототип или мокапы – для любого современного интернет-проекта разработка прототипа или мокапов является необходимым и очень ускоряет процесс и точность оценки;"

То есть заказчик до обращения к вам должен уже и прототипы нарисовать сам и мокапы и SEO-оптимизацию продумать? Еще и дизайн предоставить? Вам не кажется, что это какая-то узкость получается?

Если человек создает проект с ноля, у него ничего это не будет. И что вы потеряете клиента?) Просто из-за несоответствия вашим ожиданиям по ТЗ?)

То есть, если у меня есть ресурсы и я создаю интернет-магазин с ноля. Зачем мне тогда к вам обращаться, если столько всего нужно? Я уйду к другим, кто создаст все с ноля и сам. Я об этом. О подходе. Потому что ничего не ясно из чек-листа. То есть, наоборот, ясно, что программисты нынче очень привередливы и все им дай) А как же остальные 90% людей, которые ничего не знают о базах данных? ) Это просто отклик со стороны.
Ответить
Evergreen
Создаем привлекательные и эффективные web-решения
Sergey Kravtsov
Приветствую, а кто сказал что это должен делать заказчик?
Есть две рабочих модели, на мой взгляд:
1) я точно знаю что хочу, вот я детально всё расписал, нужны просто руки, чтобы выполнить
2) я знаю какой результат мне нужен и не хочу забивать себе голову тем как это сделать

Если мы говорим о строительстве многоэтажного (хотя бы 5 этажного) дома, без чертежа или "по описанию на 3 страницах" его не возьмутся строить. Но никто не будет говорить что заказчик должен сам рисовать чертеж.

Так и тут - прототип это чертеж. Не стоит делать визуально сложные или интерактивные интерфейсы без прототипа.

А делать ли это самостоятельно заказчику, или заказывать прототип у кого-то отдельно, или работать с компанией, которая даст комплекс - решение заказчика
Ответить
Toque Advertising
Рекламная обсерватория toqueadvertising@inbox.ru https://vk.com/toquecopywrite
Максим Лунин
Ну, тут речь именно о вашей работе. Вы лучше расскажите, как решаете эти вопросы именно вы. В теории то все понятно)

То есть вы готовы взять проект с ноля и сами нарисовать и просчитать все, что нужно? Или вы работаете только с готовыми ТЗ?
Ответить
Evergreen
Создаем привлекательные и эффективные web-решения
Sergey Kravtsov
Максим, да, конечно готовы. К нам, как наверное и к любой Веб/ИТ компании часто приходят просто с голой идеей. Мы её сначала уточняем на уровне идеи, пишем совместно user stories, анализируем конкурентов и аналоги, проверяем на общую реализуемость. Если это реализуемо, рентабельно для клиента и мы видим что клиент готов к проекту и сам проект имеет достаточный потенциал для запуска, предлагаем разработку прототипа. На прототипировании начинаем параллельно описывать функциональную спецификацию, и другие пункты, нужные для толковой разработки.
Ответить
Toque Advertising
Рекламная обсерватория toqueadvertising@inbox.ru https://vk.com/toquecopywrite
Максим Лунин
Спасибо за ответ! Напишите об этом в следующем материале. Как вы создаете проекты с ноля только по идее заказчика. Мне кажется, это будет интересно тем кто, возможно, захочет к вам обратиться. Успехов!
Ответить
Evergreen
Создаем привлекательные и эффективные web-решения
Sergey Kravtsov
Спасибо, Максим, обязательно напишем!
Ответить
Михаил Кузьмин
Почти совсем согласен, кроме того, что "Роли в проекте со стороны Заказчика и Исполнителя" и "Идеология проекта" более гладко ложатся на Устав проекта.
Ответить
Симулятор бизнес-процессов
Сервис имитационного моделирования и оптимизации бизнес-процессов
Prolis Labkk
По Уставу сайт не сделать, это высокоуровневый внутренний документ, который Заказчик и не увидит никогда.
Ответить
Михаил Кузьмин
Конечно, устав - более высокоуровневый документ, тем не менее в относительно крупных проектах разработки, в том числе, и сайтов иногда пишется устав проекта, который согласовывается с заказчиком.
Там обычно описываются общие вопросы управления данным конкретным проектом, способы коммуникации проектной команды, вопросы разделения ответственности и т.п.. Вот как раз туда проектные роли и идеология хорошо ложатся.
Ответить
Максим Мирошник
Мало материала - нужно тему более широко раскрыть
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать