Техническое задание на разработку сайта интернет магазина: Пример технического задания интернет-магазина, скачать ТЗ

Как правильно составить ТЗ для разработки сайта?

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

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

Зачем требуется техническое задание и из чего оно состоит ?

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

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

1. технические характеристики;
2. маркетинговые требования;
3. особенности дизайна.

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

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

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

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

К техническим характеристикам, указанным в техническом задании на создание сайта интернет-магазина, также относятся:

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

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

Маркетинговые характеристики

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

1. уникальные особенности товаров, продаваемых в интернет-магазине;
2. целевая аудитория;
3. особенности принятия данной категории товаров целевой аудиторией.

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

Внешний вид веб-сайта

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

1. шрифты;
2. цветовой массив;
3. Звуковые эффекты;
4. расположение окон.

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

 

Этапы разработки технического задания

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

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

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

1. о компании;
2. о целевой аудитории;
3. предпочтительные разделы, требуемые заказчиком;
4. необходимые конструктивные элементы;
5. предпочтения в дизайне, используемые шрифты, размеры символов.

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

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

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

Где найти наглядный пример технического задания?

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

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

Подведение итогов

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

что разработчик должен знать о вашем бизнесе? – Webpromo

27.07.2022

Редакция: Катя Лифиренко. Автор: Екатерина Лифиренко

---

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

Необходимость заполнения ТЗ перед созданием интернет-магазина сложно переоценить

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

Содержание: 

1. Что включает в себя ТЗ на разработку интернет-магазина?
2. Общая информация
3. Требования к сайту
4. Требования к контенту
5. Функционал
6. Дизайн
7. Маркетинговая информация
8. Выводы

---

Читайте также: Mobile-first дизайн сайта e-commerce. 6 причин почему важно начинать с создания мобильной версии

---

Что включает в себя ТЗ на разработку интернет-магазина? 

ТЗ на разработку интернет-магазина это достаточно объемный файл.

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

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

• Общая информация
• Требования к сайту
• Требования к контенту 
• Функционал 
• Дизайн 
• Поддержка сайта
• Маркетинговая информация 

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

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

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

В чем заключается основная коммерческая деятельность компании?

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

В каких регионах работает ваша компания?

Укажите в порядке приоритетности в каких регионах представлен ваш бизнес. 

Какие ваши конкурентные преимущества?

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

Если команда с вашей стороны?

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

Есть ли старый сайт?

Обязательно оставьте ссылку на старый сайт (если он есть) и опишите что вам в нем нравиться, а что категорически нет.

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

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

Какое впечатление должен производить сайт?

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

Какое количество товаров вы планируете размещать на сайте?

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

---

Читайте также: Сколько стоит разработка интернет-магазина в 2022 году? Критерии стоимости

---

Под какую рекламу должен быть подготовлен сайт?

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

Какая доля продаж идет через формы, корзину, а какая по телефону?

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

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

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

Есть ли у вас уникальный контент, который можно применить на новом сайте?

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

Планируете ли вы писать контент или нужна помощь специалиста?

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

Функционал 

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

Какие разделы должны быть на сайте?

Опишите все разделы, которые должен включать в себя интернет-магазин. Например: Главная, О компании, Каталог, Новости, Цены, Сертификаты, Отзывы, Доставка, Оплата, Вакансии, Акции, Контакты и т.д.

Какие функциональные модули должны быть на сайте?

Укажите важные для вас модули. Например, программа скидок, регистрация, слайдер, онлайн-консультант, калькулятор стоимости, подписка на email-рассылку, отзывы и т. д

Какие нужны статусы по наличию товара?

Укажите нужные статусы. Например, “Нет в наличии”, “Заканчивается” или “Под заказ”. 

В каком формате будет происходить покупка?

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

---

Читайте также: Письма о брошенной корзине: статистика, причины, типы. Исследование Webpromo на примерах украинской e-commerce

---

Какая у вас CRM-система?

Расскажите какой CRM-системой сейчас пользуетесь и нужна ли интеграция с сайтом.

Есть ли домен для нового сайта?

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

Дизайн 

Для того чтобы дизайн интернет-магазина был реализован в соответствии с вашими требованиями, расскажите: 

Какой фирменный стиль компании?

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

---

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

---

Какие сайты вам нравятся?

Приведите 3-6 примеров сайтов, которые вам нравятся и опишите, чем именно.

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

Опишите все свои идеи для интернет-магазина и укажите что категорически вам не нравиться в сайтах e-commerce. 

Маркетинговая информация 

Для разработки интернет-магазин также важно поделиться маркетинговыми данными и ответить на такие вопросы: 

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

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

• Пол
• Возраст
• Образование
• Доход
• Род занятий
• Посещаемые сайты

В идеале составить несколько портретов ЦА. О том как это сделать, вы можете прочитать в нашей статье: Продуктивный маркетинг: Как определить целевую аудиторию для вашей ниши?

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

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

Какие товары приоритетные для бизнеса?

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

Какой процесс покупки?

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

Кто ваши конкуренты?

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

Выводы

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

 

Также читайте другие статьи в блоге Webpromo:

• Виды рекламы в TikTok;
• Спрашиваем эксперта: какой домен выбрать для SEO на международный рынок — локальный или коммерческий?;
• Как изменился рейтинг социальных сетей в Украине и мире: актуальная статистика после 24 февраля 2022 года.

И подписывайтесь на наш Telegram-канал про маркетинг.

 

Подготовка технического задания для проекта по развитию ИТ АКА 6 шагов к новой информационной системе, интернет-магазину или сети

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

1. Кратко запишите справочную информацию о проекте.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

3. Подумайте о требованиях к вашему проекту и запишите их.

 

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

 

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

 

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

 

Чем больше интерфейсов и чем они сложнее, тем выше объем разработок и стоимость проекта.

 

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

 

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

 

4. Затем продумайте и запишите, кто ваши типичные пользователи (персоны).

 

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

 

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

 

5. Если возможно, нарисуйте первоначальный прототип.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

Создайте магазин электронной коммерции с пользовательской историей

Если вы занимаетесь электронной коммерцией, то у вас есть «пользователи» или клиенты, которые используют ваш веб-сайт для покупки продуктов.

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

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

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

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

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

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

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

Следовательно, они обеспечивают быстрое развитие, экономичность и клиентоориентированность.

Анатомия пользовательской истории

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

Пользовательская история состоит из двух основных частей — функции и набора критериев приемлемости. Если история связана с пользовательским интерфейсом, в ней также необходимо указать артефакты UX/UI.

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

Функция

Функция представляет приращение продукта. Следует писать в таком формате: «Как < кто >, мне нужно < что > так что <

3

4 почему 19».

Например: «Как онлайн-покупатель, мне нужно искать товары, чтобы найти те, которые я хочу купить».

Одно только это короткое предложение передает три ключевых элемента информации:

• Кого волнует эта функция? (покупатель)
• Чего они хотят? (для поиска товаров)
• Зачем им это? (чтобы они могли купить немного)

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

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

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

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

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

Критерии приемки

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

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

1. Поиск продукта по названию или категории
2. Просмотр продуктов по категориям
3. Просмотр изображений и подробностей для каждого продукта
4. Добавить в корзину со страниц сведений или поиска

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

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

Артефакты UX/UI

Дизайны UX/UI, созданные для истории, должны быть перечислены в каждой истории как часть разработки истории.

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

Типы пользовательских историй

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

• Истории, основанные на поведении
• Истории, основанные на правилах
• Истории, основанные на содержании
• Истории улучшений
• Истории интеграции
  

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

Истории, основанные на поведении

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

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

В этом примере возможны несколько сценариев:

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

Для каждого сценария нам необходимо определить критерии приемлемости. Используйте простой язык в активном залоге, чтобы указать, что продукт должен делать. Ожидается, что в каждом сценарии будут фразы «КОГДА» и «ТО». Если сценарий зависит от определенного предварительного условия, то сценарию также потребуется фраза «ДАННАЯ».

ДАННЫЙ <ситуационное предварительное условие>

КОГДА <действие пользователя 1> и <действие пользователя 2> и … <действие пользователя n>

ЗАТЕМ <действие продукта 1> и <действие продукта 2> и … <действие продукта n>

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

Критерии принятия: ‍

Сценарий 1: Успешная аутентификация

Когда пользователь вводит правильный адрес электронной почты и пароль и выбирает CTA «войти в систему» ​​

Затем перенаправьте пользователя на домашнюю страницу «Моя учетная запись» и отобразите статус входа в заголовок в заголовке 

Сценарий 2.

Неудачная аутентификация

Когда пользователь вводит неправильную комбинацию адреса электронной почты и пароля и выбирает «вход» CTA

Затем сбросьте поля учетных данных и отобразите сообщение об ошибке «Неправильные учетные данные»

Сценарий 3: Забыли учетные данные

Когда пользователь выбирает CTA «забыли учетные данные»

Затем перенаправьте пользователя на страницу «забытые учетные данные»

Сценарий 4: Зарегистрируйтесь

Когда пользователь выбирает CTA «зарегистрироваться»

Затем перенаправьте пользователя на страницу «регистрации»

Истории, основанные на правилах

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

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

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

Таким образом, критерии приемлемости для этой истории будут выглядеть так:

1) Для поиска продуктов, соответствующих критериям поиска, используйте следующие атрибуты в порядке, указанном ниже.

• Название продукта
• Название модификации продукта 
• Краткое описание продукта
• Подробное описание продукта
• Обзоры продуктов

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

• Название категории
• Краткое описание категории

3) Следует пытаться выполнить как полное, так и частичное совпадение.

4) Для частичного совпадения должно совпадать не менее 3 символов.

5) Игнорировать все стандартные стоп-слова при попытке сопоставления.

6) Используйте синонимы, чтобы найти соответствие. См. <ссылка> для списка синонимов.

7) Для поиска соответствия необходимо ввести не менее 3 символов.

Истории, основанные на содержании

Это истории, связанные с созданием и отображением содержимого.

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

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

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

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

Критерии принятия:

1) Преимущества программы лояльности должны отображаться в виде баннера над заголовком.

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

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

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

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

4) Для каждого пользовательского сегмента должна быть возможность настроить изображение и ссылку при нажатии на изображение.

5) Установите баннер со следующими изображениями и ссылками.

• Анонимный пользователь — <ссылка на изображение> — ссылка на «страницу регистрации»
• Вошедший пользователь, не являющийся участником программы лояльности — <ссылка на изображение> — ссылка на «страницу профиля»
• Вошедший пользователь, который участник программы лояльности, но не имеет баллов лояльности — <ссылка на изображение> — нет ссылки
• Зарегистрированный пользователь, являющийся участником программы лояльности и имеющий хотя бы один балл лояльности — <ссылка на изображение> — нет ссылки

6) Если баннер не был настроен (правильно) для определенного сегмента пользователей, выполните не отображать баннер для этих пользователей.

Истории улучшений

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

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

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

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

Критерии приемлемости:

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

Истории интеграции

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

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

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

Пример 1) Авторизация кредитной карты: «Как покупатель, собирающийся совершить покупку, я должен иметь возможность предоставить данные своей кредитной карты и получить авторизацию, чтобы завершить оформление заказа».

Критерии принятия:

Сценарий 1: Успешная авторизация

Когда пользователь вводит номер кредитной карты, год и месяц истечения срока действия и CVV, выбирает CTA «Вход» и авторизация прошла успешно

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

Затем отобразите сообщение об ошибке «Ошибка платежа» и сбросьте поля платежа

Сценарий 3: Неудачная авторизация — недостаточный баланс -expiry, cvv карты с недостаточным балансом и выбирает CTA «войти в систему» ​​и авторизация не удалась

Затем отобразить сообщение об ошибке «ошибка платежа» и сбросить поля платежа

Сценарий 4: Неудачная авторизация — Мошенничество

Когда пользователь вводит номер кредитной карты, год и месяц истечения срока действия, cvv и выбирает CTA «войти в систему», а авторизация завершается неудачно из-за подозрения на мошенничество

Затем отобразите «страницу ошибки» и сохраните

Сценарий 5: Проблема подключения платежного шлюза

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

Затем отобразите сообщение «Позвоните в службу поддержки клиентов» и сбросьте поля оплаты

Пример 2) Отправка заказа на выполнение: «Как покупатель, совершивший покупку, я должен правильно и своевременно выполнить свой заказ, чтобы мне не приходилось обращаться в службу поддержки клиентов».

Критерии принятия:

1) Отправьте информацию о заказе в систему выполнения в течение 30 минут после того, как покупатель завершит процесс оформления заказа

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

• Заказ, размещенный пользователем-гостем
• Заказ, размещенный зарегистрированным пользователем
• Заказ, размещенный зарегистрированным пользователем с учетной записью лояльности
• Заказ только одного товара
• Заказ нескольких товаров
• Заказ хотя бы одного товара с количеством >1
• Заказ с оплатой кредитной картой
• Заказ с оплатой подарочной картой
• Заказ с оплатой как кредитной картой, так и подарочной картой
• Заказ с одинаковым адресом доставки и выставления счета
• Заказ с разными адресами доставки и платежным адресом
• Заказ с несколькими адресами доставки
• Заказ с экспресс-доставкой
• Заказ со стандартной доставкой
• Заказ с бесплатной доставкой
• Заказ с доставкой в ​​штат без налога с продаж
• Заказ хотя бы одного товара по цене продажи
• Заказ с рекламной акцией на уровне заказа
• Заказ с рекламной акцией на уровне товара

Детализация истории

Независимо от типа написанного рассказа существуют два правила, определяющие детализацию рассказа.

Первое правило: история должна представлять значимое дополнение к продукту для пользователя продукта.

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

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

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

Читабельность истории

Кажется очевидным, но стоит отметить: история должна быть легко читаемой.

Вот несколько советов:

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

Пользовательская история против задачи

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

• Проводя пользовательские исследования
• Здание каркасы
• Анализ и дизайн
• Документация
• Строительные компоненты UI
• .