brunch

매거진 IT회사에서 PM으로 일합니다

라이킷 20

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이서 Aug 09. 2023

그거 PM 혼자 다 못해요

Project Messenger 되지 않기

기본적으로는 Product Manager, 때에 따라 Project Manager가 되는, 흔히 한국에서 '기획자'라고 불리는 직군을 PM이라고 부르며 이야기를 시작합니다.

대한민국의 PM은 할 일이 정말 많다.

'그건 PM하고 이야기 하세요'

'PM이 취합해서 전달해 주세요'

'모든 회의는 PM이 참석하세요'

심지어

‘김PM, 회의 하나만 잡아봐‘

‘박PM, 들어와서 회의록 좀 작성해’

라고 말하는 팀장들도 있더라.

노가다판의 ’잡부‘와 비교하면 좀 심한건가?

정확한 업무 역할이 정의되지 않은 채 발전한 한국의 IT문화 탓도 있겠지만, '나만 아니면 돼!'가 만연한 사회 문화가 더 근본적인 원인이라는 것이 개인적인 의견이다.

다른 사람에게 귀찮은 업무를 넘기면(던지면) 그만이다.

나만 아니면 된다.

그런 환경에서 가장 만만한건 PM이 될 수 밖에 없다.

예능 ‘1박2일’이 사회에 끼친 영향을 조사하면 재미있을 듯

왜 모든 외부와의 소통이나 협업, 의견조율은 PM이 해야 한다는 걸까? 기술 문제 해결에 대한 대응 이메일을 왜 PM보고 쓰고 답변하라는 것인가. 기술에 대해 깊이 알지도 못하는 PM을 회의에 밀어넣고 얻는 것은 대체 무엇인가. 욕받이? 나머지 팀원들의 마음의 평안? 그래선 곤란하다.

PM은 전달자가 아니다.

지속적인 정보 교환은 프로젝트 혹은 제품 운영에서 가장 중요한 요소이다. 성패를 좌우한다. IT 프로젝트에서 정보는 제품을 키우는 영양분 그 자체이다. 그토록 중요한 정보의 조율과 교환, 기록, 공유를 PM 홀로 모두 책임진다면 반드시 문제가 생긴다.

중요한 정보를 한 사람이 독점하고 관리하는 순간 병목이 생기기 때문이다. 단기 효율은 높아지겠지만, 팀은 정보를 기록하고 공유하는 문화가 정착되지 못하고 모든 걸 PM에게 의지하게 된다. 그가 긴 휴가를 쓰거나 다른 팀으로 급하게 옮기거나 최악의 경우 이직을 한다면 팀 혹은 프로젝트 자체가 흔들릴 수 있다. 이 문제는 프로젝트의 사이즈가 클 수록 심각해진다.

PM이 홀로 ‘정보 담당자’가 되어 회의,의사결정,정보공유 등을 모두 책임진다면 팀은 바보가 된다. 조직은 ‘다 아는 사람’ 과 ‘아무것도 모르는 사람‘으로 나뉘어 멍청해지고, 모든 개발자들이 PM만 바라보고 있는 형국으로 망해간다. 이 흐름은 무한반복되며 문화로 고착된다. “전 PM아닌데요? 난 모르겠으니, PM하고 이야기 하세요”라고 앵무새처럼 떠드는 개발자들만 남는다.

PM은 결국 일을 감당하지 못한다. 5명에게 수집하여 10명에게 전달하는 역할을 했다면, 나중에 그 정보가 수정되었을 경우 5명과 수정된 정보에 대해 항상 확인을 해야 하며, 10명에게는 변경된 내용을 그 즉시 족족 공유해야 하는 업무가 추가되는 것이다. 말은 쉽다. 하지만 팀원이 20명, 30명으로 늘어나고, 정보가 수십,수백,수천 건이 된다면 반드시 누락이 생긴다. 필연적이다. PM은 정보 전달 업무만 하는 게 아니기 때문이다.

파발꾼 - 각 역참에 딸려, 역참 사이에 공문서를 전하던 사람. 파발꾼은 오래 살지 못했다. (이미지 : '파발, 지옥을 달리다.' KBS드라마스페셜)

그렇다면 어떻게 해야 하나.

해당 프로젝트에 참여하는 모든 사람들, 개발자/PM/디자이너/QA/BA 등등 직군을 가리지 않고 소프트웨어 엔지니어라고 불러보자. 나는 프로젝트 혹은 제품운영에 참여하는 모든 사람이 소프트웨어 엔지니어라고 생각한다. 정보의 수집/기록/배포/공유는 내용을 가장 잘 알고 있는 '소프트웨어 엔지니어'가 하면 된다. 담당자가 아는 정보는 해당 담당자가 관리하면 된다. 담당하는 부분의 회의에 엔지니어가 직접 들어가 의견을 조율하고 결정한 후, 기록하고 팀 내에 공유하면 된다.

PM이 혼자 직접 모든 정보를 보관,수정,공유 하려고 하면 반드시 문제가 생긴다. PM도 사람이다. 모든 정보를 컨트롤 할 수 없다. 프로젝트나 제품의 규모가 조금씩 커지고 참여 인원이 많아지면 그 복잡도는 기하급수적으로 증가한다. PM은 서로 원활히 소통할수 있는 환경을 만들고 문화를 정착시키자.

어떤 PM은 모든 외부 채널을 자기가 도맡아 담당하며, 이슈들마다 끼어들어 모두 컨트롤 하려고 한다. 모든 회의에는 자기가 참석해야 하며, 외부 요청은 무조건 자기를 거쳐야 하고, 업무 조율은 본인 없이는 불가하다고 선언한다. 심지어 개발 이슈도 본인을 통해 문의하고 해결하라고 한다. 책임감일 수도 있고, 공명심일 수도 있다.

그럴 필요 없다.

PM은 수퍼맨이 아니다.

실무자들이 더 잘 안다.

PM이 모든 정보 교류의 게이트웨이가 되면 안된다. 지속가능한 방식이 아니다. 정보의 독점은 결국 프로젝트에 해를 끼친다.

PM은 원활한 의사소통과 전보전달을 위해 상호작용할 수 있는 환경과 심리적으로 안정감 있는 문화를 만드는 데 집중하자. 모두 함께 동등한 레벨에서 정보를 공유할 수 있는 판을 깔아주자. 그렇게 되면 모든 참여자들이 알아서 소통하고 영양분을 주고 받으며, 제품은 무럭무럭 자라 성공적으로 배포될 수 있다.

정보는 모두의 것이며,

팀원 모두 같이 관리, 운영해야 합니다.

PM은 Project Messenger가 아닙니다. Messenger

keyword