Notice
Recent Posts
«   2024/10   »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
관리 메뉴

Sutella의 자기 발전소:)

PM이 알아야 할 Tech의 깊이? 이상적인 PM의 모습?_코드스테이츠 PMB 11기| QA (11) 본문

코드스테이츠| PMB 11/Review

PM이 알아야 할 Tech의 깊이? 이상적인 PM의 모습?_코드스테이츠 PMB 11기| QA (11)

Sutella 2022. 3. 15. 08:00
728x90
질문 1. 회사나 산업마다 다르긴 하겠지만 PM이 알아야 할 Tech의 깊이가 어느 정도까지인지 대략적으로 알고 싶습니다.
질문 이유

 이제까지 (나름의) IT 프로젝트를 경험하면서 개발자와 협력한 경험이 있다. 매우 초보적인 수준이긴 했지만 그때마다 내가 어느 정도까지 알아야 하는지 잘 몰라서 개발자들에게 엄청 많은 질문을 쏟았던 기억이 난다.

  • "이게 무슨 말이에요?"
  • "이게 이 의미인가요?"
  • "그냥 이렇게 하면 안 되나요?" --> 안 되기도 하고 그렇게 간단한 과정이 아님 (이 부분은 코딩을 경험하며.. 과거의 나를 반성...)
  • "이렇게 짜잔하고 얍! 했으면 좋겠어요!" -> 개발자) 이건 제 역량이 아닙니다.. --> "왜요?" (그분의 역할이 아니었다)
  • 기타 등등... 

출처: Pixabay

 이후 다른 경험을 쌓고 여러 자료를 접하며+ 오늘의 학습을 통해서도 PM이 개발에 대해 완전히 알 필요는 없다고 끊임없이 들었다. 하지만 프로젝트를 하면서 개발자와 소통하기 위해서는 어느 정도 필요하다는 생각이 계속 드는데... 뭔가 자세히 알자니 Program manager의 느낌이고, 너무 얕게 알자니 Project manager의 느낌인 느낌..? 그래서 한 오늘의 Q&A 질문!

그럼 대체 어디까지 알아야 할까?

답변

* 답변은 정확하게 옮긴 녹취록이 아닌, 답변을 들으며 간단히 작성했던 메모를 바탕으로 재작성했음을 알립니다:)

 

질문의 전제에 언급한 대로 회사나 산업 등 경우에 따라 다르지만, 크게 2가지로 나눠서 답변할 수 있다.

1. 개발자의 타입에 따라 다르다

 PM에게 물론 기초적인 수준의 Tech 지식이 필요하긴 하다. 기초적인 수준에 대해 명확히 정의 내릴 순 없지만, PM이 어떤 경험을 했는지에 따라 달라질 것 같다. 개발자가 동작이나 기능에 대해 자세히 설명해 주는 타입일 경우, PM에게 요구되는 개발 지식수준이 낮다. 반대의 경우, 당연하게 PM이 개발 언어나 기능 등에 대한 배경 지식이 더 필요하다.

 다만, 개발은 개발자의 영역! PM이 실제로 개발을 하는 것이 아니기 때문에 너무 사로잡힐 필요는 없다. PM에게 무엇보다 중요한 것은 "고객"이다. 고객에게 중요한 가치가 무엇인지, 그들이 어떤 불편을 겪고 있기 때문에 어떻게 해결할지 등에 초점을 맞춰야 한다.

➡ PM은 '고객'을 위한 사람! 개발 영역에 대해 너무 걱정하고 얽매이지 말자😊

 

2. 고객에게 보여주는👀 서비스인가?

출처: Pixabay

 Product가 고객에게 '보여주는' 서비스일 경우, (앞서 언급한 대로) 기술적인 부분보다 고객에게 전달해야 할 가치, 고객이 겪고 있는 문제 해결을 위한 부분에 대한 정리 및 집중이 중요하다. (여기서 말하는 고객은 '개인' 고객을 말하는 듯)

 반면, B2B 서비스나 백엔드 등 고객에게 보이지 않는 영역의 Product라면 얘기가 다르다. 특정 도메인을 대상으로 하거나 Logic이 중요한 부분이라면 해당 부분에 대한 기술 지식이 필요하다. 예를 들어 같은 커머스 플랫폼이라도 배송 process와 관련된 PM이라면, 해당 영역은 logical 하게 처리해야 하는 부분이 많다. 개발 부분에서도 관련 지식이나 해당 분야의 API 문서 등에 대한 이해를 위해 배경 지식이 필요하다. 즉, Logical 하게 처리해야 하는 분야, 혹은 System적인 Product/Project의 PM이라면 개발팀과의 원활한 협업을 위해 보다 많은 Tech 지식이 요구될 수 있다. 단, 이 경우에도 해당 분야에 대한 100%의 지식을 얘기하는 것이 아님을 인지하자. 

 물론, Product의 형태에 관계없이 해당 분야에 대한 지식을 알 수록 좋을 것이다. 그러나 '잘 모를 수 있다'는 것이 대전제이기 때문에, Tech를 너무 걱정하기보다 고객에게 더 Focusing 해야 한다. 

➡ Logical하거나 System적인 부분, Backend 영역의 PM에게는 Tech 지식이 더욱 요구될 수 있음 (for 개발팀)

* 단, 이 경우도 100% 수준의 지식은 X

 

 

질문 2. PM님이 생각하는 가장 이상적인 PM은 어떤 모습인지 궁금합니다.
질문 이유

 어릴 적부터 진로 시간에 빠지지 않았던 #롤모델에 대한 이야기. 하지만 PM의 경우 매우 다양한 분야에서 보다 복잡한 형태로 존재하고 많은 일을 수행하기에 누군가로 특정 짓기엔 사람에 따라 천차만별로 존재할 것 같았다. 또한, PM의 특성상 여러 부분에서 장점을 수집(?)하여 자신에게 흡수시킬 수 있다고 생각하여, 가장 이상적인 모습에 대해 여쭤봤다.

 

답변
PM이 없는 것이 가장 이상적인 PM!

출처: Pixabay

PM 없이도 팀이 잘 소통하고 협업하는 것이 가장 이상적이라 생각한다. 하지만 이상은 '이상(ideal)'일뿐인지, 이러한 생각으로 과거 구글에서 PM을 다 없앤 적이 있는데, 결국 실패했다고 한다. (결국 다시 PM 복귀ㅋㅋㅋ)

 

카멜레온? 젤리 같은 PM!

출처: 네이버 영화 '라푼젤' 스틸컷, Pixabay

 평소에는 그닥 좋지 않은 의미로 쓰이는 단어이지만, 답변해 주신 PM님의 의도를 잘 나타내는 표현이었다. 특히 PM님의 답변 중 인상 깊었던 부분은 "내가 어떤 문제를 해결할 수 있는지 나도 모른다"라는 표현이었다. 이 말만 놓고 보면 대책 없이 느껴질 수도 있지만, 미래에 대한 발전 가능성을 나타내는 의미로 다가왔다.

 '나는 어떤 문제를 해결할 수 있는 PM이야!'라는 자세보다, PM은 주어진 상황에 대해 잘 이해하고 적응할 수 있는 능력이 중요하다. (이는 PM의 포트폴리오 작성과 새로운 직장(?)에 갈 때, 갔을 때 등에 대해 설명하면서 언급된 부분이다.)  즉, 변화에 대해 두려워하지 않고 잘 적응하고 대응하는 모습이 이상적이다. 새로운 환경에 놓였을 때 Tool에 어색하고 분석을 잘 못하는 경우도 있을 것이다. 하지만, 환경에 점차 적응하는 모습을 보이면서 동료들에게 신뢰를 쌓을 수 있다. 이를 통해 동료들의 도움을 받을 수도 있으니, '적응력'은 중요한 역량으로 꼽힐 것 같다. 

 이때 카멜레온과 젤리를 예로 드셨는데, 카멜레온처럼 주어진 상황에 잘 맞춰 변화하는 모습을 말씀하셨다. 젤리의 경우 (약간 본래 의미와 다르긴 하지만) 틈새를 잘 파고 들어가서 회사에서 원하는 걸 채워줄 수 있는 사람이 되야 한다고 비유하셨다. (기존에 있던 회사의 톱니바퀴/소모품과는 다른 의미! 그리고 본 교육 자체가 '취업'을 목표로 하다 보니 이에 맞춰 적절하게 설명해 주신다. 이런 비유가 기분 나쁘기보다 오히려 더 와닿는 설명이라 좋았다)

 


 오늘의 Q&A 기록은 여기까지! 혹시 코드 스테이츠 관계자분들이나 지나가시던 현직자 분들이 이 글을 보신다면... 잘못 이해한 부분이나 설명, 혹은 본인의 의견을 남겨주시면 감사하겠습니다🥰

728x90