✅ 파쓰가 한번 만나봤습니다 : 주니어 기획자들의 랜선 사수이자 아이돌, 도그냥 '이미준 PO님을' 만나봤어요!

✅ 파쓰가 전하는 테크 샤라웃 : 이번 주 파쓰가 엄선한 당근, 쏘카, 배달의민족의 테크 블로그 소식을 알려드릴게요!

🎤파쓰가 한번 만나봤습니다.

일을 오래 하신 기획하신 분들이라면 공감하실 것 같아요. 주니어분들일수록 마이너한 일이나 중요하지 않은 일에 시간을 많이 쓰는 실수를 할 때가 종종 있어요. 예를 들면, PO나 서비스 기획자인데 UI 디자인과 관련된 영역에 정책보다 더 시간을 많이 쓰죠. 특히나 요즘은 피그마와 같은 툴들을 이용해서 디자인에 공을 들이는 모습도 많이 보게 되는데요. 실제 개발에 사용될 UI 설계는 사실 디자이너가 작업하는 부분이기 때문에 상대적으로 단순하게 해도 되는데, 이에 집착해서 굉장히 많은 시간을 쓰는 경우들이 생겨요. 하지만 일을 하면 할수록 우선 순위에 대해 체계가 서는 것 같아요. 뿐만 아니라, 물어보면 바로 끝날 일들을 혼자 끙끙 앓고 고민하는 경향도 업무 효율을 크게 낮출 수 있어요. 일을 하면 할수록 어떤 것을 남에게 물어보고, 남에게 위임할지를 알게 되니까 시간 활용을 좀 더 수월할 수 있게 되는 것 같아요.

특히, 저희가 하는 일 중에 회의가 굉장히 많잖아요. 근무시간은 회의에 다 쓰고 나중에 기획안을 써야지할 수도 있는데요. 회의를 통해 다양한 결정 사항에 대해 뿌러뜨리며 대략적인 형태를 미리 맞춰놓으면 기획서를 좀 더 빠르게 쓸 수 있어요. 그러지 않고 회의는 회의대로 하고나서, 기획서 작성은 기획서대로 처음부터 시간을 너무 많이 쏟게 되면 오래 걸릴 수 밖에 없죠. 프로덕트 기획 업무는 문제 정의를 어느정도 한 후에 기획을 진행하기 때문에 무에서 유를 창조하는 것이 아니라, 회의를 해나가면서 의사결정 사항들을 하나씩 뿌러뜨리고 가면 회의가 끝날 때에 결론이 어느 정도 정해져요. 그래서 이를 바탕으로 기획서 작업을 바로 시작할 수 있죠. 하지만 이러한 순서를 캐치하지 못한다면 영업, 마케팅, 개발, 시스템의 업무를 아무것도 모른 상태에서 고민은 고민대로 하고, 회의를 진행하면서 기획서를 다 다시 수정하게 되는 것이죠.

💬 ‘서비스 기획자’와 ‘프로덕트 오너’의 이름과 차이에 대해 이렇게 깊이 있는 고민과 경험을 담아낸 책을 처음 본 것 같아요. 물론 책에 굉장히 자세하게 담겨 있지만 두 직무를 모두 경험해 보신 후, 직무 간의 가장 크게 느꼈던 차이점이 어떤 것이었을까요?

💬 해당 도메인에 오랫동안 있지 않았던 PO, PM들이 ‘비즈니스 임팩트’를 정의하고 방향을 잡아나가는 데에 도움이 될만한 꿀팁이 있을까요?

일단 많이 물어보고 비즈니스가 돌아가는 모든 회의에 참석하는 것이 좋아요. '그건 사업부가 할 일이야.', '저 일과 나는 관계가 없어.', '정해진 것만 받아서 하면 돼.'라는 생각을 지워야 해요. 사업부가 모든 플랫폼의 상황을 알고 있지 않기 때문에 같이 의견을 내고 조율해 나가야 회사의 사업 방향을 서비스에 녹일 수 있거든요. 요청된 것만 듣고 하려고 하면 요청이 발생한 맥락을 제대로 파악할 수가 없지요. 그렇게 되면 오히려 요청의 진짜 목적을 놓친 채 개발방식만 스프린트로 애자일하게 수행하겠다고 생각해서 서비스의 완결성도 떨어지고 원하는 목적도 달성하지 못하는 총체적 난국의 상황이 될 수 있죠.

💬 한때 많은 전통기업들에서 유행처럼 애자일 방식을 도입하고자 하는 시도들이 많이 있었는데요. 두 방식을 모두 경험해 본 사람으로서 특정 회사에 더 잘 맞는 방식이 있을까요?

회사의 사업 기획 방식과 위치한 시장에 따라 다를 것 같아요. 만약 회사의 사업기획이 너무 구체적이어서 몇월 며칠에 어떤 제품이 나오는지 등의 계획이 잡혀 있고, 이에 대해 케이스별 완전 무결을 추구한다면 사실 높은 확률로 '폭포수 방식(Waterfall Approach)*'이 더 적합해요. 서비스에 구멍이 나지 않고 흠 없이 만들어야 한다면 기획시간이 오래 걸릴 수밖에 없으니깐요. 특히나 해당 플랫폼이 위치한 시장이 이미 비슷한 서비스가 많아서 제품을 늦게 내나 빨리 내나 큰 상관이 없다면 폭포수 방식으로 본인들만의 스피드로 안정적이게 진행하는 것이 낫지요. 

하지만, 아직 시도해 보지 않았던 새로운 시장에 대한 시도라서 빠르게 가야 한다면 프로덕트 팀에게 많은 권한을 위임하고 목표만 던져주는 애자일 방식(Agile Approach)**이 더 적합한 것 같아요. 기능의 완결성이 높지 않지만 작은 시도들로 시장의 반응을 확인하고 빠르게 방향을 잡아나갈 수 있으니깐요. 

*폭포수 방식(Waterfall Approach):  순차적인 소프트웨어 개발 방식로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여짐

**애자일 방식(Agile Approach): 신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방식

파쓰 Talk😍

누군가에게는 인사이트가 되고, 누군가에게는 위로와 힘이 되는 이야기를 겸손하고 진솔하게 나누어 주시는 도그냥님께 감사드립니다! 앞으로 더 많은 이야기들을 풀어나가실 도그냥님을 기대하고 응원하겠습니다!