개발자가 프로덕트매니저에게 진짜로 원하는 5가지
개발자가 무엇을 원하는지 제대로 아는 PM이 되자.
이번 글을 제 자랑으로 시작을 해서 좀 쑥스럽긴 하지만, 글의 내러티브를 만들려고 하니 큰 이해 부탁드립니다.
제가 근무하는 SAP에는 서로 업무를 하면서 도움을 받았거나, 어떤 동료의 업무능력이 좋았다고 판단이 되면 사내 시스템을 통해서 그 동료를 칭찬해 주는 감사 프로세스가 있습니다. 물론 이런 서로간의 감사를 해주는 프로세스는 상호간에 동기부여도 되고, 인사시스템에도 반영이 되고 하겠지만, 이런 칭찬을 받는것은 PM에게 꽤나 중요한 일입니다. 첫번째는 함께 일한 동료들이 직접 평가를 해 주었기에, 무엇보다 공정할 수 있구요, 두번째가 중요한데요. 이 칭찬을 바탕으로 다음 프로덕트를 구성할때 좋은 개발자, 디자이너들과 팀을 꾸릴 수 있는 유용한 자산이 되기 때문입니다. 그들이 인정하는 PM이란 뜻이 됩니다. 좀 더 쉽게 설명하자면, 사내 레퍼런스 스코어 같은 것이라고 할 수 있을텐데요. 제가 지난주에 이런걸 하나 받았답니다. (물론 자주는 아니지만 가끔은 받는 사람입니다. ㅎㅎㅎ)
제가 오늘 하고 싶은 이야기가 바로 그 수상 이유 'Build bridges, not slios'입니다. "사일로를 만들지 않고, 다리를 만들었다"인데 바로 커뮤니케이션에 대한 이야기겠죠. PM에게 있어서 커뮤니케이션은 가장 중요한 덕목이 맞죠.
그 외에도 개발자가 좋아하는 PM의 덕목은 여러개 있을 수 있습니다. 그런 의미에서 오늘은 개발자가 프로덕트매니저에게 진짜 원하는 5가지 제 업무 노하우를 몽땅 정리해 보려합니다.
제가 예전에 쓴 글 중에도 비슷한 내용의 글 개발자와 PM이 (매우) 사이좋게 잘 지내는 방법 이 있긴 합니다. 이 글을 조금 더 버전업했다고 생각하시면 될것 같습니다. 지난번의 글을 상호관계를 보고 기술하였다면 오늘의 글은 그동안 개발자들과 일하면서 그들의 피드백을 중심으로 개발자 관점 (사실 저도 개발자 출신의 PM입니다.)에서 원하는 PM의 덕목들을 소개할까 합니다.
1. 투명한 커뮤니케이션
PM이 가져야 할 최고의 기술이며 덕목입니다. PM은 모든 인포메이션과 메세지 흐름의 중심 허브입니다. 상대하는 스테이크 홀더의 입장을 다 이해해야 하고, 그 입장을 잘 정리하여 다른 쪽에 전달하거나 설득하고 협상을 해야 합니다. 한쪽에 비즈니스 이해관계자(고객, 사용자, CEO, 매니지먼트 리더십, 마케팅, 교육, 사용자지원팀 등)가 있다면, 다른 한쪽에 프로덕트 엔지니어링 팀(CPO, 아키텍트, 개발팀, 디자인팀, QA팀, DevOps, 미디어팀, 커뮤니케이션팀 등등)이 있습니다. 모두가 이야기하고 요구하는 것들을 맞추어야 합니다.
특히 중요한것은 단순히 한쪽에서 듣고 다른 한쪽으로 옮기는 메신저의 역할이 아니라는 것입니다. 고객의 비즈니스 요구 사항을 들을 때면 고객이 이해할 수 있는 비지니스 언어를 사용하다가, 개발자에게 전달 설명할 때는 개발자의 언어로 번역하여 이야기를 전달해야 합니다. 이것을 위해 PM은 누구에게라도 본인의 프로덕트에 무엇을, 왜 구축해야 하는지에 대해 명쾌하게 설명 할 준비가 되어 있어야 합니다. 그런 면에서 기능에 대한 기대치가 명확하지 않거나 해당 기능이 제품에 가져올 가치를 확실하게 이해하지 못하는 경우 개발자에게 그 정보를 전달하는것은 불가능합니다. 개발자에게 설득이 가능한 데이터를 준비할수 있다면 개발자와는 더 쉽게 동기화할 수 있습니다. 그것이 왜 필요하고 어떤 영향력을 만드는 것인지를 설명하는 과정에서 투명하면서 명확한 커뮤니케이션만큼 필요한 것은 없습니다.
2. 시간 관리
고객/사용자와는 Roadmap에 있는 타임라인을 지켜야하는 것처럼 개발자가 가장 예민해하는 시간을 잘 관리해 주는 것입니다. 개발자에게는 항상 코드 프리즈(code freeze)와 같은 마감일(due date, deadline)이 가장 중요합니다. 이런 날짜를 미리 미리 소통하여 현명하게 처리하는 것은 소프트웨어 개발자가 PM에게 기대하는 것중의 하나입니다. 요즘엔 이런 일을 PM보다는 스크럼 마스터가 대신 하기도 합니다. 그러나 경우에따라, 내부 개발 일정이 자꾸 지연되는 경우, 그 일정을 외부와 조율하며 맞추어 나가는 것 역시 프로덕트매니저의 역할이며 능력입니다. 무엇보다 무작정 정해진 시간과 일정에 집착하여 진행하기 보다는 개발자의 의견과 상황을 이해하고 조율하면서 시간을 관리하는 PM을 개발자들은 신뢰하고 존중합니다.
3. 신속하고 일관성 있는 대응
개발자가 PM에게 바라는 또 다른 기대는 제품 관련 질문과 의문점에 신속하고 명확하게 응답을 해주는 것입니다. 때로는 개발 과정에서 제품 사양을 구현하는 과정에서 일부 항목을 쉽게 놓치거나 방향이 다르게 개발이 진행될 수 있습니다. 이것은 아직 개발 단계이고 PM이 발견한 시점이 하나의 스프린트가 끝나기 정도의 타이밍이라면, 절대 큰 문제는 아닙니다. 그것에 대해 프로덕트 매니저가 피드백을 명확하게 제공할 수 있다면, 개발자의 시간은 오류를 잡기 위해 최소한으로만 소모될 수 있습니다. 당연히 개발자가 좋아하는 PM의 덕목이겠죠.
4. 프로덕트 전략과 개발을 지표 기반으로 진행
많은 개발자들은 프로덕트 백로그가 할당이 되면, 그 효과나 가치를 보지 않고 맹목적으로 구현에만 집중하는 개발 경향이 있습니다. 하지만, 사용자는 프로덕트나 서비스에 담긴 기능을 보고 구매를 하는 시대는 지났습니다. 그것이 사용자의 '왜'를 해결할 수 있는 프로덕트일때 매력과 충성도가 올라갑니다. 항상 개발자에게 백로그를 설명하고 이것이 사용자에게 얼마만큼의 가치를 생성하는 것인지를 설명하면, 개발자로 부터 동기부여를 끌어 올 수 있습니다. 또한 이 방법은 PM과 프로덕트 리더십팀이 수립한 프로덕트 전략과 방향이 일치하게 되므로 모든 구성원이 한 방향을 보고 진행할 수 있게 됩니다. PM의 일과는 늘 새로운 분석 지표를 고안하고, 생성되는 지표를 활용하여, 다음 결정을 하는데 사용합니다. 정량화 가능한 결과 또는 결과 계획에 따라 무엇을, 왜 구축해야 하는지에 대한 지식을 가진 개발자는 PM 과 동기화가 되고, 생산성과 품질이 업그레이드 됩니다.
5. 개발자의 가려운 곳을 미리 알고 긁어주기
팀에 효과가 있는 것과 그렇지 않은 것을 발견하고 발전시키는 것은 좋은 PM들이 가진 공통 특성입니다. 프로덕트 개발 사이클이 끝났을때 워크플로를 개선 (예를 들어 CI/CD 파이프라인을 빠르게 진행하기 위한 방법, Acceptance 테스팅을 위한 최소 기준등) 하기 위해 개발팀에 아이디어를 제시하거나 개발자로 부터 아이디어와 피드백을 받아 다음 사이클에 반영하는 것은 개발자와 PM 관계를 다른 차원으로 올려줍니다. 이를 위해서 PM은 는 전체 소프트웨어 개발 주기를 향상시킬 수 있는 여러 도구에 대한 다양한 지식을 갖고 있어야 합니다. 예를 들어 다양한 문서 도구, 메트릭 도구, 세션 기록 도구, 애자일 프로세스 도구 및 해당 기능에 대한 지식이 있으면 더 나은 결정을 내리는 데 도움이 되며 그에 따라 개발 팀도 신뢰하에 적합한 것을 선택할 수 있습니다.
개발자가 좋아하는 PM은 자기를 신뢰하고 믿어주는 PM입니다. 개발자로부터의 신뢰를 얻기는 생각보다 그리 어렵지 않습니다. 그들이 개발에 집중할 수 있도록 주위의 여러 조건들을 미리 미리 세팅하고 알려주고 솔직하게 커뮤니케이션을 하면 됩니다. 개발자가 좋아하는 PM은 팀을 리드하고 품질 좋은 프로덕트를 릴리즈 할 가능성이 매우 높습니다. 하루 하루의 새로운 도전을 하시는 여러분 모두를 응원합니다!
