Что такое концепция программы

Содержание

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

251 просмотров

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

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

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

Концепция Программы развития университета

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

Бриф помогает команде разработки:

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

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

Какие задачи помогает решить концепция?

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

Что входит в типовую концепцию IT-продукта

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

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

Концепция 2020 | Что удалось сделать

Например, в Notamedia есть отдел технических писателей. Они обрабатывают документы, приводя их в тот вид, который требуется конкретному клиенту.

Чаще всего в концепцию входят такие разделы, как:

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

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

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

Состав и структура концепции цифрового продукта

Концепция цифрового продукта

Все статьи цикла:
Почему вашему проекту нужна концепция
Состав и структура концепции цифрового продукта (вы здесь)

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

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

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

§ 1. Состав концепции

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

§ 1.1. Краткое описание проекта

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

Эта часть нужна для того, чтобы:

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

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

§ 1.2. Цели и задачи бизнеса

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

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

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

§ 1.3. Потребности пользователей

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

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

§ 1.4. Описание основной механики

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

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

§ 1.5. Состав продукта и его технические особенности

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

§ 1.6. Ограничения

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

Например, в сервисе категорически нельзя использовать персональные данные пользователей, так как это сервис по анонимайзингу (услуги географически распределенных VPN, например). Или наоборот: у вас в сервисе хранятся сканы личных документов пользователей – а это значит, что серверы должны находиться на территории РФ.

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

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

§ 2. Структура концепции

Обычно здесь у меня четыре ключевых слоя: проект, бизнес, пользователи и техническая экспертиза. Я предпочитаю вести документацию в Confluence, завожу там раздел «Концепция», а в нём 4 подраздела:

§ 2.1. Проект

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

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

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

§ 2.2. Бизнес

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

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

§ 2.3. Пользователи

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

§ 2.4. Техническая экспертиза

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

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

В заключение

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

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

Откуда это всё?

Идея концепции в том виде, которую я здесь изложил, родилась в стенах Цифровой Артели Eleven. Если интересно подробнее узнать о нашем подходе – можете полистать книгу моего партнёра по артели, Вадима Митякина, там много интересного.

Источник: sherer.pro

Как Создать Концепцию Программного Продукта и Что Это Такое?

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

Что такое концепция программного продукта?

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

Такой подход позволяет легче нанять разработчиков для стартапа в будущем. Для того чтобы подтвердить концепцию в программной разработке необходимо сформулировать основные задачи и выполнить следующие этапы: 1.Определить цели проекта и методы их реализации. 2.Получить обратную связь от пользователей и клиентов. 3.Скоректировать идею и приступить к реализации.

Цели проекта и методы их реализации

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

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

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

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

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

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

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

Корректировка идеи и реализация

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

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

Выводы

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

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

Оцените (327 оценки — 4.3 из 5)

Источник: merehead.com