프로덕트 CommunicationⅡ
다양한 상황에서 의사소통
PM의 업무는 커뮤니케이션이 전부라고 해도 과언이 아니다. 앞서 이야기한 사업부와 개발실의 조율과 통역의 역할이 매우 중요하다. 하지만 통역과 조율이 항상 잘되는 경우만 있는 것이 아니다. 여러 가지 상황에 따라서 원활하지 못하는 경우가 많이 발생한다. PM이 개발의 입장만 생각해서 사업부와 대치하는 경우도 있고, 그 반대의 경우도 있다. 문제가 별로 발생하지 않고, 좋은 분위기일 경우에는 사실 크게 문제가 되지 않는다. 서로 좋은 감정에 일을 깔끔하게 진행되면 아무 이슈가 없다. 하지만 문제가 발생하기 시작하면 감정소모가 심하고, 잘잘못 따지기시작하면 안 좋은 결과가 발생하는 경우가 생각보다 많이 발생한다. 그럴 경우에 대해서 몇 가지 이야기해보려고 한다.
문제가 발생했을 때, 서로 남 탓만 하며 문제개선이 되지 않는 경우이다. 보통 모든 직원들과 소통을 해보면 내 탓이라고 말하는 사람은 거의 보지 못했다. 보통 나는 정상이고 문제가 없는데, 유관부서에서 하지 않았거나, 늦게 했거나, 말을 해주지 않아서 이슈가 발생했다고 주장하는 경우가 많다. 예를 들어, 개발 일정이 지연이 되어서 개발자에게 지연의 이유를 물어보면, 아직 기획서를 못 받아서 못했다거나, 디자인이 아직 확정이 안돼서 못했다는 답변을 종종 듣는다. 물론 그 직원 말대로 다른 사람이 부족해서 못한 상황도 있을 수 있다. 다만 자기가 해야 하는 업무의 선행이 필요하면 미리 연락하거나 PM에게 얘기하면 조율해 줄텐데.. 그런 상황을 보면 아쉽다. 이런 경우는 방법이 없다. 각자의 성향의 문제이고, 능력의 문제라고 생각한다. 그러므로 PM은 그런 성향의 직원들을 파악하여, 적극적으로 소통해서 진행사항을 위해 더 신경을 써서 진행해야 한다.
전문지식이 부족한 경우에 대한 오해이다. 이건 보통 사업부에서 개발실에 많이 하는 오해이다. 요즘 IT지식이 쉽게 찾을 수 있고, 접할 기회가 많다 보니, 지식을 찾으려 하면 쉽게 습득을 할 수 있다. AI 도구를 사용하거나 비교적 쉬운 툴을 이용해 MVP를 만들거나 샘플을 만들어보는 경우가 많이 있다. 하지만 단순하게 한두 개의 모듈로 이루어져 있고, 간단한 구현을 하는 것과 실제 서비스를 구축하는 것과는 좀 많이 다른 이야기이다. 예를 들어, 구글 AI스튜디오를 통해 골프 영상 분석 툴을 만들었다. 골프 영상 파일을 넣기만 하면 시퀀스별로 오류를 잡아낸다. 그러면 이걸 들고 개발자한테 가서 이렇게 간단한걸 왜 못 만드냐고 하는 경우이다. 일부 기능을 구현만 하는 것과 실제 서비스로 녹여서 연동하는 것은 다른 이야기이다. 영상을 실시간으로 보고 기존의 학습 좌표를 대입해서 분석할 위치를 찾아내서 분석하고, 온디바이스로 분석하려면 장비의 성능도 체크해야 하고, API를 연동하면 서버와 DB에 데이터를 저장하고, 모바일이나 웹으로 보여줘야 해서.. 실제 서비스가 되려면 훨씬 많은 공수가 들 수밖에 없다. 그러므로 PM은 완벽하진 않지만 사업부와 미리 확인을 해서 우리 프로세스상 서비스가 되려면 필요한 것을 설명하고, MVP를 개발팀과 함께 보면서 방향성을 제시하는 역할을 해야 한다.
내가 담당하는 일을 나만의 방식으로 하는 경우이다. 요구사항이 만들어지면 그 요구사항에 대해서 실제 구현가능한지 체크를 하고 개발기획서를 작성하고 디자인을 한다. 디자인과 개발기획서가 완성이 되면, 개발자에게 전달이 되어서 프론트, 백엔드, DB, 네이티브 등 각자의 역할에 맞게 개발을 한다. 그런데 협의한 대로 개발을 하지 않고, 본인이 편하려고 하드코딩으로 작업하거나, 개발을 전혀 고려하지 않은 디자인을 하거나, 개발기획서가 특정 Feature에만 집중되어 있거나 하면 혼란이 야기한다. 예를 들어, 디자이너가 디자인을 할 때, 아이폰의 화면 디자인할 때, 뒤로 가기 버튼을 만들지 않았다고 생각해 보자. 개발에 적용하고 나면 뒤로 갈 수 있는 방법이 없어서 문제가 발생한다. 개발자도 뒤로 가기 버튼이 없으면 안 되는 걸 알면서 디자인이 그렇게 돼있기 때문에 그대로 했다고 하는 경우이다. 또는 네이티브나 프론트에서 강제로 하드코딩해 버리면 서버를 통해 정보를 수정할 수 없게 되어서 실제 서비스에서 문제가 발생할 수 있다. 그럼 무조건 점검일정을 잡아서 업데이트를 해야지만 수정할 수 있는 경우도 발생하게 된다. PM은 기획서를 적극적으로 검토하고, 이슈가 될만한 부분을 미리 협의를 하며, 정기적인 미팅을 통해 이슈가 발생하기 전에 체크를 해야만 한다.
PM은 위에 언급한 상황 말고도 많은 혼란이 발생하는 경우를 경험할 수 있다. 사람들이 모여서 같이 일을 하기 때문에 많은 문제들이 발생하고, 일어날 수 있다. 따라서 PM은 이런 문제들을 예측하고 미리 대비해서 같이 일하는 이해관계자들의 성향을 파악해서 준비를 해야 한다. 예를 들어 아주 내성적이어서 사람들과 말을 잘하지 못하는 개발자가 하는 작업이면, 선행 업무를 하는 사람에게 PM이 먼저 일정을 이야기해서 준비시켜 준다던가, 먼저 말을 걸어서 일정이나 이슈를 미리미리 체크해야 한다. 개발기획서가 나오면 먼저 읽어보고, 이상한 점이나 개발자가 이해하기 어려운 부분을 미리 확인해서 수정 요청하거나, 개발 리뷰를 통해 같이 합의할 수 있도록 진행하면 도움이 된다.
얼마 전에 AI가 나오면 PM이 사라질 수도 있다는 브런치를 읽었다. AI가 프로젝트 관리를 실시간으로 만들고 공유하기 때문에 아마존이나 구글 같은 빅테크에서 PM을 많이 없애는 추세라는 글이었다. 일정관리와 진행사항 관리는 AI로 대체가 가능할 수 있지만, 사람들의 성향과 문제 발생이 일어나 않도록 예방하는 역할, 즉 사람 간의 이슈를 공감으로 해결해야하는 역할을 AI가 과연 해낼 수 있을까?
*요약
갈등을 기술적으로 조율하는 것을 넘어, 성향에 맞춘 선제적 공감으로 이슈를 사전 예방하고 성공적인 프로젝트를 이끄는 것이 PM의 본질입니다.