Community

퍼블리 읽어주는 청년 194 Product manager는 기획, 디자인, 개발 등 다양한 직군 전문가와 협업하는 포지션입니다. 프로젝트를 성공적으로 수행하기 위해 이와 같이 다양한 직군 전문가를

퍼블리 읽어주는 청년 194 Product manager는 기획, 디자인, 개발 등 다양한 직군 전문가와 협업하는 포지션입니다. 프로젝트를 성공적으로 수행하기 위해 이와 같이 다양한 직군 전문가를 잘 설득하고 이해시키는 것이 핵심 역량 중 하나입니다. 오늘은 PM이 다양한 직군 전문가와 어떻게 하면 원활한 소통으로 업무를 진행할 수 있는지 실전 노하우를 소개합니다 :) 일 잘하는 PM은 업무 요청부터 다르다 저자 남윤정 PM이 겪는 업무 요청의 고충에는 여러 요인이 있겠지만, 가장 큰 원인은 동일한 프로젝트를 수행할 때도 개인 간·팀 간 업무에 대한 이해가 다르다는 점이다. 실무자의 성향이나 팀 특성에 따라 업무를 바라보는 시각은 다를 수밖에 없다. 게다가 개인 혹은 팀 우선주의가 원활한 의사소통을 방해하기도 한다. 업무 요청시 공통적으로 고려해야 하는 4원칙 1) 업무 공유 툴 쓰기 2) 요청하는 업무의 기한 표시하기 3) 업무를 요청받은 사람이 해야 하는 구체적 행위 명시 4) 결과물의 형태를 구체적으로 명시 스마트 문서나 태스크 매니징 툴을 사용하기 어려운 상황이라도, 자신의 업무 환경에서 가능한 리소스를 활용해 언제든 협력 구성원이 접근할 수 있도록 공유하면 된다. 이런 방법이 불가능하다면 오프라인 칠판에 내용을 붙여두거나 매일 아침 정해진 시간에 메일로 안내하는 등, PM이 1:1로 대응하지 않더라도 다른 이들이 필요할 때마다 프로젝트 정보를 스스로 찾아볼 수 있는 환경을 조성한다. 향후 프로젝트나 사업의 전체적인 방향에 큰 영향을 미치는 기획 실무자에게는 이처럼 업무의 맥락을 공유하는 일이 무엇보다 중요하다. 이 업무가 프로젝트에서 어떤 역할을 하는지, 이 업무의 산출물이 어디에서 어떻게 활용될 것인지를 구체적으로 공유해야 한다. 업무 요청 내용을 먼저 정리한 후 레퍼런스를 찾기보다는 레퍼런스가 될 자료를 먼저 찾아보면서 생각을 정리하고, 선택된 자료를 기준으로 업무 요청 내용을 짜는 편이 좋다. PM은 개발 담당자에게 업무를 요청할 때, 이 업무의 최종 결과물은 어떤 것이 될 예정인지 명확히 보여줘야 한다. 레퍼런스를 준비하거나 직접 손그림으로 보여주는 것도 좋다. 아래의 예를 보자. 업무를 요청하는 사람이 명확하고 구체적인 최종 결과물을 머릿속에 먼저 그려둬야 한다. 특히 개발 실무자들에게 업무를 자주 요청해야 하는 실무자라면 단순히 들은 대로 업무를 요청하는 '전달자'가 아닌, 내가 이해한 바에 따라 효율적으로 업무를 요청하는 '매개자'가 돼야 한다.

알림

알림이 없습니다