올해 상반기에 대학 졸업 이후 취업에 성공하고 백엔드 개발자로 일한 지 어느덧 3개월이라는 시간이 흘렀습니다.
이 과정에서 많은 일이 있었고, 많은 것을 경험하고 느끼며 내가 개발자로서, 어른으로서 더욱 성장할 수 있었습니다.
치열한 현장에서 직접 땀을 흘려보니 과거의 노력이 값진 순간임을 알게 되었고, 겸손하고 더욱 노력해야 함을 알게 되었습니다.
학부 시절에 작은 프로젝트를 진행하면서 느낀 부분들과 현업에서 느끼는 부분은 크게 다르지는 않았지만, 그 '농도'는 달랐습니다.
자신의 직군에서 다른 직군을 이해하기는 어렵습니다. 그러나 특히 현업에서는 그러한 이해관계들이 매우 중요하고 좋은 관계를 유지할 수 있도록 노력해야합니다. 그러나 이 이상적인 내용을 적용하기 어려운 상황도 분명히 존재하기 마련입니다.
그러면 여기서 가장 중요한 포인트는 무엇일까요? 제 생각은 다음과 같습니다.
자신이 손해를 보고 자신을 깎아가며 남을 이해하고자 하는 것은 옳지 못합니다.
단지 상대방을 있는 그대로 받아들이되 자신의 경계 안에서 적정한 선을 만들어서 그 시각에서 남을 바라보며 이해할 줄 알아야 합니다.
자신과 남이 다름을 이해할 줄 알아야 하며, 폄하할 필요도 없습니다.
되도록 상대방과의 대화에서 논란의 여지가 생기거나 감정을 섞는 말을 안 하는 것이 좋습니다.
언행에서 감정이 드러나게 되면 듣는 사람 입장에서 그 사람에 대해 평가를 하게 되며 그 사람을 감정적인 사람으로 낙인 찍을 것입니다.
저는 좋은 가치를 남에게 전달할 수 있는 개발자가 되고싶습니다.
저는 '기획자'의 성향도, '개발자'의 성향도 가지고 있습니다.
때문에 다양한 직군이 가진 문제점과 해결하는 방법에도 매우 관심이 있습니다.
과연 어떻게 더 좋은 결과물을 만들어 낼 수 있을까?
어떻게 팀원에게 더 잘 설명해줄 수 있을까?
우리 팀은 어떻게 성장할 수 있을까?
어떻게 하면 사용자에게 최상의 경험을 제공할 수 있을까?
데이터를 어떻게 하면 더욱 효율적으로 관리할 수 있을까? 등등
어떤 문제를 발견하고, 문제를 개선하기 위해 머리를 싸맸던 학창시절의 기억이 떠오르고, 사용자의 입장에서 어떤 좋은 경험과 사용성을 전달해줄 수 있을지 많은 고민을 했습니다. 그 중심에는 팀원들과 각 역할들이 있었고 결코 직군끼리 분리하는 것이 아닌 같은 방향을 지향해야하는 점이 가장 중요함을 알게 되었습니다.
오늘은 프로덕트의 선봉장인 PM에 대해 작은 이야기를 나눠보려 합니다.
간단하게 PM이 어떤 직군인지 설명하자면
PM (Product Manager) 프로덕트의 기획자입니다. 회사, 업계마다 조금씩 용어는 상이하지만, 비슷한 맥락을 가지고 있습니다.
더 좋은 지향점을 목표로 팀원들을 이끌고, 프로덕트를 설계하며 최종 목적지에 도달할 수 있도록 이정표와 같은 역할을 합니다.
대규모 프로젝트나, 규모가 큰 회사나 체계가 잡혀가고 있는, 잡혀있는 회사에는 PM 직군이 따로 존재합니다.
PM이 있냐 없냐 차이는 매우 크며 좋은 프로덕트를 만드는데 필수 요소라 생각합니다.
그럼 과연 개발자가 생각하는 좋은 PM과 나쁜 PM은 무엇일까요?
본 내용은 [우아한 형제들] 개발자가 생각하는 좋은PM과 나쁜 PM을 보고 정리한 내용입니다.
1. 동기 유발을 하는 PM
PM은 컨트롤 타워와 같습니다. 캐리비안의 해적에서 마치 잭 스패로우(조니뎁) 같은 역할이죠?
팀원들에게 명령을 내려서 팀원들이 자신이 잘할 수 있는 일들을 해내도록 팀원(선원)들의 능력치를 끌어내야 합니다.
((전)우아한 형제들 김영한님)이 말하길 좋은 PM은 은근히 이 스킬을 잘 사용한다고 합니다.
PM이 자신의 일을 합니다 ( 여기서 자신의 일은 프로덕트에 관한 고민 ) ->
자신이 고민하고 결론 내린 부분을 개발자에게 툭 던집니다. -> 그럼 개발자는 이 내용을 흥미있고 나의 일이라 생각할까요?
단지 그냥 위에서 주는 order 이상 이하도 아니지 않을까요?
PM이 혼자서 고민하고 내린 결론을 바탕으로 개발자에게 전달하는 이 일을 받아서 하는 입장에서는 과연 나의 일이라고 받아들여 질까요?
개발자는 자신이 흥미있어하고 하고싶어 하는 일을 할 때 "나의 일"이라 생각하고 흥미도 높아질 것입니다.
그래서 좋은 PM은 이러한 고민속에서 이렇게 솔루션을 내립니다.
PM이 자신의 일을 합니다 ( 여기서 자신의 일은 프로덕트에 관한 고민 ) ->
자신이 고민하고 결론 내린 부분을 개발자에게 툭 던집니다. -> 이때 그냥 "툭" 던지는 것이 아니라 고객의 관점과 가치, 데이터 등 다양한 관점에서 설명을 개발자가 납득할 근거를 제시하며 소통의 창구를 열어 놓습니다.
그래서 기획 단계에서 개발자가 참여하는 듯한 느낌이 들도록 만드는 것 이 내용이 가장 중요하고 개발자의 입장에서 "나의 일"이라고 느끼는 순간이 옵니다. 이러한 피드백 사이클로 인해서 개발자와 기획자는 서로를 이해하고, "나의 일"을 즐겁게 할 수 있습니다.
기획자는 개발자가 적극적으로 개입하게 상황을 만들어줘야 합니다.
그 이유는 개발자는 내가 의견을 내고 개선할 수 있다는 느낌이 중요하기 때문입니다.
PM은 다른 직군에 비해 인간적인 유대가 더욱 필요합니다.
그 이유는 타 팀, 부서, 직군과 커뮤니케이션 할 일들이 개발 직군에 비해 더 많으며 사람을 상대하는 일을 많이 하기 때문입니다.
그렇기에 기획자는 개발자에게 신뢰감을 주어야 합니다. ( I believe you )
기획자가 개발자에게 주는 작은 신뢰감이 가지고 올 effect는 매우 크며 상호 커뮤니케이션의 벽이 낮아집니다.
개발자 스스로 더 쉽게 피드백을 이야기 하며, 더욱 적극적으로 참여할 수있도록 격려가 되기 때문입니다.
마법의 단어 [ "고민이 있어요" ]
나쁜 PM은 혼자서 일을 다 하려 합니다.
예를 들어 일정을 선택할 때, 자신이 일정을 파파 박 다 짜서 개발자에게 '툭' 던지기만 하는 PM은 좋은 PM일까요?
개발자가 참여한다는 느낌을 받을 수 있을까요?
좋은 PM은 기획 외적인 부분 윗 예시와 동일하게 일정을 같이 개발자와 논의하고 우리가 다 같이 일을 해나가고 있다. 라는 느낌을 주는 것이 중요합니다.
그리고 업무의 우선순위를 개발자와 한 번 더 논의하는 것이 중요합니다.
PM이 먼저 우선순위를 다 정하되 우선순위와 관련해 개발자와 한 번 더 이야기하고 개발자에게 내가 일을 참여하고 있구나 라는 느낌을 느끼게 하는 것이 중요합니다.
기획자는 개발자에게 참여하고 있다. 라는 "느낌", 이 "느낌"을 들게 하는 것이 좋은 PM이라고 합니다.
2. 깊이 있는 정책을 이해하는 PM
좋은 PM은 본인 도메인에 대해서 이해도가 깊고, 업무 프로세스, 데이터 흐름을 알고 있는 PM입니다.
버튼 하나를 누르더라도 어떤 기능들이 필요하고 어떤 정책을 가지고 있는지 줄줄이 소시지 처럼 말할 수 있어야 합니다.
결국 깊이있는 서비스 개선을 위해서는 깊이 있는 정책과 프로덕트에 대한 이해가 필요합니다.
이런 PM이 있으면 개발자 입장에서는 매우 든든하고 신뢰가 생기지 않을까요?
3. 대충 개발 시스템을 이해하는 PM
개발자 업무의 전반적인 프로세스를 이해하는 것도 좋지만 꼭 그럴 필요는 없습니다.
그러나 대충 개발의 시스템을 이해하고 있고 없고의 차이는 매우 큽니다.
나쁜 PM은 그냥 "개발자가 알아서" 라는 뉘앙스를 심어주는 PM입니다.
좋은 PM은 전체 조직과 시스템 관점에서 프로세스와 데이터의 흐름을 아는, 업무 프로세스와 데이터가 시스템이 어떻게 톱니바퀴처럼 돌아가는지 이해가 필요합니다.
이정도만 이해하고 있더라도 좋은 PM이라 생각하고 좋은 리더라고 생각합니다.
현업에 와보니 컨트롤 타워는 매우 중요함을 알게 되었습니다. 각 팀의 팀장 이상 급이 컨트롤 타워의 역할을 하기도 하지만 때론 PM이 컨트롤 타워의 역할을 하기도 합니다. 그래서 이 PM직군이 제시하는 방향성이 중요함을 알게 되었습니다. 사공이 많으면 배가 산으로 가는 것처럼, 각자가 맡은 업무에 최선을 다하기 위해선 모든 팀원들이 지향하는 목표점에 도달할 수 있는 동기와 느낌이 필요합니다.
그런 동기와 느낌을 심어주는 것은 PM의 역량이자 능력이라 생각합니다.
이렇게 이번 포스팅에서는 좋은 PM, 나쁜 PM에 대해서 깊이 있는 고민을 해보고 방향성을 [우아한 형제]들 PM팀과 해보았습니다.
외에도 좋은 의견들이나 인사이트가 있으시다면 댓글 남겨주시면 감사하겠습니다.
'회고와 생각정리' 카테고리의 다른 글
| 2024년 회고 (0) | 2025.01.11 |
|---|---|
| 3주차 - 개발일지 및 회고록 (2) | 2022.10.23 |
| 2주차 - 개발일지 (0) | 2022.10.23 |
| 1주차 -개발일지 (0) | 2022.10.19 |
| 사전 캠프 Day_1을 마치며.. (0) | 2022.10.19 |