Путешествие продуктового инкремента через IT
Контекст модели
Целевая система, ради которой работает платформа: состоявшаяся пара работодатель - работник.
Наша система: социотехническая платформа для рынка труда. Она не производит целевую систему в одиночку, а участвует в ее создании вместе с другими создателями: HR клиентов-работодателей, государством в разных ролях, партнерами, подрядчиками, конкурентами, агрегаторами и другими участниками рынка.
Предприятие выпускает систему-инструмент, которая эксплуатируется ради получения целевой системы. Продуктовые изменения платформы создают условия и повышают вероятность образования состоявшейся пары работодатель - работник.
Объект путешествия в этой модели: продуктовое изменение / продуктовый инкремент / новая функциональность.
Граница рассмотрения: прохождение этого объекта через подразделение IT.
Карточка путешествия инкремента
Памятка-шаблон для фиксации границ преобразования и минимальных полей ведения конкретного инкремента.
ProductIncrementJourneyCard:
transformationCore:
transformedEntityOrStructure: ProductIncrement
boundedContext: IT-подразделение
initialCondition: до признания инкремента работающим изменением платформы
postStateConditionOrDelta: работающее и наблюдаемое изменение платформы
transformationRelation: прохождение через IT-путешествие
admissibilityOrBoundaryCondition: связь с целевой системой и готовность к управляемому выпуску
incrementFields:
targetSystemRef: состоявшаяся пара работодатель-работник
instrumentSystemRef: социотехническая платформа рынка труда
changeIntent: какой барьер или возможность в образовании целевой системы затрагиваем
affectedActors: работодатель, работник, HR, support, partner, regulator, aggregator
affectedPlatformParts: UI, matching, profile, vacancy, messaging, verification, analytics, integrations
expectedEffect: какой механизм повышает вероятность целевой системы
acceptanceCriteria: что должно быть истинно для выпуска
riskRefs: legal, privacy, fairness, fraud, reliability, support load
workPlanRef: задачи и владельцы IT
evidenceRefs: тесты, ревью, метрики, исследования
releaseRef: решение о выпуске, фиче-флаг, rollout, rollback
telemetryRef: как узнаем эффект после эксплуатации
validationLevels:
itLevel: изменение корректно спроектировано, реализовано, проверено, выпущено и сопровождаемо
sociotechnicalLevel: изменение повышает вероятность образования пары работодатель-работник или снижает препятствия к ней
Состояния, работы, события и свидетельства
Граничные события жизненного цикла объекта отмечены в той же таблице: ProductIncrementExistenceStarted - начало существования инкремента как объекта управления предприятия; ProductIncrementOperationStarted - начало эксплуатации инкремента как части платформы. Начало эксплуатации не всегда совпадает с техническим деплоем: если изменение закрыто фиче-флагом и не участвует в реальных сценариях, эксплуатация еще не началась.
Событие перехода фиксирует смену состояния объекта; свидетельства и артефакты показывают, по чему это состояние признается достигнутым.
Легенда колонок:
| Колонка | Смысл |
|---|---|
Предыдущее состояние |
состояние объекта до выполнения работы перехода |
Работа перехода |
конкретная работа, которая преобразует объект |
Метод выполнения |
повторяемый способ, по которому выполняется работа перехода |
Владелец перехода |
роль, отвечающая за доведение объекта до следующего состояния |
Gate / решение |
управленческий допуск, решение или явное отсутствие gate |
Следующее состояние |
состояние объекта после выполнения работы перехода |
Что изменилось в объекте |
новая определенность, появившаяся в объекте |
Событие перехода |
факт смены состояния объекта |
Свидетельства / артефакты |
чем подтверждается или фиксируется достижение состояния |
| Предыдущее состояние | Работа перехода | Метод выполнения | Владелец перехода | Gate / решение | Следующее состояние | Что изменилось в объекте | Событие перехода | Свидетельства / артефакты |
|---|---|---|---|---|---|---|---|---|
None / ExternalSignal |
Прием и первичная классификация сигнала | ChangeIntakeMethod |
Product owner | intake decision | RawChangeCandidate |
Сигнал принят как кандидат на продуктовое изменение | ProductIncrementExistenceStarted / ChangeCandidateRegistered |
запись в backlog / intake, источник сигнала, первичная классификация |
RawChangeCandidate |
Формулирование продуктовой проблемы | ProblemFramingMethod |
Product owner | problem framing accepted | FramedProblem |
Запрос связан с целевой системой: какой барьер мешает образованию пары работодатель - работник |
ProblemFramed |
problem statement, целевая метрика, границы, затронутые пользователи |
FramedProblem |
Поиск и оформление варианта решения | ProductDiscoveryMethod |
Product owner | solution option selected | ShapedIncrement |
Появился вариант решения: функциональность, UX, данные, правила, API или операционные изменения | SolutionShaped |
solution outline, acceptance criteria, UX prototype, review note |
ShapedIncrement |
Архитектурная проработка и допуск | ArchitectureDesignReviewMethod |
Architect / tech lead | architecture admission | ArchitecturallyAdmitted |
Изменение согласовано с архитектурой платформы: модули, данные, интеграции, безопасность, масштаб | ArchitectureAdmitted |
design notes, ADR, affected components, risk list |
ArchitecturallyAdmitted |
Планирование поставки | DeliveryPlanningMethod |
Tech lead | delivery scope accepted | PlannedWorkPackage |
Изменение превращено в план работ | DeliveryPlanned |
work plan, задачи, владельцы, зависимости, оценка, release scope |
PlannedWorkPackage |
Инженерная реализация | FeatureImplementationMethod |
Tech lead | no separate gate | ImplementedIncrement |
Код, схемы, конфиги, миграции, фиче-флаги или иные инженерные изменения созданы | IncrementImplemented |
pull requests, commits, build artifacts, migration scripts |
ImplementedIncrement |
Интеграционная проверка и верификация | VerificationMethod |
QA / tech lead | verification accepted | VerifiedIncrement |
Проверена пригодность изменения и отсутствие недопустимых регрессий | IncrementVerified |
test evidence, code review approvals, security/privacy checks, performance checks |
VerifiedIncrement |
Юридическое согласование | LegalAdmittanceMethod |
Legal counsel / compliance specialist | legal admission | LegallyAdmittedIncrement |
Юридические ограничения, регуляторные обязательства, договорные последствия и требования к персональным данным согласованы для заявленного scope | LegalAdmittanceAccepted |
legal review note, privacy assessment, terms/policy update refs, regulator or contract impact note, unresolved legal risk disposition |
LegallyAdmittedIncrement |
Принятие решения о выпуске | ReleaseDecisionMethod |
Product owner / tech lead | release decision | ReleaseReadyIncrement |
Изменение допущено к выпуску | ReleaseReadinessAccepted |
release decision, rollout plan, rollback plan, support note |
ReleaseReadyIncrement |
Развертывание и начало эксплуатации | DeploymentMethod |
DevOps / tech lead | launch gate | OperationalIncrement |
Изменение работает в платформе | ProductIncrementOperationStarted / IncrementDeployed |
production release record, feature flag state, deployment log, feature flag opened or traffic exposure record, monitoring baseline |
OperationalIncrement |
Эксплуатационное наблюдение и возврат обучения | OperateAndLearnMethod |
Product owner / analyst | learning decision | LearningIncrement |
Появились наблюдения о работе изменения и его связи с продуктовыми эффектами | OperationalEffectObserved |
telemetry, support feedback, analytics report, A/B or cohort result, decision to keep/extend/fix/rollback |
Общая структура путешествия
flowchart LR
A["None / ExternalSignal"] -->|прием сигнала| B["RawChangeCandidate"]
B -->|формулирование проблемы| C["FramedProblem"]
C -->|поиск решения| D["ShapedIncrement"]
D -->|архитектурный допуск| E["ArchitecturallyAdmitted"]
E -->|планирование поставки| F["PlannedWorkPackage"]
F -->|инженерная реализация| G["ImplementedIncrement"]
G -->|верификация| H["VerifiedIncrement"]
H -->|юридическое согласование| I["LegallyAdmittedIncrement"]
I -->|решение о выпуске| J["ReleaseReadyIncrement"]
J -->|начало эксплуатации| K["OperationalIncrement"]
K -->|наблюдение и обучение| L["LearningIncrement"]
L -->|уточнение проблемы или следующего инкремента| C
Реестр методов
Легенда: methodRef - повторяемый способ выполнения работы перехода; methodDescriptionRef - источник, где этот способ описан.
| methodRef | Метод | methodDescriptionRef |
|---|---|---|
ChangeIntakeMethod |
Прием и первичная классификация сигнала | intake policy, backlog workflow |
ProblemFramingMethod |
Формулирование продуктовой проблемы относительно целевой системы | problem framing template, metrics guide |
ProductDiscoveryMethod |
Поиск и оформление варианта решения | discovery playbook, UX prototyping guide |
ArchitectureDesignReviewMethod |
Архитектурная проработка и допуск | architecture review checklist, ADR template |
DeliveryPlanningMethod |
Превращение решения в план поставки | delivery planning workflow, sprint/release planning guide |
FeatureImplementationMethod |
Инженерная реализация изменения | engineering guidelines, coding standards, branch/PR workflow |
VerificationMethod |
Проверка пригодности изменения | definition of done, test strategy, security/privacy checklist |
LegalAdmittanceMethod |
Юридическое согласование изменения | legal review checklist, privacy assessment procedure, contract/policy update process |
ReleaseDecisionMethod |
Принятие решения о выпуске | release checklist, launch gate policy |
DeploymentMethod |
Развертывание изменения в продуктивной среде | deployment playbook, incident response runbook |
OperateAndLearnMethod |
Эксплуатационное наблюдение и возврат обучения в продуктовый контур | telemetry plan, analytics protocol, support feedback workflow |
Точки управленческого контроля
| Точка контроля | Что проверяется | Если не выполнено |
|---|---|---|
architecture admission |
изменение допустимо для архитектуры платформы | не переходить к планированию поставки без ADR, design note или явного risk acceptance |
verification accepted |
проверки пройдены, дефекты классифицированы | не переходить к юридическому согласованию как к финальному допуску выпуска |
legal admission |
правовые основания, договорные и регуляторные последствия согласованы | не переходить к release decision без legal approval или явного risk acceptance |
release decision |
выпуск разрешен, rollout и rollback определены | не начинать развертывание |
launch gate |
изменение реально участвует в продуктивных сценариях | не считать OperationalIncrement достигнутым при закрытом фиче-флаге |
learning decision |
получены данные эффекта и принято решение о дальнейшем действии | не закрывать инкремент без решения оставить, расширить, исправить или откатить |
IT-роли в путешествии инкремента
| Роль | Что делает с инкрементом |
|---|---|
| Product owner / product manager | Связывает изменение с целевой системой и бизнес-эффектом |
| Business / system analyst | Уточняет сценарии, ограничения и правила предметной области |
| UX / product designer | Преобразует задачу в пользовательские взаимодействия |
| Architect / tech lead | Проверяет архитектурную допустимость и последствия |
| Developers | Производят изменение в коде, данных и интеграциях |
| QA / test engineer | Проверяет соответствие критериям и регрессии |
| DevOps / platform engineer | Обеспечивает сборку, выпуск, наблюдаемость и откат |
| Security / privacy engineer | Проверяет доверие, персональные данные и доступы |
| Legal counsel / compliance specialist | Согласует правовые основания, договорные последствия, регуляторные ограничения, тексты пользовательских условий и допустимость обработки данных |
| Data / ML engineer, если применимо | Меняет модели, признаки, ранжирование и аналитику |
| Support liaison | Готовит сопровождение и обратную связь после выпуска |