여유 있는 일정 산정
일정을 여유 있게 두지 않으면 가장 중요한 ‘사용자를 위한 결정’을 하지 못하게 됩니다.
여기서 중요한 것은 ‘QA 이후 개발 기간’ 을 과소평가하면 안 된다는 거예요. 개인적인 경험인데 저는 여기서 실수가 있었어요. ‘QA 이후 개발이면… 3일이면 되려나?’ 했다가 다음과 같은 이슈가 쏟아진 거예요.
- 예상하지 못한 곳에서 터지는 문제
- 이제서야 떠오르는 아이디어 (근데 사용자에게 꼭 필요한)
- 사용자를 위해 꼭 필요한 기획·디자인 수정 사항
- 무릎을 탁 치게 만드는 지나가던 동료의 피드백
잘 작성한 한 문서, 열 회의 안 부럽다
(잘 작성한 1 문서, 10 회의 안 부럽다)
- 아이디어 회의록 - 주기적으로 아이디어를 나누는 팀별 아이디어 미팅 시간이 있어요. 또한 언제든지 아이디어를 발산할 수 있어요.
- PRD(Product Requirement Document) 요구사항 문서 - 개발이 어떤 문제를 해결해 주는지, 어떠한 구현을 해야하는지, 요구사항에 대한 문서를 만들어요.
- (필요시) 실험 문서 - 중고거래실은 ‘데이터 기반 결정’을 아주 중요하게 생각해요. 가설을 세우고, 로그 데이터로 검증한 뒤, 실험 기능을 정식적으로 제공할지, 철회할지 결정을 합니다.
- 테크 스펙 문서 기술적 구현에 대한 문서를 작성해요. 다양한 엔지니어들이, 개발 구현에 대한 싱크를 맞추는 문서에요.
- QA 문서 배포 날이 다가오면, 중간 결과물을 어떻게 테스트할지 가이드 문서를 작성해요.
- 회고록 - 배포한 뒤, 훗날을 위한 자산으로써 회고를 진행해요. 개발 회고뿐 아니라, 일하는 방식은 어땠는지, 목적을 이루었는지 등에 대해 폭넓게 회고하는 것이 목표예요.
QA 맛있게하는법
직군별 니즈를 미리알고있기
< 직군별 니즈 >
개발자 -> 지금까지의 개발 구현
디자이너 -> 구현된 모든 디자인(UI)
PM -> 구현된 모든 유저 경험(UX)
만약 장애 등 문제가 생기면, 이전으로 롤백을 하기도 합니다.
-> 출시 이후에 해야되는 다양한 업무
---------------------------------------------------------------
기획단계에서 "앞단"부분 -> 문제정의하고 해결방안 도출하고~~~
이 부분에 대해서 자세하게 다루겠다.
실무에서 PM이 겪는 문제와 해결 방법
새로운 아이디어 내는걸 즐기거나
다른 부서들에게 업무를 요청하는 입장 (지시하는 입장) 이다보니깐 뭔가 리더같은 역할이 아닐까?
그럼 내가 리더십을 가지고 리딩하는 역할을 즐기면 적성에 잘맞겠네 등등
- 문제 정의 : 사용자의 불편함(페인포인트)을 발견하고, 진짜 문제를 정의할 수 있는 능력
- 비즈니스 : 이 기능이 유저에게만 좋은 게 아니라, 비즈니스에도 이익이 되는지 판단
- 가설 검증 : 빠르게 가설을 수립하고 검증하는 과정을 실행
<필요한 역량>
- 문제정의 : ‘새로운 기능’을 만들기 전에, “왜 이게 필요한가? 어떤 문제를 해결하려는가?”를 명확히 정의할 수 있어야 함
- 데이터 기반 의사결정 : PM은 실험과 검증을 통해 정량적 근거가 있는 판단을 내려야 함
- 우선순위 설정 : 일정, 리소스, 비즈니스 전략 등 수많은 제약 안에서 결정해야 함
✅ 1위. “내가 만든 제품이 세상에 나오는 게 좋아요”
- 기대하는 모습
- 사용자가 불편해하는 지점을 발견 + 내가 생각한 아이디어가 앱에 적용되어서 세상에 영향력을 끼침
- “덕분에 편리해졌어요!”라는 사용자 피드백과 오르는 지표(사용자수, 매출)을 보고 보람을 느낌
- 실제 모습
- 🤍 제조업, 소비재와 다르게 빠른 시간에 많은 사람에게 영향력을 끼칠 수 있음
- 다만, 여러가지 이유로 출시까지 오래걸리거나 출시가 무산되는 경우가 많음 (개발 리소스, 우선순위 변경 등)
- 출시되더라도, 기대했던 것 보다 사용자 반응이 좋지 않은 경우도 많음
- 단순히 사용자 측면 뿐만 아니라, 비즈니스 측면까지 고려해서 성과를 내야함
EX) 입사하자마자 서비스를 종료하는 업무를 맡기도 한다
-> 프로덕트 매니저는 서비스의 탄생부터 종료까지의 일들을 겪는다
우리가 알고있는 서비스, 모르고있는 서비스가 수시로 오픈하고 종료되는 것들을 반복하고있음
-> PM이 하는일
서비스도 사람처럼 제품처럼
태어나서 성장을 하다가, 어느정도 성장했으면 좀 멈춰지기도 하고,
또 쇠퇴하기도 하면서 그런 cycle을 반복하고있음
-> 하지만 이는 굉장히 자연스러운 현상이고, 오히려 이 과정을 통해서 많은것들을 배울 수 있다
✅ 2위. “새로운 걸 기획하는 걸 좋아해요”
- 기대하는 모습
- 내가 상상한 아이디어로 완전히 새로운 서비스나 기능을 만들고 싶음
- 내가 만든 기획안을 기반으로 실제 제품이 출시됨
- 실제 모습
- 🤍 기획안 작성은 PM에게 가장 중요한 핵심 업무이자 전략이 담긴 중요한 문서
- 다만, 오로지 내가 하고 싶은대로만 하는 게 아니라
현실적인 상황 (ex.고객, 대표, 주변 팀의 요구사항, 일정, 개발 리소스, 정책 등)을 고려해서 기획해야 함 - 아이디어로 세상을 바꾸는 사람 < 현실적 제약에도 불구하고 무언가를 실제로 세상에 내놓는 사람
✅ 3위. “리딩하는 역할을 하고 싶어요”
- 기대하는 모습
- 기획과 관련된 중요한 부분을 의사결정하고, 팀원들이 방향을 따르는 리더 역할
- 실제 모습
- 🤍 의사결정에서 가장 중요한 ‘문제정의’와 ‘해결안’을 포함한 ‘방향’을 제시하는 것은 PM의 중요한 역할
- PM은 공식적으로 권한이 있는 리더 직책이 아니라 역할 (인사권 없음)
- 게다가 ‘정답이 없는 상황’이 대부분이기 때문 개발자 말도 맞고, 디자이너 말도 맞고, PM도 확신 없는 경우가 있음
- 그래서 '명령'이 아닌 ‘설득과 조율’을 통해 자연스럽게 영향력을 확보해야 함
- 설득을 위해서는 ‘논리적인 기획’, ‘팀원들의 신뢰’, ‘데이터’ 등이 필요함
- PM이 되기 위한 노력
- 방향성 제시 : 팀이 혼란스러워 할 때, “무엇이 문제이고, 어디로 가야 하는지”를 명확하게 제시하는 힘
- 데이터 기반 의사결정 : 감이 아닌 데이터로 말해야 팀이 신뢰하고 따라옴
- 설득력 : 다양한 직군의 사람들(개발자, 디자이너 등)에게 각자 이해할 수 있는 언어로 설명하고, 납득시킬 수 있어야 함
- 프로젝트 관리 : 말로만 리딩하는 게 아니라, 실제로 언제까지 무엇을 완료해야 하는지 실행을 끌고 가야 함
(리더처럼 일하지만, 실제로 리더는 아님)
영향력을 제시하는 중요한 역할인건 맞지만, 이거를 잘 설득하고 조율하기 위해서
열심히 발로 뛰어야한다!!!!
그게 PM이다
✅ 4위. “다양한 사람들과 소통해서 결과물을 내는 과정이 즐거워요”
- 기대하는 모습
- 개발자, 디자이너, 마케터 등과 자유롭게 소통하며 함께 제품을 만들어가는 모습
- 실제 모습
- 🤍 팀 덕분에 혼자서는 낼 수 없는 성과와 영향력을 만들어가는 성취감
- 🤍 PM으로서 주변 팀원들에게 인정받음
- 이해관계가 엇갈릴 때 그 사이에서 갈등 조율하는 것이 쉽지 않음
- PM이 되기 위한 노력
- 각 직무에 대한 기본적인 지식 : 개발, 디자이너와 소통할수 있는 기본적인 지식
- 설득력 : 단순 전달이 아니라,이해시키고, 공감시키고, 납득시키는 커뮤니케이션이 중요
- 팀워크 : 팀원들의 기분을 읽고, 관계가 틀어지지 않게 부드럽게 리딩
그냥 사람들이랑 다같이 일하는 과정 자체가 즐거워요~~~!!
다른사람들과 함께 일하여 실제로 결과물을 도출하는 행위
-> 설득을 해야되고, 의견조율을 해야되기 때문에
1. 소통하기 위한 각 직무별 기본적인 지식이 필요
2. 설득력 필요
3. 팀원들의 기분을 읽고 관계가 틀어지지않게 부드럽게 리딩하는 팀워크 역량 필요
동전의 앞/뒷면처럼 PM에게는
동전의 앞면 => 좋은것만 있는줄 알았는데 (PM이 느끼는 보람도 있지만 그 반대편에는)
동전의 뒷면 => 힘든것도 많구나 (어려움도 많다는 사실)
- PM이란?
- 사용자와 비즈니스를 위해, 팀원들과 함께 제품을 세상에 내놓는 사람
1. 내가 사용자가 아닌 제품을 담당하면, 누구보다 사용자를 깊이 이해해야 한다
- 어려움
- 제품이 속한 산업과 고객군에 대한 이해도가 매우 중요. 그런데 정작 PM은 그 대상에 대해 전혀 경험이 없거나 관심이 없는 경우가 있음
- 내가 겪어보지 않은 사용자의 니즈를 상상하기 어렵다
- 해결방안
- 직접 사용자가 되어 많이 써보기
- UX 리서치 (사용자 인터뷰, 설문조사 등)
- 현장에 나가서 사용자 직접 만나기
- 고객과 가장 자주 만나는 회사 내부 전문가(세일즈팀, CX팀, 운영팀 등)에게 배우기
- 온라인 SNS (커뮤니티) 분석
세일즈팀, CX팀, 운영팀 -> 고객과 가장 자주 만나는 직군
토스가 사용자 경험에 "집착" 하는 또 하나의 방법 -> 유저 리서치
토스는 사용자 경험에 "집착" 한다고 말할 정도로 고객의 목소리를 중요하게 여김
토스팀은 원래부터 '미친 고객 만족감'을 지향
데이터 이면에 숨겨진 고객의 목소리를 효과적으로 찾아내야한다!!!
사용자에 대해서 잘 모른다고 하면 -> 사용자들을 가능한 최대한 많이 만나보는것을 추천!!!
2. PM 역할의 범위가 회사마다, 팀마다 조금씩 다르다
- 어려움
- PM은 조직 구조나 규모에 따라, ‘PM이 하는 일의 범위’가 다르다
- 회사가 작을수록 다양한 업무를, 회사가 클수록 좁은 범위의 업무를 담당
- → 팀에서 기대하는 역할과 어긋나면, 실망으로 이어짐
- 해결방안
- 내가 담당한 제품, 팀에서 내가 어떤 역할 범위를 가져갈지를 스스로 잘 정의해야함
- 예시. 기획안의 범위, 와이어프레임
- 내가 담당한 제품, 팀에서 내가 어떤 역할 범위를 가져갈지를 스스로 잘 정의해야함
+++ 회사마다 PM의 업무 scope이 다름
PM이라면 그 부분까지 관여해야된다 VS PM이 그 부분까지 간섭하면서 PM의 리소스를 비효율적으로 사용하는 것은 맞지않다
-> 어떻게 생각하는지는 회사 문화마다 다름
EX) 카카오에서는 와이어프레임을 잘 그려서 요청을 드리는게 PM으로서 인정을 받는 영역 중 하나였는데
우형 (우아한 형제들) 에서는 그렇지 않았음
우리회사에 맞게, 우리팀에 맞게
3. 수시로 변하는 시장상황과 회사상황에 빠르게 적응해, 우선순위를 정한다
- 어려움
- 시장상황이 바뀌면서, 최상위 목표가 수시로 바뀌기도함
- 직무별로 우선시하는 우선순위의 기준이 다름 (일정 vs 완성도)
- 해결방안
- 제품의 방향성을 기반으로 우선순위 기준에 대해서 팀 내 합의하기
- 기획을 '짧은 사이클'로 쪼개서 민첩하게 움직이기 (애자일)
- 심리적으로 ‘계속 바뀌는 게 당연하다’는 마인드 세팅
------------------------------------------------------------------------------------------------------------------------
" 비즈니스 커뮤니케이션의 기본 "
Q.직장인한테 커뮤니케이션은 왜 중요할까?
✅ 회사 생활 = 커뮤니케이션의 총 집합
✅ 입사 면접, 연봉 협상, 프로젝트, 연말 평가, 퇴사..
→ 80을 일하고 100처럼 보이는 사람 vs 110을 일하고 100처럼 보이는 사람
Q. PM의 커뮤니케이션은 뭐가 다를까? 왜 어려울까?
요약 : 팔로워지만, 여러 이해관계자를 리딩해서 성과를 낸다.
✅ 의사결정자로서의 명확한 권한/직책이 없는데, 조율해야 하는 책임은 있다
교통경찰이 제복을 입고 교통정리를 하는걸 보면, 그 제복을 통해서 아 저분이 교통경찰이구나 할 수 있는데
PM은 똑같이 교통정리를 열심히 하고있는데, 제복없이 맨몸으로 허허벌판에서 땀 삐질삐질 (권한이 없는 상태이니깐 / 내가 당근과 채찍을 제공할 권한이 없으므로) -> 이런 기분이 들때가 많다
따라서 나만의 당근 / 나만의 채찍을 만들어서 서로 다른 의견을 잘 조율해야된다
✅ 직무가 다른 이해관계자들(ex.개발자,디자이너 등)과 협업해야 한다
✅ 팀워크를 통해 성과를 내야 한다
Q. 팀 활동 vs 회사에서의 커뮤니케이션 차이점은 무엇일까? 팀 활동이 커뮤니케이션 역량에 도움이 될까?
팀 활동에서의 시행착오가, 실제 회사에서의 실수를 줄여줌
팀 활동에서 주도적인 리딩 경험을 하고, 회사에서는 체계적인 협업을 경험하며 리딩 기회를 늘려가!
팀활동에서는 빠르게 논의후 결정됨
반면에 회사에서는 서비스가 크면 클수록, 회사가 크면 클수록 내 직급이 낮으면 낮을수록, 수많은 승인과정들이 필요함
회사에서 PM같은 경우에는 도메인에 대한 지식이 굉장히 중요하기 때문에
도메인의 역사, 도메인의 히스토리, 서비스의 " 개편 히스토리 " 같은
업무 히스토리가 굉장히 많다
Leading = 리딩을 입사하자마자 바로 할 수 있냐? -> 절대못함
프로젝트 매니저로서 큰 프로젝트를 이끄는 경험을 입사 후에 빠른 시일 내에 하는 편이라고 해도
그럼에도 불구하고 1년은 지나고나서 프로젝트 매니징하는 경험을 가져갈 수 있음
하지만 팀프로젝트경험 -> 별도로 파악해야되는 히스토리도 없고, 빠르게 논의하고 결정하고 진행할 수 있다보니깐
조금이라도 내가 더 "주도적"으로 리딩(leading)할 수 있는 기회
-> leading 하면서 배운 레슨런이 굉장히 큰 도움이 된다
레슨 런(Lesson Learned) = 프로젝트나 업무 수행 과정에서 얻은 성공 또는 실패 경험을 통해 배운 교훈, 개선 사항, 노하우를 정리한 것을 의미
회사는 급여/평가/시스템 기반으로
팀원들의 역량이 보장되어 있어서,
협업이 좀 더 안정적으로 이루어진다
대신, 회사에서는 신입 PM이
처음부터 프로젝트를 리드할 기회가 거의 없음
Q. 커뮤니케이션 오류는 왜 생길까?
1. 각자 알고 있는 정보가 다르다
2. 각자 원하는 목표가 다르다
(중요하게 생각하는 업무도 다르고, 회사를 다니는 이유도 다르다)
회사를 다니는 이유 -> 어떤사람은 그냥 회사를 "돈벌기위해서" 다니는 경우도 있고, 프로젝트에 큰 애정없이 대충 임하는 사람도 있기 마련이다
-> 이렇듯 동기부여에 차이가 있으면 "나는 열심히 하는데, 왜 상대방은 열심히 하지 않지?" 라는 생각 때문에
서로 오류가 생기기도 함 / 반대로 내가 생각했을땐 이렇게까지 에너지를 써서 해야될 일은 아닌거같은데, 왜 저사람은 너무 오버를 해서 지나치게 열심히 하는거같아!!!! 라고 생각할 수도 있음
-> 관점의 차이에 따라 서로 오류가 생기기도 함
온보딩 = 신규 사용자가 서비스를 쉽게 이해하고 활용할 수 있도록 도와주는 과정
신입사원으로 입사하면 온보딩 (튜토리얼, 가이드 메시지) -> 온보딩을 누군가가 해줘야하는데
경력이 너무 많은 사람은 자기가 연차가 적었을때, 뭘 어려워했는지, 뭐가 힘들었는지가 기억이 나지 않음
-> 이게 도와주기 싫은게 아니라, 도와주는 방법을 몰라서 그걸 어려워하심
📌 📌 📌 📌 📌 📌 📌 📌 📌 📌 📌
****PM 커뮤니케이션의 원칙
✅ 1. 상대방의 니즈 파악
Q. WHAT : 상대방 니즈 파악이란?
커뮤니케이션할때 상대방이 어떻게 생각할지, 무엇을 원하는지 먼저 알아보기
역지사지 -> 다른 사람의 처지에서 생각함
Q. WHY: 왜 상대방의 니즈를 기준으로 이야기해야 할까?
내가 원하는 것만 말하면 생기는 문제점
- 상대방이 공감하지 못한다 → "왜 내가 이걸 해야 하지?"
- 협업이 어려워진다 → "이건 나한테 중요한 일이 아닌데, 왜 해야 하지?"
- 원하는 결과를 얻기 어렵다 → "거절당할 가능성이 높아짐"
→ 상대방이 필요하다고 느끼면 자연스럽게 움직임!
Q. How: 상대방의 니즈를 파악하고, 효과적으로 커뮤니케이션하는 방법은 무엇일까?
✅ 상대방의 입장에서 상대방이 중요하게 여기는 기준을 파악하기
- "개발자는 어떤 기준으로 우선순위를 정할까?"
- "나한테 이 업무를 왜 줬을까? 어떤 걸 원할까?”
- "경영진이 원하는 건 매출 증가인데, 이걸 어떻게 연결할 수 있을까?"
-> 내가 소통하고 있는 상대방이 뭘 중요하게 여기는지 먼저 파악을 해야됨
✅ 상대방이 듣고 싶은 방식으로 이야기하라
- “팀장님이 매일 바쁘시던데, 결론부터 알고 싶지 않을까?” -> 바쁜사람한테는 "결론"부터 이야기한다
- “디자이너랑 개발자도 시키는 업무 보다는 제안을 하고 싶지않을까?”
✅상대방의 언어로 말하기
- 회의에 처음 참석하는 사람도 이해하기 쉽게
📌
Q. WHAT : 빌드업이란?
결정을 **통보**하는 것이 아니라, 사전에 정보를 공유하고 논리를 쌓아가며 **자연스럽게 동의**하게 만드는 과정
단순 정보 공유와 다르게, 상대방이 그 정보나 결정에 대해 미리 인지하고, 이해하며, 점진적으로 동의하도록 만드는 과정
Q. WHY: 왜 빌드업을 해야할까?
✅ 충격 완화
- 갑작스러운 통보로 인한 반발이나 거부감을 줄여줌
✅ 준비 시간 확보
- 상대방이 정보를 미리 알고 준비할 수 있도록 도움
✅ 피드백 반영
- 중간 과정에서 팀원들의 의견을 수렴하여 더 나은 결정을 내릴 수 있음
✅ 참여 유도
- '내가 참여했다'는 느낌을 주어 팀원들의 적극적인 협업을 이끌수 있음
✅ 예시
- "아직 확정은 아닌데, 이런 과제를 할 수도 있을 것 같아요"
- “다음 주에 그 과제에 대해서 진행 여부를 논의할 것 같아요”
- “혹시 그 과제에 대해서 사전에 공유주실 의견 있으실까요?”
- “드디어 과제 진행이 결정 됐어요!”
📌
Q. How: 빌드업하면서 소통하는 방법은?
✅ 상대방이 이해하고 납득할 수 있는 논리적 근거 제공
- "이 디자인 수정해주세요.” → "사용자 테스트에서 이 버튼이 잘 보이지 않는다는 피드백이 나왔어요.”
✅ 갑작스러운 통보가 아니라, 사전에 과정을 공유한다
- “디자이너랑 개발자도 시키는 업무 보다는 제안을 하고 싶지않을까?”
- "다들 준비된 것 같으니, 다음 주부터 진행할게요!"
✅ 사람들이 "내가 참여했다"고 느낄 때 더 적극적으로 협업한다.
- "지난번 이야기했던 내용 기반으로 정리해 봤는데, 이 방향 괜찮을까요?"
PM이 공유하는 의사결정 사항 같은 경우에는 본인이 의사결정한 내용도 있지만
보통은 윗분들의 의사결정 내용을 PM이 정리를 해서, 디자이너나 개발자들한테 뿌리는 케이스가 많다
근데 그 윗분들의 의사결정 내용은 PM도 조금 납득하기가 어려울 때가 있다
그럴때 PM입장에서
" 윗분들한테 이런 의사결정 사항을 받았는데, 저도 납득하기 어려운데 이런걸 해야된대요 " 라고 말하는것이 아니라
그 부분을 작업하시는 작업자인 개발자나 디자이너한테
납득할 수 있게끔 번역하는 과정을 거쳐야한다
왜 그런 의사결정이 나오는동안 저 PM은 가만히 있었지? 라고 오해를 살 수도 있음
그렇기 때문에, 예를 들면 의사결정이 바뀐다는 소식이 들려올때
디자이너나 개발자한테 "의사결정이 바뀔 수도 있다는 소문이 있어요~" 라는 식으로
(아직 의사결정이 바뀌는 내용은 정확하진 않지만)
이런식으로 작업자들한테 조금의 정보를 사전에 흘려주는게 중요
사전에 작업자들한테 (디자이너나 개발자) 살짝 정보를 흘려줘서 충격을 완화한다
충격 완화 -> 갑작스러운 통보로 인한 반발이나 거부감을 줄여줌
Q. WHY: 왜 빌드업을 해야할까?
✅ 충격 완화
- 갑작스러운 통보로 인한 반발이나 거부감을 줄여줌
✅ 준비 시간 확보
- 상대방이 정보를 미리 알고 준비할 수 있도록 도움
✅ 피드백 반영
- 중간 과정에서 팀원들의 의견을 수렴하여 더 나은 결정을 내릴 수 있음
✅ 참여 유도
- '내가 참여했다'는 느낌을 주어 팀원들의 적극적인 협업을 이끌수 있음
✅ 예시
- "아직 확정은 아닌데, 이런 과제를 할 수도 있을 것 같아요"
- “다음 주에 그 과제에 대해서 진행 여부를 논의할 것 같아요”
- “혹시 그 과제에 대해서 사전에 공유주실 의견 있으실까요?”
- “드디어 과제 진행이 결정 됐어요!” </aside>
Q. How: 빌드업하면서 소통하는 방법은?
✅ 상대방이 이해하고 납득할 수 있는 논리적 근거 제공
- "이 디자인 수정해주세요.” → "사용자 테스트에서 이 버튼이 잘 보이지 않는다는 피드백이 나왔어요.”
✅ 갑작스러운 통보가 아니라, 사전에 과정을 공유한다
- “디자이너랑 개발자도 시키는 업무 보다는 제안을 하고 싶지않을까?”
- "다들 준비된 것 같으니, 다음 주부터 진행할게요!"
✅ 사람들이 "내가 참여했다"고 느낄 때 더 적극적으로 협업한다.
- "지난번 이야기했던 내용 기반으로 정리해 봤는데, 이 방향 괜찮을까요?"
3. 크로스체크
Q. WHAT : 크로스체크란?
내가 전달한 정보가 그대로 받아들여졌는지 확인하는 과정
Q. WHY : 왜 크로스체크를 할까?
✅ 크로스체크를 안하면 생기는 일
- 다시 논의하느냐 시간, 리소스가 낭비
- 서로가 다르게 이해한줄 모르고 업무를 진행
→ 일정, 품질 문제가 생김 + 생산성 낭비
Q. HOW : 크로스체크하는 방법은?
✅ 구두 합의 직후
- "말씀해주신 내용을 저는 ~ 이렇게 이해했는데, 맞을까요?"
✅ 업무 지시/요청 후
- "지금 이해한 대로 설명해줄 수 있을까요?"
✅ 중요한 결정/정보 공유 후
- 다시 한번 정리해서 문서로 공유할게요!" </aside>
3. ****PM이 자주 마주치는 커뮤니케이션 상황
✅1. 보고 (공유)
✅ 적절한 시점에 적절한 사람에게 진행 상황 ‘공유’
- 정보의 수신자가 해당 정보에 기반하여 의사결정하거나 다음 단계를 진행할 수 있도록 적시에 공유합니다.
✅ 내가 말하고 싶은 것보다, 상대방이 듣고 싶은 또는 필요로 하는 정보 위주로 공유
- 수신자의 역할, 관심사, 그리고 현재 진행 중인 업무에 따라 필요한 정보의 깊이와 범위를 조절합니다.
✅ 중간 단계 없는 최종 보고는 금물
- 중요한 프로젝트의 경우, 주요 마일스톤이나 병목 현상 발생 시 중간 보고를 통해 이해관계자들이 상황을 인지하고 필요시 개입할 수 있도록 합니다.
✅ 상대방이 정확하게 이해했는지 크로스체크
- 공유 후 질문을 유도하거나, 핵심 내용을 요약하여 되물어봄으로써 오해의 소지를 줄입니다.
✅ 예시
- 디자이너에게 현재까지 정리된 기획안 공유
- 팀 리더에게 업무 진행상황 공유하기
- 데일리 스크럼, 프로젝트 정기 회의
2. 요청하기
✅ 갑자기 요청하지 말고, 언제쯤 요청이 들어갈 수 있다는 걸 미리 공유
- 상대방이 업무 계획을 세울 수 있도록 여유를 두고 요청을 예고하여 혼란을 방지합니다.
✅ 요청의 맥락을 설명하기
- 단순히 무엇을 해달라고 하기보다, 왜 이 요청이 필요한지, 어떤 문제 해결에 도움이 되는지 배경 설명을 통해 상대방의 이해도를 높입니다.
✅ 각 직군의 언어로 이해할 수 있게 말하기
- 개발자에게는 기술적인 용어를 사용하여 구체적인 구현 방식을 요청하고, 디자이너에게는 사용자 경험 측면에서 어떤 개선을 원하는지 설명하는 등 상대방의 전문성을 고려하여 소통합니다.
✅ 요청 내용을 정확하게 이해했는지 크로스체크
- 요청 후 상대방에게 핵심 내용을 다시 한번 확인하거나, 궁금한 점이 없는지 물어보며 오해를 줄입니다.
✅ 예시
- 개발자에게 새로운 기능 개발 요청
- 마케팅 부서에 서비스 오픈일 공유하기
3. 요청받기
✅ 상대방이 진짜 원하는 것이 무엇인지, 요청 자체보다 "왜 이 요청이 나왔는가"를 파악하기
- 표면적인 요청 너머에 있는 근본적인 문제나 목표를 파악하여 더 효과적인 해결책을 제시할 수 있습니다.
✅ 이 요청이 진짜로 중요한지, 긴급한지 파악하고 수락하기
- 모든 요청을 무조건 수락하기보다는, 현재 진행 중인 업무의 우선순위와 비교하여 중요도와 긴급성을 판단합니다.
✅ 요청 내용과 내가 일치한 게 맞는지 크로스체크하기
- 요청받은 내용을 다시 한번 요약하거나 질문하여 서로의 이해가 일치하는지 확인합니다.
✅ "No"를 바로 말하기보다는, 대안이나 이유를 함께 제시
- 무조건 거절하기보다는, 현재 상황을 설명하고 가능한 대안이나 차선책을 함께 제시하여 상대방과의 관계를 유지하고 문제 해결에 도움을 줍니다.
✅ 예시
- 운영자의 요청으로 어드민에 기능을 개선할 때
- CS팀이 자주 들어오는 문의를 줄이기 위한 개선 요청
4. 설득 (협상)
✅ 상대방의 목표, 우선순위, 걱정하는 부분을 먼저 이해
- 상대방의 입장을 충분히 이해함으로써, 그들의 니즈에 맞는 해결책을 제시하고 공감대를 형성할 수 있습니다.
✅ 상대방이 "이득을 본다"고 느끼게 만들어야 한다
- 설득은 단순히 내 의견을 관철시키는 것이 아니라, 상대방에게도 긍정적인 영향을 미칠 수 있음을 보여주는 것입니다.
✅ 설득은 "갑자기" 하는 것이 아니라, 단계적으로 공감대를 형성
- 한 번에 모든 것을 해결하려 하지 않고, 작은 성공 경험을 쌓아가며 점진적으로 신뢰를 구축하고 설득력을 높입니다.
✅ 예시
- 개발자, 디자이너와 과제 우선순위/일정에 대한 협상
- 개발자, 디자이너와 과제의 구현 방식에 대한 협상
- 디자이너에게 유저 피드백을 반영한 다른 방향 제안
4. 회의 진행
Q. 피해야하는 회의 유형은?
목표 없는 회의 — “이 회의는 왜 하는 거지?”
- 주제 없이 습관적으로 열리는 회의
- ‘일단 모여서 얘기하자’ 식 접근
- 회의 전 아젠다 미공유 </aside>
준비 없는 회의 — “아는 게 없어 할 말이 없네.”
- 회의 자료가 회의 직전에 공유됨
- 참석자들이 내용을 검토하지 않고 들어옴
- 사전 준비 없이 즉석에서 논의 진행 </aside>
산만한 회의 — “그래서 결론이 뭐라고?”
- 진행자가 논의 흐름을 통제하지 못함
- 회의 중 잡담, 딴 얘기 많음
- 스마트폰, 사적 대화 등 집중력 저하 </aside>
결론 없는 회의 — “다음에 다시 논의하죠.”
- 의사결정 기준이 없거나 회피
- 책임자와 기한 미정
- 회의록 미작성 또는 공유 누락 </aside>
Q. 어떤 종류의 회의가 있나요?
1. 정보 공유 회의
- 왜 하나요?
- 프로젝트 상황, 공지사항, 새 정책 등을 팀원들에게 빠짐없이 전달하기 위해 엽니다
- 이럴 때 좋아요:👉 예: 주간 업무 보고, 회사 공지 전달 등
- 중요한 내용을 팀 전체에 공유해야 할 때
- 포인트참석자는 궁금한 점을 질문할 수 있는 구조가 좋습니다.
- 주간 팀 미팅
- 프로젝트 진행 상황 보고
- 부서장 브리핑
- 정책/제도 변경 공유
발표자가 핵심만 정리해서 공유하고, 참석자는 궁금한 점을 질문할 수 있는 구조가 좋습니다.
- 주간 팀 미팅
- 프로젝트 진행 상황 보고
- 부서장 브리핑
- 정책/제도 변경 공유
2. 아이디어 회의 (브레인스토밍)
- 왜 하나요?
- 하나의 주제나 문제에 대해 다양한 아이디어를 끌어내기 위해서입니다.
- 이럴 때 좋아요:
- 신제품 아이디어를 낼 때, 마케팅 전략을 기획할 때 등
- 포인트:🎈 분위기가 편해야 기발한 생각도 나옵니다.
- 신제품 아이디어 회의
- 마케팅 캠페인 아이디어 회의
- 슬로건/브랜드 네이밍 워크숍
- 고객 경험 개선 아이디어 회의
- 아이디어의 수준을 따지지 말고 일단 많이 내는 게 중요합니다.
3. 의사결정 회의
- 왜 하나요?
- 여러 대안 중에서 하나를 고르거나, 중요한 사안을 결정해야 할 때 사용합니다.
- 이럴 때 좋아요:
- 프로젝트 방향 결정, 예산 승인, 일정 확정 등
- 포인트:회의 안에서 꼭 **“이렇게 하기로 합시다”**라는 결론이 나야 합니다.
- 프로젝트 일정 확정 회의
- 예산 배정/승인 회의
- 파트너사 선정 회의
- 전략/기획 방향 결정 회의 </aside>
📂 사전에 자료가 충분히 준비돼 있어야 하고, 회의 안에서 꼭 **“이렇게 하기로 합시다”**라는 결론이 나야 합니다.
- 프로젝트 일정 확정 회의
- 예산 배정/승인 회의
- 파트너사 선정 회의
- 전략/기획 방향 결정 회의
4. 문제 해결 회의
- 왜 하나요?
- 어떤 문제가 발생했을 때 원인을 파악하고 해결책을 찾기 위해 엽니다.
- 이럴 때 좋아요:
- 고객 불만이 발생했거나, 업무 흐름에 문제가 있을 때
- 문제를 제대로 정의하고,
- 포인트:👉 왜 이런 일이 생겼는지 → 어떻게 해결할지를 차근차근 정리해야 합니다.
- 장애/버그 대응 회의
- 고객 불만 대응 회의
- 내부 커뮤니케이션 오류 원인 분석 회의
- 리소스 부족 문제 해결 회의
5. 피드백 / 회고 회의
- 왜 하나요?잘된 점과 아쉬운 점을 나눠서 다음에 더 잘하기 위해서입니다.
- 함께 진행한 프로젝트나 업무에 대해 돌아보고,
- 이럴 때 좋아요:
- 프로젝트가 끝났을 때, 정기적인 팀 성과 점검 시
- 포인트:🙌 안전하고 솔직한 환경이 핵심입니다.
- 서로 공격하지 않고 **‘이건 더 나아질 수 있겠다’**는 관점에서 이야기하는 분위기가 중요합니다.
-
- 프로젝트 회고(Retrospective)
- 월간 업무 리뷰 회의
- 팀 내 성과 공유 & 피드백
- 온보딩 이후 신입 평가 회의
Q. 회의 진행 과정마다, 해야하는 업무를 알려주세요
✅ 회의 진행 여부 검토
✅ 회의는 집중력과 시간의 공동 투자
- 예: 1시간 회의 × 5명 참석 = 5시간의 팀 총 업무 시간 사용
- 즉, “이 회의가 그만한 가치가 있는가?”를 먼저 물어야 함
✅ 이런 경우, 회의를 다시 생각하세요!
- 단순 정보 전달이라면? → 📧 이메일이나 메신저로 충분
- 논의 안건이 모호하거나 부족하다면? → ⏸️ 회의 연기 또는 자료 보완
- “일단 만나서 얘기하자”는 회의가 반복된다면? → ⚠️ 구조화된 목적 설정 필요
✅ 정기 회의도 반드시 목적을 재검토
- 회의 목적이 사라졌다면
- 🔄 포맷을 바꾸거나
- 🗑️ 과감히 폐지하거나
- 📆 주기를 줄이는 것도 방법입니다.
회의 전
✅ 회의 목적에 맞는 참석자 구성
- 회의 목적에 맞는 적절한 참가자를 선정, 너무 많거나 적으면 비효율적
- 회의에 꼭 필요한 참석자와 선택 참석자를 구분
- 특히, 의사결정이 필요한 회의라면, 최종 결정을 내릴 수 있는 권한을 가진 사람이 반드시 포함
✅ 목적 명확화
- 회의를 통해 무엇을 얻고자 하는지 (의사결정, 문제 해결, 아이디어 도출 등) 명확히 정의
- 단순 정보 공유라면 슬랙, 이메일, 공유 문서 등으로 대체
✅ 사전 준비
- 참석자들이 회의 전 충분히 숙지하고 올 수 있도록 안건과 필요한 정보를 미리 공유
- 회의 중 자료 설명에 시간을 낭비하지 않도록 한다
✅ 회의 시간 선정
- 여러명이 참여하는 회의일수록 시간을 미리 잡아두어야 함
- 일반적으로 최대 1시간 이내로 끝내는 것이 가장 효율적
회의 중 : 능동적인 참여와 조율
✅ 회의 시작 때, 전반적인 내용 공유
- 회의 목적, 회의 진행 순서, 회의를 통한 아웃풋 정리
- 회의를 시작하는 사람들이 모두 동일하게 아젠다를 인지했는지 확인하기
✅ 논의가 산으로 가지 않도록 흐름을 유지
- 논점에서 벗어난 내용은 별도 회의에서 진행
- "잠시만요, 지금 논의 중인 핵심은 ~입니다. 다시 그 부분으로 돌아와서 이야기해볼까요?"
✅ 크로스체크를 통해 오해 없이 중간 정리
- 서로 사용하는 용어가 동일한지 재정의
- "지금까지 논의된 내용을 정리하면 A, B, C입니다. 제가 제대로 이해한 것이 맞을까요?
- "혹시 다른 의견이 있거나, 추가로 고려해야 할 점이 있을까요?"
✅ 모든 참석자의 참여 유도
- 특정 소수만 발언하거나, 일부 팀원이 침묵하는 상황을 방지
- "혹시 이 부분에 대해 다른 의견 있으신가요?"
- "OO님은 어떻게 생각하세요?"
✅ 시간 관리 (타임키퍼 역할)
- 각 안건별 예상 소요 시간을 염두에 두고, 시간을 초과하지 않도록 조절
- "이 안건은 5분 안에 마무리하고 다음으로 넘어가야 합니다"
- 논의가 길어지면 과감히 다음 안건으로 넘어가거나 별도 논의를 제안
- “이 부분은 시간이 많이 소요될 것 같으니, 일단 다음 아젠다로 넘어가고 필요하면 별도 시간을 잡을까요?”
✅ 논의내용 시각화
- 필요하다면 화이트보드, 프로젝터 등을 활용하여 논의 내용을 시각화하고 정리
✅ 회의 결론 정리
- '누가(Who)', '무엇을(What)', '언제까지(When)' 할 것인지를 명확하게 결정
- "OO님, 다음 주 수요일까지 X 기능의 사용자 피드백 분석 결과를 공유해주세요.
✅ 회의 종료 : 실행으로 이어지는 마무리
✅ 회의 직후 빠른 시간 내에 회의록을 작성하여 배포
- 논의 내용, 결정사항, 각자의 역할 및 책임, 다음 단계 등이 명확하게 기록
- 특히 결정 사항과 액션 아이템은 명확하게 작성
- 혹시 누락되거나 잘못된 내용이 없는지 참석자들에게 피드백을 요청하여 최종본을 확정
✅ 회의 직후 해야하는 업무 인지시키기
- 액션 아이템을 명확히 정리하고, 담당자와 기한을 리마인드
📌 내일배움캠프에서 열심히 하고있는것이 "온라인 화상 회의"
Q. 온라인 화상 회의인 경우 주의점이 있나요?
✅ 가능한 한 모두 카메라를 켜도록 안내
- 얼굴이 보이면 집중력, 참여도, 비언어적 소통이 모두 좋아집니다.
✅ 화면 공유는 ‘기본 도구’
- 문서, 도표, 발표자료는 반드시 화면 공유로 보여주세요.
- 시각적 정보가 있으면 이해 속도가 빨라지고 논의도 명확해집니다.