26.02.03 TIL 58: 본캠프 48일차- Data Driven 기획 강의 +팀 논의

📌 오늘의 진도:

완료 100%

1. Data Driven Project 강의 수강 Chapter 3

2. 관심 도메인 & 개인 역량 공유

3. 아티클 카타 정하기

4. 개인 공부

 

오늘의 인사이트  👀

오늘은 강의 챕터 3를 들으며 이제껏 배워왔던 기획 과정 전체를 총정리 할 수 있었던 시간이 있어서 다시 한번 remind & review 할 수 있어서 좋았던거 같다. 

강의에서 흥미로웠던 것은 튜터님께서 "절대라는건 없다" 그래서 항상 유연하게 일 하는 것이 중요하다고 몇 번을 강조를 하셔서 실무에서는 이런 일들이 종종 있다는 것을 추측 할 수 있었다. 예를 들어 개발자가 우리는 mobile에서만 할거에요 라고 하고 나중에 와서 web으로도 부탁 하시는 경우가 종종 있다고 한다. 그러므로 그런걸 유연하게 대처를 해야한다고 말씀을 하셨는데.. (한 수 앞을 내다봐야한다!!) 그 범위를 어디에서부터 어디까지 설정을 해야하는지 감이 아직 잘 오지는 않는다. 요 부분은 튜터님께 여쭤볼 예정이다!

 

<강의에서>

강의를 수강하면서 생긴 질문:

질문: 오늘 강의 챕터 3를 수강하면서 백오피스 기획 실습에 관하여 윤정 튜터님께서 말씀을 해주셨습니다. 거기에서 언제든 요구사항이 변경될 수 있는 점을 감안해서 유연하게 화면 기획하라고 말씀을 해주셨는데 제가 이해한 바로는 한 수 앞을 내다보고 미리 준비하라는 말씀이신거 같아요. 제 질문은 이 유연하게의 범위가 어느정도인지 감이 잘 안와서 여쭤보러 왔습니다. 예를 들어 개발자가 디바이스 설정을 모바일로만 한다고 하셨다가 몇 일? 주? 뒤에 pc도 함께 하자는 상황이라면 제가 그 얘기를 듣기 전에  pc도 해야한다고 예상을 해야하는 부분인데 이걸 어떻게 준비 및 유연하게 대처를 할 수 있는지 궁금합니다. 

 

답변: 예측하기 어렵다. 이것또한 경력이 쌓이면서 자연스럽게 생각이 되는 부분인거 같다! 

 

챕터 3-1: 기획 과정 전체 총정리

1-1 요구사항 분석 및 요구사항 정의서(PRD)

❗ 요구사항 분석은 프로젝트나 제품 개발의 핵심 과정으로, 개발팀이 어떤 제품을 만들 것인지를 명확히 정의하는 단계입니다.
- 요구사항을 구체적으로 파악하고,
- 이를 문서화하여
- 각 팀(개발, 디자인, QA 등)이 동일한 목표를 가지고 작업할 수 있도록 공유합니다.

 

PRD는 요구사항을 체계적으로 정리한 문서로, 프로덕트 개발 과정에서의 지침서 역할을 합니다.
이 문서가 잘 작성되면 개발 팀은 물론, 이해관계자들 간의 커뮤니케이션을 원활히 하고 프로젝트 진행이 명확해집니다.

 

1-2 요구사항 정의서(PRD) 작성 방법

제품이나 서비스에서 제공해야 할 구체적인 기능들을 나열합니다.

• 기능 이름 : 기능의 이름
• 기능 설명 : 해당 기능이 어떤 역할을 수행하는지 설명
• 우선순위 : 해당 기능의 중요도 (예: 필수, 권장, 나중에 추가 가능)
• 구현 기준 : 기능이 어떻게 작동해야 하는지에 대한 세부적인 설명

2-1. 정보 구조도(IA, Information Architecture)

❗ 시스템, 웹사이트 또는 애플리케이션의 구조와 기능을 명확하게 정의한 문서입니다.

이 문서는 개발자, 디자이너, 그리고 다른 팀원들이 시스템이 어떻게 동작해야 하는지에 대한 공통된 이해를 가질 수 있도록 도와줍니다. 개발기능 정의서의 목적은 프로젝트의 요구 사항을 구체적으로 정의하고, 각 기능이 어떻게 구현되어야 하는지에 대한 구체적인 방향을 제시하는 것입니다.

 

2-2 정보 구조도 작성 방법

기능 목록 작성 : 시스템 내에서 제공할 모든 기능을 목록화합니다. 카테고리 및 메뉴 구조 설계 정보 구조도를 그리기 위해서는 기능을 논리적으로 분류하고 계층화하는 작업이 필요합니다.

• 카테고리화 : 각 기능을 관련 있는 그룹으로 묶습니다.
• 계층 구조 : 각 카테고리 내에서 세부 항목들을 어떻게 배치할지를 정합니다.

가장 중요한 정보는 상위 카테고리에 배치하고, 덜 중요한 정보는 하위 카테고리로 배치합니다.

3-1. 서비스 정책서

❗ 서비스 개발이나 개선 과정에서 기능에 대한 명확한 정의와 구현 기준을 설정하여, 관련 팀들이 일관되게 작업할 수 있도록 하는 문서

 

3-2. 서비스 정책서 작성 방법

서비스 정책서의 목적 정의 → 정책 범위 설정 → 정책의 주요 항목 및 세부사항 작성 → 정책 문서화 및 공유 → 정기적인 검토 및 업데이트

 

4-1. 에러케이스

❗ 에러 케이스는 서비스나 시스템에서 오류가 발생한 경우에 대해 어떤 식으로 처리할지, 어떤 메시지를 사용자에게 전달할지 등을 미리 정의해 놓은 문서입니다.

 

4-2 에러케이스 작성 방법

에러 케이스 정의 → 에러 발생 조건 명시 → 에러 메시지 작성

 

5-1. 상세 기능 명세서 및 유저 플로우

❗ 상세 기획은 프로젝트의 구체적이고 실행 가능한 계획으로, 프로젝트의 목표, 요구 사항, 일정, 기능 설계(명세) 등을 정의하는 과정입니다.

❗ 유저 플로우 & 기능 명세서

유저 플로우 : 사용자가 서비스를 이용할 때의 전체적인 경로와 단계별 상호작용을 명확하게 정의

기능명세서 : 각 기능을 상세히 설명하는 문서 (기능의 목적, 동작 방식, UI 요소, 제약 사항 등을 구체적으로 작성하여 협업자가 정확히 이해하고 구현할 수 있도록 작성) 

 

5-2. 상세 기능 명세서 및 유저 플로우 작성 방법

상세 기능 명세서 : 각 기능이 어떻게 동작해야 하는지, 입력 값, 출력 값, 상호작용을 구체적으로 정의

기능 이름 / 기능 설명 / 입력값 / 출력 값

 

유저 플로우 :

1. 목표 정의 : 목표를 달성하기 위한 필수 단계를 정의
2. 시작점 설정 : 유저 플로우의 시작점을 사용자가 서비스에 들어오는 지점으로 설정
3. 단계 나열 : 사용자가 목표를 달성하기 위한 단계별 흐름을 나열
4. 결정 노드와 분기점 추가 : 사용자가 선택할 수 있는 여러 경로가 있는 경우, 분기점을 추가
5. 시각적으로 표현 : 흐름을 도식화

<팀 논의>

팀원들과 함께 점심을 먹고 곧 있을 MVP 프로젝트에 관해서 관심 도메인을 공유해서 서로의 대한 이해도가 더 높아져서
프로젝트 시작 전의 관심 도메인 공유를 하는게 정말 좋았던 방법이였던거 같습니다. 강추 강추!!!

그리고 자신의 강점이랑 서로의 대한 강점을 같이 공유를 하는데 자존감도 올라가고 좋았던 시간이고 서로가 서로의 대한 강점을 얘기하면서 프로젝트에 대한
분배에도 도움이 된거 같다.