오늘의 퀴즈 정리) PM 역할+제품 제조 과정 순서+협업 관계 이해+애자일 개발 용어 이해

퀴즈... 원래 5개만 푸는 거였는데 생각보다 재밌어서 13개나 풀었다.

답변받은 내용을 내 방식대로 정리하였다.

 

추가 활동

• 아티클 카타 : 기획자로서 알아야 하는 앱 개발 유형

 

표지로 생성한 이미지(게시글 주제와 키워드 입력 후 이미지 생성)

 

 

---

 

오늘의 퀴즈 정리

 

 

▪️스크럼(Scrum) : 짧은 주기로 빠르게 만들고 검증하며 개선하는 협업 방식

역할	주요 역할
PO(Product Owner)	제품 방향성 설정, 백로그 관리, 우선순위 결정
스크럼 마스터	스크럼 프로세스 관리 및 협업 지원
개발팀	개발, 디자인, QA 등 실제 제품 구현
→ 실무에서는 회사 규모나 조직 문화에 따라, PM이 PO 역할을 겸하거나 스크럼 마스터가 따로 없는 경우도 많다

 

 

▪️스프린트(Sprint) : 스크럼에서 반복적으로 진행되는 짧은 개발 주기

• 짧은 기간 동안 목표를 정하고 집중적으로 개발하는 한 사이클(보통 1~4주 단위로 진행)
  • 빠르게 만들고 → 빠르게 검증하고 → 계속 수정

 

▪️데일리 스크럼(Daily Scrum) : 매일 15분 내외로 진행되는 짧은 미팅

• 어제 뭘 했는가?(작업 진행 상황 공유)
• 오늘 무엇을 할 것인가?(우선순위 및 계획 공유)
• 현재 막히는 문제는 무엇인가?(장애 요소 빠른 해결)
  → 단순 보고 X, 팀 상태 공유/병목 발견/빠른 협업을 위함(회의가 불필요하게 길어지면 집중력 ↓, 생산성 ↓)

 

▪️제품 개발 프로세스

일반적인 흐름(순서대로)
아이디어 발굴	문제 발견 및 아이디어 도출
시장 조사	타깃 사용자 및 경쟁 시장 검증
기획	목표, 기능, 방향성 정의
설계	UI/UX, 시스템 구조, 데이터 구조 설계
개발	실제 기능 구현
테스트	오류 및 품질 검증
출시	사용자 대상 공개
운영 및 개선	데이터 기반 유지보수 및 개선
→ but, 실무에서는 위 과정이 한 번에 끝나는 경우보다 개발 중 기획 수정/테스트 중 UX 변경/출시 후 방향 수정이 반복적으로 이루어지는 경우가 많음. 특히 최근 서비스들은 '완벽하게 만들어 출시'보다는, '빠르게 검증하고 개선'하는 방식을 더 선호하는 흐름에 가까운 것 같다. (시장 흐름과 환경 변화 속도가 너무 빠르기 때문이 아닐까)

 

 

▪️설계 단계가 중요한 이유 : 개발 전에 전체 구조를 먼저 정리하는 과정

설계 요소	UI/UX 설계	데이터 구조 설계	시스템 구조 설계
예시	사용자 화면 흐름	DB 구조 및 데이터 흐름	서버/API 구조

• 명확한 설계 없이 개발할 경우 발생하는 문제
  • 방향이 계속 흔들릴 수 있음
  • 협업 기준이 달라질 수 있음
  • 유지보수가 어려워질 가능성 有
    → 규모가 커질수록, 이해관계자(PM, 개발자, 디자이너, QA) 간 같은 기준을 공유하는 게 중요

 

▪️PM과 개발자의 협업

• 기술 제약까지 함께 이해하며 의사결정해야 함
  • 구현 가능한 일정인지
  • 개발 난이도가 어느 정도인지
  • 비용 대비 효과가 적절한지
    → 위 내용을 종합적으로 고려해야 함

GOOD 협업 방식	BAD 협업 방식
기술 제약 이해	일방적인 기능 요구
현실적인 우선순위 조율	일정 무시
개발자 의견 반영	협업 없는 강요

 

 

▪️PM과 디자이너의 협업

• PM이 방향성과 우선순위를 제시한다고 해서 디자인의 모든 세부사항을 직접 결정하는 것은 아님
  
  • 사용자 문제 정의, 비즈니스 목표, 우선순위 → 협업 필요(같은 목표 공유 중심)

 

▪️PM과 데이터 분석가의 협업

• 직감보다는 근거 기반 의사결정 필요
• 특히, 퍼널 데이터, 사용자 행동 로그 → 직관만으로 판단 X
• but, 데이터 역시 절대적인 정답이라기보다는, 실제 사용자 맥락과 함께 해석하는 시각도 필요

데이터 기반으로 확인하는 요소	사용자 행동 패턴	제품 성과 지표	가설 검증
예시	어디서 이탈하는가	전환율, 리텐션	실제 개선 효과 확인

 

 

▪️PRD/로드맵/요구사항 정의서 차이

문서	핵심 질문	주로 담는 내용
PRD	왜 만드는가?(방향성과 목적)	문제 정의, 목표, 사용자, 핵심 기능, KPI
로드맵	언제 무엇을 할 것인가?(우선순위와 일정)	방향성, 우선순위, 일정, 마일스톤
요구사항 정의서	무엇을 어떤 조건으로 만들 것인가? (실제 구현 기준)	기능/비기능 요구사항, 제약사항, 인수 기준 → 개발/디자인/QA가 공통 기준으로 삼는 문서
→ 결국 세 문서는 서로 역할이 다르며, 함께 제품 개발의 전체 흐름을 구성하는 구조

 

 

▪️기능적 요구사항/비기능적 요구사항 차이

구분	의미	예시
기능적 요구사항	시스템이 무엇을 해야 하는가	회원가입, 검색, 결제
비기능적 요구사항	어떤 품질로 동작해야 하는가	응답 속도, 보안, 안정성
제약사항	개발 시 지켜야 하는 조건	예산, 일정, 특정 기술 사용
인수 기준	어느 수준이면 완료로 볼 것인가	결제 성공 시 주문 내역 반영
→ 협업 과정에서 모두가 같은 기준을 바라보기 위한 도구(같은 목표 지향)

 

 

---

 

 오늘의 KPT 회고

 

Keep	• 퀴즈를 최소 개수만 풀지 않고 흥미가 생긴 주제를 추가적으로 더 학습한 점 • 기능 자체보다 우선순위, 데이터 기반 판단, 협업 구조 같은 실무 흐름 중심으로 이해하려 한 점
Problem	• PRD/로드맵/요구사항 정의서처럼 문서 구조는 이해했지만, 실제 실무 상황에서 어떤 흐름으로 작성되고 수정되는지는 추가 학습이 필요함 • 스크럼/애자일 방식 역시 개념은 이해했지만, 실제 프로젝트 일정 관리나 협업 상황에 적용하는 경험은 부족하다고 느낌
Try	• 유저플로우, 퍼널 분석, 우선순위 설정 같은 PM 실무 사고를 계속 연습해보기 • 추후에는 오늘 배운 내용(PRD 작성, 요구사항 정의, 우선순위 설정, Quick Win 도출 등)을 직접 적용해보며 학습/체화하기 • 왜 필요한 기능인지, 누구의 문제를 해결하는지, 지금 꼭 필요한 기능인지 → 먼저 고민하기