14Start Question first / Artifact Project card + REQ/QA matrix / Decision Scope / trade-off / blocker
Planning Methods
막연한 요청, 회의 메모, 기존 문서를 목표/범위/상태/데이터/API/QA 기준으로 바꾸는 기획 작업 방식.
좋은 기획은 먼저 질문을 바꿈
개발과 QA가 바로 쓰는 표
사람 판단 지점을 분리
Method / Product / Planning기획 기준선
method v1.1 · portfolio draft
01작업 요약
막연한 요청과 흩어진 회의 메모를 개발과 QA가 바로 이어받을 수 있는 프로젝트 카드, 플로우/상태 표, REQ/QA 매트릭스로 전환합니다.
이 단계가 약하면 개발은 화면 수와 도메인 구조를 추측하게 되고, QA는 수용 기준 없이 뒤늦게 예외 케이스를 발견합니다.
02입력 의존성
- 요구사항 / 회의 메모ready
목표, 사용자, 기능 후보 추출
- 도메인 / 팀 맥락ready
정책, 용어, 팀 역량, QA 성숙도
- 화면 / 기존 문서watch
상태와 권한 분기 확인 필요
- API / DB 후보watch
BE 검토 전 assumption 표시
03리스크 신호
| Signal | Severity | Meaning | First response |
|---|---|---|---|
scope_mixed_with_later | high | MVP와 Later가 한 문서 안에 섞임 | Out of scope와 Decision Log를 먼저 분리 |
state_not_visible | high | 초안/제출/오류/권한 상태가 화면에 없음 | Flow & State Map 재작성 |
api_assumption | medium | AI가 API 응답 구조를 추정함 | BE cross-check 전 FE 전달 금지 |
qa_gap | medium | 성공 케이스만 있고 실패/예외가 없음 | REQ별 QA 뼈대 추가 |
04반복 절차
프로젝트 카드 고정
요청이 들어온 첫 단계누가, 어떤 문제를, 이번 릴리즈에서 어디까지 해결하는지 한 장으로 정리합니다.
목적주요 사용자핵심 기능 3개Out of scope성공 기준플로우와 상태 작성
개발 범위를 추정하기 전사용자 흐름과 주요 상태 전환을 먼저 보여줘 화면 수와 권한 분기를 상상 가능하게 만듭니다.
사용자 플로우상태 목록상태 전환권한 표REQ/QA 매트릭스 생성
개발 핸드오프 전기능 설명을 ID 기반 표로 쪼개고 수용 기준과 QA 시나리오 초안을 연결합니다.
REQ ID우선순위수용 기준QA 성공/실패/예외05역할 분담
| Role | Primary work | Handoff |
|---|---|---|
| Planner | 목표, 범위, 질문 재정의 | Project Card / Decision Log |
| Domain Reviewer | 도메인 규칙과 예외 검토 | Domain Rule Notes |
| FE/BE | API, 데이터, 구현 난이도 검토 | API / Data Impact |
| QA | 수용 기준과 예외 케이스 검토 | QA Scenario Draft |
06완료 체크리스트
범위가 한 문장으로 읽힘
사용자, 문제, 이번 릴리즈 범위, 안 하는 일이 분리되어야 합니다.
상태와 권한이 보임
정상, 빈 상태, 오류, 권한 없음, 재시도 조건이 빠지지 않아야 합니다.
표로 개발 가능
REQ, API 후보, 데이터 항목, QA 초안이 같은 ID 체계로 연결되어야 합니다.
사람 결정 항목 분리
AI가 확정하면 안 되는 비용, 보안, 정책, 운영 판단은 blocker로 남깁니다.