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

• Не писать ТЗ отпадает сразу — так профессионалы не работают.
• Мы с вами технические люди и понимаем, как за простыми вещами скрываются маркетинговые уловки. Я про зловония популизма Scrum. Отсекайте их при первом появлении.

Усреднить точки зрения сторон

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

Но тот, кто согласовывал технические задания понимают, что начинаются битвы между руководителями отделов с эпизодами: «Нам это не надо», «Мы делать это не будем», «У нас все сотрудники и так работают до 22. Когда им?»,…

Максимально проработать проблему

Озвученные слова каждым мозгом интерпретируются по-разному. Кто-то, в процессе обсуждения, видит проект как картину Сальвадора Дали, а кто-то Иван Иваныча Шишкина. Саботажники сразу представляют «Чёрный квадрат» Казимира Малевача.

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

Определить скорость движения проекта

Важно определить уровень коммуникации клиента в самом начале работ. Если вы отправили график встреч (или другой «левый» документ) клиенту на согласование, но его согласовывали долго, то вы учитываете эти тормоза в план-графике работ. Есть практика когда стоимость работ моего участия увеличивается в 1,6-2 раза только по причине длительного согласования. У этого манёвра есть достойные аргументы — вам потребуется 5 встреч вместо 3, 10 звонков вместо 5.

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

Вы:

— Докажите, что оно вам надо!

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

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

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

Одно ТЗ или несколько?

Вопросы бизнес-анализа.

1. Автоматизируемая деятельность является сквозным бизнес-процессом и влияет на соседние процессы?
2. Какое количество ЛПР и ответственных в принимаемой задачи? Можно ли агрегировать решаемые задачи по ЛПР?
3. Возможно ли завершение автоматизации по ТЗ (в том числе, получение оплаты за выполненную работу исполнителю) без завершения комплексного ТЗ?
4. Насколько длительная процедура согласования договоров и оплат у Заказчика?
5. Итерационный подход (по частям) не искажает конечный результат? И др.

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

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

Если в процессе обследования появляется большой подпроцесс со своей инфраструктурой (Ниже пример «Интеграция 1С-Сайт») и ЛПРом (Начальник ОИТ), то его можно выделить в отдельное ТЗ. Например, в выше приведённой цепочке для менеджера появляется новый поток и требуется реализовать нестандартный обмен 1С с сайтом для появления документов «Заказ клиента» в 1С.

Пример технического задания 1с на интеграцию с сайтом. Отельное ТЗ от комплексной задачи.

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

Покажу самую ценную часть Технического задания — оглавление, в котором указаны технические работы на Интеграцию 1С-Сайт. Юридические детали остались в основном ТЗ, но здесь обязательно указаны «Ограничения проекта». Планово-финансовые показатели расположены в Приложении.

Пример блок-схемы.

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

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

• 17.04.2013 (Обновлено: 6.08.2020) Олег Галеня

94 50 15 29

• 1. Назначение, цели ТЗ
• 2. Общие рекомендации по написанию ТЗ
• 3. Общая структура ТЗ. От абстракции к конкретике

Назначение, цели ТЗ

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

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

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

Общие рекомендации по написанию ТЗ

• Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
• Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
• В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
• Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
• Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
• Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

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

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

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

1. Общая информация о сайте.
2. Функциональное назначение сайта.
3. Понятия и термины
4. Описание модулей сайта
5. Функциональные характеристики
6. Описание страниц.
7. Резервирование и надежность.
8. Хостинг для сайта.

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

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

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

• Поле «Ваш имя»;
• Поле «Ваш е-mail»;
• Поле «Ваш вопрос»;
• Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

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

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

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

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

Подписаться на рассылку

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

Кто должен писать ТЗ?

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

Зачем нужно техническое задание?

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

Получите 267 видеоуроков по 1С бесплатно:

Что должно содержать в себе техническое задание?

Тех. задание обязательно должно содержать в себе:

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

Примеры и образцы ТЗ для 1С

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

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Что такое техническое задание (ТЗ)?

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

Почему важно зафиксировать весь процесс работы в виде технической документации?

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

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

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

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

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

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

Участники проекта

Заказчик	Менеджер проекта	Разработчики
Ставит задачу	Ставит задачу разработчикам	Выполняют задание в соответствии с ТЗ
Согласовывает ТЗ	Контролирует ход работы и расставляет приоритеты
Принимает работу	Осуществляет взаимодействие с заказчиком и разработчиком
	Тестирует выполненную работу (если нет тестировщиков)

Если проект большой, дополнительно могут добавиться участники:

• Product Manager
• Руководитель проекта
• Спонсор проекта
• Тестировщики
• Технические писатели
• Кураторы
• Пользователи/потребители (например, для финального тестирования)
• И др.

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

Что дает сторонам каждый раздел ТЗ:

Раздел ТЗ

+ Для Заказчика

+ Для Разработчика

Осознание задач, которые решает проект или его доработка

Понимание сути задачи

Представление о том, каким будет готовый продукт

Уверенность в правильном понимании конечного результата

Ориентирование в сроках работ и получения планируемых результатов

Оценка трудозатрат и потребности в ресурсах

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

Согласованный учет всех работ проекта

Подробное описание работ и каждого этапа реализации проекта

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

Оценка результата работ

Проверка работы проекта по программе тестирования на соответствие требованиям задания

Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ

Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта

Выполнение работ с учетом обслуживания проекта в перспективе

Планируемые доработки проекта

Доработка в соответствии с новыми потребностями

Последствия составления некачественного задания

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

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

Обычно разработке качественного ТЗ мешают следующие моменты:

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

Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.

Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.

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

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

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

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

Техзадание должно отвечать на вопросы:

1. Что? (какие работы, содержание элементов)
2. Где? (расположение элементов)
3. Когда? (последовательность выполнения и установленные сроки работ)
4. Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
5. Откуда? / Куда? (при переносе и т. п.)
6. Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
7. Особенности.

Основные рекомендации и пояснения по написанию ТЗ

1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
3. Программисту нужны четкие условия. Формулировки «как вариант”, «примерно”, «около”, «где-то рядом”, «там, где лучше по вашему мнению”, – неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.

7 типовых ошибок

1. Нечеткие цели и задачи.
2. Мало деталей в технической информации.
3. Размытые или неустановленные сроки.
4. Нет согласованности по всем вопросам между сторонами.
5. Нет регламента взаимодействия.
6. Нет ответственных лиц.
7. Нет критериев оценки результата.

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

Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание:

1. ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
2. КУДА? URL новой страницы сделать: /vash_konsultant.htm
3. КАК? Макет новой страницы взять со страницы «Наши врачи”. Только вместо врачей будут консультанты.
4. ЧТО? Структура страницы следующая:
5. заголовок: Ваш консультант – по центру (в стиле других заголовков страниц сайта);
6. 3 блока в ряд, имеющие поля:
7. с фотографиями продавцов размером 400*600 (выравнивание по центру);
8. Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
9. телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
10. электронный адрес под телефоном (e-mail: site2@mail.ru);
11. кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru).
12. ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.

Также внизу разместить форму заказа.

1. ГДЕ? Под списком консультантов, над футером.
2. ЧТО? Три поля:
3. Имя
4. Номер телефона
5. КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
6. КУДА? Заявку отправлять на email заказчика: info@common.com
7. КАК? Оформление письма в свободной форме.
8. ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
   При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие «Отправка заявки”.
9. НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
   Проверить:
10. На странице не должно быть незакрытых HTML-тегов.
11. Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280 x 1024.
12. Проверить работу в браузерах Safari, Chrome, Mozilla.

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

Читать дальше подобные статьи

Онлайн SEO-сервис Labrika

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

Какие требования предъявляются к техническому заданию?

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

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

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

Техническое задание на тендер, сформированное корректно, должно содержать:

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

Составляющие техзадания

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

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

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

Тендер: электронный или обычный?

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

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

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