PM/PO가 개발자, 디자이너와 효과적으로 일하려면 ?
우선순위 선정하기, 효율적으로 일하기, 협업하기
비기술 직군인 PM/PO가 IT업계에서 살아남는 이유가 있을 것 입니다.
왜냐하면, PM/PO들은 기술 직군이 가지고 있지 않은 것을 가지고 있기 때문입니다. PM/PO가 중요한 이유는 회사가 커지거나 작을 때 중요하고 비싼 리소스인 개발자와 디자이너를 효율적으로 관리함으로써, 시간과 돈 아끼고 일의 효율성을 최고로 높혀 비즈니스를 성공으로 이끄는데 그 역할이 있기 때문입니다.
물론, 디자이너와 개발자는 사람이고 이 사람들을 하나의 자원으로 보며 관리의 대상으로 여기는 것은 회사의 언어의 가깝습니다. 이러한 회사의 언어를 수행하는 PM/PO는 사실상 어떻게하면 기술 직군과 함께 일해나갈 수 있을지 고민해야 합니다.
그 목표를 달성하기 위해서는 함께 일하는 동료이자 파트너인 개발자와 디자이너를 존중하고 함께 특정 목표를 향해 달성할 수 있도록 그 길을 살피는 '안내자'의 역할을 하는 것이 가장 중요합니다. 그러기 위해서 다음과 같은 항목들을 점검해보면서 스스로 좋은 PM/PO가 되고 있는지 점검해보도록 합시다!
PO/PM는 협업 능력이 뛰어나야 합니다.
1. 개발자와 디자이너의 업무방식을 존중하고 효율적으로 일할 수 있도록 돕고있다.
제가 공부하면서 강의를 해주셨던 PM님은 이런 이야기를 해주시곤 했습니다.
"개발자가 효율적으로 일할 수 만 있다면, 개발자의 빨래를 빨아줘서라도 그렇게 해야 한다." 그만큼 PM의 역할은 그저 사무를 보는 것에만 그치지 않습니다.
2. 개발자와 디자이너가 절차상 필요한 존재라고 치부하지 않고, 중요한 파트너로 대하고 있다.
개발자와 디자이너도 사람이고 각기 개성을 가진 존재입니다. 물론 회사 내에서 필요한 특정 기능을 수행하고 있지만, 프로덕트에 애정을 가지고 기여하기 위해서는 그들 또한 일의 주인이 되어야 하고 일이 부품이 되어서는 안됩니다.
3. 개발자와 디자이너가 제대로 일할 수 있도록 충분한 시간을 주고 있다.
비즈니스 스테이크 홀더, 상위 의사결정자(CEO, CPO etc)의 압박 때문에 개발자와 디자이너에게 일정 압박을 넣고 있지 않은가요?
대부분의 PM들은 자기가 필요하다고 생각하는 자원을 절대 받지 못할 것 입니다. 당연히 시간은 부족하고 일정은 항상 촉박합니다. 그렇다면 우리는 2번으로 돌아갈 필요가 있습니다.
우리는 개발자/디자이너를 좋은 파트너로 대하고 있는가? 그들은 우리 프로덕트의 주인으로 일하고 있는가? 난 PM으로서 그들의 업무효율성을 높히는데 기여했는가?
또, 일정적으로나 비즈니스적으로 상위결정자와 해당 상황을 잘 설명하고 일정을 조율해보았는가?
정말 최선을 다하고도 실패할 수 있습니다. 실패한다면 아마 그건 PM/PO의 잘못이 아닐 경우가 큽니다.
4. 프로젝트 초반부터 개발자와 디자이너가 참여하도록 독려한다.
디자이너/개발자가 자신의 프로덕트에 애정을 가지려면 스스로 무언가를 정해본 경험이 있어야 합니다. 정해진 기획대로 태스크를 받아서 기계적으로 수행하고 있는데 비상상황이 걸려 문제상황이 발생한다면 아마도 개발자와 디자이너는 해당 기획을 독단적으로 만든 당신을 탓한 공산이 큽니다.
이런 리스크를 피하기 위해서라도, 또 프로덕트 팀이 우리가 만드는 제품에 대해서 주인의식을 가지고 일할 수 있도록 돕는 방법 중 하나는 디자이너와 개발자가 초반부터 기획에 참여하는 것 입니다.
5. 전문가에게 권한을 위임한다.
PM/PO는 전체적으로 큰 그림을 보는 역할을 수행하기 때문에, 다른 기술직군의 전문성을 침해할 수 있을 수도 있습니다. 스스로 다른 기술 전문성을 가진 사람들에게 간섭하고 있지 않은지 끊임없이 확인해야 합니다.
PM/PO는 커뮤니케이션 능력이 뛰어나야 합니다.
1. 커뮤니케이션이 매일매일 일관적으로, 정확하게 진행하고 있다.
1일에는 입장이 A가 되었다가 2일에는 입장이 B 3일에는 왜 A로 안했냐! 라고 왔다갔다하는 커뮤니케이션을 하시고 계시진 않을까요? 스스로 회의나 했던 말들에 대해 기록과 녹취를 남기면서 일관적으로 커뮤니케이션 하고 있는지를 꾸준히 점검해야합니다. 이는 상황이 자주 바뀌는 업무 특성상 주의해야 합니다.
또, 스스로 전달한 내용들을 상대방과 함께 확인하는 것이 중요하다. 내가 A라고 말했는데 상대방은 분명히 C라고 알아들을 가능성이있습니다.
연애로 치면 썸을 타는 탐색관계에서 암묵적인 시그널을 정해놓고 우리가 혼자서 해석하고 연애의 암묵지에 맞춰주길 바라곤 합니다. 일은 연애가 아니기 때문에, 이런 암묵지들을 깨고 서로 이야기하고 있는게 합치가 되었는지 꾸준히 확인해야합니다.
2. 팀원의 의견을 경청하고, 다양한 의견을 취합하여 실행방안으로 만들어 내고 있다.
모든 의견들을 전부 기획안에 반영할 수는 없을 겁니다. 그럼에도 불구하고, 팀원들의 의견을 듣고 취합하는 모습과 태도를 가지고 있는 것이 중요합니다. 왜냐하면, 의견을 취합하는 모습을 보이지 않는다면 의견을 내지 않는 소극적인 분위기가 될 가능성이 높습니다. 소극적인 분위기 속에서 일하기 시작한다면, 좋은 기획이 나올 가능성이 적어지고 PM 단독으로 기획안을 작성할 가능성과 그 기획안이 실패할 확률도 높아집니다.
그렇기 때문에, 이야기를 최대한 듣고 의견을 취합하여 그 안에서 좋은 의견들은 꼭 살려서 기획안에 반영해봅시다. 함께 일한다는 것은 그만큼 책임도 나눌 수 있고 더 좋은 시너지를 낼 수 있는 유일한 방법입니다.
3. 최대한 많은 정보를 공유한다. (오버커뮤니케이션 > 언더커뮤니케이션)
알아서 잘하겠지.. 라고 생각해보신 적 있으실까요? 업무할 때 건들이지 않는 것 보단, 지속적으로 정중하게 진행상황에 대해 물어보고 의사소통을 하는 것이 중요합니다. 막상 데드라인 직전에 커뮤니케이션이 이루어져서 전반적으로 진행이 너무 안되어 데드라인을 넘기는 상황이 되었다면 이는 커뮤니케이션을 시도하지 않은 PM의 책임이 됩니다. 우리는 개발자와 디자이너가 효율적으로 일할 수 있도록 돕는 역할이라는 것을 잊으면 안됩니다.
좀 더 실무적으로 체크해봅시다.
업무 범위 및 리스크 관리 능력
1. 중요한 것에 집중한다.
2. 무자비할 정도로 불필요한 것을 걸러낸다.
3. 업무 범위 조정과 실험을 통해서 리스크를 관리한다.
결국 지금 Minimum viable Product를 만들기 위해서, 특정 기간동안 리소스를 투입해서 최선의 결과를 얻어야합니다. 이러한 결과를 얻기 위해서는 Biz단에서 그리고 팀 단에서 하고자 하는 일들 중에서 가장 핵심적인 일들을 골라내야 합니다. 지금 해야할 것과 나중에 해야할 것을 구분하는 것이 PM/PO의 핵심적인 능력입니다.
의사결정 능력
1. 사용자와 비즈니스 결과를 최우선으로 고려하여 일관적으로 투명한 결정을 내린다.
2. 자신의 자존심이나 명성을 위해서가 아니라 소비자, 비즈니스, 팀을 위한 결정을 한다.
3. 데이터에 기반한 결정을 내릴 줄 안다.
의사결정을 하는 것도 중요하지만, 실제로 이 과정이 얼마나 투명한가가 중요합니다. 스스로가 늘 틀릴 수 있다는 것을 알고 자존심을 내려놓는 것도 중요합니다. 지표, 유저, 비즈니스, 팀을 위한 능력을 할 수 있어야합니다.
업무지식
1. 정성적 / 정량적 리서치 방법에 대해서 이해한다.
2. 데이터를 활용하고, 데이터를 이해하는 사람과 협업할 수 있다.
3. 어떤 결정을 내릴 때 기술적으로 무엇을 의미하고 오래 걸릴지 이해하려고 노력한다.
4. 최소한 개발지식과 디자인 지식을 보유하고 있다.
업무적으로 스스로 근거를 수집할 수 있는 능력이 기본적으로 보유되어있어야하고 로그에 남아있는 데이터들을 통해 인사이트를 도출해 개선 포인트를 잡을 수 있어야합니다. 또, 기술팀에 ROI(투자 대비 임팩트)(Returm of Investment)가 큰지 작은지 확인할 수 있어야 합니다. 그렇기 위해서는 최소한의 개발지식 또한 필요합니다.
목표와 비전 설정
1. 왜 이 일을 해야하는지 그 비전과 목표를 제대로 설명할 수 있다.
2. 지속해서 사용자, 경쟁사, 시장조사를 하고 이를 제품에 반영한다.
3. 해결책보다는 문제가 무엇인지에 대해서 더 깊이 고민한다.
팀이 하고 싶은 일이 있고 팀이 하기 싫은 일이 있을 겁니다. 제품과 회사의 비전을 끊임 없이 설득력있게 전하면서 목표에 가기 위한 일들을 할필요가 있습니다. 또한, 이 목표 설정이 틀리지 않았는지 끊임 없이 점검할 필요가 있습니다. PM/PO는 문제를 해결하는 사람이지 문제상황에 대한 해답을 내놓는 사람이 아닙니다. 문제를 해결하기 위해서는 풀지 않아도 되는 문제상황이 반드시 존재합니다. PM/PO는 이를 구분함으로써 제품 팀이 필요한 곳에 시간을 투자 할 수 있게 끔 돕는 역할을 합니다.
Biz Stakeholders와 건설적인 의견 교환 능력
1. 경영진에게서 오는 압박을 잘 수용하고 이를 해결하기 위해 어떤 업무를 해야하는지 알고있다.
2. 제품을 더 좋게 만들기 위해서 회사 경영진에 이의를 제기할 수 있다.
3. 해결책보다는 문제가 무엇인지에 대해서 더 깊이 고민한다.
지금 당장 눈앞에 매출을 올려야 한다고 CEO가 이야기 한다면, 매출을 올릴 수는 있지만 소비자 리텐션은 떨어져 장기적인 손해가 발생할 것이라고 이야기하고 의사결정을 요구할 수 있어야 합니다.
개방적 태도
1. 피드백을 사적인 감정으로 받아들이지 않는다.
2. 자기 아이디어와 사랑에 빠지지 않는다.
3. 팀원이 답변을 요구하면, 제때 제대로된 답변을 할 수 있다.
우리는 항상 틀릴 수 있습니다. 우리는 수학문제를 푸는 것처럼 문제에 접근하지만, 실제로는 수학문제를 푸는 것이 아닙니다. 개발/디자인에는 어느정도 정답이 있지만 문제를 푸는 것에는 정답이 있지 않습니다. 그래서 자신이 늘 틀릴 수 있다는 것을 염두해 둡시다.
마치면서
사실 이 모든 것을 할 수 있는 PM/PO가 된다는 것은 정말 쉽지 않을 겁니다. 다만, 우리가 관성적으로 일하고 있더라도 스스로 돌아보고 점검할 시간이 필요할 때 본글이 도움이되었으면 합니다. 감사합니다!
