Модель продуктового объекта¶
Product Object — каноническая запись о том, что конкретный проект или оформленная услуга стали доступным и поддерживаемым предложением для определённых пользователей. Модель не требует заранее превращать каждую мысль в рыночную гипотезу: она подключается, когда команда готовит публичный выпуск, сознательно оформляет внутренний продукт или уже наблюдает действующее предложение.
Действующая проектная модель¶
В технологическом контуре DETai действует простое операционное правило:
Один репозиторий соответствует одному проекту.
Проект — самостоятельная единица создания и развития результата с определённой целью, границами ответственности и жизненным циклом. Он может создавать внешнее пользовательское решение, контентный результат, внутренний инструмент или инфраструктурную систему. Проект не обязан становиться продуктом, но должен создавать или увеличивать хотя бы один ресурс экосистемы: финансовый, командный, технологический, ресурс узнаваемости или аналитический.
Репозиторий сохраняет идентичность проекта до и после публичного выпуска. Если проект становится продуктом, он не перестаёт быть проектом: команда продолжает его развитие в следующих производственных циклах и выпускает новые версии.
Различение состояний¶
- Мысль / Idea — свободное наблюдение или замысел. Для неё не требуется Product Charter, market analysis или формальная проверка. Если мысль принимается в работу экосистемы, достаточно не противоречить её миссии, ценностям и принципам.
- Initiative — мысль, получившая самостоятельное движение по инициативе участника, но ещё не выделенная в отдельный проект.
- Project — самостоятельная единица создания результата. В технологическом контуре проект получает собственный репозиторий и рабочее пространство в task-системе. Версии
v0.xмогут оставаться внутренними или предварительными. - Product Candidate — проект, который готовится к публичному
v1.0и поэтому должен получить явно сформулированную пользовательскую ценность, способ доступа, границы ответственности и будущие показатели наблюдения. - Product — доступное и поддерживаемое состояние проекта или услуги, имеющее определённых пользователей, ценностную значимость, способ получения результата и наблюдаемые показатели. Для внешнего репозиторного технологического проекта базовой точкой такого перехода является публичный релиз
v1.0. - Release — зафиксированная версия проекта или продукта. Релиз обновляет доставляемое состояние, но не создаёт новый проект автоматически.
v1.0 является необходимым техническим признаком зрелости репозиторного продукта, но не превращает во внешний продукт любой стабильный проект. Внутренняя инфраструктура может иметь v1.0 и оставаться техническим проектом или capability, если она не предлагается самостоятельной аудитории.
Каждый выпущенный продукт DETai получает собственную публичную страницу на сайте DETai. Она понятным языком фиксирует аудиторию, ценностную значимость, основные сценарии использования, способ доступа, границы и текущее состояние продукта. Канонический узел продукта в MK Docs связывает это публичное представление с версией, ответственными и документацией. Техническое README проекта не заменяет ни одно из этих описаний.
Для услуг, образовательных программ и других предложений без собственного репозитория эквивалентом v1.0 является явно зафиксированный публичный запуск с владельцем, условиями доступа и ответственностью за поддержку.
Переход проекта в продукт¶
Проект становится продуктом, когда одновременно:
- зафиксирована его ценностная значимость для определённой аудитории;
- проект соответствует миссии, ценностям и принципам DETai;
- он создаёт или усиливает обозначенный ресурс экосистемы;
- существует реально работающий способ получить результат: публичный для внешнего продукта или явно ограниченный определённой аудиторией для сознательно оформленного внутреннего продукта;
- репозиторный проект выпустил стабильную версию
v1.0или услуга прошла эквивалентную фиксацию запуска; - определены владелец поддержки и минимальные показатели, по которым можно наблюдать использование, ресурсный вклад и, когда применимо, доход;
- для чувствительных сценариев выполнены необходимые профессиональные, Trust, Legal и Evidence-условия.
Не требуется проводить отдельное customer discovery до начала каждого проекта. Источником инициативы может быть профессиональный опыт, наблюдение психологов, внутреннее знание школы или авторская интуиция. Исследование рынка остаётся доступным инструментом для специально выбранных гипотез, но не является обязательным входом в производство.
Внутренний инструмент становится внутренним продуктом только по явному решению: у него должна появиться определённая внутренняя аудитория, обещанный результат, поддержка и наблюдение. Без этого он остаётся техническим проектом или capability, даже если активно используется командой.
Минимальный паспорт продукта¶
К моменту признания проекта продуктом его канонический узел должен отвечать на восемь вопросов:
- Identity и owner — как называется продукт и кто отвечает за целостность и поддержку.
- Audience и ситуация — кому и в какой ситуации он помогает.
- Ценностная значимость — какой результат получает человек и почему этот способ имеет смысл.
- Доступ и доставка — где продукт доступен и как начать использование.
- Границы — для чего продукт предназначен, чего он не делает и какие ограничения нельзя скрывать.
- Ресурс экосистемы — какой ресурс усиливает продукт и к какому эшелону относится проект.
- Версия и состояние — какая версия публична, доступен ли продукт и что сейчас находится в разработке.
- Наблюдение и устойчивость — какие usage-, quality-, resource- и финансовые показатели отслеживаются после выпуска.
Технические, методические, Trust- и Evidence-документы раскрывают эти ответы настолько подробно, насколько требует реальный риск. Ранней мысли и внутреннему v0.x полный паспорт не нужен.
Параллельное развитие проекта и продукта¶
После публичного выпуска поддерживаемая версия остаётся в production-контуре, а новые идеи возвращаются в «🧠 Ещё мысль» и затем в новый производственный цикл проекта. В проектах, использующих ветки production и dev, первая отражает текущее публичное состояние, а вторая готовит следующую версию.
Следующий крупный релиз, например v2.0, одновременно:
- завершает очередной производственный цикл U.L.I.;
- обновляет публичное состояние продукта;
- запускает проверку ценностной значимости, показателей, документации и публичной страницы.
Пограничный пример: основной сайт¶
Основной сайт DETai является самостоятельным проектом и публичной поверхностью, создающей прежде всего ресурс узнаваемости. Это не делает его автоматически отдельным продуктом.
Публичность, трафик или появление рекламного дохода сами по себе не меняют тип объекта. Если через сайт появится самостоятельное рекламное предложение с определённым покупателем, ценностью, условиями и метриками, Product Object может быть создан для этого предложения, а сайт останется каналом его доставки. Сам сайт станет продуктом только если DETai начнёт предлагать его как самостоятельную поддерживаемую ценность для собственной аудитории, а не просто использовать как витрину экосистемы.
Независимые оси описания¶
Чтобы не смешивать разные свойства, проект или продукт описывается по нескольким независимым осям:
| Ось | На какой вопрос отвечает |
|---|---|
| Owning system | Где находится ответственность и канонический узел? |
| Отношение к методу | Универсальная психологическая или DET-специфическая зависимость? |
| Форма доставки | Цифровой инструмент, медиа-продукт, программа, услуга или capability? |
| Пользовательская функция | Образование, публикация, саморефлексия, диагностика, терапия или внутренняя работа? |
| Эшелон и ресурс | Какую роль проект играет и какой ресурс возвращает экосистеме? |
| Состояние | Мысль, инициатива, проект, Product Candidate, продукт или завершённый/приостановленный объект? |
Цифровая форма не исключает образовательную функцию, а принадлежность к универсальному контуру не означает, что сам продукт является инфраструктурой.
Связи¶
Product Object связывает проект, репозиторий, релизы, публичную страницу, показатели, claims, evidence, риски и ответственных вокруг конкретного предложения. Правила синхронизации этих представлений определены в модели документации продукта.