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

18 ответов на вопрос “Как составить техническое задание на разработку сайта?”

  1. Inkognito Ответить

    Где же я Вам тыкаю-то, уважаемый?)
    Предложения, где обращение идет к Вам – на Вы:)
    Не синонимы. Одно свободную форму имеет, второе по ГОСТУ.
    Логично, все верно.
    К чему это? Не ясно. Пришли в фирму – Вы полный спектр услуг оказываете.
    Правильно, заплатит в виде проектирования (или агрегации требований по-вашему), но это происходит в процессе работы с Вами. Все верно. Я где-то другое пишу? Я пишу, что заказчик изначально НЕ ДОЛЖЕН приносить никакого ТЗ. Все, именно это в любом предложении.
    О, вот тыкаете, а сами на Вы хотели, как так-то?
    Действительно, про сроки Вы заговорили – какое это отношение к разговору о наличии ТЗ у заказчика имело – я не знаю.
    Опять же тыкаете, давайте будем на Ты? Я рад знакомству, реально зовут Андрей, можете обращаться, рад общаться с умными людьми.
    Отлично, спасибо за просмотр. Я только пытаюсь побороть свое стеснение, поэтому там ничего интересного, но, надеюсь, со временем смогу что-то полезное донести.
    Ну да, закончил универ и сразу на работу. До этого пытался фрилансить)
    Кто ж себя убил? Я всегда занимался самообразованием, а на работе я сидел на жопе в техподдержке и выполнял одни и те же задачи. По факту моя работа текущая мало чем отличается, вопрос только в количестве свободного времени и оплате труда.
    Не всем суждено или хочется в Москву, я живу тут, есть ипотека:) Мне нужно это оплачивать. На работе в 40к это сделать сложно) И как раз на работе я перестал развиваться. Да, была какая-то сетка развития до условного сеньора, но я понимал, что это не то.
    Поэтому выбор на фриланс очевиден. У тебя полно времени, у тебя существенно больше денег, у тебя интересные проекты, общение с людьми.
    Что ты можешь узнать в студии на позиции разработчика?)
    Как с гитом работать?) Так это и так можно.
    Как выполнять задачи от вышестоящего? Ну такой себе опыт.
    В чем убийство-то?) Не вижу не единого плюса в стандартном вебе быть в студии, если ты не ее руководитель.
    У менять есть толковые друзья, которые работают и в Яндексе, и свою фирму держат – я с ними общаюсь и обучаюсь. Такой процесс куда лучше, как по мне.
    Но буду рад услышать иную точку зрения:)

  2. zaza Ответить


    Если Вы читаете эту страницу и являетесь руководителем компании или маркетологом, значит, находитесь гораздо выше уровня «сделайте мне как у этих». И скорее всего, уже не первый раз меняете облик своего сайта.
    О разработке ТЗ на Хабре было много статей. Нужно ли оно, как оно должно быть сделано в студии и т.п.
    Я хочу показать, что перед созданием именно технического задания во многих случаях имеет смысл сделать еще один документ.
    Для начала разберемся с терминами. Это важно!
    Техническое задание — это документ, разработанный заказчиком и утвержденный исполнителем. В нем изложены требования, параметры и основные эксплуатационные характеристики проекта, объекта или системы.
    Чувствуете разницу? Разрабатывать техзадание должен именно клиент, а не веб-студия! И утверждает ТЗ именно студия, а не заказчик!
    В реальности большинство ТЗ на сайт представляет собой внутренний документ веб-студии, в котором техническим языком описаны основные термины, модули и прочие составные части сайта.
    Беда этих технических заданий именно в «техничности». В процессе создания сайта участвуют как минимум: заказчик или его представитель, менеджер студии, дизайнер, верстальщик, программист.
    Каждый из них говорит на своем языке, который другим непонятен. Получается конфликт однозначного понимания требований к сайту. Кстати, этот момент во многих договорах нивелируется пунктом «заказчик не вправе ссылаться на неоднозначность ТЗ».
    А ведь еще есть и конечный пользователь! Про него в контексте ТЗ никто не думает вообще.
    Именно поэтому для передачи разработчику стоит сделать упрощенный для понимания всеми сторонами документ. Наглядный. По сути, это готовый сайт на бумаге. Он лучше помогает понять, что именно с точки зрения бизнеса хочет получить от сайта заказчик, и что нужно посетителю. И объяснить это «на пальцах» веб-студии.
    Несомненно, для создания такого документа нужен специалист со стороны, у которого есть компетенции и в сфере продвижения продуктов/сайтов и в сфере бизнес-аналитики. Такой специалист сможет быть «переводчиком» с технического языка на языка бизнеса и наоборот.

    В чем отличие ТЗ и концепции

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

    Перед созданием концепции

    Первое, с чем нужно определиться, это с объемом аудитории, для которой мы создаем сайт.
    К примеру, нет смысла создавать сложный и подробный интернет-магазин автозапчастей для «ГАЗелей», если вы работаете только в своем регионе, а число машин в нем исчисляется несколькими сотнями. Вряд ли найдется много желающих ежедневно пользоваться вашим сайтом.
    В данном случае одним из вариантов решения будет одностраничник со скачиваемым каталогом запчастей или складских остатков.
    То есть одна из задач концепции – выбрать оптимальное решение (на данный момент). Сэкономить деньги и время на разработку.
    Основное содержание концепции:
    Определить цели. Зачем мы создаем сайт и какие результаты (в цифрах – посещаемость, продажи, звонки) от него ожидаем.
    Определить задачи. Что нужно сделать, чтобы достичь указанных выше целей.
    Определить целевую аудиторию и действия. Здесь речь идет о регионе, в котором вы работаете, секторе экономики и о том, чего ждете от посетителей на сайте (чтобы оформил заказ, позвонил, написал). Действия нужно определить, чтобы их можно было посчитать в системах аналитики.
    Изучить статистику спроса в поисковиках на ваши услуги/продукцию. То, как ищут вас люди, станет основой структуры (списка страниц и разделов) вашего сайта.
    Кроме того, объем спроса (популярность) покажет, чему на сайте нужно уделить больше внимания, а чему меньше. К примеру, если отзывы о вашей продукции ищут всего 50 человек в месяц, то хватит для них одной странички, а если их ищет несколько тысяч – имеет смысл создать полноценный раздел, где для каждого отзывы своя страница.
    Собрать все материалы для сайта – поймем, чего не хватает и сможем ли подготовить эту информацию для передачи разработчикам. Если нет, корректируем структуру и содержание типовых страниц.
    Еще один важный момент, почему информация должна быть готова до создания дизайна. Разработчик почти никогда не представляет, какие именно тексты, видео, фото будут на вашем сайте, а потому делает дизайн так, как считает нужным. В итоге под те же отзывы дизайнер отведет места меньше, чем на самом деле требуется, а сам дизайн «развалится».
    Отрисовать все типовые страницы сайта (главная, контакты, отзывы, каталог и его разделы, карточка товара и т.п.) и описать принцип их работы и взаимодействия с посетителем.
    Изучить конкурентов. Это поможет дополнить структуру или навести на новые мысли об оформлении страниц сайта.
    Создание прототипов страниц — это ключевой момент в концепции. Он является итогом всех изысканий и аналитики, подготовки контента и прочего. Поэтому без примера хотя бы одного прототипа этот пост будет незаконченным.

    Пример описания прототипа одной из страниц сайта

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

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

    Итоги

    Я занимаюсь разработкой подобных документов практически с самого начала работы с сайтами, т.е. с 1998 года. На создание первой версии такого концепта уходит 1-2 дня в зависимости от сложности проекта и используемых инструментов (иногда проще даже на бумаге сделать отрисовку).
    Эффективно использование такого подхода для проектов с 50 страницами и более.
    Что это дает:
    Ставит на место голову с точки зрения «что хочу я, что хочет мой клиент».
    Документ становится основой для маркетинговой стратегии.
    Разговор всех участников процесса идет на одном языке.
    Исключается вариант, когда в итоге получается компания отдельно, сайт отдельно. Сайт является частью бизнес-процессов предприятия.
    Сильно экономит время на больших и сложных проектах.
    Заметно удешевляет проект и сокращает число переделок — а значит, вы запуститесь вовремя и не выйдете за пределы бюджета.
    Готов поделиться с читателями примерами таких концептов. Кстати, как результат: yavitrina.ru
    Такой итог может получиться, если сделать и концепт и грамотное ТЗ для команды разработчиков.

  3. Dule Ответить

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

    Кому-то такой дизайн нравится
    Также в ТЗ надо исключить формулировки наподобие:
    Сайт должен понравиться заказчику. А это будет зависеть от того, что заказчик с утра съел горькую кашу?
    Сайт должен быть удобным. Для кого?
    Сайт должен выдерживать большие нагрузки. А большие это какие? 10 тысяч? 100 тысяч? Миллион?
    Качественный экспертный контент. А какие критерии экспертности?
    Поэтому постарайтесь заменить все неоднозначности как можно более точными формулировками. Например:
    Как не надо

    Как надо

    Сайт должен быстро грузиться
    Любая страница должна получить более 90 баллов в Google PageSpeed Insights
    Сайт должен выдерживать большое количество пользователей
    Сайт должен выдерживать 70 тысяч посетителей одновременно
    На главной странице выводятся статьи
    На главной странице выводится список последних 8 опубликованных статей
    Стильный и приятный интерфейс подписки
    Поле «Оставьте e-mail» и кнопка «Подписаться» с утвержденным дизайном

    Структура техзадания

    Общая информация

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

    Глоссарий терминов


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

    Рекомендуем писать пояснения в инфостиле

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

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

    Требования к работе сайта

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

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

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

    Наполнение каждой страницы

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

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

    Сценарий использования сайта

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

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

    Контент

    Заранее решите кто будет отвечать за наполнение контентом. Сделает ли разработчик все сразу без дополнительной платы; потребует ли он за тексты деньги или заказчик сам будет писать туда заголовки и статьи.
    Распишите, кто за какой контент отвечает
    Критерии оценки качества текстов довольно разнятся. Есть объективные, наподобие воды, количества ключевых слов или повторов. А есть необъективные – наподобие красоты или стиля. Чтобы лучше понимать, что считать хорошим текстом, рекомендуем вам почитать посты про копирайтинг в наших группах в социальных сетях.

    Описание дизайна

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

    Дополнительные соглашения

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

    Резюме

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

  4. Darkdragon Ответить

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

    Описание сути проекта.

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

    Вид, тип и специфика сайта.

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

    1. Описание содержания сайта и предпочтений целевой аудитории.

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

    2. Описание структуры проекта.

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

    3. Дизайн будущего сайта.

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

    4. Технические особенности реализации.

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

    5. Период реализации проекта.

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

    6. Дополнительная информация и приложения.

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

  5. Zanaya Ответить

    Доброго времени суток, уважаемые читатели. Работать над созданием сайта с заказчиком всегда трудно. Клиент, как правило, хочет либо «что-то крутое», либо «ничего необычного, пусть будет как у всех». Абстрактные понятия, согласитесь. Если это ваш первый заказ, то вы даже можете обрадоваться подобным словам: «Круто, мне дают свободу творчества, я могу сделать все что пожелаю». Скажу по опыту, ничего подобного!
    У заказчика свое понимание «крутого» и «как у всех». Вы можете не угадать, попасть не в то настроение или клиент просто решит, что «за такие деньги этому парню (или девушке) можно еще немного поработать». Чтобы такого не происходило, сегодня мы обсудим как составляется техзадание на разработку сайта.

    План действий по работе с заказчиком

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

    В идеале клиента лучше даже оставить на денечек с этими материалами или послать их на почту за несколько дней до встречи. Хотя, на данном этапе заказчик, как правило, не особенно интересуется порталом. Он готов резать правду-матку по факту и заставлять вас переделывать и добавлять что-то новое, но не обсуждать что-либо заранее. Поэтому, единственный выход – спрашивать как можно больше и записывать каждое слово.
    Составление и подписание технического задания.
    Запомните, чем больше бумажек, тем чище попа. Записывайте, составляйте и подписывайте у клиента все, что только можно. Впоследствии вам будет что предъявить. Вообще, прописывая ТЗ сразу представляйте, что вы с клиентом не сошлись во мнениях и отстаиваете свою правоту в суде.
    Мы говорим не о супердорогих проектах, и, я надеюсь, что с заказчиками вам будет везти. Но один дотошный клиент может надолго испортить вам настроение. Вам захочется плюнуть, отказаться от денег, только бы не встречаться с ним больше. Это понятно, но если вы изначально проявляете себя как профессионал, досконально все изучаете и проявляете себя как солидный человек, то этого делать не придется.
    Однажды мне очень повезло. Прежде чем прийти на встречу клиент изучил вопрос, и сам составил не только грамотное ТЗ, но и художественное задание. То есть литературное и подробное описание как оно все должно выглядеть. Моему удивлению не было предела, на что он ответил: «Я считаю, что заказчик сам в первую очередь должен знать, чего хочет, а не мучать специалистов». К сожалению, это редкость, поэтому нам приходится задавать вопросы, прописывать и утверждать.

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

    Чего не должно быть в ТЗ, а что там быть обязано

    По сути техническое задание не должно содержать в себе указаний по поводу самого дизайна. Напишите вы, что на сайте для программиста вы нарисуете клавиатуру, а потом начнется – она не такая, мне хочется, чтобы она была в стиле комиксов и доказывайте потом, что вы не олень. Чем лучше вы проявите себя как профессионал, тем меньше к вам будет претензий!
    Вы сами знаете в каком стиле и что должно быть нарисовано. Перед вами стоит задача: улучшить узнаваемость бренда или мотивировать на отдых в таком-то месте. Как вы будете реализовывать эту задачу – ваши проблемы. Не хватало еще, чтобы заказчик учил вас код писать и рассказывал какими инструментами пользоваться.
    Пусть в вашем ТЗ будет фраза: «Все, что не оговорено выполняется на усмотрение исполнителя». И не обязательно делать эту строчку маленьким шрифтом. Пусть думает заранее, а не начинает мечтать, когда проект уже готов. Конечно же, небольшие изменения вы можете и должны внести. Хорошая репутация – залог будущих клиентов, но иногда заказчик может так достать своими пожеланиями, что жить не захочется.

  6. Line Ответить

    Общая информация о проекте

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

    Эксплуатационное назначение сайта

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

    Функциональное назначение

    Раздел, в котором идет речь о технических возможностях ресурса, а именно:
    Наличие адаптива или необходимости разработки отдельного мобильного приложения.
    Кроссбраузерность сайта, то есть его корректное отображение на самых старых браузерах.
    CMS, или система управления сайтом, например, 1C-Битрикс или WordPress.

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

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

    Сквозные элементы

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

    Уникальные страницы

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

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

    Прочие страницы

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

    Общие пункты

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

    Что даёт техническое задание по созданию сайта заказчику?

    Перечислим основные преимущества ТЗ для заказчика:

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

    Что даёт техническое задание по разработке сайта исполнителю?

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

  7. Твоямамка Ответить

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

    Из чего состоит техническое задание?

    Что включает в себя полноценное техническое задание?
    Структуру будущего продукта. Для разработки CRM – это состав кабинетов пользователей и их функционала (страниц). Структура – это исходный элемент для всех остальных работ по ТЗ.
    Макеты и текстовое описание всего функционала по структуре. Макеты упрощают визуализацию ТЗ и будущего сайта. Это снижает риски недопонимания между заказчиком и исполнителем. Не секрет, что исполнители больше тяготеют к техническому языку, а заказчики – к бизнес-целям. Макеты позволяют общаться на одном языке, оба видят один и тот же интерфейс и разговаривают не на абстрактном уровне, а на уровне элементов, которые одинаково понятны всем – кнопки, таблицы, меню и т.д.
    Требования по интеграции. Если система связана с внешними ресурсами, то вы должны прописать, как именно система будет взаимодействовать с ними и в каком объеме. Хороший пример – это интеграция с 1С. Не пишите в ТЗ «Сделать интеграцию с 1С»! 1С содержит сотни таблиц в базе данных. Очень трудоемко сделать интеграцию всех объектов 1С с приложением и в большинстве случаев не нужно. Лучше указать, какие именно объекты надо синхронизировать с приложением (клиенты, заказы, единицы измерения, товары и т.д.). Указывайте также предпочтительный способ реализации (например, через веб-сервисы), это позволит избежать недоразумений на стадии разработки. Согласен, вы не можете знать всех технических нюансов. В этом плане вам должен помогать исполнитель, который пишет ТЗ. Задавайте ему максимум вопросов по реализации. Его задача – предоставить вам информацию, и на ее основании вы уже решаете, какой вариант выбрать.
    Особые требования. Сюда можно отнести требования по производительности (хотя в некоторых случаях это сложно прогнозировать, т.к. приложение работает не изолированно, а в некоторой среде), требования к браузерам, требования к дизайну и др.
    Насчет браузеров – указывайте список браузеров и версии для которых должно работать приложение. Некоторые авторы с легкой руки пишут такие версии, которые уже не поддерживают такие порталы как ВКонтакте (например IE8).
    Если говорить о дизайне CRM, то главная его задача – не мешать пользователю. На мой взгляд, здесь не нужно придумывать велосипед – можно взять готовый шаблон и использовать его.
    Проработка узких моментов. Если в вашем проекте есть сложные механизмы, то лучше проработать их на этапе ТЗ. Это снижает риски проекта. В случае если не найдется приемлемого решения, то лучше изменить что-то на этапе ТЗ, а не на этапе разработки системы. Почему? Это дешевле. Чем раньше обнаружена ошибка, тем дешевле ее исправить. Самые дорогие ошибки – на этапе эксплуатации. Пример: автоматическая генерация пароля. Вы сделали в начале так, что пароль генерируется слишком простой. В начале проекта поменять это несложно. Теперь представьте, что у вас система запущена, и в ней работают 100 пользователей. Будет довольно непросто сменить всем пароли (поменять данные в базе, оповестить, часть пользователей не поймет что произошло, т.е. дополнительные расходы на техподдержку).

    Как написать ТЗ на разработку сайта: организация процесса

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

    Особенности написания ТЗ

    При обсуждении темы, как написать ТЗ на разработку сайта, также следует упомянуть о случаях, когда очень трудоемко написать ТЗ сразу. Система настолько сложна и быстро меняется, что нет смысла писать сразу большое ТЗ. В этом случае необходимо определить область действия ТЗ при создании торговой площадки. Делайте ТЗ только на какую-то конкретную часть системы, например, на блок «База клиентов» или процесс «Обработка заказа от клиента».
    При этом желательно иметь план внедрения модулей системы. Например, в этом году мы внедрим одни модули, а в следующем – такие-то модули.
    Из опыта вспоминаются ситуации, когда некоторые заказчики хотят выполнить очень большой проект за один этап, например аналог Avito.ru. Желание заказчика понятно – он хочет избежать риска получить часть продукта, а ему нужен целостный продукт. Сам не понимая того, он движет проект к катастрофе, т.к. подобные проекты невозможно сделать одним куском за один раз. Здесь действует цикл «задумка – реализация – получение обратной связи – анализ». Вспомните, Windows не сразу стал тем, что он есть сейчас.
    При этом есть и обратные примеры, когда разработка ведется фрагментарно. Новые функции появляются без всякого плана, спонтанно. Это тоже плохой вариант развития ситуации, поскольку продукт теряет фокус и функции добавляются хаотично.
    Очень важный момент. Обе эти ситуации порождает заказчик, а не исполнитель. Именно заказчик определяет стиль стратегического управления продуктом. Исполнителю остается только разве что пожимать плечами и подчиниться пожеланию заказчика. Помните об этом моменте в своем проекте: если у вас большой проект, то имейте стратегический план развития сайта и не пишите большое ТЗ сразу на всю систему.

  8. VideoAnswer Ответить

Добавить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *