03 하네스 Markdown
Planning Methods
막연한 요청, 회의 메모, 기존 문서를 목표/범위/상태/데이터/API/QA 기준으로 바꾸는 기획 작업 방식.
한눈에 보기
막연한 요청, 회의 메모, 기존 문서를 목표/범위/상태/데이터/API/QA 기준으로 바꾸는 기획 작업 방식입니다.
- Start: Question first — 좋은 기획은 먼저 질문을 바꿈
- Artifact: Project card + REQ/QA matrix — 개발과 QA가 바로 쓰는 표
- Decision: Scope / trade-off / blocker — 사람 판단 지점을 분리
질문에서 범위로
기획의 첫 단계는 문서 페이지를 늘리는 일이 아니라 질문을 바꾸는 일이다. “AI가 기획서를 써줄 수 있는가”보다 “이 기능의 목표, 범위, 안 하는 일, 성공 기준이 개발/QA 관점에서 충분히 명확한가”를 먼저 본다.
- 사용자와 이해관계자 분리
- 해결할 문제와 이번 릴리즈 범위 고정
- Out of scope와 Later 항목 분리
- 러프해도 측정 가능한 성공 기준 기록
흐름과 상태
기능 설명만으로는 구현이 시작되기 어렵다. 사용자 플로우, 주요 상태, 상태 전환, 권한별 허용/차단 행동을 먼저 보이면 개발자는 도메인 구조와 화면 수를 빠르게 상상할 수 있다.
- 사용자 흐름: 로그인 → 목록 → 상세 → 작성 → 저장
- 상태 목록: 초안, 제출, 진행중, 확정, 삭제됨
- 권한 표: STUDENT, TEACHER, ADMIN별 조회/작성/수정/삭제
- 예외 상태: empty, loading, error, forbidden, retry
표 단위 스펙
개발과 QA가 바로 쓰는 기획은 문장보다 표 단위가 강하다. 요구사항 ID, 설명, 역할, 우선순위, 입력/출력, 수용 기준, QA 시나리오 초안을 같은 묶음으로 관리한다.
- REQ 리스트: ID, 기능 설명, 역할, 우선순위, 수용 기준
- API 후보: 리소스, 메서드, 파라미터, 응답 구조
- 데이터 항목: 민감도, 소유 관계, 보존/삭제 기준
- QA 뼈대: 성공, 실패, 예외, 권한 케이스
AI 초안과 사람 리뷰
AI는 초안을 빠르게 만들고 사람은 범위와 현실성을 자른다. 중요한 것은 AI가 만든 문서를 그대로 채택하는 것이 아니라, 근거와 화면과 API와 사람 검토 기준이 같은 버전 관리 흐름에 남는 구조다.
- AI 생성: 기능 후보, 플로우, REQ 표, QA 초안
- 사람 판단: MVP 범위, 보안/운영 기준, trade-off, blocker
- 공유 단위: 프로젝트 카드, 플로우/상태 표, REQ/QA 매트릭스, Decision Log
연결 문서
- Planning Generation Harness Loop — 기획 초안을 증거 기반 루프로 검증하는 구조
- Design Methods — 기획을 화면 구조와 상태 설계로 넘기는 방식
- Work Method Library — 직무별 방법론 허브