Что такое веб продукт
Как в Атвинте разрабатывают веб-продукты, часть 2: дизайн-макеты, frontend, backend, тестирование
Весь процесс разработки мы делим на две большие части:
I. Этап Аналитики и проектирования.
II. Этап разработки.
На первом этапе закладываем базис будущего сайта: определяем, кто и как будет пользоваться, разрабатываем пользовательские сценарии, проектируем архитектуру и логику работы продукта, определяем общую стилистику, готовим контент.
Эта статья посвящена второму этапу: как команда digital-агентства создает работающий сайт или другой продукт на основе аналитики, прототипов, дизайн-концепции и техзадания.
Работы этого этапа:
Теперь подробнее о каждом шаге.
1. Разработка дизайн-макетов
Результат этого этапа — набор всех страниц сайта или экранов приложения под все необходимые разрешения и устройства, правила использования всех элементов на них.
Какие специалисты задействованы
Арт-директор, дизайнеры, менеджер и аккаунт проекта.
Дизайнеры разрабатывают макеты главной и всех уникальных страниц сайта или экранов приложения. В работе опираются на аналитику, прототипы, дизайн-концепцию и SEO-рекомендации.
Арт-директор подбирает на проект дизайнеров с релевантным опытом, контролирует чистоту макетов и единство стилистики. При необходимости направляет дизайнеров к лучшим решениям в интерфейсе.
Что нужно для разработки
SEO-структура сайта, прототипы, дизайн-концепция, текстовый и медиа-контент.
Что делаем на этапе разработки дизайн-макетов
На этапе проектирования мы отвечали на вопрос «Как работает?», на этапе концепции подобрали визуальную идею. Теперь развиваем стилистику для всех страниц сайта, детально продумываем внешний вид элементов и эффекты при взаимодействии пользователя с интерфейсом.
Для каждого экрана разрабатываем адаптивные макеты, чтобы сайт хорошо выглядел и работал на разных устройствах с разными разрешениями экранов. Сайт будет одинаково удобен и на компьютере или ноутбуке, и на смартфоне.
Вот так выглядит набор макетов, включая адаптивы, для корпоративного сайта Детской многопрофильной больницы:
А так набор макетов для интернет-магазина обуви:
В проектах со сложными анимациями и визуальными эффектами на этапе разработки дизайн-макетов подключаем frontend-разработчиков, чтобы заранее продумать техническую реализацию.
Это здорово экономит время и упрощает работу на этапе программирования интерфейса. Разработчик сразу будет в курсе, с чем ему предстоит работать и заранее подберет решения. А дизайнеры найдут баланс между визуальной эффектностью и удобством реализации.
Финальный шаг этапа — подготовка макетов к верстке и формирование UI-кита. UI-кит дизайнеры выносят все типы элементов интерфейса и как они реагируют при наведении курсора, нажатии, переключении между страницами. В нем же описаны все типы заголовков и их поведение при изменении верстки. Этот инструмент помогает frontend-разработчикам быстро собрать верстку, избежать разнобоя в элементах и сохранить стилистическое единство всех разделов.
Перед передачей в разработку дизайнеры проверяют макеты по чек-листу на ошибки: на всех ли страницах верная сетка, отступы, расположение элементов.
Инструменты и технологии
Макеты разрабатываем в Figma, для создания иллюстраций, иконок визуальных эффектов используем Photoshop и Illustrator, отдельный софт используем для 3D и моушен-графики.
2. Программирование: frontend
Результат frontend-разработки — всё, с чем взаимодействует пользователь на сайте или в приложении. Главная цель этапа — сделать сайт удобным для пользователей и эффективным с точки зрения бизнеса.
Какие специалисты задействованы
Frontend-разработчики и технический директор.
Фронтендеров иногда еще называют Creative Frontend Developer, так как они являются связующим звеном между дизайном и его техническим воплощением. Они программируют визуальные решения, пользовательские сценарии и функциональность, заложенные дизайнерами.
Что нужно для разработки
Дизайн-макеты, UI-кит или дизайн-система, сценарии и архитектура продукта, описанные в техзадании.
Что делаем на этапе frontend
На этапе фронтенда — воплощаем функциональность и «оживляем» отрисованный дизайнерами интерфейс с помощью кода.
Frontend — это больше, чем просто верстка макетов. Frontend-разработчики разрабатывают все, что помогает пользователю быстрее и удобнее решать задачи с помощью сайта.
Инструменты и технологии
*SPA или Single Page Application — это одностраничное веб-приложение, которое позволяет быстрее загружать контент в браузер пользователя. При первичном обращении к SPA-приложению загружается разметка и основной контент. А остальная информация при прокрутке или переходах между страницами подгружается динамически без полной перезагрузки всей страницы.
3. Программирование: Backend
Реализуем все процессы, которые происходят на серверной части сайта в ответ на действия пользователя.
Какие специалисты задействованы
Backend-разработчики, технический директор.
Чаще всего этот этап идет параллельно frontend-разработке, а разработчики бэкенда и фронтенда работают в тесной связке.
Что нужно для разработки
Техническое задание с подробным описанием всех необходимых алгоритмов, структуры данных, техническими описаниями для интеграции с фронтендом и сторонними сервисами.
Что делаем на этапе backend
Cайт без бэкенда — это не более, чем красивая оболочка. Чтобы сайт функционировал, нужно запрограммировать логику хранения данных и правила обмена информацией между сервером и клиентской частью.
Backend-разработчики программируют внутреннюю логику работы сайта или веб-продукта.
Инструменты и технологии
Бэкенд пишем на PHP.
4. Тестирование
Тестирование нужно, чтобы оценить, все ли работает как надо и исправить до передачи проекта заказчику и релиза для конечных пользователей.
Какие специалисты задействованы
Тестировщики, менеджер проекта, технический директор, арт-директор.
Что делаем на этапе тестирования
Тестирование проводится после каждого этапа разработки сайта: после этапа проектирования тестируем пользовательские сценарии, проверяем по чек-листу сначала макеты, а потом верстку, проводим автотесты и нагрузочные тесты после разработки каждой новой функции. Особенно это актуально для многофункциональных веб-сервисов.
Основные виды тестирования:
Так тестируем сценарии авторизации, добавления товара в корзину, путь до определенного экрана. Проверяем, верно ли отрабатывают формы, кнопки, верную ли информацию выдает сайт в ответ на запросы пользователей.
Например, разработчик написал модуль добавления товара в корзину. И он проверяет, правильно ли отработает модуль при разных сценариях:
1. Если добавили товар в пустую корзину, то на выходе на странице корзины должен отобразиться один товар.
2. Если в корзине уже был товар, то предыдущий должен остаться в корзине, а к нему добавиться новый.
Веб-сервисы и веб-приложения для бизнеса: кому, зачем и почему нужна такая разработка
Современный веб-сервис
Андрей Батурин
Это всегда уникальная разработка, которая создается для решения конкретных задач в отдельно взятой компании. Или в группе компаний. Сразу возникает вопрос: если есть такой «волшебный» метод упорядочить взаимодействие и ускорить бизнес, почему не все его используют? Во-первых, не всем он нужен. Многие компании пользуются стандартными, распространенными CRM и иными системами, и их все устраивает. Во-вторых, для малого или начинающегося бизнеса разработка иногда кажется непосильной в финансовом плане. В-третьих, есть компании, и таких много, которые почему-то не считают, что веб-сервис может им серьезно помочь. Рассмотрим в статье эти три аспекта.
Веб-сервисы и веб-приложения, по сути, часто представляют собой сходный продукт. В отдельную категорию выделяются мобильные приложения, но и они очень близки к рассматриваемой теме. Типичный пример веб-сервиса — это закрытый портал для взаимодействия работников одной компании. Или площадка для составления отчетности, автоматизированного контроля чего-либо, для учета операций, для обмена данными, для постановки задач подчиненным и многого другого.
Преимущества веб-сервисов
Им свойственны 3 ярких достоинства, которые наверняка покажутся привлекательными. Причем представителям любого бизнеса.
Отдельно скажем о главном преимуществе веб-сервисов — они изначально разрабатываются под специфику и задачи вашего бизнеса. Это не типовой продукт, который тоже может быть полезен. Но уникальная разработка, полностью отвечающая точным установкам, созданная исключительно под ваши бизнес-процессы.
Веб-приложения для бизнеса
Все программные продукты, применяемые в коммерческой или производственной деятельности, условно можно выделить в 2 категории:
Но работать с ЦА можно и иными средствами — через сайт, площадки бренда в социальных сетях, в мессенджерах, на видеохостингах и в иных каналах, с помощью классической или интернет-рекламы, путем проведения маркетинговых мероприятий.
Бывают задачи по работе с клиентами, для которых требуется создание уникального приложения. Это, к примеру, партнерские программы, треккеры заказов, учет предоставленных скидок и пр. Подобные продукты тоже можно разработать именно под ваш бренд.
Существует мнение, что создание веб-приложения — дорогое удовольствие. Скажем так, стоимость сопоставима с ценами на создание сайта, хотя многое зависит от специфики и от объема решаемых задач. Но ресурс, направленный на повышение эффективности, в конечном счете окупает затраты на разработку.
В каком виде можно реализовать веб-сервис или приложение
На первый план обычно выдвигается функционал. Также на главных ролях остается понятный и логичный интерфейс. На второстепенных — дизайн, если это не приложение для работы с потенциальными или настоящими клиентами.
В плане дизайна важна адаптивность и кроссплатформенность, поскольку предполагается, что веб-сервисом будут пользоваться с устройств различных типов.
Такой подход обычно строится на приоритетных задачах — оптимизировать бизнес-процессы, снизить нагрузку на сотрудников, автоматизировать внутреннее взаимодействие, в результате выйти на те преимущества, которые были названы выше.
Поэтому в ходе даже не самой разработки, а на этапе подготовке к ней, важно:
Упрощенная схема разработки выглядит так:
В каком примерно виде можно реализовать веб-сервис или приложения:
Перечень очень условный, поскольку названные разновидности часто комбинируются, добавляются необходимые опции и функционал.
Кому нужна такая разработка?
Безусловно, не всем могут пригодиться веб-сервисы. Однако есть сферы, где программные продукты действительно помогают вывести бизнес на новый уровень.
В пример можно привести:
Как видим, в списке преимущественно присутствует сфера услуг B2C. Но и в других направлениях бизнеса найдется то, что помогут автоматизировать веб-приложения.
— Веб-сервис — это всегда индивидуальное решение, разработка оригинального ПО под точно сформулированные цели. Наша веб-студия успешно реализует такие проекты, выполняя полный комплекс работ по разработке от проведения исследований до запуска. Приглашаем познакомиться с кейсом, посвященным созданию веб-сервиса для крупной сети ресторанов быстрого питания!
Как работают веб-приложения
1. Чем веб-приложения отличаются от сайтов
Для меня сайт это в первую очередь что-то информационное и статичное: визитка компании, сайт рецептов, городской портал или вики. Набор подготовленных заранее HTML-файлов, которые лежат на удаленном сервере и отдаются браузеру по запросу.
Сайты содержат различную статику, которая как и HTML-файл не генерируется на лету. Чаще всего это картинки, CSS-файлы, JS-скрипты, но могут быть и любые другие файлы: mp3, mov, csv, pdf.
Блоги, визитки с формой для контакта, лендинги с кучей эффектов я тоже отношу для простоты к сайтам. Хотя в отличие от совсем статических сайтов, они уже включают в себя какую-то бизнес-логику.
А веб-приложение — это что-то технически более сложное. Тут HTML-страницы генерируются на лету в зависимости от запроса пользователя. Почтовые клиенты, соцсети, поисковики, интернет-магазины, онлайн-программы для бизнеса, это все веб-приложения.
2. Какие бывают веб-приложения
Веб-приложения можно разделить на несколько типов, в зависимости от разных сочетаний его основных составляющих:
3. Pyhon-фреймворк Django aka бэкенд
В разработке фреймворк — это набор готовых библиотек и инструментов, которые помогают создавать веб-приложения. Для примера опишу принцип работы фреймворка Django, написанного на языке программирования Python.
Первым этапом запрос от пользователя попадает в роутер (URL dispatcher), который решает какую функцию для обработки запроса надо вызвать. Решение принимается на основе списка правил, состоящих из регулярного выражения и названия функции: если такой-то урл, то вот такая функция.
Функция, которая вызывается роутером, называется вью (view). Внутри может содержаться любая бизнес-логика, но чаще всего это одно из двух: либо из базы берутся данные, подготавливаются и возвращаются на фронт; либо пришел запрос с данными из какой-то формы, эти данные проверяются и сохраняются в базу.
Данные приложения хранятся в базе данных (БД). Чаще всего используются реляционные БД. Это когда есть таблицы с заранее заданными колонками и эти таблицы связаны между собой через одну из колонок.
Данные в БД можно создавать, читать, изменять и удалять. Иногда для обозначения этих действий можно встретить аббревиатуру CRUD (Create Read Update Delete). Для запроса к данным в БД используется специальный язык SQL (structured query language).
В Джанго для работы с БД используются модели (model). Они позволяют описывать таблицы и делать запросы на привычном разработчику питоне, что гораздо удобнее. За это удобство приходится платить: такие запросы медленнее и ограничены в возможностях по сравнению с использованием чистого SQL.
Полученные из БД данные подготавливаются во вью к отправке на фронт. Они могут быть подставлены в шаблон (template) и отправлены в виде HTML-файла. Но в случае одностраничного приложения это происходит всего один раз, когда генерируется HTML-страница, на который подключаются все JS-скрипты. В остальных случаях данные сериализуются и отправляются в JSON-формате.
4. Javascript-фреймворки aka фронтенд
Клиентская часть приложения — это скрипты, написанные на языке программирования Javascript (JS) и исполняемые в браузере пользователя. Раньше вся клиентская логика основывалась на использовании библиотеки JQuery, которая позволяет работать с DOM, анимацией на странице и делать AJAX запросы.
DOM (document object model) — это структура HTML-страницы. Работа с DOM — это поиск, добавление, изменение, перемещеие и удаление HTML-тегов.
AJAX (asynchronous javascript and XML) — это общее название для технологий, которые позволяют делать асинхронные (без перезагрузки страницы) запросы к серверу и обмениваться данными. Так как клиентская и серверная части веб-приложения написаны на разных языках программирования, то для обмена информацией необходимо преобразовывать структуры данных (например, списки и словари), в которых она хранится, в JSON-формат.
JSON (JavaScript Object Notation) — это универсальный формат для обмена данными между клиентом и сервером. Он представляет собой простую строку, которая может быть использована в любом языке программирования.
Сериализация — это преобразование списка или словаря в JSON-строку. Для примера:
Десериализация — это обратное преобразование строки в список или словарь.
С помощью манипуляций с DOM можно полностью управлять содержимым страниц. С помощью AJAX можно обмениваться данными между клиентом и сервером. С этими технологиями уже можно создать SPA. Но при создании сложного приложения код фронтенда, основанного на JQuery, быстро становится запутанным и трудно поддерживаемым.
К счастью, на смену JQuery пришли Javascript-фреймворки: Backbone Marionette, Angular, React, Vue и другие. У них разная философия и синтаксис, но все они позволяют с гораздо большим удобством управлять данными на фронтенде, имеют шаблонизаторы и инструменты для создания навигации между страницами.
HTML-шаблон — это «умная» HTML-страница, в которой вместо конкретных значений используются переменные и доступны различные операторы: if, цикл for и другие. Процесс получения HTML-страницы из шаблона, когда подставляются переменные и применяются операторы, называется рендерингом шаблона.
Полученная в результате рендеринга страница показывается пользователю. Переход в другой раздел в SPA это применение другого шаблона. Если необходимо использовать в шаблоне другие данные, то они запрашиваются у сервера. Все отправки форм с данными это AJAX запросы на сервер.
5. Как клиент и сервер общаются между собой
Общение клиента с сервером происходит по протоколу HTTP. Основа этого протокола — это запрос от клиента к серверу и ответ сервера клиенту.
Для запросов обычно используют методы GET, если мы хотим получить данные, и POST, если мы хотим изменить данные. Еще в запросе указывается Host (домен сайта), тело запроса (если это POST-запрос) и много дополнительной технической информации.
Современные веб-приложения используют протокол HTTPS, расширенную версию HTTP с поддержкой шифрования SSL/TLS. Использование шифрованного канала передачи данных, независимо от важности этих данных, стало хорошим тоном в интернете.
Есть еще один запрос, который делается перед HTTP. Это DNS (domain name system) запроc. Он нужен для получения ip-адреса, к которому привязан запрашиваемый домен. Эта информация сохраняется в браузере и мы больше не тратим на это время.
Когда запрос от браузера доходит до сервера, он не сразу попадает в Джанго. Сначала его обрабатывает веб-сервер Nginx. Если запрашивается статический файл (например, картинка), то сам Nginx его отправляет в ответ клиенту. Если запрос не к статике, то Nginx должен проксировать (передать) его в Джанго.
К сожалению, он этого не умеет. Поэтому используется еще одна программа-прослойка — сервер приложений. Например для приложений на питоне, это могут быть uWSGI или Gunicorn. И вот уже они передают запрос в Джанго.
После того как Джанго обработал запрос, он возвращает ответ c HTML-страницей или данными, и код ответа. Если все хорошо, то код ответа — 200; если страница не найдена, то — 404; если произошла ошибка и сервер не смог обработать запрос, то — 500. Это самые часто встречающиеся коды.
6. Кэширование в веб-приложениях
Еще одна технология, с которой мы постоянно сталкиваемся, которая присутствует как веб-приложениях и программном обеспечении, так и на уровне процессора в наших компьютерах и смартфонах.
Cache — это концепция в разработке, когда часто используемые данные, вместо того чтобы их каждый раз доставать из БД, вычислять или подготавливать иным способом, сохраняются в быстро доступном месте. Несколько примеров использования кэша:
WEBURSITET.RU
Онлайн-курсы профессиональной разработки ПО
Виды программных и интернет-продуктов
Текстовая расшифровка седьмого урока курса Введение в профессию аналитика.
Сегодня мы поговорим о том, что влияет на выбор эффективных способов и форматов разработки требований. И, в первую очередь, речь пойдёт о видах программных продуктов.
До того, как появился интернет (и этим концепциям аналитиков до сих пор и учат), использовалось такое сравнительно простое деление продуктов на основные классы. Эти классы во многом определяют способы работы с требованиями: как их разрабатывать, использовать, какие использовать при этом документы Основных классов всего два: это коробочный и заказной продукт. Немного в стороне стоит ещё внутренняя разработка, которая вроде как и заказная, но продукт разрабатывается внутри самой организации. То есть если у организации есть достаточно ресурсов для разработки собственного продукта под свои нужды, то часто это оказывается выгоднее. Может быть, дешевле, хотя не всегда. Но главное преимущество в том, что когда разработчики продукта, что называется, ближе к телу, то получается продукт, более соответствующий потребностям организации.
Когда программные продукты разрабатывались не для интернета, а для установки на компьютеры — сначала на большие, потом на персональные, — можно было разделить потребителей этих продуктов на организации и на личных пользователей. Например, для личного пользования — Microsoft Office, разные игры, приложения для видеомонтажа А продукты для организаций — это разные системы автоматизации их деятельности, которые в основном подходили под определение автоматизированной системы, которое мы вспоминали на прошлом вебинаре.
Каким образом вид продукта влиял на методы или подходы для работы с требованиями? В случае с коробочной разработкой требования к продукту нужно было собирать на рынке, проводить исследования, и всё это делалось до выпуска первой версии продукта. Довольно затратный был процесс. Можно было неправильно собрать требования и выпустить неправильный продукт, а стоило это дорого, поэтому процесс был очень трудоёмким и дорогостоящим, и относились к нему очень серьёзно.
Между коробочной и заказной разработкой есть промежуточный вариант, когда мы разработали систему — может быть, для других клиентов, может быть, в попытках автоматизировать наиболее частые функции и модули, и потом уже предлагаем её на заказ компании с адаптацией. То есть с разработкой под нужды этой организации. Такой вид продукта находится между коробочной и заказной и, соответственно, в методах выявления требования сочетаются части обоих подходов, когда мы сначала собираем требования, исследуя рынок, а потом фактически дополнительные требования для внедрения мы собираем с закзачика.
Особенность внутренней разработки в том, что есть постоянный доступ к пользователям и к заинтересованным лицам, которые не являются пользователями, но являются важными стейкхолдерами — заказчиками и системы. У нас есть к ним постоянный доступ, поэтому система может жить вместе с организацией, и здесь можно применять методы непрерывного выявления потребностей, их обработки и реализации.
До интернета все было сравнительно просто. Что же изменилось после появления интернета? Здесь я перечислили основные особенности, которые повлияли на разработку требований с приходом интернета. Давайте их коротко рассмотрим.
Быстрая обратная связь от пользователя. Интернет — это глобальный канал коммуникации всего мира. Мы можем практически мгновенно, создав продукт и отправив его пользователю, получить от него отзывы: насколько продукт соответствует его ожиданиям, насколько он реализует те функции, которые нужны пользователю, с каким качеством и так далее.
Интернет дал ещё одну важную возможность, которой не было раньше: теперь можно практически любые интегрировать между собой. Можно выпускать продукты, встраиваемые уже в сложившуюся экосистему, то есть складывать «пирамидку» на базе уже существующих продуктов и сервисов.
И ещё одно важное изменение: маркетинговые возможности по рекламе и продажам в интернете можно включать непосредственно в продукт. То есть продукт сам себя может рекламировать и даже сам себя может продавать. Вы можете найти в интернете подходящий вам сервис, попробовать его, тут же оплатить и начать им пользоваться. Этой возможности не было до интернета. Раньше у коробок и у продуктов на заказ маркетинг и продажи были довольно сложными отдельными процессами, часто не позволяющими найти свой путь к пользователю, для которого продукт создавался. Сейчас же любой пользователь может найти себе в интернете любой продукт, исходя из своих потребностей.
Каким образом это повлияло на работу с требованиями и разработку? Что я сделал: я из предыдущего слайда «Что нам дал интернет» основные возможности перенёс в этот блок, который практически дублирует предыдущий слайд, и раскрыл чуть подробнее, что нам эти изменения дают.
Поскольку у нас появилась быстрая обратная связь от пользователя, стало возможным быстро протестировать концепцию. То есть у вас возникла идея нового продукта, вы не знаете насколько она будет эффективной, но интернет позволяет вам очень быстро создать прототип, развернуть его в интернете, получить первые отзывы пользователей и понять, насколько ваша концепция жизнеспособна. Чего, конечно же, не было до интернета, когда программы продавались в коробках в магазинах. Кроме того, быстрая связь позволяет нам для практически непрерывно выявлять требования. То есть запросы пользователей, анализ их активности, сообщения об ошибках. Причём эта обратная связь не обязательно предоставляется пользователем лично. Сейчас настолько развиты системы сбора статистики, в том числе поведенческой, что можно уже автоматически выявлять, что не так с вашим продуктом, что можно улучшить, и как вообще пользователи с ним работают.
Возможность непрерывного обновления. Поскольку у нас теперь появилась возможность релизить наш продукт в интернет хоть каждый день, возможность непрерывного выявления требований тоже становится очень важной. Чтобы релизить часто, нужно и требования собирать тоже часто.
Две этих новых возможности — возможность протестировать концепцию и возможность непрерывного выявления требований — требуют новых подходов и новых форматов требований. Для их разработки нужны новые методы. И, собственно, как отзыв и как результат этого вызова, появились соответствующие методы. Это, в первую очередь, метод user stories, который активно используется в Agile. И метод, который называется «сценарии, ориентированные на персоны». Эти методы предназначены именно для того, чтобы быстро выявлять и описывать требования и запускать их в производство.
Маркетинг внутри продукта. Как я говорил, фактически сейчас пользователи интернета сами продукт находят. Если вам нужен сервис, вы его находите поиском или по рекламе, заходите на его сайт, там же можете его оценить и сразу приобрести. Это очень сильно влияет на то, как собственно должен выглядеть продукт, и фактически эта возможность породила новый тип требований, которым сейчас все должны соответствовать или должны учитывать. Я здесь перечислил основные.
Демонстрационный доступ. Очень активно используется для того, чтобы потенциальные пользователи сразу могли оценить, насколько продукт соответствует их потребностям.
Посадочные страницы. Это не очень удачное название. Смысл в том, что продукт должен учитывать разные способы захода пользователей на сайт (по разным запросам или по рекламе) и подстраиваться под них.
Ещё пример: очень важной стала интеграция с соц. сетями. Ну и, наверное, можно и дальше дополнять этот список.
Продукты в интернете — и развлекательные, и информационные, и автоматизирующие деятельность — должны считаться с этими требованиями, потому что это становится важным конкурентным преимуществом.
Простота интеграции позволяет встраивать продукт в уже существующую экосистему. Кроме того, появились новые виды продуктов: посредники и разного рода агрегаторы. Например, сайт поиска билетов, о котором мы говорили. Этот продукт возник в интернете благодаря возможности интегрироваться с другими продуктами — с сайтами авиакомпаний — для поиска билетов. Появились и другие виды продуктов, специфичные продукты для интернета: разные рекламные площадки, разные метрики, статистика, анализ поведения пользователей и так далее.
Поэтому то деление продуктов, которые было до интернета (коробочные и заказные продукты) уже стало размытым, оно уже не удовлетворяет нашим потребностям, когда мы хотим с помощью этого деления выбрать оптимальные подходы и методы разработки требований.
Сейчас появляется много разных классификаций видов продуктов. Единой классификации я не видел, но здесь постарался перечислить важные признаки, по которым при создании продукта мы можем определить, к какому виду он относится. А от этого, как мы увидим из курса, достаточно сильно зависят методы разработки требований, важность тех или иных видов требований, а также форматы их представления.
Можно делить по потребителю.
Есть продукты для массового пользователя: развлекательные, интернет-магазины, информационные ресурсы, социальные сети и так далее.
Ну и заказные продукты для бизнеса никуда не делись, просто они сейчас идут больше в интернет. Например, банковские системы уже бывают «облачными». То есть, вместо того, чтобы ехать в банк и устанавливать сервера для банковской системы, сейчас модель меняется на то, что у вас есть собственные сервера в облаке, а банк пользуется ими фактически по подписке. Но это подписка не для личного пользователя, а для большого бизнеса. Возможно, конечно, расширение этой классификации, но даже такого простого деления достаточно, чтобы понимать, на что влияет определение вашего потребителя при разработке требований.
По назначению. Тоже, может быть, классификация не очень совершенная, но полезная.
Самодостаточный продукт — это продукт, который существует только в интернете.
Об услугах, специфичных для интернета, мы уже говорили.
Торговая. Это интернет магазины, тут особенно вдаваться не во что.
Информационная. Это различные сайты: новостные, профессиональные, юридические
Рекламная и социальная модели. Нужно сказать, что продукт не обязательно относится только к одной указанной модели, может сочетать несколько. Например, Facebook решает социальную функцию, но при этом зарабатывает за счёт рекламы.
Когда мы разрабатываем бизнес требования к нашему сервису, мы должны все эти классификации учесть, чтобы понять, какие требования являются для нас наиболее приоритетными, кто наши заинтересованные лица, какие у них проблемы и ожидания и какие функции мы должны реализовать в нашем продукте, чтобы эти проблемы и ожидания удовлетворить.
Я постоянно говорю о методах разработки требований, потому что это сейчас больная тема. Аналитиков учат определенным методам разработки требований, и они их потом пытаются применять в ситуациях, в которых эти методы не очень хорошо работают.