PM은 여러 직무와 긴밀하게 협업하면서 하나의 프로덕트를 완성합니다. 특히 개발자와 자주 소통하면서 제품 개선을 이끌죠. 그런데 어떻게 해야 개발자와 좋은 시너지를 낼 수 있는지 모르는 PM도 많습니다. 양방향 협업이 아닌 단방향 소통도 흔히 발생하는 문제입니다.
단방향으로 소통하는 기획자 / 제작: 퍼블리
결국 제품 개발도 딜레이되거나 초기 구상과 다른 제품이 구현되는 등의 이슈가 생겨납니다. 어떻게 하면 PM이 개발자와 원활히 소통하며 프로젝트를 리드할 수 있을까요? 이 아티클에서는 개발자로 커리어를 쌓으면서 경험한 것을 바탕으로 '일잘 PM'에 대해 이야기해 보려고 합니다. 개발자와의 협업에 어려움을 겪는 PM, 서비스 기획자에게 좋은 힌트가 되기를 바랍니다.
✍아티클 끝까지 읽고 체크리스트 받아가세요!
개발자는 이래서 PM이 필요합니다
1. PM은 개발자의 업무를 객관적으로 판단해 줍니다.
생각보다 많은 개발자가 업무에 들어가는 리소스를 측정하는 데 어려움을 겪습니다. 보통은 주어지는 업무의 크기나 양을 작게 측정하는 경향이 있죠. 반대로 작업하는 속도나 달성 가능한 퍼포먼스는 현실보다 크게 상정하고는 합니다.
다음은 개발자가 업무를 과소평가한 예시입니다. PM은 일정을 정하는 스프린트 미팅이나 개발 업무에 대해 소통하는 자리에서 비슷한 일을 자주 경험합니다.
👨💻개발자: "이거, 어려운 작업은 아니에요." 🦸♀️PM: "그러면 이번 스프린트에도 끝낼 수 있을까요?"
👨💻개발자: "네, 금방 끝나서요. 무조건 할 수 있어요."
(스프린트가 끝날 때쯤)
👨💻개발자: "아, 코딩은 얼마 안 걸리는데, 그 외에 부가적인 작업들이 시간을 많이 잡아먹네요."
위와 비슷한 패턴으로 일정이 딜레이된 경험이 누구나 한 번쯤 있을 거예요. 이런 상황은 개발자가 자신의 퍼포먼스를 '프로그래밍 시간'으로만 재기 때문에 생깁니다. 요리를 예로 들면, 요리사가 재료 구매 및 손질 시간을 잊고 '조리 시간'만 체크해서 답변하는 것과 같습니다. 개발자에게는 업무를 추정해주고 객관적으로 계획을 조율해줄 PM이 필요합니다.
2. PM은 개발팀의 팀워크와 생산성을 향상합니다.
회사의 오너들은 개발자를 더 많이 뽑으면 퍼포먼스가 즉시 향상될 거라고 기대합니다. 실제는 그렇지 않습니다. 〈맨먼스 미신〉의 저자 브룩스는 다음과 같은 '브룩스의 법칙'을 이야기합니다.
"지체되는 소프트웨어 개발 프로젝트에 인력을 더하는 것은 개발을 늦춘다."
소프트웨어 제작의 생산성은 복합적인 요소에 의해 결정됩니다. 자동차 생산 등 기계의 가동률이 중요한 업무는 더 많은 인력을 투입해서 생산성을 키울 수 있습니다.
하지만 소프트웨어의 생산성은 제품의 비전에 공감하는 개인이 기술적 역량을 발휘하는 데 달려 있습니다. 즉, 단순 가동률로 측정할 수 없으며 팀의 비전과 개인의 얼라인먼트(alignment)* 정도를 따져봐야 합니다. 개발자 충원 시에 얼라인먼트를 통해 생산성 향상을 이끌어주는 핵심 인물이 바로 PM입니다.
* 목표나 방향을 일치시키는 것
제가 경험한 동료 중에 능력 있고 일 잘하는 PM은 구성원을 존중하면서 팀 퍼포먼스를 끌어올렸습니다. 그들이 가진 어떤 역량이 개발자의 입장에서 '일잘'로 느껴졌는지 구체적인 예시를 들어 말씀드리겠습니다.
퍼포먼스를 키우는 온보딩
일 잘하는 PM은 팀 문화와 온보딩을 중요시합니다
퍼포먼스를 향상하는 지름길이 있습니다. 바로 온보딩(onboarding)*입니다. 특히, IT 업계는 이직이 잦고, 주니어는 물론 시니어 레벨까지 유입과 이탈이 자주 일어납니다. 애써 닦아온 팀 문화가 흐지부지되는 경우가 다반사죠.
* 배에 올라탄다는 뜻으로, 새로 온 직원을 효과적으로 조직 구성원으로 잘 정착하게 해주는 프로그램을 의미한다.
