프로덕트 Meeting
미팅 운영하기
PM 프로덕트를 시작하고 운영할 때 가장 핵심이 커뮤니케이션이라고 생각한다. PM의 역할 중 8할은 커뮤니케이션이고, 이해관계자들과의 관계 형성과 프로젝트가 끝날 때까지 상황을 체크해야 한다. 진행하는 일정 및 내용을 명확히 하고 이슈 발생 시 대처하는 타이밍, 방법 등 다양한 부분을 확인하는데, 가장 기본적인 것이 미팅이다. PMBOK에서도 애매하면 미팅을 하라고 솔루션을 줄 정도로 미팅은 이해관계자들과 자주 이야기해서 공통의 목표를 이루어내는데 아주 중요한 역할을 한다고 생각한다.
미팅의 종류는 매우 다양하고 많이 있다. 월간보고, 주간보고, 일일보고, 일정회의, 정기회의, 프로젝트 킥오프, 포스트모텀, 시연 등 다양한 미팅들이 있으며, 이 모든 미팅을 PM이 주관하지는 않지만, 프로젝트 담당자로써 아주 중요한 역할을 하는 것은 사실이다. PM의 주관이 되는 미팅은 프로젝트 관련 정기회의나, 이슈가 발생했을 때 비정기 회의, MVP나 프로토타입을 시연하는 회의, 프로젝트가 종료하고 나서 문제점에 대해서 분석하는 포스트모텀 등이 대표적이라고 할 수 있다. 회사의 운영상황에 따라 미팅의 종류가 다를 수 있으나 PM의 역할은 비슷할 것이라 본다.
PM은 프로덕트 or 프로젝트가 시작되면 이해관계자들을 선별하여 정기회의를 소집한다. 미팅의 규모를 어떻게 설정할 것인지, 몇 개의 회의를 운영할 것인지 정하고 실행한다. Agile이라면 매일 아침 Stand-up 미팅을 할 수도 있고, 큰 프로젝트라면 실부장님 포함한 사업부와 개발실 전체 일정과 방향성 회의를 따로 하는 경우도 있고, 작은 프로젝트면 실무자들끼리 관련 담당자들과 디테일한 내용을 협의하는 회의를 만들 수도 있다.
중요한 것은 회의의 특성에 맞게 관련자들을 선별하여 회의를 소집해야 한다. 관련자들을 잘못 소집하면 회의내용과 무관한 내용으로 시간과 리소스를 허비할 수 있다. 나는 보통 프로젝트가 시작되면 일주일에 한 번씩 정기회의를 소집하고, 고정 멤버를 선별하고, 게스트를 매주 초대한다. 예를 들어 개발기획 담당자와 개발 담당자, 사업 담당자는 고정으로 있고, 마케팅 이슈나 현장 설치, CS, HW 등 이슈가 논의되면 그 회의록에 작성하고 그다음 주 회의에 게스트를 초대하는 형태로 주로 운영한다.
회의 진행하는 동안 촉진자로써의 활동을 해야 한다. 진행사항 일정표를 만들어서 전주에 진행한 내용과 지금 현황이나 진행하기로 한 내용을 브리핑을 해주고, 각 담당자들의 답변을 유도한다. 문제가 발생 시에는 감정적으로 이야기하기보다는 Fact를 기반으로 이야기하고, 해결이 되지 않는다면 기록을 해서 각 조직의 상위 직책자들에게 에스컬레이션을 한다. 권한 없는 PM이 할 수 있는 유일한 무기이며, 회의를 주재하면서 이슈들을 해결 할 수 있는 수단이다.
회의록과 백로그는 누구보다 중요한 자산이다. 회의를 하고 그냥 끝내면 절대 안 되며, 이 회의에서 나온 이슈들에 대해서 정리하고, 해결을 위해 지속적인 기록과 관리가 필요하다. 기본적으로 매일 Tool을 이용해서 진행사항을 체크하고, 회의에서 담당자가 있는 상태에서 진행 중 발생한 여러 가지 기록들을 펼쳐놓고 이야기한다. 각 담당자들의 역할과 진행하기로 한 약속들을 명확히 기록하여 회의록으로 남긴다. 프로젝트가 끝날 때까지 일정 및 이슈에 대한 처리 내용은 이 회의록과 기록된 백로그들로 증빙해야만 하므로 매우 중요한 작업이다.
담당자들 간의 갈등이 가장 이슈인데, 회의를 통해 해소한다. 보통 엔지니어들은 본인의 업무만 하기 때문에 상대방을 이해하지 못하는 경우가 많다. 특히 SW와 HW 담당자들이 마찰이 일어나는 경우가 제법 있다. HW성능이 부족해서 안된다거나, SW에서 조금만 수정하면 HW를 새로 제작하지 않아도 된다거나 마찰이 많이 발생한다. 막상 한 명씩 이야기하면 문제가 심각한 것으로 생각할 수 있으나, 만나서 이야기하고, 전체적인 스토리와 거시적인 관점으로 설명하면 보통 이해하고 이슈에 대한 해결책이 나오기 마련이다.
신제품 프로덕트를 리딩하면서 있었던 미팅이 생각난다. 보통 업그레이드 제품을 출시하면 HW만 업그레이드되거나 SW만 업그레이드되는데, 그 제품은 둘 다 신규였었다. 그러다 보니 SW개발부서와 HW개발부서가 항상 서로 불만이 많았었다. HW입장에서는 사소한 이슈 하나 수정하는 것도 샘플을 수정하거나 때때로 샘플을 새로 제작해야 하는 경우도 있어서 시간과 비용이 많이 든다. 그래서 간단한 것은 SW가 수정하면 좋겠다고 이야기한다. SW입장에서는 HW의 특정상황 때문에 SW에서 예외사항을 많이 처리하면 안정성에 이슈가 발생할 수 있으니, 근본 원인인 HW를 수정해야 한다는 주장을 한다. 둘 다 틀린 이야기는 아니라고 판단하여, 미팅을 테스트 부스에 가서 HW와 SW를 같이 보면서 진행했다. 실제로 HW를 분해해 보면서 이슈에 대한 부분을 서로 날것으로 이야기하고 나니, HW샘플도 간단한 부분만 수정하고, SW에서도 보완을 해주면서 이슈를 해결했던 적이 있었다.
서로 한마음으로 진행하면 얼마나 좋을까? 가족끼리도 마음이 맞기가 어려운데, 직장 동료들과 마음을 맞춘다는 것은 너무 큰 욕심이지 않을까 싶다.. 그래서 PM이 각 담당자들이 이슈없이 담당 업무에 집중할 수 있도록 조율하고 촉진하는 역할을 해야 한다고 생각한다. 이 역할이 프로덕트의 성공여부가 결정되지 않을까 생각해 본다.
*요약
명확성이 곧 친절함이다. PM은 객관적인 사고로 회의 소집과 운영, 결과를 명확하게 하여, 혼란이 발생되더라도 즉시 해결할 수 있도록 해야 한다.