콘텐츠로 이동
✍️ 수정가능누구나 고쳐도 됩니다. 고치면 하단 frontmatter의 갱신일·작성자·변경요약을 남겨 주세요.작성 Claude · 2026-06-04 · v12 재편·raw 컴파일·인간화

우선순위 & 범위 의사결정

요지

d-edu PM이 "무엇을 먼저, 무엇을 자를지" 결정하는 프레임. 핵심 기준: 마일스톤은 배포 가능한 단위, 범위는 Epic 단위로 고정, 일정은 유연. 진행률이 아니라 달성률로 본다.

핵심 원칙

  1. 마일스톤 = "기능 완성" 중심 (일정 중심 X). 배포 가능한 단위로 정의.
  2. 범위는 Epic 단위로 고정, 기간은 유연. 일정 조정은 가능하되 마일스톤 내 스코프는 고정.
  3. 포함/제외를 명시한다. MVP 릴리즈 문서의 Scope 섹션처럼 포함(로그인·스터디룸·노트) vs 제외(알림·영상 업로드)를 명확히 구분 → QA 우선순위로 직결. → requirements-guide.
  4. '달성률'을 본다, '진행률'이 아니라. Task 개수가 아니라 Epic별 배포 가능 상태로 판단. 모든 Task에 Feature 필드 필수 → QA·통계·진행률의 단위. 운영은 sprint-operations.

판단 기준 · 의사결정 룰

PRD 초안은 다음 신호를 입력으로 우선순위를 정한다(S5):

입력 신호 무엇을 보나
피드백·아이디어 유저 피드백·아이디어 풀에서 페인 빈도·강도
리서치·페르소나 페르소나별 미충족 니즈
시장·경쟁 인텔 차별점이 발동하는 지점
임팩트 vs 비용 "충분한 임팩트를 내는가 / 나중에도 활용 가능한가" (설계 체크포인트)
  • 반응형처럼 고비용 작업은 비중 차등(로그인 전 우선).
  • 가설이 불확실하면 작게 실험해 게이트로 자른다(예: 6모 시즌 engagement-first 결정 → 결제 push 연기). 실험 설계는 experiment-design(→methodology-literacy).

하지 말 것 (안티패턴)

  • 일정 중심으로 마일스톤 정의 금지 — "기능 완성"이 기준이지 날짜가 기준이 아니다.
  • 마일스톤 중간 스코프 추가 금지 — 범위는 고정, 흔들리면 일정만 조정.
  • Feature 없는 Task 금지 — QA·통계·달성률 단위가 깨진다.
  • 검증 없이 고비용 작업 우선순위 상향 금지 — 작게 실험해 게이트로 자른다.

예시 · 사례

  • 좋은 예: 6모 시즌을 engagement-first로 규정하고 결제 push를 7월 중순 이후로 연기 — PMF 실험 윈도우 가설을 게이트로 검증.
  • 포함/제외 명시 예: MVP Scope = 포함(로그인·스터디룸·노트) / 제외(알림·영상 업로드) → QA 우선순위 직결.
  • 비중 차등 예: 반응형(고비용)은 로그인 전 페이지 우선, 로그인 후는 핵심 콘텐츠만.

관련