PM이 개발자와 협업하는 법 - 소통편
개발에 대한 지식이 전무한 상태로 AI 스타트업 PM으로 커리어를 시작한 저는
입사 초기에 개발자와의 소통에 다소 어려움을 겪었습니다.
부끄럽지만 정확히는 개발자분들을 화나게 하는 PM이었죠. 😂
PM 입사를 앞두고 있거나,
이제 막 주니어 PM으로 입사해 과거의 저와 비슷한 행동을 하고 있는 분들이 계시다면
저의 경험을 공유해 적어도 개발자를 화나게 하는 PM이 되지는 않길 바라는 마음으로
이렇게 글을 적어봅니다!
1.그냥 해주세요...
“OO님, 고객사가 이거 필요하다고 해서 만들어주셔야 해요.”
입사 초기에 제가 개발자분들께 기계적으로 하던 말입니다.
그러면 개발자분들은 다소 일그러진 표정으로 이렇게 되물으시곤 했죠.
“근데 이거 왜 하기로 결정한건가요?”
“왜 이렇게까지 개발해야하는 건가요?”
처음에는 이런 개발자분들의 반응에 왜 이렇게 공격적으로 반응하지? 왜 이렇게 화가 났을까?
개발자들은 항상 안된다고 한다는 밈이 사실이구나.. 생각했지만
얼마 지나지 않아 저의 소통 방식이 완전히 잘못되었다는 것을 깨달았습니다.
개발 요청을 드릴 때, ‘왜 해야하는지’를 자세히 설명하는 과정은 생각보다 더 중요합니다.
PM이 개발자에게 업무를 요청드리는 것이다보니,
자칫 잘못하다가는 개발자 입장에서 단순히 PM이 시키는 일을 해야하는
하향식 의사 결정이 이루어진다고 느낄 수 있기 때문입니다.
그렇기에 왜 해당 개발이 필요한지 그 배경 맥락과 니즈를 상세하게 설명하여
개발자가 일의 필요성과 방향성에 대해 충분히 공감할 수 있도록 해주어야 합니다.
그 과정에서 이 작업이 해결해야 하는 ‘나의 일’이라고 느낄 수 있도록 만들어주는 것이 필요합니다.
이제는 개발자분들께 작업 요청을 드릴 때,
- 구체적으로 어떤 개발이 필요한지
- 그 이유는 무엇인지
- 이 작업이 갖는 효용/중요성은 무엇인지
- 어떠한 고민의 과정을 거쳐 이러한 형태로 구현하면 좋겠다고 생각한건지
배경 맥락을 상세하게 말씀드리고 있습니다.
여기에 개발자분들께 조언을 구하고, 도움을 요청한다는 뉘앙스를 조금 첨가하면
이 문제를 해결해주겠다는 의지로 활활 불타오르기도 하시더라구요. 🔥
2.(냅다) 이때까지 해주세요...
빠른 결과 확인을 원하는 고객사와 킥오프 미팅을 가진 후,
회사 구글 캘린더를 보며 일주일 뒤에 고객사에 결과를 전달드리기 위한 야무진 일정을 짰습니다.
‘내부 킥오프는 오늘 밤, 내부 결과 공유는 수요일 오후 4시쯤,
내부 공유시 피드백해서 개선된 결과는 금요일 저녁에 확인하고,
정리된 문서와 함께 다음주 월요일에 결과를 전달해야겠다.’
스스로의 계획에 만족하며 배정된 AI 엔지니어분께 다가가 일정을 공유드렸죠.
“다음주 월요일까지 빠르게 고객사에 결과를 전달해야하니,
오늘 밤에 간단히 저랑 킥오프하시고, ~~한 일정대로 진행하면 될 것 같습니다.”
돌아온 대답은 당연히 “(분노의) 절대 안돼요...” 였습니다.
특히 저희 회사의 경우, 한 AI 엔지니어가 n개의 프로젝트를 담당하는 구조이기 때문에
각 프로젝트의 진행 상황 및 가용 리소스를 잘 판단해 적절한 프로젝트 타임라인을 정해드려야 하는데요,
그렇기 때문에 평소에 각 엔지니어분들이 어떤 프로젝트를 담당하고 있는지,
각 프로젝트 별로 요구되는 리소스는 어느 정도인지에 대해 파악하여 일정을 조율하는 과정이 중요합니다.
요즘 제가 타임라인을 설정하고 전달드리는 방식은 다음과 같습니다.
1.타이트한 / 넉넉한 개발 일정이 잡힌 이유 공유
OO님, A 고객사에서 다음달부터는 신제품 출시 준비로 바쁘신 관계로
이번 달 내로 빠른 결과 확인을 원하셔서 최대한 빨리 개발 진행하면 좋을 것 같습니다.
2.개발자가 담당하고 있는 다른 태스크에 대한 고려/조정 및 우선순위 전달
현재 담당하고 계신 B,C 프로젝트는 어느 정도 마무리된 것으로 알고 있습니다.
D 프로젝트 함께 하고 계신 박 PM님께 여쭤보니, 그 프로젝트는 그렇게 급하지 않은 것 같더라구요.
그래서 D 프로젝트 타임라인 조정 부탁드렸습니다.
이 프로젝트 우선순위로 두고 작업해주시면 됩니다!
3.필요한 구현 수준 및 완성도 전달
빠른 결과 전달이니만큼, 완성도 100%의 결과보다는
기본적으로 이 정도 구현은 가능하다 정도만 보여주시면 될 것 같아요.
4.일정과 관련해 의견을 구하는 태도
최대한 개발 리소스 고려하여 타임라인 잡아보았는데, 괜찮으실까요?
개발 난이도를 고려해볼 때 너무 빡빡하시면 편하게 말씀해주세요.
어렵다면, 고객사와 조금 더 시간을 잡고 진행해볼 수 있도록 소통해보겠습니다.
그래도 최대한 위 일정에 맞춰서 진행해주시면 좋을 것 같긴 합니다.
3.(앞뒤 설명 없는) 안돼요... 안된대요...
입사 두 달차, 처음으로 제가 담당하고 있던 고객사로부터 ‘에러가 발생하고 있다’는 연락을 받았습니다.
1초만에 고객사에 확인해보겠다는 답변을 드린 후,
얼른 해결해야한다는 마음으로 담당 개발자분께 바로 디엠을 보냈죠!
“A고객사 안된다고 연락 받았습니다. 빠른 해결 부탁드립니다.🙇♀️”
그러자 담당 엔지니어분이 확인 후, 에러 발생 원인을 파악해 문제를 해결해주셨습니다.
그리고 한동안은 고객사로부터 오류 관련 연락을 받으면,
“OO님, XX 고객사 안된대요. 빠른 해결 부탁드립니다.🙇♀️”
라고 담당 엔지니어분께 정중한 이모티콘과 함께 연락을 드렸습니다.
빠르고 정중하게 문제 해결 요청을 드리는 나 자신 잘하고 있다!라고 생각하면서요.
그렇게 여느때와 같이 빠르게 문제 해결 요청을 드리던 어느 날,
담당 개발자님으로부터
‘좀 더 명확하게 문제 상황을 전달해줬으면 좋겠다’는 날선 피드백을 받았습니다.
결국 개발자분들이 문제 파악을 위해 로그를 살펴보셔야 하다보니
더욱 빠르고 효율적으로 문제를 해결하기 위해,
문제 상황을 구체적으로 정리해 전달해드리는 것이 중요하더라구요.
이후로는 아래와 같은 형태로 문제 상황을 전달드리고 있습니다.
- A 고객사에 제공하고 있는 B서비스에서
- ~~한 동작을 하던 중
- XX시 XX분 쯤에
- 서비스 장애 혹은 에러가 발생했습니다.
- 긴급도 ‘최상’이라 빠르게 해결 부탁드립니다.
이렇게 명확하게 문제 상황을 전달드리니,
담당 개발자님께서도 더욱 빠르게 원인을 파악해 문제를 해결하실 수 있었습니다.
가장 중요한 건...
PM과 개발자의 소통도 사실 사람 간 커뮤니케이션입니다.
그렇다보니 결국 그 본질은 인간적인 유대감이라는 걸 많이 느낍니다.
개발자와의 소통에 어려움을 겪고 있는 분들이 계시다면,
그들의 고충에 대해 먼저 공감하고 이해하려는 모습을 보여주고
자주 감사함을 표현해보시라고 말씀드리고 싶어요.
개발자분들도 문제를 해결하고 싶은 욕구와 인정에 대한 욕구를 가진 나와 같은 사람일 뿐이랍니다.
개발자분들이 어떤 어려움을 겪고 있는지 관심을 가지고,
그들의 역할을 인정해주며,
더 나은 소통을 위해 많이 노력하는 모습을 보인다면 (ex. 기본적인 개발 지식 갖추기, 피드백 요청하기 등)
개발자를 화나게 하지 않는 PM을 넘어 함께 일하고 싶은 PM이 되실 수 있다고 생각합니다.
긴 글 읽어주셔서 감사합니다. 😊
