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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Предполагаемая структура.

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

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

• Предполагаемое наполнение ключевых страниц (описание шаблонов и функций).

• Риски.

• Приоритеты запуска продукта.

• Список интеграций.
• Идеи для развития.

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

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

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

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

Цели и специфика продукта

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

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

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

Цели

В данной части концепции указываются цели будущего продукта. Это результат, к которому команда придет после запуска. Лучше, чтобы цель была написана по SMART (полностью или частично): конкретная; измеримая; достижимая; актуальная, с ограничением по времени. Целей может быть несколько. Но не стоит их путать с бизнес-задачами.

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

Иногда этот блок не включается в концепцию. Бизнес-задачи отвечают на вопрос: “Что нужно сделать для достижения конкретной цели бизнеса?”. Если целью значится разработка системы онлайн поддержки, то задачами могут быть:

• разработать интерфейс оператора системы;
• разработать систему модерации входящих сообщений.
  

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

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

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

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

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

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

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

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

Здесь аналитики пишут про все основные функции, которые предполагаются на сайте:

• Авторизация по смс;
• Печать чеков;
  
• Интеграция с платежной системой;
  
• Сканирование QR-кодов;
  
• И другие возможности.
  

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

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

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

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

Риски

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

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

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

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

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

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

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

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

1. При подготовке концепции собрано достаточно информации, чтобы узнать все подводные камни в рамках продукта и требования клиента.
2. Документ написан грамотно и понятно для людей, которые не являются разработчиками. Рассчитан на разный уровень технической подготовки. Информация о сути продукта изложена доступно и однозначно.
   
3. Материалы по продукту хорошо структурированы, представлены логично и последовательно.
   
4. Сложная логика концепции дополняется вспомогательным визуалом типа схем, поясняющим непонятные места.
   
5. Спустя время концепция остается понятной и прозрачной для клиента, разработчиков и вообще всех, кто её читает. Помогает избежать недопонимания и разночтений при реализации продукта.
   

Обратившись в компетентную команду разработки, клиент получает качественно разработанную концепцию продукта, а затем и другие артефакты. Что значит “качественную”? Давайте подытожим и зафиксируем критерии хорошей концепции:

1. Это описание системы, написание просто, логично и понятно для представителей бизнеса.
2. Из концепции очевидно, для чего и для кого создается решение, какие задачи будет решать продукт.
   
3. Если даже прочитать ее через полгода, все пожелания к системе, требования и идеи по развитию продукта очевидны как для разработчиков, так и для всех представителей клиента.
   
4. Благодаря взаимодействию аналитиков и клиента, все участники процесса разработки продукта понимают, с какими целями создается решение, и каким оно должно быть в идеале.
   

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

Спасибо, что прочитали нашу статью!