Основы составления технического задания для интернет-проектов. Системы управления проектами. Тема №1

1.

Тема №1. Основы составления
технического задания для
интернет-проектов. Системы
управления проектами.

2.

Техническое задание (ТЗ, техзадание) — документ
или несколько документов, определяющих цель,
структуру, свойства и методы какого-либо проекта, и
исключающие двусмысленное толкование
различными исполнителями.
Основное назначение — документальное
закрепление всех требований и условий между
заказчиком и исполнителем.
2

3.

Польза техзадания для клиента:
• Понять, на что будут потрачены финансы, и что он получит взамен. Этот пункт
помогает заказчику познакомиться со структурой и понять работу ресурса. Если есть
моменты, которые не устраивают, то до начала разработки их можно изменить;
• Убедиться в компетентности исполнителя. Четкое ТЗ - это доверие к тому, кто будет
заниматься разработкой, а хаос может быть сигналом о том, что похожее может
быть на сайте;
• Застраховаться от недобросовестности разработчика. Имея техническое задание,
готовый сайт можно легко проверить по нему. Если имеются несоответствия, то
разработчик должен их устранить;
• Упростить передачу разработки ресурса другим исполнителям. Это актуально в тех
случаях, когда разработчик и клиент повздорили между собой. Имея на руках
техническую документацию, можно ресурс передать другим профессионалам. Они
втянутся в работу быстрее, чем без ТЗ;
• Узнать цену на создание сложного сайта. Стоимость разработки и точные сроки
сдачи сложного сайта сразу назвать нельзя. Необходимо понять, какие функции
будут на ресурсе и как он будет работать.
3

4.

Польза техзадания для исполнителя:
• Правильно оценить, что нужно клиенту. Заказчику задается множество вопросов,
предлагаются решения, показываются разные примеры. Далее вся информация
оказывается в едином документе. Если заказчик согласен с внесенными данными, то
будущий разработчик сайта все понял правильно;
• Застраховаться от неожиданных пожеланий заказчика. Бывают ситуации, когда клиент хочет
все изменить. Его не смущает, что сайт уже наполовину сделан. ТЗ - это страховка от таких
хотелок;
• Доказать свою компетентность. Техническое задание, если оно хорошо сделано
исполнителем, вызовет у клиентов уважение и даст понять, что перед ними профессионалы.
Многие клиенты соглашаются работать с разработчиками после того, как увидят эту
документацию;
• Ускорить и облегчить разработку ресурса. Как правило в техзадании можно найти
требования к структуре сайта, функции и элементы, расположенные на каждой странице.
Имея это перед глазами, остается сделать малое: оформить визуал и написать код;
• Создать возможность для заработка. Составить правильно ТЗ - дело непростое и очень
хлопотное, особенно для человека, который в этом плохо разбирается. Поэтому
разработчики предлагают услугу по составлению технической документации.
4

5.

Основные блоки технического задания.
Хорошие технические задания состоят из 3 основных блоков:
технического, маркетингового и дизайнерского.
Техническая часть – технологическая основа того, от чего
будет разработчик отталкиваться: выбор CMS, описание
необходимых функций сайта.
Маркетинговая часть отвечает за коммерческий успех
будущего сайта. Описание ряда требований с учетом ниши, в
которой компания работает, преимуществ, ситуации на
рынке, уровня конкуренции, отметив особенности целевой
аудитории и т.д.
Цель дизайнерской части технического задания – сделать
ресурс максимально удобным, полезным, интересным для
пользователя.
5

6.

Основные вопросы технического задания также делятся на 3 группы: общего характера,
дизайн и прототип, функционал проекта.
Вопросы общего характера:
• Задачи и цели проекта. Тут необходимо вкратце расписать требования и пожелания
того, что хочется получить от сайта. Лучше это сделать в цифрах. Например, достичь
определенного трафика в месяц, добиться увеличения продаж на 30% и т.д.;
• Концепция будущего сайта. Здесь необходимо озвучить проблему, которую должен
решать продукт, предложить порядок ее устранения и рассказать о целевой аудитории;
• Расшифровка терминов, которые используются в документе. Часто заказчик под
определенным термином понимает одно, а исполнитель другое. Чтобы не было
путаницы при выполнении работ, рекомендуется составить словарь, используемой
терминологии;
• Перечень документации, на основании которой будет создан сайт. Тут можно указать
ссылки на приглянувшийся дизайн, внешние документы и т.д.;
• Карта страниц будущего проекта или разделов. Требований тут немного: нужно
нарисовать структуру в формате дерево. Благодаря этому рисунку будет понятен объем
работ, с которым придется столкнуться разработчику.
6

7.

Дизайн и прототип:
• При разработке сайта часто исполнитель предлагает заказчику сделать прототип схемы страниц, представленные в единой структуре, которые имитируют работу
серверной части и интерактивных элементов. Если он будет сделан, то проект можно
оценить быстрее;
• Иногда у заказчика уже есть дизайн сайта, тогда рекомендуется на исходные файлы
макетов прикрепить ссылку. Если дизайна нет, то необходимо написать перечень
требований к дизайну. Например, какие должны быть цвета на сайте: общие по всему
ресурсу и отдельно в логотипе, какие элементы хочется использовать и т.д.;
• Динамика страниц. Здесь необходимо указать требования к реагированию интерфейса,
когда происходит нажатие на определенные элементы управления. А также расписать
нужны ли всплывающие окна, дополнительные эффекты, подсказки;
• Требования к адаптивной версии ресурса. Здесь указывается, на каких платформах и
браузерах будет использоваться сайт.
7

8.

Функционал проекта:
• Информационная архитектура. В этом разделе необходимо описать структуру
сущностей сайта: объекты системы, сущности базы данных, основные функции ядра и
т.д.;
• Функциональная спецификация. Здесь указываются какими алгоритмами вызываются
определенные действия системы;
• Описательная часть для бек-офиса. Необходимо указать функционал для контентменеджера, администратора и т.д. Главный вопрос здесь: описать порядок наполнения
контентом и администрирование;
• Интеграция с внутренними и внешними системами. В этой части необходимо написать
информацию о данных: куда и откуда они передаются, в каком виде;
• Информация о тестировании. Необходимо указать требования о том, какие системы
будут тестировать продукт: прописать устройства, системы, браузеры;
• Описание требований к безопасности ресурса. Заказчиком должны быть озвучены
требования к безопасности, причем как общие, так и частные;
• Информация о серверах и нагрузке. Указываются требования на каких серверах
должен быть размещен проект и какую нагрузку выдерживает.
8