Важность создания ТЗ на разработку web-приложения правила составления


Содержание материала:

ОБРАЗЕЦ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ WEB-САЙТА

Курс

Практическое занятие 1

«Составление технического задания на разработку web-сайта»

Цель работы

1.1 Научиться правильно составлять техническое задание на разработку web-сайта

Пояснение к работе

2.1 Краткие теоретические сведения

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

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

Техническое задание разделяется на три части:

· Назначение и цели создания сайта

ОБРАЗЕЦ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ WEB-САЙТА


Техническое задание на разработку Веб-сайта

1. Имя сайта (название домена).
www._______.ru
Если домен www._____.ru будет занят, возможна замена имени.

2. Название сайта.
Сайт ООО «______________». Далее — Фирма.

3. Назначение сайта (цель создания сайта).
Представление Фирмы в Интернет: информация о Фирме, история Фирмы, партнёры Фирмы, Заказчики Фирмы, цены на оказываемые услуги, справочная техническая и юридическая информация, советы клиентам, сопроводительные графические рисунки, юридический адрес, почтовый адрес, схема проезда, контактная информация, банковские реквизиты, сведения об имеющихся вакансиях. Сайт должен способствовать привлечению клиентов и нахождению деловых партнеров.

4. Язык сайта.
Русский

5. Основные ключевые слова, по которым сайт должны находить по запросам в поисковых системах и Интернет — каталогах.
Согласно материалам Заказчика.
Примечание:
Перечень ключевых слов для Веб-дизайнера сайта носит справочный характер и не входит в число обязательных параметров, подлежащих проверке при приемке сайта. Занимаемые сайтом позиции в рейтингах, каталогах и поисковых системах не оговариваются.

6. Объём и состав текстовой и графической информации в электронном виде.
Согласно материалам Заказчика.

7. Предполагаемая возрастная аудитория сайта.
От 30 лет и старше.
7.1. Предполагаемое возрастное ядро аудитории от 35 до 50 лет.
7.2. Данная информация носит рекомендательный характер. Цифровые показатели контролю и проверке при приёмке сайта не подлежат.

8. Количество страниц сайта.
Сайт должен содержать следующие html страницы: 1 — Главная (домашняя) страница; 2 — Прайс-лист; 3 — Фото (каталог) товаров; 4,5,6,7,8,9,10 — Справочная информация; 11 — О Фирме; 12 — Офис; 13 — Партнёры; 14 — Вакансии; 15 — Потребности; 16 — Сервисы.
Количество html страниц сайта определяется Веб-дизайнером самостоятельно, исходя из объёма предоставленных материалов Заказчика.

9. Кнопки управления (навигация сайта).
Определяются Веб-дизайнером самостоятельно.
С каждой страницы сайта должен быть обеспечен переход (установлена гиперссылка) на главную страницу сайта. Сайт должен содержать страницу «Содержание» (карта сайта).

10. Блок схема сайта.
Определяется Веб-дизайнером самостоятельно.
Головная (начальная) страница сайта должна содержать гиперссылки, обеспечивающие переход с нее на не менее чем 95% страниц сайта, но не более чем 160 гиперссылок.

11. Объём сайта, Мб.
Не оговаривается.

12. Оформление рисунков.
Все рисунки объемом более 1 Кб должны быть выполнены с замещающим текстом. Рисунки размером более 15 Кб должны быть выполнены с предпросмотром. Формат всех рисунков gif или jpg (jpeg).

13. Пропускная способность линии связи.
Среднее время загрузки страниц не должно превышать 28 секунд при скорости соединения 28.8 Кбит/сек. Допускается увеличение времени загрузки отдельных страниц до 36 секунд, но не более чем на 30% числа страниц сайта. Головная (начальная) страница должна иметь время загрузки не более 40 секунд.
Примечание:
Во всех случаях не учитывается время загрузки подгружаемых элементов (счетчики, баннеры, информеры и т.д.).

14. Основной диапазон разрешения мониторов, на которых будет просматриваться сайт.
От 600х800 до 1240х1024 пикселей.
Основное разрешение, на которое оптимизируется сайт: 1024х768 пикселей.
15. Минимальное разрешение монитора, на котором будет просматриваться сайт.
600 х 800 пикселей. При указанном разрешении возможность просмотра страниц сайта без горизонтальной прокрутки браузера не предусматривается.

16. Основной браузер, которым будет просматриваться сайт, и его минимальная версия.
IE 5.5 и выше.

17. Цветовая палитра.
Основной режим мониторов, на которых будет просматриваться сайт: 15 разрядов цветов и выше (число цветов 65536 и выше).
При разработке сайта должен быть обеспечена возможность его просмотра при использовании безопасной цветовой палитры (разрядность цветов 8). Изменения оттенков цветов, при просмотре сайта с использованием безопасной цветовой палитры, не оговариваются.

18. Общий фон сайта.
Общий фон сайта светлый (белый). Допускается использование светлого фонового рисунка.

19. Размер и вид шрифта сайта.
Размер шрифта сайта должен быть в пределах 10-12 для оформления текста. Размер шрифта для оформления заголовков, названия страниц и т.д. не оговаривается. Вид (название) шрифта не оговаривается.

20. Регистрация сайта в каталогах, рейтингах, топах и пр.
Оговаривается дополнительно.

21. Проведение рекламной кампании по раскрутке сайта.
Раскрутка сайта определяется отдельным техническим заданием.В настоящем техническом задании раскрутка сайта не оговаривается и не входит в состав выполняемых работ (услуг).

22. Срок разработки сайта.
Три недели со дня зачисления 70% предоплаты на расчётный счёт Веб-студии.

23. Порядок передачи сайта.
Веб-дизайнер передает сайт на CD ROM, а также логин, пароль и название (код передачи данных) по протоколу ftp.
Заказчик обязан проверить наличие грамматических и орфографических ошибок на сайте в течение трех рабочих дней. Обнаруженные ошибки Веб-дизайнер обязан устранить в течение трех рабочих дней.

24. Сопровождение сайта.
Сопровождение сайта определяется отдельным техническим заданием.В настоящем техническом задании сопровождение сайта не оговаривается и не входит в состав выполняемых работ (услуг).

25. Дополнительные условия.
Каждая страница сайта должна содержать логотип и название Фирмы.
Внизу на каждой странице сайта должна быть указана контактная информация.
Сайт должен содержать не менее двух счетчиков подсчета посетителей.

Материалы предоставляемые Заказчиком:

Текстовая (формат Word) и графическая информация (формат jpeg и gif), представленные на CD ROM.

Примечание:

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

Подписи Сторон:

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Сдача сессии и защита диплома — страшная бессонница, которая потом кажется страшным сном. 8760 — | 7142 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Техническое задание на разработку приложения

Написать хорошее ТЗ сложно, это не дело пяти минут. Но есть отличная новость! Эта ответственная задача ложится не только на ваши плечи, но и на плечи мобильного разработчика. Он тоже заинтересован в успехе вашего сотрудничества.

1 шаг. Идея разработки мобильного приложения

Опишите ваше будущее приложение будто рассказываете рецепт сложного блюда. Какие ингредиенты вы хотите туда положить? Какие функции они выполняют? Запишите их, продумайте, какая между ними логика взаимодействия. Не пытайтесь втиснуть в одно приложение все сразу — ведь в блюдах мы не мешаем все, что находим в холодильнике. Мы выбираем что-то главное и добавляем к нему несколько менее важных ингредиентов, для того чтоб вкус получился уникальным.

Посмотрите, нет ли аналогов приложения? Если нет, то вам крупно повезло. Обычно же аналоги находятся и в крупных размерах — ваша задача придумать, чем ваше приложение будет отличаться, причем в лучшую сторону. И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.

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

2 шаг. Вопросы, с которых начинается ТЗ

Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:

  1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?
  2. Какие задачи решает приложение? Если оно для клиентов, то что клиенты смогут делать с помощью вашего приложения – заказывать товары, услуги, бронировать, записываться онлайн, узнавать об акциях и т.д.? Если оно для сотрудников, то какие функции в приложении помогут им работать эффективнее?
  3. На каком устройстве вы хотите видеть ваше приложение? Смартфон, планшет или десктоп?
  4. В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.
  5. Когда вы хотите получить готовое приложение? То есть сроки.
  6. Какой у вас бюджет? Уникальное приложение стоит не дешево, однако стоит учитывать те бонусы, которые вы за счет него получите — прибыль от увеличения заказов или оптимизации бизнеса.

Ответив на эти вопросы, можете смело заполнять бриф. А это первый шаг к тому, чтобы составить правильное ТЗ, а потом и к разработке успешного мобильного приложения.

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

3 шаг. Настало время ТЗ!

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

За некоторыми исключениями, ТЗ состоит из вот таких разделов:

  1. Терминология. Очень важно договориться о терминах заранее, ведь одно и то же слово вы и разработчик можете понимать по-разному.
  2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
  3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей. К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку?
  4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно? Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
  5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо. Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?6.Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.

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

Начните прямо сейчас!

На самом деле, написать хорошее ТЗ — просто, если подойти к этому делу с умом. И не возлагать на себя одного это нелегкое дело. Ведь ТЗ нужно для результативного взаимодействия. А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности разработчик берет на себя!

Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта. Поэтому начинайте прямо сейчас — напишите бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!

Как написать ТЗ на разработку сайта?

Как написать ТЗ на разработку сайта?

Некоторые заказчики полагают, что техническое задание (ТЗ) – это формальность и исполнители делают его бесплатно.

В некоторых случаях это действительно так. Например, если продукт типовой и, поменяв в рыбе документа несколько параметров, получаем новое ТЗ.

В случае, если сайт разрабатывается на заказ, то написание ТЗ – это объемная кропотливая работа, которая требует не только фиксации требований заказчика, но и проработки предметной области клиента, предпроектирования отдельных модулей системы, создания тестовой функциональности для проработки узких моментов.

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

Из чего состоит техническое задание?

Что включает в себя полноценное техническое задание?

  1. Структуру будущего продукта. Для разработки CRM – это состав кабинетов пользователей и их функционала (страниц). Структура – это исходный элемент для всех остальных работ по ТЗ.
  2. Макеты и текстовое описание всего функционала по структуре. Макеты упрощают визуализацию ТЗ и будущего сайта. Это снижает риски недопонимания между заказчиком и исполнителем. Не секрет, что исполнители больше тяготеют к техническому языку, а заказчики – к бизнес-целям. Макеты позволяют общаться на одном языке, оба видят один и тот же интерфейс и разговаривают не на абстрактном уровне, а на уровне элементов, которые одинаково понятны всем – кнопки, таблицы, меню и т.д.
  3. Требования по интеграции. Если система связана с внешними ресурсами, то вы должны прописать, как именно система будет взаимодействовать с ними и в каком объеме. Хороший пример – это интеграция с 1С. Не пишите в ТЗ «Сделать интеграцию с 1С»! 1С содержит сотни таблиц в базе данных. Очень трудоемко сделать интеграцию всех объектов 1С с приложением и в большинстве случаев не нужно. Лучше указать, какие именно объекты надо синхронизировать с приложением (клиенты, заказы, единицы измерения, товары и т.д.). Указывайте также предпочтительный способ реализации (например, через веб-сервисы), это позволит избежать недоразумений на стадии разработки. Согласен, вы не можете знать всех технических нюансов. В этом плане вам должен помогать исполнитель, который пишет ТЗ. Задавайте ему максимум вопросов по реализации. Его задача – предоставить вам информацию, и на ее основании вы уже решаете, какой вариант выбрать.
  4. Особые требования. Сюда можно отнести требования по производительности (хотя в некоторых случаях это сложно прогнозировать, т.к. приложение работает не изолированно, а в некоторой среде), требования к браузерам, требования к дизайну и др.

Насчет браузеров – указывайте список браузеров и версии для которых должно работать приложение. Некоторые авторы с легкой руки пишут такие версии, которые уже не поддерживают такие порталы как ВКонтакте (например IE8).

Если говорить о дизайне CRM, то главная его задача – не мешать пользователю. На мой взгляд, здесь не нужно придумывать велосипед – можно взять готовый шаблон и использовать его.

  1. Проработка узких моментов. Если в вашем проекте есть сложные механизмы, то лучше проработать их на этапе ТЗ. Это снижает риски проекта. В случае если не найдется приемлемого решения, то лучше изменить что-то на этапе ТЗ, а не на этапе разработки системы. Почему? Это дешевле. Чем раньше обнаружена ошибка, тем дешевле ее исправить. Самые дорогие ошибки – на этапе эксплуатации. Пример: автоматическая генерация пароля. Вы сделали в начале так, что пароль генерируется слишком простой. В начале проекта поменять это несложно. Теперь представьте, что у вас система запущена, и в ней работают 100 пользователей. Будет довольно непросто сменить всем пароли (поменять данные в базе, оповестить, часть пользователей не поймет что произошло, т.е. дополнительные расходы на техподдержку).

Как написать ТЗ на разработку сайта: организация процесса

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

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

На мой взгляд, наиболее предпочтительным способом является следующая схема взаимодействия:

  1. Исполнитель и заказчик совместно работают над ТЗ (например, через сессии по скайпу). Причем исполнитель руководит этим процессом, а заказчик выступает в роли источника знаний о системе. Иными словами, исполнитель спрашивает, а заказчик отвечает.
  2. Только исполнитель фиксирует изменения в ТЗ.
  3. Заказчик периодически анализирует ТЗ. Все ли ему понятно? Ничего не упущено? Надо чем-то дополнить?

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

Особенности написания ТЗ

При обсуждении темы, как написать ТЗ на разработку сайта, также следует упомянуть о случаях, когда очень трудоемко написать ТЗ сразу. Система настолько сложна и быстро меняется, что нет смысла писать сразу большое ТЗ. В этом случае необходимо определить область действия ТЗ при создании торговой площадки. Делайте ТЗ только на какую-то конкретную часть системы, например, на блок «База клиентов» или процесс «Обработка заказа от клиента».

При этом желательно иметь план внедрения модулей системы. Например, в этом году мы внедрим одни модули, а в следующем – такие-то модули.

Из опыта вспоминаются ситуации, когда некоторые заказчики хотят выполнить очень большой проект за один этап, например аналог Avito.ru. Желание заказчика понятно – он хочет избежать риска получить часть продукта, а ему нужен целостный продукт. Сам не понимая того, он движет проект к катастрофе, т.к. подобные проекты невозможно сделать одним куском за один раз. Здесь действует цикл «задумка – реализация – получение обратной связи – анализ». Вспомните, Windows не сразу стал тем, что он есть сейчас.

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

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

Если вам понравилась статья, помогите, пожалуйста с распространением этого материала в Сети.

Техническое задание на разработку мобильного приложения

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

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

Что такое ТЗ на разработку мобильного приложения

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

  • какие задачи и цели выполняет приложение (например, пользователь одним нажатием на иконку узнает новости, отслеживает акции, заказывает продукты и услуги);
  • особенности дизайна, соответствующие стилю и фирменным цветам компании;
  • где хранятся и как структурированы базы данных;
  • на каких мобильных платформах будет работать приложение: IOS / Android/ Windows Phone;
  • тип верстки (альбомная, книжная, адаптивная);
  • особенности серверной части
  • ососбенности интеграции

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

Как написать ТЗ самостоятельно?

Самостоятельно создать техническое задание — задача сложная и требующая компетенций в различных областях знания (IT, дизайне и т.п.). Как правило, заказчики приходят с идеей, или с описанием требуемого функционала и общих представлений о том, как это должно выглядеть и работать. Некоторые компании собирают собственную команду для создания технического задания или нанимают внешнего подрядчика для выполнения этой работы.

Мы выделяем следующие стадии готовности ТЗ:

2. Описание функционала

3. Референсы (приложения, аналог которого Вы хотите получить)

На любой стадии прежде чем обратиться за расчетом стоимости, мы рекомендуем найти время и письменно ответить на следующие вопросы (хотя бы для себя):

1) Цели создания приложения

— для кого вы хотите создать приложение

— какие реальные задачи пользователей будет решать приложение

— зачем пользователи будут скачивать приложение и занимать память своего телефона

— какую цель преследуете Вы сами (ваш бизнес), создавая это приложение

— какие функции должны быть в первой версии приложения обязательно

— какие функции могут появиться во вторую/третью/… очередь

3) Как организован бизнес-процесс сейчас

Как правило, приложения — это внешняя часть некоторого бизнес-процесса, данные о котором уже содержатся в некой системе. Это может быть CRM, 1С, IIKO, R-Keeper и другие. В каждой отрасли своя специфика, но в каждой отрасли есть решения, позволяющие хранить и обрабатывать данные о клиентах/заказах/продукции и т.п. Приложение не работает на пустом месте — это лишь оболочка, которая транслирует пользователю информацию с сервера и загружает ее обратно. При отсутствии такой системы — необходимо либо ее внедрение либо проектирование и создание (а это уже совсем другой процесс). Нужно быть к этому готовым.

Можно заказать приложение и без ТЗ

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

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

Техническое задание на разработку приложения

ТЗ на разработку — а оно нам надо?


Техническое задание — один из главных этапов создания мобильного приложения. При этом, самый первый. А значит, пропустить его или отложить нельзя. Ведь от того, насколько хорошо составлено ТЗ, будет зависеть, какое приложение вы получите. Оно может получиться отличным, но не тем, какое нужно именно вам.
Написать хорошее ТЗ сложно, это не дело пяти минут. Но есть отличная новость! Эта ответственная задача ложится не только на ваши плечи, но и на плечи мобильного разработчика. Он тоже заинтересован в успехе вашего сотрудничества.

1 шаг. Идея разработки мобильного приложения

Опишите ваше будущее приложение будто рассказываете рецепт сложного блюда. Какие ингредиенты вы хотите туда положить? Какие функции они выполняют? Запишите их, продумайте, какая между ними логика взаимодействия. Не пытайтесь втиснуть в одно приложение все сразу — ведь в блюдах мы не мешаем все, что находим в холодильнике. Мы выбираем что-то главное и добавляем к нему несколько менее важных ингредиентов, для того чтоб вкус получился уникальным.
Посмотрите, нет ли аналогов приложения? Если нет, то вам крупно повезло. Обычно же аналоги находятся и в крупных размерах — ваша задача придумать, чем ваше приложение будет отличаться, причем в лучшую сторону. И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.
Если же вы делаете приложение под свои бизнес-задачи, то вам будет полезно посмотреть, какие приложения есть у ваших конкурентов. Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.

2 шаг. Вопросы, с которых начинается ТЗ

Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:
1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?
2. Какие задачи решает приложение? Если оно для клиентов, то что клиенты смогут делать с помощью вашего приложения – заказывать товары, услуги, бронировать, записываться онлайн, узнавать об акциях и т.д.? Если оно для сотрудников, то какие функции в приложении помогут им работать эффективнее?
3. На каком устройстве вы хотите видеть ваше приложение? Смартфон, планшет или десктоп?
4. В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.
5. Когда вы хотите получить готовое приложение? То есть сроки.
6. Какой у вас бюджет? Уникальное приложение стоит не дешево, однако стоит учитывать те бонусы, которые вы за счет него получите — прибыль от увеличения заказов или оптимизации бизнеса.
Ответив на эти вопросы, можете смело заполнять бриф. А это первый шаг к тому, чтобы составить правильное ТЗ, а потом и к разработке успешного мобильного приложения.
Если вы не технический писатель или программист — подготовить грамотное ТЗ самостоятельно у вас, к сожалению, вряд ли получится. Но вам обязательно поможем мы, разработчики, ведь мы успешно делали это десятки раз.

3 шаг. Настало время ТЗ!

ТЗ – индивидуальный документ, и каждый раз составляется заново под каждый проект. Это также зависит и от разработчика, к которому вы обратились. Ведь у всех свой метод работы, а это значит, что в ваших интересах составить техзадание максимально подробно.
За некоторыми исключениями, ТЗ состоит из вот таких разделов:
1. Терминология. Очень важно договориться о терминах заранее, ведь одно и то же слово вы и разработчик можете понимать по-разному.
2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей. К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку.
4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно? Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо. Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?
6. Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.

Топ-пост этого месяца:  Яндекс.Коллекции что это такое, как добавить или убрать коллекции

Начните прямо сейчас!

На самом деле, написать хорошее ТЗ — просто, если подойти к этому делу с умом. И не возлагать на себя одного это нелегкое дело. Ведь ТЗ нужно для результативного взаимодействия. А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности мы берем на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта. Поэтому начинайте прямо сейчас — заполните бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!

Техническое задание на сайт: образец от digital-агентства

Решили заказать сайт (он же лендинг)? Как показывает практика, это не так просто. Сотни заказчиков, увидев свой готовый сайт, обнаруживают, что он им не подходит: дизайн не тот, расположение хромает, тексты мимо, прикрутили кучу ненужных функций.

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

Чтобы таких последствий избежать, Вам необходимо техническое задание на разработку сайта.

ОНО МНЕ НАДО?!

Неважно, кто будет исполнителем сайта – Вы сами, Ваш родственник, фрилансеры за скромную оплату, специализированная компания за огромную сумму денег…

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

Техническое задание (коротко “ТЗ”) – это документ, который максимально подробно и однозначно отражает требования к Вашему будущему сайту.

Сайт создают именно на основе ТЗ. Чем более подробным и однозначным оно будет, тем больше Ваш новый сайт будет соответствовать Вашим ожиданиям.

ТЗ на создание сайта – как закон, не должно допускать трактовок и разночтений.

Всё, что не прописано в ТЗ разработчик делает на своё усмотрение. И, как показывает практика, его усмотрение сплошь и рядом не будет совпадать с Вашим.

Такие разные

Кто должен составлять техническое задание на разработку сайта? На этот вопрос есть только два варианта ответа: заказчик или исполнитель.

И это логично, кроме одной тонкости – смысл в составлении ТЗ для Вас и для разработчика разный, а от этого разные подходы и требования к нему.

  1. Понять, какой именно сайт Вам нужен;
  2. Зафиксировать бюджет (иначе Вам потом выставят счёт, мама не горюй);
  3. Контролировать разработчика (сроки, объём работ, функционал, переделки и т.д.).
  1. Понять и с первой попытки удовлетворить заявленные Вами пожелания;
  2. Избежать бесплатных доработок и корректировок.

Таким образом, Вы оба – и заказчик, и исполнитель сайта, заинтересованы прийти к максимальному пониманию.

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

Бриф на разработку сайта

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

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

ТЗ на разработку сайта можно составить только на основе Ваших пожеланий и никак иначе.

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

Бриф – это анкета с вопросами о содержании, дизайне, технических возможностях Вашего будущего сайта.

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

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

Если отдельные пункты вызывают затруднения, то не стесняйтесь задавать разработчику вопросы по типу “Что это значит?”, “Как это повлияет на работу моего сайта?”, так как не все разработчики под одним понимают то же самое, что и Вы.

Либо в графе “Дополнительная информация” обязательно укажите все Ваши пожелания, не вошедшие в ответы на вопросы.

Если эта графа отсутствует, просто допишите их в конце брифа. Главное не оставлять недосказанности.

Рыба технического задания

Ещё не определились, кому доверить создание Вашего сайта? Можно написать техническое задание самому, разослать его нескольким потенциальным исполнителям и сравнить их ценовые предложения.

Имейте ввиду, что у Вас получится только основа, набросок технического задания.

Оно обязательно должно вызвать у потенциального разработчика массу вопросов, отвечая на которые, Вы будете вносить в ТЗ подробности и нюансы.

В последствии техническое задание будет неоднократно редактироваться обеими сторонами. Это нормальный рабочий процесс.

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

Пункт технического задания Что писать? Пример заполнения
БИЗНЕС-ТРЕБОВАНИЯ
Информация о компании Название, товары, услуги, род деятельности, дата создания, знаки отличия и достижения,
основные конкуренты
Компания “Брандмейстер”. Поставка пожарного оборудования. Основана в 2020 году. Лауреат премии “Партнёр года”. Конкуренты “ПожСервис”, “ПожАвтоматика”
Целевая аудитория Максимально подробно опишите людей, которых Вы хотите видеть в роли посетителей Вашего сайта –
социально-демографические признаки, привычки, увлечения,
географию проживания – всё, что знаете. И не забудьте продумать, зачем они будут приходить на Ваш сайт
(найти полезную информацию, пообщаться, узнать новости и т.д.). Какую их проблему
он сможет решить.
Если целевая аудитория большая, её нужно сегментировать и рассказывать о каждом сегменте.
Лица, занимающие должность ответственного по пожарной безопасности на крупных предприятиях.
Мужчины от 35 до 55 лет.
С высшим техническим (преимущественно пожарным) образованием.
Проживающие и работающие на юге России.
Со средним доходом 35 000 — 50 000 тысяч рублей в месяц.
Имеют собственное жильё и личный автомобиль.
Семейные, есть дети.
Работают по графику Пн-Пт 9:00-18:00.
Проблема целевой аудитории: плохое знание нормативных документов по необходимому оснащению предприятий пожарным оборудованием.
Решение: благодаря статьям из блога пользователи, не углубляясь в чтение законов и нормативов, поймут, какое оборудование и в каких количествах должно быть на их предприятии.
Цели сайта Какого целевого действия Вы хотите добиться от посетителей сайта – сделать онлайн-заказ, подписаться на рассылку, позвонить к Вам в офис или что-то другое. Если целей несколько – пишите их все.
Это очень важный, буквально ключевой пункт, потому что именно целям сайта должен быть подчинен и функционал, и дизайн, и любой контент – всё на сайте.
1. Подписаться на рассылку по нашим акциям и предложениям.
2. Запрашивать наш прайс или цены на отдельные позиции при закупке товара.
Анализ существующего сайта Ссылка на него и что в нём хорошо, а что плохо Ссылка.ru
Отсутствие возможности редактирования и обновления информации.
Скучный дизайн.
Нет форм обратной связи.
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Предварительная структура сайта Какие разделы обязательно должны быть Главная (о компании, география работы, текущие акции); Каталог; Блог; Новости; Акции; Контакты
Примерная структура страниц Какие элементы должны присутствовать на страницах, как размещаться Строка поиска по сайту; Телефон горячей линии; Диалоговое окно с менеджером; Текущие акции; В боковом меню: список разделов каталога; Форма подписки на рассылку
Требования к дизайну и оформлению Шрифты, цвета, стилистика, наличие/отсутствие незаполненного пространства Сайт в строгом деловом стиле.
Корпоративные цвета красный и серый. Красный используется в качестве принта. Оттенки светло-серого как основной фоновый.
Фотографии – насыщенные цветные, иллюстрирующие процесс использования оборудования в деле.
Предпочтительные шрифты: Bravo; Yanone Kaffeesatz; Intro Condensed или похожие.
Имеющиеся материалы Ссылки на понравившиеся сайты, а также буклеты, журналы, фотографии – что угодно, а может быть у Вас есть готовый бренд-бук. Прилагается отдельным архивом.
Минимальное разрешение и устройства отображения В этом пункте укажите, с каких устройств предполагается просматривать сайт – ПК, ноутбуков, смартфонов… Мониторы ПК от 19 до 27 дюймов; Ноутбуки от 15,6 до 17,3 дюйма; Смартфоны от 3,5 до 6 дюймов; Планшеты от 7 до 12 дюймов
Нужна ли мобильная версия? Да
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Примерный набор модулей (для пользователей) В этом разделе нужно перечислить все функциональные возможности, которые Вы хотите видеть на сайте. Это может быть корзина, фильтры каталога по разным параметрам, возможность сделать онлайн-заказ, оставить заявку на обратный звонок, подписаться на рассылку и любые другие опции Фильтры каталога по цене, по алфавиту, по производителю.
Личный кабинет с историей заказов и просмотров.
Автоматическое формирование счёта.
Онлайн консультация.
Подписка на рассылку.
Возможность заказать обратный звонок.
Калькулятор стоимости.
Возможности администрирования Здесь нужно описать, какие текущие изменения Вы (или Ваш сотрудник) планируете самостоятельно вносить в работу будущего сайта, не прибегая к помощи разработчика.
После завершения работы, попросите научить Вас производить эти изменения.
Возможность создания/удаления/редактирования карточки товара, акций, новостей.
Возможность редактирования контактов, добавления/удаления дополнительных офисов.
Подключение платёжных систем и служб доставок Желательно указать, каких именно. Нужна рекомендация разработчика
Интеграция с CRM, 1С и другими программами Интеграция с Мегапланом и 1С.
ОБЗОР ИНТЕРНЕТ-РЕСУРСОВ
Обзор Лучше всего делать в формате: ссылка – что именно по этой ссылке нравится/категорически не нравится adme.ru— Развертывание меню
tobiafran.com — Анимация загрузки
anotherstate.co — Шрифты
ДОПОЛНИТЕЛЬНО
Вопросы к разработчику Если у Вас есть, о чём спросить предполагаемого исполнителя Вашего сайта, лучше задать их письменно и получить ответ в той же форме.
Дополнительные пожелания

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

Предпроектное проектирование

Этот пункт является неотъемлемой частью технического задания на создание сайта, хотя фактически он к нему не относится.

Дело в том, что после того как Вы заполнили бриф, подписали техническое задание и разработчик изучил всё это (включая рынок и конкурентов), то он делает предпроектное проектирование.

Предпроектное проектирование – это создание прототипа Вашего сайта, его скелета, который потом будет обрастать дизайном, контентом и функционалом с фишечками.

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

А так как этот процесс занимает не один день, то логично, что компании, которые делают проектирование до договора, просто показывают Вам шаблон в формате “как у всех”.

И да, сам прототип можно сделать с помощью обычных листов бумаги и цветных фломастеров.

Каждый лист – отдельная страница сайта (или экран одностраничника). Либо можно воспользоваться простыми офисными программами вроде Microsoft World или Microsoft Excel.

Лично мы при разработке landing page используем специальные программные продукты.

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

Предпроектным проектированием можно заняться совместно с разработчиком или полностью переложить это на его плечи. Главное, не забудьте, потом его согласовать и подписать двумя сторонами.

ЛАЙФХАКИ ПО СОСТАВЛЕНИЮ ТЗ

Эти пункты в равной степени относятся как к заполнению брифа, так и к составлению технического задания.

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

1. Где взять сайты-образцы?

Хорошим помощником могут стать широко представленные в сети рейтинги и ТОПы Интернет-ресурсов.

Например, ресурс allawards.ru подойдёт для этих целей. Здесь собирают лучшие, с точки зрения юзабилити, дизайна, креатива и эффективности сайты.

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

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

Но слепо не копируйте, наш российский менталитет всё-таки отличается и это не просто слова.

2. Как определить цветовую гамму?

Задача облегчается, если у Вас есть готовый бренд-бук или чёткий фирменный стиль.

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

Не лишним будет немного изучить вопрос восприятия цвета в рекламе. Или обратиться в Google за помощью.

Для этого открывайте кртинки по запросу “цветовые подборки” или вводите название цвета, который хотите взять за основу, а далее выбирайте понравившиеся и прикрепляйте к Вашему тз для дизайнера.

3. Как подобрать шрифты для сайта?

Не следует забывать, что шрифт играет не последнюю роль в восприятии текста. Пишите конкретные названия предпочтительных шрифтов.

Только не смотрите коллекцию шрифт Microsoft World, их уже на сто рядов все используют.

Лучше воспользуйтесь библиотеками шрифтов в интернете, например, allfont.ru.

ОШИБКИ ПРИ НАПИСАНИИ ТЗ

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

Поэтому выделяю самые основные из списка, те, что у Вас с вероятностью в 80% будут, если это Ваша первая разработка тз.

1. Нет ограничений во времени

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

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

Особо педантичные заказчики выставляют сроки разработки по каждому разделу сайта.

2. Утрата данных доступа

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

А дальше в 9 из 10 случаев эти данные просто теряются: разработчику они больше не нужны, а заказчик про них благополучно забывает.

И в один прекрасный день сайт просто перестаёт работать, потому что вовремя не продлили хостинг или доменное имя. Адреса сайта так и вовсе можно лишиться.

Поэтому запомните, что данные доступа к хостингу и доменному имени – это Ваши личные данные.

Распечатайте их и бережно храните вместе с важными документами. А лучше после разработки поменяйте все доступы, ведь всякое бывает, в той компании тоже существует человеческий фактор.

3. Отсутствие наглядности

Принцип “лучше 1 раз увидеть, чем 100 раз услышать” работает здесь на полную. В одни и те же слова заказчик и исполнитель могут вкладывать разный смысл.

И наверное эта ошибка вообще должна стоять на первом месте нашего хит-парада, так как такая картина происходит постоянно:

“Хочу абстракцию”, – пишет заказчик, подразумевая нечто подобное (пример на картинке ниже)

Абстракция – вид заказчика

“Ок, держите”, – говорит разработчик. И предлагает заказчику абстракцию следующего вида.

Абстракция – представление исполнителя

И попробуй потом докажи, что Ваша абстракция абстрактнее его. Каждый прав, никто не виноват.

За чей счёт переделывать – непонятно. А приложи заказчик к техническому заданию картинку с образцом, ничего такого бы не случилось.

4. Качественные прилагательные

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

Например, красивый (кто-то может быть ещё красивее или страшнее), умный, современный и т.п. Это слова-табу.

Их нельзя однозначно понять. У каждого субъективное представление о красоте и современности.

Только конкретика. Например, “На два тона светлее”, “Смещаем на 5 сантиметров” или “Острые углы у кнопки”.

5. “На усмотрение разработчика”

Об этот коварный пункт спотыкаются многие. Заполняя бриф или составляя тз на дизайн сайта, не оставляйте в нём пробелов.

Вы должны понимать, что “На усмотрение разработчика” означает “что хочу, то и ворочу” или же “Всё, что не оговорено, выполняется на усмотрение исполнителя”. И поверьте, это не просто лазейка, а целое окно в Европу для разработчика.

И конечно, так происходит не всегда. Если Вам попался грамотный специалист, то можно не волноваться за результат.

Но тут возникает другая проблема, он может сделать реально как надо, а Вам не понравится чисто субъективно. И всё будет как в известном для многих разработчиков анекдоте:

КОРОТКО О ГЛАВНОМ

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

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

Но при этом, даже составив и утвердив максимально подробное техническое задание, Вы не полностью застрахованы от разницы между ожиданием и полученным результатом.

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

Спасибо!

Наш менеджер свяжется с Вами в ближайшее время!

Что-то пошло не так

Попробуйте повторить попытку

«На данный момент мы делаем ребрендинг сайта и он станет активным в ближайшее время.

Но Вам же нужно увеличение продаж уже сейчас?! Поэтому заполните форму справа и мы свяжемся с Вами для презентация услуги.»

1. Общие положения

1.1. Политика в отношении обработки персональных данных (далее — Политика) направлена на защиту прав и свобод физических лиц, персональные данные которых обрабатывает ИП Жестков Н. В. (далее — Оператор).
1.2. Политика разработана в соответствии с п. 2 ч. 1 ст. 18.1 Федерального закона от 27 июля 2006 г. № 152-ФЗ «О персональных данных» (далее — ФЗ О персональных данных»).
1.3. Политика содержит сведения, подлежащие раскрытию в соответствии с ч. 1 ст. 14 ФЗ «Оперсональных данных», и является общедоступным документом.

2. Сведения об операторе

2.1. Оператор ведет свою деятельность по адресу 664009, г. Иркутск, ул. Ядринцева, 1/9, 70.
2.2. Руководитель Жестков Никита Владимирович (телефон +7 (964) 111-8758) назначен ответственным за организацию обработки персональных данных.
2.3. База данных информации, содержащей персональные данные граждан РоссийскойФедерации, находится по адресу: mailigen.ru, in-scale.bitrix24.ru, mail.yandex.ru, in-scale.ru, vk.com, facebook.com, manychat.com.


3. Сведения об обработке персональных данных

3.1. Оператор обрабатывает персональные данные на законной и справедливой основе для выполнения возложенных законодательством функций, полномочий и обязанностей, осуществления прав и законных интересов Оператора, работников Оператора и третьих лиц.
3.2. Оператор получает персональные данные непосредственно у субъектов персональных данных.
3.3. Оператор обрабатывает персональные данные автоматизированным и не автоматизированным способами, с использованием средств вычислительной техники и без использования таких средств.
3.4. Действия по обработке персональных данных включают сбор, запись, систематизацию,накопление, хранение, уточнение (обновление, изменение), извлечение, использование,передачу (распространение, предоставление, доступ), обезличивание, блокирование,удаление и уничтожение.
3.5. Базы данных информации, содержащей персональные данные граждан РоссийскойФедерации, находятся на территории Российской Федерации.

4. Обработка персональных данных клиентов

4.1. Оператор обрабатывает персональные данные клиентов в рамках правоотношений сОператором, урегулированных частью второй Гражданского Кодекса Российской Федерацииот 26 января 1996 г. № 14-ФЗ, (далее — клиентов).
4.2. Оператор обрабатывает персональные данные клиентов в целях соблюдения норм законодательства РФ, а также с целью:
— заключать и выполнять обязательства по договорам с клиентами;
— осуществлять виды деятельности, предусмотренные учредительными документами ИПЖестков Н. В.;
— информировать о новых продуктах, специальных акциях и предложениях;
— информировать о новых статьях, видео и мероприятиях;
— выявлять потребность в продуктах;
— определять уровень удовлетворённости работы.
4.3. Оператор обрабатывает персональные данные клиентов с их согласия,предоставляемого на срок действия заключенных с ними договоров. В случаях,предусмотренных ФЗ «О персональных данных», согласие предоставляется в письменном виде. В иных случаях согласие считается полученным при заключении договора или при совершении конклюдентных действий.
4.4. Оператор обрабатывает персональные данные клиентов в течение сроков действия заключенных с ними договоров. Оператор может обрабатывать персональные данные клиентов после окончания сроков действия заключенных с ними договоров в течение срока,установленного п. 5 ч. 3 ст. 24 части первой НК РФ, ч. 1 ст. 29 ФЗ «О бухгалтерском учёте» и иными нормативными правовыми актами.
4.5. Оператор обрабатывает следующие персональные данные клиентов:
— Фамилия, имя, отчество;
— Тип, серия и номер документа, удостоверяющего личность;
— Дата выдачи документа, удостоверяющего личность, и информация о выдавшем его органе;
— Год рождения;
— Месяц рождения;
— Дата рождения;
— Место рождения;
— Адрес;
— Номер контактного телефона;
— Адрес электронной почты;
— Идентификационный номер налогоплательщика;
— Номер страхового свидетельства государственного пенсионного страхования;
— Должность;
— Фотография.
4.6. Для достижения целей обработки персональных данных и с согласия клиентов Оператор предоставляет персональные данные или поручает их обработку следующим лицам:
— менеджер по продажам
— руководитель проекта
— менеджер проекта
— маркетолог

5. Сведения об обеспечении безопасности персональных данных

5.1. Оператор назначает ответственного за организацию обработки персональных данных для выполнения обязанностей, предусмотренных ФЗ «О персональных данных» и принятыми в соответствии с ним нормативными правовыми актами.
5.2. Оператор применяет комплекс правовых, организационных и технических мер по обеспечению безопасности персональных данных для обеспечения конфиденциальности персональных данных и их защиты от неправомерных действий:
— обеспечивает неограниченный доступ к Политике, копия которой размещена по адресу нахождения Оператора, а также может быть размещена на сайте Оператора (при его наличии);
— во исполнение Политики утверждает и приводит в действие документ «Положение об обработке персональных данных» (далее — Положение) и иные локальные акты;
— производит ознакомление работников с положениями законодательства о персональных данных, а также с Политикой и Положением;
— осуществляет допуск работников к персональным данным, обрабатываемым в информационной системе Оператора, а также к их материальным носителям только для выполнения трудовых обязанностей;
— устанавливает правила доступа к персональным данным, обрабатываемым в информационной системе Оператора, а также обеспечивает регистрацию и учёт всех действий с ними;
— производит оценку вреда, который может быть причинен субъектам персональных данных в случае нарушения ФЗ «О персональных данных»;
— производит определение угроз безопасности персональных данных при их обработке в информационной системе Оператора;
— применяет организационные и технические меры и использует средства защиты информации, необходимые для достижения установленного уровня защищенностиперсональных данных;
— осуществляет обнаружение фактов несанкционированного доступа к персональным данным и принимает меры по реагированию, включая восстановление персональныхданных, модифицированных или уничтоженных вследствие несанкционированного доступак ним;
— производит оценку эффективности принимаемых мер по обеспечению безопасностиперсональных данных до ввода в эксплуатацию информационной системы Оператора;
— осуществляет внутренний контроль соответствия обработки персональных данных ФЗ «Оперсональных данных», принятым в соответствии с ним нормативным правовым актам,требованиям к защите персональных данных, Политике, Положению и иным локальнымактам, включающий контроль за принимаемыми мерами по обеспечению безопасностиперсональных данных и их уровня защищенности при обработке в информационнойсистеме Оператора.

6. Права субъектов персональных данных

6.1. Субъект персональных данных имеет право:
— на получение персональных данных, относящихся к данному субъекту, и информации,касающейся их обработки;
— на уточнение, блокирование или уничтожение его персональных данных в случае, еслиони являются неполными, устаревшими, неточными, незаконно полученными или неявляются необходимыми для заявленной цели обработки;
— на отзыв данного им согласия на обработку персональных данных;
— на защиту своих прав и законных интересов, в том числе на возмещение убытков икомпенсацию морального вреда в судебном порядке;
— на обжалование действий или бездействия Оператора в уполномоченный орган позащите прав субъектов персональных данных или в судебном порядке.
6.2. Для реализации своих прав и законных интересов субъекты персональных данныхимеют право обратиться к Оператору либо направить запрос лично или с помощьюпредставителя. Запрос должен содержать сведения, указанные в ч. 3 ст. 14 ФЗ «Оперсональных данных».

УТВЕРЖДАЮ
Н. В. Жестков
29.06.2020

Уважаемый пользователь. Любая информация, размещенная на сайте in-scale.ru, предназначена только для свободного изучения пользователями сайта. Администрация сайта прилагает все усилия для того, чтобы предоставить на этом сайте достоверную и полезную информацию, которая отвечает на вопросы пользователей сайта, но в то же время не исключает возникновения ошибок.

Ни при каких обстоятельствах Администрация Сайта in-scale.ru не несет ответственности за какой-либо прямой, непрямой, особый или иной косвенный ущерб в результате использования информации на этом сайте или на любом другом сайте, на который имеется гиперссылка с нашего cайта, возникновение зависимости, снижения продуктивности, увольнения или прерывания трудовой активности, а равно и отчисления из учебных учреждений, за любую упущенную выгоду, приостановку хозяйственной деятельности, потерю программ или данных в Ваших информационных системах или иным образом, возникшие в связи с доступом, использованием или невозможностью использования Сайта, Содержимого или какого-либо связанного интернет-сайта, или неработоспособностью, ошибкой, упущением, перебоем, дефектом, простоем в работе или задержкой в передаче, компьютерным вирусом или системным сбоем, даже если администрация будет явно поставлена в известность о возможности такого ущерба.

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

Сайт in-scale.ru — это проект, работающий без заключения каких-либо договорённостей или договоров между вами, пользователями данного сайта, администрацией, владельцами серверов, на которых он размещён, либо кем-то ещё, любым образом связанными с этим или родственными ему проектами, которые (договора) могут стать предметом прямых претензий.

Некоторые ссылки на in-scale.ru ведут к ресурсам, расположенным на сторонних сайтах. Данные ссылки размещены для удобства пользователей и не означают, что Администрация одобряет содержание других сайтов. Кроме этого, Администрация in-scale.ru не несет никакой ответственности за доступность этих ресурсов и за их контент. Это заявление относится ко всем ссылкам, представленным на in-scale.ru, и материалам всех веб-сайтов, доступных через баннеры и ссылки на веб-сайте по адресу in-scale.ru

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

In-scale.ru не гарантирует возможность приобретения или использования тех или иных товаров или услуг по ценам и/или на условиях, указываемых в рекламных блоках (текстах, баннерах).

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

Администрация сайта in-scale.ru вправе отказать в доступе к сайту любому Пользователю, или группе Пользователей без объяснения причин своих действий и предварительного уведомления.

Администрация вправе изменять либо удалять ссылки на информацию, графические, звуковые и прочие данные, размещенные Пользователями на in-scale.ru, без предварительного уведомления и объяснения причин своих действий.

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

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

Бездействие со стороны Администрации в случае нарушения Пользователем либо группой Пользователей пользовательского соглашения не лишает Администрации права предпринять соответствующие действия в защиту интересов in-scale.ru позднее.

Все права на материалы, находящиеся на in-scale.ru, охраняются в соответствии с законодательством ЕС и РФ, в том числе, об авторском праве и смежных правах.

Если в соответствии с действующими законами какие-либо условия будут признаны недействительными, остальные условия остаются в полной силе.

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

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

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

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

Вся наша продукция и услуги созданы с образовательной и ознакомительной целями.

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

Администрация in-scale.ru в любое время вправе внести изменения в Правила, которые вступают в силу немедленно. Продолжение пользования сайтом после внесения изменений означает ваше автоматическое согласие на соблюдение новых правил.

Данный документ гласит о том, что вы даете свое согласие на то, что ИП “Жестков Н.В.”, команда ресурса in-scale и сам сайт in-scale.ru не несёт ответственность за ошибочно принятые Вами решения по поводу доходов, прибылей, способов ведения бизнеса, продукции тренинг-центра, предоставляемых услуг или других материалов, что размещаются на данном сайте: текстовой, аудио и видео информации.

Заполняя форму подписки на сайте in-scale.ru, Вы соглашаетесь с политикой конфиденциальности проекта, а также с другими положениями:

1. Подписчик дает бессрочное согласие на обработку всех персональных данных, предоставленных на домене in-scale.ru

2. Подписчик не возражает против получения e-mail, смс уведомлений информационного и рекламного характера о предстоящих акциях, изменениях на проекте, иных событиях с домена in-scale.ru или от сообществ vk.com/in_scale, facebook.com/inscalerus

3. Подписчик может отписаться от информационной рассылки проекта In-scale в любое время по своему желанию при помощи специальной гиперссылки, а также обратившись в службу поддержки по адресу [email protected] и попросив удалить его контакты адрес из нашей подписной базы.

После получения администрацией сайта in-scale.ru такой просьбы, e-mail адрес или аккаунт в социальных сетях будет удален из базы в течение 72 часов, кроме выходных и праздничных дней.

ИП “Жестков Н.В” гарантирует полный возврат средств за приобретенный цифровой продукт по первому требованию клиента.

Срок гарантийного периода для всех цифровых продуктов составляет 7 календарных дней с момента оплаты.

Для того, чтобы запросить возврат денежных средств за определенный продукт обратитесь на [email protected] . Все заявки рассматриваются в течении 72 часов, кроме выходных и праздничных дней.

Возврат денежных средств осуществляется путём перевода необходимой суммы на один из электронных кошельков (WebMoney, Яндекс.Деньги), либо на карту VISA/MASTERCARD в пределах России. Длительность транзакции – от 1 до 5-х банковских дней после отправки денег.

Как составить грамотное техзадание на разработку сайта

Время чтения: 17 минут Нет времени читать? Нет времени?

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика — потратил время впустую.

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

Статья будет полезна:

  • Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
  • Менеджерам проектов.
  • Руководителям диджитал-студий.
  • Предпринимателям, которые планируют заказать разработку сайта.

Чтобы материал получился дельный, я собрал комментарии нескольких разработчиков, дизайнеров, проект-менеджеров и владельцев диджитал-студий. Самые ценные добавил в конец статьи. Поехали разбираться.

Что такое техзадание и зачем оно нужно

Техническое задание — это документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше все участники процесса понимают, каким он должен быть. А значит, растет шанс того, что все останутся довольны результатом.

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

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

Польза для исполнителя:

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

Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.

Техзадание составляет исполнитель

Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» — это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.

Хорошее ТЗ всегда составляет исполнитель: проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец кафе или стоматологической клиники. Поэтому описывать проект придется ему.

Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:

  • Познакомить исполнителя с компанией, продуктами и целевой аудиторией.
  • Объяснить, зачем ему сайт.
  • Рассказать, что он хочет, поделиться идеями.
  • Показать примеры хороших с его точки зрения сайтов.
  • Ответить на любые другие вопросы исполнителя.

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

Пишите однозначно и точно

Этот совет вытекает из главной цели техзадания — «Убедиться, что клиент и исполнитель правильно поняли друг друга».

В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое — с невнятными формулировками, которые ничего сами по себе не значат:

  • Сайт должен понравиться заказчику. А если у него будет плохое настроение?
  • Сайт должен быть удобным. Что это значит? Удобным для чего?
  • Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
  • Качественный экспертный контент. Ну, вы поняли.

Проверяйте, нет ли в тексте неоднозначностей. Если есть — перепишите. Ваши формулировки должны быть четкими и точными:

  • Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
  • Большие нагрузки → 50 тысяч посетителей одновременно.
  • На главной странице выводится список статей На главной странице выводится список последних 6 опубликованных статей.
  • Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

А еще стоит указать цель сайта и описать его функционал в двух словах — чтобы не получить интернет-магазин вместо блога.

Поясните сложные термины

Первое правило техзадания — оно должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка — владелица магазина детских игрушек — обязательно поясните их. Понятным языком, а не копипастой из «Википедии».

Опишите инструменты и требования к хостингу

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом — он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP — а у клиента сервер на .NET.

Перечислите требования к работе сайта

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

Сюда же напишите требования к скорости загрузки сайта, устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

Это один из важнейших этапов работы на сайтом. Структура — это фундамент. Если она неудачная — сайт получится кривой.

Объясните, что будет на каждой странице

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

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

Перечисление элементов — ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.

Распишите сценарии использования сайта

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

  • Действие пользователя.
  • Ответное действие сайта.
  • Результат.

Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы — очень желательно.

Подробнее о сценариях использования читайте в «Википедии».

Определите, кто отвечает за контент

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

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.

Опишите дизайн (если сможете)

Как и в с случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме — напишите ее. Если у него есть брендбук, в котором прописаны шрифты, — укажите и их.

Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.

Вместо вывода: структура техзадания

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

  • Информация о компании и целевой аудитории, цели и задачи сайта.
  • Глоссарий терминов, которые могут быть непонятны клиенту.
  • Технические требования к верстке и работе сайта.
  • Описание используемых технологий и список требований к хостингу.
  • Подробная структура сайта.
  • Прототипы страниц или описания элементов, которые должны на них быть.
  • Сценарии использования нестандартного интерфейса (опционально).
  • Список контента, который делает разработчик.
  • Требования к дизайну (опционально).

Также рекомендую почитать

  • Правила составления Software Requirements Specification. SRS — следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
  • Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

Это конец той части, которую писал я. Но есть и другая — комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.

Комментарии разработчиков

Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.


Аша Саакян, веб-дизайнер, фрилансер

Техзадание должен писать менеджер проекта, тимлид или сам разработчик (если он фрилансер и работает один). Клиент не разбирается в сайтах — он не сможет учесть все важное.

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

Чем сложнее задача, тем подробнее должно быть ТЗ. Когда я участвовала в больших проектах, я видела техзадания и на 30 страниц.

Гурам Сипки, основатель диджитал-студии Udix Media

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

ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

  • Информацию о компании и цель сайта.
  • Требования к дизайну, цветовую гамму.
  • Используемые технологии и CMS.
  • Кто занимается контентом — мы или клиент.
  • Структуру сайта вплоть до каждой страницы.
  • Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

Последние 2 раздела — самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.

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

Дмитрий Кузьмин, менеджер проектов

Писать техзадание должен разработчик или менеджер проекта. Нужно указывать только конкретные завершенные формулировки, которые невозможно оспорить. И избегать оценочных прилагательных: красивый, эффективный и прочее.

Если что-то не указано в ТЗ — надо или уточнить у клиента или реализовать на усмотрение разработчика. Но отдельно сообщаем об этом моменте клиенту. Это нужно обсудить заранее, а еще лучше прописать в конце техзадания.

А еще нужно нарисовать примерные эскизы того, что должно получиться. С подробными комментариями.

Александр Курочкин, основатель студии Etalon Idea

Техзадание есть всегда, без него не бывает работы. «Мне нужен интернет-магазин» — это уже техзадание. Проблема в том, что это очень расплывчатое ТЗ, оно не дает практически никакого понимания.

Задача проект-менеджера — собрать всю необходимую информацию, продумать решение, создать сайт у себя в голове. А потом описать его в документе. Фактически, ТЗ — это уже полпути к готовому продукту.

Техзадание — это эталон, с которым вы и ваши клиенты будете сравнивать сайт. Оно нужно всем:

  • Разработчик равняется на вещи, описанные в ТЗ.
  • Тестировщик проверяет, все ли работает так, как задумано.
  • Клиент понимает, что получит в итоге.
  • Менеджер проекта может оценить стоимость и сроки разработки.

С сайтом-визиткой или магазином все просто. На нем вряд ли будет что-то новое, поэтому оценить его стоимость легко еще на этапе обсуждения. Если мы делаем что-то подобное, то можем обойтись вообще без ТЗ. Обсудили задачу, написали формальность в договоре, сделали. Все довольны.

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

В ТЗ мы указываем:

  • цель сайта;
  • требования к серверу;
  • описание работы сайта и отдельных его элементов;
  • используемые технологии и библиотеки;
  • макет дизайна интерфейса;
  • структуру и логику внутренних переходов;
  • роли и сценарии работы с сайтом для каждой из них;
  • архитектуру базы данных (опционально).

Мой совет читателям — в первую очередь наладьте коммуникацию. Если члены команды не могут понять друг друга и клиента — никакое техзадание вам не поможет.

Юрий Кетов, фронтенд-разработчик, фрилансер

Я не люблю работать по ТЗ. Большинство ТЗ, которые я видел, чрезмерно громоздки и неэффективны. Для меня идеальна ситуация, когда клиент в одном абзаце формулирует задачу сайта и контекст, в котором он будет использоваться.

Сайт для Кукольного театра. Задача — рассказать посетителям о театре и репертуаре, предоставить возможность заказать билет онлайн.

В этом случае для меня главное — референсы. Я посмотрю, что сделали в этом тематике Студия Лебедева, Nimax, RedCollar, ONY, Сибирикс и еще примерно 10 компаний, выберу 2-3 наиболее удачных проекта, согласую с клиентом и буду ориентироваться на них.

Промостраница для продажи хны для биотатуажа.

Здесь главное сделать сайт, с помощью которого можно достигнуть нужных KPI. Смотрим, какие сайты делают IT-Agency и Convert Monster и делаем также, не надо ничего изобретать.

Чем больше контента дает клиент, тем лучше. Если вы дадите мне 1000 фотографий, 20 видео, 50 страниц текста — супер. Я сам все отфильтрую и выберу то, что нужно. Я немного утрирую, но, в общем, это так. Чем больше контента на входе, тем лучше, но оставьте за мной право выбирать.

Александр Белов, проект-менеджер «Текстерры»

Техническое задание нужно любому проекту. В каждом ТЗ обязательно должны быть указаны:

  • Цели и задачи, которые будет выполнять сайт.
  • Целевая аудитория.
  • Проработанная до мелочей, структура сайта.
  • Интерфейсные элементы сайта.

Клиент должен четко представлять свой сайт в законченном варианте, его внешний вид и дальнейшую стратегию развития.

Техническое задание не должно указывать разработчикам «как им делать, что делать и какой код вставить» — это в корне неправильно. В общих чертах, нужно описывать какой сайт должен быть, а не как его делать. Это необходимо учитывать как минимум потому, что заказчик, чаще всего, не обладает должной экспертизой.

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

Как мы готовим техзадание:

  • Анализируем ТЗ, присланное клиентом.
  • Изучаем прототип и дизайн-макет сайта.
  • На основе полученных данных начинаем подбирать функциональные модули для сайта, которые будут использоваться 100 % и которые, возможно, потребуется использовать.
  • Прописываем элементы, которые будут нужны при работе с интерфейсом.
  • Исходя из этих данных и оценки «веса» сайта, вычисляем подходящие системные требования к хостингу сайта.
  • После этих базовых пунктов начинаем расписывать ТЗ более детально по каждой странице.

Разработка технического задания (ТЗ)

Каждая разработка программного обеспечения, начинается с оформления технического задания (ТЗ). Государственные заказчики и компании режимного регламента обязаны составлять ТЗ в соответствии с ГОСТ 19. В бизнесе, формат технического задания, обычно, не регламентируется какими-либо правилами, но имеет ряд основных разделов.

Основные разделы ТЗ

  • Словарь терминов. Описание основных объектов и сокращений.
  • Назначение разработки. Отражает суть создаваемого приложения или комплекса.
  • Технические условия / требования. Описывает рамки создаваемого приложения
  • Логика работы
  • Интерфейс приложения
  • Панель администрирования / Настройки

Назначение разработки

Данный раздел должен донести до исполнителя цель создания приложения. Это очень важно – когда программист понимает то что он создает, т.к. он может учитывать специфику темы и заложить возможность для будущего развития ПО. Абстрактная цель не позволит получить удобства в использовании, т.к. критерий оценки работы будет не явный.

Технические условия, Технические требования.

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

  • Платформа работы приложения: IOS / Android
  • Приложение IOS
    • Совместимость с ОС : IOS 8.0 и старше
    • Поддержка устройств : iPhone 5S+, iPad2+, iPad Air+, iPad mini +
    • Верстка iPhone Книжная : Да
    • Верстка iPhone Альбомная : Адаптивная от книжной
    • Верстка iPad Книжная: Да, см. макет в Приложении 3
    • Верстка iPad Альбомная : Да, см. макет в Приложении 4
  • Приложения Android
    • Совместимость с Android : Android 4.4. и старше
    • Верстка телефон книжная : Да
    • Верстка телефон альбомная : Да
    • Верстка планшет Книжная : Адаптивная от телефона
    • Верстка планшет Альбомная : Адаптивная от телефона
  • Сервер
    • Совместимый вебхостинг на базе Apache 2+ PHP 5+ MySQL

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

Если приложения создаются под определенные требования (Безопасность, секретность и т.д.), то они, так же, описываются в данном разделе в произвольной форме.

Логика работы

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

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

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

Если Вы не имеете достаточной компетенции для составления разделал логики, привлеките профессионала. Объясните профессионалу то что Вы хотите получить, и он будет задавать те дополнительные вопросы, которых может не хватать в Вашем толковании.

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

Интерфейс приложения

Мы уже описали требования к исходным данным, где преимущественно говорится о формате представления интерфейса приложения.

Интерфейс должен быть описан и показан в графическом виде. Если в приложении должны присутствовать элементы атрибутики фирменного стиля, то подобные медиаматериалы должны передаваться на цифровом носителе или размещены на файлообменнике с указанием прямой ссылки на файл. Корпоративные цвета описываются в формате HEX (например #4177ab).

Желательно приложить блок-схему переходов между экранами, с описанием переходов. При необходимости включения эффектов анимации, они должны быть описаны четко, техническими терминами. Если уже подготовлены макеты экранов, то можно включить их в эту схему или сослаться на название конкретного макета. В случаях, когда на макете присутствует много элементов управления (кнопок) то желательно явно прорисовывать от какой кнопки к какому экрану должен производиться переход

Описание интерфейса должно точно соответствовать логике работы, в противном случае не явно что является истинным. Перед окончанием правки раздела ТЗ связанного с интерфейсом, убедитесь что нет ничего лишнего. Если есть какой-то рисунок или эскиз, но ни один другой объект на него не ссылается, значит следует его описать дополнительно.

Сервер API

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

Описание сервера API должно включать состав протокола, а также методы взаимодействия с системами, которые не были описаны в разделе «Логика работы».

Минимальное описание с применением формата JSON в архитектуре REST:

Авторизация

URL: https://site.ru/api/login
Метод передачи входных параметров : POST
username — логин пользователя
password — md5-хэш контантенации логина и пароля
autologin — автовход (значение null/on)
Формат выходных данных : JSON

Пример

Где

  • result — вид ответа
    • succefull — удачный вход
    • login_error — логин не найден
    • password_error — ошибка пароля
    • locked — пользователь заблокирован
    • try_error — превышено количество попыток входа за 10 минут
  • session — идентификатор сессии пользователя
  • user_id — идентификатор пользователя

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

Панель администрирования / Настройки

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

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

  • Адреса ресторанов с самовывозом, время выдачи заказов. (какой-либо ресторан может быть закрыт на проведение банкета или ремонт, а в праздничные дни, время самовывоза может быть сокращено)
  • Ограничение минимальной стоимости.
  • Условия проведения акций. (возможность проинформировать клиента о новых предложениях)
  • Меню и цены

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

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

Чаще всего, для работы с системами обеспечения данных (API), мы разрабатываем панели управления по технологии WEB. Данный подход прост, эргономичен, функционален и не тянет за собой установки какого-либо дополнительного софта.

В разделе ТЗ про панель администрирования, опишите максимум зависимых переменных. Если сервер будет собирать данные, опишите в каком виде должна отображаться информация. После накопления, опишите желательные виды отчетов, графиков или диаграмм.
В случае если система должна сопрягаться с внешним сервером ( например 1С), то панель администрирования должна поддерживать изменение реквизитов подключения (адрес, логин, пароль).

Рекомендуем узнать подробнее о панели администрирования в статье Web-офис.

Входные данные

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

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

Любая информация, полученная до работы приложения, относится к входным данным.

Выходные данные

Приложение, которое создает какой-либо контент в хранилище смартфона, должно содержать данный раздел в ТЗ.

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

После оформления технического задания, подготовьте остальные исходные данные, необходимые для разработки мобильного проиложения

Примеры ТЗ

Техническое задание на разработку системы по доставке продукции из магазинов и ресторанов на дом. Включает:

  • База данных
  • Серверная часть (API)
  • Диспетчерский кабинет
  • Веб-кабинет партнера
  • Набор мобильных приложений

Техническое задание на разработку службы по бронированию автомобилей как сервис франшизы (аналог Hetzner). Включает:

  • База данных
  • Серверная часть (API)
  • Офис менеджера
  • Кабинет для обслуживающего персонала
  • Веб-кабинет партнера
  • Набор мобильных приложений для клиентов

Помощь в разработке ТЗ

Мы понимаем, что не всегда в организации есть профессиональные технические сотрудники, которые могут качественно выполнить работу по разработке технического задания. Предлагаем рассмотреть наши услуги по разработке ТЗ под ключ. Мы описали процесс этой услуги в разделе разработка технического задания на проект. Узнайте о правильных этапах разработки ТЗ. С нами Вы не допустите ошибок при поставновке задачи подрядчику (исполнителю), а наше ТЗ будет четко описывать цели и ограничения для исполнителя. С корректным ТЗ, в случае проблем в ходе работ, Вы гарантированно получите ожидаемый результат, или защитите свои права даже в судебном порядке.


Узнайте цены на наши услуги по разработке ТЗ и эскизного проекта. Съэкономьте свое время и используйте его с умом в своей основной работе, а мы позаботимся о технической части, в которой отлично разбираемся сами.

Техническое задание на разработку веб-приложения

Требуется разработать веб-приложение (сайт) по поиску работы, подбору персонала и выбора образования.

Основные страницы (разделы) сайта:

Главная страница. Содержит список последних добавленных вакансий (должность, требования, контакты), фильтр по категории, список VIP вакансий (логотип, контакты, произвольный HTML-код), а также ссылки для перехода на предыдущую/следующую страницу.

Добавить вакансию. Пользователю отображается форма с полями:

требования к соискателю;

поле для ввода captcha.

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

Сайт разрабатывается под базовое разрешение экрана 1024×768 пкс,

Корректное отображение броузерами Internet Explorer, Opera, Mozilla.

Использование фирменных цветов и логотипа компании.

Обязательная визуальная поддержка действий пользователя — т.н. «интерактив» (визуальное отображение активных, пассивных ссылок; четкое обозначение местонахождения пользователя). По ссылке с каждой страницы загружается почтовая программа (бланк письма для обратной связи).

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

ТЗ для сайта: как составить идеальное техническое задание

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

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

Зачем составлять ТЗ для сайта?

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

Какие конкретные преимущества даёт обеим сторонам правильно подготовленное ТЗ для сайта? Мы подготовили для вас несколько аргументов в пользу составления тех.задания.

Поделитесь публикацией

Мы будем рады, если вы поделитесь этой статьёй с друзьями!

Что даёт ТЗ заказчику?

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

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

Что даёт ТЗ исполнителю?

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

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

Кто составляет ТЗ для сайта?

Пожалуй, с этим вопросом сталкиваются обе стороны на том или ином этапе своей работы. Если коротко, то ответ на него звучит так:

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

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

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

Основные разделы ТЗ для сайта

« Что должно быть в техническом задании?» — главный вопрос, с которым к нам обращаются заказчики на этапе согласования проекта. Чтобы получить на него ответ, мы предлагаем ознакомиться с важнейшими разделами ТЗ для сайта.

Информация о проекте

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

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

Технические особенности проекта

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

  • Адаптивность. Требуется ли вашему сайту отдельный вариант отображения на мобильных устройствах?
  • Кроссбраузерность. Какие минимальные версии браузера должны отображать сайт? Помните, что старые браузеры ( вроде Internet Explorer 7) существенно урезают возможности разработки, занимая при этом не более 1% всех используемых в мире браузеров.
  • Система управления. Если вы уже определились с тем, какую CMS выбрать для сайта, зафиксируйте это в ТЗ. Если вы выбрали 1C-Битрикс, возможно, вам поможет наша статья о сравнении её с WordPress.

Появились вопросы?

Свяжитесь с командой #VA — мы расскажем вам подробнее о сайтах и нашей студии.

Структура сайта

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

Сквозные элементы

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

  • Шапка сайта — верхняя часть, содержащая, как правило, логотип компании, навигацию по страницам, контактную информацию и дополнительные элементы.
  • Подвал сайта — нижняя часть, являющаяся заключительной частью каждой страницы. Зачастую, может дублировать часть информации из шапки.
  • Боковые панели ( сайдбары) — вертикальные колонки, содержащие определённый набор функциональных блоков ( виджетов). Пример: боковая панель на странице интернет-магазина, содержащая фильтры и навигацию по категориям.
  • Всплывающие окна и формы, появляющиеся на страницах сайта при клике на кнопку или ином действии.

Уникальные страницы

Как правило, объём работы дизайнера и разработчика зависит от количества уникальных разделов/страниц, на базе которых строится сайт. Именно поэтому каждую такую страницу, имеющую уникальные дизайн и структуру, необходимо зафиксировать и описать в ТЗ для сайта.

Уникальные страницы — своеобразные макеты, на базе которых будут создаваться и множиться страницы сайта, обладающие схожими характеристиками. Каждая такая страница требует затрат со стороны дизайнера и разработчика.

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

  • Страница новости в блоге. Содержит сквозные элементы в виде шапки и подвала, а также дополнительные блоки: заголовок новости, краткое описание, фотографию-обложку, дату публикации, текст новости и блок комментариев.
  • Страница товаров в каталоге. Содержит сквозные элементы в виде шапки и подвала, а также дополнительные блоки: боковую колонку с фильтрацией товаров по заданным параметрам, список товаров в конкретной категории и блок персональных предложений.

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

Прочие страницы

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

  • Типовая текстовая страница — на базе неё будут создаваться все новые страницы, не попадающие под описанные уникальные страницы. Рекомендуется на этапе дизайна заложить в этот пункт все необходимые элементы для оформления текста: заголовки, параграфы, списки, таблицы, изображения, встраиваемые видео и так далее.
  • Страницы ошибок — те самые небольшие странички на сайте, которые видит посетитель, когда что-то пошло не так. Не стоит недооценивать эти страницы — если подойти к их реализации с креативом, результат может удивить посетителей вашего сайта. Отличные примеры можно посмотреть здесь, здесь и здесь.
  • Страница результатов поиска — один из важнейших функциональных блоков на сайте. От того, насколько удобно будут представлены результаты поиска иногда напрямую зависит конверсия в продажи.
  • Страницы входа и регистрации — если на вашем сайте предполагается авторизация пользователей, позаботьтесь о том, чтобы формы были удобными.

ТЗ для сайта — важные моменты

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

Детальное описание сущностей

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

  1. Вы создаёте сайт-визитку, состоящий исключительно из нескольких страниц. В этом случае, сущностью будет «Страница», у каждой из которых есть свой заголовок, содержимое и другие опции.
  2. Если вы захотите добавить на свой сайт раздел с новостями, то «Новость» будет новой сущностью. Помимо заголовка и содержимого эти материалы могут иметь, например, дату публикации или автора.
  3. Кстати, «Автор» также является сущностью — у каждого из них может быть уникальная фотография и имя. В этом случае, сущности могут быть связаны друг с другом, как новость и её автор.

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

Функциональные особенности

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

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

Шаблон ТЗ для сайта

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

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

Заключение

Несмотря на объём этой статьи, мы описали далеко не все аспекты, которые помогут сделать техническое задание для сайта идеальным. Чем более детальным и продуманным будет ТЗ для сайта, тем меньше проблем и разногласий появится в процессе разработки. Закон Мёрфи, адаптированный для данного случая, будет звучать так:

Если какая-то особенность сайта не зафиксирована в ТЗ, она будет реализована неправильно.

Безусловно, это актуально не для каждого проекта. Однако, имея качественно подготовленное ТЗ для сайта, вы практически гарантируете сохранение бюджета от 5 до 20%. И если есть возможность снизить вероятность ошибки — почему ей не воспользоваться?

Продолжить чтение:

Вам могут также понравиться другие статьи из нашего блога:

Сайт va-promotion.ru уважает Ваше право и соблюдает конфиденциальность при заполнении, передачи и хранении Ваших конфиденциальных сведений.

Размещение заявки на сайте va-promotion.ru означает Ваше согласие на обработку данных и дальнейшее использование этих данных для осуществления связи с Вами.

Под персональными данными подразумевается информация, относящаяся к субъекту персональных данных, в частности фамилия, имя и отчество, дата рождения, адрес, контактные данные (телефон, адрес электронной почты), семейное, имущественное положение и иные данные, относимые Федеральным законом от 27 июля 2006 года № 152-ФЗ «О персональных данных» к категории персональных данных.

Целью обработки персональных данных является информирование об оказываемых услугах ИП Алексеев Валерий Альбертович.

В случае отзыва согласия на обработку своих персональных данных мы обязуемся удалить Ваши персональные данные в срок не позднее 3 рабочих дней. Отзыв согласия можно отправить в электронном виде по адресу: [email protected]

ДОГОВОР-ОФЕРТА

Школа #VA

Индивидуальный Предприниматель Алексеев Валерий Альбертович (далее по тексту – Исполнитель) адресует настоящий Договор-оферту (далее по тексту – Договор-оферта) любому лицу (неопределенному кругу лиц), чья воля будет выражена им лично, либо через уполномоченного представителя (ст. 182, 185 ГК РФ), выразившему готовность воспользоваться услугами Исполнителя (далее по тексту – Заказчик).

  1. Общие положения
    1. Договор-оферта является официальным предложением Исполнителя (офертой) к заключению договора возмездного оказания информационно-консультационных услуг по программам обучения (далее по тексту – Услуги), представленным на сайте Исполнителя: https://va-promotion.ru/school (далее по тексту – Сайт).
    2. Акцептом Договора-оферты является оплата Услуг, которые указаны в настоящем Договоре-оферте.
    3. Осуществляя акцепт Договора-оферты в п. 1.2 настоящего Договора-оферты, Заказчик гарантирует, что ознакомлен, безоговорочно принимает все условия настоящего Договора-оферты в том виде, в каком они изложены. Акцепт Договора-оферты равносилен заключению Договора возмездного оказания услуг на условиях, изложенных в Договоре-оферте.
    4. Услуги Исполнителя не являются образовательной деятельностью в традиционном понимании, не подлежат лицензированию, не сопровождаются проведением итоговой аттестации, присвоения какой-либо квалификации и выдачей документа об образовании.
    5. Договор-оферта размещается на Сайте.
    6. Исполнитель вправе в любое время вносить изменения в условия настоящего Договора-оферты. Изменения в условия Договора-оферты начинают свое действие с момента опубликования их на Сайте.
    7. Договор–оферта не требует скрепления печатями и/или подписания Заказчиком и Исполнителем (далее по тексту – Стороны), сохраняя при этом полную юридическую силу.
  2. Предмет Договора-оферты
    1. В соответствии с условиями Договора-оферты Исполнитель обязуется оказать Услуги, предусмотренные п. 1.1., а Заказчик обязуется оплатить Услуги в установленные настоящим Договором-офертой сроки.
    2. Для оказания услуг Исполнитель вправе привлекать соисполнителей по своему выбору.
    3. Обучение проводится с использованием дистанционных технологий на онлайн-платформе Исполнителя (программное обеспечение, представляющее собой набор взаимосвязанных веб-сервисов и модулей, составляющих единое пространство предоставления услуг потребителям в сети Интернет). Период обучения и срок освоения программы указаны в соответствующей программе на Сайте.
  3. Сроки Договора-оферты
    1. Срок для совершения акцепта Заказчиком является неограниченным.
    2. Договор-оферта вступает в силу с момента совершения Заказчиком акцепта, определяемого в соответствии с п. 1.2. настоящего Договора-оферты и действует до момента окончания Курса, определенного моментом окончания последней консультации Курса, дата которой определяется расписанием «Исполнителя» и не может превышать трехмесячного срока с момента начала оказания Услуг.
    3. Сроки оказания Услуг – в соответствии с разработанной и размещенной в Личном кабинете Заказчика “Расписанием курса”.
  4. Права и обязанности сторон
    1. Заказчик обязуется:
      1. Оплатить Услуги Исполнителя полностью в соответствии с форматом оплаты изложенным в п.7 настоящего Договора.
      2. Выполнять домашние задания по курсу в соответствии с расписанием Исполнителя. Сданным домашним заданием считается загруженный соответствующий файл/группа файлов в личный кабинет Заказчика в установленные Исполнителем сроки, согласно расписанию в личном кабинете.
      3. Исполнитель имеет право отчислить Заказчика с текущего курса исходя из следующих оснований:
        1. На основании письменного заявления Заказчика;
        2. При условии отсутствия сдачи еженедельного домашнего задания по курсу
      4. В случае отчисления, Заказчик не имеет права на возврат денежных средств, уплаченных за обучение на курсе, но имеет право изучать материалы самостоятельно без получения помощи исполнителя и без проверки домашнего задания
      5. Не копировать, не тиражировать и не распространять методические материалы или их составные части и иной материал, полученный на курсе, без предоставления письменного согласия Исполнителем, в противном случае «Заказчик» несет ответственность в соответствии с п. 7.5. Договора-оферты, а также законодательством РФ.
      6. Предоставить Исполнителю достоверные Контактные данные (E-mail) для рассылки обязательных уведомлений, методического материала, а также других оповещений, необходимых для надлежащего исполнений условий Договора-оферты. В противном случае, Заказчик не вправе ссылаться на обстоятельства, послужившие причиной пропуска занятий или иного неоказания Услуги в полном объеме, при непредоставлении, либо при предоставлении недостоверных Контактных данных Исполнителю для информационного обмена.
      7. Обеспечивать сохранность паролей и кодов доступа к личному кабинету, предоставляемых Исполнителем и не допускать их передачу третьим лицам, в противном случае Заказчик несет ответственность в соответствии с п. 7.5. Договора-оферты и законодательством РФ.
      8. Не загружать, не публиковать, не распространять любые материалы и информацию, которая порочит третьих лиц, а также иным образом нарушает законные права (например, права на неприкосновенность частной жизни, интеллектуальные и авторские права и пр.) третьих лиц. Заказчик обязан пользоваться Сайтом и его содержимым добросовестно, не нарушая законодательство Российской Федерации, права и свободы третьих лиц, нормы морали и нравственности. Заказчик обязуется не публиковать, не размещать, не распространять любые материалы и информацию, признаваемую Исполнителем непристойной и/или порнографического характера. Заказчик обязуется не публиковать, не размещать, не распространять любые материалы и информацию, которые разжигают ненависть по отношению к группам лиц по признаку расы, социального положения, религии, пола, возраста и (или) сексуальной ориентации. Заказчик обязуется не публиковать, не размещать, не распространять любые материалы и информацию, способные ввести в заблуждение третьих лиц. Заказчик обязуется не использовать Сайт для пропаганды суицида, для загрузки, хранения и распространения информации, содержащей описание способов суицида и любое подстрекательство к его совершению; информации о наркотических и психотропных веществах, в том числе, информации о распространении наркотиков, рецепты их изготовления и советы по употреблению, а равно, указывать в приложении любым способом (в том числе, путем размещения ссылки) на место нахождения материалов, содержащих признаки такой пропаганды или указанную информацию.
      9. Заказчик обязуется не загружать или иным образом не доводить до всеобщего сведения Произведения, являющиеся информационным наполнением (содержанием) Сайта и прочие результаты интеллектуальной деятельности Исполнителя или иных лиц-правообладателей, при отсутствии явным образом выраженного письменного согласия правообладателя/Исполнителя, а равно, указывать где-либо любым способом (в том числе, путем размещения ссылки) на место нахождение таких материалов.
    2. Исполнитель обязуется:
      1. Организовать и обеспечить надлежащее оказание Услуг в соответствии с Программой курса.
      2. Предоставить Заказчику методические материалы курса в объеме, предусмотренном Исполнителем, в рамках выбранной Заказчиком Услуги. Указанный материал публикуется в личном кабинете Заказчика согласно Расписанию курса.
      3. Создать для Заказчика отдельный личный кабинет (учётную запись) и предоставить на период обучения аутентификационные данные (логин и пароль) для доступа в личный кабинет. Аутентификационные данные направляются Исполнителем на адрес электронной почты Заказчика, указанный им при регистрации на Сайте.
    3. Заказчик вправе:
      1. Обращаться к Исполнителю по всем вопросам, связанным с оказанием Услуг, а также задавать вопросы, связанные с оказанием Услуг.
      2. Получать полную и достоверную информацию об оценке своих знаний, умений и навыков, основывающейся на практическом опыте Исполнителя.
      3. Получать необходимые и предусмотренные программой Исполнителя методические материалы, согласно выбранной тематике курса.
    4. Исполнитель вправе:
      1. Самостоятельно определять формы и методы оказания Услуг, исходя из требований законодательства, а также исполнения настоящего Договора-оферты.
      2. Самостоятельно определять состав специалистов, оказывающих Услуги, и по своему усмотрению распределять между ними обязанности.
      3. Получать от Заказчика достоверную информацию, необходимую для выполнения своих обязательств по Договору-оферте.
      4. Обнародовать и безвозмездно использовать личное изображения и видео-материалы Заказчика, полученного посредством фото-, видеосъемки или иным способом, а также вправе обрабатывать, изменять, в том числе демонстрировать третьим лицам.
  5. Порядок сдачи-приема услуг
    1. Услуги по Договору-оферте считаются оказанными, а со стороны Заказчика принятыми, если со стороны последнего в 3 (трехдневный) срок с момента оказания Услуг не поступило претензии по качеству и объему оказанных Услуг. Последним днем оказания Услуг Стороны признают последний день проведения Курса согласно графику (расписанию).
    2. По факту оказания услуг Исполнитель предоставляет Заказчику в последний день проведения Курса Акт об оказании Услуг. Заказчик подписывает Акт в день предоставления его Исполнителем, либо предоставляет Исполнителю мотивированный письменный отказ от его подписания.
    3. С момента подписания Сторонами Акта Услуга считается надлежащим образом оказанной Исполнителем, а Заказчиком принятой в полном объеме и на условиях Договора-оферты.
    4. В случае необоснованного отказа в подписании Акта, а также при отсутствии письменных претензий и возражений Заказчика в течение 3 (трех) календарных дней после исполнения Договора-оферты (последний день Курса согласно графику (расписанию), Услуги считаются надлежащим образом оказанными, а Заказчиком принятыми.
  6. Стоимость услуг
    1. Цены Курсов объявлены на Сайте на страницах соответствующих Курсов и актуальны на момент акцепта.
    2. Все цены, предусмотренные в настоящем Договоре-оферте, указаны с учетом налогов и других обязательных платежей.
    3. Стоимость услуг не облагается налогом на добавленную стоимость в связи с применением упрощенной схемы налогообложения и может быть оплачена любым третьим лицом, действующим в интересах Заказчика, в том числе — юридическим лицом, индивидуальным предпринимателем, родителем или опекуном.
  7. Порядок оплаты и возврата денежных средств
    1. Оплата услуг Заказчиком в пользу Исполнителя осуществляется на основе платёжной системы Wallet One с использованием доступных способов оплаты.
    2. Возврат средств осуществляется на тот источник, с которого была произведена оплата.
  8. Ответственность сторон
    1. За неисполнение или ненадлежащее исполнение обязательств по настоящему Договору-оферте, Стороны несут ответственность в соответствии с действующим законодательством Российской Федерации.
    2. В случае невозможности исполнения Договора-оферты, возникшей по вине Заказчика, а также в случаях нарушения порядка сдачи домашнего задания в порядке п. 4.1.2. и в сроки предусмотренные настоящим Договором-офертой, стоимость Услуги не возвращается.
    3. Заказчик вправе в одностороннем порядке расторгнуть Договор-оферту по правилам п. 8.3. настоящего Договора-оферты.
    4. При полном или частичном отказе Заказчика от приобретенного по акции пакета Услуг в рамках указанной акции, – оплата, произведенная Заказчиком, возврату не подлежит равно и как отказ Заказчика от пакета Услуг (одного или нескольких курсов), приобретенных в рамках, проводимой Исполнителем акции не является основанием для возврата денежных средств Заказчику.
    5. В случае нарушения п. 4.1.5., 4.1.7. Договора-оферты, Заказчик уплачивает штраф в размере 10 000 (десять тысяч) евро, а в случае причинения убытков оплачивает понесенные Исполнителем расходы.
    6. Выплата неустойки и (или) штрафа не освобождает Стороны от выполнения обязанностей, предусмотренных Договором-офертой.
    7. Стороны освобождаются от ответственности за полное или частичное неисполнение своих обязательств по настоящему Договору-оферте, в случае если оно явилось следствием обстоятельств непреодолимой силы (форс-мажор), а именно: наводнения, пожара, землетрясения, диверсии, военных действий, блокады, изменения законодательства и др., препятствующих надлежащему исполнению обязательств по настоящему Договору-оферте, а также других чрезвычайных обстоятельств, которые возникли после заключения настоящего Договора-оферты и непосредственно повлияли на исполнение Сторонами своих обязательств, а также которые Стороны были не в состоянии предвидеть и предотвратить.
  9. Основания и порядок расторжения Договора-оферты
    1. Настоящий Договор-оферта может быть расторгнут по взаимному соглашению Сторон.
    2. По инициативе одной из Сторон Договор-оферта может быть расторгнут по основаниям, предусмотренным Договором-офертой и действующим законодательством Российской Федерации.
    3. В случае расторжения Договора-оферты по инициативе Заказчика, он обязан письменно уведомить Исполнителя не позднее, чем за 5 календарных дней до предполагаемой даты расторжения Договора-оферты.
    4. Возврат средств при расторжении Договора-оферты по инициативе Заказчика не осуществляется.
    5. Исполнитель в праве расторгнуть Договор-оферту в одностороннем порядке в случаях предусмотренные п. 4.1.5., 4.1.7. Договора-оферты. Исполнитель считается добросовестным, Услуги по Договору-оферте оказанными и стоимость Услуг не возвращается.
  10. Разрешение споров
    1. Все споры и разногласия, возникшие в процессе исполнения Договора-оферты, Стороны будут стремиться урегулировать путем переговоров.
    2. Все претензии, заявления, уведомления и иные переговоры между сторонами осуществляются в письменной форме путем направления в адрес Стороны по почте, по месту нахождения Сторон. Претензия в адрес «Исполнителя» направляется – по адресу, указанному в разделе 12 Договора-оферте, либо путем личного вручения Стороне с отметкой. Претензия в адрес «Заказчика» направляется по дополнительно согласованным Контактным данным. Срок ответа на претензию 10 (десять) календарных дней с момента ее получения.
    3. По результатам рассмотрения претензии Исполнитель вправе предпринять следующие действия:
      1. Удовлетворить претензию и принять необходимые меры для устранения недостатков, возникшие в процессе оказания Услуг.
      2. Оставить претензию без удовлетворения (в случае, если по результатам рассмотрения претензии, а также в ходе выяснения возникновения конфликтной ситуации данные Заказчика не подтвердились).
    4. При невозможности урегулирования споров путем переговоров и в претензионном порядке, Сторона чье право нарушено, вправе обратиться за защитой своих прав в судебном порядке.
    5. Подсудность по месту исполнения Договора-оферты.
  11. Прочие условия
    1. Вся информация, которая стала известна Сторонам в процессе исполнения Договора-оферты, признается Сторонами конфиденциальной, не подлежит разглашению и охраняется в соответствии законодательством РФ. С информацией, ставшей известной в ходе исполнения обязательств, предусмотренных настоящим Договором-оферты, могут быть ознакомлены только те лица, которые непосредственно связаны с исполнением обязательств по Договору-оферте.
    2. Настоящим, Заказчик, в соответствии Федеральным законом от 27 июля 2006 года N152-ФЗ “О персональных данных” свободно, своей волей и в своих интересах выражает свое согласие на обработку своих персональных данных Исполнителем в целях исполнения Договора-оферты, такие как: сбор, систематизацию, накопление, хранение, уточнение (обновление, изменение), использование, распространение (в том числе передачу), обезличивание, блокирование, уничтожение персональных данных. Стороны договорились считать согласием Заказчика на обработку следующих персональных данных: фамилии, имени, отчества; даты рождения; почтовых адресов (по месту регистрации и для контактов); сведений о гражданстве; номере основного документа, удостоверяющего личность Заказчика, сведений о дате выдачи указанного документа и выдавшем его органе; номерах телефонов; номерах факсов; адресах электронной почты (E-mail), а также иная информация, полученная Исполнителем от Заказчика.
    3. Согласие Заказчика считается полученным с момента акцепта Договора-оферты. Указанное в настоящем пункте согласие действует бессрочно.
    4. Одновременно с вышеуказанным согласием на обработку персональных данных Заказчик также дает свое полное согласие на получение сообщений от Исполнителя посредством электронной почты, в том числе сообщений рекламного содержания.
    5. В случае направления Исполнителю заявки, Заказчик может получить экземпляр Договора-оферты на бумажном носителе с подписью уполномоченного лица и печатью.
  12. Адреса и реквизиты сторон

Исполнитель:

ИП Алексеев Валерий Альбертович
Тел.: +7-499-899-57-79
E-mail: [email protected]
ИНН: 332134318318
ОГРИП: 316332800075500
Свидетельство о регистрации: 33 002060713
Дата регистрации: 23.05.2020
Р. счет: 40802810501500000322
К.счет: 30101810845250000999
БИК: 044525999
Банк: ТОЧКА ПАО БАНКА “ФК ОТКРЫТИЕ”

Топ-пост этого месяца:  Фреймворк Yii2. Оформление вывода статей. Компонент Yii2 View. Пагинация
Добавить комментарий