01
Не интернет-магазин
Человек покупает не мёд
Он покупает связь с конкретным ульем, у которого есть номер, имя, пчеловод и история. Мёд — следствие, а не товар. Поэтому центр продукта — карточка объекта, а не карточка товара.
PRD · v1.0/Август 2026 · До Такта 0
Цифровая платформа «Реальная ферма в виртуальном мире»
Человек выбирает конкретный улей или дерево на ферме в Сочи, даёт ему имя, весь сезон видит фото и отчёты пчеловода, получает свой мёд и приезжает на сбор урожая. Документ фиксирует, из чего состоит продукт, где проходят границы первой версии и какие решения нужно принять до старта разработки.
🐝
Реальный объект
🔗
Цифровая связь
🍯
Физический результат
PRD
Product Requirements DocumentДокумент, фиксирующий цели, аудиторию, функции и границы продукта до старта разработки.
01 · Позиционирование
Чем этот продукт не является
Три отрицания, которые определяют архитектуру сильнее, чем любой список функций.
02
Не CRM фермы
Интерфейс обращён к городскому жителю
Пользователь никогда не интересовался сельским хозяйством. Ему нужны простые слова, красивые фото и понятные решения из двух-трёх вариантов, а не агрономические сводки.
03
Не игра
Геймификация обслуживает возврат
Уровни и достижения нужны, чтобы человек возвращался между событиями сезона. Они не создают отдельный игровой мир и не подменяют реальные действия на ферме.
02 · Контекст
Исходные данные проекта
Модель не изобретается с нуля: краудфарминг работает в Европе не первый год. Это снижает продуктовый риск и даёт готовые ориентиры по сценариям и ценам.
Территория первой фермы
Сочи — пасека, сад, огород, животные, эвкалиптовая плантация
Стадия
ТЗ подготовлено, выбор подрядчика, разработка не начата
Первые типы объектов
Улей и дерево — ядро MVP по решению заказчика
Проверенная модель в мире
CrowdFarming (Испания), Treedom, adopt-a-hive/olive-программы
Ключевая гипотеза
Человек готов платить за эмоциональную связь с конкретным объектом
Горизонт масштабирования
Через 3 года — до 100 независимых ферм на одной платформе
03 · Устройство продукта
Четыре системы в одном продукте
Карта, геймификация и агротуризм — обёртки над этими четырьмя слоями. Порядок строительства обратен порядку, в котором продукт видит пользователь.
Слой 1
Ядро: реестр реальных объектов
Ферма → Зона → Объект → Тариф → Участие. Универсальная карточка, на которой одинаково живут улей, дерево, грядка и коза. Всё остальное — надстройки над этим слоем.
Строится первым
Слой 2
Подписочный сервис
Участие на сезон, продление, тарифные планы, подарки, долевое и корпоративное участие. Здесь живут деньги продукта и здесь же — главный риск переделки, если модель заложена неверно.
Параллельно с ядром
Слой 3
E-commerce с персонализацией
Магазин фермерской продукции плюс принципиально иная витрина — «продукция с моего объекта». Мёд с улья №124 отличается от мёда в каталоге тем, что человек видел, как он появлялся.
После ядра
Слой 4
Полевая CRM сотрудника
Инструмент пчеловода и садовника: список объектов на сегодня, съёмка, комментарий, публикация. Производит весь контент продукта. Без него платформа мертва уже на второй месяц.
Критический путь
04 · Роли пользователей
Кто работает с платформой
Участник
Выбирает объект, оформляет участие, наблюдает, принимает решения по уходу, получает продукцию, приезжает на ферму
Получатель подарка
Приходит по сертификату, активирует аккаунт и становится участником. Отдельный сценарий входа без покупки
Сотрудник фермы
Пчеловод, садовник, агроном, животновод. Видит свой список объектов на день, снимает и публикует отчёты
Администратор фермы
Создаёт зоны и объекты, назначает ID и цены, редактирует тарифы, ведёт новости и события, видит заказы и платежи
Оператор поддержки
Отвечает на вопросы участников, обрабатывает проблемы с заказами и компенсации. В MVP — та же учётная запись, что и администратор
Партнёрская ферма
Phase II. Своя территория, свои объекты и сотрудники, общий каталог для пользователя, выплаты через сплит-платежи
05 · Ядро
Доменная модель платформы
Цепочка из п. 30 технического задания, доведённая до уровня сущностей. Именно она позволяет улью, дереву, грядке и козе жить на одном движке.
5.1 · Сущности
Ферма
Территория с собственником, реквизитами и набором зон. Обязательный скоуп во всех сущностях с первого дня
Зона
Пасека, сад, огород, плантация, загон. Имеет положение на карте и ответственного сотрудника
Объект
Улей, дерево, грядка, животное. Глобально уникальный ID, тип, атрибуты по типу, статус, координаты
Тариф
Что входит в участие: доступ, объём продукции, посещение, привилегии. Редактируется из админки без программиста
Участие
Связь пользователя с объектом на период: даты, тариф, присвоенное имя, статус оплаты, история продлений
Событие
Осмотр, цветение, медосбор, перевод на пастбище. Порождает запись в ленте и уведомление адресатам
Продукция
Что дал объект: 18,4 кг мёда. Привязана к объекту и сезону, конвертируется в заказ по тарифу
Заказ
Фасовка, персональные этикетки, самовывоз или доставка. Общая сущность для магазина и продукции с объекта
5.2 · Правила, заложенные с первого дня
✓Идентификатор объекта уникален глобально, а не в пределах фермы — иначе объединение каталогов сломается
✓Каждая сущность несёт ссылку на ферму, даже когда ферма одна
✓Роль сотрудника ограничена своей фермой и своими зонами
✓Медиа хранится с разделением по ферме — это упрощает и объёмы, и будущее разделение прав
✓Платёжный провайдер выбирается с поддержкой сплита сразу — миграция платежей на живой базе подписчиков болезненна
✓Тип объекта — это данные, а не код: добавление новой культуры не должно требовать релиза
Почему это важно именно сейчас. Скоуп по ферме, глобальные идентификаторы и платёжная схема со сплитом стоят на старте близко к нулю. Через год, на живой базе подписчиков и проведённых платежах, их добавление превращается в отдельный проект с миграцией данных и простоем продаж.
06 · Модуль 1
Пасека — «Мой улей»
Самый понятный сценарий и лучший кандидат на первый модуль: короткий сезон, яркий результат в килограммах и естественный повод приехать на ферму.
6.1 · Сценарий от выбора до продукции
01
Пользователь
Открывает карту фермы
Видит зоны территории, выбирает «Пасека» и попадает в список доступных ульев по секторам.
02
Пользователь
Выбирает улей и тариф
Карточка улья: сектор, пчеловод, состояние семьи, ожидаемый сбор. Выбирает тариф Basic, Family или Premium.
03
Система
Резервирует объект на время оплаты
Улей помечается занятым на 20 минут, чтобы двое не купили один и тот же объект одновременно.
04
Пользователь
Оплачивает и даёт имя
Оплата картой или СБП, чек по 54-ФЗ. После оплаты присваивает улью имя — «Мишкин мёд».
05
Сотрудник
Проводит осмотр и публикует отчёт
Пчеловод снимает улей с телефона, отмечает состояние семьи и дату следующего осмотра, публикует одним нажатием.
06
Система
Доставляет событие владельцу
Запись появляется в ленте, уходит уведомление в Telegram и на email. Владелец видит своё фото в тот же день.
07
Система
Фиксирует медосбор
После откачки в карточке появляется результат: «Ваш улей дал 18,4 кг мёда» и доступный по тарифу объём.
08
Пользователь
Распоряжается продукцией
Забрать на ферме, заказать доставку, добавить фасовку, сделать персональные банки, подарить или приехать на сбор.
6.2 · Функциональные требования
✓Каталог ульев по секторам с признаком «свободен / занят / мой»
✓Карточка улья: сектор, номер, пчеловод, дата подключения, дата следующего осмотра, ожидаемый сбор
✓Резервирование объекта на время оформления оплаты
✓Присвоение имени объекту после оплаты и его отображение везде вместо номера
✓История осмотров с фото, видео и комментариями пчеловода
✓Фиксация результата медосбора в килограммах и доступного объёма по тарифу
✓Заказ продукции прямо из карточки объекта
✓Персональная фасовка и этикетка с именем участника
✓Продление участия на следующий сезон с сохранением того же объекта
✓Приоритетное право на свой объект при продлении
6.3 · Ограничения первой версии
×
Датчики веса, температуры, влажности и активности — Phase III
×
Live-камеры на пасеке — Phase III
×
Автоматический прогноз урожайности — Phase III
×
Выбор конкретной матки или породы пчелосемьи
07 · Модуль 2
Сад — «Моё дерево»
Второй тип объекта на той же карточке. Если ядро спроектировано верно, модуль стоит около четверти от «Пасеки» — это и есть проверка качества архитектуры.
7.1 · Сценарий
01
Пользователь
Выбирает культуру
Эвкалипт, мандарин, лимон, инжир, хурма, олива, яблоня. Каждая культура — свой сезонный календарь событий.
02
Пользователь
Выбирает конкретное дерево
Внутри сада — конкретный экземпляр с номером, возрастом и положением в квартале.
03
Система
Выдаёт цифровой сертификат
После оплаты формируется именной сертификат участия с номером дерева и датой подключения.
04
Сотрудник
Ведёт сезон
Садовник фиксирует пробуждение, цветение, завязь, налив, сбор. Каждое событие — фото и короткий комментарий.
05
Пользователь
Получает урожай
Забирает на ферме, заказывает доставку или превращает в подарочный набор.
7.2 · Функциональные требования
✓Каталог деревьев с фильтром по культуре и саду
✓Карточка дерева: культура, номер, возраст, квартал, ответственный садовник
✓Цифровой сертификат участия с именем и номером дерева
✓Сезонный календарь событий, свой для каждой культуры
✓Сценарий «Посади дерево»: оплата посадки, присвоение номера, появление на карте — Phase II
✓Наследование архитектуры карточки от модуля «Пасека» без дублирования кода
08 · Универсальная карточка
Одна архитектура для всех типов объектов
Улей, дерево, грядка и животное различаются набором атрибутов и календарём событий, но живут в одной сущности. Добавление типа — настройка, а не релиз.
Поле
Характер
Комментарий
Идентификатор
Обязательное
Глобально уникальный, отображается пользователю как номер объекта
Тип объекта
Обязательное
Улей, дерево, грядка, животное. Определяет набор атрибутов и календарь событий
Имя от пользователя
Появляется после оплаты
Заменяет номер во всех интерфейсах владельца
Расположение
Обязательное
Зона, сектор, координаты на карте фермы
Статус
Обязательное
Свободен, зарезервирован, занят, на обслуживании, выведен из оборота
Ответственный сотрудник
Обязательное
Пчеловод, садовник, животновод — показывается владельцу по имени
Медиагалерея
Накопительное
Все фото и видео объекта по датам, независимо от смены владельца
История событий
Накопительное
Полная хронология объекта за все сезоны
Продукция
По сезонам
Что и сколько дал объект, сколько доступно владельцу по тарифу
История участий
Накопительное
Кто и когда был владельцем — нужно для продлений и приоритетного права
История заказов
Связанное
Заказы продукции, привязанные к этому объекту
Прогноз
Опциональное
Ожидаемый сбор и сроки. В MVP заполняется сотрудником вручную
История объекта переживает владельца. Медиа и события привязаны к объекту, а не к участию. Когда улей переходит к новому человеку, у объекта остаётся полная биография — это ценность для продукта и основа для приоритетного права на продление.
09 · Критический модуль
Кабинет сотрудника — двигатель всего продукта
В техническом задании он стоит 17-м из 19 пунктов MVP. Мы переносим его на критический путь: контент, который он производит, — единственная причина, по которой участник возвращается в приложение между сезонами.
9.1 · Рабочий день пчеловода
01
Утро
Открывает список на день
Сегодня проверить: улей 101, 104, 124, 131. Список формируется из графика осмотров и приоритетов.
02
В поле
Выбирает объект и снимает
Камера прямо в интерфейсе. Фото и короткое видео сжимаются на устройстве, привязка к объекту автоматическая.
03
В поле
Отмечает состояние
Короткая форма по типу объекта плюс свободный комментарий голосом или текстом. Дата следующего осмотра.
04
Без сети
Материалы копятся на устройстве
На пасеке связи может не быть. Ничего не теряется: очередь хранится локально и уходит сама, когда появится сеть.
05
Система
Публикует владельцу
Одно нажатие «Готово» — событие в ленте владельца и уведомление. Отдельный менеджер в цепочке не участвует.
9.2 · Функциональные требования
✓Список объектов на день по зонам и ответственным
✓Съёмка фото и видео прямо в интерфейсе, без перехода в галерею
✓Сжатие медиа на устройстве до отправки
✓Офлайн-очередь: работа без сети и фоновая досылка при появлении связи
✓Формы состояния, различающиеся по типу объекта
✓Голосовой комментарий с расшифровкой в текст
✓Массовое действие: один отчёт на группу объектов одного сектора
✓Дата следующего осмотра, автоматически попадающая в план
✓Контроль выполнения: администратор видит, какие объекты давно без отчёта
Масштаб задачи. 500 объектов при еженедельном осмотре дают около 2 000 единиц медиа в месяц. Ни один менеджер не разошлёт это вручную. Поэтому кабинет сотрудника — не вспомогательный экран, а производственная линия контента, и проектировать его нужно первым.
10 · Удержание
Лента событий как сезонный контент-календарь
Между оформлением участия в марте и медосбором в сентябре проходит полгода. Лента — не украшение, а механизм, который переносит человека через этот разрыв.
10.1 · Сезонный календарь событий
Период
Улей
Дерево
Март — апрель
Первый весенний осмотр, оценка зимовки, чистка
Пробуждение, обрезка, первая подкормка
Май — июнь
Рост семьи, начало цветения медоносов, расширение
Цветение, завязь, фото цветущего дерева
Июль — август
Главный медосбор, откачка, результат сезона
Налив плодов, полив, защита урожая
Сентябрь — октябрь
Итоги сезона, подготовка к зиме, доступна продукция
Сбор урожая, приглашение приехать на сбор
Ноябрь — февраль
Зимовка: редкие, но регулярные сводки о состоянии
Покой, обрезка, планы на следующий сезон
10.2 · Правила ленты
✓Минимум одно событие по объекту в две недели даже в межсезонье
✓Событие с фото приоритетнее текстового: без изображения запись в ленту не публикуется
✓Персональная лента объединяет все объекты пользователя в одну хронологию
✓Уведомление ведёт сразу в карточку конкретного объекта, а не на главную
✓Напоминание о приближении медосбора или сбора урожая за две недели
✓Приглашение приехать на сбор своего урожая — ключевая точка перехода в офлайн
✓Предложение продления формируется до окончания сезона, а не после
11 · Метрики
Цифры, по которым оценивается первая версия
Стоимость привлечения и LTV считаются вне платформы: CAC живёт в рекламных кабинетах. Внутри продукта — события и выгрузки, дашборды строит готовый BI.
0 %
Продление на второй сезон
Главная метрика продукта: без продлений экономика не сходится
0 дней
Максимум между событиями
Предельный интервал без новостей по объекту: дальше начинается отток
0 %
Доля допродаж в выручке
Фасовка, доставка, посещения и мероприятия сверх цены участия
0 %
Доля подарочных покупок
Подарок — самый дешёвый канал привлечения новых участников
12 · Монетизация
Тарифы и модели участия
Объект не привязан к одной цене. И, что важнее для экономики, один физический актив не обязан соответствовать одному клиенту.
12.1 · Тарифная линейка
Тариф
Что входит
Роль в экономике
Basic
Цифровой доступ к объекту, лента событий, фото и отчёты
Точка входа с низким барьером, источник апсейла
Family
Всё из Basic плюс объём продукции и одно посещение фермы
Основной тариф, на который ориентируется экономика
Premium
Увеличенный объём, персональная упаковка, мероприятие, привилегии
Маржинальный тариф и источник эмоциональных отзывов
12.2 · Модели участия
Индивидуальное
Один человек — один объект. Базовая модель
Семейное
Несколько членов семьи с доступом к одной карточке, один плательщик
Долевое / клубное
Несколько участников на один объект с распределением продукции. Резко повышает выручку с физического актива
Подарочное
Покупатель и владелец — разные люди. Отдельный сценарий активации
Корпоративное
Компания оформляет объекты сотрудникам или клиентам. Требует пакетной покупки и брендирования сертификатов
Долевое участие меняет экономику сильнее любой другой функции. Один улей, разделённый между четырьмя участниками, приносит кратно больше выручки с того же физического актива и снижает порог входа для клиента. Архитектура участия должна допускать нескольких владельцев одного объекта с самого начала, даже если продавать так вы начнёте позже.
13 · QR-механика
Мост между физическим объектом и цифровой карточкой
Дешёвый в реализации модуль с непропорционально высоким эффектом: он работает и на ферме, и на упаковке, попадающей к чужим людям.
1
Система
Каждому объекту генерируется постоянный QR-код при создании в админке
2
Ферма
Код печатается на табличке улья, бирке дерева, колышке грядки и на упаковке продукции
3
Пользователь
Гость на ферме сканирует код у реального объекта
4
Система
Открывается карточка объекта: своя — с полной историей, чужая — с публичной витриной и предложением участия
5
Пользователь
Код на банке мёда ведёт к истории конкретного улья — работает как канал привлечения через продукт
14 · Административная панель
Ферма управляет продуктом без программиста
Второй по объёму модуль после ядра. Строится на готовой admin-платформе с кастомизацией — функциональность та же, экономия по блоку около 40 %.
✓Создание ферм, зон и объектов без участия программиста
✓Массовый импорт объектов из таблицы — заводить 500 ульев вручную недопустимо
✓Назначение ID и позиций объектов на карте
✓Редактирование тарифов, состава и цен
✓Управление участием: продление, перенос, отмена, компенсация
✓Заказы и платежи: статусы, возвраты, ручная корректировка
✓Пользователи: поиск, история, объекты, обращения
✓Новости фермы и календарь мероприятий
✓Ручные рассылки уведомлений по сегментам
✓Контроль контент-конвейера: объекты без отчёта дольше N дней
15 · Технические допущения
Решения, принятые до Discovery
Всё перечисленное подлежит подтверждению в Такте 0, но заложено в оценку и определяет стоимость первой версии.
Веб-приложение, не нативка
MVP — адаптивное веб-приложение с установкой на домашний экран. Нативные приложения в сторах выносятся в Phase II: они не проверяют гипотезу, но заметно удорожают первую версию.
Telegram как основной канал
В России Telegram-уведомления доходят лучше push и не зависят от ограничений iOS на web-push. Push оставляем как дополнительный канал, а не единственный.
Готовая admin-платформа
Административная панель строится на готовом решении с кастомизацией, а не пишется с нуля. Функциональность та же, экономия около 40 % по этому блоку.
Медиа в объектном хранилище
Фото и видео не хранятся рядом с приложением: объектное хранилище плюс раздача через CDN. Объём растёт линейно числу объектов и осмотров.
Платежи со сплитом с первого дня
Провайдер выбирается с поддержкой маркетплейс-схемы, даже если ферма одна. Смена платёжного контура на живой базе подписчиков — самая дорогая из миграций.
Карта как данные, а не картинка
Иллюстрация территории и позиции объектов разделены. Смена художественного слоя или переход к 3D не требует переноса объектов вручную.
Аналитика событиями, дашборды готовым BI
Внутри платформы — событийный слой и выгрузки. CAC и LTV собираются вне продукта: стоимость привлечения живёт в рекламных кабинетах.
Тип объекта — конфигурация
Добавление новой культуры или типа актива выполняется настройкой, а не релизом. Это условие масштабирования на новые фермы.
16 · Масштабирование
Мультиферма — это три разных продукта
Пункт 25 технического задания объединяет три уровня, различающиеся по стоимости примерно вдвое. Разделяем их явно и реализуем первый.
Уровень
Что означает
Когда делаем
Уровень 1 · Общий бренд
Один сайт и один аккаунт, объекты разных ферм в одном кабинете «Мои фермы»
Закладываем в MVP: скоуп по ферме во всех сущностях, глобальные ID, роли сотрудников по ферме
Уровень 2 · Маркетплейс
Фермы-партнёры получают выплаты, платформа удерживает комиссию, отдельные кабинеты и отчётность
Phase II. Требует сплит-платежей, договорной схемы и модерации партнёров
Уровень 3 · White-label
У каждой фермы свой домен, бренд и оформление, общий технологический слой
Phase III и только при подтверждённом спросе со стороны других ферм
Принцип, который мы предлагаем зафиксировать на старте. Сейчас строится MVP для одной фермы в Сочи, но backend проектируется так, будто через три года к системе подключаются сто независимых ферм. При этом в первую версию попадает только то, что реально нужно первой ферме, — иначе фундамент под сто ферм съест бюджет одной.
17 · Дорожная карта
Такт 0 → MVP → Phase II → Phase III
Каждый этап заканчивается работающим сценарием, а не набором экранов. Первый этап отвечает на вопрос, стоит ли делать остальные.
Такт 0 ·
6 недель
Первый шаг
Discovery и проверка спроса
- Бизнес-модель, модели участия, юнит-экономика
- User Flow, CJM, информационная архитектура
- UX-прототип и UI-концепция
- Техническая архитектура и декомпозиция
- Лендинг и приём предзаказов с оплатой
→ Ответ, платят ли за гипотезу, и фиксированная смета вместо вилки
MVP ·
5 месяцев
Первая версия
Улей, дерево и весь цикл
- Ядро: реестр объектов, тарифы, участие, платежи
- Карта фермы, каталог, карточка объекта, «Моя ферма»
- Кабинет сотрудника с офлайн-съёмкой
- Лента событий, уведомления, QR
- Магазин, подарки, админка, аналитика
→ Полный цикл: выбор → оплата → сезон → продукция → визит → продление
Phase II ·
после сезона
Расширение
Грядки, животные, агротуризм
- Модули грядки и животных на той же карточке
- Доставка с интеграцией СДЭК и Почты
- Бронирование посещений, экскурсий, мероприятий
- Клубная и реферальная программы
- Мультиферма второго уровня со сплит-выплатами
→ Рост выручки с существующей базы и подключение первой партнёрской фермы
Phase III ·
горизонт
Перспектива
Датчики, 3D и цифровой двойник
- IoT: вес улья, температура, влажность, активность
- Live-камеры и погодные данные
- Полноценная 3D-ферма и цифровой двойник территории
- AI-ассистент фермера и прогноз урожайности
- White-label и международная версия
→ Платформа как самостоятельный технологический продукт
Принципы поэтапного внедрения
✓Ядро строится один раз: второй тип объекта стоит около четверти от первого
✓Кабинет сотрудника делается в первом спринте разработки, а не последним
✓Каждый этап заканчивается работающим сценарием, а не набором экранов
✓Скоуп по ферме закладывается сразу, даже пока ферма одна
✓Всё, что можно решить настройкой, не решается релизом
18 · Границы MVP
Что не входит в первую версию
×
Модули грядок и животных — Phase II
×
Нативные приложения в App Store и Google Play
×
Полноценная 3D-ферма и цифровой двойник
×
Live-камеры, датчики и IoT-контур
×
Доставка с интеграцией СДЭК и Почты
×
Бронирование и оплата посещений, экскурсий, глэмпинга и ресторана
×
Реферальная программа и расширенная геймификация
×
Выплаты фермам-партнёрам и маркетплейс-схема
×
AI-ассистент фермера и компьютерное зрение
×
Мультиязычная версия
18.2 · Зависимости от заказчика
Что ферма предоставляет до старта или в первый месяц
📌
Перечень и нумерация реальных объектов: сколько ульев, деревьев по культурам, зон
📌
План территории и фотоматериалы для иллюстрированной карты
📌
Юридическая модель участия и форма договора — со стороны юриста фермы
📌
Политика на случай гибели объекта: замена, продление или возврат
📌
Реквизиты, онлайн-касса и договор с эквайрингом
📌
Назначенные ответственные сотрудники по зонам и их готовность снимать еженедельно
📌
Решение по логистике продукции: только самовывоз или сразу доставка
📌
Ответственный за проект со стороны фермы — 3–5 часов в неделю
19 · Разбор технического задания
Восемь мест, требующих решения до старта
Техническое задание проработано заметно глубже среднего — особенно п. 30 и 32. Ниже собраны места, где формулировки расходятся между собой или оставляют пробел, и наше решение по каждому.
01
Масштаб против бюджета
П. 26 открывается словами «не требуется создавать огромный дорогостоящий продукт», после чего перечисляет 19 модулей, а п. 25 добавляет мультитенантность и п. 31 — девять артефактов Discovery.
Решение: Три сценария объёма вместо одной цифры. Явный перечень того, что выносится за MVP, и оценка последствий каждого сокращения.
02
Мобильное приложение отсутствует в MVP, но есть в смете
В составе MVP (п. 26) приложения нет. В структуре сметы (п. 31) «мобильное приложение» стоит отдельной строкой.
Решение: MVP — веб-приложение с установкой на домашний экран и уведомлениями в Telegram. Нативные приложения — Phase II отдельной сметой.
03
Мультиферма описана как одно требование, а это три продукта
П. 25 объединяет общий бренд, white-label и маркетплейс с выплатами. Разница в стоимости между крайними вариантами — около двух раз.
Решение: Разделили на три уровня. В MVP реализуем первый, фундамент закладываем под все три, эквайринг сразу берём со сплитом.
04
CAC и LTV нельзя собрать внутри платформы
П. 24 требует стоимость привлечения и LTV наравне с внутренними метриками, но CAC формируется в рекламных кабинетах.
Решение: Внутри — событийный слой и выгрузки. Снаружи — Метрика, CRM и готовый BI. Самописных дашбордов в MVP нет.
05
Кабинет сотрудника недооценён по приоритету
Модуль указан 17-м из 19 в составе MVP, хотя именно он производит весь контент продукта.
Решение: Поднят на критический путь и делается в первом спринте. Заложен офлайн-режим: на пасеке и в саду связи может не быть.
06
Карта со всеми объектами нереализуема
П. 4 предполагает отображение объектов на карте. При сотнях ульев такая карта нечитаема и дорога в разработке.
Решение: Карта зон, внутри зоны — список и сетка объектов. Иллюстрация и позиции разделены, переход к 3D не требует переноса данных.
07
Модель участия по животным не определена
П. 10 верно ставит вопрос и оставляет его открытым, но от ответа зависит структура тарифов, платежей и оферты.
Решение: Предлагаем патронаж или спонсорство как услугу, а не куплю-продажу животного. Требует подтверждения юристом фермы.
08
Четырёх обязательных элементов нет в составе MVP
Отсутствуют публичная витрина для рекламного трафика, политика на случай гибели объекта, логистика продукции и юридический пакет.
Решение: Витрину включаем в объём работ. Политику, логистику и документы фиксируем как зависимости от заказчика с нашим сопровождением.
20 · Открытые вопросы
10 решений, которые нужны до старта
Мы спрашиваем только то, что реально меняет архитектуру, стоимость или график. Всё остальное решено в этом документе.
01
Сколько объектов планируется передать участникам в первый сезон и в каком диапазоне цены участия?
Влияет на: Нагрузка, админка, массовый импорт, юнит-экономика
02
Сколько сейчас реально ульев, деревьев по культурам и зон? Есть ли действующий учёт объектов?
Влияет на: Объём импорта, структура зон, состав карты
03
Есть ли мобильный интернет непосредственно на пасеке и в саду?
Влияет на: Офлайн-режим кабинета сотрудника
04
Сколько сотрудников будет публиковать отчёты и готовы ли они снимать еженедельно?
Влияет на: Контент-конвейер, роли и права, реалистичность частоты событий
05
Как юридически оформляется участие: оферта на обслуживание, патронаж, подписка?
Влияет на: Тарифы, платежи, оферта, модуль животных
06
Что получает участник, если объект погиб: замену, продление или частичный возврат?
Влияет на: Жизненный цикл объекта, компенсации, тексты оферты
07
Есть ли договорённости с фермой №2 и в каком горизонте она подключается?
Влияет на: Глубина мультифермы в MVP, выбор платёжной схемы
08
Наличие приложения в сторах — принципиальное требование или подходит веб-приложение?
Влияет на: Стоимость и срок первой версии
09
В первой версии только самовывоз на ферме или сразу доставка?
Влияет на: Модуль заказов, интеграции, операционная нагрузка фермы
10
Что уже работает: сайт, интернет-магазин, CRM, касса, учёт в 1С или МойСклад?
Влияет на: Интеграции вместо разработки с нуля
21 · Вопросы без ответа
Ответы на эти вопросы могут повлиять на весь проект
Ниже — те же десять пунктов в исходной формулировке, как мы отправили их заказчику до подготовки документа. Ответа мы не получили, поэтому оставляем список здесь целиком.
Пока эти вопросы открыты, часть решений принята нами по умолчанию — они описаны выше и помечены как допущения. Ответ на любой из десяти пунктов может изменить архитектуру, состав MVP, смету и график. Разбираем их на Такте 0 — это первое, чем мы займёмся.
01
Проверка гипотезы: что для вас будет означать «сработало»?
Сколько объектов вы рассчитываете передать пользователям в первый сезон — 10, 100, 1000? И в каком диапазоне цены участия: 5, 15, 50 тыс. ₽ за улей или дерево в год? От этого зависит не дизайн, а вся архитектура: система на 100 объектов и на 10 000 — это разные решения по нагрузке, админке и логистике.
Без ответа
02
Физический масштаб фермы сегодня
Сколько сейчас реально ульев, деревьев по культурам, зон? Сколько из них вы готовы вывести в продажу в первый сезон? Есть ли уже нумерация и учёт объектов — в таблицах, в 1С, на бумаге? Если объектов сотни, в админке нужен массовый импорт, а не ручное заведение — это отдельная функция.
Без ответа
03
Кто и как будет снимать контент
Это, по нашему опыту, главный риск таких платформ: продукт живёт ровно до тех пор, пока пользователь получает свежие фото. Вопросы предметные:
- Сколько сотрудников будет публиковать отчёты — пчеловод, садовник, сколько человек всего?
- Готовы ли они снимать еженедельно и кто за это отвечает?
- Какая связь на территории — есть ли мобильный интернет непосредственно на пасеке и в саду?
Последнее принципиально: если в поле связи нет, приложение сотрудника должно уметь снимать офлайн и досылать материалы автоматически. Это делается, но должно быть заложено сразу.
Без ответа
04
Юридическая модель участия
Как оформляется отношение пользователя с объектом — договор оферты на обслуживание, патронаж, подписка на услугу? Отдельно по животным: продажа козы физлицу — не самый удобный вариант, обычно это оформляют как спонсорство. Есть ли у вас юрист, который это уже прорабатывал? От ответа зависит структура тарифов и схема платежей — переделывать её после запуска на живых подписчиках дорого и болезненно.
Без ответа
05
Что происходит, если объект погиб
Улей не пережил зиму, дерево засохло, урожай не удался. Что получает пользователь — замену объекта, продление на сезон, частичный возврат? Это не техническая деталь: без этого правила нельзя написать оферту и нельзя спроектировать жизненный цикл объекта в системе.
Без ответа
06
Несколько ферм — насколько это реальный горизонт?
Пункт 25 мы считаем самым важным в ТЗ, но под ним скрываются три разных продукта:
- Общий бренд: один сайт, объекты разных ферм в одном кабинете.
- White-label: у каждой фермы свой домен и оформление.
- Маркетплейс: фермы-партнёры получают выплаты, платформа берёт комиссию.
Разница в стоимости примерно вдвое. Есть ли уже конкретные договорённости с фермой №2 и в каком горизонте она подключается — год, три? Мы в любом случае заложим фундамент под мультиферму, вопрос в том, что делаем сейчас, а что оставляем на потом.
Без ответа
07
Мобильное приложение: в сторах или в браузере?
В составе MVP (п. 26) приложения нет, а в структуре сметы (п. 31) оно есть. Мы рекомендуем на первом этапе веб-приложение, которое ставится на домашний экран и выглядит как нативное — это экономит существенную сумму и снимает модерацию в сторах. Отдельно предложим Telegram-бота как канал уведомлений: в России он работает заметно лучше пушей. Готовы ли вы к такому решению или наличие приложения в App Store и Google Play — принципиальное требование?
Без ответа
08
Что уже есть из работающего
Есть ли сейчас сайт, интернет-магазин, продажи мёда онлайн? В чём ведётся учёт продукции и остатков — 1С, МойСклад, Excel? Есть ли CRM и касса? Если часть инфраструктуры уже работает, дешевле интегрироваться, чем писать заново.
Без ответа
09
Продукция: как она физически доходит до человека
Кто фасует, кто клеит персональные этикетки, есть ли опыт отправок? В первой версии оставляем только самовывоз на ферме или сразу нужна доставка с интеграцией СДЭК и Почты? Это ощутимая разница в объёме работ и в вашей операционной нагрузке.
Без ответа
10
Сроки и сезон
К какой дате вы хотите начать продавать? Мы исходим из того, что осмысленное окно старта продаж — весна, к началу цветения, когда история «наблюдай за своим деревом» начинается с первого дня. Если ориентир такой, у нас комфортный график. Если запуск нужен раньше — скажите, предложим сокращённый сценарий.
Без ответа