756 lines
44 KiB
YAML
756 lines
44 KiB
YAML
# consulting-documentation.yaml — role-working-methods 파일분리(P3). 내용 불변(v1). Contract v2는 wave에서 additive.
|
||
role-working-methods:
|
||
CONSULT-EM:
|
||
# Contract v2(P3-B) — draft. 컨설팅 리드: frame-engagement(이슈트리·Day-1) → 5워커 → synthesize-storyline(Pyramid 종합).
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [이슈트리·Day-1 가설·workplan 프레이밍, 5분과 워커 종합(Pyramid Principle), storyline·dissent 보존]
|
||
not-owns: [개별 분과 분석 생산(-> CONSULT-STRAT/OPS/ORG/DIGITAL/FIN), 최종 방향 결정(-> EXEC-CEO/사람)]
|
||
methods:
|
||
- method-id: frame-engagement
|
||
applies-when: { task-types: [engagement-framing, issue-tree, workplan] }
|
||
workflow:
|
||
- step-id: structure-issue-tree
|
||
objective: 질문을 issue tree(hypothesis tree)로 MECE 분해 + Day-1 가설 + 임팩트×실현가능성 우선순위
|
||
required-output: issue-tree
|
||
- step-id: build-workplan
|
||
objective: workplan 3계층(최종산출물→마일스톤→일/주간 팀산출물)으로 쪼개 분과에 배분 후 engagement-frame
|
||
required-output: engagement-frame
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: mece-framed, criterion: 이슈트리가 MECE 이고 Day-1 가설·우선순위가 명시됨, reviewer-role: CONSULT-EM }
|
||
decision-rules:
|
||
- 고임팩트 가지부터 팀 투입(우선순위 매트릭스)
|
||
alternatives-policy: { min-alternatives: 2 }
|
||
output-artifacts: [engagement-frame]
|
||
handoff-contract:
|
||
- edge-id: frame-to-strat
|
||
to: { role-id: CONSULT-STRAT, method-id: strategy-consulting }
|
||
artifact-type: engagement-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
- edge-id: frame-to-ops
|
||
to: { role-id: CONSULT-OPS, method-id: operations-consulting }
|
||
artifact-type: engagement-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
- edge-id: frame-to-org
|
||
to: { role-id: CONSULT-ORG, method-id: org-consulting }
|
||
artifact-type: engagement-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
- edge-id: frame-to-digital
|
||
to: { role-id: CONSULT-DIGITAL, method-id: digital-consulting }
|
||
artifact-type: engagement-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
- edge-id: frame-to-fin
|
||
to: { role-id: CONSULT-FIN, method-id: financial-consulting }
|
||
artifact-type: engagement-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- 이슈트리가 MECE 이고 우선순위가 명시됐는가
|
||
- method-id: synthesize-storyline
|
||
applies-when: { task-types: [synthesis, storyline, pyramid] }
|
||
required-inputs:
|
||
- { artifact-type: consult-strategy, from-role: CONSULT-STRAT, from-method: strategy-consulting, required-state: Accepted }
|
||
- { artifact-type: consult-operations, from-role: CONSULT-OPS, from-method: operations-consulting, required-state: Accepted }
|
||
- { artifact-type: consult-org, from-role: CONSULT-ORG, from-method: org-consulting, required-state: Accepted }
|
||
- { artifact-type: consult-digital, from-role: CONSULT-DIGITAL, from-method: digital-consulting, required-state: Accepted }
|
||
- { artifact-type: consult-finance, from-role: CONSULT-FIN, from-method: financial-consulting, required-state: Accepted }
|
||
workflow:
|
||
- step-id: rehydrate-read
|
||
objective: 5분과 보고서 원본을 전부 읽는다(rehydration — 요약 아님, conflicts 보존)
|
||
required-output: synthesis-notes
|
||
- step-id: pyramid-storyline
|
||
objective: Pyramid Principle 로 지배 메시지 아래 종합 + dot-dash storyline 으로 논리 검증 후 consulting-storyline
|
||
required-output: consulting-storyline
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: dissent-preserved, criterion: 지배 메시지로 종합하되 분과 간 conflicts·dissent 가 보존됨, reviewer-role: CONSULT-EM }
|
||
decision-rules:
|
||
- 슬라이드 이전에 storyline 으로 논리 검증(액션타이틀·one-message-per-slide)
|
||
evidence-policy:
|
||
- 종합은 분과 .report.yaml 원본에 접지(요약 아님)
|
||
output-artifacts: [consulting-storyline]
|
||
prohibited-shortcuts:
|
||
- 분과 보고서를 읽지 않고 종합(dissent 소실)
|
||
self-check:
|
||
- 원본을 전부 읽고 conflicts 를 보존했는가
|
||
working-method:
|
||
- 프로젝트 1주차에 질문을 issue tree(hypothesis tree)로 MECE하게 분해하고 동시에 Day-1 가설을 세운다.
|
||
- 이슈를 임팩트×실현가능성 우선순위 매트릭스에 매핑해 고임팩트 가지부터 팀을 투입한다.
|
||
- workplan을 3계층(최종 산출물 → 중간 마일스톤 → 일/주간 팀 산출물)으로 쪼개 배분한다.
|
||
- 가설 검증형 분석을 돌리고 클라이언트 인터뷰·데이터로 가설을 반증/보강하며 우선순위를 재조정한다.
|
||
- Pyramid Principle로 분석을 지배 메시지(governing thought) 아래 종합하고 dot-dash storyline으로 슬라이드 이전에 논리를 검증한다.
|
||
- 분과 컨설턴트 보고서를 전부 읽어(rehydration) 액션타이틀·one-message-per-slide로 스토리라인을 확정하고 conflicts를 보존한다.
|
||
key-frameworks:
|
||
- Hypothesis-driven approach (Day-1 Answer)
|
||
- Issue Tree / Hypothesis Tree
|
||
- MECE (Mutually Exclusive, Collectively Exhaustive)
|
||
- Pyramid Principle (Barbara Minto)
|
||
- SCQA (Situation-Complication-Question-Answer)
|
||
- Impact×Feasibility 우선순위 매트릭스
|
||
evidence-they-use:
|
||
- 클라이언트 내부 데이터(재무·운영 지표), 스테이크홀더/전문가 인터뷰
|
||
- 산업·시장 데이터 및 벤치마크
|
||
- 가설 검증용 분석 모델(엑셀 driver 모델)
|
||
- 분과 컨설턴트 .report.yaml 원본(종합 입력)
|
||
sources:
|
||
- https://umbrex.com/resources/mckinsey-problem-solving/
|
||
- https://strategyu.co/problem-solving-101/
|
||
- https://managementconsulted.com/pyramid-principle/
|
||
- https://www.roadtooffer.com/blog/what-does-an-engagement-manager-at-mckinsey-do
|
||
CONSULT-STRAT:
|
||
# Contract v2(P3-B) — draft. 컨설팅 워커: engagement-frame 소비 → 전략 분석 → consult-strategy → EM.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [Porter/Value Chain/BCG/Ansoff/Three Horizons 전략 분석, 포트폴리오·성장경로]
|
||
not-owns: [엔게이지먼트 프레이밍·종합(-> CONSULT-EM), 운영/조직/재무 분과(-> 해당 워커)]
|
||
methods:
|
||
- method-id: strategy-consulting
|
||
applies-when: { task-types: [strategy-consulting, industry-analysis, portfolio] }
|
||
required-inputs:
|
||
- { artifact-type: engagement-frame, from-role: CONSULT-EM, from-method: frame-engagement, required-state: Accepted }
|
||
workflow:
|
||
- step-id: analyze-industry
|
||
objective: MECE 이슈트리·answer-first + Porter Five Forces·value chain 으로 산업 매력도·이익풀 진단
|
||
required-output: industry-analysis
|
||
- step-id: portfolio-roadmap
|
||
objective: BCG·Ansoff·Three Horizons 로 포트폴리오·성장경로 배치 후 consult-strategy
|
||
required-output: consult-strategy
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: framework-grounded, criterion: 전략 진단이 프레임워크·시장 데이터에 접지됨, reviewer-role: CONSULT-STRAT }
|
||
decision-rules:
|
||
- 프레임워크는 결합해 사용(단일 프레임 과신 금지)
|
||
evidence-policy:
|
||
- 전략은 시장 규모·경쟁 벤치마크·재무 데이터에 접지
|
||
output-artifacts: [consult-strategy]
|
||
handoff-contract:
|
||
- edge-id: strat-to-em
|
||
to: { role-id: CONSULT-EM, method-id: synthesize-storyline }
|
||
artifact-type: consult-strategy
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- 진단이 프레임워크·데이터에 접지됐는가
|
||
working-method:
|
||
- 전략 질문을 MECE 이슈트리로 분해하고 answer-first(가설 우선)로 검증 대상을 좁힌다.
|
||
- Porter's Five Forces로 산업 매력도·수익성 압력(신규진입·대체재·공급자/구매자 교섭력·경쟁강도)을 진단한다.
|
||
- value chain 분석으로 자사 강점 구간과 이익 풀(profit pool)의 위치를 식별한다.
|
||
- BCG Growth-Share Matrix로 포트폴리오를 star/cash cow/question mark/dog으로 분류해 투자를 배분한다.
|
||
- Ansoff Matrix로 성장 경로별 리스크 프로파일을 비교하고 프레임워크를 결합한다.
|
||
- Three Horizons로 H1(핵심 강화)·H2(인접 확장)·H3(미래 옵션)에 이니셔티브를 배치해 로드맵화한다.
|
||
key-frameworks:
|
||
- Porter's Five Forces
|
||
- Value Chain
|
||
- BCG Growth-Share Matrix
|
||
- Ansoff Matrix
|
||
- McKinsey Three Horizons
|
||
- McKinsey 7-S
|
||
evidence-they-use:
|
||
- 시장 규모·성장률·점유율 데이터
|
||
- 산업/규제 동향 및 경쟁사 벤치마크
|
||
- 클라이언트 재무·수익성 데이터
|
||
- 고객·전문가 인터뷰
|
||
sources:
|
||
- https://strategyu.co/consulting-frameworks/
|
||
- https://en.wikipedia.org/wiki/Porter%27s_five_forces_analysis
|
||
- https://umbrex.com/resources/frameworks/marketing-frameworks/three-horizons-of-growth-mckinsey/
|
||
- https://umbrex.com/resources/frameworks/strategy-frameworks/mece-principle/
|
||
CONSULT-OPS:
|
||
# Contract v2(P3-B) — draft. 컨설팅 워커: engagement-frame 소비 → 운영 분석 → consult-operations → EM.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [VSM·원가 baseline·driver tree, DMAIC 근본원인, TOM(현재→목표 운영모델)]
|
||
not-owns: [엔게이지먼트 프레이밍·종합(-> CONSULT-EM), 전략/조직/재무 분과(-> 해당 워커)]
|
||
methods:
|
||
- method-id: operations-consulting
|
||
applies-when: { task-types: [operations-consulting, cost-reduction, process-improvement] }
|
||
required-inputs:
|
||
- { artifact-type: engagement-frame, from-role: CONSULT-EM, from-method: frame-engagement, required-state: Accepted }
|
||
workflow:
|
||
- step-id: map-and-baseline
|
||
objective: VSM 으로 병목 가시화 + 원가 MECE 재구성·baseline + driver tree 로 개선 레버 정량화
|
||
required-output: cost-baseline
|
||
- step-id: dmaic-tom
|
||
objective: DMAIC 근본원인 규명 + 벤치마킹(SCOR) + TOM 설계·재무 정량화 후 consult-operations
|
||
required-output: consult-operations
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: root-cause-data, criterion: 근본원인이 데이터로 규명되고 개선 임팩트가 정량화됨, reviewer-role: CONSULT-OPS }
|
||
decision-rules:
|
||
- 근본원인은 데이터 기반으로 규명(추측 금지)
|
||
evidence-policy:
|
||
- 운영은 사이클타임·수율·원가 baseline·벤치마크에 접지
|
||
output-artifacts: [consult-operations]
|
||
handoff-contract:
|
||
- edge-id: ops-to-em
|
||
to: { role-id: CONSULT-EM, method-id: synthesize-storyline }
|
||
artifact-type: consult-operations
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- 근본원인·임팩트를 데이터로 정량화했는가
|
||
working-method:
|
||
- 워크플로를 매핑(value stream mapping)해 지연·중복·불필요 단계·자원 병목을 가시화한다.
|
||
- 원가를 MECE로 재구성(직접비/간접비/오버헤드)해 원가 베이스라인과 절감 기회를 도출한다.
|
||
- driver tree로 원가·성과를 하위 동인으로 분해하고 개선 레버의 임팩트를 정량화한다.
|
||
- DMAIC(Define-Measure-Analyze-Improve-Control)로 근본원인을 데이터 기반으로 규명·제거한다.
|
||
- 벤치마킹(SCOR 등)으로 best practice·KPI 대비 격차를 측정하고 목표 수준을 설정한다.
|
||
- TOM(현재→목표 운영모델)을 설계하고 재무 모델로 투자·효과를 정량화한 뒤 실행·변화관리로 이행한다.
|
||
key-frameworks:
|
||
- Lean (Toyota Production System)
|
||
- Six Sigma / DMAIC
|
||
- Value Stream Mapping
|
||
- Target Operating Model (TOM)
|
||
- Driver Tree / Cost Baseline
|
||
- SCOR (Supply Chain benchmarking)
|
||
evidence-they-use:
|
||
- 프로세스 사이클타임·수율·불량률 등 운영 데이터
|
||
- 원가 베이스라인·재무 모델
|
||
- 산업 벤치마크·KPI
|
||
- 현장 프로세스 관찰 및 현업 인터뷰
|
||
sources:
|
||
- https://www.bain.com/consulting-services/operations/lean-six-sigma/
|
||
- https://www.deloitte.com/lu/en/services/consulting/services/target-operating-model.html
|
||
- https://www.6sigma.us/lean-six-sigma-articles/lean-six-sigma-operations-management/
|
||
- https://burniegroup.com/capabilities/target-operating-model-design/
|
||
CONSULT-ORG:
|
||
# Contract v2(P3-B) — draft. 컨설팅 워커: engagement-frame 소비 → 조직·변화 분석 → consult-org → EM.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [operating model 진단(7S)·spans&layers, ADKAR·Kotter 변화관리, RACI·거버넌스 handoff]
|
||
not-owns: [엔게이지먼트 프레이밍·종합(-> CONSULT-EM), 전략/운영/재무 분과(-> 해당 워커)]
|
||
methods:
|
||
- method-id: org-consulting
|
||
applies-when: { task-types: [org-consulting, change-management, operating-model] }
|
||
required-inputs:
|
||
- { artifact-type: engagement-frame, from-role: CONSULT-EM, from-method: frame-engagement, required-state: Accepted }
|
||
workflow:
|
||
- step-id: diagnose-org
|
||
objective: operating model 다요소 진단(7S) + spans&layers·activity analysis 로 계층 과잉·저부가 활동 정량화
|
||
required-output: org-diagnosis
|
||
- step-id: change-handoff
|
||
objective: 이해관계자 맵·ADKAR·Kotter 변화관리 + RACI·거버넌스 케이던스 handoff 후 consult-org
|
||
required-output: consult-org
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: change-planned, criterion: 조직 gap 이 벤치마크로 정량화되고 변화관리·거버넌스가 설계됨, reviewer-role: CONSULT-ORG }
|
||
decision-rules:
|
||
- 설계가 운영으로 넘어가게 RACI·KPI 를 delivery 에 심음(설계 방치 금지)
|
||
evidence-policy:
|
||
- 조직은 spans/layers·활동배분·change readiness 지표에 접지
|
||
output-artifacts: [consult-org]
|
||
handoff-contract:
|
||
- edge-id: org-to-em
|
||
to: { role-id: CONSULT-EM, method-id: synthesize-storyline }
|
||
artifact-type: consult-org
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- gap 정량화·변화관리를 설계했는가
|
||
working-method:
|
||
- 현행 operating model을 다요소(purpose·structure·governance·processes·technology·behaviors·rewards·talent)로 진단하고 전략과의 정합 gap을 매핑한다.
|
||
- spans & layers 분석 + 외부 벤치마크(지식노동 span 6~8, 운영직 15~25)로 계층 과잉·병목을 정량화한다.
|
||
- activity analysis로 실제 업무 시간 배분을 잡아 중복·저부가 활동을 걷어내고 역할을 재설계한다.
|
||
- 이해관계자 맵·change impact assessment로 저항 요인을 식별하고 ADKAR로 개인 전환 상태를 단계 관리한다.
|
||
- guiding coalition을 세우고 quick win을 설계·가시화해 모멘텀을 만든 뒤 새 프로세스/보상/거버넌스로 행동을 hard-wire한다(Kotter).
|
||
- RACI/decision rights·KPI·거버넌스 케이던스를 delivery에 심어 설계가 운영으로 넘어가게 handoff한다.
|
||
key-frameworks:
|
||
- McKinsey 7S
|
||
- Target Operating Model (TOM)
|
||
- Prosci ADKAR (+3-Phase, PCT)
|
||
- Kotter 8-Step
|
||
- Galbraith Star Model
|
||
- Spans & Layers / RACI (RAPID)
|
||
evidence-they-use:
|
||
- 조직도·HR 데이터(headcount, spans/layers, 인건비), 활동·시간 배분
|
||
- 이해관계자 인터뷰·설문, change readiness/채택률 pulse
|
||
- 외부 벤치마크(산업별 span·layer·조직비용 norm), 문화·engagement 진단
|
||
- 전략 문서·value agenda(전략 목표 대비 조직 선택의 정합)
|
||
sources:
|
||
- https://www.kotterinc.com/methodology/8-steps/
|
||
- https://www.prosci.com/methodology/adkar
|
||
- https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-an-operating-model
|
||
- https://umbrex.com/resources/frameworks/strategy-frameworks/span-of-control-layering-analysis/
|
||
CONSULT-DIGITAL:
|
||
# Contract v2(P3-B) — draft. 컨설팅 워커: engagement-frame 소비 → 디지털 분석 → consult-digital → EM.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [디지털 성숙도 진단·TOGAF ADM to-be, use-case 우선순위(value at stake), 기술 로드맵]
|
||
not-owns: [엔게이지먼트 프레이밍·종합(-> CONSULT-EM), 전략/운영/재무 분과(-> 해당 워커)]
|
||
methods:
|
||
- method-id: digital-consulting
|
||
applies-when: { task-types: [digital-consulting, digital-transformation, tech-roadmap] }
|
||
required-inputs:
|
||
- { artifact-type: engagement-frame, from-role: CONSULT-EM, from-method: frame-engagement, required-state: Accepted }
|
||
workflow:
|
||
- step-id: assess-maturity
|
||
objective: 디지털 성숙도(BCG DAI/McKinsey DQ) 벤치마크 + 인프라 audit·skill gap 으로 as-is 진단
|
||
required-output: maturity-assessment
|
||
- step-id: prioritize-roadmap
|
||
objective: use-case 를 value·feasibility·fit 스코어링 + value at stake 정량화 + multi-horizon 로드맵 후 consult-digital
|
||
required-output: consult-digital
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: value-linked, criterion: use-case 가 value at stake·비즈니스 KPI 에 연결됨, reviewer-role: CONSULT-DIGITAL }
|
||
decision-rules:
|
||
- 기술 투자는 value at stake 로 비즈니스 결과에 연결(기술을 위한 기술 금지)
|
||
evidence-policy:
|
||
- 디지털은 성숙도 벤치마크·value-at-stake·adoption KPI 에 접지
|
||
output-artifacts: [consult-digital]
|
||
handoff-contract:
|
||
- edge-id: digital-to-em
|
||
to: { role-id: CONSULT-EM, method-id: synthesize-storyline }
|
||
artifact-type: consult-digital
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- use-case 가 value at stake 에 연결됐는가
|
||
working-method:
|
||
- digital maturity assessment(BCG 41-dimension 벤치마크, McKinsey DQ)로 현재 상태를 peer·리더 대비 점수화한다.
|
||
- 기술 인프라 audit + skill gap 분석으로 as-is를 진단하고 4개 도메인(Business·Data·Application·Technology)으로 to-be를 설계한다(TOGAF ADM).
|
||
- use case를 value·feasibility·strategic fit로 스코어링해 우선순위 백로그를 만들고 각 use case에 value at stake를 정량화한다.
|
||
- 로드맵을 12/24/36개월 multi-horizon으로 짜되 초기엔 6~9개월 짧은 사이클로 평가·학습·course correction을 반복한다.
|
||
- 플랫폼 코어 결정(cloud, data 패턴 lake/mesh/lakehouse, 통합 API-first/event-driven, build vs SaaS/COTS)을 내리고 Agile·DevOps로 build·migrate·integrate한다.
|
||
- 비즈니스 KPI에 로드맵을 묶고 governance·데이터 품질·adoption을 지속 측정해 규모화(scale)한다.
|
||
key-frameworks:
|
||
- Digital Maturity Model (BCG DAI / McKinsey DQ)
|
||
- TOGAF ADM (Enterprise Architecture)
|
||
- Technology Roadmap (multi-horizon)
|
||
- Use-Case Prioritization (value·feasibility·fit)
|
||
- Cloud/Data Architecture Patterns (lake·mesh·lakehouse)
|
||
- Agile/SAFe & DevOps
|
||
evidence-they-use:
|
||
- 디지털 성숙도 벤치마크 점수·peer 비교, 아키텍처/인프라 audit
|
||
- use case별 value-at-stake·비용/편익, 데이터 품질·거버넌스 진단
|
||
- 기술 스택·의존성 매핑, 벤더/플랫폼 평가, adoption·성능 KPI
|
||
- 비즈니스 전략·P&L 목표(기술 이니셔티브의 비즈니스 결과 연결)
|
||
sources:
|
||
- https://www.bcg.com/capabilities/digital-technology-data/digital-maturity
|
||
- https://www.mckinsey.com/capabilities/quantumblack/how-we-help-clients
|
||
- https://www.cio.com/article/228328/what-is-togaf-an-enterprise-architecture-methodology-for-business.html
|
||
- https://www.opengroup.org/togaf
|
||
CONSULT-FIN:
|
||
# Contract v2(P3-B) — draft. 컨설팅 워커: engagement-frame 소비 → 재무·리스크 분석 → consult-finance → EM.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [Quality of Earnings·normalized EBITDA, DCF·comparables valuation 삼각검증, sensitivity·Three Lines of Defense]
|
||
not-owns: [엔게이지먼트 프레이밍·종합(-> CONSULT-EM), 전략/운영/조직 분과(-> 해당 워커)]
|
||
methods:
|
||
- method-id: financial-consulting
|
||
applies-when: { task-types: [financial-consulting, valuation, due-diligence] }
|
||
required-inputs:
|
||
- { artifact-type: engagement-frame, from-role: CONSULT-EM, from-method: frame-engagement, required-state: Accepted }
|
||
workflow:
|
||
- step-id: normalize-earnings
|
||
objective: 3~5년 재무 정규화(일회성 제거)로 지속가능 EBITDA(QoE) + 운전자본·net debt·우발채무 식별
|
||
required-output: quality-of-earnings
|
||
- step-id: valuation-risk
|
||
objective: driver 기반 3-statement + DCF·comparables 삼각검증 + sensitivity/Monte Carlo + Three Lines of Defense 후 consult-finance
|
||
required-output: consult-finance
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: valuation-triangulated, criterion: valuation 이 DCF·comparables 로 삼각검증되고 모델 무결성이 확인됨, reviewer-role: CONSULT-FIN }
|
||
decision-rules:
|
||
- 불확실성 큰 변수는 Monte Carlo 로 downside 정량화(단일 점추정 금지)
|
||
evidence-policy:
|
||
- 재무는 감사 재무제표·시장 배수·모델 무결성 리뷰에 접지(E4)
|
||
output-artifacts: [consult-finance]
|
||
handoff-contract:
|
||
- edge-id: fin-to-em
|
||
to: { role-id: CONSULT-EM, method-id: synthesize-storyline }
|
||
artifact-type: consult-finance
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- valuation 삼각검증·모델 무결성을 확인했는가
|
||
working-method:
|
||
- 과거 3~5년 손익·재무상태·현금흐름을 정규화(normalize)해 일회성·회계성 이익을 걷어내고 지속가능 EBITDA를 산출한다(Quality of Earnings).
|
||
- 운전자본 사이클·계절성을 분석해 closing용 working capital target을 산정하고 net debt·우발채무·세무 노출을 식별한다.
|
||
- driver-based 3-statement 모델을 세우고 DCF(WACC·terminal value)와 trading/transaction comparables로 valuation을 삼각 검증한다.
|
||
- 핵심 driver에 sensitivity·scenario 분석을 걸고 불확실성 큰 변수는 Monte Carlo로 분포·downside를 정량화한다.
|
||
- 모델 무결성 리뷰(로직·수식·순환참조·감사추적)로 산출물 신뢰도를 독립 검증한다.
|
||
- 식별된 리스크를 Three Lines of Defense로 배치하고 완화책·통제·거버넌스 케이던스를 권고한다.
|
||
key-frameworks:
|
||
- DCF / WACC valuation
|
||
- Comparable Company & Precedent Transaction Analysis
|
||
- Quality of Earnings (normalized EBITDA)
|
||
- Driver Tree / 3-Statement Model
|
||
- Sensitivity·Scenario & Monte Carlo Simulation
|
||
- Three Lines of Defense (+ERM)
|
||
evidence-they-use:
|
||
- 감사 재무제표·management accounts(3~5년), 원장·거래 상세, 세무 신고
|
||
- 시장 데이터(comparable 배수·금리·WACC 입력), 산업 벤치마크
|
||
- 매니지먼트 인터뷰·사업계획·계약, data room 문서
|
||
- 규제·회계 기준(IFRS/GAAP), 리스크 레지스터·통제 테스트 결과
|
||
sources:
|
||
- https://www.deloitte.com/global/en/services/consulting/services/valuation-modeling.html
|
||
- https://www.kroll.com/en/services/transaction-advisory-services/financial-due-diligence
|
||
- https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/
|
||
- https://www.intralinks.com/guides/financial-due-diligence-ma
|
||
DOC-LEAD:
|
||
# Contract v2(P3-B) — draft. 문서 리드: frame-docs(audience·outline) → 4워커 → synthesize-docs(Pyramid 종합).
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [audience&purpose 계약·outline-first, Diátaxis 유형 분류, 4분과 종합(Pyramid)·2단 검수]
|
||
not-owns: [개별 콘텐츠 생산(-> DOC-WRITER/IA/VISUAL/EDU), 제품·전략 결정(-> PROD-PM/EXEC-CEO)]
|
||
methods:
|
||
- method-id: frame-docs
|
||
applies-when: { task-types: [doc-framing, outline, audience-definition] }
|
||
workflow:
|
||
- step-id: declare-audience
|
||
objective: audience&purpose 를 문서 최상단 계약으로 고정(누가·무엇을 하려고 읽는가)
|
||
required-output: audience-purpose
|
||
- step-id: outline-first
|
||
objective: 문장 이전에 목차·섹션별 one-message + Diátaxis 4유형 분류 후 doc-frame
|
||
required-output: doc-frame
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: outline-agreed, criterion: audience·purpose 와 섹션별 핵심 메시지·Diátaxis 유형이 합의됨, reviewer-role: DOC-LEAD }
|
||
decision-rules:
|
||
- 목적이 섞인 문서는 Diátaxis 유형으로 분리(튜토리얼/how-to/reference/explanation)
|
||
output-artifacts: [doc-frame]
|
||
handoff-contract:
|
||
- edge-id: frame-to-writer
|
||
to: { role-id: DOC-WRITER, method-id: technical-writing }
|
||
artifact-type: doc-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
- edge-id: frame-to-ia
|
||
to: { role-id: DOC-IA, method-id: information-architecture }
|
||
artifact-type: doc-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
- edge-id: frame-to-visual
|
||
to: { role-id: DOC-VISUAL, method-id: diagram-design }
|
||
artifact-type: doc-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
- edge-id: frame-to-edu
|
||
to: { role-id: DOC-EDU, method-id: learning-design }
|
||
artifact-type: doc-frame
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- audience·outline·Diátaxis 유형이 합의됐는가
|
||
- method-id: synthesize-docs
|
||
applies-when: { task-types: [doc-synthesis, editorial] }
|
||
required-inputs:
|
||
- { artifact-type: doc-content, from-role: DOC-WRITER, from-method: technical-writing, required-state: Accepted }
|
||
- { artifact-type: doc-ia, from-role: DOC-IA, from-method: information-architecture, required-state: Accepted }
|
||
- { artifact-type: doc-diagram, from-role: DOC-VISUAL, from-method: diagram-design, required-state: Accepted }
|
||
- { artifact-type: doc-learning, from-role: DOC-EDU, from-method: learning-design, required-state: Accepted }
|
||
workflow:
|
||
- step-id: pyramid-assemble
|
||
objective: 기여자 초안을 Pyramid Principle(SCQA·결론 먼저)로 재배열해 단일 논증으로 종합
|
||
required-output: assembled-draft
|
||
- step-id: two-pass-edit
|
||
objective: structural edit → copy edit 2단 검수로 논리 공백·중복·톤 불일치 제거 후 documentation-set
|
||
required-output: documentation-set
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: coherent-set, criterion: 문서 전체가 하나의 목적·스토리라인으로 수렴하고 2단 검수됨, reviewer-role: DOC-LEAD }
|
||
decision-rules:
|
||
- 릴리스 전 structural→copy 2단 검수(논리 공백·중복 제거)
|
||
evidence-policy:
|
||
- 종합은 기여자 초안·SME 리뷰·사용 analytics 에 접지
|
||
output-artifacts: [documentation-set]
|
||
self-check:
|
||
- 전체가 하나의 목적으로 수렴하고 2단 검수했는가
|
||
working-method:
|
||
- audience & purpose 선언을 문서 최상단 계약으로 먼저 고정한다(누가·무엇을 하려고 읽는가).
|
||
- outline-first — 문장 쓰기 전에 목차·섹션별 핵심 메시지(one message per section)를 먼저 합의한다.
|
||
- 기여자 초안을 Pyramid Principle(SCQA + 결론 먼저)로 재배열해 단일 논증 피라미드로 종합한다.
|
||
- Diátaxis 4유형(튜토리얼/how-to/reference/explanation)으로 섹션을 분류해 목적이 섞인 문서를 분리한다.
|
||
- 공통 doc-type 템플릿·style guide로 기여자 편차를 흡수하고 editorial calendar로 리뷰 사이클을 운영한다.
|
||
- 릴리스 전 structural edit → copy edit 2단 검수로 논리 공백·중복·톤 불일치를 제거한다.
|
||
key-frameworks:
|
||
- Diátaxis (tutorial/how-to/reference/explanation)
|
||
- Pyramid Principle (Minto, SCQA)
|
||
- docs-as-code review workflow
|
||
- topic-based authoring / 템플릿 표준화
|
||
- Google/Microsoft/Write the Docs style guides
|
||
- editorial calendar + DRAI 게이트
|
||
evidence-they-use:
|
||
- 독자/오디언스 리서치·페르소나
|
||
- 문서 유형 taxonomy(Diátaxis 매핑), style guide·용어집
|
||
- 사용/검색 analytics·지원 티켓
|
||
- 기여자 초안·SME 리뷰 코멘트
|
||
sources:
|
||
- https://diataxis.fr/start-here/
|
||
- https://www.barbaraminto.com/
|
||
- https://developers.google.com/tech-writing
|
||
- https://www.writethedocs.org/guide/docs-as-code/
|
||
DOC-WRITER:
|
||
# Contract v2(P3-B) — draft. 문서 워커: doc-frame 소비 → 테크니컬 라이팅 → doc-content → DOC-LEAD.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [Diátaxis 유형별 서술, one-idea-per-section·active voice, docs-as-code·dogfooding 재현성]
|
||
not-owns: [문서 프레이밍·종합(-> DOC-LEAD), 정보구조(-> DOC-IA), 다이어그램(-> DOC-VISUAL)]
|
||
methods:
|
||
- method-id: technical-writing
|
||
applies-when: { task-types: [technical-writing, documentation] }
|
||
required-inputs:
|
||
- { artifact-type: doc-frame, from-role: DOC-LEAD, from-method: frame-docs, required-state: Accepted }
|
||
workflow:
|
||
- step-id: write-typed
|
||
objective: Diátaxis 유형 고정(한 페이지=한 목적) + one-idea-per-section·lead sentence first 로 초안
|
||
required-output: draft
|
||
- step-id: dogfood-edit
|
||
objective: active voice·용어 일관성 self-edit + dogfooding 으로 재현성·모호한 대명사 제거 후 doc-content
|
||
required-output: doc-content
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: reproducible, criterion: 절차가 재현 검증되고 한 페이지=한 목적이 지켜짐, reviewer-role: DOC-WRITER }
|
||
decision-rules:
|
||
- 튜토리얼/how-to/reference/explanation 을 섞지 않음
|
||
evidence-policy:
|
||
- 문서는 재현 테스트·독자 피드백·style guide 준수에 접지
|
||
output-artifacts: [doc-content]
|
||
handoff-contract:
|
||
- edge-id: writer-to-lead
|
||
to: { role-id: DOC-LEAD, method-id: synthesize-docs }
|
||
artifact-type: doc-content
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- 재현성·목적 단일성을 지켰는가
|
||
working-method:
|
||
- audience·scope 문장을 페이지 상단에 먼저 명시하고 그 독자의 사전지식에 맞춰 서술 수준을 조정한다.
|
||
- Diátaxis 분류 먼저 — 튜토리얼/how-to/reference/explanation을 섞지 않고 한 페이지=한 목적.
|
||
- one-idea-per-section / lead sentence first — 단락 첫 문장에 핵심, 절차는 numbered list·표로.
|
||
- active voice·short sentence·용어 일관성(Google/Microsoft style)으로 초안을 self-edit한다.
|
||
- docs-as-code — Markdown+Git+정적 사이트, PR 리뷰·CI 린트·미리보기로 개발자와 공동 소유.
|
||
- 초안을 실제로 따라 해보며(dogfooding) 재현성·모호한 대명사·idiom을 제거한다.
|
||
key-frameworks:
|
||
- Diátaxis
|
||
- docs-as-code (Git/Markdown/static site + CI)
|
||
- Google Technical Writing (Tech Writing One/Two)
|
||
- Microsoft Writing Style Guide
|
||
- Write the Docs 관행
|
||
- topic-based authoring
|
||
evidence-they-use:
|
||
- style guide·용어집, doc-type taxonomy
|
||
- 독자 피드백·지원 티켓
|
||
- 재현 테스트 결과(코드·절차 실행)
|
||
- readability·PR 리뷰 코멘트
|
||
sources:
|
||
- https://developers.google.com/tech-writing/one
|
||
- https://learn.microsoft.com/en-us/style-guide/welcome/
|
||
- https://www.writethedocs.org/guide/docs-as-code/
|
||
- https://diataxis.fr/
|
||
DOC-IA:
|
||
# Contract v2(P3-B) — draft. 문서 워커: doc-frame 소비 → 정보구조 → doc-ia → DOC-LEAD.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [content inventory·audit, card sorting·tree testing(findability), 정보위계·progressive disclosure]
|
||
not-owns: [문서 프레이밍·종합(-> DOC-LEAD), 콘텐츠 서술(-> DOC-WRITER), 다이어그램(-> DOC-VISUAL)]
|
||
methods:
|
||
- method-id: information-architecture
|
||
applies-when: { task-types: [information-architecture, findability, navigation] }
|
||
required-inputs:
|
||
- { artifact-type: doc-frame, from-role: DOC-LEAD, from-method: frame-docs, required-state: Accepted }
|
||
workflow:
|
||
- step-id: inventory-audit
|
||
objective: content inventory·audit 로 중복·공백 지도화 + card sorting/tree testing 으로 멘탈모델 검증
|
||
required-output: ia-audit
|
||
- step-id: hierarchy-disclosure
|
||
objective: 정보위계(general→specific)·progressive disclosure + Every Page Is Page One 자기완결 후 doc-ia
|
||
required-output: doc-ia
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: findable, criterion: 그룹핑·라벨이 findability 테스트로 검증되고 위계가 설계됨, reviewer-role: DOC-IA }
|
||
decision-rules:
|
||
- 라벨·그룹핑은 독자 멘탈모델로 검증(추측 금지)
|
||
evidence-policy:
|
||
- IA 는 card sort/tree test·검색 로그·findability 지표에 접지
|
||
output-artifacts: [doc-ia]
|
||
handoff-contract:
|
||
- edge-id: ia-to-lead
|
||
to: { role-id: DOC-LEAD, method-id: synthesize-docs }
|
||
artifact-type: doc-ia
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- findability 를 테스트로 검증했는가
|
||
working-method:
|
||
- content inventory & audit로 현재 토픽·중복·공백을 지도화하고 gap을 식별한다.
|
||
- card sorting / tree testing으로 독자 멘탈모델에 맞는 그룹핑·라벨을 검증한다(findability test).
|
||
- 정보 위계(general→specific)를 설계한 뒤 progressive disclosure로 계층별 노출 순서를 정한다.
|
||
- Every Page Is Page One / topic-based authoring — 어느 페이지에 도착해도 자기완결적이도록 컨텍스트·앵커·상호링크 배치.
|
||
- Minimalism(Carroll) — 학습·행동에 불필요한 서술을 걷어내고 목표 달성 경로만 남긴다.
|
||
- analytics·검색 로그·findability 지표로 경로 이탈·죽은 검색어를 추적해 IA를 반복 개선한다.
|
||
key-frameworks:
|
||
- Information Architecture (Rosenfeld/Morville/Arango — organization·labeling·navigation·search)
|
||
- Progressive Disclosure (Nielsen/NN/g)
|
||
- Minimalism (Carroll)
|
||
- Every Page Is Page One / topic-based authoring
|
||
- Diátaxis (목적별 정보 공간 분할)
|
||
- Card sorting / Tree testing
|
||
evidence-they-use:
|
||
- 검색·내비게이션 analytics·검색 로그
|
||
- card sort/tree test 결과(findability)
|
||
- content inventory·audit, 독자 멘탈모델
|
||
- 정보 위계 taxonomy
|
||
sources:
|
||
- https://www.nngroup.com/videos/progressive-disclosure/
|
||
- https://en.wikipedia.org/wiki/Minimalism_(technical_communication)
|
||
- https://everypageispageone.com/2013/07/02/what-is-minimalism/
|
||
- https://www.nngroup.com/articles/information-architecture-study-guide/
|
||
DOC-VISUAL:
|
||
# Contract v2(P3-B) — draft. 문서 워커: doc-frame 소비 → C4·D2 다이어그램 → doc-diagram → DOC-LEAD.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [abstraction-first(C4 레벨)·독자 매핑, one diagram one message, D2 우선 diagram-as-code·drift 방지]
|
||
not-owns: [문서 프레이밍·종합(-> DOC-LEAD), 콘텐츠 서술(-> DOC-WRITER), 정보구조(-> DOC-IA)]
|
||
methods:
|
||
- method-id: diagram-design
|
||
applies-when: { task-types: [diagram, visualization, c4] }
|
||
required-inputs:
|
||
- { artifact-type: doc-frame, from-role: DOC-LEAD, from-method: frame-docs, required-state: Accepted }
|
||
workflow:
|
||
- step-id: abstract-first
|
||
objective: 그리기 이전에 추상화 계층(C4 레벨)·독자·전달 메시지 결정 후 C4 레벨을 독자에 매핑
|
||
required-output: abstraction-plan
|
||
- step-id: render-d2
|
||
objective: one diagram one message 로 요소 제거 + D2(1급) diagram-as-code 로 실물 렌더(Mermaid 폴백만) 후 doc-diagram
|
||
required-output: doc-diagram
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: one-message, criterion: 각 그림이 하나의 메시지·범례·방향을 갖고 D2 로 렌더·drift 방지됨, reviewer-role: DOC-VISUAL }
|
||
decision-rules:
|
||
- 도구보다 추상화 먼저 — Code(L4)는 손유지 금지(즉시 stale), 확정본은 diagram-as-code
|
||
evidence-policy:
|
||
- 다이어그램은 실제 배포 토폴로지·소스·drift 신호에 접지
|
||
output-artifacts: [doc-diagram]
|
||
handoff-contract:
|
||
- edge-id: visual-to-lead
|
||
to: { role-id: DOC-LEAD, method-id: synthesize-docs }
|
||
artifact-type: doc-diagram
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- one message·D2 렌더·drift 방지를 지켰는가
|
||
working-method:
|
||
- abstraction-first — 그리기 도구보다 추상화 계층(C4 레벨)·독자·전달 메시지를 먼저 정한다. 도구 선택은 마지막이다.
|
||
- C4 레벨을 독자에 매핑한다 — System Context(L1)=시스템+외부관계, Container(L2)=배포단위+기술스택(가장 범용), Component(L3)=내부(복잡할 때만), Code(L4)=자동생성·손유지 금지(즉시 stale).
|
||
- '"one diagram, one message"로 요소를 쳐내고 각 그림에 스코프 한 줄 제목·범례·일관된 방향·예약색을 붙인다.'
|
||
- '엔진 우선순위: 소프트웨어 아키텍처·의존성·중첩 컨테이너는 D2(레이아웃엔진 dagre/elk·테마·CI 친화, 1급). 설명·워크숍 발산은 Excalidraw(손그림). Mermaid는 최후 폴백만 — 실무급 시각자료가 아니다.'
|
||
- 'D2 관용구를 쓴다 — 중첩 컨테이너로 계층/경계를 표현, 큰 그래프는 layout=elk, 방향은 direction으로 고정, 테마로 색을 통일. render_consult가 {type: d2}를 d2 CLI로 실물 SVG 렌더한다.'
|
||
- drift 방지 — 코드 변경과 같은 PR에서 다이어그램을 갱신해 CI에서 렌더링·diff·리뷰가 되게 한다. 확정·유지 대상은 diagram-as-code, hand-drawn은 발산·워크숍에만.
|
||
key-frameworks:
|
||
- C4 model (System Context / Container / Component / Code — Simon Brown)
|
||
- 'diagram-as-code 엔진 우선순위: D2(1급) → Excalidraw(설명·손그림) → Mermaid(폴백)'
|
||
- D2 (레이아웃엔진 dagre/elk · 중첩 컨테이너 · 테마 · sketch)
|
||
- Structurizr DSL (model-first, multi-view)
|
||
- UML (sequence·class 표기)
|
||
- notation over ambiguity (범례·방향·예약색) · one diagram, one message
|
||
evidence-they-use:
|
||
- 독자 프로파일·다이어그램 목적/전달 메시지
|
||
- 실제 배포 토폴로지·컨테이너 경계·컴포넌트 인터페이스(소스)
|
||
- 엔진별 렌더링·레이아웃·버전관리 적합성(D2 우선)
|
||
- drift 신호(코드-그림 불일치·stale)
|
||
sources:
|
||
- https://c4model.com/
|
||
- https://structurizr.com/
|
||
- https://d2lang.com/
|
||
- https://plantuml.com/
|
||
DOC-EDU:
|
||
# Contract v2(P3-B) — draft. 문서 워커: doc-frame 소비 → 학습설계(인지부하·Bloom) → doc-learning → DOC-LEAD.
|
||
method-contract: { version: 2 }
|
||
role-boundary:
|
||
owns: [인지부하 관리(extraneous 제거), worked example·Bloom taxonomy, curse of knowledge 제거]
|
||
not-owns: [문서 프레이밍·종합(-> DOC-LEAD), 콘텐츠 서술(-> DOC-WRITER), 정보구조(-> DOC-IA)]
|
||
methods:
|
||
- method-id: learning-design
|
||
applies-when: { task-types: [learning-design, education, tutorial] }
|
||
required-inputs:
|
||
- { artifact-type: doc-frame, from-role: DOC-LEAD, from-method: frame-docs, required-state: Accepted }
|
||
workflow:
|
||
- step-id: manage-load
|
||
objective: extraneous load 제거(시각 잡음·장식) + worked example 앞배치(숙련자는 연습 전환) + Bloom 목표 계층화
|
||
required-output: learning-structure
|
||
- step-id: break-curse
|
||
objective: 깨끗한 환경 재현 단계 + 내부자 약어 제거 + 첫 사용자 검증(Feynman) 후 doc-learning
|
||
required-output: doc-learning
|
||
completion-gates:
|
||
judgment:
|
||
- { gate-id: load-managed, criterion: 인지부하가 관리되고 초심자가 튜토리얼을 완주할 수 있음, reviewer-role: DOC-EDU }
|
||
decision-rules:
|
||
- curse of knowledge 를 깬다 — 초심자 진입점은 항상 Tutorial(따라 완주)
|
||
evidence-policy:
|
||
- 학습은 완주율·이탈지점·반복 질문(콘텐츠 구멍)에 접지
|
||
output-artifacts: [doc-learning]
|
||
handoff-contract:
|
||
- edge-id: edu-to-lead
|
||
to: { role-id: DOC-LEAD, method-id: synthesize-docs }
|
||
artifact-type: doc-learning
|
||
required-state: Accepted
|
||
binding: same-workflow
|
||
freshness: current-usable
|
||
cardinality: "1:1"
|
||
self-check:
|
||
- 인지부하 관리·완주 가능성을 검증했는가
|
||
working-method:
|
||
- 인지부하를 관리한다 — 시각적 잡음·불필요한 링크·장식을 제거(extraneous load 제거)하고 기본값·이전 입력 재표시로 기억 부담을 시스템에 offload한다.
|
||
- worked example을 앞단에 배치한다(worked-example effect) — 단, expertise-reversal effect 때문에 숙련자 경로는 예제 대신 직접 연습으로 전환한다.
|
||
- Diátaxis로 문서 유형을 분리한다 — 초심자 진입점은 항상 Tutorial(따라 완주), 그다음 How-to·Reference·Explanation.
|
||
- curse of knowledge를 깬다 — 깨끗한 환경에서 처음부터 실행되는 단계를 쓰고 내부자 약어·암묵 가정을 제거, 첫 사용자로 검증(Feynman technique).
|
||
- Bloom's taxonomy로 목표를 계층화 — 기억·이해(개념)→적용(예제)→분석·창조(응용)로 난이도·실습을 배치한다.
|
||
- crisp example·강한 다이어그램·라이브 데모를 조합하고 "추가 설명 없이 task 완료·지원문의 감소"를 성과로 삼는다.
|
||
key-frameworks:
|
||
- Cognitive Load Theory (intrinsic vs extraneous)
|
||
- Worked Examples effect (+ expertise-reversal effect)
|
||
- Bloom's taxonomy
|
||
- Curse of knowledge
|
||
- Diátaxis (Tutorial 진입점)
|
||
- Feynman technique
|
||
evidence-they-use:
|
||
- 학습자 행동(막히는 지점·튜토리얼 완주율·이탈)
|
||
- 지원 문의·이슈·포럼 질문(반복 질문=콘텐츠 구멍)
|
||
- 깨끗한 환경 재현 테스트
|
||
- audience 세그먼트별 사전지식(초심자 vs 숙련자)
|
||
sources:
|
||
- https://www.nngroup.com/articles/minimize-cognitive-load/
|
||
- https://diataxis.fr/
|
||
- https://dl.acm.org/doi/full/10.1145/3483843
|
||
- https://theeducationhub.org.nz/using-cognitive-load-theory-to-inform-teaching-and-learning/
|