PM과 함께 일하는 사람들
💡 목표 : 함께 일하는 사람들의 직무와 역할 이해
왜 ?
다양한 이해관계자들과 더 잘 협업할 수 있도록!
개발자와 디자이너 뿐만 아니라 다양한 부서와 협업한다.
*회사 상황에 따라 다름
개발자
프론트 개발자
- 사용자 인터페이스와 사용자 경험을 설계하고 구현
PM
화면이 어떻게 보여야하는지, 어떤 기능이 필요할 지 설명
프론트
그것을 실제로 구현함
백엔드 개발자
- 서버, 데이터베이스 등 보이지 않는 시스템을 담당
PM
프론트에서 보낸 데이터를 어떻게 처리할 지, 필요한 정보를 어떻게 저장할 지 설명
백엔드
설명을 바탕으로 개발함
앱 개발자
-(프론트에서 같이 하기도 ...) 플랫폼에 맞춰 앱을 구현한다.
PM앱의 기능과 사용자에게 어떻게 보여야하는지에 대한 요청
앱 개발
구현
QA 엔지니어
제품의 품질을 보장하는 역할
제대로 작동하는지, 버그가 없는지, 예상대로 동작하는 지를 테스트하고 결과를 개발자에게 전달하는 역할
PM
요구사항과 기능 설명
QA
테스트 계획을 세우고 케이스를 작성 후 테스트 함
PM이나 디자인, 개발자가 다같이 모여서 QA를 할 수도 있음
UX/UI 디자이너
사용자 경험을 설계하는 역할
사용자에게 직관적이고 편리한 경험을 제공하기 위해 노력함
PM
사용자가 어떻게 이 기능을 사용해야 편할지 설명함
UX/UI
기획의도를 반영해 디자인 제작
UX 리서처
사용자 경험을 개선하기 위해 다양한 방법론을 통해 사용자에 대한 인사이트를 수집하고 분석하는 역할
이를 바탕으로 파악한 사용자의 행동, 요구사항, 문제점 등을 파악하여 이를 개선하는 데에 인사이트를 제공함
PM
사용자들의 문제와 불편 사항을 알려줌
UX 리서처
정보를 수집해서 제품 개선에 도움
배워두면 PM에게도 도움 ! 스타트업에서는 PM이 겸임하기도 함.
UX 라이터
프로덕트에서 만날 수 있는 모든 텍스트를 담당해 작성함
토스 채용공고 참고 키워드
사용자 경험, 톤앤매너, 비즈니스
PM
기능의 목표와 사용자 니즈, 비즈니스 목표를 전달
UX 라이터
전체적인 맥락을 이해하고 라이팅 작성, 이후 실제 목표했던 바가 달성되었는지 논의하며 개선
아티클 인사이트
https://toss.tech/article/1st_uxwriter
독자가 이해하기 쉽게 맥락을 충분히 설명하고 배경 지식 없이도 읽을 수 있는 단어로 풀어써도, 그 문장을 굉장히 좁은 영역에 넣어야 했기 때문에 정보를 덜어내야 했어요. 제가 생각해 온 좋은 문장이 여기에서는 좋은 문장이 아니었죠.
https://toss.im/tossfeed/article/uxwriter-interview
토스도 금융을 다루다보니 텍스트 비중이 높아요. 텍스트를 잘 가공하는 것을 넘어, 어떤 정보까지 텍스트로 전달할지부터 근본적인 고민을 할 사람이 필요했을거예요.
스타트업에서는 디자이너나 PM이 담당하기도 한다 !
마케터
제품의 시장 진입 전략과 마케팅 활동을 총괄하는 역할
제품의 가치를 고객에게 전달하고 제품의 성공적인 출시와 판매를 지원함
PM
제품의 핵심기능과 사용자 니즈, 비즈니스 목표 공유
마케터
정보를 바탕으로 전략을 수립하고 마케팅 결과와 인사이트를 다시 PM에게 공유
PM
인사이트를 통해 프로덕트 전략을 재수립, 과정 반복
데이터 분석가
데이터를 수집, 처리, 분석하여 인사이트를 도출하고 의사결정에 도움을 주는 역할
PM
KPI를 설정하고 데이터를 요청함
데이터 분석가
데이터와 인사이트를 제공함
PM
분석 결과를 바탕으로 다양한 과제를 수립하고 우선순위화하여 실행함
- 데이터 분석가는 A/B테스트와 실험 설계를 지원하고, PM은 이를 통해 지속적으로 프로덕트를 고도화한다.
아티클 인사이트
https://techblog.woowahan.com/2686/
- 린 스타트업 프로세스
만들고 build > 측정하고 measure > 배우고 learn
스타트업에서는 PM이나 마케터가 간단한 데이터 분석을 하거나 , 외부 툴을 활용해 분석하는 경우가 많다.
세일즈
제품을 고객에게 직접 판매함. B2B일 경우가 많다! 고객과 직접 소통해서 도출한 고객 니즈를 바탕으로 개선사항을 PM에게 전달함
PM은 세일즈를 통해 고객과 간접적으로 소통하고, 시장상황과 니즈를 파악해 프로덕트를 개선한다.
덧
이전에 읽었던 아티클에서 PM도 CRM을 봐야하는 이유에 관한 아티클이 있었는데, 고객과 간접적인 소통 뿐만 아니라 데이터를 기반으로 직접적인 소통과 문제 정의가 필요할 수도 있다 !
CX 매니저
고객 경험을 총괄적으로 관리하고 개선하는 역할
VOC 데이터를 기반으로 고객의 공통된 문제를 파악하고 관련 부서에 전달함
CX 매니저
VOC 데이터를 수집하고 분석해 고객이 겪는 주요 문제와 개선점을 파악하고 전달함
PM
이를 바탕으로 제품 기능이나 사용자 플로우를 개선함
- CX 매니저는 고객센터 운영 과정에서 발생한 인사이트를 공유하고, PM은 이를 제품 로드맵에 반영하거나 우선순위를 설정하여 실행함
서비스 운영자
프로덕트의 안정적인 품질 운영을 위한 운영성 업무를 담당함
예시
- 검색 서비스 운영자는 품질을 높이기 위해 검색품질을 정기적으로 평가하고 개선함
- 콘텐츠 서비스 운영자는 품질을 높이기 위해 메인화면에 노출되는 콘텐츠를 정기적으로 교체함
(큐레이션 하거나 ... 등등)
스타트업의 경우 서비스 운영을 최소화할 수 있도록 하거나 PM이 담당한다.
덧
요새는 AI를 활용하는 것이 트렌드 !
제품 출시 후 정책에 맞게 서비스를 운영할 수 있도록 함께 정책을 수립
예시
댓글 운영의 경우, 단시간에 많은 댓글을 효율적으로 검토할 수 있는 내부 프로덕트를 만든다거나, 댓글 운영 정책을 함께 세움
법률 및 개인정보 보호 전문가
법률 전문가
- 법적 리스크 검토, 법률적 자문
- 외부 파트너와의 계약 검토, 법적 리스크 관리, 지적 재산권 보호, 컴플라이언스 준수 등 담당
개인정보 보호 전문가
- 사용자의 데이터 보호
- 관련 법적 준수 책임, 개인정보 보호 정책 수립, 데이터 보호법 준수, 개인정보 위험 평가, 데이터 유출 대응 업무 등 수행
PM
초기 기획의 방향성을 공유하고, 검토할 수 있도록 예상되는 리스크를 리스트업해서 질문한 후 조언과 기존 기획의도를 반영할 수 있는 적절한 방법을 찾아 프로덕트에 반영한다.
개인정보 보호 전문가의 가이드에 따라 개발을 진행한다.
스타트업의 경우 법무팀이 없을 수 있다. 대신 외부 자문을 받거나 PM이 직접 개인정보 처리 방침을 관리하는 경우가 있다.
PM도 어느정도는 관련 지식을 알고 있어야 함 !
통번역가
글로벌 기업에서는 다양한 언어와 문화를 가진 팀원들이 협업하기 때문에 사내 통번역가를 요청하면, 필요한 회의에 참석해 통역을 도와주거나 문서 번역을 돕는다.
글로벌 기업에서는 외국어 능력이 큰 장점이자 필수 요소!
애자일 이론편
애자일 방법론을 겪은 사람을 찾는다 ? 이미 그 회사는 애자일하게 일하고 있다 ! 그게 뭐길래?
프로젝트 방법론이란
업무 = 프로젝트 업무 + 운영성 업무
프로젝트 업무 : 신규 기능 개발, 서비스 개선, 목표 달성 캠페인 등
운영성 업무 : 운영 및 유지 보수, 데이터 분석, 마케팅, CX관리 등
프로젝트를 성공적으로 완료시키기 위한 다양한 방법론들이 존재한다
워터폴 VS 애자일
워터폴
폭포수처럼 각 단계가 끝난 후에 다음 단계로 진행하는 방식
애자일
짧은 주기로 작업을 반복하며 고객 중심의 반복적이고 점진적인 개발 방식
애자일에는 MVP가 존재한다
제품 개발 초기 단계에서 가장 기본적인 기능만 포함한 제품을 신속히 제작하여 시장에 출시한다.
왜?
시장과 고객의 요구에 빠르게 대응하기 위해
단순히 빠른 게 아니라, 초기 제품을 통해 학습하고 지속적으로 개선하는 데 초점
| 항목 | 애자일 | 워터폴 |
|---|---|---|
| 프로젝트 시작시 요구사항 | 초기 요구사항이 불완전해도 시작가능 | 초기 요구 사항을 명확히 정의하고 시작 |
| 계획 | 요구사항은 계속 진화, 계획은 유동적으로 조정 | 초기 단계에서 모든 요구사항과 계획을 상세히 수립 |
| 개발 주기 | 스프린트, 짧은 개발 주기, 주기적 릴리즈 | 단계 별로 순차적으로 진행, 긴 개발 주기, 한 번에 전체 프로젝트 진행 |
| 유연성 | 요구사항 변경에 빠르게 대응가능 | 변경이 어려움, 이미 완료된 단계로 돌아가려면 큰 비용과 시간 소모 |
| 고객 참여 | 스프린트마다 고객의 피드백을 지속적으로 반영 | 초기 요구사항 정의 이후 고객 참여가 제한적 |
| 문서화 | 최소한의 문서화, 팀과의 의사소통에 집중 | 상세한 문서 작성 |
아티클 인사이트
https://techblog.woowahan.com/12417/
장사캘린더의 애자일한 개발 과정
목표 : 외식업 콘텐츠 포털
콘텐츠에 따라 지표 변동 -> 상시 이용 서비스 기능 개발
잘되는 콘텐츠
- 돈이 들어간 콘텐츠
- 요약형 선호
경쟁사 분석
- 외식업 공고만 골라 보기 어려움
- 공고문이 길고 어려운 용어로 되어 있음
빠르게 시도하고, 실패하고, 배우자
빨리 오픈해서 가설 검증을 한 후 발전을 시키자
MVP의 범위는 어느정도?
mvp의 범위와 우선순위를 정하는 것이 굉장히 중요하다 !
= 기존 데이터 분석을 통한 선정과 개발 리소스를 고려한다.
아티클 인사이트
디자이너 입장에서의 가장 큰 차이
PO가 원페이저라는 문서로 문제인식과 개선목표를 설정하는 데 집중했다 !
원페이저
전반적인 큰 그림을 그리는 역할의 문서
기획과 디자인이 중첩되고, 개발과정에서 서로 조율이 가능함 -> 소통할 일이 훨씬 많음
애자일이 무조건 좋나요?
no. 요즘 IT 환경과 트렌드에서 기업들이 생존 확률을 높이기 위해 선택한 방법론
워터폴과 애자일의 장단점
| 항목 | 애자일 | 워터폴 |
|---|---|---|
| 장점 | 빠른 출시, 고객 중심 개발, 유연성 | 명확한 계획과 예측 가능성, 안정성 |
| 단점 | 관리가 복잡하고, 종합적인 계획을 세우기 어려움 | 유연성 부족, 변경에 높은 비용이 발생 |
| 적용 | 요구사항이 자주 변경되거나 고객 피드백이 중요한 프로젝트 | 명확한 요구사항이 있는 프로젝트 |
왜 최근 주목 받는가?
2000년대 초반, 시장 환경이 급변하고 시장 경쟁이 치열하면서, 고객들이 IT 개발업체에 요구하는 것이 점점 많아짐
“경쟁사보다 출시가 빨라져야한다. 더 빨리 개발해달라”
“고객 피드백을 반영해야한다. 요구사항이 변경됐다” 워터풀은 초기 기획이 확정된 이후에는 변경이 거의 불가능한 방식이라 여러가지 문제점 발생
2001년, 미국의 개발자 17명이 이런 문제를 해결하기 위해 토론하다가, ‘애자일 선언문’ 발표
애자일 선언문
- 개인과 상호작용
도구나 절차에 의존하기 보다는 사람 중심의 협력과 문제 해결에 집중 - 작동하는 소프트웨어
개발 초기 방대한 문서 작성 대신, 빠르게 프로토타입을 만들어 고객에게 제공 - 고객과의 협력
계약 조건 보다는, 고객/사용자와 긴밀히 협력하여 요구사항 변화에 유연하게 대응 - 변화에 대한 대응
처음 계획에 얽매이기 보다, 환경과 고객 요구 변화에 맞게 유연하게 조정
애자일 환경에서 PM은 어떤 역할에 중점을 둬야하는가
- 팀원과 협업 활성화
- MVP 정의, 반복적 개선
- 고객과 정기적인 소통 유지, 피드백 적극 환영
- 시장 변화와 고객 요구를 주시, 팀이 계획을 재조정하도록 조율
애자일 실전편
실제 애자일 환경에서 어떻게 일하는 지 알아보기
스크럼
스크럼이란
애자일의 원칙을 실천하는 방법 중 하나
팀이 협업하고 목표를 달성하기 위한 효율적인 관리 프레임워크
- 짧은 주기로 프로젝트 진행
- 스포츠 팀이 큰 시합을 준비하는 것과 유사함
어떻게 진행할까
스프린트 단위로 쪼개어서 진행 !
절차
스프린트란, 스크럼의 반복적인 개발 주기를 뜻한다 !
일반적으로 1-4주 정도 진행된다.
- 프로덕트 백로그
제품 개발에 필요한 작업목록.
우선 순위를 스프린트 백로그로 설정하고 관리한다. - 스프린트 플래닝
스프린트 기간 동안 수행할 작업과 목표를 계획한다.
팀과 함께 작업 내용을 구체화 한다. - 데일리 스크럼
매일 15분 내외로 진행 상황을 공유한다.
- 어제 완료한 일은?
- 오늘 할 일은?
- 현재 이슈는? - 스프린트
정해진 기간 동안 계획된 작업을 실행한다.
리뷰와 회고를 통해 결과를 개선하고 다음 주기를 준비한다.
참여자
PO
프로덕트 로드맵, 백로그를 만들고 우선순위를 관리함
what / why 결정
스크럼 마스터 -> 팀에서 정하기 나름 !
팀이 스크럼을 잘 따를 수 있도록 지원하는 퍼실리테이터
개발팀 ; PM, 개발, 디자인
실제 프로덕트를 개발, 디자인 등을 통해 구현함
HOW 결정
아티클 인사이트
https://helloworld.kurly.com/blog/inbound-squad-sprint-1/
서로에 대한 이해도, 싱크가 어려워 단시간에 목표에 집중하고자 스크럼을 도입
스크럼 팀에서는 수직구조가 없다 ! 함께 논의하고 협업하며 문제를 정의한다.
스크럼 팀의 적정인원 : 피자 한 판 나눠먹을 수 있을 정도, 7명 내외
스토리리뷰?
스토리란 사용자 입장에서 정의한 어떤 요구 사항 하나
그게 모인 것이 에픽, 팀 내의 큰 목표가 된다.
https://medium.com/wantedjobs/2%EC%A3%BC-%EC%8A%A4%ED%94%84%EB%A6%B0%ED%8A%B8%EB%9D%BC%EB%8A%94-%EA%B5%B4%EB%A0%88-613a1dd16012
스프린트 기간이 짧을 수록 가지는 이점
- 데모를 더 자주 실시함
- 더 자주 회고가 가능
부작용
- 스프린트의 이벤트 비용이 증가
- 이벤트들이 갖는 의미가 퇴색
각자의 팀에 맞춰 기간을 조정하는 것이 중요하다 !
내가 일하는 프로덕트에서는 어떤 기간이 적정할 지 고민할 것
https://helloworld.kurly.com/blog/daily-scrum-thinking/
스크럼을 오용하는 경우
- 숙제 검사, 보고처럼 진행할 때
- 토론하다 길어지고 결론을 내지 못할 때
- 일방적인 업무 전파
- 너무 무겁고 경직된 분위기
- 우선순위와 목표가 모호할 때
아 플랭크 스크럼 정말 웃기다
짧고 굵은 스크럼의 중요성 .....회의록을 따로 작성할 수도 있지만, 크게 필요하지는 않다
우리는 보고가 아닌, 함께 작전을 짜는 것!
실제 데일리 스크럼을 실무에서 적용할 때 참고해보자
https://techblog.woowahan.com/14484/
백로그 관리법
배민의 선물 거절이라는 백로그를 스프린트 백로그로 넘기기까지.
서비스에는 혁신도 좋지만 작은 개선도 필요하다.
거절 경험 개선으로 재정의
지표 설정
- 목표 지표
- 가드레일 지표
- 모니터링 지표
간단한 개선건들도 프로덕트 백로그에 쌓아두고, 스프린트 백로그로 넘길 만한 시기에 넣어놓고 적절한 타이밍에 진행한 적절한 예시
칸반 방식
- 스프린트와 같은 주기 없이 칸반 보드에 ’To Do', 'In Progress', 'Done'으로 작업 단계별로 관리해서 시각화
- 지속적인 흐름 관리가 중요하거나, 자주 우선순위가 변경되거나, 유지/운영 보수 관련 업무에서는 칸반을 사용
루틴 업무에 보통 사용 !
애자일 관리 툴 JIRA
채용 공고에서도 우대사항에 적힐 정도로, 가장 중요하고 대표적인 애자일 관리 툴 !
JIRA
주로 애자일 개발 프로세스를 지원하는 프로젝트 관리 툴
작업 추적, 우선순위 관리, 팀 협업을 돕는 다양한 기능을 제공한다.
현업에서 사용하는 방법
참고 아티클
https://spoqa.github.io/2022/06/15/how-to-use-jira-in-spoqa.html
- 프로젝트 관리
프로젝트 내에 작업을 스크럼, 칸반 두 가지 방식으로 관리
- 칸반 보드 형태
- 스크럼 보드 형태
- 백로그
현재 생성된 모든 이슈 목록을 노출
- 액티브 스프린트
칸반 형태로 표기
스프린트 관리
- 스프린트 계획
- 스프린트 생성
- 스프린트 설정
- 에픽 생성
- 각자 업무 생성 (스토리 설정)
스프린트 시작 - 스프린트 종료
우리의 업무 내용을 통계적으로 요약해 보여줄 수도 있다.
운영이슈는 운영 칸반에서 !
프로덕트 개발 과정
각 단계 별로 어떤 일이 일어나는지, 각 단계에서 PM이 무슨 역할을 하는 지 알아보자
기획
기획 단계
어떤 프로젝트와 과제인지에 따라 PM의 역할이 다양하다. 프로젝트의 배경, 목표 설정, 문제 정의, 해결 방안 도출, 가설 수립 및 검증 방법 등을 구체화 한다
PM의 업무
- 목표수립
- 프로덕트와 상위조직의 목표를 바탕으로, 과제 목표 수립
- 문제 정의
- 가장 중요한 핵심 문제를 명확히 정의
- 필요한 경우 각종 방식을 동원해 문제를 발견
- 해결 방안 도출
- 문제를 해결할 수 있는 최적 방안 도출
- 문서화
- 동료들이 요구사항을 명확히 파악할 수 있도록
- 이해관계자 파악
- 해당 과제를 진행하기 위해 함께 해야하는 이해관계자가 누가 있는지 피악하고 협업이 원활하게 진행될 수 있는 환경을 조성
아티클 인사이트
<당근마켓의 문서 작성 방법>
아이디어 회의록
- 주기적으로 아이디어를 나누는 팀별 아이디어 미팅 시간이 있어요. 또한 언제든지 아이디어를 발산할 수 있어요
PRD(Product Requirement Document) 요구사항 문서
- 개발이 어떤 문제를 해결해 주는지, 어떠한 구현을 해야하는지, 요구사항에 대한 문서를 만들어요.
(필요시) 실험 문서
- 중고거래실은 ‘데이터 기반 결정’을 아주 중요하게 생각해요. 가설을 세우고, 로그 데이터로 검증한 뒤, 실험 기능을 정식적으로 제공할지, 철회할지 결정을 합니다.
테크 스펙 문서
- 기술적 구현에 대한 문서를 작성해요. 다양한 엔지니어들이, 개발 구현에 대한 싱크를 맞추는 문서에요.
QA 문서
- 배포 날이 다가오면, 중간 결과물을 어떻게 테스트할지 가이드 문서를 작성해요.
회고록
- 배포한 뒤, 훗날을 위한 자산으로써 회고를 진행해요. 개발 회고뿐 아니라, 일하는 방식은 어땠는지, 목적을 이루었는지 등에 대해 폭넓게 회고하는 것이 목표예요.
디자인
디자인 단계
기획안을 바탕으로 디자이너가 UI/UX를 디자인한다.
기획안이 문서화되어있지 않더라도, 프로젝트의 목적이나 배경만을 파악한 상태에서 디자이너가 프로토타입을 먼저 설계하기도 한다.
PM의 업무
- 기획 내용 공유
- 디자이너들에게 기획 내용을 공유하고 서로 싱크될 수 있도록 크로스체크
- 디자인 이슈 해결
- 이슈가 발견되면, 빠르게 해결하고 우선순위를 재조정
- 디자인 일정 관리
- 진행 상황을 지속적으로 점검하고, 일정에 따라 작업이 원활히 진행되는지 확인
- UX 리서치
- 필요하다면, 디자인을 바탕으로 리서치를 통해 사용자 니즈 파악
개발
개발 단계
개발자가 기획, 디자인을 바탕으로 프로덕트를 개발한다.
기획, 디자인이 완전히 완성되지 않은 상태에서도 개발에서 먼저 할 수 있는 업무가 있다면 개발을 시작한다.
PM의 업무
- 기획 공유
- 개발자들에게 기획, 디자인 내용을 공유하고 서로 싱크될 수 있도록 크로스 체크
- 개발 이슈 해결
- 이슈가 발견되면, 빠르게 해결하고 우선순위를 재조정하거나 기획과 디자인을 논의 후 업데이트
- 개발 일정 관리
- 개발 진행 상황을 지속적으로 점검하고, 일정에 따라 작업이 원활히 진행되는지 확인
QA
QA 단계
지금까지 개발한 것을 개발 환경에 배포한다.
사용자가 사용해도 문제 없는지 품질을 테스트하고, 문제를 발견한 경우 수정한다.
PM의 역할
- QA 계획 수립
- 엔지니어가 없는 경우 직접 테스트 케이스를 작성
- 있는 경우 내용 공유, 엔지니어가 테스트 케이스 작성
- QA 진행
- 테스트 케이스를 바탕으로 진행
- QA 일정 관리
- 출시 일자까지 프로덕트의 품질이 유지될 수 있도록 일정을 관리
- 버그 리포트 관리
- 발생한 버그 및 이슈를 정리하고, 우선순위를 정하고 이해관계자들에게 공유
절대 QA 이후 개발 기간을 과소평가하지마 !
예상보다 쏟아지는 이슈, 수정사항, 새로운 아이디어와 훈수가 많다 ....
직군 별 니즈를 미리 알고 있는 것이 중요하다.
출시
출시 단계
예정된 날짜와 시간에 모든 사용자가 사용할 수 있도록 기능을 오픈한다. 개발자는 운영 환경에 해당 기능을 배포한다.
PM의 역할
출시 직후 문제가 없는지 모니터링, 사용자 반응을 분석해 다음 과제를 백로그에 추가한다.
- 출시 모니터링
- 데이터 수집은 잘 되는지, 장애나 버그가 발생하진 않았는지 모니터링 하고, 문제가 생기면 이전으로 롤백하기도 한다.
- 사용자 반응 분석
- 오픈 후 데이터를 분석해 출시 이후 사용자 반응을 분석한다.
- 분석한 인사이트를 기반으로 개선점 등은 다음 과제로 진행한다.
