Skip to content

Производственный цикл проектов и карта ролей вокруг него

Этот документ описывает полный производственный цикл DETai: как мысль превращается в проектное намерение, затем в работу, реализацию, релизную фиксацию и документационную обвязку.

Короткая формула цикла:

мысль/идея -> план проекта -> Epic Issue -> Work Package -> код / результат -> версия -> документационная обвязка -> новый смысл

Граница производственного цикла

Производственный цикл принадлежит U.L.I. и отвечает за создание и развитие проекта, а не за исследование рынка или управление коммерческими показателями продукта.

В технологическом контуре действует правило:

Один репозиторий соответствует одному проекту.

Проект может создавать внешнюю или внутреннюю ценность. Он может стать пользовательским продуктом, а может остаться инфраструктурой, внутренним инструментом, медиа-проектом или технической capability. В любом случае проект должен усиливать хотя бы один ресурс экосистемы.

До публичного выпуска разработка не обязана проходить customer discovery или заполнять Product Charter. Для начала движения достаточно инициативы участника и отсутствия противоречия миссии, ценностям и принципам DETai.

1. Project Intent

На первом этапе появляется мысль, наблюдение или возможность, которая постепенно оформляется в проектное намерение.

Здесь важно понять:

  • что именно должно измениться;
  • зачем это изменение нужно;
  • какой новый смысл или ресурс оно может дать экосистеме;
  • готова ли мысль стать проектом или пока должна остаться в пространстве наблюдений.

Если идея ещё не созрела, она фиксируется как импульс. Для этого в нашей системе есть место, оно называется "🧠 Еще мысль", это материал/хаб для будущего развития. Если из неё уже сформировался вектор, он может перейти в Epic Issue.

Смысловую методологию этого перехода описывает документ Методология проектного цикла DETai.

2. Work Model Planning

На втором этапе проектное намерение переводится в четкий план.

Здесь формируются:

  • Epic Issue как блок смысла и навигации;
  • Sub-Issue / Work Package как поставляемые фрагменты результата;
  • Acceptance Tasks как проверяемые результаты;
  • критерии завершения и связи с будущим PR.

Этот этап уже относится к Work Model. Производственный цикл только показывает место этапа в общей траектории, а конкретные правила структуры задаются связкой Модель работы и Work Model.

Как дополнительный связанный материал к этому этапу см. Совместное планирование человека и агента в Work Model Planning — документ о распределении high-level и low-level ролей между человеком и агентом.

3. Implementation

На третьем этапе Work Package выполняется.

Типичная форма выполнения:

Work Package -> branch -> PR -> проверка -> merge

На этом уровне Codex или другой исполнитель работает внутри заданного Epic Issue, выполняет Sub-Issue / Work Package / checklist, фиксирует важные решения и доводит результат до проверяемого состояния.

Этот этап также регулируется Work Model: именно там описаны роли Epic Issue, Work Package, Acceptance Tasks, Implementation Steps, PR и финальной проверки.

4. Release Fixation

Release Fixation отвечает за момент, когда результат работы перестаёт быть набором изменений и становится зафиксированным состоянием проекта, репозитория или документационной системы.

На этом этапе уточняется:

  • какая версия или состояние завершены;
  • какие PR, решения и документы входят в итог;
  • что должно быть отражено в changelog, release notes или release summary.

Дополнительно определяется тип достигнутого состояния:

  • внутренняя или предварительная версия проекта v0.x;
  • стабильная версия внутреннего проекта или capability;
  • публичный v1.0 проекта, готового перейти из Product Candidate в продукт;
  • новая публичная версия уже существующего продукта.

v1.0 фиксирует готовность проекта к публичной ответственности, но не делает продуктом внутренний технический проект автоматически. Для перехода в продукт одновременно нужны публичный доступ, ценностная значимость, владелец поддержки и будущие показатели наблюдения.

Этот этап описан отдельным стандартом Release Fixation Standard и не смешивается с Work Model.

5. Documentation Architecture

На пятом этапе результат цикла связывается с Knowledge Substrate и другими документальными слоями.

Здесь определяется:

  • какие документы нужно обновить;
  • какие новые документы нужно создать;
  • какие старые документы стали устаревшими;
  • какие статусы и версии должны измениться;
  • какие элементы должны перейти в ClickUp-лист «Новые версии документов».

Если релиз создаёт или обновляет продукт, Documentation Architecture также проверяет:

  • канонический продуктовый узел и его текущую версию;
  • ценностную значимость и два базовых GEO-вопроса;
  • статус и публичное описание на сайте;
  • SEO/GEO metadata и structured data страницы продукта;
  • ограничения, поддержку, аналитику и условия доступа.

На этом этапе производственный цикл не исправляет все представления самостоятельно. Он передаёт Management Layer сигнал о выпуске и перечень изменившихся канонических объектов. Management определяет затронутые домены: Product–Market подтверждает ценность, Brand & Communications и владельцы каналов обновляют публичные проекции, а Trust, Evidence и Legal подключаются по предмету изменения.

Изменившийся продуктовый смысл не считается синхронизированным, пока Management Layer не подтвердил, что связанные представления обновлены либо явно отмечены как неприменимые. Сквозное правило описано в карте источников истины.

Этот этап закрывает цикл: результат становится частью знания экосистемы и может породить новые мысли, наблюдения и будущие проектные намерения.

Распределение документов по этапам

Этап производственного цикла Основной вопрос Документ / связка
1. Project Intent Как мысль становится проектным намерением? Методология проектного цикла DETai
2. Work Model Planning Как намерение разложить на структуру работы? Модель работы и Work Model
3. Implementation Как выполнить Work Package через branch, PR и проверку? Work Model, Epic Issue Contract, Sub-Issue (Work Package) Contract
4. Release Fixation Как зафиксировать достигнутое состояние? Release Fixation Standard, ♻️ Процесс версионности в U.L.I.
5. Documentation Architecture Как результат становится частью Knowledge Substrate? Versioning Standard, ♻️ Процесс версионности, Политика metadata документов

Связь с продуктовым циклом

Производственный и продуктовый циклы идут параллельно и соединяются в точках публичного релиза.

Состояние U.L.I. / производственный цикл Product–Market / продуктовый цикл
Мысль и ранняя инициатива Даёт свободно развить идею Не обязан подключаться
Проект и v0.x Планирует, реализует и фиксирует версии Может консультировать по запросу, но не создаёт обязательный gate
Подготовка публичного v1.0 Готовит стабильный релиз, передаёт Management сигнал об изменении и готовит deployment Совместно с владельцем Product Candidate формулирует ценностную значимость, аудиторию, доступ и показатели
Публичный продукт Поддерживает production-состояние Наблюдает использование, ресурсный вклад, доход и обратную связь
Следующая версия Развивает проект в новом dev-цикле Передаёт наблюдения и проверяет, изменилась ли ценность продукта

В проектах с ветками production и dev публичная версия остаётся в production-контуре, пока следующая версия развивается в dev. После Release Fixation следующего major-релиза Platform DETai обновляет доставляемый продукт; Product–Market подтверждает ценность и показатели; Brand & Communications и владельцы каналов обновляют публичные представления; Management Layer координирует и закрывает эту эстафету.

Подробная продуктовая сторона интерфейса описана в модели продуктового объекта, стандарте ценностного предложения и рыночном и портфельном цикле. Явная последовательность передачи ответственности дана в интерфейсе производственного и продуктового циклов.

Роли и skills

Производственный цикл может поддерживаться разными ролями и Codex skills.

На уровне Project Intent skill может выполнять роль фасилитатора и сверять идею с тем, какой ресурс эта идея может принести и в каком из эшелонов он может быть будущий проект.

На уровне Work Model Planning и Implementation ключевым становится агент, который умеет работать внутри Epic Issue / Work Package, удерживать scope, выполнять checklist и готовить PR.

Отдельную логику совместной planning-коммуникации между человеком и агентом раскрывает документ Совместное планирование человека и агента в Work Model Planning.

Граница документа

Этот документ отвечает за карту цикла и распределение ответственности между этапами.

Он не должен подробно описывать:

  • внутреннюю механику Acceptance Tasks и PR;
  • правила повышения версий документов;
  • конкретный формат release notes;
  • политику metadata;
  • правила публикации Knowledge Substrate.

Эти темы должны жить в соответствующих стандартах и процессных документах, а производственный цикл должен связывать их в одну понятную траекторию.

Связанные документы