요구사항 작성 가이드¶

기획 문서(PRD·FDD)를 어떻게 쓰는지에 대한 기준이다. 슬랙·지라·노션으로 비동기 협업하는 전제라, 회의 없이 문서만 보고도 개발·디자인·QA가 작업할 수 있는 수준을 목표로 한다.

PRD vs FDD¶

PRD (Product Requirement Document): 왜, 어떻게 제품을 만들지를 담는다. 상위 기획 단계에서 풀 문제를 정리하고 그것을 왜 지금 다뤄야 하는지를 구체화한다.
FDD (Feature-Driven Document): 기능 중심 명세서다. 애자일 환경에서 모든 기능의 정의·예외·정책·완료 조건을 한 곳에 모아 관리한다. 문서가 적다고 불필요한 게 아니라, 최소한의 공통 이해와 비동기 의사소통을 보장하는 장치다.

FDD가 가져야 할 5가지 기준¶

완결형(Self-contained) — 다른 문서 안 봐도 목적·흐름·예외·결과 이해. 방대하면 기술 문서로 분리 + 링크.
단방향 커뮤니케이션 — 추가 질문 없이 작업 가능. 시나리오를 [User] [FE] [BE] 주체별 명시.
상태 중심(State-driven) — 케이스 나열 대신 상태 전이(예: ACTIVE → LOCKED)로 정의. QA·개발 테스트 기준으로 직결.
명확한 완료 조건(DoD) — 측정 가능하게("로그인 성공 → /dashboard 리다이렉트 + 토큰 쿠키 저장이면 완료"). 기능 단위는 실행 검증, Epic 단위는 결과물 품질.
책임 단위(Owner/Trigger) — 누가 어떤 조건에서 어떤 액션을 트리거하는지 [User] [FE] [BE]로 시각 구분.

페이지 단위 명세서 17항목 (FDD 초안용)¶

기획자는 모든 페이지에 대해 다음 항목을 빠짐없이 채우고, 이 표는 그대로 개발·QA의 기준 문서가 된다.

목적 · 레이아웃 영역 · 구성요소 · 행동(Interaction) · 상태(State) · 권한 · 화면 전환 · 디자인 참고 · 예외 시나리오 · 전제 조건 · 결과/출력 · 데이터 매핑 · 메시지 스펙 · 트래킹 이벤트 · 접근 경로 · QA 테스트 포인트 · 정책/제약.

기획·로직 설계 체크포인트¶

빠뜨리기 쉬운 항목들이다.

정보량: Ideal / Min / Max / None (+스켈레톤 여부)
화면 상태: Empty / Loading / Error / Active / Inactive
버튼 상태: Normal / Rollover / MouseDown / Active
모든 접근 경로: 뒤로가기(주의) / 화면 내 모든 버튼 / 새로고침·저장 시점
고객 단계: Onboard / Nth / Landing, B2B 케이스
데이터: 트래킹 이벤트, 보관 기간, Admin 관리 항목

MVP 릴리즈 전략 문서 11항목¶

MVP 릴리즈 전략 문서에는 다음을 담는다. 개요 · 릴리즈 범위(포함/제외) · 주요 일정(D-Day +n) · 환경 구성(dev/stage/prod) · QA 전략(P0 100%/P1 80%) · 배포 전략(롤백·버전 태그) · 모니터링·알림 · 커뮤니케이션 플랜 · 성공 지표(이벤트 트래킹 기반) · 리스크·대응 · 후속 계획(v1.1/v2.0). 대부분의 책임자는 PM이다.

마일스톤·Feature 운영 (지라 연동)¶

Epic → Task 구조. Story 안 씀 — Task의 Feature 필드가 Story 역할. 모든 Task는 Feature 필수.
마일스톤은 일정이 아니라 배포 가능한 단위로 정의. 범위는 Epic 단위 고정, 기간은 유연.
PM은 '진행률'보다 '달성률'(Epic별 배포 가능 상태) 관리.
자세한 마일스톤 절차·스프린트 운영은 sprint-operations.

지라 RFP·티켓 작성 (기획 → 티켓 진입)¶

요구사항은 지라 티켓으로 흘러야 공식적으로 반영된다. 구두·슬랙·노션으로 던진 제안은 RFP로 등록되기 전까지는 반영되지 않는다.

RFP (기획 이전 제안서)¶

신규 기능·개선·리서치 제안의 무→유 검토 흐름. 아이디어 → 논의 → Approved → Epic 편성으로 다음 MS 후보군이 된다.

제목: Prefix 필수 (예 [Feature] 강의 평가 기능 제안).
본문 구조: 제안 배경(Background) · 제안 내용(Proposal) · 기대 효과(Expected Impact) · 참고 자료(IA·Figma·벤치마킹).
유형: Request / Proposal / Research. 상태: Draft → Reviewing → Approved / Pending / Dropped(리오픈 가능).
승인 처리: Approved만 다음 MS 기획 회의 검토 → Epic 승격(RFP 링크로 추적성 유지). 등록 전 유사 RFP를 JQL로 검색해 중복 방지.

티켓 구조 (Epic / Task / Bug)¶

Epic = 마일스톤(1:1) — 제목은 MS명 그대로(MS2(MVP-B)). 해당 기간의 모든 Task/QA/Bug를 연결, 회고·QA 결과를 Epic 단위 집계. 본문: 목표 · Feature 목록 · 완료 기준(예 Feature별 QA Pass 80%) · 관련 문서 · 비즈니스 가치.
Task — Epic 내 실행 단위. 제목에 [FE]/[BE]/[DOCS]/[QA] Prefix. Feature 필드 필수(도메인 지정 — Story 대체). 본문: 목적 · 결과물 · 완료 기준(QA/코드리뷰로 판정 가능) · Epic·Feature 연결 · 우선순위.
Bug — QA 발견 문제. 제목 [Feature명] + 구체 증상. 재현 절차 / 기대 결과 / 실제 결과 / 실행 환경(OS·브라우저·API버전) 필수 + 스크린샷·콘솔 로그 첨부. Epic·Feature·관련 Task와 양방향 링크.

공통 원칙: 모든 티켓은 Epic 연결, 연관 Task/QA/Bug는 양방향 링크로 추적성 유지. 형식보다 맥락 전달이 우선.