<aside>

📄 기능명세서 작성 원칙 — 개발팀 핸드오프용

1. 문서 유형
   • 경량 기능명세서 (현재)
     • 핵심 MVP 단계에서 사용
     • 기능 목적·트리거·동작 흐름·예외 처리 등 행위 중심 정보만 담아 빠르게 협업
     • API·DB·캐싱 등 미확정 기술 사양은 빈 섹션으로 두고 추후 확장 예정
   • 풀스펙 기능명세서 (핵심 MVP 개발 이후)
     • 제품이 정식 개발 단계에 진입한 뒤, QA·개발·디자인·기획 전 부서의 싱크를 맞추기 위해 작성하는 완전 사양서
     • 세부 API 명세, DB 구조, 캐싱, 성능 지표, 테스트 케이스까지 포함
2. 핸드오프 시 유의점
   • 경량 명세서는 “지금 구현에 필요한 최소 정보”만 포함해 속도를 확보
   • 기술 스펙이 확정되는 기능부터 풀스펙으로 단계적 확장
   • 대접두사 - 세부 기능 - 3자리 일련번호 체계를 유지해 버전·릴리즈 관리가 용이하도록 함
   • 최신 수정 사항을 쉽게 확인할 수 있도록 최종 수정일 기준 최신순으로 정렬
3. 상태 설정 원칙
   • 기획 팀 영역 : 기획 팀이 기능명세서를 작성하거나 피드백을 반영하여 수정 중일 때 다음 2가지 상태로 설정합니다.
     • 작성 중 : 기능명세서 초안 작성 시 설정
   • 공통 영역 : PM, 기획&디자인 팀, 개발팀 모두가 설정할 수 있는 상태입니다.
     • 공유 중(기본) : 작성, 수정, 피드백 작업이 모두 끝난 후 기능명세서 확인 및 공유 상태일 때 설정
     • 수정 중 : 기능명세서 일부 내용 수정 중일 때 설정
     • 피드백 진행 : 특정 내용에 대해 피드백을 요청한 상태일 때 설정

요약 현재는 경량 기능명세서로 개발 속도를 우선하고, 추후 풀스펙으로 자연스럽게 업그레이드한다. 최종 수정일 기준 최신 순으로 정렬하고, 기능명세서 업데이트 상황에 따라 “상태” 속성을 변경하여 상황을 공유한다.

</aside>

Untitled