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

Как составить ТЗ для программиста

Есть идея, есть разработчики, есть ресурсы – как получить результат?

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

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

Давайте по шагам разберем как отразить требования в документе.

Основные сведения о приложении: название, сроки выполнения, бюджет и т.п.

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

Какая цель приложения?

Внимательно! Тут нужно подумать, все написать, передохнуть, перечитать на свежую голову и внести финальные правки.

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

Функционал на страницах. Нужно прописать все функции, которые хотите видеть – блоки, поля, кнопки и т.д.

Данный шаг делиться на 3 варианта:

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

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

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

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

Желаю качественных ТЗ и всегда получать то, что хотите!

Источник

Стандарты и шаблоны для ТЗ на разработку ПО

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы рекомендует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

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

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

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

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

3. Системные требования

SRS может содержать следующие разделы:

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

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

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

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

Также рекомендую ознакомиться со следующими материалами:

Источник

Как писать четкие ТЗ программистам, дизайнерам и даже себе

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

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

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

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

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

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

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

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

Заголовок: Задать подготовленные мета-данные для страниц сайта

Мы обнаружили, что на сайте не сформулированы titles & meta descriptions. У части страниц они не заполнены, половина страниц — дубли, а оставшаяся часть сформулирована без использования ключевых слов и некликабельно. Это критическая ошибка, так как без корректных мета-данных сайт не может расти в поисковой выдаче.

Мы составили таблицу в Google Docs с прописанными мета-данными для каждой статической страницы сайта, а также с шаблонами для динамически генерируемых страниц. Ссылка на документ:. Так как у проекта нет админки, где мы могли бы все настроить своими руками, просьба вставить метаданные из документа на страницы сайта:

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

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

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

Заголовок: Разработать landing page для

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

Мы узнали собрали всю инфу и контент у клиента:

Помни: рисуем mobile-first, так как 90% трафика — мобильные устройства!

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

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

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

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

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

Еще небольшая фишка: когда задача уже сформулирована по феншую. Ее нужно ПРОДАТЬ исполнителю:

Прямо по канонам AIDA получается, да? 🙂

Хороший пример:
Вася, привет! В процессе аудита сайта мы обнаружили серьезную ошибку — которая мешает росту сайта. Нужна твоя помощь. Посмотри, пожалуйста, ее сегодня — <ссылка на тикет>!

Плохой пример:
Всем привет! Завели новую задачу:

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

Источник

Как грамотно составить задание для программиста

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

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

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

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

На картинке я показал, что ТЗ прорабатывается до КП, но некоторые студии меняют эти этапы местами. Для текущего вопроса это не принципиально, поэтому я объединил в один формат.

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

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

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

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

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

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

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

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

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

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

Если клиента устраивает оценка, следующий этап — проектирование. Проектирование сводится к пяти основным разделам:

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

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

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

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

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

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

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

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

Источник

Как грамотно составить ТЗ программисту на доработку сайта?

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

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

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

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

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

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

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

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

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

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

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

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

Раздел ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание:

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

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

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

Источник