Когда в компании появляется новая идея, кажется, что все очевидно: знаем, зачем это нужно, кто будет пользоваться, и даже описали пару простых функций. Но проходит неделя — и вдруг оказывается, что у каждого члена команды свое понимание задачи. Разработчики обсуждают одно, стейкхолдеры ждут другое. Сроки тают, а вместо уверенности появляется ощущение, что что-то пошло не так.
Разбираем, что такое концепция проекта, зачем она нужна до написания ТЗ и как собрать ее за один спринт.
Что такое концепция проекта и зачем она нужна
Когда появляется идея нового проекта, хочется как можно быстрее приступить к работе: собрать команду, раздать задачи, запустить разработку. А что еще нужно? Нужна концепция.
Концепция проекта — это, простыми словами, описание идеи, целей и базовой логики реализации идеи на одну или пару страниц. Она помогает:
- Быстро проверить проект на жизнеспособность — стоит ли вообще его запускать.
- Выровнять ожидания. Чтобы не случилось такого, что один видит инновационную платформу, а другой — лендинг, который можно сделать за неделю.
- Заранее заметить узкие места — в ресурсах, данных, экспертизе.
- Минимизировать конфликты на старте.
- Снизить количество согласований.
- Ускорить старт и дать всем участникам прозрачную картину — без недомолвок и лишних ожиданий.
Прежде чем писать техническое задание, рассчитывать бюджет или составлять проектную документацию, стоит начать с концепции. Это первый шаг в подготовке проекта.
Особенно она нужна крупным командам, где решения принимаются не единолично, а проходят через несколько уровней согласования: от продакт-менеджера и руководителя разработки до финдиректора, юристов и инвесторов.
Чем концепция отличается от других документов:
Чтобы концепция действительно работала, в нее стоит включить 7 обязательных блоков.
Структура концепции проекта: 7 обязательных блоков
Концепция проекта — емкий и понятный документ. В нем всегда есть семь обязательных блоков:
1. Краткое описание проекта
Один–два абзаца: суть идеи, зачем она вообще нужна, в каком контексте возникла.
2. Цель и ожидаемый результат
Цель лучше ставить по SMART, например, «Увеличить конверсию на 15% за 3 месяца». Лозунги вроде «сделать удобнее» непонятны ни разработчикам, ни руководителям.
3. Целевая аудитория и ее потребности
Опишите, кто будет пользоваться результатом вашей работы, какие задачи хочет решить ваша ЦА с помощью нового продукта, как сейчас она их решает. Здесь не нужны длинные портреты и подробное описание персонажей. Лучше — конкретные сегменты и типичные ситуации.
Пример:
- Пользователь: менеджер по логистике в компании, которая занимается продажей детских товаров;
- Что делает во время работы: вручную заполняет таблицы с доставками, сверяется с 1С, звонит в транспортные компании;
- Боль: тратит по 3 часа в день на рутину и часто ошибается.
4. Предлагаемое решение или стратегия MVP
В этом блоке концепции нужно сжато описать суть проекта:
- какой подход для разработки нужно использовать;
- какой должен быть минимальный набор функций, чтобы выпустить продукт или MVP;
- что точно попадет в первую версию, а что можно отложить на потом.
Не надо сразу описывать каждую мелочь проекта. Но должно быть понятно, будет ли это мобильное приложение, плагин к CRM, внутренняя BI-система или автоматизация через Google-таблицы.
Пример:
- MVP: дашборд с фильтрами по статусу заявок. Работает по API, подключаясь к 1С, обновляется раз в час;
- полноценное решение: веб-сервис с авторизацией, возможностью выгрузки в Excel и правами доступа по ролям;
- отложенные функции: мобильная версия, Telegram-бот, интеграция с Outlook.
Подробнее об MVP рассказывали в статье «Что такое MVP и MLP и как снизить риски при запуске нового продукта»
5. Ресурсы и бюджет
Проект не сделает сам себя. Поэтому в концепции нужно зафиксировать:
- кто участвует в создании проекта: разработчики, аналитики, дизайнеры, маркетологи и другие;
- сколько времени им нужно;
- какие деньги и инфраструктура понадобятся.
Часто на этом этапе становится понятно, что не хватает аналитики, лицензий на необходимое ПО и даже серьезной суммы на оплату работы команды.
6. Риски и ограничения
Они могут поджидать на каждом шагу при создании проекта. Примеры рисков:
- зависимость от внешних подрядчиков,
- нет доступа к нужным данным,
- ограничения законодательства,
- недостаток экспертизы в команде.
Не надо пытаться выглядеть супергероями. Учтя риски на старте, вы защитите себя от провала.
7. Метрики успеха
Lead time, ROI, NPS, конверсия — выбирайте, что релевантно. Главное, чтобы метрика была измеримой и проверяемой. Примеры:
- конверсия в покупку больше 3% в течение 30 дней после запуска;
- время ответа на обращение — не более 2 минут;
- 80% пользователей повторно заходят в приложение в течение недели.
Как сформировать концепцию за один рабочий спринт
Спринт — понятие из Scrum. Это короткий отрезок времени (1–4 недели), в течение которого команда фокусируется на достижении конкретного результата. Это удобная рамка, чтобы ограничить время и довести дело до конца. Подходит не только для разработки, но и для запуска любой идеи, которую нужно быстро обдумать, оформить ее структуру и согласовать.
Спринт может помочь команде не затягивать разработку концепции проекта. Соберите нужных людей, сделайте набросок, пройдитесь по ключевым рискам — и подготовьте версию 1.0, которую можно показать руководству и команде. Вот как это можно сделать за один спринт:
1. Определите бизнес-контекст: проведите интервью со стейкхолдерами. Пообщайтесь с заказчиками и инициаторами проекта. Выясните, чего они ждут, какие бизнес-проблемы хотят решить и есть ли ограничения и приоритеты.
2. Изучите пользователей: проведите экспресс-дискавери. Интервью с 3–5 представителями целевой аудитории поможет понять, есть ли у них боль, как они сейчас ее решают, чего не хватает. Это быстрое, но ценное подтверждение, что проект нужен не только бизнесу, но и потенциальным пользователям.
3. Определите риски и ресурсы с экспертами. Подключите тех, кто будет непосредственно участвовать в разработке проекта — маркетологов, аналитиков, дизайнеров, фронтенд- и бэкенд-разработчиков и других специалистов. Они скажут, какие идеи нужно реализовывать несколько месяцев и за большие деньги, а какие можно запустить за две недели по цене лендинга. Это спасет от разработки нежизнеспособного продукта.
4. Зафиксируйте метрики и согласуйте их с PMO и финансами. Определите, какие цифры покажут, что разработка проекта идет по плану. Это может быть ROI, NPS, количество регистраций, Lead Time — все, что важно бизнесу.
5. Создайте черновик концепции: зафиксируйте 7 ключевых блоков. Не тратьте сутки на формулировки. Важно просто зафиксировать основные гипотезы: цели, аудитория, стратегия, ресурсы, риски, метрики.
6. Утвердите версию 1.0. Получите «OK» от ключевых людей проекта. С этого момента концепция становится живой: она не лежит в папке, а помогает двигаться вперед, как план навигатора.
После этого можно начать остальные этапы реализации проекта.
Почему концепцию проекта лучше делать в рамках спринта
В классическом подходе разработка концепции напоминает долгую семейную ссору: все спорят, пишут правки в документах, потом переделывают все в PowerPoint, а в итоге к запуску теряется и контекст, и энергия.
Спринт-подход работает иначе: вы берете одну ключевую задачу, например, формирование концепции проекта, и ограничиваете ее по времени. Структура + дедлайн = результат. Такое решение хорошо подходит Agile-командам и ускоряет старт без потери качества.
Что дает спринт:
- Устанавливает жесткий дедлайн. Вы не обсуждаете задачу бесконечно. У вас есть пара недель, чтобы договариваетесь и сформировать документ.
- Фокусирует на одной работе. Вы и ваша команда не распыляетесь между задачами, а концентрируетесь на ключевых блоках концепции.
- Заставляет давать активную обратную связь. Согласование идет параллельно: вы не ждете ответа неделями, а решаете важные вопросы здесь и сейчас.
Рабочая версия — лучше, чем идеальный черновик. Главное — зафиксировать общую рамку, а не вычитывать все до запятой. Такой формат особенно полезен для больших организаций, где согласование может убить любую инициативу на корню. Спринт делает процесс динамичнее: всё быстро, по делу и с уважением к ресурсам всех участников.
Как организовать создание концепции проекта на доске в Kaiten
После того как вы договорились с командой и стейкхолдерами о создании концепции, самое время организовать рабочее пространство. В Kaiten для этого есть Scrum-доска. Вот как ее настроить.
Выберите шаблон Scrum-доски и создайте колонки
В Kaiten уже есть готовый шаблон. Используйте его, чтобы не тратить время на ручную настройку.
Создайте необходимые колонки, которые будут отражать этапы работы:
- планы на спринт (To Do) — задачи, которые вы берете в работу в текущую итерацию;
- в работе (In Progress) — все, над чем сейчас работает команда;
- на проверке (Review) — задачи, которые нужно протестировать, обсудить или согласовать;
- готово (Done) — задачи, которые завершены и согласованы.
Для каждого блока концепции создайте отдельную дорожку
В Kaiten можно делить доску на дорожки (свимлайны). Это удобно при одновременной работе над несколькими направлениями. Создайте дорожки для всех семи блоков концепции:
- краткое описание проекта;
- цели и ожидаемые результаты;
- целевая аудитория и ее потребности;
- предлагаемое решение или стратегия MVP;
- ресурсы и бюджет;
- риски и ограничения;
- метрики успеха.
Такой подход поможет команде параллельно работать над всеми блоками концепции.
Разместите карточки с задачами на каждой дорожке
Заполняйте дорожки задачами, которые помогут ответить на ключевые вопросы блока концепции. Например:
Задачи для дорожки «Целевая аудитория и ее потребности»:
- интервью с текущими клиентами;
- JTBD (Jobs To Be Done);
- сбор инсайтов из обращений в поддержку;
- анализ конкурентов и функциональности их приложений.
- Интервью со стейкхолдерами: юридические и административные ограничения.
- Анализ доступных API.
В каждой задаче можно назначить ответственного и указать срок выполнения, а также там можно будет оставлять комментарии в процессе работы, чтобы сохранить историю обсуждений.
Внутри задач используйте чек-листы
Если задача объемная, создайте чек-лист с более мелкими задачами. Например, в карточке «Интервью с пользователями» может быть такой чек-лист:
- согласовать список респондентов;
- назначить время;
- подготовить вопросы;
- провести интервью;
- зафиксировать инсайты.
Укажите сроки спринта и запустите его
Срок спринта всегда будет отображаться на доске и напоминать о дедлайне.
Так как все задачи и процесс работы визуализированы, вы сможете анализировать эффективность команды и замечать, если она сталкивается с проблемами. В этом вам помогут встроенные графики и отчеты в Kaiten.
Как следить за разработкой концепции
Kaiten автоматически собирает множество данных об эффективности команды, помогает выявлять «узкие места» и проблемы.
- Lead Time — покажет, сколько времени в среднем занимает подготовка задач в рамках каждого блока концепции. Если время растет, значит, где-то возникли сложности. Подробнее об этой метрике — в статье «Lead Time vs Cycle Time: в чем разница».
- Throughput — количество задач, закрытых за спринт. Помогает оценить темп команды: достаточно ли ресурсов и не перегружены ли исполнители.
- WIP-лимиты на CFD (кумулятивная диаграмма потока) — сигнализируют о дисбалансе. Если задачи застревают в отдельных колонках, это признак «узкого горлышка» в процессе.
- Доля задач без описания или с просрочкой — индикатор качества планирования. Много таких задач — значит, стоит пересмотреть подход к формулировке требований и распределению ответственности.
Эти метрики помогут не только следить за сроками разработки проектной концепции, но и провести продуктивную ретроспективу в конце спринта. Вы увидите, какие блоки дались команде легко, а где возникли сложности. Это можно будет учесть при подготовке следующих проектов.
Хорошая концепция экономит десятки часов на обсуждениях, снимает лишние вопросы и помогает всем двигаться в одном направлении. Даже если вы запускаете проект внутри одной команды, сформулированная концепция — это шаг к прозрачности и управляемости. А если речь о корпорации с десятками участников — без нее не обойтись.
👉 А вы создаете концепции перед стартом проектов? Напишите в комментариях — будет интересно сравнить подходы.
