코드스테이츠| PMB 11/Review
[정리] 서비스 기획 산출물
Sutella
2022. 4. 6. 11:35
728x90
- PRD
- 서비스 정책서, 기능정의서, 스토리보드, 상세기술서, 서비스기획서, 화면 설계서, 요구사항 정의서 etc
- 서로 형태는 다르지만 만들어지는 목적은 같음: 서비스의 기능과 정책을 정의하기 위해 만들어지는 문서
- 문서들: UI 설계 이전 서비스의 용어 및 기본 운영 정책을 정의한 프로젝트 산출물
- 정책 정의를 위해 서비스 비즈니스 구조, 운영 서비스에 대한 정의가 먼저 이루어 져야 함
- 정책설정은 회사의 서비스 방향과 전략을 반영하기 때문
- 서비스 정책: 이후 화면? UI와 IT 설계의 기본 구조 결정
- 정책 마련: 비즈니스 중심 고려, 화면 UI에 대해 생각 X
- 스토리보드
- 플로우 차트: 사용자에게 앱 이동 동선/순서를 알려주는 순서도
- User Flow: 사용자 여정에 집중(↔ 플로우차트: 기능과 분기에 집중)
- Y/N를 사용해 기능의 흐름 설명, 알고리즘 그림과도 유사.
- 화면흐름도
- 디자인된 화면 전부 배치, 화살표와 기능 설명을 통해 직관적으로 설명
- 개발자가 기능을 한 눈에 볼 수는 없지만, 직관적인 의사소통은 가능
- 서비스 정책서, 기능정의서, 스토리보드, 상세기술서, 서비스기획서, 화면 설계서, 요구사항 정의서 etc
- 서비스 정책서
- 서비스에 적용될 수 있는 모든 법적 요소를 고려하여 작성된 정책 문서
- 기획된 서비스의 법적 가능 여부, 이슈, 규제 제한 등 관련 법령에 대한 정리
- 외부 환경 요인 및 경쟁사 분석, 타사 정책, 차별화 전략 등 설정
- 프로젝트의 규모와 비용, 내부 개발 인력 등 전반적인 내용
- 정보 계층구조도 (IA)
- 서비스의 구성, 기능의 구현 화면을 나타내는 도구
- 서비스의 복잡한 구조의 틀 → 디자이너와 개발자가 작업할 수 있도록 만든 문서
- IA는 사용자, 콘텐츠, 시나리오를 고려하여 작성
- 사용자: 기존 사용자의 경험을 분석하여 설계, 사용자의 서비스 진입한 목적과 패턴을 분석 → 편의를 고려하여 구성을 설계
- 콘텐츠: 콘텐츠 구성에 있어, 공급자/사용자 중심인지를 결정하여 구조 만들기
- 시나리오: 정보의 시나리오가 어떠한 방식으로 전달되어야 하는지를 고려하며 정보 구조도 설계
- 기능 정의서
- 개발자에게 기획한 기능을 구현해 달라고 요청하는 문서
- 기획자가 만든 '무엇(기능)'을 '어떻게 만들어 하는지(개발로 구현)'에 대해 정리
- ID, 페이지, 기능 설명, 버전/수정 이력 등이 포함
- 대체로 엑셀/스프레드시트 등의 표 형태로 작성
- 화면설계서 (스토리보드)
- 와이어프레임+기능정의서 함꼐 정리한 문서
- 목저기 최종적으로 유저에게 보일 화면의 모습 작성
- 전체적인 방향성, 모든 과정에서 디테일한 부분까지 체크할 수 있도록 하는 문서
- Description 종류
- 버튼 디스크립션(Button Description): 버튼의 수행 기능, 활성화/비활성화의 상황, 버튼 컬러 변경 등 버튼에 대한 설명
- 펑션 디스크립션(Function Description): 기능에 대한 상세 설명, 아이디 입력 기능에서 제한되는 텍스트의 글자 수, 기호/숫자 사용 가능 여부, 유효성 체크 방식 등 내부적으로 동작하는 디테일한 기능 작성
- 읽기자료
- 유저 스토리
- 애자일 프로세스(Agile Process)에서 사용되는 산출 문서
- 목적: 고객의 요구사항(Epic)을 바탕으로 제품팀의 '공유된 이해' 만들기
- 요구사항을 가지게 된 맥락과 배경을 팀원 전체가 이해 하고, 그 요구사항을 통해 동일한 결과물을 떠올리는 것
- 애자일 프로세스에서 ‘문서 산출 최소화’라는 통념과 다르게 상당한 문서 필요(But 전통적 문서X/ 대화, 스케치, 포스트잇, 인덱스 카드 등)
- 형식 중요 X, 담겨야 할 내용 = 고객과 사용자의 묘사(ex. 퍼소나), 제품 사용 시나리오(왜 원하는지, 왜 사용하는지)
- 중요 요소: INVEST (품질을 평가하기 위한 일련의 기준 또는 체크리스트(인수 기준, Acceptance Criteria)를 작성하는 데 도움)
- 독립적인 (Independent) : 각각의 스토리는 서로 의존하지 않고 독립적
- 협의 가능한(Negotiable) : 사용자가 필요로 하는 핵심만을 포착하고 대화의 여지 남기기. 계약서처럼 작성 X
- 유용한(Valuable) : 최종 사용자에게 특정한 가치를 제공
- 추산 가능한(Estimable) : 스프린트에서 우선순위를 적용할 수 있도록 사용자의 스토리를 통해 추산 가능해야 함
- 작은(Small) : 약 3~4일 안에 완성할 수 있는 작은 작업 덩어리
- 검증 가능한(Testable) : 사용자 이야기는 미리 작성된 인수 기준을 통해 확인 가능해야 함.
- 인수 기준
- 유저 스토리가 제대로 구현되었는지 검증하기 위한 체크리스트
- 프로젝트/제품이 달성해야 하는 사전 설정된 기준과 요구사항
- 인수 기준
- 요구사항 정의 (명세)서, (SRS, Software Requirements Specification)
- 워터폴 프로세스에서 '외주 업체'에서 고객(사)의 요구사항을 수집하기 위해 작성되던 문서
- 고객/이해관계자의 요구사항을 수집해 문서로 작성한다는 부분에서 유저 스토리와 일맥상통
- 개발 요구사항을 정리한 구조화된 문서 → PM과 서비스 기획자가 전부 알아야 함
- 정해진 형식 X, 조직 내 규칙에 따라 작성하지만 대체로 표(엑셀) 형태
- 요구사항 주체, 요구 기능 이름, 기능 상세 등 기입
- 기능 정의서: 실제 개발될 기능을 하나하나 구체적으로 기입
- 요구사항 정의서: 개발을 원하는 요구사항을 포괄적으로 기입
- 유저 스토리
- 읽기자료
- PRD
- 우리가 이 기획을 왜 해야 하나요? (WHY)
- 이 문제는 어떻게 접근해야 하나요? (HOW)
- 가장 적합한 솔루션은 무엇인가요? (WHAT)
- 목적: 올바른 제품을 만들고 사용자에게 잘 전달하기 위한 방향으로 팀이 함께 나아가도록 하는 것
- 작성 내용
- 요약과 배경(Summary and Background): 문제가 무엇이고, 왜 중요한지. 이 기획의 중요성을 강조하기 위한 사업 지표나 유저 리서치 내용 또는 여러 다른 인사이트 포함 가능
- 주요 사용자(Target Users): 이 해결책은 누구를 위한 것인가? 유저들은 왜 중요하며, 이들의 불편함을 우선순위를 높여 해결해야 하는 이유는?
- 핵심 사용자 여정(Critical User Journeys, CUJs): 문제를 해결했을 때 사용자가 얻을 수 있는 것은? 구체적인 솔루션보다는 사용자 니즈에 집중해서 작성. ——-피드백——
- 기능적 요구사항(Functional requirements): 솔루션의 세부 기획 작성. PM으로서 기능적 요구사항을 상세히 쓰는 것은 중요하지만, 특정 솔루션을 너무 강요하지는 않도록 주의.
- 관련 문서(Supporting documents): 솔루션의 세부 인터랙션 디자인이나 기술적 구현에 대해서는 디자이너, 엔지니어와 논의. PRD에 관련 UX 플로우 또는 개발 설계 문서를 추가적으로 연결해 참고할 수 있도록 해야함.
- 배포 계획(Go-to-market): 해당 기능 출시와 관련된 여러 고려사항과 출시 후 마케팅, 영업, CS 등 고객과 맞닿아있는 조직이 예상하고 있는 바에 대해 작성
- 주의 사항
- 문제에 집중
- 한 눈에 쉽게 읽을 수 있도록 구조화
- 와이어프레임, 도식, 표 등 활용
728x90