Как концепция продукта в IT выступает переводчиком с языка клиента на язык разработчиков

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





Идет 19-й год деятельности Notamedia на digital-рынке, и за все это время к нам приходили разные клиенты. Иногда было четкое ТЗ и детальное представление о результате — это идеальный клиент. И наоборот, случалось, что у заказчика есть лишь общее представление о планируемом результате. Например, клиент говорит: «Мне нужен стильный сайт с лаконичным дизайном. Нравится, как сделано у Тинькофф». И все. Это, безусловно, осложняет работу.

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

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

Сначала нам на помощь приходит бриф.

Бриф как первичный инструмент коммуникации

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

Предположим, клиент обратился к нам за разработкой корпоративного сайта.

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

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

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

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

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

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

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

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

Если клиент требует формальное ТЗ (в том числе по ГОСТ), его разработка должна начинаться сразу за созданием концепции проекта.




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

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

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

Расскажем подробнее о типовых разделах концепции проекта

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

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


Описание бизнеса и информация о заказчике

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


Цели

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





Бизнес-задачи

В некоторых проектах этот блок не отображается в концепции. Бизнес-задача должна отвечать на вопрос: «Что сделать, чтобы достичь определенной цели бизнеса?». Если ваша цель — это разработка системы онлайн-поддержки, то бизнес-задача для нее может быть «разработать интерфейс оператора системы».


Бизнес-специфика

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


Целевая аудитория

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





Текущие проблемы

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


Функциональные возможности

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


Технические требования

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


Наполнение ключевых страниц

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


Риски

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


Предполагаемые интеграции

Этот раздел включает предполагаемые интеграции. Например, с сервисом Яндекс.Карт, с внутренними CRM, ERP и т.д.





Источники информации

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


Идеи по развитию продукта

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

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

Пример концепции сайта, которую мы делали для клиента:
Концепция сайта клиники стоматологии.

Как на наш взгляд выглядит хорошая концепция. Чек-лист:

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

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