개발 기획의 기획 PM 업무 역량과 한계

본 블로그에서는 사업 기획, 서비스 기획, 개발 기획을 구분하고 있다는 점을 말씀드립니다. 이 글은 온라인 서비스 개발 기획과 관련한 PM 업무에 대해 그간 경험을 토대로 정리한 것입니다. 앞으로 더 많은 경험을 하게 된다면 글을 더 채워 나가겠습니다.

 

 

기획자로서 프로젝트 매니저(PM) 한계 케이스

제 경험으로 온라인 서비스 개발 프로젝트의 PM은 주로 개발자 출신이 맡아 왔었습니다. 그러다 사업 또는 서비스 이해에 대한 문제가 중요한 경우 기획자가 PM을 맡는 경우도 있게 되었습니다.

 

개발자가 PM을 맡는 것은 온라인 서비스 개발 프로젝트의 목적이 서비스 개발이므로 당연한 것이라 할 수 있습니다. 여기서 기획자가 PM을 맡는 경우 문제가 생깁니다.

 

생각보다 많은 경우 온라인 서비스 개발 프로젝트에 투입되는 기획자는 사업이나 서비스에 대한 이해가 부족한 경우가 있습니다. 주로 화면을 중심으로 기획을 해 왔기 때문입니다. 일종의 디자이너가 작업하기 전 고객이 볼 화면을 문서로 정리하여 보여주는 역할을 해 온 것입니다.

 

이 경우 기획자는 온라인 서비스 개발 프로젝트의 범위와 업무를 설정하고 관리하는데 한계를 가질 수밖에 없습니다.

 

 

화면 중심 기획이 중심이 된 이유

그러기에 개발에 대해 어느 정도 아는 기획자여야 하기에 과거의 SI 기획자 하면 주로 개발자 출신이 많았습니다. 그러나 지금은 프로젝트에 참여해 본 결과  개발자 출신 기획자는 상대적으로 비율이 줄어든 것으로 느껴집니다.

 

이는 시장의 흐름과도 관련이 있어 보이기는 합니다. 요즘 목업/프로토타이핑/디자인 툴을 활용해 기획을 하는 경우가 많아진 듯합니다. 이는 최근 10여 년간 불어온 온라인/모바일 창업 열풍과도 관련이 있어 보입니다.

 

이렇게 창업을 준비하고 있으나 해당 업무에 경험이 없는 창업자가 투자금 또는 창업 지원금을 받기 위한 가장 쉬운 방법은 그럴듯한 앱 또는 서비스의 모습을 보여주는 것입니다. 이 방법에 목업/프로토타이핑/디자인 툴은 매우 유용합니다. 개발을 하지 않고도 실제 앱과 서비스 같은 모습을 투자자 또는 심사자에게 보여줄 수 있기 때문입니다.

 

그러다 보니 서비스나 개발에 대한 지식보다는 목업/프로토타이핑/디자인 툴에 대한 지식이 더 중요해졌고, 이런 작업 과정을 겪어 온 경력은 서비스 구조나 기능, 데이터보다는 보이는 화면에 집중할 수밖에 없습니다. 이것이 강점이기 때문입니다.

 

최근 스타트업 온라인 서비스 개발 기획을 진행하기도 했는데 여기서도 화면 중심의 기획을 진행하였습니다. 요구하는 툴 자체가 그렇기 때문입니다.

 

 

기획자 PM이 갖추어야 할 업무 역량   

최근 기획자의 특성을 만든 것은 아마도 스타트업 창업 열풍과 지원사업이 한몫한 것으로 생각됩니다. 문제는 이런 화면 중심 기획자는 온라인 서비스 개발 기획 업무에서 중고급 이상 직무는 맡을 수 없다는 점입니다. 실제 화면 중심 기획자가 PL 이상을 맡은 프로젝트의 상당수는 시간이 경과하면 할수록 발생 문제의 수와 난이도가 올라가는 경향을 띠게 됩니다.

 

그 이유를 간단히 설명하면 이렇습니다.

 

기획자가 관리 업무인 PM 또는 PL을 하기 위해서는 업무의 범위와 내용을 파악할 수 있어야 합니다. 이를 위해서는 사업에 대한 이해와 서비스 이해가 있어야 합니다. 더하여 이를 개발과 연결하는 역량이 필요합니다.

 

기본적으로 온라인 서비스 사업 기획과 서비스 기획은 고객에서 진행합니다. 개발 기획자는 이를 이해하고 개발 관련하여 해석/설계할 수 있어야 합니다. 이는 요구사항 상세화와 서비스 구조 설계로 나타납니다.

 

요구사항은 고객이 온라인 서비스 개발 회사에 말하는 내용을 의미합니다. 이를 실제 개발로 이어질 수 있도록 구체화하고 상세화 하면서 목표 서비스 구조를 잡습니다. 이를 통해 개발 구현할 기능과 이 기능의 플로우(사용 프로세스)를 정리합니다. 

 

이렇게 작업된 내용을 가지고 개발 PL 또는 설계자와 개발 프레임워크와 기능별 관계, 진행 과정을 정리합니다. 이렇게 정리된 내용이 WBS가 됩니다.

 

아무리 개발에 대한 지식이 있는 기획자라도 프레임워크 버전 또는 투입 개발자들의 특성, 활용 라이브러리나 설계 DB 구조 등에 의해 달라지는 개발의 세부 과정을 모두 알 수는 없습니다. 그러므로 투입된 개발 관리자와 협의는 필요합니다.

 

이때 필요한 문서가 존재합니다. 그것이 앞서 언급한 요구사항 상세화와 서비스 구조도, 기능 정의서, 플로우 문서 등인 것입니다.

 

이후 정리된 문서를 가지고 화면을 설계하게 됩니다. 흔히 스토리보드 또는 시나리오라 불리는 문서가 그것입니다. 개발 설계가 기획 내용을 가지고 개발할 기능을 작성하는 것이라면 화면 설계는 기획 내용을 가지고 사용자의 화면을 작성하는 것이라 할 수 있습니다.