Виды программных и интернет-продуктов

Текстовая расшифровка седьмого урока курса Введение в профессию аналитика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Две этих новых возможности — возможность протестировать концепцию и возможность непрерывного выявления требований — требуют новых подходов и новых форматов требований. Для их разработки нужны новые методы. И, собственно, как отзыв и как результат этого вызова, появились соответствующие методы. Это, в первую очередь, метод user stories, который активно используется в Agile. И метод, который называется «сценарии, ориентированные на персоны». Эти методы предназначены именно для того, чтобы быстро выявлять и описывать требования и запускать их в производство.

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

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

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

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

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

Ещё пример: очень важной стала интеграция с соц. сетями. Ну и, наверное, можно и дальше дополнять этот список.

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

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

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

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

Можно делить веб-продукты по потребителю.

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

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

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

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

Самодостаточный продукт — это продукт, который существует только в интернете.

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

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

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

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

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

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

Торговая. Это интернет магазины, тут особенно вдаваться не во что.

Информационная. Это различные сайты: новостные, профессиональные, юридические и т. д.

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

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

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

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

Предыдущий урок: Какие виды требований важнее остальных?

Следующий урок: Сводные документы требований к программным продуктам