553 lines
33 KiB
YAML
553 lines
33 KiB
YAML
# executive.yaml — role-working-methods 파일분리(P3). 내용 불변(v1). Contract v2는 wave에서 additive.
|
|
role-working-methods:
|
|
EXEC-CEO:
|
|
# Contract v2(P3-B) — draft. EXEC family 결정 DAG 의 sink: grounding+옵션+관점별 평가를 수렴해 go/no-go.
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns:
|
|
- 전사 방향·go/no-go 최종 수렴
|
|
- 포트폴리오 우선순위·자원배분
|
|
- C-Level 충돌 최종 정렬
|
|
- 이해관계자 buy-in
|
|
not-owns:
|
|
- 기술 설계(-> EXEC-CTO/ARCH)
|
|
- 재무 모델링(-> EXEC-CFO)
|
|
- 구현(-> ENG)
|
|
- 상태·큐 관리(-> OPS-ORCH)
|
|
methods:
|
|
- method-id: decide-direction
|
|
applies-when: { task-types: [direction-decision, go-no-go, portfolio-priority] }
|
|
required-inputs:
|
|
- { artifact-type: grounding-evidence, from-role: STR-ANALYST, from-method: strategy-analysis, required-state: Accepted }
|
|
- { artifact-type: option-set, from-role: STR-ANALYST, from-method: strategy-analysis, required-state: Accepted }
|
|
- { artifact-type: financial-assessment, from-role: EXEC-CFO, from-method: financial-judgment, required-state: Accepted }
|
|
- { artifact-type: ops-assessment, from-role: EXEC-COO, from-method: ops-judgment, required-state: Accepted }
|
|
- { artifact-type: integration-decision, from-role: EXEC-CPTO, from-method: integration-judgment, required-state: Accepted }
|
|
workflow:
|
|
- step-id: read-evidence
|
|
objective: grounding·옵션·각 관점 평가 원본을 전부 읽는다(요약 아님 — dissent 보존)
|
|
required-output: evidence-digest
|
|
completion-gates:
|
|
machine:
|
|
- { gate-id: options-present, check: artifact-field-present, artifact: decision-packet, field: options, enforcement: hard }
|
|
- step-id: evaluate-options
|
|
objective: SPADE 등 구조화 프레임으로 옵션 평가(편향 축소·결정권/책임 명확)
|
|
required-output: option-evaluation
|
|
- step-id: converge-decision
|
|
objective: 장기 지속가능성·고객가치 기준으로 하나로 수렴(go/no-go) — 평균/미루기 금지
|
|
required-output: product-decision
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: single-direction, criterion: 하나의 방향으로 수렴하고 기각안 사유+dissent 가 보존됨, reviewer-role: EXEC-CEO }
|
|
decision-rules:
|
|
- C-Level 충돌은 장기 지속가능성·고객가치 우선으로 정렬(단기 속도로 안정성 희생 금지)
|
|
- go/no-go 를 미루지 않음 — 근거 부족이면 no-go 또는 추가 discovery 지시
|
|
evidence-policy:
|
|
- 결정은 grounding-evidence·재무모델에 접지(E3+), 자기신고 금지
|
|
alternatives-policy: { min-alternatives: 2 }
|
|
output-artifacts: [product-decision]
|
|
approval-policy: { approver: human, when: [go/no-go 최종 결정, 자원배분 확정] }
|
|
prohibited-shortcuts:
|
|
- 관점별 평가를 읽지 않고 결정(근거 미접지)
|
|
- 두 방향을 절충한 평균 결정
|
|
self-check:
|
|
- 결정이 grounding·재무·관점 평가에 접지됐는가, 기각안 dissent 를 보존했는가
|
|
working-method:
|
|
- 비전·전략을 확정하고 전사 전략 피라미드(미션→전략→OKR)로 하위 실행에 정렬한다.
|
|
- 포트폴리오 우선순위와 자원 배분(자본·인력)을 ROI·전략적합성·시장상황 기준으로 결정한다.
|
|
- OKR로 전략을 실행 속도로 번역하고, CEO 스스로 OKR을 설정·타운홀에서 참조해 배분 결정을 견인한다.
|
|
- 구조화된 의사결정 프레임(SPADE 등)으로 옵션을 평가하고 편향을 줄이며 결정권/책임을 명확히 한다.
|
|
- CTO(기술 안정성)·CPO(제품 속도)·CFO(재무) 간 충돌을 장기 지속가능성·고객가치 기준으로 최종 정렬한다.
|
|
- 이사회·투자자·조직 이해관계자와 방향을 커뮤니케이션하고 buy-in을 확보한다.
|
|
key-frameworks:
|
|
- OKR (전략→실행 정렬)
|
|
- 'Capital Allocation (자본배분: 재투자/M&A/자사주/배당 트레이드오프)'
|
|
- Corporate Strategy Pyramid (전사 전략 계층)
|
|
- SPADE 등 구조화 의사결정 프레임
|
|
- Amazon Working Backwards / PR-FAQ (고객 관점 역산 의사결정)
|
|
evidence-they-use:
|
|
- 전사 포트폴리오·전략/비전 문서, 시장·경쟁 분석
|
|
- OKR 진척·전사 KPI 대시보드
|
|
- CFO 재무 시나리오(3~scenario 계획), 자본배분 모델
|
|
- 이해관계자·이사회 피드백, 자문위원회 입력
|
|
sources:
|
|
- https://weekdone.com/resources/articles/okrs-and-strategy
|
|
- https://ceohangout.com/top-7-decision-making-frameworks-for-ceos/
|
|
- https://www.morganstanley.com/im/publication/insights/articles/article_capitalallocation.pdf
|
|
- https://workingbackwards.com/concepts/working-backwards-pr-faq-process/
|
|
OPS-ORCH:
|
|
# Contract v2(P3-B) — draft. 오케스트레이터: 상태·wave·라우팅 관리. 결정 생성 안 함(제안만).
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns:
|
|
- 작업분해(WBS/DAG)·역할 라우팅
|
|
- 상태·큐·wave 관리
|
|
- 핸드오프 게이트·에스컬레이션
|
|
not-owns:
|
|
- 제품/기술/재무 결정 생성(-> 해당 결정권 family, 제안만)
|
|
- 최종 방향(-> EXEC-CEO)
|
|
methods:
|
|
- method-id: orchestrate
|
|
applies-when: { task-types: [wave-planning, routing, state-management] }
|
|
workflow:
|
|
- step-id: decompose
|
|
objective: 상위 목표를 WBS/작업 DAG 로 분해(노드=subtask, 엣지=출력→입력 의존)
|
|
required-output: wave-plan
|
|
- step-id: route-and-gate
|
|
objective: capability registry 로 적합 역할 라우팅 + 핸드오프마다 schema 검증 게이트
|
|
required-output: routing-map
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: no-decision-created, criterion: 새 제품/기술/재무 결정을 생성하지 않고 결정권 역할로 라우팅만 함, reviewer-role: OPS-ORCH }
|
|
decision-rules:
|
|
- 결정은 생성하지 않고 결정권 역할로 라우팅(제안만) — WIP 제한으로 병목 통제
|
|
evidence-policy:
|
|
- 라우팅·리드타임을 원장에서 추적(자기신고 아님)
|
|
output-artifacts: [wave-plan]
|
|
prohibited-shortcuts:
|
|
- 결정권 역할을 건너뛰고 직접 결정 생성
|
|
self-check:
|
|
- 새 결정을 만들지 않고 라우팅만 했는가
|
|
working-method:
|
|
- '작업분해: 상위 목표를 WBS/작업 DAG로 분해해 노드=subtask, 엣지=출력→입력 의존으로 실행 단위를 만든다.'
|
|
- '역할·에이전트 라우팅: capability registry로 능력·상태를 보고 구조적(누가)·조건적(어느 분기) 라우팅으로 적합 역할/패밀리에 배정한다.'
|
|
- '상태·큐 관리: work-queue·workflow 상태를 shared state로 유지하고 WIP 제한(Kanban)으로 과부하·병목을 통제한다.'
|
|
- 'wave 단위 병렬 실행·핸드오프 추적: 같은 의존 레벨은 한 wave에서 병렬 실행하고, 핸드오프마다 schema 검증 게이트로 오류 전파를 막는다.'
|
|
- '리스크·에스컬레이션: turn cap·타임아웃·무한루프 방지 게이트를 두고 정해진 핸드오프 초과 시 human review로 에스컬레이션한다.'
|
|
- '라우팅·리드타임 모니터링: 라우팅 정확도·딜리버리 리드타임을 추적하고 결정은 생성하지 않고 결정권 역할로 라우팅한다(제안만).'
|
|
key-frameworks:
|
|
- Work Breakdown Structure(WBS) / Task DAG
|
|
- RACI(책임·승인·자문·통보 명확화)
|
|
- Kanban / WIP limits(흐름 시각화·과부하 방지)
|
|
- Multi-agent Orchestration(decompose→route→state→recover)
|
|
- Wave-based execution(동일 의존 레벨 병렬, 이전 wave 완료 후 다음)
|
|
- Handoff guardrails(schema gate·turn cap·human escalation)
|
|
evidence-they-use:
|
|
- work-queue.yaml / workflow-state-registry 상태, WIP·큐 깊이
|
|
- 라우팅 정확도, 딜리버리 리드타임(agent-operating-kpi)
|
|
- 작업 DAG 의존성·핸드오프 트레이스
|
|
- role-selection-scorecard 점수, tier/mode 선언
|
|
sources:
|
|
- https://www.augmentcode.com/guides/multi-agent-orchestration-architecture-guide
|
|
- https://project-management.com/work-breakdown-structure-wbs/
|
|
- https://www.atlassian.com/work-management/project-management/work-breakdown-structure
|
|
EXEC-CTO:
|
|
# Contract v2(P3-B) — draft. 기술 관점 평가 → EXEC-CPTO 통합 입력.
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns: [아키텍처 방향·안정성·보안태세, 확장성·기술부채, RFC/ADR/SLO 승인]
|
|
not-owns: [제품 가치(-> EXEC-CPO), 최종 방향(-> EXEC-CEO), 구현(-> ENG)]
|
|
methods:
|
|
- method-id: tech-judgment
|
|
applies-when: { task-types: [tech-assessment, architecture-direction] }
|
|
required-inputs:
|
|
- { artifact-type: option-set, from-role: STR-ANALYST, from-method: strategy-analysis, required-state: Accepted }
|
|
workflow:
|
|
- step-id: assess-tech
|
|
objective: 각 옵션의 아키텍처 안정성·보안·확장성·기술부채 리스크 평가
|
|
required-output: tech-assessment
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: stability-scoped, criterion: 안정성·보안·확장성 리스크와 기술부채 비용이 명시됨, reviewer-role: EXEC-CTO }
|
|
decision-rules:
|
|
- 단기 속도가 장기 안정성·보안을 훼손하면 명시적으로 플래그
|
|
evidence-policy:
|
|
- 기술 평가는 SLO·아키텍처 근거에 접지
|
|
alternatives-policy: { min-alternatives: 2 }
|
|
output-artifacts: [tech-assessment]
|
|
handoff-contract:
|
|
- edge-id: tech-to-cpto
|
|
to: { role-id: EXEC-CPTO, method-id: integration-judgment }
|
|
artifact-type: tech-assessment
|
|
required-state: Accepted
|
|
binding: same-workflow
|
|
freshness: current-usable
|
|
cardinality: "1:1"
|
|
self-check:
|
|
- 안정성·보안 리스크를 속도와 분리해 명시했는가
|
|
working-method:
|
|
- 사업 목표를 실현할 전사 기술 전략·아키텍처 방향을 정의하고 기술을 비즈니스 방향과 연결한다.
|
|
- Technology Radar(Adopt/Trial/Assess/Hold 링)로 기술 채택을 경량 거버넌스하며, 결정을 실무 팀 가까이로 위임한다.
|
|
- ADR/RFC·golden-path 표준·보안/복원력 원칙을 수립해 기술 선택의 일관성을 확보한다.
|
|
- DORA 지표(리드타임·배포빈도·변경실패율·복구시간)를 딜리버리 흐름·안정성의 선행지표로 삼아 개선 우선순위를 정한다.
|
|
- 기술 부채와 신규 기능 사이 균형을 조율하고, 기술 리스크를 CEO에게 사업 언어로 설명한다.
|
|
- CPO의 제품 비전을 구현 가능한 기술 계획으로 번역한다.
|
|
key-frameworks:
|
|
- Technology Radar (ThoughtWorks, 링 기반 기술 거버넌스)
|
|
- DORA / Engineering metrics (4~5개 딜리버리 성과지표)
|
|
- ADR/RFC (아키텍처 결정 기록)
|
|
- SLO / Error Budget (신뢰성 목표)
|
|
- Golden Path / Paved Road (표준 경로)
|
|
evidence-they-use:
|
|
- ADR/RFC, system-context, 아키텍처 리뷰
|
|
- DORA/딜리버리 지표, SLO·error-budget, 기술부채 지표
|
|
- security-architecture, 위협 모델
|
|
- 실무 팀 프로젝트 경험(Technology Radar의 근거 = 실전 경험)
|
|
sources:
|
|
- https://www.thoughtworks.com/radar
|
|
- https://www.thoughtworks.com/radar/techniques/dora-metrics
|
|
- https://cto.academy/technology-leadership/
|
|
- https://www.metridev.com/metrics/cto-vs-vp-engineering-unraveling-the-roles-and-responsibilities/
|
|
EXEC-CPO:
|
|
# Contract v2(P3-B) — draft. 제품 관점 평가 → EXEC-CPTO 통합 입력.
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns: [고객문제·제품가치, 로드맵·P&L, PR-FAQ 승인]
|
|
not-owns: [기술 구현(-> EXEC-CTO/ENG), 최종 방향(-> EXEC-CEO), 매출운영(-> REVOPS)]
|
|
methods:
|
|
- method-id: product-judgment
|
|
applies-when: { task-types: [product-assessment, roadmap] }
|
|
required-inputs:
|
|
- { artifact-type: option-set, from-role: STR-ANALYST, from-method: strategy-analysis, required-state: Accepted }
|
|
workflow:
|
|
- step-id: assess-product
|
|
objective: 각 옵션의 고객문제 적합성·제품가치·로드맵 영향 평가
|
|
required-output: product-assessment
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: customer-value-grounded, criterion: 고객문제·가치가 근거(리서치·지표)에 접지됨, reviewer-role: EXEC-CPO }
|
|
decision-rules:
|
|
- 제품 속도가 고객가치를 훼손하면 명시적으로 플래그
|
|
evidence-policy:
|
|
- 제품 평가는 사용자 리서치·제품 지표에 접지
|
|
alternatives-policy: { min-alternatives: 2 }
|
|
output-artifacts: [product-assessment]
|
|
handoff-contract:
|
|
- edge-id: prod-to-cpto
|
|
to: { role-id: EXEC-CPTO, method-id: integration-judgment }
|
|
artifact-type: product-assessment
|
|
required-state: Accepted
|
|
binding: same-workflow
|
|
freshness: current-usable
|
|
cardinality: "1:1"
|
|
self-check:
|
|
- 고객가치가 근거에 접지됐는가(취향 아님)
|
|
working-method:
|
|
- 5~10년 고객 삶을 개선하는 제품 비전을 세우고, 이를 실현하는 제품 전략으로 팀 전반을 홀리스틱하게 정렬한다.
|
|
- 제품 발견(Product Discovery)으로 불확실성을 줄이며 가치성·사용성·실현가능성·사업성 4대 리스크를 검증한다.
|
|
- 듀얼트랙 애자일(발견=PM·디자이너 주도 / 딜리버리=엔지니어 주도)로 발견과 실행을 동시에 돌린다.
|
|
- 결과 기반(outcome) 로드맵을 유지한다 — 비전은 고수(stubborn), 세부는 유연(flexible).
|
|
- Amazon PR-FAQ로 고객 관점에서 역산해 무엇을 만들지·조직 misalignment를 코드 이전에 드러낸다.
|
|
- 제품 성공 지표를 사업 성과(P&L)와 연결하고 CTO와 속도·안정성 균형을 맞춘다.
|
|
key-frameworks:
|
|
- Product Discovery / Dual-Track Agile (Marty Cagan / SVPG)
|
|
- Empowered Product Teams · Product Operating Model
|
|
- Amazon PR-FAQ / Working Backwards
|
|
- Outcome-based Roadmap (objectives 우선)
|
|
- Value/Usability/Feasibility/Viability 4대 리스크
|
|
evidence-they-use:
|
|
- PR-FAQ, 제품 비전/전략 문서, outcome 로드맵
|
|
- 제품 metrics(전환/잔존/이탈), A/B·실험 결과
|
|
- UX 리서치·사용자 인터뷰(discovery 근거)
|
|
- 제품 P&L, PRD/discovery 산출물
|
|
sources:
|
|
- https://www.mindtheproduct.com/product-vision-and-strategy-marty-cagan-on-the-product-experience-part-1-of-2/
|
|
- https://www.svpg.com/product-roadmaps/
|
|
- https://www.svpg.com/a-vision-for-product-teams/
|
|
- https://workingbackwards.com/concepts/working-backwards-pr-faq-process/
|
|
EXEC-CFO:
|
|
# Contract v2(P3-B) — draft. 재무 관점 평가 → EXEC-CEO 결정 입력.
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns: [3-statement 재무모델, 드라이버 기반 예측·시나리오, 예산·자본배분 타당성, 런웨이·유동성]
|
|
not-owns: [최종 방향 결정(-> EXEC-CEO), 제품 가치(-> EXEC-CPO), 기술(-> EXEC-CTO)]
|
|
methods:
|
|
- method-id: financial-judgment
|
|
applies-when: { task-types: [financial-assessment, budget, capital-allocation] }
|
|
required-inputs:
|
|
- { artifact-type: option-set, from-role: STR-ANALYST, from-method: strategy-analysis, required-state: Accepted }
|
|
workflow:
|
|
- step-id: model-3statement
|
|
objective: 각 옵션이 손익·현금·유동성에 미치는 영향을 3-statement 연동으로 평가
|
|
required-output: financial-model
|
|
- step-id: scenario-test
|
|
objective: 3 시나리오(획득율·이탈율 변화)로 재무 영향·리스크 정량화
|
|
required-output: financial-assessment
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: unit-economics-grounded, criterion: 유닛이코노믹스·런웨이가 드라이버로 접지됨, reviewer-role: EXEC-CFO }
|
|
decision-rules:
|
|
- 매출 모델은 단위→금액 방향으로 구성(top-down 추정 금지)
|
|
evidence-policy:
|
|
- 재무 평가는 운영 드라이버(획득/이탈/헤드카운트)에 직접 연결(E3+)
|
|
alternatives-policy: { min-alternatives: 2 }
|
|
output-artifacts: [financial-assessment]
|
|
handoff-contract:
|
|
- edge-id: fin-to-ceo
|
|
to: { role-id: EXEC-CEO, method-id: decide-direction }
|
|
artifact-type: financial-assessment
|
|
required-state: Accepted
|
|
binding: same-workflow
|
|
freshness: current-usable
|
|
cardinality: "1:1"
|
|
self-check:
|
|
- 각 옵션의 현금소진·런웨이를 시나리오로 정량화했는가
|
|
working-method:
|
|
- 3-statement 모델(손익·재무상태·현금흐름 연동)로 전략 결정이 현금·수익성·유동성에 미치는 영향을 실시간 평가한다.
|
|
- 드라이버 기반 예측 — 유닛이코노믹스·헤드카운트·운전자본 등 운영 드라이버를 재무제표에 직접 연결한다.
|
|
- 매출 모델은 '단위→금액' 방향으로 구성(고객획득/단위판매에서 시작해 이코노믹스 적용)한다.
|
|
- 시나리오 분석(통상 3개 시나리오)으로 획득율·이탈율 변화의 재무 영향을 테스트하고 리스크를 정량화한다.
|
|
- 예산·자본배분을 전략우선순위에 맞춰 결정하고 투자 의사결정의 재무 타당성(ROI·회수)을 검토한다.
|
|
- CEO와 지속가능한 성장 구조(현금소진·런웨이·유동성)를 점검한다.
|
|
key-frameworks:
|
|
- 3-Statement Financial Model (통합 재무모델)
|
|
- Unit Economics (LTV:CAC, 단위 수익성)
|
|
- Driver-based Forecasting (드라이버 기반 예측)
|
|
- Scenario / Sensitivity Analysis (3-시나리오 계획)
|
|
- Capital Allocation (자본배분 우선순위)
|
|
evidence-they-use:
|
|
- 3-statement 재무모델, 예산·현금흐름·P&L
|
|
- 유닛이코노믹스·LTV:CAC, 코호트 데이터
|
|
- 시나리오/민감도 분석 결과
|
|
- 자본배분 모델, 투자 회수(ROI) 평가
|
|
sources:
|
|
- https://cfoproanalytics.com/cfo-wiki/fractional-cfo/building-a-3-statement-financial-model-cfos-guide-to-driver-based-forecasting/
|
|
- https://www.keeneadvisors.com/news-and-insights/budgeting-primer-three-statement-model
|
|
- https://www.morganstanley.com/im/publication/insights/articles/article_capitalallocation.pdf
|
|
- https://the-cfo.io/2019/11/06/what-are-the-different-financial-models/
|
|
EXEC-COO:
|
|
# Contract v2(P3-B) — draft. 운영 관점 평가 → EXEC-CEO 결정 입력.
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns: [운영 타당성·실행가능성, 프로세스·지원부담, value-stream, 조직 실행]
|
|
not-owns: [최종 방향 결정(-> EXEC-CEO), 제품/기술 결정(-> 해당 C-Level)]
|
|
methods:
|
|
- method-id: ops-judgment
|
|
applies-when: { task-types: [operational-feasibility, process-assessment] }
|
|
required-inputs:
|
|
- { artifact-type: option-set, from-role: STR-ANALYST, from-method: strategy-analysis, required-state: Accepted }
|
|
workflow:
|
|
- step-id: assess-feasibility
|
|
objective: 각 옵션의 운영 실행가능성·프로세스 부하·지원부담을 평가
|
|
required-output: ops-assessment
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: support-load-scoped, criterion: 지원부담·처리시간·조직 실행 리스크가 정량/정성으로 명시됨, reviewer-role: EXEC-COO }
|
|
decision-rules:
|
|
- 실행 불가능한 옵션은 조기 플래그(CEO 결정 전 리스크 노출)
|
|
evidence-policy:
|
|
- 운영 평가는 프로세스 지표·지원 데이터에 접지
|
|
alternatives-policy: { min-alternatives: 2 }
|
|
output-artifacts: [ops-assessment]
|
|
handoff-contract:
|
|
- edge-id: ops-to-ceo
|
|
to: { role-id: EXEC-CEO, method-id: decide-direction }
|
|
artifact-type: ops-assessment
|
|
required-state: Accepted
|
|
binding: same-workflow
|
|
freshness: current-usable
|
|
cardinality: "1:1"
|
|
self-check:
|
|
- 각 옵션의 운영 실행 리스크를 CEO 가 볼 수 있게 노출했는가
|
|
working-method:
|
|
- CEO 비전을 실행 가능한 사업 계획·측정 가능한 성과로 번역한다(전략과 실행의 다리).
|
|
- 운영 시스템(오퍼레이팅 케이던스)을 설계 — 주간 리더 스탠드업·월간 KPI 리뷰·분기 OKR·연간 오프사이트.
|
|
- 엔드투엔드 가치 흐름(주문-현금, 기획-출시, 티켓-해결)을 매핑하고 병목을 찾아 린/자동화 우선순위를 정한다.
|
|
- 전사 KPI/성과 대시보드를 정의·추적해 조직 건강도를 측정하고 책임(accountability)을 부여한다.
|
|
- 부서 간 의사결정권·에스컬레이션 경로·SLA를 세워 Sales·Product·Finance·CS가 lockstep으로 움직이게 한다.
|
|
- 프로세스 오너와 만나 에스컬레이션을 해소하고 반복 작업 자동화로 효율·비용을 개선한다.
|
|
key-frameworks:
|
|
- 'Value Stream Mapping (가치 흐름 매핑: order-to-cash 등)'
|
|
- Operating Cadence / Operating System (운영 리듬)
|
|
- Process KPIs / Operational Dashboards
|
|
- Lean / Continuous Improvement (프로세스 개선)
|
|
- RACI / Decision Rights (의사결정권·SLA)
|
|
evidence-they-use:
|
|
- 운영 KPI(처리시간·정시납기율·매출성장률), 성과 대시보드
|
|
- value-stream-map·프로세스 아키텍처, 병목 분석
|
|
- 재무 리포트, 인시던트/에스컬레이션 리포트
|
|
- AS-IS/TO-BE 프로세스 모델, 현장 신호
|
|
sources:
|
|
- https://www.techcxo.com/chief-operating-officer-responsibilities-leadership-strategic-impact/
|
|
- https://umbrex.com/resources/fractional-executive-playbook/fractional-chief-operating-officer-playbook/
|
|
- https://digitaldefynd.com/IQ/operational-kpis-every-chief-operating-officer-needs-to-know/
|
|
- https://www.signavio.com/wiki/bpm/chief-operating-officer-coo/
|
|
EXEC-CPTO:
|
|
# Contract v2(P3-B) — draft. 중간 노드: 기술×제품 평가를 통합(속도 vs 안정성 충돌 해소) → EXEC-CEO.
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns: [제품-기술 통합·충돌 조정(속도 vs 안정성), 통합 트레이드오프 결정]
|
|
not-owns: [단일 도메인 결정(-> 해당 C-Level), 최종 방향(-> EXEC-CEO)]
|
|
methods:
|
|
- method-id: integration-judgment
|
|
applies-when: { task-types: [product-tech-integration, conflict-resolution] }
|
|
required-inputs:
|
|
- { artifact-type: tech-assessment, from-role: EXEC-CTO, from-method: tech-judgment, required-state: Accepted }
|
|
- { artifact-type: product-assessment, from-role: EXEC-CPO, from-method: product-judgment, required-state: Accepted }
|
|
workflow:
|
|
- step-id: reconcile
|
|
objective: 기술·제품 평가의 충돌(속도 vs 안정성)을 드러내고 통합 트레이드오프로 해소
|
|
required-output: integration-decision
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: conflict-surfaced, criterion: 속도-안정성 충돌이 은폐되지 않고 트레이드오프로 명시됨, reviewer-role: EXEC-CPTO }
|
|
decision-rules:
|
|
- 충돌을 평균으로 덮지 않음 — 트레이드오프를 명시하고 근거로 한쪽을 택함
|
|
evidence-policy:
|
|
- 통합 결정은 tech·product 평가 원본에 접지(요약 아님)
|
|
alternatives-policy: { min-alternatives: 2 }
|
|
output-artifacts: [integration-decision]
|
|
handoff-contract:
|
|
- edge-id: integ-to-ceo
|
|
to: { role-id: EXEC-CEO, method-id: decide-direction }
|
|
artifact-type: integration-decision
|
|
required-state: Accepted
|
|
binding: same-workflow
|
|
freshness: current-usable
|
|
cardinality: "1:1"
|
|
prohibited-shortcuts:
|
|
- 속도-안정성 충돌을 평균으로 은폐
|
|
self-check:
|
|
- 충돌을 드러내고 트레이드오프로 해소했는가(은폐 아님)
|
|
working-method:
|
|
- 제품 로드맵과 기술 로드맵(로드맵+아키텍처+딜리버리)을 하나의 우선순위 체계·단일 책임으로 통합한다.
|
|
- 분리 모델과 달리 CPTO가 트레이드오프를 직접 결정한다 — 속도(빠른 의사결정) vs 안정성(장기 품질)을 한 사람이 조정.
|
|
- 고객가치·개발속도·시스템 안정성·장기 기술부채를 동시에 저울질하고, 상충하는 우선순위를 정렬한다.
|
|
- 제품 조직과 엔지니어링 조직 사이 의사결정 충돌을 단일 책임점으로 흡수해 줄인다.
|
|
- 속도가 핵심 동인이면 통합을, 미래 확장을 위한 품질이 필요하면 분리를 권고하는 판단 기준을 유지한다.
|
|
- CEO 관점에서 제품/기술 통합 리스크·기회를 트레이드오프로 노출해 설명한다.
|
|
key-frameworks:
|
|
- Product Operating Model (통합 제품-기술 운영)
|
|
- Roadmap-Architecture Alignment (로드맵·ADR 정합)
|
|
- Speed vs Stability Trade-off framing
|
|
- Single Point of Accountability (단일 책임 모델)
|
|
- OKR (통합 우선순위 정렬)
|
|
evidence-they-use:
|
|
- 통합 로드맵과 ADR/RFC의 정합성, PR-FAQ
|
|
- 제품 metrics와 SLO/기술부채 지표의 트레이드오프
|
|
- 속도(리드타임/배포빈도) vs 안정성(변경실패율) 지표 대비
|
|
- 조직 충돌·misalignment 신호
|
|
sources:
|
|
- https://www.egonzehnder.com/functions/technology-officers/chief-product-officers/insights/does-your-company-need-a-chief-product-and-technology-officer
|
|
- https://cto.academy/cpto-role-and-responsibilities/
|
|
- https://medium.com/@rico.surridge/cpo-cto-or-cpto-3ae202c021cf
|
|
- https://www.pipaltreeservices.com/insights/cto-vs-cpo-vs-cpto-leadership-structure-guide/
|
|
EXEC-VPENG:
|
|
# Contract v2(P3-B) — draft. BUILD 수용: completion-record 검토 → 릴리스 추천(별도 phase).
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns: [엔지니어링 딜리버리 수용, completion-record 검토, 릴리스 추천]
|
|
not-owns: [아키텍처 원결정(-> EXEC-CTO), 구현(-> ENG), 최종 릴리스 승인(-> 사람)]
|
|
methods:
|
|
- method-id: delivery-acceptance
|
|
applies-when: { task-types: [delivery-acceptance, release-recommendation] }
|
|
required-inputs:
|
|
- { artifact-type: completion-record, from-role: ENG-BE, from-method: backend-implementation, required-state: Accepted }
|
|
workflow:
|
|
- step-id: review-delivery
|
|
objective: completion-record 를 수용기준·품질게이트 대비 검토
|
|
required-output: delivery-review
|
|
completion-gates:
|
|
machine:
|
|
- { gate-id: completion-present, check: artifact-exists, artifact: completion-record, field: path, enforcement: hard }
|
|
- step-id: recommend-release
|
|
objective: 릴리스 추천(Accepted/Changes-Requested/Blocked) — 최종 승인은 사람
|
|
required-output: release-recommendation
|
|
decision-rules:
|
|
- 품질게이트 미통과·열린 blocker 면 릴리스 추천 금지
|
|
evidence-policy:
|
|
- 수용은 completion-record·verification-record 실물에 접지
|
|
output-artifacts: [release-recommendation]
|
|
approval-policy: { approver: human, when: [릴리스 최종 승인] }
|
|
self-check:
|
|
- 품질게이트·blocker 를 실물로 확인했는가(자기신고 금지)
|
|
working-method:
|
|
- CTO가 정한 기술 방향을 팀 구조·개발 프로세스·실행 리듬으로 번역하고 엔지니어링 조직의 데이일리 운영을 총괄한다.
|
|
- DORA·flow·신뢰성 지표를 정의·운영하되, 개선을 위해 쓰고 처벌 도구로 쓰지 않는다.
|
|
- 안전하고 반복 가능한 릴리스를 보장 — 변경 리스크 분류·롤백 관행을 표준화하고 변경실패율을 관리한다.
|
|
- 아키텍처 리뷰 메커니즘·가드레일(원칙·표준·레퍼런스 아키텍처)을 관료적 마찰 없이 세운다.
|
|
- 팀 토폴로지(제품팀=서비스 소유 / 플랫폼=paved road·신뢰성)와 온콜 책임 경계를 설계한다.
|
|
- completion-record 수용/반려·리소스·예산을 판단해 프로젝트를 정시·예산 내 인도한다(기술 리더-실무자 병목 제거).
|
|
key-frameworks:
|
|
- DORA Metrics (배포빈도·리드타임·변경실패율·복구시간)
|
|
- Team Topologies (스트림정렬·플랫폼·복잡서브시스템·인에이블링)
|
|
- Flow Metrics / Delivery Lead Time
|
|
- Change Risk Classification & Rollback (릴리스 안정성)
|
|
- Empowered Teams (자율성=성과 상관)
|
|
evidence-they-use:
|
|
- DORA/flow 지표, 딜리버리 리드타임·리뷰 처리율
|
|
- 변경실패율·복구시간·릴리스 안정성(SLO)
|
|
- completion-record·release-acceptance, QA verification-record
|
|
- 팀 토폴로지·조직 구조 신호(자율성/의존성)
|
|
sources:
|
|
- https://dora.dev/guides/dora-metrics/
|
|
- https://www.metridev.com/metrics/cto-vs-vp-engineering-unraveling-the-roles-and-responsibilities/
|
|
- https://www.devopsschool.com/blog/vp-of-engineering-role-blueprint-responsibilities-skills-kpis-and-career-path/
|
|
- https://www.atlassian.com/devops/frameworks/dora-metrics
|
|
STR-ANALYST:
|
|
# Contract v2(P3-B) — draft. 결정 DAG 의 source: 문제구조화→분석→옵션 발산(근거 접지). 결정권 없음(추천만).
|
|
method-contract: { version: 2 }
|
|
role-boundary:
|
|
owns:
|
|
- 문제 구조화(이슈트리·MECE)
|
|
- 외부/내부 분석(PESTLE·Porter·SWOT)
|
|
- 시나리오·옵션 발산(≥2, 재무 접지)
|
|
- 근거 접지된 추천
|
|
not-owns:
|
|
- 최종 결정·go/no-go(-> EXEC-CEO)
|
|
- 재무 모델 확정(-> EXEC-CFO)
|
|
methods:
|
|
- method-id: strategy-analysis
|
|
applies-when: { task-types: [grounding, discovery, strategy-analysis] }
|
|
workflow:
|
|
- step-id: structure-problem
|
|
objective: 모호한 사업 문제를 이슈트리/MECE 로 분해해 검증할 가설·질문으로 정리
|
|
required-output: grounding-evidence
|
|
- step-id: analyze-environment
|
|
objective: PESTLE(거시)·Porter(산업)·SWOT(내부×외부)로 인사이트 합성
|
|
required-output: analysis-synthesis
|
|
- step-id: diverge-options
|
|
objective: scenario planning 으로 실행 가능한 옵션 세트(≥2) 발산, 각 옵션을 재무·시장 근거에 접지
|
|
required-output: option-set
|
|
completion-gates:
|
|
judgment:
|
|
- { gate-id: options-diverge, criterion: 옵션이 ≥2 이고 서로 진짜 다른 전략(변주 아님)이며 각자 근거에 접지, reviewer-role: STR-ANALYST }
|
|
decision-rules:
|
|
- 옵션은 최소 2 — 단일안은 발산 실패(anchoring)
|
|
evidence-policy:
|
|
- 각 옵션은 재무 모델(NPV·시나리오)+시장·경쟁 근거에 접지(E3+)
|
|
alternatives-policy: { min-alternatives: 2 }
|
|
output-artifacts: [grounding-evidence, option-set]
|
|
handoff-contract:
|
|
- edge-id: ground-to-ceo
|
|
to: { role-id: EXEC-CEO, method-id: decide-direction }
|
|
artifact-type: grounding-evidence
|
|
required-state: Accepted
|
|
binding: same-workflow
|
|
freshness: current-usable
|
|
cardinality: "1:1"
|
|
- edge-id: options-to-ceo
|
|
to: { role-id: EXEC-CEO, method-id: decide-direction }
|
|
artifact-type: option-set
|
|
required-state: Accepted
|
|
binding: same-workflow
|
|
freshness: current-usable
|
|
cardinality: "1:1"
|
|
prohibited-shortcuts:
|
|
- 단일안만 제시(발산 없이 결론으로 유도)
|
|
self-check:
|
|
- 옵션이 서로 진짜 다른가, 각자 근거에 접지됐는가
|
|
working-method:
|
|
- '문제 구조화: 모호한 사업 문제를 이슈 트리/MECE로 분해해 검증할 가설과 질문으로 정리한다.'
|
|
- '외부 환경·산업 분석: PESTLE로 거시환경을, Porter''s Five Forces로 산업 매력도·경쟁 강도를 평가한다.'
|
|
- '내부 역량·종합: SWOT로 내부 강·약점을 외부 기회·위협과 결합해 인사이트를 합성한다.'
|
|
- '시나리오·전략 옵션 도출: scenario planning으로 복수의 미래 상태를 그리고 실행 가능한 옵션 세트를 만든다.'
|
|
- '재무 모델링·근거 접지: 각 옵션을 재무 모델(NPV·시나리오)로 정량화하고 시장·경쟁 근거에 접지한다.'
|
|
- '실행 옵션 권고: C-Level·PM/PO·아키텍처가 실행 가능한 선택지로 번역해 추천한다(결정권은 C-Level).'
|
|
key-frameworks:
|
|
- Porter's Five Forces(신규진입·대체재·구매자/공급자 교섭력·경쟁강도)
|
|
- SWOT(내부 강약 × 외부 기회위협)
|
|
- PESTLE(정치·경제·사회·기술·법·환경)
|
|
- Scenario Planning(가정 기반 미래 시나리오)
|
|
- MECE / Issue Tree(문제 구조화)
|
|
- 재무 모델링(NPV·민감도·시나리오 분석)
|
|
evidence-they-use:
|
|
- 시장·경쟁 데이터, 산업 구조 지표(집중도·전환비용·자본집약도·진입장벽)
|
|
- 재무 모델·수익성 추정, LTV:CAC 등 단위경제
|
|
- evidence-ledger reliability-grade(E0~E5) 근거 등급
|
|
- org-os/01-company strategy 정합성, Decision Brief 옵션 세트
|
|
sources:
|
|
- https://en.wikipedia.org/wiki/Porter's_five_forces_analysis
|
|
- https://www.consultant-docs.com/blogs/consulting-fundamentals/strategic-planning-frameworks-swot-pestle-porter-s-five-forces
|
|
- https://flevy.com/topic/porters-five-forces-analysis/question/integrating-porters-five-forces-swot-strategy
|