기획자와 PM

들어가며

안녕하세요. 입사한지 4개월쯤 된 노머스 PM 이아영입니다.

그동안 서비스 기획자로 업무를 진행해오다가 노머스 입사 후 처음 맡게 된 프로젝트에서 기존에 진행 중이던 작업에 PM 역할로 참여하게 되었습니다. 입사 당시 서비스 기획과 함께 프로젝트 매니저 역할도 함께 수행하게 될 것이라는 이야기를 들었었는데 이번 프로젝트에서는 기능을 설계하기보다 일정과 진행 상황을 관리하는 역할에 더 가까운 업무를 맡게 되었습니다.

프로젝트의 범위는 이미 어느 정도 정해져 있었고, 개발도 일부 진행된 상태였습니다. 처음에는 정해진 범위 안에서 진행 상황만 잘 관리하면 될 것이라고 생각했습니다. 하지만 실제로 프로젝트를 진행해보니 기능을 기획할 때와는 전혀 다른 기준으로 판단해야 하는 순간들이 많았습니다.

이번 글에서는 서비스 기획자로 일해오다가 처음으로 PM 역할을 맡으면서 어떤 점이 어려웠는지, 그리고 그 과정에서 무엇이 가장 크게 달라졌는지 정리해보려고 합니다.

기능을 기획할 때와 프로젝트를 관리할 때의 기준은 달랐다

기존에는 프로젝트 안에서도 기능 단위, 혹은 서비스 단위로 업무를 맡는 경우가 많았습니다.

요구사항을 정리하고, 정책을 정의하고, 화면을 설계하고, 예외 케이스를 확인하는 것이 주요 역할이었습니다.

이 과정에서 가장 중요하게 생각했던 기준은 기능의 정합성이었습니다. 정의되지 않은 조건이 없는지, 흐름상 어색한 부분은 없는지, 빠진 케이스는 없는지를 계속 확인하며 완성도를 높이는데 집중해왔습니다.

하지만 이번 프로젝트를 맡으면서 판단의 기준이 달라져야 한다는 것을 느끼게 되었습니다. 기능이 맞는지보다 지금 이 기능을 추가해도 되는지, 일정 안에 구현이 가능한지, 다른 작업에 영향을 주지는 않는지를 먼저 고려해야 했습니다.

당연한 이야기라고 생각할 수도 있지만 실제로 프로젝트를 진행하다 보니 자연스럽게 더 좋은 설계를 먼저 고민하고 있는 스스로를 발견하게 되었습니다.

기획자로 일할 때는 더 나은 설계를 찾는 것이 자연스러운 흐름이었지만 프로젝트를 관리하는 입장에서는 항상 더 좋은 선택을 할 수 있는 것은 아니었습니다.

기능 단위로 볼 때는 필요한 수정이라도 프로젝트 전체 일정 안에서는 부담이 되는 경우가 있었고 이런 상황에서 어디까지 반영할지 판단하는 일이 생각보다 쉽지 않았습니다.

이번 경험을 통해 기능 중심으로 판단할 때와 프로젝트 전체를 기준으로 판단할 때 같은 작업이라도 기준이 달라질 수 있다는 것을 처음으로 체감하게 되었습니다.

이미 진행 중인 프로젝트에 들어가며 느낀 어려움

이번 프로젝트는 처음부터 설계를 진행하는 상황이 아니라 이미 개발이 진행 중인 상태에서 PM 역할로 참여하게 된 작업이었습니다.

일정이 정해져 있었고 구현 방향도 어느 정도 결정되어 있었기 때문에 전체 흐름을 빠르게 파악하는 과정이 필요했습니다.

기존에 정리된 문서를 기반으로 현재까지 진행된 범위를 확인하고 남아 있는 작업을 다시 정리하면서 프로젝트의 상태를 이해하려고 했습니다.

이 과정에서 가장 어려웠던 점은 내가 직접 설계하지 않은 기능의 범위와 일정을 판단해야 한다는 것이었습니다.

기획을 처음부터 진행하는 경우에는 구현 범위를 스스로 정의할 수 있지만 이미 진행 중인 프로젝트에서는 정해진 방향 안에서 조정해야 하는 경우가 많았습니다. 기능의 필요성과 일정 사이 어디까지 반영할지 결정해야 하는 상황이 계속 발생했고, 이 기준을 잡는 것이 쉽지 않았습니다.

그래서 기능 단위로 판단하기보다 현재 프로젝트에서 반드시 필요한 범위가 무엇인지 먼저 정리하려했고, 일정 안에서 구현 가능한 작업을 기준으로 우선순위를 나누는 방식으로 정리해 진행했습니다.

이 과정을 거치면서 기능의 완성도만 보는 것이 아니라 프로젝트 전체 흐름 안에서 판단해야 한다는 것을 처음으로 체감하게 되었습니다.

일정 산정은 생각보다 단순하지 않았다

PM 역할을 맡으면서 가장 부담이 되었던 부분은 일정이었습니다.

기획을 할 때는 기능을 정확하게 정의하는 것이 중요했다면 프로젝트를 관리할 때는 언제까지 가능한지를 결정하고 그 일정 안에 마무리해야 했습니다.

특히 이미 개발이 진행된 상태에서는 단순히 남은 작업만 계산해서 일정을 잡기 어려웠습니다.

현재 진행된 범위와 남은 작업의 양, 추가 요구사항이 발생할 가능성, QA 필요한 시간, 다른 작업과의 일정 충돌, 개발 리소스 상황 등 여러 가지 요소를 동시에 고려해야 했고, 그 위에서 우선순위를 정해야 했습니다.

일정 산정에서 중요한 건 기능 단위로 보기보다 작업 단위로 나누고, 변경 가능성이 높은 영역과 그렇지 않은 영역을 구분해 두는 방식으로 접근하려 했습니다. 또한 반드시 필요한 작업과 이후에 보완할 수 있는 작업을 나누고, 현재 일정 안에서 가능한 범위를 기준으로 계획을 세우고자 하였습니다.

이 경험을 통해 일정은 단순히 기간을 정하는 일이 아니라 범위와 우선순위를 함께 결정하는 과정이라는 것을 느끼게 되었습니다.

처음 맡은 PM 역할을 통해 배운 점

PM 역할을 맡으면서 기능 하나를 완성하는 것보다 프로젝트 전체 흐름을 유지하는 것이 더 중요하다는 것을 느꼈습니다.

기획을 할 때는 하나의 기능을 완성하는 것이 목표였다면 프로젝트를 관리하는 입장에서는 여러 작업이 동시에 진행되는 상황에서 어떤 순서로 진행할지, 어디까지 진행할지, 언제 결정을 내려야 할지를 계속 판단해야 했습니다.

특히 일정이 정해져 있는 프로젝트에서는 모든 요구사항을 반영하는 것보다 정해진 범위 안에서 끝까지 완성하는 것이 더 중요할 수 있다는 것도 처음으로 체감하게 되었습니다.

또한 프로젝트는 혼자 진행하는 일이 아니라 여러 역할이 함께 움직여야 하기 때문에 기능의 완성도뿐 아니라 협업과 조율도 중요한 요소라는 것을 느끼게 되었습니다.

기능을 잘 만드는 것과 프로젝트를 끝까지 가져가는 것은 또 다른 능력이라는 것 또한 배웠습니다.

여러 의사결정 속에서 방향을 정리하고, 함께 일하는 사람들과 조율하며 프로젝트를 완성해 나가는 과정이 PM의 역할이라는 것도 느끼게 되었습니다. 이번 경험을 통해 기획자의 역할이 단순히 문서를 작성하는 것이 아니라 프로젝트의 방향을 함께 고민하는 일이라는 것을 다시 한 번 배우게 되었습니다.

앞으로는 기능의 완성도뿐 아니라 일정과 협업까지 함께 고려할 수 있는 기획자가 되고 싶습니다.

긴 글 읽어주셔서 감사합니다.