직장에서 커뮤니케이션이란..
PM직무는 다양한 부서와 커뮤니케이션을 많이 하는 직무이다.
왜냐하면 PM은 Product에 대한 콘셉트를 기획하고, 다양한 시장조사를 진행해서 상상해서 제품을 만드는 업무인데, 본인이 직접 할 수 있는 것들은 지극히 제한적이다.
기획과 콘셉트, 시장조사를 통한 인사이트 도출 등은 깊지는 않지만 넓고 포괄적으로 고민해야 나올 수밖에 없다.
그 추상적인 개념을 진짜 Product로 만들어 내기 위해서 많은 도움이 필요하다.
콘셉트 기획을 설정하고, 향후 마지막 최종 모습을 상상해서 만들지만 실제 서비스 프로세스와 개발적인 부분이 이루어져야 Product가 세상에 나갈 수 있다.
요새 여러 글들을 보면 SW관련된 PM분들이 써놓은 업무 노하우 같은 글들이 많이 있다. 콘텐츠화를 시킨다는 것이 쉽지 않은 작업이다. SW와 HW의 업무는 크게 다르지 않다. HW는 양산과 제조가 추가되고, HW에 SW까지 얹는 경우가 많기 때문에 SW만 기획한 부분의 프로세스를 추가하면 된다.
이를 이루기 위해서 PM들은 고군분투를 한다. 영업부서, 마케팅 부서, 기획부서, 개발부서, 품질부서, SCM부서, AS/CS 등 다양한 직군들과 커뮤니케이션을 한다. PM업무가 다양한 회사에서 추구하는 목적이 다르기 때문에 중점을 두는 부분에 따라서 많이 다를 수는 있다.
나의 경우에는 HW와 SW를 병행하는 제조 제품을 기획하는 경우도 있고, SW에 국한된 콘텐츠에 대해서 기획한 경우도 있었다. 이번에는 SW에만 한정되어서 얘기하고 싶다. 추후 글을 쓰는 게 익숙해진다면.. SW기획과 HW기획에 대한 글을 연재해도 될 만큼 많은 경험들이 있다.
이번 글에서 얘기하고 싶은 부분은 커뮤니케이션이다. 다양한 직무들과 커뮤니케이션을 하기가 생각보다 쉽지 않다. 영업부서는 그들이 영업하는 고객들의 니즈를 맞추려고 한다. 고객들의 니즈를 모두 맞추고 싶지만 고객이 한두 명이 아니다. 예를 들어, 고객이 1,000명~2,000명이 되는데 그들이 요구사항이 2~3개만 충족시켜 준다면 5~6,000개의 요구사항에 만족을 시켜야 한다. 이는 거의 불가능에 가깝다.
그래서 내가 주로 하는 전략은 공통된 니즈를 분석하고, 불편하지만 운영으로 풀 수 있는지, 운영으로 풀고 싶어도 기능이 없어서 할 수 없는지, 이 2가지에 대한 기준을 가지고 있다. 최우선 순위는 불편을 감수하는 운영과 서비스를 이용할 수 있지만, 기능이 없어서 이용할 수가 없어서, 영업에 방해가 된다면 1순위가 된다.
마케팅 부서와의 커뮤니케이션은 Product에 대한 콘셉트와 철학에 대해서 설명하는 과정이다. 마케팅 담당자들은 홍보에 Killer Point를 요구한다. 사실 혁신적인 콘텐츠가 아닌 이상 Killer Point가 있기가 쉽지 않다. 다만 이 Product가 왜 탄생했는지, 이게 세상에 왜 나가야 하는지에 대한 철학을 전달하는 커뮤니케이션이 매우 중요하다. 광고 영상을 만들 때에도 내 Product가 세상에 알려지는 것이기 때문에 콘셉트에 맞게 나올 수 있도록 지속적으로 담당자와 조율하면서 설명해야 한다.
기획부서는 예산과 돈에 대한 얘기를 잘해야 한다. 제품을 만들기 위한 투자와 향후 매출 목표들을 정량적으로 잘 협의해야 한다. 자칫 잘못하다가는 매출 계획이 말도 안 되는 수준으로 설정되면, 성공적인 론치가 되더라도 성과를 인정받기가 쉽지 않다.. 품질과 CS/AS 같은 경우에는 디테일한 Product에 대해서 설명과 콘셉트를 잡은 히스토리와 론치 이후에 대한 기대효과를 잘 설명을 해야지 문제가 덜 하다.
마지막으로 대망의 개발부서이다... 최대의 난관이고, PM의 존재 이유인 것 같다. 나는 개발부서와 밀접한 관계를 가지고 있고, 내가 추구하는 Product를 창조해 내는 역할을 개발부서에서 해준다. 하지만 개발부서에는 다양한 직무가 있고, 그에 맞도록 맞춤형 커뮤니케이션을 해야 한다. 서비스기획, 디자인, 백엔드, 프론트, 네이티브, 서버, DB 등등 업무들이 세분화되어 있다. 서버에서 처리해도 되고, 백엔드나 프론트, 네이티브에서 처리해도 되는 과제들이 생긴다. 사실 엔드 유저 입장에서는 어디에서 어떤 역할을 하든 간에 결과만 나오면 되지만, 개발 과정에서는 쉽지 않다. 그래서 내가 주로 하는 방법은 관련자들을 다 모아놓고 회의를 하면서 화이트보드에 하나하나 적어가면서 역할을 균등하게 나눈다. 사실 내가 개발자 출신이 아니라서 모든 분야를 모르지만 러프하게 어떤 역할을 하는지는 파악해서 진행한다.
서로 의견충돌도 되고, 사업에 대한 방향을 얘기해도 본인 업무에 대한 입장만 얘기하는 개발자들이 많다. 그럴 때일수록 이슈제기하는 부분에 귀 기울여서 들어주고, 다 같이 있는 자리에서 해결책을 요구한다. 그러면 대략 의견들이 나온다. 그러면 그런 의견들을 종합하고, 조율한다. 그러다 사업부의 의사결정이 필요하다고 하는 포인트들에 대해서는 그 자리에서 의사결정을 해준다. 모든 프로젝트가 다 성공하는 것은 아니지만 그 자리에서 PM이 의사결정을 하면, 생각보다 일이 잘 풀린다. 나중에 번복이 되더라도 정리가 잘된 상태에서는 변경하는 것은 그나마 진행할 수 있는 수준이 된다.
특히 개발자들은 세부적으로 나뉜 분야에서 본인의 Pride가 있다. 물론 한 분야에 스페셜리스트이고 직접 창조하기 때문에 각각의 분야에 대한 역할 정의가 되면 싸울 일이 없다. 무수히 많은 프로젝트에서 아사리판을 많이 봐왔기 때문에 프로젝트 성공을 위해서라면 심판을 봐주고, 전체적인 시야에서 조율해 주는 것이 매우 중요하다고 생각한다.
간혹 가다가 말도 안 통하고 자기만의 세상에 빠져있는 개발자들이 있는데..(특히 개발부서의 직책자인 경우..) 이런 사람들은 좀 더 연구해 봐야 한다.. 오늘 그런 사람과의 커뮤니케이션이 있어서, 나의 커뮤니케이션 능력을 향상해야겠다고 다짐했었다.
소통이야 말로 정말 제일 중요한 Skill인 것 같다.
