Руководства, Инструкции, Бланки

тех задание сайта образец img-1

тех задание сайта образец

Категория: Бланки/Образцы

Описание

Пример тех задания (сайт)

/ Пример тех задания (сайт)

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

1. Общие сведения. Состав продукта

IT-инфраструктура поддержки дистанционного образования должна включать в себя Web-портал (Web-сайт), организованный с применением облачного хостинга ISPserver и систему управления контентом (CMS) Joomla 1.5.

Минимальные системные требования Joomla 1.5:

Apache 1.3.x или новее;

MySQL 3.23.x или новее, но не 6.x;

PHP 4.3.10 или новее, рекомендуется 4.4.7 (Для Joomla! 1.5.x).

Административная часть сайта представляет собой систему управления контентом разделов пользовательской части сайта, а также является инструментом для создания обучающих объектов, формирования Курсов, контроля лицевых счетов клиентов и их учётных записей. Рабочие места администраторов Системы Дистанционного Обучения (Далее СДО или Система) представляют собой инструментальные панели, вход на которые защищёны логинами и паролями.

2. Назначение и цели создания (развития) системы

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

3. Характеристика объектов автоматизации

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

Система Дистанционного Обучения предусматривает следующий механизм взаимодействия участников.

Администраторы системы делятся на три категории:

Преподаватель (автор предмета, курса)

Действия Администратора системы

В задачи Администратора Системы входит Управление ресурсами, Управление клиентами, Управление Кураторами, Управление преподавателями.

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

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

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

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

Обучающие объекты реализуются в следующих вариантах:

Электронные учебники (книги)

Клиентами системы являются:

Обучающиеся других образовательных учреждений;

Действия клиента Студент

Регистрация клиентов осуществляется путём заполнения соответствующей регистрационной формы on-line. После заполнения регистрационной формы, данные отправляются на WEB-сервер, где специальная программа, отвечающая за регистрацию. производит проверку правильности заполнения полей. В случае обнаружения ошибки в заполнении, клиенту предлагается повторно заполнить поля с некорректными данными. Проверенные данные, не содержащие ошибок, сохраняются в базе данных для последующего использования. В регистрационной форме предусмотрено обязательное для заполнения поле для ввода адреса электронной почты. После успешного сохранения данных, полученных в результате регистрации, на электронный адрес клиента, указанный при регистрации, высылается текст, содержащий ссылку на страницу подтверждения регистрации. Это делается для того, чтобы защитить систему от автоматической регистрации несуществующих клиентов. После подтверждения регистрации, клиенту высылается электронное письмо, с параметрами доступа (Логин и Пароль, URL контрольной панели) к обучающим объектам Системы и личной панели управления (личный кабинет, персональная страница). Для входа на личную страницу, клиенту необходимо пройти процедуру авторизации. то есть ввести Логин и Пароль. Клиент получает доступ к обучаемым объектам в режиме on-line для самостоятельного изучения.

Клиент Гость – это незарегистрированный пользователь системы.

4. Требования к системе

Реализация информационных задач:

раздел с информацией о филиале, кафедрах;

раздел Преподавателю (с сервисами для преподавателей);

раздел Студенту (с сервисами для студентов);

раздел Графики и расписания;

раздел Дистанционное обучение.

Реализация дополнительных сервисов:

доступ к файлам с иерархической структурой.

5. Состав и содержание работ по созданию системы

В состав работ по созданию Web-ресурса дистанционного обучения входят:

техническая реализация сервисов;

тестирование и отладка;

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

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

6. Порядок контроля и приемки системы

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

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

Другие статьи

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

Техническое задание на верстку

Автор: Евгений Рыжков Дата публикации: 06.01.2013

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

  • затянутые сроки;
  • неоплаченные часы работы верстальщику (обычно за подобные "мелочи" не считают необходимым доплачивать);
  • испорченные отношения с клиентом (споры почти неизбежны).

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

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

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

Платформы. Windows, MacOs.

Браузеры. IE7-9, Chrome (15+), Firefox (15+), Opera (12+), Safari 5 – верстка полностью соответствует дизайну, скрипты работают в соответствии с ТЗ. В IE7-8, могут быть незначительные упрощения, скрипты, связанные с анимацией, могут работать в упрощенном виде.

Стандарты. HTML5/CSS3. HTML - должен проходить валидацию. CSS - не обязательно.

  • используется фреймворк jQuery 1.7.2.
  • для определения поддержки HTML5 используется Modernizr .

Соответствие макету. при накладке допустимы незначительные различия.

Ширина сайта. статична, сайт выровнен по центру. При 1024px должна отсутствовать горизонтальная прокрутка.

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

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

Масштабирование страниц. страницы при масштабировании страницы в диапазоне 70-150% в браузерах IE9, Chrome 15+, Opera 12+, Safari 5, FF15+ должны выглядеть так же как и при 100%. Допускаются не большие погрешности, которые возникают из-за неправильных округлений координат браузеров.
Масштаб в IE7-8 не проверяется.

  • Кодировка – utf-8
  • Структурный, комментируемый код (обозначается начало/конец крупных блоков). Отбивка табами.
  • Семантическая разметка на уровне грамотного использования тегов.
  • Имена классов и идентификаторов – осмысленные, на наше усмотрение.
  • Классы служат для привязки оформления, идентификаторы – скриптов.
  • Структурный, отбивка табами.
  • Комментариями обозначены начало/конец крупных модулей/блоков разметки.
  • Допускается использование вендорных префиксов.
  • Стили для IE7-8 вынесены в отдельные CSS.
  • Для IE7-8 для реализации не поддерживаемых CSS свойство допустимо использование Javascript и expression.
  • Структурный, отбивка табами.
  • Имена переменных осмысленные, на наше усмотрение.
  • Снабжен комментариями: описаны назначения
    • методов/классов
    • функций
    • условий.
  • Для объемных задач используется ООП, для простых – обычные функции.
  • Код должен быть без ошибок.
  • При использовании Ajax и не предоставления заказчиком api для взаимодействия с серверной частью, api делаем на свое усмотрение.

Изображения :
Имена файлов осмысленные, на наше усмотрение.
Проходят базовую оптимизацию на уровне оптимизации для Веб в Photoshop.
Малые изображения оформления объединенные по назначению и склеиваются в спрайты .

Файловая организация :
HTML файлы лежат в корне. Главная страница – index.html. Остальные – по именам макетов.
Стили в папке /css/
Javascript - /js/
Изображения оформления - /img/
Изображения содержания - /pic/

Дополнительные требования

(отмечаем плюсиками, что необходимо)

Платформы/браузеры Ошибки и доработки

ошибка – не соответствие верстки дизайну (кроме заранее оговоренных отличий) и /или ошибки в работе указанного в ТЗ функционала хотя бы на одной/ом из утвержденных платформах/браузерах.

Ошибки устраняются без доплат. Исключением является поиск ошибок после привязки к серверной части, если они появились при некорректной интеграции верстки и/или самостоятельных внесений изменений в html/css/javascript.

Доработка – изменение дизайна и/или изменение в функциональности и/или api работы front end.

Доработки оговариваются отдельно и не входят в первоначальную оценку работ.

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

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

  • верстка
    • город –выпадающий список ссылок. Оформляем на свое усмотрение (городов
    15).
  • Тянется как левая так и центральная колонка сайта
  • Предусмотреть вид пустой корзины: КОРЗИНА В ШАПКЕ ДОЛЖНА ВЫГЛЯДЕТЬ ТАК ЖЕ, ТОЛЬКО ВМЕСТО КОЛИЧЕСТВА И СТОИМОСТИ ДОЛЖНО БЫТЬ НАПИСАНО "КОРЗИНА ПУСТА"
  • Рядом с полем поиска кастомизированный выпадающий список (cusel или jquery ui)
  • В index8 показан вид шапки залогиненного пользователя
  • В верхнем меню отличающийся пункт – это hover
  • Может быть выпадающее подменю. Пример одного в index3
  • В левой колонке “каталог” – просто текст. Иконки рядом с ним - ссылки
  • В левом меню верхний уровень каталога не является ссылкой. Клик по нему – раскрывается под меню.
  • Синим подменю окрашивается при раскрытии. В один момент может быть раскрыт только один пункт меню.
  • При резиновости баннер-слайдер остается статичным, тянутся рядом находящиеся табы “новости/ Акции”
  • При резиновости в слайдерах ниже становится видно большее к-во пунктов. Сами пункты статичны по ширине.
  • в блоках "Новинки/Хиты продаж" как быть когда название товара и/или его описание длиннее, чем на одну строку - просто обрезать
  • кнопка “в корзину” и + - цельная картинка-кнопка.
  • Предусмотреть чтобы 6-ная цена влезла в блок. При необходимости уменьшить шрифт
  • Фото центрируются по вертикали и горизонтали
  • Меню после слайдеров резиновое по высоте
  • Скрипты
    • Кастомизированные выпадающие списки городов и в поле поиска
    • Аккордеон в левом меню
    • Кастомизированные скролы для “Новости/Акции”. Программист выводит сколько угодно анонсов. Учет переинициализации при изменении ширины окна.
    • Горизонтальные скролы для товаров. Учет переинициализации при изменении размера окна.
    • Слайдер для баннера
  • Этот пример не претендует на полноту. Чем крупнее, ответственнее проект, тем детальней должно быть техническое задание. Например, я в этом примере не перечислил версии Windows и MacOs, а это может стать большой головной болью.

    Подобное ТЗ имеет еще пару полезных плюсов:

    • так вы дополнительно демонстрируете клиенту, что профи в своем деле;
    • в таком форме клиент наглядно видит реальный объем работ и откуда взялся такой большой бюджет;
    • информируете клиента о дополнительных своих возможностях/услугах (например, большинство заказчиков не знают, что сайт можно "разгонять" и что сделать сайт и сделать сайт быстрым - это зачастую задачи разного уровня сложности).

    Учимся писать грамотное техническое задание (ТЗ) на разработку баннера

    Учимся писать грамотное техническое задание (ТЗ) на разработку баннера

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

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

    Как писать ТЗ для разработчика банеров:

    1. Тип баннера.
    В самом начале важно определить, какой тип баннера вам нужен. Возможные варианты: анимированный flash. анимированный gif. статический gif или jpg. нестандартный rich-баннер (всплывающий посреди страницы). Если вы не уверены, какой формат должен быть у вашего баннера, напишите, что формат определяет дизайнер согласно сценарию.

    2. Размеры баннера.
    Если вы уже знаете, на каком сайте будете размещать свой баннер, пишите размер, который принимают на этом сайте. При размещении через посредника (будь то рекламное агентство, нанятый seo-специалист или сайт-посредник типа Rotaban.ru ) уточните у него, баннеры какого размера чаще всего размещают, какие выгодно размещать по соотношению цена/качество. Например, на блогах под управлением WordPress чаще всего незаполненными бывают баннерные места размером 125×125 пикселей, потому такие баннеры владельцы сайтов часто размещают с существенной скидкой .

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

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

    3. Вес баннера.
    Вес или размер баннера в Кб – достаточно важный параметр. В некоторых банерообменным сетях существуют ограничения на размер баннера, потому особо сложных или неоптимизированных flash-монстров не принимают. Нормальным считается вес баннера до 100 КБ, но лучше, чтобы он не превышал 40 Кб.

    4. Пожелания по цвету, логотип, корпоративный стиль.
    В техническом задании на разработку баннера важно описывать, какие цвета нужно использовать при создании баннера. В ваших же интересах выслать разработчику лого своей компании, желательно, в векторном виде (в кривых), т.е. расширения файла должно быть .ai. .cdr или .eps. Если у вас есть брендбук, элементы фирменного стиля и вы хотите, чтобы эта информация использовалась при создании вашего баннера, не стесняйтесь, отправьте разработчику эти файлы. Лучше пусть информации будет много и дизайнеру будет из чего выбирать, чем он будет угадывать, чего вы от него ждете. Не факт, что угадает.

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

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

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

    6. Примеры баннеров, которые вам нравятся.
    Можете вложить в письмо баннеры, которые вам делали раньше и которые вам нравятся. Напишите, что именно вам в них нравится, а что не нравится. Можете дать ссылки на сайты, где размещены примеры отличных, на ваш взгляд, баннеров. Хорошим решением будет фраза «хочу баннер, похожий на тот, который выложен у вас в портфолио для компании ХХХ, но со следующими изменениями…» .

    7. Дополнительные материалы, которые могут помочь в изготовлении сайта.
    Если есть качественные фотографии продукции вашей компании, есть ссылка на красивую графику, которую вы бы хотели видеть на вашем баннере – не ленитесь, шлите это дизайнеру. Чем меньше он будет рыскать по фотобанкам в поисках фотографий компрессионных фитингов, которые вы успешно продаете, тем больше времени потратит на работу над анимацией или меньше денег потребует за создание баннера.

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

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

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

    В раскрутке блога сегодня помогают:
    Грамотная раскрутка сайта в поисковиках. Курсы и семинары seo в Украине.

    Образец тз на разработку сайта

    Тз на разработку сайта пример

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ну и в окончании следует описать те условия, после которых должна наступить расплата с исполнителем.

    Ниже расположен типовой образец и бланк примера тз на разработку сайта, вариант которого можно скачать бесплатно.

    Техническое задание на разработку сайта – что это?

    Создание собственного интернет-магазина – начинаем с техзадания

    — Через три месяца работы над проектом мы поняли, что работаем согласно четкому, грамотно спланированному ХЗ

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

    Хорошее техническое задание — важнейшая составляющая успеха в проекте.

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

    Статья адресована менеджерам проектов как со стороны заказчика, так и разработчика.

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

    Попробуем систематизировать и разобраться.

    Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей.

    1 Как, когда и что.

    Каким вообще должно быть техническое задание

    — А ТЗ есть?

    — Конечно, там я сканы обсуждений выложил

    ТЗ — своеобразный миф веб-разработки. Все говорят о ТЗ, многие его пишут, разработчики любят когда оно есть и ругаются когда оно плохое. Иногда кажется что этот намозоливший в сетевой папке глаза документ типа «Final-TZ-version14.4_pravlennoe_i_podpisannoe.pdf» — залог успеха в проекте. ТЗ — основа порядка, но не панацея.

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

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

    Помните: вы как автор ТЗ всегда должны адаптировать стиль написания под конкретные условия. ТЗ вы пишете не только для себя и ваши персональные вкусы не имеют права быть определяющим фактором.

    Думайте головой и пишите для других.

    Предмет ТЗ. Что вы поручаете разработчику?

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

    И цель проекта — продажи, прибыль, бизнес.

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

    Допустим, вы заказываете разработку сайта для интернет-магазина. Что вы хотите на выходе? Продажи!

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

    От чего зависит посещаемость?

    От качества сайта, доступности сервера, скорости открытия, индексации, карты сайта и прочего.

    А главное — от рекламы.

    А от чего зависит конверсия?

    Конверсия зависит от качества Интернет-магазина.

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

    При создании магазина можно идти двумя путями:

    1. Скопировать успешное. Например, вот так мы сделали магазин одежды. очень похожий на один магазин компьютеров. Ничего не украли, но все принципиальные решения были «как там». Получилось успешно и с минимумом сомнений.
    2. Закопаться в самую глубь задачи и решить ее творчески. Так мы делали интернет-магазин масел для компании Shell. Изначально мы думали что все будет как всегда: каталог, поиск, корзина. Но когда мы поняли что масел тысячи, а моделей автомобилей десятки тысяч, пришлось сделать совершенно необычную штуку для подбора. Рисков больше, сомнений больше, но интересно. Получилось тоже здорово, этот магазин готовится к тиражированию на всю страну, аналог уже делаем для Хабаровского дистрибьютора.

    Оба пути правильные.

    Но ради чистоты кармы не соглашайтесь делать «не как у всех, а то скучно».

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

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

    В частности, очень часто забывают про:

    заголовки, ключевые слова, подписи изображений подставляемые программным кодом;

    возможности гибкой настройки страниц для поискового продвижения;

    параметры серверного быстродействия сайта с контентом и при наличии посетителей, скорость отдачи основных страниц сайта (для ИМ это главная, страница товара и остальные страницы пути конверсии)

    вопросы клиентской оптимизации, быстрого открытия сайта браузером, скорость работы разнообразных «эффектов», параметры кроссбраузерности;

    начальное наполнение контентом.

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

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

    В отличном ТЗ определен порядок тестирования и приемки результата, причем не скопирован из ГОСТа, а действительно продуман и принят сторонами.

    «Выпустить быстро» или «сделать полнофункционально»?

    Причина просрочки многих проектов — неуместный перфекционизм

    Какие функции нужно сделать к моменту запуска магазина, а что добавить потом?

    Какую стратегию выбрать: «выйти с не вполне готовым продуктом и быстро начать работу» или «идеальный результат, чтобы не испортить первое впечатление»?

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

    Сразу надо делать:

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

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

    2 Задаем вопросы, намечаем путь

    Для кого пишем?

    У ТЗ два основных читателя и один редкий.

    Два основных это разработчик и клиент.

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

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

    У заказчика и разработчика разный уровень подготовки и разное отношение к ТЗ.

    Типичные реакции типичного клиента на ТЗ в 50-70 страниц это

    • попытка раздать его всем коллегам «почитать» или
    • подписывание без чтения.

    И то и другое плохо. В первом случае никто не читал все. Во втором никто не читал ничего. При разборках будет сказано: «Мы ничего не поняли и подписали. Вы же профессионалы».

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

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

    Кстати, разработчики тоже любят картинки.

    Разработчику нужно кроме картинок написать довольно много занудного текста. Что откуда выводится, какими признаками обусловлено, по каким формулам считается, где настраивается, как надо и как НЕ надо это реализовывать и тп.

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

    клиент прочитал ТЗ (в смысле посмотрел картинки и прочитал первый абзац в каждой главе).

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

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

    После первого же глубокого тестирования и исправления ошибок почти все будет хорошо.

    И пусть у вашего ТЗ не будет третьего «редкого» читателя.

    Кто, с кем и как должен говорить?

    Написание проектного документа это не опрос и запись «с голоса». Ничего хорошего так написать нельзя. Если вы будете в документе писать только сказанное клиентом и не работать своей головой, то очень скоро нарветесь на претензию: «а вы ничего не предлагаете»!

    Это правильная претензия.

    Я уверен, что написать хороший проектный документ можно при соблюдении условий:

    все участники одинаково понимают цель проекта и задачи проектирования;

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

    Задача клиента — описать ситуацию, уточнить приоритеты и принять.

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

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

    Сколько времени тратить на проектирование

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

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

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

    Что надо сделать? На проектирование крупного интернет-магазина для внешнего заказчика надо выделять 1 календарный месяц и тратить на него 2-4 часа каждый день. Но если вы подписали ТЗ через 2 месяца, то считайте что вы успели. Порой это занимает намного больше времени.

    Если вы делаете интернет-магазин, связанный со складской системой (например 1С), то я вам крайне рекомендую сначала получить из нее выгрузку (или как минимум лично ознакомиться со структурой данных) и только потом описывать логику. Если вы этого не сделаете, с вероятностью 100% вы будете опираться на данные, которых в складской системе нет или их структура грубо отличается.

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

    3 Как писать, как читать, как проверять?

    Есть три простых принципа:

    Автор должен хорошо писать.

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

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

    «Что вы ворвались как лошадь? У вас языка нет постучать?».

    Читающий должен задавать вопросы.

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

    «Рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть».
    Вольтер.

    На моем опыте предельный объем — 100 страниц вместе с картинками. А лучше до 50. В противном случае подробность проектирования начнет всем мешать.

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

    Война с терминами. Кратко и четко или исчерпывающе и подробно?

    «Если вам непонятно какое-то слово в техническом тексте, не обращайте на него внимания. Текст полностью сохраняет смысл и без него».

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

    Если вы не уверены — самое время задуматься.

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

    В чем же затруднение?

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

    Не напишешь — сдержанный исполнительный кодер сделает неправильно, излишне придирчивый скажет «там этого не было написано».

    Спасением был бы здравый смысл и понимание нормы подробности. Но вот беда — у всех команд и у всех людей они разные.

    Панацеи нет, но хорошая практика заключается в:

    • минимальном числе использованных терминов (дизайн, макет, мокап, эскиз, шаблон, сетка, схема — сведите все это к одному скучному термину типа «jpg-изображение одного типа страниц» и введите краткое «макет страницы»);
    • использовании стандартной терминологии без локального жаргона и сомнительных неологизмов;
    • создании раздела с глоссарием, где определены все потенциально незнакомые термины.
    CMS/платформа

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

    Правильно ли, когда в ТЗ явно подразумевается на какой системе будет делаться ИМ?

    Мое мнение однозначно: Да, это правильно.

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

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

    Есть только две ситуации, когда описание (особенно неявное) используемой CMS вредно и опасно:

    выбор CMS/платформы сделан неправильно.

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

    Бывает, указанная CMS лучше некоторого конкурента только тем, что автор ТЗ (или заказчик магазина) знаком с ней лучше, чем с другими.

    выбор CMS сделан с целью уменьшения конкуренции при проведении тендера и во вред делу.

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

    Стандарты и заблуждения о них

    Часто говорят: а чего вы строем не ходите почему у вас ТЗ не по ГОСТУ? Иногда спрашивают про другие стандарты. Если у вас это спрашивают, мысленно тяжело вздохните. Этот вопрос — признак крайней дремучести собеседника.

    Нет никаких внятных стандартов. Ни отечественные ГОСТы 19 и 34 группы, ни документы, которые советуют фанатики популярных методологий разработки, ни взятые отдельно AXURE-макеты, не являются универсальной хорошей практикой.

    Если вы возьмете и напишете по стандарту (или содрав с чужого шаблона), на вид будет очень симпатично, начальник-чайник вас зауважает, но это будет «мимо кассы». Хорошего проекта вы не сделаете и программисты вам спасибо не скажут.

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

    Структура ТЗ и обязательные пункты Цели и задачи прежде всего

    Зачем делается интернет-магазин? Обычно — ради продаж. Куда реже — для пиара чего-то сопутствующего. Отнесем это к странностям и сосредоточимся на продаже.

    Четко определите в ТЗ кто и что будет покупать в магазине.

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

    Если вы не знаете как будут вести себя покупатели (или грубо ошибаетесь в предположениях) — ничего хорошего с первой попытки вы не сделаете.

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

    Структура данных

    Нужно прописать структуру данных всех основных сущностей. Это товары, бренды, коллекции, линейки, основные справочники. Крайне желательно описать список свойств каждой сущности.

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

    Не поленитесь, выясните состав полей, а также нужен ли по ним автоматически настраиваемый отбор (так называемый «умный фильтр»).

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

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

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

    Один опытный человек как-то мне сказал: «Заставь клиента подписаться под структурой данных. Они врут что не понимают диаграмму сущность-связь. Ее все понимают. И скажи: каждая неправильная стрелочка — 10 тысяч долларов обойдется на переделках».

    Жестко, но здравое зерно в этом есть.

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

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

    Будем честны – заказчикам интернет-магазинов очень сложно самостоятельно составить детальное техзадание и учесть в нем все нюансы, тренды и новые технологические возможности.

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

    4 Обсуждаем и подписываем

    Чему уделять внимание

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

    А вот основные вещи надо сделать хорошо. Что основное для магазина:

    1. Все страницы пути конверсии:
      • главная (или другая посадочная страница),
      • поиск/подбор,
      • страница группы товаров, страница товара,
      • корзина, оформление заказа,
      • оплата, оформление доставки,
      • отслеживание статуса заказа.

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

    Но удобным и качественным его сделать можно. И пусть меню побьют креативные ребята, но я уверен: задачу создания дизайна Интернет-магазина можно на 90% решить грамотной организацией работы с клиентом, материалами и дизайнером. Если вам интересно, вот как мы делаем дизайн

    Источник данных о товарах и обработка заказов.

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

    Если у вас на сайте 1С-Битрикс, а на складе 1С, задача становится немного проще. Но лишь немного, проблем с интеграцией Битрикса с 1С масса

    Работа администратора магазина.

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

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

    Живые макеты в Axure

    Текст со вставленными картинами читать скучно, много остается «за кадром», некоторые вещи сложно объяснять словами.

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

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

    Выглядит это примерно так

    Это интересная схема, но я не считаю ее панацеей. Вот почему:

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

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

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

    Главное — не верьте в них слепо, адаптируйтесь под проект, команду, заказчика.

    Пишем и комментируем

    Идеальная форма работы над ТЗ в проектной группе — совместное чтение, написание и комментирование в Google Docs или аналогичном софте. При этом очень полезно встречаться лично 1-2 раза в неделю. В таком режиме крупную и сложную систему можно качественно спроектировать за 3-5 недель.

    У Google Docs есть недостатки, разумеется: не поддерживаются сильно многоуровневые списки, нельзя вставить документ размера А2 в обычный файл, при превышении объема в 100 листов документ начинает крепко тормозить.

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

    Большие файлы вставляйте ссылками, не делайте нумерации глубже 3 уровня и не пишите больше 100 листов. А совместная работа и отсутствие дурных проблем «не дошел файл», «мигнул свет», «не та версия» вам даст совершенно новое ощущение контакта и качества работы.

    5 Передаем в разработку

    Читаем и раскрашиваем

    Если вам надо оценить трудоемкость работы по ТЗ, напечатайте несколько копий, отдайте экспертам (программистам, тимлидам, опытным менеджерам) и попросите раскрасить ТЗ.

    Зеленое — просто, понятно, поставил оценку времени.

    Желтое — требует уточнений, рискованно, поставил интервал.

    Красное — непонятно, неспроектировано, нереализуемо, противоречиво. Не оценено.

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

    Голосовая/игровая форма такой же затеи называется Planning Poker. Она тоже хорошо работает, создавая еще полезную атмосферу обсуждения.

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

    Не забудьте умножить оценки на «коффициент пессимизма». Некоторые умножают на 3. Но это не вполне профессионально, гуру советуют умножать на число "Пи"

    Лист изменений

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

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

    6 Проверяем и вычеркиваем

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

    Но вы — менеджер проекта, вам нужно обеспечить качественное чтение и отработку ТЗ и минимум итераций при сдаче.

    Есть простой и эффективный прием.

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

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

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

    Компания: Red Graphic
    Должность: Менеджер технических проектов

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

    Поэтому я со спокойной душой прочитал статью до конца.

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

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

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

    И с ГОСТом тоже, кстати, полезно ознакомиться.

    Алексей Маренков

    Компания: "Пять плюс"
    Должность: Исполнительный директор

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

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

    Юрий Колчин

    Компания: AGIMA
    Должность: Руководитель отдела дизайна и проектирования

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

    При проектировании и написании ТЗ большинство просто-напросто забывает о наиболее важных для ТЗ вещах, а именно:

    1. Определение потребности пользователя в продукте.

    2. Моделирование процесса поиска и оценки информации о товаре.

    3. Анализ этапа принятия решения о покупке.

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

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

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

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

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

    Роман Петров

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

    Если Вы хотите дать экспертный комментарий к статьям, публикуемым на CMS Magazine, следите за анонсами материалов в нашей группе в Facebook .

    91 совет по интернет-магазинам

    Это по-своему уникальный материал — над ним работали сразу четыре команды. Сначала Cueblocks подготовили 91 совет по электронной коммерции на английском языке. Потом коллеги из SeoNews сделали адаптированную на русский язык инфографику этих советов. Далее, в E-pepper.ru перевели весь их материал на русский язык. А мы почти для каждого совета подобрали несколько примеров применения в интернет-магазинах СНГ.

    Если так называемый бизнесмен хочет.
    Чтоб его бизнесом занималась веб-студия. То какой он после этого бизнесмен.

    Правильно. Российский. То есть. У меня есть деньги.
    Думать и делать что-то я не умею. Да и не хочу. Просто заплачу.

    Если недорого. То не жалко.
    Если дорого. То пусть и несут ответственность.

    За продажи. За клиентов. За конверсию. И что там еще в магазине.
    Не хочу знать. Я плачу. А там пусть разбираются другие. Удачи такому бизнесмену.

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

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

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

    Вот уж точно, оговорка (вернее описка) по Фрейду.

    У Вас в самом начале статьи не ТЗ, а четко и грамотно спланированному ХЗ.
    Правильно, Хрен его Знает как.