Содержание

Как правильно писать техническое задание на разработку веб-сайта

Всем привет, мы веб-студия Mad Design — специализируемся на разработке веб-проектов. Около 75% наших клиентов, при обращении к нам, не предоставляют вообще никакого ТЗ на разработку веб-сайта, около 20% пишут как могут, и оставшиеся 5% приходят к нам с подробным ТЗ (спасибо вам большое!). Эта статья для тех, кто хочет самостоятельно написать ТЗ для разработки своего проекта! Лично мы в 99% случаев ТЗ разрабатываем бесплатно.

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

Есть 2 варианта:

1. Описать все очень подробно в свободной форме и отдать это подрядчику, подрядчик на основании этого составит для вас профессиональное ТЗ. Минус — за это нужно заплатить дополнительно.

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

Суть техзадания:

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

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

Пример: «Будущий интернет-магазин кондиционеров будет служить основным инструментом для привлечения клиентов и увеличения продаж. От большинства конкурентов нас отличает наличие собственного сервисного центра и технический персонал прошедший обучение в Японии. Наш посетитель и потенциальный клиент должен с первого взгляда понять, что попал на сайт серьезной организации, однако серьезность не должна „давить“ — мы хотим произвести впечатление открытой компании с которой легко работать.».

Как сделать техническое задание на разработку сайта?

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

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

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

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

Составляем ТЗ

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

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

ПунктСодержаниеПример

Назначение сайта

Название проекта, тип сайта, задачи, которые сайт должен решать

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

Пожелания заказчика к дизайну

Цветовая гамма, стиль, присутствие аудио-/видео-контента, анимации и т.д.

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

Структура сайта

Перечень категорий и разделов сайта

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

Навигация

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

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

Администрирование

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

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

Содержание веб-страниц

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

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

Общие вопросы

Примерные наработки обеих сторон по особенностям работы сайта и каждого его элемента.

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

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

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

Как найти сайт-образец

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

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

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

Образец сайта бухгалтерской компании


Образец сайта бухгалтерской компании

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

Помимо сайтов конкурентов, поищите интересные примеры верстки и дизайна на тематических ресурсах.

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

Шаблоны сайтов на TemplateMonster
Шаблоны сайтов на TemplateMonster

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

Каталог шаблонов на Timeweb
Каталог шаблонов на Timeweb

Как описать дизайн сайта

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

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

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

Дизайнер намного быстрее и точнее выполнит свою работу, если в ТЗ будет разобран внешний вид каждого элемента сайта:

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

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

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

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

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

Текстовые блоки должны быть оформлены в соответствии с общим дизайном сайта. При этом важно, чтобы у посетителя не возникало трудностей при чтении текста. Что касается шрифтов, если у заказчика нет определенных предпочтений или корпоративных шрифтов, чаще всего используются Tahoma, Verdana и Arial. Оптимальный размер – от 12 до 16 px. В ТЗ также можно указать, какими заказчик видит заголовки. Они должны гармонично сочетаться с основным текстом, привлекать внимание пользователя, но при этом не мешать чтению.

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

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

Как не допустить ошибок при составлении ТЗ

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

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

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

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

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

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

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

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

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

Мой подход к созданию ТЗ на шаблонные сайты / Хабр


Вместо эпиграфа.

Поймал дед золотую рыбку. Она ему говорит:
— Чего тебе, дед?
— Хочу чтоб мой аппарат был длиной до колен.
Взяла рыбка и укоротила деду ноги.
Мораль: ставьте корректно техническое задание.

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

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

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

Наш процесс выглядит так:

  1. Нашли заказчика, пообщались, пришли к общему пониманию, что будем делать сайт, масштаб цен озвучили.
  2. Работа по дизайну и программированию распадаются на две параллельные ветки — дизайн и программирование. На дизайн ТЗ не пишется. Я лично не представляю как вообще может быть написано ТЗ на внешний вид. Нет, можно сказать, что мол три колонки, баннер сверху и зеленый логотип, но только такое описание может включать в себя как шедевр дизайностроения так и полный отстой и соответственно огорчить заказчика. Т.е. такое ТЗ не может гарантировать, что на выходе будет что-либо хорошее, в отличие от ТЗ на программную часть, где ТЗ может дать гарантию, что мы получим то, что заказали (по крайней мере теоретически может). Делать ТЗ на дизайн, это как ТЗ на мелодию: «нота ля не более 8 раз, барабаны и что бы весело» — бред.
  3. Вторая ветвь работы — программная часть, сюда входят программирование, верстка и сопряженные с этим работы. Как правило этот процесс стартует чуть позже дизайна, когда уже есть первые макеты.
  4. Соединяем все вместе и результат выкладываем на хостинг.

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

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

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

Эта схема, согласованная с заказчиком, позволила легко отсечь ряд хотелок. Например, после демонстрации (законченного, по нашему мнению) сайта заказчику он спрашивает:
— А где карта проезда на сайте?
— Сейчас посмотрим схему сайта… Так, вот «Главная страница», вот «Новости», «О проекте»… хм, Кулверстукаса нет! А страницы «Карта проезда» и не должно было быть. Но если вы хотите, мы можем завершить работу по согласованной схеме и потом за недорого вернуться и сделать карту проезда.

Кроме этого схема позволила решить еще одну, на этот раз внутреннюю проблему. У нас достаточно часто было, что дизайнер после согласования и утверждения дизайнов прорисовывал ключевые страницы сайта, но забывал о некоторых второстепенных. Этот момент оказывался непроконтролированным, дизайны уходили в порезку, а затем к программистам, которые сообщали:
— А где порезка страницы «404»?
— А нету. Забыли…

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

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

Таким образом, схема сайта имеет такие преимущества:

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

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

Такой класс хотелок отсекается описанием сущностей, присутствующих на сайте. Например «Новость» это:

  • Название — строка длиной до 255 символов
  • Анонс — текст с анонсом новости, длина до 200 символов
  • Текст — текст новости, длина до 5000 символов
  • Дата публикации

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

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

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

Содержание такого ТЗ имело примерно следующий вид:

СОДЕРЖАНИЕ
1. Введение
2. Основание для разработки
3. Назначение разработки
3.1. Функциональное назначение
3.2. Эксплуатационное назначение
4. Требования к программе или программному изделию
4.1. Требования к функциональным характеристикам публичной части сайта
4.1.1 Общие положения
4.1.2 Страницы сайта
4.1.2.1 Раздел «Главная страница»
4.1.2.3 Раздел «Страница с заключением и комментариями»
4.1.2.4 Разделы «Разработка концепции проекта», «Консультирование и сопровождение проектов», «Маркетинговый аудит», «Продвижение объекта на рынке», «Продажи компанией», «Управление продажами»
4.2 Требования к функциональным характеристикам приватной части сайта (админке)
4.2.1 Общие положения
4.2.2 Страница управления общими настройками
4.2.3 Страница управления разделом «Главная страница»
4.2.4 Страница управления разделом «Страница с контактами»
4.2.5 Страница управления разделом «Страница с комментариями»
4.2.5 Страница управления разделами «Разработка концепции проекта», «Консультирование и сопровождение проектов», «Маркетинговый аудит», «Продвижение объекта на рынке», «Продажи компанией», «Управление продажами»
4.2.6 Страница управления разделом «Заключения»
4.4. Условия эксплуатации
4.5. Требования к составу и параметрам технических средств и программного обеспечения
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению
5. Наполнение сайта
6. Порядок контроля и приёмки

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

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

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

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

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

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

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

Естественно хотелось то, ради чего всё затевалось — техзадание.

Хотелось еще много чего…

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

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

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

Надеюсь, вам будет полезен и мой опыт, и мой сервис.

UPD. Если вы не пользователь хабра, и хотите инвайт, на сайте есть форма обратной связи.
UPD2. Прямая ссылка на сервис. azalo.net

Как просто составить ТЗ на расчет разработки сайта?

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

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

Цели проекта

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

Пример:

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

Примеры похожих сайтов

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

Пример:

Сайт1.ru — нравится дизайн главной страницы и профиля пользователя;

Сайт2.ru — нравится дизайн карточки товара;

Сайт3.ru — нравится структура и расположение блоков на главной странице.

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

Структура

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

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

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

Пример:

На сайте будут страницы: Главная, О компании, Продукция, Тендера, Личный кабинет, Отдельный раздел для оптовых покупателей.

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

Технические особенности

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

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

Дизайн

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

Пример:

Сайт должен быть в темных тонах, с замашками под luxury сегмент. Вот такой дизайн мне понравится у Сайт23.ru

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

И т.д.

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

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

Адаптация и платформы

Рекомендую сразу указывать в справочном ТЗ, должен ли быть адаптирован сайт под те или иные платформы. Казалось бы, в 2020 году всем очевидно, что сайт должен быть адаптирован ПОД ВСЁ. Но доходит до абсурда, если исполнителям не указать что-то, то и делать они не будут. Это звучит смешно, но нужно указывать даже версии браузеров, под которые должен быть адаптирован сайт.

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

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

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

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

С уважением, команда веб-студии Госайт.рф !

ТЗ на создание сайта с человеческим лицом (не по ГОСТу)

ТЗ на создание сайтаКак для постройки дома, так и для создания сайта нужен план

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

Важный момент, мы говорим о сложных сайтах, а не сайтах, сделанных с помощью сборки на WordPress или других CMS (системах управления сайтом). Мы говорим о порталах, биржах, CRM, онлайн-сервисах и так далее.

Зачем нужно ТЗ на создание сайта?

Если вы задумались построить дом, то имеет смысл нарисовать его план. Портал – это штука не менее сложная, чем дом. Почему же некоторые считают, что крупный сайт можно сделать без технического задания? Просто по обрывкам фраз или “как Youdo.ru”. ТЗ снижает риски, уменьшает бюджет и сроки проекта, улучшает аппетит, снимает бессонницу… Если вы работаете без ТЗ – фундамент вашего проекта строится на болоте.

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

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

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

Что является самым важным для ТЗ?

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

Раздел Термины и определения. Не нужно забивать его общими понятиями типа “сайт”, “хорошо”, “плохо”. Здесь должны быть термины предметной области (например, “Обналичивание чеков”), с которыми предстоит познакомиться разработчикам, а также специфические термины, которых может не знать заказчик (например, “DNS-зона”). Термины и определения должны встречаться не только в этом разделе, а использоваться в ТЗ! Не создавайте мертвые термины, которые не планируете использовать.

Раздел Общие моменты по взаимодействию. Здесь мы проявляем различные ожидания по взаимодействию. Например, что все, что не описано в ТЗ – это доп (дополнительные работы; доработка, не включенная в ТЗ), который оплачивается отдельно. Заказчик должен сразу это понимать, а не делать изумленный взгляд, когда ему сообщают, что реализовать кабинет Исполнителя в системе – отдельный доп, которого нет в текущем ТЗ.

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

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

Раздел Требования к страницам. Здесь описываются конкретные требования к каждой странице. Главное слово “конкретные”. Очень опасно писать неконкретику в этом разделе – это порождает споры и недопонимание на этапе сдачи проекта. “Я думал, что это входит”, “а мы поняли это так-то…”.

В нашей практике был случай, когда лет 7 назад в ТЗ была прописана безобидная фраза “Интеграция с 1С”. Такого автора ТЗ можно смело увольнять – при такой постановке задачи заказчик вправе интегрировать все, что угодно из 1С. Нужно конкретно указать какие данные будут передавать из 1С (в одну сторону или в обе). Без этих деталей есть риск возникновения принципиальных разногласий.

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

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

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

Раздел про Требования к заказчику. Да, заказчик тоже должен участвовать в проекте. И надо явно обозначить его роль. Чем точнее эта роль и чем лучше заказчик осознает свои обязанности в проекте, тем больше шансов на успех проекта. Наверно кто-то подумает “вообще обнаглели. Заказчику вешают какие-то обязанности”. Можно и так сказать, но сознательный разработчик-исполнитель должен понимать, что ему не нужна в портфолио мертвая работа. Если заказчик себя плохо проявляет в начале проекта в плане общего менеджмента, то, вероятнее всего, проект быстро загнется, а исполнитель просто потратит время на неперспективный проект.

ТЗ на создание сайта и макеты (прототип)

И последнее, что непременно должно быть в современном ТЗ – это макеты.

Макеты – это схематичное отображение графического интерфейса портала.

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

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

Так, а где рыба ТЗ? Рыба ТЗ на разработку сайта: https://web-automation.ru/wp-content/uploads/2017/11/ТЗ-Web-Automation.docx. Здесь учтены многие дополнительные нюансы, о которых мы не упомянули. Она составлена в таком плане, чтобы максимально прояснить ожидания по проекту.

Более глубокие знания о разработке ТЗ можно получить на нашем курсе создания технического задания.

P. S. Рекомендуем прочитать статью о стоимости услуг разработки ПО, которая подробно рассматривает вопрос ценообразования программирования и нюансы работы специалиста IT.

10 правил и немного занудства / Блог компании RegionSoft Developer Studio / Хабр

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Грани взаимодействия


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

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

Возможности — если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM. Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается — да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ— позже.

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

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

Сбор и анализ требований


Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»). На самом деле, в большинстве случаев это обычный вышколенный продажник, у которого две задачи: накрутить стоимость проекта и не дать вам сорваться с крючка.
Он находится здесь уже целый час и даже не притронулся к белой маркерной доске. Он не настоящий системный аналитик

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

Есть очень простая схема сбора требований.

  1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
  2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
  3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
  4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
  5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

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

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


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

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

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

Уровень бизнеса — самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов — RegionSoft Retail.

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

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

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

Уровень технологии — последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.

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

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

Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему — были найдены решения по оптимизации процесса. Уже в ходе работы выяснилось, что продажник перестраховался и отчёт нужен ему только по итогам месяца, и то его можно запускать по расписанию ночью. Стоит ли говорить, что время и деньги были потрачены зря.

Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.

Что должно делать? Самый информативный блок — в нём описываются требования, ожидания от системы. И вот тут случаются тем самые перлы, чудеса и коллизии, которые впору отправлять на башорг, и которые ну очень усложняют жизнь. Причина одна — пользователь не знает, чего он хочет, что нужно сделать. Есть ещё маленькая подпричина — пользователь не может сформулировать требования. И тут задача разработчика (рабочей группы, аналитика, если он есть) помочь сформулировать потребность верно, выбрать целесообразное требование, вписать задачу в контекст работы системы. В этом же блоке нужно упомянуть ожидаемый результат.

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

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

10 правил, написанных слезами разработчика


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

Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft — 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?

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

Например, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое.

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

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

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


Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей

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


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

Техническое задание должно быть написано на человеческом языке. И это важно, нет, ВАЖНО. Выделю две ситуации, когда проблемы с языком приводят к затягиванию реализации проекта.

  1. Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите — пишите обычными словами, мы их понимаем.
  2. ТЗ переполнено грамматическими ошибками. Нужно не только избавиться от расплывчатых описаний и метафор (из реального: «Чтобы компьютер не пищал, будто помирает в судорогах»), лишних слов, слов-паразитов. Проверяйте пунктуацию – зачастую ошибки в ней искажают смысл требования. Задание на проект – это документ и лексика в нём должна быть соответствующая, а грамотность — близкая к 100%.

И ещё — не используйте редакторы типа Microsoft Visio и UML-диаграммы, если вы в них не разбираетесь. То, что кажется красивым и деловым, на взгляд разработчика оказывается адской путаницей. Если хочется вставить схему или картинку — нарисуйте её человеческими методами, не утруждайте себя, это нам, разработчикам, ничем не поможет.

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

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

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

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

Заповеди закончились, теперь отповедь


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

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


Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.

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

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

Исходите из объективной необходимости изменений и расширений — выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» — поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.

О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание — не норма права, не ГОСТ и не догма, поэтому, если можно улучшить — улучшайте, можно упростить — упрощайте, можно сделать изящно и чтобы всем нравилось — делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.



Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.


Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт, там много о CRM, её преимуществах и прочем корпоративном софте.

И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на [email protected]

Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод — будем рады его внести в пост.

надо ли и как писать. Критика примера / Хабр

При создании объекта есть два способа описать требования: «что должен уметь/делать объект» (описание цели) и «каким должен быть объект» (описание реализации). Прощу прощения если формулировка не точна, источника сией мысли я не знаю, формулирую сам. Далее речь пойдет о втором способе описания объекта — дизайна сайта.


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

Разработке подлежит дизайн сайта компании АА (имя сайта АА-company.ru)

Исходные материалы: логотип, визитка, буклет, примеры продукции компании, фотографии работ, текстовое наполнение (15 стр в doc).

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

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

Конкуренты
Основные:

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

— Конкурент 2
Достоинства: обширное портфолио.
Недостатки: дизайн сайта крайне примитивен, как и навигация.

— Конкурент 3
Достоинства: яркая, хотя и не очень впечатляющая, графика. Много грамотно написанных текстов (встречаются ошибки).
Недостатки: каталог товаров и услуг не проиллюстрированы фотографиями и ценами. приходится качать файлы прайсов.

Дополнительно рассмотрены:

— Конкурент 4
Достоинства: достаточно интересный классический дизайн
Недостатки: внутренние страницы, в частности по сувенирке, не проработаны. масса странных ссылок и страшных фотографий

— Конкурент 5
Достоинства: нет.
Недостатки: скучный дизайн, примитивное оформление страниц

— Конкурент 6
Достоинства: удачный дизайн с применением флеш-элементов. Персонажики повсюду. Применены разумно. Много различного контента.
Недостатки: сайт не растягивается, что портит неплохой дизайн (половина экрана белая), внутри проблемы со структурой страниц.

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

— Конкурент 8
Достоинства: яркий и простой дизайн с применением флеш-анимации. Простая и понятная навигация.
Недостатки: шрифты страниц неконтрастны, плохо читаемы.
Хороший дизайн и концепцию испортили наполнением.

— Конкурент 9
Достоинства: проработанный дизайн, множество иллюстраций
Недостатки: внутри сайта нет фотографий, тексты смотрятся слепыми

— Конкурент 10
Достоинства: яркий дизайн, качественное наполнение, удачная флеш-анимация.
Недостатки: нет

— Конкурент 11
Достоинства: любовно и старательно наполнен
Недостатки: некоторые странные решения по дизайну и огрехи по наполнению
В целом очень достойно

— Конкурент 12
Достоинства: яркие страницы, простой и хорошо структурированный каталог.
Недостатки: глаза устают.
Сайт абсолютно классический, на твердую 4.

— Конкурент 13
Достоинства: флешка красивая.
Недостатки: крайне неприятная цветовая гамма, наполнение сделано странно.

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

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

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

Слоган для использования на сайте:
главная ценность нашей компании — наши клиенты

Сайты, на стиль исполнения которых следует обратить внимание, т.к. они нравятся заказчику:
www.alfa-suvenir.ru
www.elenara.ru
www.tipograf.info
www.vremenagoda.biz
www.viveska.info
www.emotiondesign.ru
www.driada-pr.ru — не открылся
www.corporative.ru
www.credo-positive.ru

Образцами можно считать:
alfa-suvenir.ru — да
www.viveska.info — да, построение шапки, стиль оформления текстов и меню
www.vremenagoda.biz — да, структура страницы. можно использовать как образец при наличии исходных материалов для создания коллажей. создание иллюстраций не включается в разработку сайта

Пункты меню главной страницы:
О компании
Новости
Услуг
Портфолио
Контакты
Полезно знать (статьи о рекламе)
Заказать

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

На всех страницах — шапка, меню, логотип.

Первое предлагаемое решение по созданию дизайна сайта.
Сайт создается как растягивающийся на любую ширину страницы.
1. Стартовая и внутренние страницы имеют разную структуру. общие цвета: белый/кремовый, оранжевый, гамма синего, буквы черные.
2. Стартовая страница:
— содержит крупный логотип (до 25% высоты сайта) и в качестве шапки цветовую полосу (может быть неправильной формы) с блоками, иллюстрирующими направления деятельности (или конкретные работы) компании
— имеет структуру, собранную из информационных блоков: о компании, наши преимущества, что умеем, полезно знать, последние работы, наши услуги, новости, баннер перехода на форму, возможно еще что-то (скомпоновано по принципу www.ra-alterego.ru/?id=manufacture). Каждый блок построен по принипу вынесения главного или самого современного. Все блоки одного размера. В будущем возможно расширение и обновление сайта путем замены одного блока на другие.
2. Основные страницы (портфолио, клиенты, новости, услуги):
— логотип и шапка имеют меньшую высоту (10-15%), шапка содержит коллаж из работ или иллюстрацию (при наличии)
— имеют трехколоночное построение (лого, шапка, вертикальное меню, поле дополнительной иформации). В поле дополнительной информации выводятся небольшие блоки информации, которая может быть интересна при просмотре раздела (в новоястях-портфолио, в клиентах-услуги и т.п.) или блоки, аналогичные блокам на главной.
3. Внутренние и текстовые страницы имеют двухколоночное представление: шапка+меню+текст страницы.
4. Наобходимо придумать визуальное решение, позволяющее подчеркнуть широкий спектр оказываемый услуг и собственную производственную базу.

Второе предлагаемое решение по созданию дизайна сайта.
Идея решения заключается в использовании в дизайне в качестве рамки символов печати (штампа), сувенирной продукции, других примеров продукции компании. Сайт будет иметь фиксированную ширину. По периметру располагаются графические элементы, созданные на основе графики продукции компании (печати, буклеты, сувенирка).
По высоте сайт растягивается либо путем добавления белого пространства слева и справа по периметру, либо повторяющегося рисунка.
1. Стартовая и внутренние страницы имеют разную структуру. общие цвета: белый фон, графика фона с приглушенными серо-сине-желтыми тонами, заголовки в гамме синего, буквы черные.
2. Стартовая страница:
— содержит крупный логотип (до 25% высоты сайта) и левое текстовое меню с графическими маркерами (стиль как на www.viveska.info)
— имеет структуру, собранную из вертикально следующих информационных блоков: о компании, наши преимущества, что умеем, полезно знать, последние работы, наши услуги, новости. Каждый блок построен по принципу вынесения главного или самого современного. Все блоки одного размера. В будущем возможно расширение и обновление сайта путем замены одного блока на другие.
Под меню можно разместить ленту работ.
2. Основные страницы (портфолио, клиенты, новости, услуги):
— логотип имеет меньшую высоту (10-15%), левая колонка содержит коллаж из работ или иллюстрацию (при наличии)
— имеют двухколоночное построение (лого вертикальное меню).
3. Внутренние и текстовые страницы имеют двухколоночное представление: шапка+меню+текст страницы.

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

бесплатных шаблонов веб-сайтов | TemplateMonster

Все продукты
  • Шаблоны веб-сайтов
    • Магазин WordPress
      • Темы WordPress
      • Темы WooCommerce
      • Торговая площадка для Elementor
      • Техническое обслуживание WordPress
    • HTML-шаблоны
      • HTML5-шаблоны
      • Шаблоны страниц
      • Шаблоны страниц для администрирования
      • Specialty Pages
      • Muse Templates
    • E-commerce Templates
      • Shopify Themes
      • Magento Themes
      • PrestaShop Themes
      • OpenCart Templates
      • MotoCMS
      • 000 Templates
      • 000
      • 000
      • 000
    • Шаблоны CMS
      • Шаблоны Joomla
      • Шаблоны Moto CMS 3
      • Темы Drupal
      • HTML шаблоны Moto CMS
    • Популярные категории
      • Софтверная компания HTML Шаблоны
      • Строительные шаблоны HTML
      • Шаблоны бизнес-сайтов
      • Шаблоны туристических веб-сайтов
      • Бизнес-шаблоны WordPress
      • Шаблоны веб-дизайна
      • Медицинские шаблоны WordPress
      • Темы WordPress для новостей и журналов
      • Шаблоны HTML для зоомагазинов
      • Консультации по темам WordPress
      • Шаблоны для рекламных агентств
      • Темы для ювелирных магазинов Shopify
      • Темы WordPress для разработчиков программного обеспечения
      • Темы Shopify для автозапчастей
    • Категории веб-сайтов
      • Искусство и культура
      • Животные и домашние животные
      • Дизайн
      • Образование и книги
      • Бизнес и услуги
      • Автомобили и мотоциклы
      • Компьютеры и Интернет
      • Шаблоны электроники
      • Развлечения, игры и ночная жизнь
      • Дом и семья
      • Мода и красота
      • Foo d & Restaurant
      • Праздники, подарки и цветы
.

Профессиональное программное обеспечение для морской навигации

Совместимость с картами S-63

Своевременное обновление карт является важным элементом обеспечения безопасности всех, кто находится на море. TZ Professional теперь совместим с официальными зашифрованными картами S-63. Графики S-63 обновляются каждую неделю. Эти карты соответствуют стандарту S-52, разработанному Международной морской организацией (IMO). Иконка предлагает упрощенное отображение, чтобы улучшить читаемость морских карт на экране.

Новое расширенное управление маршрутами

Планирование маршрута имеет первостепенное значение для всех профессий на море.

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

Новое окно профиля, замечательный новый инструмент!

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

Fishing Workspace

Рабочее пространство, предназначенное исключительно для профессиональных рыбаков, позволяет персонализировать 2D / 3D, поэтому сначала отображается доступ к наиболее важной информации.

Новые функции AIS

Конфигурация AIS иногда может оказаться сложной. Наш новый модуль AIS позволяет полностью настраивать всю информацию непосредственно в TZ Professional (статус, пункт назначения и т. Д.).). Кроме того, теперь можно получать и отправлять текстовые сообщения AIS от TZ Professional. Эта система позволит упростить общение, бесплатное и индивидуальное, со всеми лодками, оборудованными АИС.

Защитный конус

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

.

Танзания 10 ведущих хостинговых компаний. Лучшие провайдеры в ТЗ

TZ country flag Команда WHTop ведет уникальный список из 10 ведущих веб-хостинговых компаний (из 25 в списке) с таргетингом Танзания , по сравнению с Alexa Rank . Текущее население Танзании составляет 53 950 935 (# 26 в мире) с 6 822 754 пользователей интернета ( 13 % населения и # 51 во всем мире).Этот список часто обновляется (последнее обновление 8 августа 2020 г.) и дает вам беспристрастную и беспристрастную информацию о лучших веб-хостингах в Танзании (включая отзывы пользователей / клиентов).

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

Провайдер веб-сайтов Продукты Профиль
Рейтинг пользователей
Социальные ссылки Домены Alexa
/ Links
duhosting.co.tz Icon Дудумизи
(Дар-эс-Салам)
5 продуктов о доменах, реселлерском хостинге, общем хостинге.Платформа Linux. Ценовой диапазон 22 000 — 140 000 тенге. Последнее обновление 30 января 2020 г.
Язык (-и) веб-сайта: zh-CHS en-GB sw-KE
Сделано
& check; Описание компании в порядке
& check; Адрес компании полный
& check; Добавлен телефон / факс компании
& check; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса «О странице» или «Контактная страница».
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
& check; Продукты (планы) добавлены, но некоторые из них не обновляются более 2 лет.
Примечание: добавьте акцию или купон
Всего отзывов: 1
Средняя оценка: 10 / 10
Хорошие отзывы : 1
Плохие обзоры : 0
Официальные ответы: 0

298914/4
yatosha.com Icon Yatosha 12 продуктов в облаке, домены, реселлерский хостинг Электронная почта, общий хостинг.Платформа Linux. Ценовой диапазон 15 000 — 180 000 тенге. Последнее обновление 26 января 2020 г.
Язык (-и) веб-сайта: en-US
Что сделано
& check; Адрес компании полный
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
& check; Добавлены продукты (планы)
Примечание: добавьте акцию или купон

Что нужно сделать
& cross; Описание компании слишком короткое.Минимум 500 символов
и крестик; Отсутствует номер телефона / факс компании
& cross; Аккаунт Facebook отсутствует
& cross; URL «О странице» или URL «Контактной страницы» отсутствуют


Всего отзывов: 1
Средняя оценка: 10 / 10
Хорошие отзывы : 1
Плохие отзывы : 0
Официальные ответы: 0

776 657/26
extremewebtechnologies.com Icon Extreme Web Technologies
(Дар-эс-Салам)
16 продуктов по электронной почте, доменам, общему хостингу, сертификатам SSL, Реселлерский хостинг.Платформа Linux. Ценовой диапазон 19 000 тенге — 1,660 000 тенге. Последнее обновление 26 января 2020 г.
Язык веб-сайта: en
Дела выполнены
& check; Примечание. Описание компании краткое. Рекомендуется 1000 символов
& check; Адрес компании полный
& check; Добавлен телефон / факс компании
& check; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса «О странице» или «Контактная страница».
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
& check; Продукты (планы) добавлены
Примечание: Добавьте промоакцию или купон

1,390,665 / 56
webmaster.co.tz Icon Webmaster-TZ Указано 0 продуктов.
Язык веб-сайта: en-US
Дела выполнены
& проверить; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
Примечание. Добавьте промоакцию или купон

Что нужно сделать
& cross; Описание компании слишком короткое. Минимум 500 символов
и крестик; Адрес компании не указан. Должен содержать: улицу, город, почтовый индекс и страну
& крест; Отсутствует номер телефона / факс компании
& cross; URL «О странице» или «Контактная страница» отсутствуют.
& cross; Отсутствуют продукты (планы)



1,555,320/21
empireict.net Icon Empire ICT
(Дар-эс-Салам, Танзания)
4 продукта на доменах, реселлерском хостинге, общем хостинге.Платформа Linux. Ценовой диапазон 22 500,00 — 130 000,00 турецких лир. Последнее обновление 2 марта 2019 г.
Язык (-и) веб-сайта: en-US
Что сделано
& check; Примечание. Описание компании краткое. Рекомендуется 1000 символов
& check; Адрес компании полный
& check; Добавлен телефон / факс компании
& check; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса «О странице» или «Контактная страница».
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
& check; Добавлены продукты (планы)
Примечание: добавьте акцию или купон
Всего отзывов: 1
Средняя оценка: 10 / 10
Хорошие отзывы : 1
Плохие отзывы : 0
Официальные ответы: 0

2,228,128 / 14
untsolutions-tz.com Icon Unt Solutions В списке 0 продуктов.
Язык веб-сайта: en-US
Дела выполнены
& проверить; Добавлен телефон / факс компании
& check; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
Примечание. Добавьте промоакцию или купон

Что нужно сделать
& cross; Описание компании слишком короткое. Минимум 500 символов
и крестик; Адрес компании не указан.Должен содержать: улицу, город, почтовый индекс и страну
& крест; URL «О странице» или «Контактная страница» отсутствуют.
& cross; Отсутствуют продукты (планы)



2,427,232 / 13
routeafrica.net Icon Route Africa
(Dodoma)
4 продукта на виртуальном хостинге, хостинг реселлеров. Платформа Linux. Диапазон цен от 10,99 до 55 000 долларов. Последнее обновление 17 мая 2020 г.
Язык веб-сайта: en
Дела выполнены
& check; Описание компании в порядке
& check; Адрес компании полный
& check; Добавлен телефон / факс компании
& check; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса «О странице» или «Контактная страница».
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
& check; Продукты (планы) добавлены, но некоторые из них не обновляются более 2 лет
& check; Акции добавляются, но некоторые не обновляются за 2 года.
Всего отзывов: 1
Средний рейтинг: 10 / 10
Хорошие отзывы : 1
Плохие отзывы : 0
Официальные ответы: 0

2 626 624/2
WebsiteHosting.co.tz В списке 0 товаров.
Язык веб-сайта: en
Сделано
& проверить; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
Примечание. Добавьте промоакцию или купон

Что нужно сделать
& cross; Описание компании слишком короткое. Минимум 500 символов
и крестик; Адрес компании не указан.Должен содержать: улицу, город, почтовый индекс и страну
& крест; Отсутствует номер телефона / факс компании
& cross; URL «О странице» или «Контактная страница» отсутствуют.
& cross; Отсутствуют продукты (планы)


4,033,353 / 0
aptus.co.tz Icon Aptus.co.tz
(Дар-эс-Салам, -)
В списке 0 продуктов. Сделано
& check; Адрес компании полный
& check; Добавлен телефон / факс компании
& check; Добавлены корпоративные учетные записи Twitter и Facebook
Примечание. Добавьте промоакцию или купон

Что нужно сделать
& cross; Описание компании слишком короткое.Минимум 500 символов
и крестик; URL «О странице» или «Контактная страница» отсутствуют.
& cross; Форум, Блог / Объявления, База знаний или URL-адреса часто задаваемых вопросов отсутствуют.
& cross; Отсутствуют продукты (планы)



221 +1 8 631 694/39
cloudy360.com Icon Облачно 360
(Дар-эс-салам)
4 продукта на общем хостинге. Платформа Linux. Ценовой диапазон TZS 50.000 — 120 000 тенге. Последнее обновление 19 апреля 2018 г.
Язык (-и) веб-сайта: en-US sw-KE
Сделано
& check; Описание компании в порядке
& check; Адрес компании полный
& check; Добавлен телефон / факс компании
& check; Добавлены учетные записи компании Twitter и Facebook
& check; Добавлены URL-адреса «О странице» или «Контактная страница».
& check; Добавлены URL-адреса форума, блога / объявлений, базы знаний или часто задаваемых вопросов.
& check; Продукты (планы) добавлены, но некоторые из них не обновляются более 2 лет
Примечание: Добавьте промоакцию или купон
Всего отзывов: 2
Средний рейтинг: 10 / 10
Хорошие отзывы : 2
Плохие отзывы : 0
Официальные ответы: 0

8,958,316 / 135
.

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


Вы хотите изменить дизайн своего сайта?

Мы создаем необычные веб-сайты с отличным и ярким веб-дизайном. Мы делаем веб-дизайн на веб-сайтах с нашей командой веб-дизайна и разработки веб-сайтов. У них разные навыки, чтобы создавать красивый веб-сайт для клиентов. Будь то промо-сайт для бизнеса,

Читать далее
Веб-сайт и печатные СМИ — Контактное лицо:

+ 91-9500009990

+ 91-9444488270

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

  • Понедельник суббота

    8.00 — 22.00

  • Воскресенье

    День отдыха


Вы хотите изменить дизайн своего сайта?

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

.

Подробнее

Создание веб-сайтов Ченнаи — Мы создаем отличный профессиональный дизайн веб-сайтов и профессиональные услуги SEO по невысокой цене. Услуги по созданию веб-сайтов со 100% удовлетворением. Качественное и своевременное обслуживание.

Создание веб-сайта Ченнаи

Создание веб-сайтов Ченнаи

Автор: admin | Метки: Интернет сайт, Дизайн, Логотип, Веб-страница

Создание дизайна веб-сайтов chennai — India — это профессиональная компания, занимающаяся дизайном веб-сайтов, предлагающая экономичные веб-сайты мирового класса для различных предприятий в

странах. ЧИТАТЬ ДАЛЕЕ
Создание веб-сайтов Ченнаи

Автор: admin | Метки: Интернет сайт, Дизайн, Логотип, Веб-страница

Мы предлагаем множество веб-сервисов, таких как разработка шаблонов, дизайн веб-сайтов, SEO-услуги, дизайн логотипов, дизайн статических веб-сайтов, услуги SEO на странице / вне страницы, Flash-баннеры и многое другое….

Профессиональные веб-сайты 100% профессиональная гарантия — Профессиональный дизайн веб-сайтов chennai — статическая компания по разработке веб-сайтов, предлагающая доступные профессиональные услуги веб-сайтов chennai ….

ЧИТАТЬ ДАЛЕЕ
Удалить фон — ретушь

Автор: Faizel | Теги: Графика, иллюстрация, Логотип, Ретуширование, Коррекция цвета

Наша служба удаления фона идеально подходит для изображений — Удалить фон | Белый фон | Прозрачный фон | Пользовательский фон | Отсечения путь | Маскировка

ЧИТАТЬ ДАЛЕЕ
Новый веб-сайт и редизайн веб-сайта Ченнаи

Автор: admin | Теги: Графика, иллюстрация, Логотип

Мы создаем отличный профессиональный дизайн веб-сайтов и профессиональные услуги SEO по невысокой цене.Услуги SEO со 100% удовлетворением.

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

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

Теги: создание сайта в Ченнаи, создание сайта в Индии, создание сайта в Тамилнаду, создание сайта в Old Washermenpet

ЧИТАТЬ ДАЛЕЕ

Клиент — Отзывы

г.Rahul
ВЕЧЕРИНКА BIG BANG В ИНДИИ

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

007 Индия
Детективное агентство в Ченнаи

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

A1 Mobile City
Мобильный магазин в Ченнаи

Static Web Creation «Абсолютно превосходно. Отличная творческая работа и разработка с полным пониманием процесса создания и вниманием к деталям. Мне бы очень хотелось поработать с A1mobile city., Спасибо за хорошо выполненную работу.

Наши основные услуги

КОМПАНИЯ ПО СОЗДАНИЮ ВЕБ-САЙТОВ В ЧЕННАЕ

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

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

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

Анализ дизайн Уточнить казнить

Пакеты веб-дизайна


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

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

  • Отлично адаптивный веб-сайт
  • 5 страниц сайта, в том числе домашняя
  • Многослойный Photoshop PSD
  • Заголовок JQuery
  • Фотогалерея
  • Ваш логотип, графика и баннеры
  • HTML5 / CSS 3
  • XML карта сайта
  • Карта сайта
  • Представление поисковой системы
  • Настройка учетной записи FB и фан-страницы
  • БЕСПЛАТНОЕ создание учетной записи Twitter
  • 300 МБ дискового пространства (ежемесячно)
  • Пропускная способность 3 ГБ (ежемесячно)
  • Мета-теги для каждой страницы
  • Веб-хостинг (бесплатно только 1 год)
  • Бесплатное обслуживание в течение одного месяца
  • Базовая оптимизация страницы Бесплатно
₹.9 500 индийских рупий
  • Отлично адаптивный веб-сайт
  • (15 долларов США / 1000 индийских рупий за страницу)
  • Купленный шаблон (опция)
  • Домашняя страница
  • Создание БЕСПЛАТНОЙ фан-страницы на Facebook
  • Фотогалерея
  • Ваш логотип, графика и баннеры
  • HTML5 / CSS 3
  • XML карта сайта
  • Карта сайта
  • Представление поисковой системы
  • Настройка учетной записи FB и фан-страницы
  • БЕСПЛАТНОЕ создание учетной записи Twitter
  • Мета-теги для каждой страницы
  • Веб-хостинг (бесплатно только 1 год)
  • Бесплатное обслуживание в течение одного месяца
  • Поисковая оптимизация всех страниц
  • Платеж за базовую оптимизацию страницы
₹.1000 / — INR
  • Отлично адаптивный веб-сайт
  • 8-10 страниц, включая домашнюю
  • Многослойный Photoshop PSD
  • Заголовок JQuery
  • Фотогалерея
  • Ваш логотип, графика и баннеры
  • HTML5 / CSS 3
  • XML карта сайта
  • Карта сайта
  • Представление поисковой системы
  • Настройка учетной записи FB и фан-страницы
  • БЕСПЛАТНОЕ создание учетной записи Twitter
  • 500 МБ дискового пространства (ежемесячно)
  • Пропускная способность 5 ГБ (ежемесячно)
  • Мета-теги для каждой страницы
  • Веб-хостинг (бесплатно только 1 год)
  • Бесплатное обслуживание в течение одного месяца
  • Базовая оптимизация страницы Бесплатно
₹.13 500 индийских рупий
  • Отлично адаптивный веб-сайт
  • От 15 до 20 страниц, включая домашнюю
  • Многослойный Photoshop PSD
  • Заголовок JQuery
  • Фотогалерея
  • Ваш логотип, графика и баннеры
  • HTML5 / CSS 3
  • XML карта сайта
  • Карта сайта
  • Представление поисковой системы
  • Настройка учетной записи FB и фан-страницы
  • БЕСПЛАТНОЕ создание учетной записи Twitter
  • 500 МБ дискового пространства (ежемесячно)
  • Пропускная способность 10 ГБ (ежемесячно)
  • Мета-теги для каждой страницы
  • Веб-хостинг (бесплатно только 1 год)
  • Бесплатное обслуживание в течение одного месяца
  • Базовая оптимизация страницы Бесплатно
₹.25 400 индийских рупий

Пакеты для разработки веб-сайтов для частных лиц

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

Интересные веб-сайты для бизнеса

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

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

Стоимость пакетов для создания веб-сайтов

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

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

Услуги компании по созданию веб-сайтов

  • Дизайн веб-сайтов и веб-шаблонов

    Разработка веб-сайтов и поисковая система оптимизируют услуги для бизнеса любого уровня.Для получения более подробной информации свяжитесь с нами.

  • Профессиональные услуги SEO в Ченнаи

    веб-услуг, таких как дизайн шаблонов, создание дизайна веб-сайтов, дизайн веб-страниц, дизайн логотипов, статический дизайн веб-сайтов и многое другое … ПОДРОБНЕЕ

  • Удаление фона и ретуширование

    Одежда и аксессуары, Обувь и обувь, Ювелирные изделия и часы, Мода и сумки, Электроника и игрушки, Мебель, Дом и кухня, Автомобильная промышленность и промышленность ПОДРОБНЕЕ

  • Создание логотипа и редизайн логотипа

    Создайте свой собственный логотип.Если вы довольны своим дизайном, простое решение для владельцев бизнеса, стартапов и интернет-компаний. УЗНАТЬ БОЛЬШЕ

  • SEO Onpage — Оптимизация Offpage, создание веб-сайтов chennai

    10 декабря, 2013-18: 33:04

    SEO Services в Ченнаи — Веб-дизайн и поисковая система оптимизируют услуги для всех уровней потребностей бизнеса.Для получения более подробной информации свяжитесь с нами. УЗНАТЬ БОЛЬШЕ

,