토글 ( )을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다.
(전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )
)을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다.
(전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )목차 확인하기
1. PM에게 팀워크가 중요한 이유
여러분들도 이미 많은 팀 활동과 업무를 수행하시면서 알고 계실텐데요,
팀워크는 다수가 함께 협력하여 일을 하는 사람들에게는 모두 중요합니다.
하지만 왜, 유독 PM에게는 팀워크를 필수 소양으로 강조 할까요?
당연히 PM 혼자서는 문제를 해결할 수 없기 때문입니다.
•
어떤 문제에 대해 나 혼자 해결할 수 있다면, 팀워크보다 문제 해결에만 집중하면 됩니다. (1인 개발자 만세!)
오늘도 개발자가 안 된다고 말했다 - YES24
성공적인 프로덕트를 만들기 위해 가장 중요한 건 Makers와 협업하는 것입니다. 이 책은 '기획자, 디자이너, 개발자' 각자의 관점에서 어떻게 프로덕트를 바라보고, 진행하는지에 대해 저자의 경험 기반으로 쉽고 체계적으로 설명하고 있습니다. 특히 서비스를 사람의 신체 구조에 빗대어 시각화하여 설명한 부분이 인상적이었습니다.
http://www.yes24.com/Product/Goods/97919905
개발하기 싫어서 안 된다고 말하는 것이 아닙니다. 안된다고 해서 속상해 하지말고, 왜 안되는지를 아는 사람이 됩시다.
•
하지만 우리는
◦
더 복잡한 문제를 해결하기 위해서
◦
더 큰 임팩트를 시장에 내놓기 위해서 → 다양한 역할의 팀원들과 함께 팀을 이뤄 문제를 해결합니다.
근데 왜 유독, PM에게만 ‘팀워크’에 대해 엄격한 걸까요?
PM은 문제를 해결할 기술이 없기 때문일까요? 말로만 문제를 해결하려는 뜬구름 잡는 사람이라서 그럴까요? 그래서, PM에게만 팀워크가 중요하다는 것을 강조하는 것일까요?
그렇지 않습니다.
PM에게 팀워크가 중요한 이유를 이해하기 위해서는, 회사에 PM이 왜 필요한지 살펴보면 됩니다.
•
먼저 사이드 프로젝트를 예로 들어 보겠습니다. 팀 구성을 위해 팀원을 모은다고 가정 했을 때,
◦
내가 개발자나 디자이너라면 제발 와주세요!
제발 와주세요!◦
내가 기획자 혹은 PM라면 저 좀 데려가주세요..
저 좀 데려가주세요..•
물론 요즘에는, 개발자와 디자이너의 공급이 늘어난 만큼 PM의 수요 또한 늘었습니다. 그리고 수요와는 상관없이 이미 뛰어난 능력을 가진 PM에게는 연락이 빗발치고 있습니다. 그럼 사이드 프로젝트에 참여하기 위해서는 개발자나 디자이너가 되어야 한다는 의미일까요?
그렇지 않습니다.
사이드 프로젝트를 통해 기대하는 결과물은 그리 크거나 복잡하지 않기 때문에, 기획자 혹은 PM의 역할이 적거나 없다는 의미입니다. 역할을 잘 분배하고, 그것만 잘 수행한다면 큰 문제는 없을 것입니다.
•
하지만 회사에서 PM이 필요하다는 의미는, 단순히 사이드 프로젝트를 기획하는 것과는 많이 다를 것입니다.
◦
문제의 우선 순위를 정하고 지속적으로 제품을 개선하며, 목표 달성으로 이끌 사람이 필요하다는 것
◦
제품을 개선하려는 범위 혹은 문제해결의 목표가 작게 투닥투닥해 볼 수 있는 것이 아니라는 것
◦
문제를 아주 조사버릴(?) 메이커는 이미 존재하니, 한 팀으로 움직여 달라는 것
•
즉, 회사가 해결하고 싶은 문제는 그만큼 복잡하고 제품을 개선하여 달성하고자 하는 목표가 높기 때문에,
1.
수 많은 역할을 부여받은 구성원들이 회사에 모여있고
2.
제품의 지속적인 개선을 위해 이들의 역량을 최대한으로 발휘해야 하는 상황에서
3.
메이커들이 메이킹에 온전히 집중 할 수 있도록 → 제품을 리드할 사람이 필요한 것입니다.
•
PM은 제품의 목표를 달성하기 위해서 (회사에) 고용 되었기 때문에, 책임감을 가지고 혼신의 투닥투닥을 할 수 밖에 없습니다.
•
달성해야 하는 뚜렷한 목표를 이루고자 다양한 구성원과 함께 하므로, 대학교 과제나 사이드 프로젝트에서 경험해본 팀워크와는 차원이 다른 팀워크가 필요합니다.
싸늘하다. 가슴에 비수가 날아와 꽂힌다.
2. 어떻게 일해야 할 것인가?
더이상 강조하지 않아도 팀워크의 중요성에 대해서는 이미 여러분 모두 공감 하실텐데요.
PM에게 팀워크 역량이 필요한 맥락에 대해서 이해 한다면, 이후 내용도 빠르게 습득하실 수 있습니다.
그렇다면 PM이 팀 내에서 팀워크를 만들고 끌어올리기 위해, 왜 소프트 스킬이 필요할까요?(1) 지속적인 제품 개선이 필요하기 때문입니다.
•
당연하게도, 제품개선은 한 번에 이루어지지 않습니다. 물론 우리가 정의한 핵심 문제도 한 번의 스프린트만으로 해결되지 않습니다. 우리는 특정한 목표를 달성하기 위해서 지속적으로 제품을 개선 해야만 합니다.
•
PM은 문제를 해결하기 위해 도박을 하지 않습니다. 반복해서 실험을 할 뿐입니다.
그로스 해킹 - YES24
네이버, 이음소시어스, SK텔레콤을 거쳐 지금은 여행 스타트업 마이리얼트립(MyRealTrip)의 그로스실 실장(Head of Growth)으로 일하고 있다. 마이리얼트립의 데이터 분석과 마케팅, 구체적으로는 데이터 파이프라인과 핵심 지표 관리, 가설 검증, 성장 실험을 담당한다. 데이터를 이용해서 서비스와 비즈니스가 마주한 문제를 푸는 일에 관심이 많다. 작은 목표를 세우고 차근차근 달성해 나가는 것을 좋아...
http://www.yes24.com/Product/Goods/96576416
데이터와 실험을 통해 서비스와 비즈니스가 마주한 문제를 해결하는 ‘그로스 해킹’ 방법론을 소개하는 책 입니다.
•
제품 개선을 위해 구성된 하나의 스쿼드(Squed)*에서, PM은 함께 하는 구성원들과 이번 스프린트, 다음 스프린트, 이번 분기, 어쩌면 내년을 넘어갈 수도 있는 제품 개선의 순환고리에 함께 탑승하게 되었습니다.
(퇴사 혹은 조직개편 외에는, 당분간 그 순환 고리에서 빠져나갈 방법은 없습니다 )
)◦
스쿼드(Squed)란, 애자일 조직의 기초 단위를 의미합니다. 구성원(6~12명)은 작지만 프로젝트 수행에 필요한 개발자와 디자이너, 기획자 등이 포함되어 하나의 일을 처리할 수 있는 완결된 구성입니다.
한 번에 문제를 해결할 수 없는 것은 이해 했습니다. 그럼 지속적으로 팀을 유지하려면 무엇이 필요할까요?(2) What vs How
•
Why - 왜 이것을 해야 하는가?
•
How - 어떻게 할 것인가?
•
What - 무엇을 할 것인가?
•
팀의 방향 설정에 있어서, Why는 당연히 0순위이며 Why가 중요하다는 것은 더 이상 말할 필요도 없습니다.
•
가끔 우리 조직은 ‘Why에 대한 고민이 없다’, ‘시키는 대로 해야 한다’는 불만을 가진 분들이 있으실텐데,
(아마도) 다음과 같은 두 가지 경우 중 하나 일 것이라 예상합니다.
1.
(불만을 가진) 그 분이 Why에 대해서 충분히 이해 혹은 공감하지 못했다.
2.
윗선에서 (불만을 가진) 그 분께 Why를 공감 시키려는 노력을 하지 않았다.
•
보통은 첫 번째인 경우가 많습니다. ‘이걸 왜 해야 돼?’ 라는 의문은 왜 보다는 이걸에 방점이 찍혀있죠. 이런 경우에는 PM에게 두 가지 선택지 밖에 없습니다. → 들이받거나 / 수용하거나
(참고) “이끌거나, 따르거나, 비키거나!”
•
다시 본론으로 돌아와, 팀워크에 있어서 What과 How 중 무엇이 중요할까요?
◦
What: 우리 팀이 어떤 일을 해야 하는지
→ What에 능통한 PM은 더 효율적이고 빠르게 제품 개선을 가져오는 PM이 될 것입니다.
◦
How: 우리 팀이 어떻게 일을 해야 하는지
→ How에 능통한 PM은 어떤 제품 개선이든지 협업을 통해서 달성하는 PM이 될 것입니다.
•
즉, 정답은 없습니다. 각자 PM의 입장에서 집중하고자 하는 방향성에 따라서 다르기 때문입니다.
→ 하지만, How를 잊어서는 안됩니다. 왜냐하면 PM은 ‘지속적인’ 제품개선을 이끌어야 하기 때문입니다.
•
우리가 어떤 일(What)을 해야 하는지 명확하게 정의하여 구성원들에게 단기적으로 동기를 부여할 수도 있습니다. 그러나 어쩌면 이 일은 실패할 수도 있고, 아주 작은 걸음으로 시작하여 앞으로 반복될 이터레이션 과정에서 동기가 희석될 수 있습니다.
◦
보통 협업에 갈등이 생기는 사례를 보면 이러한 부작용이 드러나곤 합니다.
→ “아니 리뷰 할 때 분명히 이야기했는데, 이제 와서 이걸 못한다고 하는게 말이 되나요?”
메이커 : 그래서… 내가 뭐라고…… 했지….?
6개월 차 신입 PM : (흔들리는 동공)
•
하지만 어떻게(How) 일을 해야 할지 구성원들과 충분히 공감하고 합을 맞춰간다면, 실패할 가능성이 높아 보이거나 매우 천천히 진행되거나 하는 어떤 상황에서도 협업을 통해서 문제를 해결할 수 있습니다.
◦
왜냐하면 어떻게 문제를 해결 하는 지 우리만의 규칙을 찾았고, 문제 해결 과정이 명확하기 때문입니다.
◦
메이커는 매번 고민할 필요 없이, 우리가 달성해야 할 목표, 문제해결의 방향성에만 몸을 맡기면 됩니다.
물론 PM은 이 판을 깔기 위해서 엄청난 노력을 해야 합니다. Why, How, What의 의미에 대해서도 이해 했습니다. 이것만 준비되어 있으면 충분한가요?(3) 협업과 신뢰를 위한 소프트 스킬
•
재품 개선을 위해 지속적으로 운영할 팀을 구성하고, 구성원들과 Why, How, What에 대해 공유하며 같은 방향으로 가기 위한 준비를 모두 마쳤습니다. 이제 본격적으로 일을 시작하기 위해, PM이 ‘이렇게’ 문제를 해결하자고 제안했을 때 구성원들이 모두 문제없이 받아들일 수 있을까요?
◦
아마도 아닐 것입니다.
같은 Why를 공감하고 있더라도, 구성원들은 다양한 환경에서 여러가지 방법으로 일해왔기 때문입니다.
•
그래서 팀워크 향상의 첫 단추를 잘 채우기 위해, PM은 신뢰를 얻어야 합니다.
◦
팀워크를 형성하기 위해 필요한 것은 바로 신뢰입니다. 구성원 간의 신뢰도 중요하지만, 가장 먼저 팀의 구성원들이 PM을 신뢰할 수 있어야 합니다.
•
신뢰는 행동에서 나옵니다.
◦
PM이 모든 구성원들을 존중하고 있으며, 우리는 한 팀이라는 것을 행동으로 보여줘야 합니다.
◦
PM은 더 많이, 더 효과적으로 커뮤니케이션을 하며 메이커들의 의견을 적극적으로 수렴해야 합니다.
→ 인간적으로 동료가 되기 위하여, 소프트 스킬을 적극적으로 활용해야 합니다.
•
구성원들간의 신뢰가 확보된다면, 우리의 팀은 문제를 해결하는 과정에서 넘어져도 바로 일어날 수 있습니다.
◦
명확한 두뇌로 항상 성공하는 가설을 내놓는 PM이라면 상관 없을 수 있지만, 대부분의 사람들은 문제를 해결하는 과정에서 자주 벽을 만나거나 넘어지게 됩니다. 서비스 스펙은 코드에 더 명확하게 남아있기 때문입니다.
◦
팀원들과 리뷰하는 과정에서, 사전에 협의한 스펙이 변경되어야 할 때 “이거 안돼요” 보다 “이건 어때요?”로 커뮤니케이션을 시작할 수 있는 사람이 되었으면 좋겠습니다.
3. 요약 하자면, 이렇습니다.
•
PM이 해결해야 할 문제, 달성해야 하는 목표는 너무 복잡하고 크기 때문에 협업이 필요합니다.
•
협업은 일회성이 아니며, 지속적인 제품개선을 위해서 지속적으로 수행되어야 합니다.
•
PM은 지속적인 협업을 위해 어떻게(how) 일을 할지 구성원을 이끌어야 하고, 이때 필요한 것이 신뢰입니다.
•
PM이 신뢰를 얻기 위해서는 소프트 스킬을 적극적으로 활용해야 합니다.
(추가) 참고자료
다음 주제 →
Copyright 2022. ⓒ TeamSparta All rights reserved.
