plan-doc

name	plan-doc
description	제안서·요구사항 정의서·정책/운영 문서·리서치 보고서 등 PRD가 아닌 기획 문서를 유형별 표준 구조로 초안 작성한다. "제안서 써줘 / 요구사항 정의서 만들어줘 / 운영 정책 문서 초안 / 리서치 보고서 정리해줘 / 기획 문서 작성 도와줘"라고 할 때 트리거. (PRD는 [[write-spec]]로)

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

기획 문서 작성 (plan-doc)

PRD 말고 나머지 기획 문서 전부를 다룬다. 아무 템플릿이나 갖다 붙이지 말고, 유형부터 판별하고 그 유형에 맞는 구조로 초안을 쓴다.

왜 유형 판별부터 하나

문서 유형이 다르면 읽는 사람도, 필요한 내용도 다르다. 제안서에 요구사항 목록만 잔뜩 있으면 결재가 안 나고, 정책 문서에 설득 문구만 있으면 실무자가 못 쓴다. 먼저 물어라: "이거 누가 읽고, 읽고 나서 뭘 하게 하고 싶어요?"

유형별 표준 구조 (각 섹션 옆에 '왜' 한 줄)

• 제안서: 배경/문제 → 제안 개요 → 기대효과 → 실행안·일정 → 예산/리소스 → 리스크. (왜: 의사결정자의 "할까 말까"를 돕는 문서라 근거와 효과가 핵심)
• 요구사항 정의서(SRS): 목적/범위 → 이해관계자 → 기능 요구사항 → 비기능 요구사항 → 제약/가정 → 용어. (왜: 개발/디자인이 오해 없이 구현하도록 "무엇을"을 못 박는 문서)
• 정책/운영 문서: 목적 → 적용 범위/대상 → 원칙·규칙 → 프로세스(절차) → 예외 처리 → 담당/개정 이력. (왜: 실무자가 상황이 오면 바로 찾아 쓰는 문서라 절차와 예외가 생명)
• 리서치 보고서: 요약(핵심 결론) → 배경/목적 → 방법 → 발견 → 시사점 → 다음 액션. (왜: 바쁜 사람이 결론부터 보고 판단하도록 top-down)

작성 원칙 (공통)

1. 왜를 사람 말로: 각 섹션은 "이게 왜 필요한지"를 한 줄로 붙여라. 형식만 채운 문서는 죽은 문서다.
2. 근거·출처: 수치·주장에는 출처를 달아라. 없으면 지어내지 말고 그 자리에 **"확인 필요"**로 표시. 리서치 보고서는 특히 방법·표본을 명시.
3. 반자동: AI가 초안까지, 결정은 사람이. 초안은 "여기까지 채웠고 이건 빈칸"이라고 솔직하게 넘겨라.
4. 코칭(신입이면): 왜 이 유형인지, 어느 섹션이 결재를 가르는지 짚어줘라.

참고

• 유형 판별은 위 "유형별 표준 구조"를 기준으로 한다(제안서·기획서·리서치·보고서·회의자료 등). 애매하면 사용자에게 목적·독자·결재선을 한 번 묻는다.
• 과거 문서·조직 톤: ~/.pm-copilot/data
• 완성 초안은 ~/.pm-copilot/data/docs/에 날짜-유형 이름으로 저장 제안.

흐름 예시

1) "무슨 문서예요? (제안서/요구사항/정책/리서치)" → 유형 확정
2) 유형별 구조로 빈 초안 생성, 아는 것부터 채움
3) 근거 없는 칸은 "확인 필요" 표기, 사용자에게 질문 목록 전달
4) 초안 완성 → [[ask-sunbae]]로 사수 관점 검토 제안

체크리스트 (넘기기 전)

• 유형이 맞나? 읽는 사람 기준으로 골랐나
• 모든 수치에 출처 or "확인 필요"가 붙었나
• 각 섹션에 '왜'가 있나
• 결정이 필요한 빈칸을 사용자에게 명확히 넘겼나

관련: [write-spec] · [[research-synthesis]](리서치 원자료 정리) · [[decision-log]](결정 기록) · [ask-sunbae]

🎨 Figma 연동 (커넥터 figma 연결 시)

• 기존 Figma 디자인·기획 자료를 열람해 문서 근거로 삼는다(get_design_context). 시각 산출물은 [[mockup]]·[[simple-design]]로.
• 디자인과 문서가 어긋나면 최신순 기준 — 단 권한상 기획자는 문서 쪽만 현행화하고, 디자인 수정은 디자이너에게 요청.