Как составить тз на разработку сайта

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

Как составить тз на разработку сайта

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

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

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

Для чего нужно техническое задание

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

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

  1. Абсолютно неинформативны.
  2. Могут трактоваться по-разному.

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

Подробное ТЗ с объяснением каждой детали не оставит места для субъективной оценки.

  • Экономит время и бюджет. Этот пункт вытекает из предыдущего — постоянные правки отнимают драгоценное время, а иногда требуют доплаты, если задача описана в общих чертах и может трактоваться по-разному.
  • Даёт эффективный результат. Работа над техническим заданием позволяет увидеть задачу со стороны и лучше понять её. Это понимание, в свою очередь, позволяет чётче определить необходимую функциональность.
  • Гарантирует результат. Если согласованное ТЗ конкретно и объективно описывает задачу, исполнитель обязан следовать ему и любые несоответствия корректировать бесплатно.

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

Кто составляет техническое задание

Фактически ТЗ на разработку сайта может составляться был человеком, но вот качество готового документа в таком случае остаётся под вопросом. Будет лучше, если за дело возьмётся опытный человек — например, проект-менеджер: так вы не только получите задание, но и сможете проверить компетентность разработчика.

Если задание путанное, наполнено туманными объяснениями с минимальной конкретикой, это повод задуматься о профессионализме выбранной компании. Это спасёт вас от бесперспективного сотрудничества.

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

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

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

Формат и структура технического задания

Формат и структура ТЗ на разработку сайта могут варьироваться, но есть несколько общих правил оформления. Им стоит следовать — это упрощает и написание, и трактование, и, в последующем, разработку сайта.

Формат технического задания

Документ может создаваться в любом текстовом редакторе. Наиболее популярными являются Microsoft Word и Google Docs. Особенно удобно работать во втором сервисе — доступ к просмотру и редактированию осуществляется по ссылке, поэтому можно в любой момент создать примечание или внести правку.

Из общих правил оформления можно выделить:

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

В любом случае главное — удобство для обеих сторон.

Структура и объём технического задания

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

  1. Введение. В вводной разделе содержится основная информация о сайте и его назначении: заказчик знакомиться исполнителя с проектом.
  2. Назначение. Здесь стоит описать задачи, которые должен выполнять сайт: корпоративный — рассказывать о компании, лендинг — увеличивать конверсии, интернет-магазин — продавать. На первый взгляд кажется, что этот пункт очевиден и не требует отдельного раздела, но это не так.
  3. Структура. Здесь указывается количество разделов и название каждого из них, дополнительно — короткое описание.
  4. разделов и страниц. Большая часть ТЗ отводится под подробное описание каждой страницы будущего сайта.
  5. Технические требования. В этой части нужно рассказать, как должна работать готовая площадка: будет ли у неё версия под мобильные устройства, под какие браузеры она создаётся и так далее.
  6. Сценарии использования — кто, как и зачем будет заходить на сайт.
  7. Контент. Этот пункт носит опциональный характер: можно уточнить, кто и когда будет заниматься наполнением страниц, но это не обязательно.
  8. Условия. Это завершающий раздел, в котором указываются сроки подготовки и сдачи проекта, в том числе время, выделенное на каждый этап.

Есть ли специальные требования для написания ТЗ

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

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

— Нет: “Сайт работает быстро”.

— Да: “Страница загружается за n-секунд при стабильном подключении к сети”.

Второй совет. Отдавайте предпочтение развёрнутым описаниям.

— Нет: “Поиск должен быть удобным”.

— Да: “Поиск по сайту должен содержать n-фильтров и сортировку выдачи по n-критериям”.

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

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

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

Пример технического задания

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

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

Пример: Техническое задание на разработку сайта интернет-магазина косметики.

1. ВВЕДЕНИЕ

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

2. НАЗНАЧЕНИЕ

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

3. СТРУКТУРА И ОПИСАНИЕ

На сайте будет 9 разделов:

  • страница;
  • О магазине;
  • Каталог (подразделы: тональная основа, пудра, тушь для ресниц, тени для век, помады, румяна, кисти);
  • Карточка товара;
  • Корзина;
  • Оформление заказа;
  • Доставка и оплата;
  • Блог.
  • Карточка блога.

3.1. страница:

  • Шапка сайта с названием компании и логотипом бренда;
  • Контентный блок для описания акций;
  • Карта сайта;
  • Корзина;
  • Блоки разделов (Распродажа, Новая коллекция, Для веганов, Гипоаллергенно);
  • Партнёры;
  • Социальные сети;
  • Копирайт, контактные данные.

3.2 Общее оформление разделов:

  • Шапка;
  • Корзина;
  • Поиск по сайту, фильтры и сортировка;
  • Копирайт, контактные данные.

4. РАЗДЕЛЫ И СТРАНИЦЫ

4.1 страница:

Шапка главной страницы — обложка с продукцией бренда, название и логотип. Карта сайта расположена под шапкой в одну строку. Ниже:

  • Строка поиска;
  • Корзина;
  • Фильтры поиска и сортировка;
  • Блок с акциями, текст на фоне изображения;
  • Блок с новыми коллекциями, текст на фоне изображения;
  • Блок этичной косметики с кнопкой “перейти” для перехода в раздел;
  • Блок с гипоаллергенной косметикой с кнопкой “перейти” для перехода в раздел;
  • Графические блоки с логотипами партнёров;
  • Логотипы с ссылками на социальные сети;
  • Нижняя панель с копирайтом (слева) и контактными данными (справа).

4.2 О магазине:

Страница оформляется по типовому шаблону: шапка и текстовый блок с описанием компании.

4.3 Каталог:

  • Строка поиска;
  • Корзина;
  • Фильтры поиска и сортировка;
  • Блок этичной косметики с кнопкой “перейти” для перехода в раздел;
  • Блок с гипоаллергенной косметикой с кнопкой “перейти” для перехода в раздел;
  • Блоки для каждого подраздела;
  • Логотипы с ссылками на социальные сети;
  • Нижняя панель с копирайтом (слева) и контактными данными (справа).

4.5 Подраздел:

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

  • Строка поиска;
  • Корзина;
  • Фильтры поиска и сортировка;
  • Позиции;
  • Список страниц с возможностью вернуться на первую и перейти на последнюю;
  • Логотипы с ссылками на социальные сети;
  • Нижняя панель с копирайтом (слева) и контактными данными (справа).

4.6 Карточка товара:

  • Строка поиска;
  • Корзина;
  • Фильтры поиска и сортировка;
  • Изображение товара слева;
  • Краткое описание справа;
  • Выбор модели;
  • Характеристики;
  • Логотипы с ссылками на социальные сети;
  • Нижняя панель с копирайтом (слева) и контактными данными (справа).

5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

Перечень технических требований:

  1. Корректное отображение в Google Chrome, Safari;
  2. Оптимизированная мобильная версия;
  3. Мета-теги для продвижения в Google и Yandex;
  4. Базовое разрешение десктопной версии 1024×768.

6. СЦЕНАРИИ

Сайт будет использоваться:

  1. Для продаж;
  2. Для изучения ассортимента и составления списка желаний;
  3. Для получения информации о продукции бренда.

7. КОНТЕНТ

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

8. УСЛОВИЯ

Общий срок создания интернет-магазина составляет 60 дней. Из них:

  1. 20 — создание макетов и шаблонов;
  2. 30 — программирование и вёрстка;
  3. 10 — создание контента.

8.1 Этапы создания сайта:

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

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

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

Источник: https://waytostart.ru/blog/technical-task

Как создать ТЗ на разработку сайта

Как составить тз на разработку сайта

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

К примеру, у клиента в голове появилось определенное представление, каким бы он хотел видеть сайт, и пытается объяснить это разработчикам. Но разработчики неверно трактовали «на пальцах» пожелания. Плачевный итог – клиент получил совсем не то, что представлял себе. Силы, время исполнителей и клиента были потрачены зря.

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

Что такое техническое задание

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

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

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

  • Рассказать подробнее о компании, предлагаемых товарах или услугах, целевой аудитории;
  • Уточнить о проблемах, с которыми целевая аудитория (ЦА) будет приходить к клиенту и их решения;
  • Узнать, что именно клиент хочет получить от сайта;
  • Попросить привести примеры удачных сайтов конкурентов.

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

Чёткость формулировок в ТЗ

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

Главный критерий качества ТЗ — чёткие формулировки, отсутствие двусмысленных трактовок.

Конкретика в техническом задании — главное условие качества, например:

  • Каждая страница должна провериться на GTmetrix или GoogleSpeed с показателем скорости не менее 80/100 по Google Page Speed.
  • Ресурс должен выдерживать до 20 тыс. посетителей одновременно.
  • На главной должны выводиться новости и ниже отображаться форма с кнопкой «Подписаться» с возможностью отправить e-mail адрес.
  • Список партнеров в виде карусели логотипов, отзывы клиентов в слайдере с горизонтальной прокруткой по 1-му отзыву на слайд.

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

Структура технического задания

Структура сайта – фундамент. Решите, какие страницы необходимо создать и продумайте навигацию на них. По нашему опыту клиент проще воспринимает блок-схему, нарисованную в XMind.

Но если вы считаете, что работа в XMind займет слишком много времени, то просто перечислите секции в word файле.

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

Пример структуры ТЗ по договору

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

Страница «»

  • Секция «Меню» с разделами и выпадающим списком подразделов:
    • Логотип и слоган;
    • «»;
    • «Проекты»;
    • «Каталог продукции» с выпадающим списком разделов «Трубы SML», «Фитинги SML», «Соединительные хомуты»;
    • «Производство»;
    • «О компании»;
    • «Проектировщикам»
    • «База знаний / FAQ»;
    • «Контакты»;
    • Ссылка на скачивание катала продукции в .pdf;
    • Контактный телефон компании;
    • Кнопка «».
  • Секция «Слайдер» с фотографией по ширине экрана и кнопкой обратной связи с запросом на просчёт проекта / запроса на полный прайс-лист продукции.
  • Секция «Преимущества» с указанием ключевых выгод для клиентов;
  • Секция «Производство» с кратким описанием и информацией про систему контроля качества, со ссылкой на раздел «Производство» и кнопкой с записью на поездку на завод;
  • Секция «Продукция» с текстовым описанием преимуществ, ссылками на сертификаты, ссылкой на «Каталог продукции»;
  • Секция «Наши проекты» (с переходом в раздел «Все проекты»);
  • Секция «Компания в цифрах» с цифрами достижений и ссылкой на раздел «О компании»;
  • Секция «-инструкции» с текстовым описанием и ссылкой в раздел «Все видео»;
  • Секция «Подвал»:
  • Контакты, телефон, адрес, электронная почта;
  • Кнопка обратной связи;
  • Ссылка на канал и на социальные сети компании.

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

Функционал сайта

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

  • CMS система Вордпресс, Битрикс и тп.
  • Формы заявок с возможностью оставить заявку
  • Модальные окна
  • Слайдеры
  • Модули галереи
  • Модули SEO оптимизации и страниц
  • Модули кеширования и сжатия
  • Онлайн-карта с гео-метками
  • Онлайн-калькулятор с расчетом цены

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

Подключение и настройка CMS системы 1С БитриксИсполнитель настраивает CMS систему управления сайтом 1С Битрикс. Лицензия «1С-Битрикс: Управление сайтом» оплачивается Заказчиком самостоятельно.
Наполнение контентомНаполнение текстом и фотографиями указанных выше страниц. Текст и фотографии предоставляет Заказчик. Исполнитель в праве использовать также контент с сайта заказчика. Расположение блоков на страницах выводится в рамках структуры страниц шаблона.
Настройка ролей доступаДобавление роли «Администратор» с возможностью администрирования CMS, роли редактора (для отдела закупок) с возможностью добавления информации.
Адаптация для мобильных устройств и планшетовШирокоэкранная верстка и адаптация под более мелкие разрешения экрана, сайт должен корректно отображаться на экранах шириной от 1920 до 320 пикселей, появление горизонтальной прокрутки недопустимо.
Подключение дополнительных модулей CMSИсполнитель также вправе добавлять модули CMS и функциональные элементы на своё усмотрение, если они улучшают работоспособность сайта по согласованию с Заказчиком, платные модули оплачиваются Заказчиком.
Подключение домена и хостинга ЗаказчикаИсполнитель подключает домен и хостинг Заказчика для веб-сайта. Производится парковка домена с указанием адресов ns1, ns2. Включается версия PHP не ниже 7.0.
Настройка базы данных MySQLИсполнитель создает базу данных MySQL на хостинге заказчика для размещения данных веб-сайта. Доступы к базе данных передаются Исполнителем Заказчику по электронной почте.
фон на главной страницеВывод подложки с видеорядом Заказчика в первом блоке главной страницы сайта. Должна присутствовать затемняющая подложка для повышения читабельности текста.
Вывод модальных окон и отправка данныхКаждая из кнопок должна вызывать соответствующее модальное окно с формой обратной связи. Данные с формы в корректном виде должны отправляться на почту Заказчика.
Вывод форм обратной связиФорма обратной связи должна выводиться на каждой странице. В форме обратной связи должны присутствовать: форма поля ввода номера телефона и кнопка «отправить заявку». Данные с формы должны передаваться на электронный адрес администратора, а также дублироваться на адрес info@domen.ru.
Подключение Яндекс карты c ГЕО-меткамиНа страницах выводится Яндекс.Карта с ГЕО меткой расположения / адреса Заказчика. Заказчик устанавливает метку на собственном аккаунте Яндекс.
Подключение статистики Яндекс.МетрикаСервис сбора данных о посещаемости и поведении пользователей. Заказчик предоставляет Яндекс почту, на которую Исполнитель подключает сервис.
Настройка целей в Яндекс.МетрикаИсполнитель настраивает цели в Яндекс.Метрика. Цели сообщают в статистике о том, с какой конкретно формы была отправлена заявка.
Вывод H1 и МЕТА-описаний страниц согласно ключевому запросу веб-страницыКаждая страница веб-сайта должна иметь заголовок и МЕТА-описание в соответствии с содержимым страницы.
Кроссбраузерная оптимизация сайтаСайт должен корректно открываться в последних актуальных версиях существующих браузеров.
Настройка файлов sitemap.xmlИсполнитель выводит карту сайта в отдельный раздел sitemap.xml с указанием существующих страниц для индексации.
Добавление «хлебных крошек»Исполнитель выводит в каждый раздел навигационную цепочку («хлебные крошки», англ. Breadcrumbs) с адресом страницы формата: → Раздел → Подраздел → Текущая страница.
Настройка файла robots.txtИсполнитель настраивает текстовый файл, который содержит параметры индексирования сайта для роботов поисковых систем.
Настройка файла .htaccessИсполнитель настраивает специальный файл, позволяющий редактировать конфигурации и настройки веб-сервера.
Настройка ЧПУ адресов страниц в формате domen.ru/arenda-skladaАдрес каждой страницы должен содержать корректное описание для поисковых систем и посетителей на латинице.
Настройка 404 и 303 страницНастройка корректной выдачи ошибки 404, настройка 303 переадресации на страницы, которые изменили свой адрес.
Оптимизация программного кода HTML/CSS/PHP и скриптовИсполнитель выполняет оптимизацию программного кода страниц сайта для повышения скорости загрузки страниц и веб-сайта в целом. При необходимости Исполнитель переносит загрузку .js скриптов в «подвал» сайта, настраивает кеширование страниц и сжатие CSS / HTML.
Оптимизация размера изображений и графического контентаИсполнитель сжимает изображения и видео, размещаемые на страницах веб-сайта для повышения скорости загрузки страниц ресурса.
Тестирование и поддержка в течение 1-го месяца после запускаПосле приемки и запуска веб-сайта Исполнитель оказывает услуги по технической поддержке, устраняет технические ошибки и корректирует работу сайта при необходимости.

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

Скачать шаблон ТЗ

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

Помните, что сайт — это техническое и программное обрамление контента. Если контент (фото и видео) не очень, то и сайт будет таким же.

Отдельно стоит уделить внимание качеству фото и видео. Мы всегда рекомендуем заказать фото и видео съёмку клиентам, если нет презентабельного фото и видео контента для сайта.

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

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

Если у вас будут неказистые фото, то красивые кнопочки не помогут.

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

Техническое задание на сайт

Как составить тз на разработку сайта

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям.

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

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

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

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

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

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

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

Стоимость diff — это стоимость изначально неоговоренных доработок, стоимость ТЗ — это, собственно, стоимость ТЗ. Чем более подробное и детализированное техническое задание, тем выше его стоимость, но тем меньше величина и стоимость diff-а, и наоборот. Если рассматривать две крайности, когда тех. задания просто нет, нет совсем, т.е.

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

до строк кода, переменных и стилей css. В этом случае diff равен нулю, а стоимость ТЗ равна стоимости проекта (т.к. ТЗ уже является реализацией). А между этими крайностями находится реальность, которая отражена на этом графике: Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации. Голубой линией отмечена суммарная стоимость ТЗ и переделок, предстоящих по окончании работы. Как видно из графика, у этой суммарной стоимости есть минимальное значение. Т.е. с некоторой точки становится дешевле исправить в конце работы хотелки заказчика, чем доводить до совершенства ТЗ.

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

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

2. Что в нем должно быть и чего нет. Формулировки

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

Исходя из этого получается, что в техническом задании не должно быть речи о дизайне. Да и вообще, задание техническое, а не художественное. Дизайн не поддается объективной оценке, что одному нравится, другому — нет, и не существует объективных критериев, по которым можно сказать, хороший дизайн или нет. Реализация дизайна с формулировкой задачи «в зеленых тонах, и что бы дерево», может быть как плохой работой, так и шедевром (и что особо печально, оба варианта могут не нравиться заказчику). Короче говоря, выполнение объективных критериев описывающих дизайн может приводить к плохому результату. Вообще, ТЗ надо писать так, как будто вы с заказчиком не сошлись во мнениях и ваш спор будут разбирать в суде, основываясь на тексте тех. задания. А у вас в ТЗ написано «сделать дизайн, который понравится заказчику». Судья спрашивает: «Заказчик, Вам нравится дизайн?». Заказчик: «Нет, Ваша честь!». Судья: «Исполнитель, присуждаю — 2 года уборки снега в Сибири за невыполнение условий ТЗ!». Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы. В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно». «Всё, что не оговорено, выполняется на усмотрение исполнителя» — не смотря на суровость этого заявления, эта фраза должна присутствовать в ТЗ. Она проистекает из самой сути задания: заказчик хочет получить некий продукт, но он не может и не должен указывать каким образом будет достигнут конечный результат. Этот пункт защищает от вмешательства в глубины работы (не хватало, чтоб заказчик начал рассказывать, как именовать функции в коде и какие пакеты использовать), но также перечеркивает возможность заказчика иметь любые хотелки. На мой взгляд, стоит идти на встречу заказчику в хотелках, пока это не выходит за рамки приличия. Когда же терпение лопается, нам и пригодится этот пункт. Как в песне поется: «Мы мирные люди, но наш бронепоезд стоит на запасном пути». (Фразу «что не оговорено — на усмотрение исполнителя», лучше всунуть под конец ТЗ, в начале она может быть встречена в штыки. Но если ТЗ нормальное и в конце стоит эта фраза, против неё не будут протестовать). Тех. задание — это документ, который нам дает заказчик (Не важно, что его пишем мы. По смыслу это задание, техническое задание, а задание дает заказчик исполнителю, т.е. нам). А из этого следует, что в ТЗ должны быть формулировки, которые указывают нам, что делать (типа «сайт должен содержать», «должна быть возможность»). В некоторых ТЗ я видел, формулировки вида «на сайте будет то-то и то-то» — это неверная формулировка, это какое-то уведомление заказчика, что будет сделано, но документ-то называется «задание», а не «уведомление».

3.1 Общие слова

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

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

3.2 Эксплуатационное. назначение

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

Остановимся на шаг раньше, непосредственно перед «подзаработать деньжат».

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

3.3 Функциональное назначение

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

Например, для интернет магазина это каталог товаров, корзина заказа, страницы с информацией о доставке, возврате и о компании.

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

3.4 Термины и определения

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

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

Например, заказчик говорит: «Сеанс работы с сайтом стоит 100 тугриков». Фраза «сеанс работы с сайтом» — претендент на описание. Этот термин может означать продолжительность времени от входа на сайт до выхода, или же период работы пока на счету пользователя не закончатся деньги. Т.е. нам нужно точно знать, что такое «Сеанс работы».

Ошибочное понимание такого простого термина может создать реальную проблему.

3.5 Данные и списки

Ключевой раздел ТЗ. Можно сказать его сердце. Это не самый многословный, но самый важный и трудный пункт ТЗ. Если он сделан как надо, можно быть уверенным, что автор задания понимает, что именно нужно сделать. Наличие этого пункта накладывает очень сильные ограничения на создаваемый продукт. Один только этот пункт, думаю, «весит» больше половины всего ТЗ.

Данные

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

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

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

Для примера, та же самая новость:

  • Заголовок
  • Текст
  • Дата публикации

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

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

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

Списки

Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей. Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список.

А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи. Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра.

И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е.

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

3.6 Страницы с описанием

Источник: https://habr.com/ru/post/138749/

Финансист тут
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: