서로의 언어를 이해한 의사소통
PM스쿨_학습일지08
2024.03.04
지독한 장염이 끝나고 다시 치열한 공부의 현장으로 돌아왔다. 혹시나 필자의 성장 스토리를 함께 공유하고 있는 독자들이 있다면 최근 유행하고 있는 '노로 바이러스'를 꼭 주의하길 바란다.
이번 시간에 기록으로 남기고자 하는 내용은 크게 두 가지 이다. 첫째는 사람의 언어를 이해한 의사소통의 힘이고, 둘째는 동료 혹은 공동체의 힘이다. 먼저 이야기 나눌 의사소통에 관한 이야기는 사람으로 구성된 팀에서 결국 소통하는 주된 수단은 '언어'라는 것일 텐데, PM이 알아야 하는 사람들의 '언어'는 무엇이며, 어떤 영향이 있을까?에 관한 부분이다. 또한, 이어서 남길 동료에 관한 글은 마라톤을 완주하는데 있어 주변 동료 혹은 경쟁자가 어떤 도움이 되는 지에 관한 개인적인 감상평이다.
의사소통
사람은 혼자 살지 않는다. 더욱이, 각자의 역할을 인정하고 그 역할에 따라 수행한 일들의 총체인 서비스 혹은 상품을 만드는 IT 프로덕트 팀에서는 혼자 일한다(산다)는 것은 상상도 할 수 없는 일이다. 그렇기에 우리는 나 외에 다른 사람과 대화하는 법을 배워야 한다. 특별히, 건전한 대화를 하기 위해서는 적절한 의사소통에 관한 방법론을 인지하고 있어야 하며, 사실은 인지하는 것을 넘어 몸소 체득하고 그것을 사용할 줄 알아야 한다. 이번 학습의 주된 요지는 바로 팀원 들과의 적절한 의사소통 방법론이었다.
"각자의 언어로 서비스의 진행 상황을 점검하고, 공유할 수 있다면 좋은 의사소통을 하는 기획자이다."
목적 조직(Cross Functional Product Team)으로 이루어진 서비스 프로덕트 팀은 개발팀, 디자인팀, 기획팀 등으로 나누어 져있던 기능 조직을 '특정 목적'을 이루기 위해 각 역할을 담당하는 팀원들이 하나의 팀으로 구성되어 있는 것을 특징으로 한다. 쉽게 말하면, 하나의 목표를 이루기 위해 이전에 전문팀으로 흩어져 있던 구성원들을 하나의 작은 팀으로 만들었다는 것을 말한다. 이미 눈치채신 분들도 있겠지만, 각자 전문으로 하는 분야가 다른 경우에, 같은 사물을 보더라도 해석하는 방법이 다르고, 표현하는 말, 용어가 모두 다를 수 있다. 예컨데, 같은 물이더라도, 식품 영양의 측면에선 섭취의 대상으로, 운동의 측면에선 원료로, 화학의 측면으로 H2O로 인지되곤 한다. 심지어, 철학이나 인문 사회적으로는 아예 다른 지위이거나 다른 개념으로 접근도 가능하다.
그렇기에, 서비스를 기획하고 출시를 고대하는 기획자라면, 결국 일의 완성과 진행을 위해선 각 팀원들의 언어를 이해해야만 대화할 수 있다는 결론에 이르게 된다.
공통적으로 업무에 필요한 언어는 '데이터'에 기반한 정량에 관한 언어와 '현상에 이해'에 해당하는 정성에 관한 언어가 필요했다. 무언가를 결정해야 하고, 결정한 바를 통해 결과와 변화에 관한 방향을 설정하기 때문에 결국 결정을 위한 정확한 근거가 필요하다. 건전한 기획자라면 정량과 정성적 언어가 공통적으로 필요할 것이다.
이러한 것들이 잘 담겨있는 것이 각 서비스마다 기획자가 작성하는 정책서에 잘 표현이 되어 있다고 한다. 다양한 프로젝트의 경험이 없는 신규 PM에게 공통적으로 필요한 '정량', '정성'적 언어와 개발자 만의 언어, UI/UX 디자이너의 언어를 한눈에 살펴볼 수 있는 기회가 될 것이다. 어떤 데이터에 근거하여 무엇을 목표로 하고자 하는지, 누구를 어떻게 설득하고 있는지, 기획자는 개발 지식을 어느 정도로 함양하고 있는지, 디자이너에게 요구사항을 어떻게 제시하는지. 등의 수 많은 질문과 해결을 발견해낼 수 있었다.
경쟁자라는 동료
일주일 간 장염과의 사투를 벌이고 다시 학습의 현장으로 돌아온 필자의 눈에 가장 먼저 들어온 것은 바로 옆 칸에서 하루하루 열심히 과제를 해나가는 경쟁자이자 동료의 학습 스케줄표였다. 필자가 학습의 도구로 삼고 있는 PM스쿨은 강의와 과제의 진도에 관한 스케줄표를 구글 스프레드 시트의 형태로 모든 PM스쿨 참가자와 공유하고 있다. 쉽게 말해, 나의 학습 진도와 결과를 다른 PM스쿨 지원자가 볼 수 있다는 뜻이기도 하나, 나 역시 다른 지원자의 진도와 결과물들을 살펴볼 수 있다는 것이다.
어떤 때는 스케줄표를 공유하는 것이 부담인 경우도 있었다. 스스로는 잘했다고 생각했던 결과물이 비교의 잣대를 통해 부족한 결과물이 되는 것을 경험했을 때는 스스로의 능력에 관한 아쉬움이 생기고 했긴 때문이다. 하지만, 건강을 회복하고 돌아온 외로운 자리에 경쟁자라는 동료를 통해 다시 한 번 학습의 열의를 불태우는 시간을 가져보았다. 경쟁 체제의 순기능이 이러한 것일까? 스스로에 대한 인정과 타인에 대한 인정을 기반으로한 건전한 경쟁. 그것이 어쩌면 서로를 동료로 만드는 계기가 되는 지도 모르겠다.
마치며,
오늘 학습을 통해 팀원들과 협업함에 있어 정확한 서류가 필요하고 그 서류에는 각 팀원들이 사용하는 언어로 기능과 역할에 관하여 설명이 되어야 된다고 했다. 이 글을 쓰는 시점의 필자는 개발자, 디자이너, 등의 팀원들이 사용하는 언어를 사용할 수 있다고 인정하진 못하겠다. 하지만, 다른 서비스들의 정책서와 요구사항 정의서(PRD)를 계속해서 검토하고 분석하다 보면 조금씩 이해할 수 있는 날이 오지 않을까 생각해본다.
