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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что собой представляет техзадание

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

Для чего оно необходимо

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

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

Кто должен заниматься составлением ТЗ, написанием технического задания для сайта

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

Так, заказчик в первую очередь пытается сделать следующее:

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

Разработчик стремится:

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

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

Бриф на разработку ресурса

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

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

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

Четкость формулировок

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

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

Структура техзадачи

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

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

Из чего состоит техническое задание на разработку сайта: образец

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

Пункты ТЗ	О чем писать	Варианты заполнения
БИЗНЕС-ТРЕБОВАНИЯ
Сведения об организации	Наименование, изделия, услуги, вид деятельности, конкуренты, достижения, дата регистрации.	Компания «Молтехникс». Производство оборудования по переработке молока. Основана в 2012 г. Обладатель премии «Товар года». Конкуренцию составляют: «Млечный путь», «Ферм Строй».
Целевая аудитория	Как можно подробнее опишите контингент, который планируете видеть на страницах. Укажите их предполагаемое место жительства, уровень дохода, возрастные характеристики.	Индивидуальные предприниматели, выпускающие молочную продукцию. Фермерские хозяйства. Мужчины и женщины в возрасте от 30 до 55 лет. Занимаются сельскохозяйственной деятельностью, проживают на территории Российской Федерации. Имеют средний доход и выше.
Цели веб-ресурса	Что Вы хотите получить от посетителей своей страницы? Оформить заказ, связаться с сотрудником компании по внутренней связи, подписаться на рассылку. Когда цель не одна, лучше обозначить все сразу. Данный пункт можно смело назвать основным. Именно на базе него строится формирование дизайна, функциональных возможностей и осуществляется наполнение контентом.	Пользователи должны активировать подписку. Заказывать наши товары. Оставлять отклики об использовании продукции.
Анализ имеющегося сайта	Предоставьте на него ссылку и расскажите о плюсах и минусах по вашему мнению.	Имеющиеся сведения на ресурсе нельзя обновлять или редактировать. Интерфейс слишком сложен для пользователей.
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
Начальная структура	Что из основного обязано быть в наличии.	Домашняя (сведения об организации, место деятельности, проводимые акции). Каталог; Блог; Новости; Контакты.
Структурирование страниц	Какие детали должны быть и примерное место их размещения.	Поисковая строка, Телефон для связи, окно диалога с оператором компании, перечень проводимых акционных мероприятий. Сбоку список подразделов каталога, форма для подписки.
Пожелания по оформлению и дизайну	Предпочтительный цвет, стилистика, шрифты.	Веб-сайт больше в дружеском стиле. Основная палитра: синий, голубой, бирюзовый, белый. Верх и низ темнее, центр светлый. В качестве изображений фотографии, иллюстрирующие деятельность.
Прилагающиеся наработки	Ссылки на образцовые ресурсы, фото, буклеты, журналы.	Выделено архивом.
Разрешение и изображение	Обозначьте, с какого устройства должны просматриваться страницы.	Мониторы ПК от 19 до 27 дюймов; Ноутбуки от 15,6 до 17,3; Смартфоны от 3,5 до 6; Планшеты от 7 до 12.
Целесообразность мобильной версии		Нужна.
Приблизительные перечень модулей	Укажите, что хотите видеть на своей странице. Фильтры каталога, возможность сделать онлайн-заказ и т.д.	Распределение товарных позиций по стоимости, в алфавитном порядке. Консультация предполагаемым покупателям.
Администрирование	Опишите, какие корректировки Вы должны вносить самостоятельно. Выясните как именно это делается.	Доступны все действия с товарными карточками, возможность публикации новостей, акционных предложений.
Подключение платежных систем	Укажите предпочтительные.	Необходима консультация разработчика.
Возможности интеграции		Интегрирование с Мегапланом и 1С.
ИНТЕРНЕТ-РЕСУРСЫ
Обзор	Оптимально будет привести примеры в виде ссылок, что нравится, а что категорически нет.	adme.ru— меню tobiafran.com — анимация загрузки anotherstate.co — шрифты.
ДОПОЛНЕНИЯ
Вопросы к исполнителю	Если что-то непонятно, сразу спрашивайте в письменной форме. Так удастся избежать недопонимания.
Пожелания	В эту графу следует внести все, что не было затронуто в предыдущих позициях.

 

Предпроектное проектирование

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

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

Примерное составление (структура)

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

«Домашняя» (главная) страница

• Отдел «Меню» с основными разделами и всплывающим перечнем подразделов.
• Логотип и рекламный лозунг (слоган).
• «Главная».
• «Проекты».
• «Каталог изделий» с выдаваемым списком составляющих.
• «Деятельность».
• «Об организации».
• «Клиентам».
• «Информация».
• «Контактные данные».
• Ссылка на скачивание в формате pdf.
• Телефонный номер компании.
• Клавиша «Заказ звонка».
• Отдел «Слайдер» с фото в ширину дисплея и кнопкой обратной связи.
• Блок «Преимущества».
• «Товары» с обязательным описанием плюсов.
• «Организация в цифрах» с указанием достижений, продаваемых объемов и т.д.
• «Видеоруководства».
• «Подвал».
• Контактная информация.
• Ссылки на соцсети компании.

Лайфхаки как написать, составить тз для сайта

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

Где взять образцовые варианты

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

Параллельно стоит сформировать собственные подборки с понравившимися референсами. Будет очень удобно пользоваться ими в перспективе.

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

Как определить цветовую гамму

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

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

Как подобрать шрифты

Немаловажный аспект. От их качества (читаемости) и соответствия общему дизайну во многом зависит понимание информации пользователями. Обязательно пропишите в техзадании конкретные пожелания. Коллекцию Word можете смело не рассматривать. Все, что в ней имеется, уже многократно использовано до Вас. Лучше обратите внимание на сетевую библиотеку allfont.ru.

Как писать шаблон ТЗ, составлять техзадание для сайта правильно: основные ошибки

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

Не указано отведенное время

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

Потеряны данные доступа

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

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

Отсутствие наглядности

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

Качественные прилагательные

При составлении техзадачи старайтесь избегать использования слов, обозначающих неточные характеристики предметов. Например: красивый, умный, сильный, современный и т.д. Помните — только конкретика: «На два оттенка темнее», «Укоротить на 4 см», «Округлые края у кнопки». Опять же, у каждого человека собственное представление о красоте, силе, современности и иных сравнительных параметрах.

«На усмотрение исполнителя» 

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

Заключение

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

Техническое задание на разработку сайта – Пример составления ТЗ на сайт

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

• Общее описание проекта;
• Цели и задачи;
• Функции;
• Глоссарий терминов;
• Данные и списки;
• Описание страниц;
• Технические требования;
• Наполнение сайта;
• Сдача проекта.

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

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

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

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

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

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

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

Описания страниц. Этот раздел содержит краткие описания страниц: главная страница содержит рекламный слайдер, список товаров «Новинки», текст о компании и т.д. Дополнит этот раздел можно макетами страниц.

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

Наполнение сайта. На этапе составления ТЗ нужно определить, кто будет заполнять сайт контентом. Это может сделать исполнитель или заказчик. Если заполнением сайта занимается исполнитель – нужно прописать: кто именно готовит контент, объем работы.

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

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

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

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

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

Зачем нужно ТЗ и что в него входит?

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

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

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

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

Технические параметры

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

Начинается все с выбора CMS. Он определяется тем, каким планируется сайт. Будет ли это одностраничник или значительное структура. Каковы требования к сложности дизайна. Подойдет ли бесплатная платформа, или надежнее воспользоваться платной.

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

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

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

Маркетинговый блок

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

• специфику продукции, реализуемой магазином,
• целевую аудиторию,
• особенности восприятия ею именно этой категории товаров.

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

Внешний вид

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

• шрифтов,
• цветовой гаммы,
• звуковых эффектов,
• расположения окон.

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

Этапы разработки ТЗ

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

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

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

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

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

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

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

Где найти пример хорошего ТЗ?

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

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

Подводим итоги

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

Техническое задание (ТЗ, техзадание) на разработку сайта. Образец, пример ТЗ.

С чего начать? Образец ТЗ на разработку сайта.

Любое техническое задание на разработку сайта начинается с изучения бизнеса заказчика, специфики тех услуг и товаров, которые он предлагает, изучения конъюнктуры рынка, и того контента, который уже имеется. Если всего это не знать, не прочитать информацию, которая впоследствии будет размещена на сайте, не понимая, как надо будет систематизировать информацию на сайте и обрабатывать, разработать качественное техническое задание просто не получится. В любом случае, заниматься разработкой технического задания, тем более, с смs-системой, должен только специалист – программист. Поэтому есть смысл обращаться сразу к опытным профессионалам, не рискуя бизнесом и деньгами. Но если вы планируете заказать разработку сайта попроще, и сами немного разбираетесь в том, что Без технического задания структура! хотели бы видеть на своем сайте, то есть смысл заняться написанием задания самостоятельно. Важно, чтобы техзадание на разработку сайта было написано корректно, грамотно юридически, понятно для разработчиков, не включало в себя нереальных требований.Можно сказать, что разработка технического задания является важнейшим этапом разработки самого сайта, поскольку без детального письменного описания самых главных моментов и требований к будущему сайту не стоит даже браться за его разработку. Переделывать каждую мелочь не согласится ни один программист, да и стоит ли, не легче ли с самого начала ориентироваться на документ, в котором отображены все пожелания будущего владельца сайта, все обсуждено и договорено. Этим документом и является техническое задание, которое учитывает как интересы заказчика, имеющего возможность описать свое видение сайта, и разработчика, который будет знать, на что ориентироваться, занимаясь разработкой сайта. После того, как прошло согласование технического задание, и его подписали обе стороны, оно считается утвержденным, если впоследствии понадобится внести некие коррективы в утвержденное задание, то они будут внесены по согласовании обеих сторон. Новую редакцию технического задания вновь подписывают обе стороны, далее осуществляется перерасчет стоимости разработки сайта, с учетом внесенных изменений. Кроме того, что для сайта разрабатывается техническое задание, для некоторых сайтов отдельно по желанию клиента разработчики могут отрисовать посредствам специального программного обеспечения пользовательский интерфейс – все станицы сайта, точнее, их прототипы.

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

Техзадание — ТЗ — на разработку сайта

Без предоставления исходных текстов для наполнения, гл.страница сайта будет выглядеть так. Компании-разработчики сайтов устанавливают свои цены на разработку технического задания. В среднем, ТЗ на разработку сайта стоит примерно процентов 8-10 от стоимости самого сайта. Если провести аналогию процесса разработки сайта со строительным процессом, то ТЗ на разработку сайта – это как технический проект строительства. Естественно, стоимость разработки техзадания во многом зависит от финансовых возможностей заказчика, его планов, степени сложности будущего сайта. Этим же, кстати, определяется и срок разработки технического задания. Для грандиозных проектов процесс разработки сайта разбивается на несколько этапов, кроме того, заказчик должен понимать, что не все, что он задумал, получится осуществить – пока заказчики будет мечтать о сайте, его обойдут конкуренты, с более простыми, но эффективными сайтами. Нельзя забывать и о том, что сроки разработки ТЗ не должны быть слишком затянуты, посетителей, в конце концов, волнует не техзадание, а сам сайт и его содержание. Вместе с тем, и скупиться на разработку технического задания нельзя, поскольку оно определяет идеологию будущего сайта в целом.

ТЗ на разработку сайта, например сайта на CMS

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

как написать ТЗ на разработку сайта, пример, образец

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

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

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

Базовая информация о проекте

“Введение” в ТЗ состоит из описания компании заказчика, его продукта, ЦА и ее потребностей, а также поставленных задач. Технические особенности — продолжение первого пункта в виде списка утвержденных технологий и функций. Здесь указывают выбранную CMS или фреймворк и хостинг, а также прописывают требования к адаптивности и кроссбраузерности. Все интеграции, например, с сервисами онлайн-оплаты или 1С тоже размещают тут, чтобы получился базовый чек-лист. Подробнее о разных системах управления контентом и сложности подключения функций заказчику расскажут при подготовке ТЗ.

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

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

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

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

В современных диджитал-агентствах структуру сайта не просто описывают списком или таблицей, но создают UI/UX макет. Заказчик увидит, где расположены блоки на прототипе и посмотрит, как они работают до того, как утвердить ТЗ. Отдельно на этом этапе прописываются сложные сценарии, например, что должно происходить после того, как посетитель нажмет на кнопку “Заказать”.

Дизайн и контент

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

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

Еще 3 совета по составлению технического задания

1. Формулируйте четко. Само название “техническое задание” подразумевает точность и однозначность формулировок. Это значит — никаких качественных прилагательных, например, быстрый или удобный, и абстрактных значений там, где могут быть конкретные. Примеры: вместо “быстрая загрузка страниц” — от 80 баллов по оценке сервиса Google PageSpeed Insights или не больше четырех секунд на отображение каждой. Вместо “удобная функция заказать в 1 клик” — картинка всплывающего окна с полем для текста, местом для ввода телефонного номера и соответствующей кнопкой. Это правило касается даже мелочей — сколько картинок будет в одном блоке, какие статьи на блоге будут показываться сверху, где будет расположена плашка “скидка” и т. д.
2. Описывайте сущности и функции. Чем подробнее ТЗ — тем лучше. Опишите характеристики для каждого вашего товара, статусы, которые будут указываться в истории заказов, в общем все, что может отображаться на страницах сайта. Программисты объединят это в сущности — объекты с определенными атрибутами и методами, которыми просто управлять. Точно так же поступите и с нестандартными функциями. Если нужно подключение кнопок социальных сетей, интеграция с CRM, отправка уведомлений на e-mail или sms — это должно быть прописано в ТЗ.
3. Составьте глоссарий. Клиенты не обязаны знать сложные термины из лексикона разработчиков и дизайнеров, а вот техническое задание должно быть понятно и тем и другим. Конечно, на этапе обсуждения ТЗ, сотрудники диджитал-агентства подробно расскажут, что такое CMS или “футер”, но хорошим тоном считается создать отдельную страницу для заказчика, где он прочтет короткое и понятное описание технологий и функций, использованных в проекте.

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

Разработка технического задания (ТЗ) на сайт по ГОСТ

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

В отличие от ТЗ на АСУ или на программу, нет ГОСТов предъявляющих требования к структуре и содержанию технического задания на изготовление сайтов. Однако, исходя из лучших практик, требования ГОСТов (34.602 и 19.201) очень часто учитывают при оформлении ТЗ. В частности требования ГОСТ 34.602 учитывают при создании ТЗ на портал, интернет-магазин, а ГОСТ 19.201 при разработке ТЗ на сайт-визитку.

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

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

Для чего нужно техническое задание

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

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

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

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

Заказать ТЗ на сайт

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

Руководство по написанию документов спецификации веб-сайтов (обновлено в 2019 г.)

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

Карта сайта

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

Пример базовой карты сайта

Существуют отличные инструменты для создания карты сайта.Мы любим Gloomaps.

Типы контента

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

Некоторые другие распространенные примеры типов контента:

• Люди
• Продукты
• Отзывы

Данные типа контента

Для каждого типа контента должны быть перечислены данные, связанные с этим типом контента.Например, если существовал тип контента «Человек», они могут потребовать следующие данные:

• Имя
• Фамилия
• Должность
• Био
• Адрес электронной почты
• Номер телефона

Таксономия

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

Например, если у вас есть веб-сайт с рецептами, вам может потребоваться таксономия «блюд», в которой термины таксономии будут «завтрак», «обед», «ужин», «закуски», «десерт» и т. Д.У вас также может быть таксономия «кухни» с такими терминами, как «индийская», «британская», «французская» и т. Д.

В блогах наиболее распространенными двумя таксономиями являются «Категории» и «Теги».

Существует два основных типа таксономии:

1. Иерархическая — например, «Категории»
2. Неиерархический — например, «Теги»

Другим примером может быть таксономия «Отрасль», которую вы можете назначить своим типам контента «Блог», «Клиент», «Пример использования» и «Услуга».

Шаблоны страниц

Шаблон страницы — это определенный формат информации. Например, ваша «Домашняя страница», вероятно, будет отличаться от страницы «Контакты».

Ниже приведены некоторые примеры общих шаблонов страниц:

• Главная
• Запись в блоге
• «Наша команда»
• Архив новостей — список всех новостных сообщений сайтов в обратном хронологическом порядке.
• Контакты — могут иметь карту и form

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

Советы по написанию технических требований к веб-сайту

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

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

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

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

Существует аббревиатура спецификации требований к программному обеспечению — SRS. Технические спецификации или спецификации также являются популярным термином для описания требований проекта. Другой термин — документ требований к продукту (PRD) — часто используется как синонимы. Существует также термин Business Requirement Document (BRD), который больше фокусируется на бизнес-перспективах проекта.

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

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

Части документа требований

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

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

Вот хорошая структура для документа требований:

1. Назначение
2. Персоны пользователей
3. Истории пользователей (особенности)
4. Структура сайта
5. Описание страниц
6. Каркасы
7. Нефункциональные требования

1.Назначение товара

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

2. Персоны пользователей

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

3. Пользовательские истории (особенности)

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

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

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

5. Описание страниц

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

6. Каркасы

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

7. Нефункциональные требования

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

Советы по написанию хорошего документа с требованиями

Сделайте его лаконичным и информативным одновременно

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

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

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

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

Передайте на рассмотрение заинтересованным сторонам

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

Позвольте нам помочь вам с вашими требованиями к спецификации!

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

Технические спецификации в веб-разработке и разработке программного обеспечения

доктор Уильям Сен | Генеральный директор и основатель blue media

Как создавать технические спецификации

---

технические характеристики

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

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

Технические спецификации

расположены между проектированием и кодированием в типичном процессе, основанном на спринте, как показано в этом примерном процессе:

1. Каркас
2. Мокап / Дизайн
3. Технические характеристики
4. Кодирование

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

Кто создает технические спецификации?

Создатели технических спецификаций — это в основном обученные инженеры-программисты или менеджеры по программному обеспечению, которые осведомлены обо всех проблемах проекта на протяжении всего процесса.Прежде всего, они должны знать о болевых точках клиента и обсуждаемых решениях. Кроме того, автор технических спецификаций должен хорошо разбираться в UX / UI (пользовательских ожиданиях / пользовательском интерфейсе) и программировании. Он / она должен обладать необходимыми техническими знаниями, чтобы иметь возможность изложить все требования таким образом, чтобы они могли быть точно реализованы в коде.

Работа без технических спецификаций

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

Преимущества технических спецификаций

Всего технических характеристик 7 основных преимуществ:

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

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

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

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

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

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

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

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

   Технические характеристики

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

   Технические характеристики

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

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

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

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

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

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

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

    Технические спецификации

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

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

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

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

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

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

    Однако техническая спецификация может взять на себя более 80% этой нагрузки от менеджера проекта программного обеспечения. Имея хорошо продуманную техническую спецификацию, вам не нужно бояться объяснять проект кому-то заново. Насколько вам известно, вы можете просто передать техническое задание 10 разным кодировщикам и посмотреть, кто из них возьмется за эту работу.Когда программист держит в руке технические спецификации, он уже знает, о чем идет речь. Следующее, что вам нужно сделать, это просто ответить на некоторые из вопросов, которые могли возникнуть, а остальные вы просто поговорите о погоде. Потому что к тому времени об остальном позаботятся технические спецификации. Этот процесс делает вас независимым от программиста. Вы также можете привлечь в проект новых программистов. Это просто красиво.

Заключение

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

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

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

Готовы повысить свой SEO?

Расскажите нам подробнее о своем бизнесе, и мы расскажем, чем мы можем вам помочь!

КАТЕГОРИИ Разработка программного обеспечения Веб-разработка

---

ОБ АВТОРЕ ДокторУильям Сен Генеральный директор и основатель blue media

Уильям Сен занимается поисковой оптимизацией с 2001 года, а с 1996 года — инженером-программистом, а также работал доцентом в Германии в Университете Дюссельдорфа и Кельна. Он принимал участие в разработке специальных инструментов SEO, крупных веб-сайтов и программных проектов. Уильям имеет докторскую степень в области информационных наук и работал с такими брендами, как Expedia, Pricewaterhouse Coopers, Bayer, Ford, T-Mobile и многими другими. Он является основателем синих медиа.

Как написать спецификацию веб-сайта

«Сколько стоит машина?»

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

Когда вы обращаетесь в агентства, вы должны быть вооружены убийственной спецификацией. Вот примерный шаблон, которому нужно следовать при написании своего.

1. Начните с того, что представьтесь

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

• Краткая история
• Размер (количество сотрудников, оборот)
• Ключевые услуги
• Основные достижения
• Заявление о вашей миссии

2. Изложите свои цели

Объяснение их будет определять остальную часть спецификации. Подумайте:

• Зачем вам проект?
• Каких результатов вы хотите достичь — измеримы ли они?
• Есть проблемы с вашим существующим сайтом?
• Каковы бизнес-движущие силы перемен?

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

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

Да, и если у вас есть второстепенные цели — возможно, они заключаются в «привлечении внимания прессы» или «уменьшении количества администратора, связанного с X», — тоже хорошо включить их.

3. Вытяните свою ключевую аудиторию

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

• Потенциальные клиенты / клиенты
• Существующие или постоянные клиенты / клиенты
• Ключевые заинтересованные стороны (отдел маркетинга, сотрудники склада, сотрудники отдела выполнения заказов / администраторы, группы обслуживания клиентов, руководство)

Но они могут также быть:

• Представители прессы
• Перспективные сотрудники
• Любые другие, ключевые сегменты?

Есть их в списке? Теперь для каждой группы подумайте:

• Что они хотят сделать на вашем веб-сайте?
• Что нужно сделать , чтобы они сделали на вашем сайте?

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

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

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

4. Ваши конкуренты

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

Составьте список своих основных конкурентов и отметьте, чем они занимаются. У кого лучший интернет-магазин (и почему)? Кто не так хорош (и в чем причины)?

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

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

5. Структура веб-сайта (не волнуйтесь, она предварительная)

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

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

6. Основная часть: функциональная спецификация

Другими словами, что должен делать сайт?

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

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

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

• «Как клиент, я хочу добавлять товары в свою корзину, чтобы купить их позже»
• сотрудник, я хочу изменить статус заказов, чтобы отмечать отправленные товары «

» Примечание. Если у вас есть необычные требования к функциональности, они особенно важны.

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

7. Теперь перейдем к нефункциональным требованиям.

Не так привлекательно, но, поверьте, вы не захотите их пропустить.

• Удобство использования : есть ли у вас требования к доступности? Если вы (планируете) продавать в США, прочтите это.Можно ли использовать ваш веб-сайт в основном на планшетах? Может, пожилые люди?
• Безопасность : нужно ли вам соответствовать PCI?
• Производительность веб-сайта : насколько важно для вас время загрузки? Если вы занимаетесь электронной коммерцией, ответ — «очень» (и вот почему).
• Legal : существуют ли отраслевые требования соответствия, которым должен соответствовать ваш веб-сайт? Потребуется ли вашим клиентам принимать Условия и положения?

8. Хорошее, плохое и уродливое…

Расскажите об этом: когда-нибудь сталкивались с какими-либо сайтами с элементами дизайна, которые вам не нравились? Или другие аспекты, которые просто … не для вас?

А как насчет тех, что привлекли ваше внимание?

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

9. Слово Б

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

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

Что тебе терять?

10. Пришло время отметить крайний срок

Мы вас умоляем: будьте разумны! Проекты веб-сайтов электронной коммерции могут занять от 6 недель до 6 месяцев.Все зависит от масштабов проекта. 3 месяца — это в среднем.

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

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

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

11. Кратко опишите процесс закупок

При отправке спецификации вашего веб-сайта агентствам четко укажите эти вещи.

• Когда вам нужен ответ?
• Кто будет основным контактным лицом вашего бренда?
• Кто заинтересованные стороны?
• Когда будет принимать решение?
• Есть ли другие ключевые даты для включения?

И, наконец, вот несколько НЕЛЬЗЯ

(или, по крайней мере, старайтесь не делать)

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

С учетом сказанного, удачи и вперед!

Документы функциональных спецификаций: ваше полное руководство

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

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

Получите функциональные спецификации с Justinmind

Скачать бесплатно

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

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

Что такое документация по функциональным характеристикам?

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

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

Что включают в себя документы с функциональными характеристиками?

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

В разделе «Заинтересованные стороны» вы указываете имена и должностные инструкции всех, кто участвует в проекте.

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

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

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

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

Здесь вы указываете, что ваш продукт должен делать, чтобы помочь пользователю и решить бизнес-цели, то есть какие функции он должен иметь.

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

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

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

Отчет об ошибках и обработка исключений

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

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

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

На кого ориентирована документация по функциональным спецификациям?

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

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

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

Роли, участвующие в определении функциональных спецификаций

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

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

Зачем нужна документация по функциональным спецификациям?

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

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

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

Избегает проектирования комитетом: повышает коммуникацию

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

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

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

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

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

Как определить функциональные спецификации

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

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

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

Сядьте вместе с важными членами вашей команды

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

Совместное написание — это способ работать с документами функциональной спецификации, а не работать изолированно.

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

Во-первых, это помогает использовать программное обеспечение с хорошим контролем версий.Многие документы функциональных спецификаций написаны в Microsoft Word, однако Google Docs имеет тенденцию обеспечивать лучший контроль версий, что имеет решающее значение при разработке продукта.

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

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

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

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

Экономьте время — используйте шаблон

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

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

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

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

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

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

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

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

Укажите условие публикации продукта

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

Включите ссылку на прототип, CSS и ресурсы

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

Определите временную шкалу для пользовательского тестирования и развертывания продукта

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

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

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

Шаблоны документов функциональных спецификаций

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

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

2. Шаблон функциональных требований к веб-сайту Smartsheet

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

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

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

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

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

27-страничный шаблон функциональной спецификации

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

Шаблон Кларити позволяет вам вводить спецификации для функций, связанных с манипулированием данными, обработкой данных, вычислениями, условиями и т. Д. Его можно купить на их сайте по цене 9,99 доллара.

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

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

Визуализация функциональных спецификаций и создание документов

Тестирование функциональных спецификаций с помощью прототипов

Знаете ли вы, что вы действительно можете протестировать свои функциональные спецификации и проверить их, когда вы достигнете стадии прототипа?

Используя Justinmind, вы можете быстро и легко протестировать функциональность вашего продукта на своих пользователях, прежде чем перейти к этапу кодирования, используя его в сочетании со встроенными инструментами, такими как UserTesting и Hotjar.Именно этим и занимается одна из наших клиентов, Юдит Казакуберта Баго из Скитля!

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

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

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

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

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

Модуль требований в Justinmind

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

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

Чтобы обеспечить полную видимость всей вашей команды и улучшить совместную работу, Justinmind также позволяет легко интегрироваться с JIRA. Щелкнув по кнопке (точнее: «Файл»> «Экспорт в документ»), вы получите документацию — визуальные элементы и все такое!

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

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

Технические требования для разработки веб-сайтов на заказ. Развитие для масс

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

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

Итак, Спецификация требований (RS) — это свод всех требований к веб-сайту. RS является неотъемлемой частью договора между клиентом и разработчиками: он должен содержать описание всех этапов разработки сайта, суть и задачи разработки, задачи функциональных элементов; должны быть определены правила программирования, ограничения и методы тестирования и оценки проекта. Наличие RS облегчит работу обеим сторонам и позволит проверить конечный результат работы.

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

1. Общие сведения о проекте.
В этой части определены сроки разработки сайта;
дается информация о финансировании проекта;
определен порядок предоставления результатов работы и др.

2. Назначение и задачи сайта.
В этой части определяются цели сайта, описывается вид деятельности, которая должна осуществляться через сайт и т. Д.

3. Характеристики сайта.
В этой части сайта RS описаны условия функционирования и работы, определены ограничения и ограничения (например, по объему хранимой в базе данных информации) и т. Д.

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

5. Структура навигации веб-сайта.
Рекомендуем описать структуру навигации по сайту. Это поможет клиенту увидеть структуру контента и впоследствии правильно ее подготовить.

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

7.Требования к содержанию.
Эти требования могут быть установлены только в том случае, если разработчики берут на себя ответственность за разработку контента сайта. Если вы разрабатываете контент самостоятельно, эта часть RS не имеет значения.

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

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

RS может быть разработан как отдельным специалистом, так и группой. Группа специалистов может быть небольшой (2–5 человек), она должна включать специалистов по маркетингу, интернет-консалтингу и возглавляться менеджером проекта. Идеальный вариант, если в группу входит еще и специалист по маркетингу клиента.

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

By Development for the Mass , ваша компания по разработке решений для Интернет-бизнеса.

Как писать документы по разработке программного обеспечения: с примерами

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

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

* Примечание. * Здесь я описываю небольших клиентов, которые хотят получить от своего разработчика единоличную армию. Это не единственный путь, по которому может пойти фрилансер, и это не единственные клиенты, с которыми мы работаем в Toptal, но это тот путь, который мне нравится больше всего. Конечно, если вы работаете в команде, а не в одиночку, некоторые из перечисленных ниже не применимы. Например, если вы используете методологии Agile или Scrum, вы, вероятно, захотите немного по-другому структурировать свои этапы.

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

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

Вы не можете работать, получив по Skype несколько предложений с кратким описанием и сказав: «Увидимся через три месяца, когда я закончу».

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

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

Итак, когда вы беретесь за новый проект , прежде чем даже откроете Xcode или Visual Studio, вам необходимо иметь четкие и согласованные цели дизайна . И эти цели должны быть установлены в документе спецификации. Если клиент еще не написал его, вам следует написать его и отправить ему на рассмотрение, прежде чем вы даже откроете свою среду IDE.И , если вы встречаетесь с клиентом, который откровенно говорит: «У нас нет времени на проектную документацию», вам следует отказаться от проекта , потому что впереди вас ждут проблемы. Спецификация не должна быть особенно длинной; это может быть всего несколько страниц, но, по крайней мере, он должен содержать макет пользовательского интерфейса, включать каркасы (если есть компонент пользовательского интерфейса) и устанавливать этапы завершения.

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

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

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

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

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

Пользовательский интерфейс

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

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

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

1. Всегда ли элементы управления видны и / или включены? При каких условиях меняются их состояния?
2. Похоже на растровое изображение — это кнопка?
3. Какие переходы происходят между этими состояниями и представлениями? А как их анимировать?

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

Размеры экрана тоже важны. Есть (на момент написания) три размера экранов iPhone. Отдельные каркасы для экранов 3,5 и 4 дюйма, вероятно, излишни, но вам, возможно, придется их сделать; в большинстве случаев можно просто изменить пропорции.

Если ваш клиент предоставляет вам графику, убедитесь, что у нее правильный размер и правильное соотношение сторон; преобразование любого растрового изображения, содержащего текст или объекты (например, круги), приведет к искажениям. Если они не совпадают, попросите клиента воссоздать их с соответствующими размерами. Не думайте, что вы можете растянуть экран-заставку размером 3,5 дюйма до заставки размером 4 дюйма и просто кататься вместе с ним.

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

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

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

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

Вехи

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

Пример спецификации проектирования программного обеспечения

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

Заявление о целях

Включите короткий абзац с описанием проекта и его целевой аудитории.

Функциональное описание

Что делает приложение ? С какими состояниями приложения (высокоуровневыми описаниями основных пользовательских сценариев) столкнется пользователь?

Например, ваше функциональное описание может выглядеть так:

• Первый запуск
• Создание нового _____ (игра, поиск и т. Д.)
• Операции
• Поведение на переднем и заднем плане

Пользовательский интерфейс

Включите каркасы для каждой страницы с подробным описанием:

• Каждый элемент управления, включая состояния (включен / выключен / выделен) и операции.
• Поддерживаемые ориентации и переходы между ними.
• Функциональные возможности представлены.
• Обработка ошибок.
• Размеры и ограничения.

Вот макеты, относящиеся к моему последнему приложению для iOS, NotifEye:

Если вам интересно, я сделал эти макеты с помощью инструмента каркасного моделирования Balsamiq.

Например, описание вашего пользовательского интерфейса может выглядеть так:

• Панель навигации
  • Левый элемент управления навигацией: вернуться на главную страницу
  • Строка заголовка: текущий экран или название операции
  • Новая кнопка: создать новую вещь
• Просмотр таблицы
  • Раздел 0: Название раздела
  • Раздел 0 строк:
    • Контроль ряда 0 (e.г., изображение)
    • Текстовая строка 0
    • Текстовая строка 2

Вехи

Как описано выше, сроки завершения и ожидаемые результаты.

Например, раздел этапов в шаблоне проектного документа может выглядеть так:

1. Фасадное приложение с изображением экрана и с временными переходами и примерами изображений / текста
2. Протокол связи: приложение подключается к сети / серверу
3. Функциональный этап 1:…
4. Альфа-приложение (с полной функциональностью)
5. Устойчивость
6. Версия

Обеспечение соответствия документации по программному обеспечению

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

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

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

1. Над чем только что работал разработчик?
2. Над чем сейчас работает разработчик?
3. Над чем разработчик будет работать дальше?

.