프로덕트 매니저, 관계학개론
개발자와 관계 1편
요즘 PM(프로덕트 매니저), PO(프로덕트 오너)와 같은 직군의 수요가 IT업계에서 개발자 다음으로 증가하고 있는 추세이며, 그에 맞는 국비교육이나 부트캠프들도 우후죽순으로 생겨나고 있다.
클래스 101, 탈잉만 하더라도 어떻게 하면 PM 또는 PO로서 업무를 원활하게 진행하고 전문성 있는 포지션으로 성장할 수 있는지에 대한 스킬 셋을 상품화하여 많이 판매하고 또한 그에 따른 수요도 증가하고 있다.
PM, PO에 관련된 서적도 베스트셀러가 되고 있는 시점이다.
주니어 PM 1년 차가 되는 시점, 나는 여러분에게 기술적이거나 스킬적인 부분이 아닌 결국
'관계'관점에서 내가 얻은 인사이트를 전달하려고 한다.
주니어 PM에게 업무적인 능력과 스킬도 중요하지만 내가 가장 중요하게 생각하고 만들어야 하는 것이 바로
'관계'이기 때문이다.
업무적이거나 기술적으로 부족한 부분은 누구나 열심히 공부하고 따라가면 채울 수 있지만, 많은 PM들이 중간 단계에서 사라지는 이유가 바로 '관계'에서 지쳐서 사라지기 때문이라고 본다.
많은 포지션의 교집합에 위치한 PM은 더욱 이것으로부터 오는 스트레스가 극심할 것이다.
1~3년 차 주니어 PM에게서 가장 중요한 것은 '적응'과 '관계의 확장성'이라고 나는 본다.
결국 일은 '사람'과 함께한다는 것을 제발 기억해주었으면 한다.
아무리 능력이 좋아도 조직에 대한 정확한 파악과 조직원들의 관계 파악이 이뤄지지 않는다면, 혼자 독주하고 조직에게 실망하는 PM이 될 수 있기 때문이다.
https://platum.kr/archives/66506
어느 날, 개발자가 나에게 '미어캣'같다는 별명을 붙여주었다.
아무래도 나는 항상 다른 포지션의 이야기에 궁금하고 경청하는 자세를 가져야 하며, 문제가 발생하면 어디선가 불쑥 나타나서 '뭐가 문제예요?', '어떤 부분을 제가 해결하고 전달해드릴까요?"와 같이 발바닥에 땀나게 돌아다니고 이야기 듣고 전달하고 정리하고 팀을 이끌어가기 때문이다.
또한, 늘 긴장하면서 외부의 시장에 대한 흐름에 대해 늘 주시하고 있는 모습이 마치 경계를 서고 있는 미어캣이 생각난다는 것이었다.
오늘도 나는 긴장하면서 출근한다. 그리고 슬랙을 쳐다보고 있다사실 부인할 수 없는 이야기이다. PM은 마치 미어캣처럼 항상 긴장감과 예의 주시하며 여기저기 돌아다녀야 하며, 조직원들의 의견을 경청하고 하나의 핵심적인 차별성으로 모을 수 있어야 한다.
때론 여기저기의 불만을 듣기도 하고 또 때로는 이곳도 맞는 말이다 저곳도 맞는 말이다라고 해서 우유부단한 포지션이라고 생각될 때도 있지만, PM이 선택하는 결정 하나하나 또는 다음 액션이 조직에게 큰 영향력과 변화를 줄 수 있기 때문이다.
그중에서도 이번에는 PM이 어떻게 개발자와 관계를 구성해야 시너지를 만들 수 있는지
딱 주니어 PM 관점에서 전달하려고 한다.
#1. 선무당이 사람 잡는다. 어설프게 개발 용어를 아는 것보다 그냥 물어보는 습관을 가지자
PM이 되고자 하면, 꼭 한 번쯤은 시중에서 보았던 책이 있을 것이다.
비개발자도 이해할 수 있는 개발자 용어와 같은 워딩들의 책들이다.
물론, 이 책이 기본적인 개발자의 언어를 이해 나는데 도움이 될 수 있지만, 어디까지나 매뉴얼화되고 정형화된 용어들이다. 실제로 현업에서는 빠르게 사용하는 기술 스택과 개발자들의 언어가 변화하고 있기 때문에, 내가 알고 있는 앝은 지식으로 개발자에게 마치 그들의 언어와 메커니즘을 다 이해했다고 착각하고 다가서면 안 된다는 것이다. 그 순간, 여러분들은 앞으로 개발자와 계속해서 불협화음을 내기 시작할 것이다. PM이 그들의 세계와 프로세스를 존중해주지 않고 PM 식으로 해석하고 다가갔으니 말이다.
" 개발자님 궁금한 게 있는데, 이건 무슨 원리인 거예요?
"개발자님 또 하나 여기서 어떤 뎁스로 넘어가면 좋을까요?"
"개발자님 자꾸 여쭤봐서 죄송한데, 우리 조직에서 현재 적용 가능한 기술 스택이 어느 정도인가요?"
나의 무지함을 인정하고 물어볼 때, 개발자도 마음을 열게 된답니다. 나는 출근해서 부끄러움을 무릅쓰고 개발자에게 모르는 것이 있으면 직접 물어보고 정리하는 습관을 가지고 있다.
오히려, 안 물어보는 것보다 직접 물어보는 것이 PM으로서도 조직으로서도 빠른 성장에 도움이 된다고 생각한다. '괜히 물어봤나? 실력이 없다고 느끼면 어떡하지?'라는 고민에 빠질 시간에 직접 물어보는 것을 추천한다.
오히려, 개발자들은 기초적이고 기본적인 것을 물어보는 주니어 PM이 처음에는 못마땅해 보이지만, 개발언어와 환경을 이해하려고 부단히 노력하는 PM을 보면 개발자들도 장기적으로는 함께 회사에서 일을 해야 하는 또 다른 포지션의 동료 서서히 인식하기 때문에 협력하기 시작한다. 1년의 주니어 PM으로 현업에 있으면서 내린 결론 중 하나는 '세상에 못된 개발자는 없다.'이다.
#2. 좋은 기획을 했어도 공은 개발자에게도 전달하자
PM이 아무리 좋은 기획안을 그려도 그 기획안이 살아 숨 쉬게 만드는 개발자가 없으면, 휘발되는 아이디어 그리고 한 장의 상상화 그 이상도 이하도 아니라고 생각한다. PM이 주목받고 모든 포지션에서의 관심과 애정을 받는 포지션이라면 어쩌면 개발자는 정말 음지에서 우리의 조직이 정상적으로 돌아가게 알게 모르게 힘쓰는 포지션이라고 보아도 된다. 쉽게 생각해, 항해하는 배의 갑판에서 PM이 방향성 설정과 조직원들에게 동기부여를 전달하며 뱃머리 앞에서 지시할 때, 개발자분들은 우리의 배가 지정한 목표를 향해 갈 수 있게 열심히 노를 저어주는 역할을 해주시는 포지션이라고 비 융해서 생각하면 이해하기 쉬울 것이다.
눈에 보이지 않는다고 개발의 가치가 무시되어서는 안 된다결코, 그 가치가 무시되어서는 안 된다고 생각한다.
"이야, 이번 기획안이 정상적으로 갈 수 있었던 것은 개발팀에서 신경을 써주셔서 그런 것 같아요"
" 다음엔 이 부분을 한번 같이 상의해보시죠. 고생도 했는데, 오늘 간단하게 술이나 한잔하시죠. 금요일인데 ㅎㅎ"
평상시 나의 대화의 일부분이다. 결국, 모두에게 공적을 돌리면서 특히, 개발팀에게 더 티 나게 방점을 찍어서 이야기해준다. 그렇다고 너무 차별이 느껴지게 말하면, 다른 포지션이 서운할 수 있기 때문에 이 간 근은 아마 직접 시도하고 도전하면서 줄여 나갈 수 있을 것이다.
#3. 명확한 것을 좋아하는 개발자는 추상적일 때 더욱 당황하는 법
" 개발자님 이번에 신규 기능을 넣고 싶은데 화면 설계서로 하는 것이 편하세요? IA처럼 정보구조도 형식이 괜찮으세요?
"개발자님 어떤 방식으로 직관적으로 나타내 주는 것이 개발하는데 혼선이 없고 명확한지 여쭤봐도 될까요?"
"개발자님 제가 한번 구성해보았는데 이런 문서 양식으로 이야기하면 괜찮으실까요?"
업무를 진행하면서 내가 개발자와 커뮤니케이션을 하는 장면 중 한 부분이다.
개발자들의 세계는 '명확성'을 좋아한다. 쿼리를 구성하고 코드를 짜고 운영 프로세스를 만드는 개발자의 세상에서 '추상적인 표현'과 '모호한 지시사항'은 그들의 세계를 더욱 혼란스럽고 스트레스를 가져다주게 된다.
이는 개발자의 환경을 이해하고 눈높이를 맞춰야 한다.
결국 배가 어떻게 나아가야 하는지를 '노트'단위와 좌표로 설정해주어야 나아가듯이 개발이라는 것도 그냥 말로 오더를 하게 되면 표류하게 되기 때문이다.
그러면서도 우리의 개발자가 평소 익숙한 문서와 툴을 찾으려 노력하고 작성하여 중간 공유를 해주게 된다면, 개발자는 PM에게 나지 막 하게 인사이트를 전다 해준다.
오늘도 명확성을 갖추기 위해 개발자분들이 있는 자리로 찾아간다"샤넬로, 이 부분은 굳이 필요 없는 것 같고 여기까지만 그려주시면 제가 백엔드랑 이야기해서 개발해볼게요"
#4. 우리의 개발 기술 환경을 반드시 파악하자, 불행은 여기서 시작되는 법
많은 주니어 PM들이 유튜브나 IT 블로그를 통해 선도적으로 적용되는 개발환경에 매료되어 당장 조직에 도입시키고 기획을 하는 경우가 있는데, 이는 불행하게도 개발자와 불행이 시작되는 시발점이 될 수 있다.
가장 중요한 것은 내가 속한 조직의 개발 기술 환경과 적용 가능한 기술 스택을 파악하려는 자세가 필요하다.
어느 조직이건 모든 것을 잘 해낼 수 없다. 그리고 우리의 개발 범위와 능력을 벗어난 부분을 개발단에 요구하고 강압적으로 푸시하는 순간 조직이 망가지는 것을 나는 한차례 뼈저리게 경험도 하였다.
개발자들이 일을 하기 싫어서 그런 이야기를 하는 것이 아니다. 현재 단기적으로 실현 불가능한 목표를 가지고 성과와 구현을 요구하니 이러지도 저러지도 못하고 일의 방향성이 성립되지 못하니 일자체를 접근을 못하고 있을 뿐이다.
개발자도 사람이야 사람이라고 엉?!간혹, 경영진이나 간부들에게 목소리를 내는 개발자분들도 있지만, 대다수 개발자분들은 내색은 하지 않지만 깊은 한숨과 담배 연기를 마시며 하루를 버티거나 그 조직을 떠날 준비를 한다.
늘 말하지만 개발자는 마술사가 아니다.
#5. 개발자들은 퇴근 후에도 코딩만 생각할 것이라는 착각을 버리자
물론, 퇴근 후에도 자신의 커리어를 위해 코딩과 개발 언어를 열심히 공부하는 개발자분들도 많을 것이지만, 모든 개발자가 그런 루틴을 가질 것이라는 일반화를 가지고 개발자와 이야기를 진행하는 것이 다소 지양했으면 하는 바람으로 이 부분을 이야기한다.
사실, 개발자분들 중에서는 퇴근 후에는 와인 클래스를 다니시거나 드럼이나 디제잉을 배우시는 분들도 만났었다. 정말 퇴근 이후에는 개발자가 아닌 하고 싶고 도전하고 싶은 것이 많은 그 사람 그 자체가 되는 것이다.
예전에 퇴근 후 개발자와 일 이야기와 코드 관련 이야기를 한번 꺼냈다가
"샤넬로 님, 퇴근 후에는 그냥 따른 이야기 하고 싶어요. 리프레쉬도 하고 싶고요"라는 답변을 받았다.
어쩌면, 나도 큰 착각을 하고 있었다. 개발자는 하루 종일 코딩 생각만 하고 그런 이야기만 계속할 것이라는 것을..
하지만, 그들도 걸그룹, 정치 이야기 등을 좋아하는 나와 같은 사람이라는 것을 매번 퇴근 후에 느낀다.
별 거창한 노하우나 비법은 없지만, 정말 많은 분들이 이 거창하지 않은 것을 시도하지 못해서 조직 내 잡음을 만드는 경우가 정말 많다는 것을 나는 종종 현업에서 볼 수 있었다.
PM이 조금 더 다가가고 살갑게 이야기하고 모르는 것을 쉽게 인정하고 맞장구치며 리액션을 통해 그들을 이해하려고 시도하는 모습을 계속 보여주는 관계가 정말 중요하다.
협업이라는 관계는 입사를 했다고 바로 쌓이는 것도 능력이 좋다고 바로 형성되는 것도 아니다.
내가 잘 알지 못함을 인정하고 그들의 눈높이에서 도움을 갈구하고 협력을 요청하면서 감사함을 지속적으로 전달하기 시작할 때 만들어지는 것이다.
어떤가? PM이라는 포지션 정말 쉬워 보이면서도 감정노동도 많이 들어가고 힘들어 보이지 않는가?
그래도 PM으로서 그리고 주니어 PM으로서 성장하는 하루를 보내고 싶다면, 개발자와의 관계부터 형성하고 만들어가 보는 것은 어떨까?
PM을 꿈꾸고 준비하고 막 PM으로서 현업에서 고군분투하는 동지 여러분의 행운을 빈다.
