«Хочу сайт, как у Тинькофф, но чтобы дизайн был уникальным» — с такой фразы часто начинается работа над проектом. Для клиента это исчерпывающее описание задачи. Для разработчика — полное отсутствие данных: неясно, какой нужен функционал, кто аудитория, что значит «уникальный дизайн» и какой бюджет.
Разрыв между тем, как о продукте думает заказчик, и тем, что нужно знать команде, чтобы его построить, закрывает концепция проекта — документ, который переводит пожелания клиента в конкретные функции, экраны и сценарии. Разберемся, как она устроена и почему без нее сложные IT-проекты редко обходятся без потерь в деньгах и сроках.
Что такое концепция проекта простыми словами
Концепция — это описание будущего продукта: кто им будет пользоваться, какую проблему он решает и какими средствами. В IT чаще всего речь идет о концепции конкретного продукта — сайта, приложения, сервиса. Но тот же принцип применим и шире: когда компания описывает новое направление бизнеса, а не отдельное цифровое решение, логика документа остается той же.
Чем концепция отличается от идеи, стратегии и ТЗ
Эти понятия часто путают. В итоге команда либо тратит недели на то, что можно было прояснить за один созвон, либо берется за разработку по одной фразе клиента и потом переделывает половину.
Концепция и идея
Идея — это первая мысль о продукте: «сделать сайт, где пациенты сами будут записываться к врачу». В идее почти никогда нет ограничений — ни по бюджету, ни по срокам, ни по технологиям. Она отвечает на вопрос «что хочется сделать».
Концепция превращает эту мысль в рабочий документ: кто целевая аудитория, какие у нее сценарии, какие функции нужны в первую очередь, а какие можно отложить. Идея клиента про «сайт с записью к врачу» в концепции превращается в описание пользовательских групп, сценариев записи, интеграции с расписанием врачей и правил отмены визита — то есть в то, что действительно можно оценить и разработать.
Концепция и стратегия
Стратегия — это то, куда движется бизнес в целом: какие рынки осваивать, как расти, какую долю рынка занять через несколько лет. Концепция гораздо конкретнее: она про один продукт или его версию.
Если в компании есть стратегия выхода в новый сегмент, концепция конкретного сайта или приложения будет одним из инструментов ее реализации, но не заменит ее. В концепцию иногда включают краткий раздел о том, как продукт будет позиционироваться и продвигаться после запуска, — но это скорее ссылка на маркетинговую стратегию, чем ее пересказ.
Концепция и техническое задание
Концепция отвечает на вопрос «что делать», техническое задание — на вопрос «как именно». Пример: в концепции может быть написано «пользователь авторизуется на сайте». В ТЗ уже будет прописано, по какому номеру телефона, через какой SMS-провайдер, что происходит при неверном коде и сколько попыток дается.
Если клиенту не требуется формальное ТЗ — например, для тендера по ГОСТу — работа может пойти сразу от концепции к разработке. Если требуется — ТЗ пишут на основе уже согласованной концепции, а не параллельно с ней.
Когда концепция нужна, а когда без нее можно обойтись
Концепция — не обязательный этап для любого проекта. Она полезна, когда:
-
у клиента нет четкого технического задания и границы продукта размыты;
-
нужна точная оценка сроков и бюджета;
-
в проекте много неочевидных решений — например, сложная логика записи или несколько ролей пользователей.
В концепции, скорее всего, нет необходимости, если:
-
у заказчика уже есть детальное ТЗ или подробный бриф, по которому можно оценивать проект напрямую;
-
проект небольшой и типовой — например, лендинг из пяти блоков по референсу;
-
будущая система настолько велика, что для нее в принципе нужен полноценный этап аналитики.
В таких случаях время на подготовку концепции разумнее потратить на детальное интервью с заказчиком или сразу на аналитику.
Зачем нужна концепция проекта
Даже после подробного брифинга часто остается зона неопределенности — то, что клиент не проговорил, потому что для него это «само собой разумеется». Концепция закрывает эту зону: она заставляет команду и заказчика явно обсудить то, что иначе всплыло бы в разгар разработки, когда исправлять уже дорого.
Концепция помогает:
-
увидеть все составляющие продукта до старта работ;
-
разбить разработку на этапы и приоритеты;
-
точно оценить сроки и стоимость;
-
заранее понять, есть ли у команды техническая возможность реализовать то, что задумал клиент;
-
избежать ситуации, когда заказчик и разработчики по-разному понимают одну и ту же фразу в брифе.
Из чего состоит концепция проекта: структура и разделы
Жесткого стандарта на структуру концепции не существует — она строится вокруг задач конкретного проекта. Если от заказчика поступили только базовые требования, документ может ограничиться функциональным описанием. Если есть исследования и конкурентный анализ, разделов становится больше. Обычно концепция состоит из следующих блоков:
-
Цели и специфика продукта. Что за бизнес у клиента, кто пользователь продукта, какие проблемы он решает.
-
Описание бизнеса и информация о заказчике. Чем занимается компания, когда основана, какие услуги предоставляет на рынке.
-
Цели. Результат, которого команда должна добиться после запуска. Лучше формулировать по принципу SMART — конкретно, измеримо, достижимо, актуально, ограничено во времени.
-
Бизнес-задачи. Что нужно сделать, чтобы достичь цели бизнеса. Например: «разработать интерфейс оператора системы онлайн-поддержки».
-
Бизнес-специфика. Особенности бизнеса, которые могут повлиять на проект: несколько филиалов в разных часовых поясах, отсутствие общей ERP-системы и так далее.
-
Целевая аудитория. Без четкого портрета пользователя продукт создается в вакууме. Аудиторию делят на группы и прописывают цели каждой.
-
Текущие проблемы. Сложности текущего решения у клиента — например, сайт медленно грузится или плохо адаптирован под ТВ-экраны.
-
Функциональные возможности. Основные функции будущего продукта: авторизация по SMS, интеграция с платежной системой и другие.
-
Технические требования. Ограничения к инфраструктуре — например, к надежности серверов при высокой нагрузке.
-
Допущения и ограничения. Бюджет, сроки, технологический стек, зоны ответственности сторон. Раздел снижает риск разногласий на поздних этапах.
-
Наполнение ключевых страниц. Описание каждого уникального шаблона: что именно должно быть на странице.
-
Риски. Потенциальные проблемы в разработке — например, если пользовательский контент может нарушать законодательство.
-
Предполагаемые интеграции. Внешние сервисы: Яндекс.Карты, CRM, ERP-системы и другие.
-
Источники информации. Данные и исследования, которые легли в основу концепции, и кто их предоставил.
-
Идеи по развитию продукта. Гипотезы о том, как продукт будет расти: масштабирование, новые фичи.
Не все из этого списка обязательно — например, для небольшого проекта разделы про риски и интеграции могут уместиться в пару абзацев внутри других блоков. Смысл концепции проекта в том, чтобы не упустить то, что реально важно для конкретного продукта.
Как разработать концепцию проекта: этапы
Разработка концепции — командная работа: аналитик собирает вводные, но опирается на экспертизу разработчиков, дизайнеров и архитекторов. Обычно процесс укладывается в несколько этапов:
-
Сбор данных. Изучаем бриф, интервьюируем заказчика, уточняем бизнес-цели и специфику.
-
Анализ и структурирование. Раскладываем информацию по разделам будущей концепции, выявляем пробелы в требованиях.
-
Проработка с командой. Обсуждаем с разработчиками и архитекторами техническую реализуемость, стек технологий, оценку трудозатрат.
-
Черновик документа. Собираем все в единый файл по типовой структуре, формулируем функциональные и нефункциональные требования.
-
Презентация и согласование. Показываем концепцию клиенту, вносим правки по обратной связи.
-
Финал. Утвержденная концепция становится основой для оценки сроков, бюджета и — при необходимости — технического задания.
Частая ошибка — писать концепцию в одиночку, без участия разработчиков и дизайнеров. Аналитик может отлично понимать бизнес заказчика, но не видеть, что предложенное решение нереализуемо в разумные сроки или требует совсем другого технологического стека. Проработка с командой — этап, который экономит недели на переделках.
В среднем на разработку концепции уходит от 8 до 60 часов в зависимости от сложности продукта. В Notamedia мы, как правило, готовим и презентуем концепции еще до заключения договора с клиентом — это помогает глубже понять задачи и дать точную оценку.
Если хотите разобраться, что должно быть в концепции именно вашего продукта, — напишите нам, обсудим задачу и дадим предварительную оценку.
Пример концепции проекта
Один из примеров из нашей практики — концепция сайта стоматологической клиники.
Компания решила уйти от формата авторской клиники одного врача к бренду технологичной стоматологии среднего+ и бизнес-сегмента. Разрабатываемый продукт — сайт со статьями, каталогом услуг и цен, онлайн-записью к врачу, онлайн-оплатой и личным кабинетом пациента.
В концепции мы зафиксировали бизнес-цели заказчика: создание имиджа высокотехнологичной клиники, привлечение новых клиентов и удержание текущих, работу с аудиторией еще на этапе, когда человек только задумывается о визите к стоматологу, а не когда уже «болит и нужно срочно». Отдельная бизнес-задача — сократить время, которое персонал тратит на заполнение анкеты пациента при визите.
Главная ценность документа была в деталях, которые он вскрыл еще до старта разработки: онлайн-запись оказалась не просто формой на сайте, а логикой с интервалами по 30 и 60 минут в зависимости от услуги, автоматическими уведомлениями об отмене и правилом «запись закрывается за полчаса до приема». Без концепции эти детали, скорее всего, всплыли бы уже в разработке — и обошлись бы дороже.
Полная версия документа: Концепция сайта клиники стоматологии →
Чек-лист сильной концепции
Как на наш взгляд выглядит хорошая концепция:
-
В ней собрано столько информации, сколько нужно, чтобы узнать все подводные камни по продукту и требования заказчика.
-
Она написана грамотно и понятно для людей, не разбирающихся в разработке технически.
-
Из нее сразу ясно, для каких целей и пользователей создается решение, какие задачи оно будет решать.
-
Она хорошо структурирована, разделы логичны и идут последовательно.
-
Сложная логика дополнена вспомогательным визуалом — например, схемами, которые расшифровывают непонятные места.
-
Она не пытается предугадать все — фиксирует то, что известно на старте, и осознанно оставляет пространство для уточнений по ходу проекта.
-
Она остается понятной и прозрачной для всех, кто читает документ, даже спустя полгода-год.
Если через полгода-год концепцию можно открыть и с ходу понять логику принятых решений — значит, она разработана правильно.
Часто задаваемые вопросы о концепции проекта
Сколько времени занимает разработка концепции?
В среднем — от 8 до 60 часов работы аналитика в зависимости от сложности продукта и объема вводных данных. Простой сайт с понятной функциональностью можно описать за один-два дня. Сложную систему с несколькими ролями пользователей и нетривиальной бизнес-логикой — за одну-две недели.
Кто должен участвовать в разработке концепции, кроме аналитика?
Как минимум — разработчики или технический архитектор, чтобы оценить реализуемость решений, и дизайнер, если в концепции уже намечается структура интерфейса. Чем раньше в обсуждение подключается команда, тем меньше риск, что концепция окажется красивой, но нереализуемой в разумные сроки.
Что делать, если заказчик не хочет тратить время на концепцию?
Стоит объяснить, что она защищает интересы самого заказчика: без нее оценка сроков и бюджета будет приблизительной, а уточнения по ходу разработки почти всегда стоят дороже и занимают больше времени, чем их обсуждение на старте. Если заказчик все равно настаивает на разработке без концепции, разумно хотя бы зафиксировать ее ключевые пункты — цели, аудиторию, границы — в переписке.
Можно ли менять концепцию в процессе разработки?
Да, и это нормально: концепция — это зафиксированное на старте понимание, а не окончательный документ. Если в процессе появляются новые вводные, логичнее внести правки в концепцию и заново оценить их влияние на сроки и бюджет, чем молча менять требования по ходу работы.