커뮤니케이션
여러 팀원과 함께 제품을 만들다 보면, 자연스럽게 커뮤니케이션의 형태에 대해서 고민하게 됩니다. PM이 정의하는 문제 및 해결방안, 요구사항에 대해서 메이커들이 이를 디자인하고, 구현하고, 분석하는 형태가 되다 보니 PM이 업무 요청 또는 업무 지시/할당을 진행하게 됩니다. 물론 훌륭한 조직에서는 메이커들이 스스로 이를 판단하여 업무를 진행하기도 합니다.
PM의 요구사항을 기반으로 업무를 진행하다 보니 메이커들은 자연스레 PM의 의사결정에 주목하게 되고, 의사결정의 배경을 궁금해합니다. 본인의 시간을 할애하여 업무를 수행할 필요가 있는지, 본인이 주체적으로 업무를 진행할 수 있는 요인이 무엇인지, 본인이 동기부여가 되는 일인지 등 그 궁금함의 배경은 여러 개가 있을 수 있겠지요. 결국 PM은 이들에게 요구사항과 의사결정의 맥락에 대해 설명하고, 설득해야 할 필요가 있습니다.
이번 글은 PM이 마주하는 여러 충돌 중에서 팀 내 커뮤니케이션에 대한 경험을 통해 느낀 점을 적어보았어요. 글의 순서는 아래와 같아요.
1. 충돌
2. 피할 수 없다면 강하게 밀어붙여봐?
3. 그럼 어떻게 하는 것이 좋을까?
4. 충돌은 오히려 좋아
충돌
PM이 업무를 수행하는 과정에서는 수많은 이해관계자들이 존재하고, 각각은 저마다의 생각을 가지고 있기 때문에 당연히 수많은 문제에 직면하게 되곤 합니다. 이는 팀 내에서도 마찬가지예요. 사실 팀 내에서 발생하는 충돌의 순간은 빈번하고, 대부분은 한 번에 넘어가는 경우가 없어요.
이런 경우를 원활하게 해소하지 못하면 기존 요구사항이 크게 변경될 수 있고, 설사 빠르게 변경된다 하더라도 의사결정이 완료되지 않았다면 구현이 진행되지 않아 전체적인 프로젝트의 일정이 밀리는 경우가 발생할 수도 있어요. 이러한 케이스가 극단적으로 심해지거나, 서로가 서로에게 무례할 수 있는 상황까지 가는 경우가 (당연히 안 되겠지만) 왕왕 존재할 수 있기도 합니다.
피할 수 없다면 강하게 밀어붙여봐?
물론 때때로 PM 입장에서도 양보할 수 없는 스펙이 있기도 해요. 그래서 답답해하기도 하고, “그냥 해! 하라고!!” 하고 싶어질 때가 있어요. 이러한 방법이 때때로 먹히기도 하고, 이렇게 밀어붙여서 제품이 성공한다면 “거 봐, 내 말이 맞잖아?” 하면서 앞으로의 의사결정 과정 또한 강하게 밀어붙이려고 할 수 있어요.
그렇지만 이렇게 강하게 밀어붙이는 것은 정말 강한 확신, 불법을 저지르는 행위와 같이 타협할 수 없는 윤리적인 사항 등 제한적으로나마 활용하는 것이 좋아요. 강한 스타일의 커뮤니케이션은 지속 가능성이 떨어집니다. PM에 대한 불만이 생길 수 있고, 팀 내 동기부여를 저하하거나 팀워크에 저해되는 요인이 될 수 있거든요. 장기적으로는 PM이 부재한 상황에서는 아무것도 할 수 없는 팀이 되어버릴 수도 있어요.
그럼 어떻게 하는 것이 좋을까?
그래서 무조건 강하게 밀어붙이기보다 반드시 PM의 요구사항처럼 구현이 되어야 하는 이유를 설명하는 것이 좋습니다. 물론 위에서 얘기한 것처럼 당연히 그냥 강력하게 밀어붙일 수도 있지만, 업무 효율이 떨어지거나 서로 감정이 상하는 일은 가급적 없는 것이 장기적으로 좋을 수 있으니까요. 오히려 우리는 법적인 정책 또는 가이드라인을 준수하기 위한 부분이거나 이를 통해 리스크를 발생시키지 않도록 완전무결함을 추구하는 것이 중요하다고 어필할 수 있습니다.
또는 수많은 사용자와의 인터뷰나 행동패턴을 보고 판단한 것이거나, 산업 자료 또는 통계 자료와 같은 데이터 적인 부분으로 어필할 수도 있어요. 이렇게 PM의 요구사항 대로 구현할 수밖에 없는 제품 내 ・ 외부의 영향도를 좀 더 근거로 삼는 것이 대부분의 충돌에서 효과적인 커뮤니케이션 형태로 동작할 수 있습니다. 사실 대부분 이러한 근거는 PM이 주도적으로 파악하고 메이커들은 잘 모를 수 있기 때문에 메이커들을 설득하기 수월한 경우가 많습니다.
이제 어느 정도 설득이 되었다면, 우리의 요구사항대로 구현하려면 어떻게 해야 하는지 메이커들에게 의견을 물어 제시할 수 있도록 하면 도움이 됩니다. 이때부터는 메이커들도 반대나 거절의 의견보다는 정말 어떻게 하면 이를 구현할 수 있을지 고민하게 돼요.
충돌은 오히려 좋아
이 과정까지 오게 되면 오히려 앞서의 충돌이 좋은 경우가 되기도 합니다. PM의 요구사항이 꼭 필요한 가에 대해서 여러 시각에서 검토하다 보면 불필요한 스펙일 수 있어 제거할 수 있기도 하고, 기술적으로 더 훌륭한 스펙의 구현이 가능하기도 합니다. 또는 더 훌륭한 사용자 경험을 만들어 낼 수도 있어요. 이제 같이 한 방향으로 나아가면서도 더 좋은 제품을 구현할 수 있게 돼요. 사실 PM의 대부분의 일은 이러한 커뮤니케이션을 조율하는 데에 쓰이게 되는 것 같습니다.
결론
제품 조직에서 PM은 단순히 기획의 업무만 담당하는 것은 아닙니다. PM은 제품 책임자로 제품이 사용자에게 좋은 가치를 전달하기 위해 필요한 모든 것들을 책임지고 관리할 수 있어야 합니다. 이 과정에서 당연히 수많은 충돌을 경험하게 되고, 매일매일 수많은 커뮤니케이션을 진행하게 됩니다.
때때로 이 과정이 지난하고 힘들지 모르겠지만 사용자가 만족하는 좋은 기능과 제품을 만드는 과정에서 좋은 영양분이 되기도 하는 꼭 필요한 과정이라고 생각합니다. 다만 우리의 의견을 더 잘 설득하기 위한 여러 방법들을 학습하고 탑재해 두는 과정은 필요하기에 매일 배우고 학습하고, 써먹는 과정의 반복이 되는 것 같습니다.
June님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
모비인사이드의 뉴스레터를 구독해보세요
