Surf 
Тендеры и лиды
Информация
Разбираем концепцию цифрового продукта — самый ранний документ «зачем и что», который пишут до ТЗ и дизайна: зачем он нужен, что в него входит, как выглядит готовый шаблон с мини-примером и чем концепция отличается от ТЗ, бизнес-плана и устава проекта.
Типичный старт проекта выглядит энергично: идея всем нравится, и команда сразу бросается писать техническое задание и рисовать экраны. Проходит месяц-другой, и всплывает неприятное: заказчик всё это время представлял себе один продукт, а разработчики строили немного другой. Спорить уже поздно — половина работы сделана. Концепция проекта — это способ поймать расхождение в самом начале, когда согласовать общее понимание стоит одного разговора, а не переделки готового. Это короткий документ, который фиксирует, зачем мы делаем продукт и что это будет, ещё до того, как погружаться в детали.
Мы в Surf начинаем с концепции каждый проект — будь то проектирование продукта, дизайн приложения или мобильная разработка — и знаем, что пара страниц на старте экономит недели на финише. В этом материале — практический разбор для того, кто заказывает или ведёт цифровой продукт: что писать в концепции, как она выглядит и чем отличается от соседних документов. Речь именно про документ «зачем и что»; глубокий анализ рынка, детальное ТЗ и этапы разработки — это отдельные шаги, а если нужен расширенный гайд с полным шаблоном, у нас есть подробный разбор концепции проекта.
Концепция отвечает на два вопроса: зачем этот продукт вообще нужен и что он собой представляет на верхнем уровне. Не как именно реализовать каждую функцию — это уже задача ТЗ, — а какую проблему решаем, для кого, в чём ценность и где границы. Её задача не в детализации, а в том, чтобы все участники видели одну и ту же картину до того, как в неё начнут вкладывать деньги.
Хорошая концепция умещается на нескольких страницах, и это не недостаток, а свойство. Её должен понять человек не из команды — инвестор, руководитель смежного отдела, новый разработчик — за пять минут чтения. Если документ разросся до тома с требованиями, это уже не концепция, а что-то другое, и работать с ним как с точкой согласования не получится.
Соблазн пропустить концепцию понятен: кажется, что это лишняя бюрократия, а идея «и так всем ясна». На практике «ясна» она у каждого своя, и расхождения выясняются в самый дорогой момент. Заказчик думал, что приложение в первую очередь про быструю запись, а команда сделала акцент на подробном каталоге услуг — и теперь нужно переделывать логику, экраны и половину бэкенда.
Цена пропущенной концепции измеряется именно в таких переделках. Правка на этапе, когда есть только общий замысел, — это несколько строк текста и полчаса обсуждения. Та же правка на готовом продукте — это новая постановка задачи, работа дизайнера и разработчиков, повторное тестирование и сдвиг сроков. Концепция дешевле любого из этих переделочных циклов, поэтому написать её выгоднее, чем сэкономить пару дней на старте и заплатить неделями потом.
Единого стандарта нет, но проверенный набор разделов закрывает почти любой цифровой продукт. Ниже — рабочий шаблон, по которому можно собрать собственную концепцию; в каждом разделе подсказка, что в него писать.
Проблема — чью боль решаем и в чём она. Без внятной проблемы всё остальное повисает в воздухе.
Идея решения — что предлагаем, в одном-двух предложениях. Если не формулируется коротко, идея ещё не созрела.
Целевая аудитория — для кого продукт, какие у этих людей сегменты и потребности.
Ценность и отличие — почему выберут вас, а не существующие альтернативы и привычные способы решать проблему.
Цели и метрики — что считаем успехом в измеримых показателях: и для бизнеса, и для продукта.
Объём и границы — что входит в продукт, а что осознанно остаётся за рамками на этом этапе. Раздел, который экономит больше всего споров.
Риски — что может пойти не так и что вы с этим будете делать.
Оценка реализуемости — по верхам: сроки, ресурсы, технологическая выполнимость.
Раздел про границы стоит выделить особо: концепция не менее ценна тем, что она явно проговаривает, чего в продукте не будет. Именно размытые границы позже превращаются в бесконечное «а давайте ещё вот это» и в разросшийся бюджет.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Чтобы шаблон не остался абстрактным, вот как он мог бы выглядеть заполненным для несложного цифрового продукта — приложения для записи к врачу в сети клиник.
Проблема: пациенты тратят время на дозвон в регистратуру, часть не дозванивается и уходит к конкурентам.
Идея решения: мобильное приложение для онлайн-записи к врачу с напоминаниями и историей визитов.
Аудитория: пациенты сети клиник 25–55 лет, которые регулярно посещают врачей и привыкли к мобильным сервисам.
Ценность: запись за минуту без звонка, напоминания сокращают неявки, вся история под рукой.
Цели и метрики: за год перевести 40% записей в приложение, снизить долю неявок.
Границы: в первой версии — запись, напоминания, история; телемедицина и оплата страховок пока за рамками.
Риски: сложная интеграция с медицинской системой клиники; снижаем риск пилотом на одной клинике.
Реализуемость: MVP реалистичен на существующем API клиники в обозримый срок.
Даже такой короткий документ уже задаёт общее понимание: по нему видно, что делаем, для кого и где остановимся, — и с ним можно идти к ТЗ.
Концепцию постоянно путают с соседними документами, а из-за путаницы в неё либо впихивают лишнее, либо ждут от неё не того. Разница проста, если смотреть, на какой вопрос отвечает каждый.
Концепция
На какой вопрос отвечает: Зачем и что делаем
Детализация: Верхнеуровневая, пара страниц
Момент: Самый ранний, до ТЗ
ТЗ / SRS
На какой вопрос отвечает: Как именно реализуем
Детализация: Детальные требования
Момент: После концепции, перед разработкой
Бизнес-план
На какой вопрос отвечает: Как на этом заработаем
Детализация: Финмодель, рынок, деньги
Момент: Для бизнеса и инвесторов
Устав проекта
На какой вопрос отвечает: Кто отвечает и каковы границы
Детализация: Управленческая
Момент: При запуске проекта в управлении
Из таблицы виден порядок: концепция идёт первой и питает всё остальное. Из неё вырастает ТЗ, на неё опирается разговор с инвестором, к ней апеллируют, когда спорят, входит ли новая хотелка в проект. Поэтому подменять концепцию сразу техническим заданием — значит проектировать дом, не договорившись, для кого он и сколько в нём этажей.
Сильнее всего роль концепции видна там, где смелое решение на старте определяет всё остальное. Для аптечной сети «Ригла» ключевым был именно концептуальный выбор в самом начале: не делать шесть отдельных приложений для разных брендов сети, а построить единую платформу с общим ядром, на которой живут все бренды.
По данным кейса Rigla, эта концепция дала экономию около 40% против разработки каждого приложения по отдельности, а получившаяся система держит месячную аудиторию 1,3 млн+ пользователей при доле сессий без сбоев 99,97–99,99%. Если бы идею «одна платформа, много брендов» не зафиксировали как концепцию на старте, проект легко ушёл бы шестью параллельными дорогами с шестикратными затратами. Ранний документ «зачем и что» здесь стоил недорого, а определил экономику всего проекта.
Понять, что концепция удалась, можно по нескольким признакам — и по типичным ошибкам, которых стоит избегать.
Понятна человеку со стороны. Если её приходится объяснять на словах, документ не работает как точка согласования.
Реалистична. Цели и сроки бьются с ресурсами, а не описывают мечту.
Лаконична. Несколько страниц, а не том: концепция теряет смысл, когда раздувается до ТЗ.
С измеримыми целями. «Сделать удобно» — не цель; цель — то, что можно проверить цифрой.
С явными границами. Написано и что делаем, и чего осознанно не делаем сейчас.
Главная ошибка — либо пропустить концепцию вовсе, либо превратить её в свалку из анализа рынка, требований и финмодели. И то, и другое лишает её смысла: ценность концепции в том, что это короткий и ясный ответ на вопрос, зачем и что мы строим.
Концепция проекта — короткий документ «зачем и что», который фиксирует общее понимание продукта до ТЗ и дизайна.
Её пишут в первую очередь, чтобы поймать расхождение ожиданий на старте, а не в готовом продукте, где переделки дороги.
В неё входят проблема, идея, аудитория, ценность, цели и метрики, границы, риски и оценка реализуемости.
Концепция — не ТЗ, не бизнес-план и не устав: у каждого документа свой вопрос и свой момент.
Хорошая концепция понятна человеку со стороны, реалистична, лаконична и явно очерчивает границы продукта.
Концепция проекта не делает работу заметной — её ценность в том, что не случилось: в несделанных переделках и несостоявшихся спорах о том, что вообще строим. Пара страниц, написанных до старта, почти всегда дешевле недель, потраченных на выяснение этого уже по ходу разработки. Поэтому начинать стоит не с ТЗ и не с макетов, а с ответа на простой вопрос: зачем и что мы делаем.
Владимир Макеев, генеральный директор Surf — компании по разработке и дизайну цифровых продуктов для крупного и среднего бизнеса.
