🗂️ 프로덕트 매니지먼트 개론 (3) - 프로덕트 개발 / PM의 업무 / 애자일
PM의 좋은 전략도 혼자서는 이뤄낼 수 없다
"협업 빈도의 차이, 다양한 이해관계자와 함께 한다"
# 개발자
- 프론트 개발자
- 백엔드 개발자
- 앱개발자
💭 PM은 눈에 보이는 것에 포커스 맞추고, 개발자는 보이지 않는 곳의 작업
# QA 엔지니어
상품의 품질 점검, 기능 테스트
PM의 아이디어 공유 -> QA 작업 후 -> 개발자에게 전달
# UX/UI 디자이너
기획 의도에 맞춰 디자인
PM이 하던 업무의 고도화를 위해 업무가 세분화 되고있음
# UX 리서치
# UX 라이터
# 데이터 분석가
프로덕트 목표 잘 반영한 핵심 지표 (KPI) 설정하고 데이터 분석가에게 데이터 요청
데이터 분석가 : 인사이트와 함께 데이터 전달
PM : 분석 결과 바탕 업무 및 목적 전달
데이터 분석가 : A/B 테스트 환경 구축 , 대시보드 전달
# 세일즈
# CX 매니저 : voice of customer 기반 고객들의 문제 전달
# 서비스 운영자
# 법률 및 개인정보보호 전문가
# 통번역가
"워터풀 vs 애자일"
| 워터풀 | 애자일 |
| 초기 요구사항 명확히 두고 시작 초기에 모든 계획을 수립하고 문서 기록 단계별 순차 진행 계발 기간 장기 변경이 어렵고 이미 지난 단계 돌아가기 어려움 |
초기 요구사항 불완전해도 시작 가능 -> MVP (최소 기능 제품) 요구사항 진화 , 계획 유동적 반복적이고 점진적으로 개발 스프린트마다 고객 의견 반영 최소한의 문서화 , 팀과의 소통 우선 |
MVP가 어느정도인가?
일을 하며 팀원들과 기준을 맞춰야함
프론트, 백오피스의 핵심 기능 갖춰야함
어느 것 하나가 좋다라고 말할 수는 없지만 요즘의 업무에서는 애자일한 방식이 많이 사용됨
애자일한 업무, 실무에선 어떻게 사용될까 ?
1. 칸반
별 다른 주기 없이 할 예정, 과정 중, 완료 이런 식으로 쪼개어 업무
우선순위가 자주 변동되면 칸반
2. 스크럼
- 애자일을 실천하는 방법 중 하나
- 짧은 주기로 프로젝트 진행 (스프린트, 퀘스트처럼 깨고 넘어간다)
스크럼 단계 (w. PO, 스크럼 마스터, 개발자)
(1) 백로그
(2) 플래닝
(3) 데일리 스크럼 : 진행 상황 공유 , 이슈 공유
(4) 스프린트
✅ 스프린트
스크럼은 스프린트 단위로 쪼개서 진행됨
애자일 업무의 대표적인 툴 Jira
계정 생성 후 스프린트 생성해보기
PM의 한 주 🏃🏻♂️
기획 ➡️ 디자인 ➡️ 개발 ➡️ QA ➡️ 릴리즈
이 과정이 하나의 프로젝트가 완성되는 데에 거치는 과정들이다.
물론 애자일한 업무 방식으로 진행된다면 한 번에 과정이 거쳐지지는 않는다.
중간 과정에서 이슈가 생기고 피드백이 생기면 또 다시 전 과정으로 돌아가 다시 진행한다.
과정 이름만 봤을 때 모든 과정의 전문가가 있어보이지만
Pㅣㄹ요하면 Mㅝ든지 하는 PM 역시도 전 과정에 참여를 한다.
1. 기획
프로젝트의 종류에 따라 다르겠지만 기본적으로
목표를 정의, 팀원들과의 공유를 위한 준비 과정
이해관계자 파악
2. 디자인
이해관계자 : 디자이너, UX 리서처
기획 의도와 내용을 공유
디자인 이슈 발견 시 빠른 피드백
필요 시 고객 경험 추가 관찰
3. 개발
기획 공유 및 개발 이슈 팔로업
4. QA
제품을 출시하기 전 개발 환경 사전 배포로 확인하는 과정
기획 의도와 맞게 진행이 되었는지 , 고객이 사용하기 문제 없는지
5. 출시 (릴리즈)
제품을 사용자에게 공개한다고 끝이 아니라
실시간으로 관찰하며 특별한 버그나 이슈가 없는지 모니터링
유저들의 반응을 관찰해 다음 백로그 추가
PM이 생각보다 쉽지 않다고 하는 이유 🥵
새로운 것을 기획하고 내가 만든 것을 누군가가 사용한다는 것에 보람
but, 고객에 대한 이해에 있어 어려움이 많음
-> 직접 고객의 입장이 되어보기도 하고, 나보다 해당 고객들을 더 많이 만나는 타 팀의 동료들과 이야기를 나누기도 함
-> 빠르게 변화하는 시장에서 최상위 목표가 수시로 변화함
-> 직무별 우선순위 정도가 다름
크고 작은 문제들을 마주했을 때,
- 데이터를 근거로 설득하기
- 직접 경험하고 공유하기
이 모든 어려움이 있어도 기획에 대한 보람이 크기 때문에 매력적인 것
PM의 센스
💭 커뮤니케이션
사회생활의 기본적인 요소
PM 자리에서의 커뮤니케이션의 의미 :
성과를 내기 위해 다양한 이해관계자들과 소통 필요
적당한 동기부여를 해주며 팀원과 네트워크 필요
PM의 커뮤니케이션 에러:
서로 다른 위치에 있는 사람들과의 소통 벽 해결 필요
원하는 목표가 상이
커뮤니케이션 에러 해결을 위해:
상대방 니즈에 포커스
상대방의 목표, 우선순위, 요구 고려
빌드업 (갑작스런 요청보다 이해관계자들과 미리 컨택하며 빌드업)
-> 충격완화, 피드백 반영, 참여 유도 등
틈틈이 크로스 체크 해줘야함
-> 한번에 100을 전달했다가 서로 추구하는 방향의 차이를 발견하면 시간, 노력 모두 낭비
-> 핑퐁을 최소화하되 과정 중간에 크로스체크를 해주며 같은 목표를 향해 가고 있는지 확인해줄것
그 외 자주 마주하는 케이스:
보고 , 요청 주고 받기, 설득
좋은 회의 vs 나쁜 회의
정확한 주제를 갖고 아젠다가 정리된 후 진행되는 회의 추구
산만하고 사적인 대화가 오가며 결론이 없는 회의는 지양
회의 전/중/후 모든 과정이 중요 -> 잘 기록해두기, 이 프로젝트를 함께하는 사람들과 싱크 맞추기
🗂️ Today I learned
오늘은 프로덕트 매니지먼트 개론을 마무리 하고 마지막 저녁 시간에는 피그마를 다뤄보았다.
PM의 업무환경적 요소나 기획이 이뤄지는 방법 이런 부분은 '내가 이곳에서 일을 하고있다' 상상과 함께 정리하면서 들어보니 이해가 쉬웠는데 피그마는 익숙하지 않은 프로그램이라 강의 하나 따라가는 데에도 시간이 꽤 걸렸다.
내일은 피그마에 시간을 더 투자해 완강해보려 한다. 새로운 프로그램이고 이것도 실습이다 보니 반복해서 연습하다보면 익숙해질 거라 생각한다.
