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

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

Скачать образцы технического задания на разработку сайта:

Грамотно составленное техническое задание на сайт должно содержать следующие моменты:

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

Как должна выполняться ТЗ на разработку сайта?

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

Стоимость создания ТЗ начинается от 30 000 рублей.

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

• Этап планирования;
• Составление итоговой документации предстоящей закупки, извещения, проектные договора;
• Этап непосредственного исполнения условий контракта.

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

На основании сведений, которые содержаться в данном документе, становится возможным:

• Формирование плана, проекта закупок;
• Определение стоимости контракта как начальной, так и максимально возможной;
• Составление извещения о проведении закупки;
• Формирование графика выполнения условий контракта;
• Подготовка основополагающей документации, включая проекты контракта;
• Оценка поступивших предложений от желающих принять участие в закупке;
• Заключение контракта и контроль за его исполнением.

Как составить форму

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

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

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

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

На выполнение строительно-монтажных работ

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

• Сам объект аукциона. Какие именно работы должны быть произведены в соответствии с будущим контрактом;
• Адрес местоположения. Точное местонахождение объектов, на которых требуется осуществить строительно-монтажные работы;
• Условия проведения работ. В данном пункте, как правило, перечисляется характер почв, инженерно-геологические характеристики, например, уровень глубины грунтовых вод и иные характеристики, значимые при проведении будущего строительства;
• Указывается характер строительно-монтажных работ — будет ли это новое строительство либо работы будут проводиться на уже возведенном объекте;
• Способ осуществления, например, подряд;
• В следующем пункте содержится информация о наличии проектно-сметной документации и о том, кем она была составлена;
• Технико-экономические характеристики объекта строительства;
• В следующем пункте расписываются функции, которые возлагает на себя заказчик строительно-монтажных работ, включая бухгалтерский учет, контроль за ходом строительства на всех этапах, организации работы и предоставление разрешения на проведение строительно-монтажных работ;
• Требования к исполнителю с перечнем работ, которые подлежат выполнению стороной-подрядчиком;
• Стадии строительства и сроки выполнения определенного объема согласно распределению на этапы;
• Организационные требования, например, необходимость соответствия выполняемой работы требованиям ГОСТа, и действующим СНиПам;
• В конечном пункте указываются сроки, в которые строительно-монтажные работы должны быть произведены в полном объеме.

На выполнение электромонтажных работ

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

• Место выполнения работ;
• Сроки выполнения;
• Дается краткое описание требуемых работ;
• Требования к исполнителю.

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

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

На выполнение работ по 44-фз

Согласно требованиям Федерального закона № 44-ФЗ, заказчику надлежит руководствоваться едиными требованиями, касающимися описания объекта закупок, при подготовке документов вне зависимости от способов фактического исполнения контракта. При оформлении ТЗ заказчик должен руководствоваться следующими директивами:

1. При описании объектов аукциона следует ориентироваться на критерии объективности;
2. Функционал, технико-эксплуатационные характеристики объекта закупок должны присутствовать в описании в случае необходимости;
3. ТЗ должно носить нейтральный характер, не содержа излишнее количество чрезмерных требований с целью ограничения количества потенциальных участников.

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

От автора : Как написать техническое задание на разработку сайта ? Тема достаточно обширная, и в рамках одной статьи ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, то, что нужно учесть, на что следует обратить внимание при составлении ТЗ, я постараюсь достаточно подробно изложить в данной статье.

Итак, ТЗ

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

Давайте проанализируем такой пример:

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

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

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

Что мы имеем. Исполнитель пункт ТЗ выполнил, а вы хотели совсем другой календарь. Вроде все в соответствии с ТЗ, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит ТЗ?

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

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

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

Поехали по пунктам.

Описание сайта

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

для кого – целевую аудиторию сайта :

• потенциальные покупатели
• продавцы продукции (магазины, интернет-магазины)
• сервисные центры
• партнеры (фирмы)
• потребители продукции (тот, кто уже купил)

Для чего нужен сайт :

• Для повышения имиджа компании
• Для увеличения продаж
• Для удобства клиентов

Тип сайта :

• Корпоративный
• Сайт – визитка
• Интернет магазин

Языковые версии :

• Английский
• Русский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам сайта.

Цели и задачи сайта

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

Потенциальные покупатели продукции .

Цель : привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи :

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

• Дать информацию о салонах-магазинах
• Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули сайта.

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

Для того чтобы перечислить функционал сайта, нужно решить что ему необходимо:

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

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

Описание функционала сайта

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

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

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

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

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

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

О компании

• история компании
• контакты
• отзывы

Новости

• события
• акции
• новое на сайте

Продукция

• каталог продукции
• релизы
• отзывы о продукции

Сервис

• служба сервиса
• гарантийное обслуживание
• послегарантийное обслуживание

Потребителю

• покупка и доставка
• пользование
• о сервисе

Магазинам и интернет магазинам

• фотографии продукции
• Часто задаваемые вопросы

Сервисным центрам

• Как стать сервисным центром
• Часто задаваемые вопросы

Партнерам

• приглашение к сотрудничеству
• часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

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

Я описывать буду исходя из рисунка выше.

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

Примерно так описывается общая логика работы.

Теперь подробно описываем каждый блок. Например «Новостная лента».

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание : попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!

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

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

Что было раньше

На многих проектах это выливалось в следующие проблемы:

1. Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
2. Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
3. ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.

Новый подход

ТЗ состоит из следующих разделов:

1. Введение
2. Статика
3. Динамика
4. Задачи
5. Административная панель
6. Общие технические требования

Введение и подготовка к реализации

• Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
• Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
• Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа - “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики - страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель - задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

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

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

Динамика

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

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

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

Административная панель

Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.

Общие технические требования

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

1. SEO-требования к тегам и микроразметке
2. Правила транслитерации
3. Ручное и автоматическое тестирование
4. Поддерживаемые браузеры

Новые версии

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

Пример

Статика

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

Интегрируется следующий функционал:

1. “Хлебные крошки”
2. “Дерево каталога”
3. “Фильтрация. Общие положения”
4. “Фильтрация. Текст”
5. “Фильтрация. Текст и изображение”
6. “Фильтрация. Диапазон”
7. “Сортировка. По умолчанию”
8. “Сортировка. По возрастанию цены“
9. “Сортировка. По убыванию цены”
10. “Превью товара. Плитка”
11. “Пагинация. Постраничная”
12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

Динамика

Функционал “Фильтрация. Общие положения”

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

• выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
• название кнопки фильтра приобретает вид: “Название фильтра: K”, где K - количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
• цвет кнопки фильтра меняется на вид используемого фильтра
• в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
• у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
• пагинация сбрасывается

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

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

1. Цена (целое число в рублях РФ)
2. Название товара
3. Метка “В магазине” или “С витрины”
4. Изображение
5. Размер
6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

На одной строке должно помещаться 3-4 плитки с превью товара.

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

Административная панель

Товар

Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:

1. Название (текст)
2. Бренд (радио)
3. Изображения
4. Цена (целое число)
5. Описание (текстовый блок)
6. Тип (магазин/витрина, радио)
7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
8. Статус. Возможны варианты:
   1. на продаже
   2. на модерации
   3. на доработке
   4. отклонен
   5. продан
   6. не прошел проверку
   7. отменен Продавцом
9. Размер с бирки (необязательное). Текстовое поле без валидации

Выводы

1. Полнота . Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
2. Понятность . Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
3. Молекулярность . ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
4. Простота оценки и конфигурации сметы . Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
5. Взаимодействие с заказчиками поднялось на новый уровень . Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
6. Рентабельность . Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.

1. Внесение доработок . На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
2. Сложность восприятия при автоматизации бизнес-процессов . Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
3. Стоимость и время разработки . Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).

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

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

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

Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.

Однако, как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. К сожалению, многие заказчики уверены, что, написав пару страниц требований к будущей системе, они получат от нас точную (максимум с дельтой в 10-20%) оценку с календарным планом работ. Получая в очередной раз на почту «ТЗ, по которому к завтрашнему дню надо дать оценку и выслать КП», я всегда морально готовлюсь увидеть очередное творение в стиле «система должна обмениваться с сайтом всей необходимой информацией».

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

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

Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?

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

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

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

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

3. Usability. Из двух предыдущих пунктов есть простое следствие – понятная логика работы и максимальная визуализация будущей системы помогут в итоге заложить в ТЗ нужное количество примечаний\пунктов, касающихся удобства использования системы. Для систем, с которыми работают низкоквалифицированные сотрудники, это может стать решающим фактором успешности проекта (впрочем, этот параметр также крайне важен и для топ-менеджмента, не желающего иметь дела с «этими бухгалтерскими программами»). Например, в ТЗ на систему для розничных продаж не указали, что поиск артикула должен занимать не более трех секунд. Если бы систему реализовали через типовой поиск конфигурации, то это могло привести к критическим ситуациям в реальной эксплуатации, т.к. с учетом количества номенклатуры этот поиск занимал до 30 секунд, что недопустимо при работе с розничными покупателями, где каждая секунда на счету.

4. Ссылки на популярные решения . Зачастую, для всех, к примеру, менеджеров по продажам компании, фраза «функционал ведения сделок» означает примерно одно и то же, но для сотрудников подрядчика эта фраза не значит ровным счетом ничего. Но добавьте пару слов в эту фразу, и из варианта «карточка сделки, аналогичная таковой в Битрикс24(или 1С:CRM)» уже понятно, чего примерно ожидает от этой самой карточки Заказчик.

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

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