brunch

You can make anything
by writing

C.S.Lewis

by Jenny Jang Mar 05. 2023

IT 프로젝트를 수행하는 PM 업무 & 산출물 정리

IT 서비스 전문 PM 의 업무 및 산출물 정리

IT 회사에서, 혹은 소프트웨어 개발 외주 업체에서 기획~오픈까지 프로젝트를 총괄 담당하는 PM(프로젝트 매니저)의 역할은 매우 매우 중요하다고 할 수 있다. 나 자신도 IT 회사의 PM 업무를 맡기 전 까지는 이렇게 중요한 직무인지 잘 알지 못했다.

기획자, 디자이너, 퍼블리셔, 개발자, QA 테스터 등 각 단계에 따른 기술자들의 역할도 매우 중요하지만, 프로젝트 매니저는 이 모든 과정을 관리하고 조율하는 유일한 직무로서 한 프로젝트의 시작부터 끝까지의 모든 과정에 참여한다. 따라서 모든 과정에 대한 깊은 지식과 이해는 필수이다. 어쩌면 현 비즈니스 세계에서 많이들 원하는 "통합형 인재" 라고도 할 수 있겠다. 또한 다방면에서의 지식 뿐만 아니라 이해관계자들의 의견을 수렴하고, Comflict를 잘 조율해 나가는 매니징 능력 또한 갖추어야 하는 중요한 직무라고 생각한다.

PM 은 프로젝트의 전과정을 관리하고 매니징하는 만큼, 모든 과정에 대한 책임을 지고, 그만큼 프로젝트 내에서 매우 높은 권력(권한)을 가지게 된다. 따라서, PM 이 되려면, IT 프로젝트의 전과정을 리딩하고, 책임질 수 있을 만큼의 경험과 경력이 필수이기도 하다.

개인적으로는 기획자, 디자이너, 프론트앤드 개발자, 백앤드 개발자, DevOps, 테스터, 외부 이해관계자, 외부 프리랜서 및 에이전시 들의 업무를 충분히 이해해서 그들이 겪을 수 있는 문제, 이러한 결정을 내림으로서 벌어질 수 있는 문제를 도출하고, 그에 따른 솔루션과 최적의 방안을 찾을 수 있는 능력이 매우 중요하다고 생각한다. 실제로 프로젝트를 진행하게 되면 작은 수정이나 작은 change 요청이 정말 많이 발생한다. (부득이하게도) 윗선이나 해당 업무를 이해하지 못하는 외부 직무의 사람들에게는 "겨우 이거 바꾸는데 문제가 될까?"라고 생각하기 쉽지만, 해당 업무를 이해하게 되면 이 작은 수정이 얼마나 힘든지, "왜 개발자는 맨날 안된다고만 하나요?" 라고만 한다. 이럴때 상황을 조율 할 수 있는 PM의 능력이 많이 요구된다.

특히나 많은 개발 인력이 외국인으로 구성되어 있는 우리 팀 같은 경우 더욱 의사소통에 문제가 있을 수 있기 때문에 PM의 대처 능력이 중요하다.

IT 프로젝트 프로세스

대략적으로 정리해 본 IT 프로젝트 로드맵

보통 [기획, 디자인, 퍼블리싱, 개발, 테스트, 오픈] 단계로 이루어진다.

각 단계가 어떤 업무를 하는지도 중요하다. 이는 해당 업무에 대한 경험도 필요하고 많은 공부가 필요하다.

실제로 프로젝트를 해보면서 직접 경험해 보는것이 제일 좋지만 갑자기 다양한 분야에서의 실제 프로젝트를 맡을 수 있는 경우는 그리 많지 않으니 다양한 리소스, 강의, 케이스 스터디를 통해 기본적인 틀, 산출물 정도는 꼭 익혀 놓는 것이 좋다.

1. 기획

일단 클라이언트/혹은 사내에서 개발을 원하는 서비스의 요구사항을 분석하고 정리합니다. 이후 정리된 요구 사항을 바탕으로 개발할 기능을 상사하게 정리 한 후, WBS (개발 일정)을 세세하게 작성합니다.

이후, 이를 바탕으로 IA(Information Architecture)를 작성하고, 이후 와이어 프레임, 스토리보드를 제작합니다. 이 모든 과정은 구체적으로 어떤 서비스를 개발하기를 원하는지, 기능은 무엇인지, 의도는 무엇인지 하나도 빼놓지 않고 세세하게 정의하는 과정이라고 보시면 됩니다. 이것은 아주 단순한 업무 과정이고, 필요에 따라 UX 기획, UX 카피라이팅, 경쟁사 분석, 시장 분석, 정량/정성 분석 등 너무나도 많은 기획 요소가 포함되거나 생략될 수 있습니다. 이는 B2B서비스인지, B2C서비스인지 혹은 사내 일부 인원들만 이용하는 프로그램인지 아닌지 등의 서비스의 목적에 따라 큰 차이가 납니다.

산출물

요구 사항 정의서

기능 정의서

WBS(개발 일정 - 간트 차트 많이 씀)

IA(Information Architecture)/순서도(화면 흐름도)

와이어프레임

스토리보드

툴

Jira (WBS를 위해서)

Figma/Figjam

Protonow

등... (PPT, 스케치 등을 쓰는 기획자들도 많음)

(But, 나는 기능 정의서부터 IA, 와이어프레임, 스토리보드, UXUI디자인까지 모두 피그마 & 피그잼으로 진행하는 것을 선호한다. 특히나 프로젝트가 크지 않는 경우라면 기획자,PM,디자이너,개발자 모두 한 곳에서 소통할 수 있는 피그마를 선호한다.) 피그마

앱 프로젝트라면 피그마 Community에 어느 한 디자이너가 올려주신 화면 설계서/정의서 샘플을 사용해도 좋을 것 같다. 링크

요구사항정의서

(출처:위시캣)

wbs 예시

IA 예시

Figjam으로 만든 IA (Information architecture)

Wireframe

2. 디자인

산출물을 바탕으로 디자이너가 디자인의 컨셉을 먼저 컨펌 받습니다. 이때 클라이언트 혹은 사내 결정권자가 “메인 컬러는 보라색으로, 깔끔한 디자인으로 가고 싶다”와 같이 대략적인 디자인 컨셉을 알려주면 디자이너는 이를 바탕으로 디자인 시안 작업을 시작합니다. 간단히 몇페이지 정도로 제작하고, 약 3~5개 정도의 시안을 제공합니다. 이를 통해 어떤 시안을 쓸지 결정하고, 확정 이후 기획에서의 산출물들을(와이어프레임, 스토리 보드 등) 바탕으로 전체적인 디자인 작업을 시작하게 됩니다.

사실 경험상 디자인 파트에서 굉장이 많은 시간낭비를 하게 되는데, 대부분 의사소통의 문제 때문입니다. 막상 다 개발을 했더니 디자인이 마음에 안든다며 다시 엎는다거나 (이런 경우 프론트앤드 작업 - 혹은 퍼블리싱) 을 다시 일정 부분 엎어야 하기 때문에 매우 매우 비생산적입니다. (실제로도 몇번 있었음)

따라서 PM은 반드시 모든 결정권자들이 해당 디자인에 동의를 하는지 컨펌을 받아야 합니다.

산출물

디자인 컨셉

디자인 시안 (3개 정도)

전체 UXUI 디자인

툴

주로 Figma, AdobeXD

3. 퍼블리싱

사실 해외에서는 퍼블리셔라는 직업이 그다지 흔하지 않기 때문에 사실 한국에 와서야 퍼블리싱이라는 과정이 있다는 것을 알게되었습니다. (아마 비용 절감의 목적이 큼) 이 글을 읽는 대다수의 분들은 아마 한국 회사에서 일할 가능성이 크기 때문에 퍼블리싱 과정을 포함했지만, 대부분의 외국인 프론트앤드 개발자들은 (심지어 프론트앤드만 하는 개발자보다는 대부분 프론트+백을 다 하는 풀스택이 더 많습니다.) 퍼블리싱이라는 Task를 따로 구분하지 않습니다. 보통 퍼블리셔들이 하는 업무를 모두 함께 진행하며, Figma로 UXUI 디자인을 마친 경우, 다양한 플러그인을 통해 어느정도 HTML/CSS 코드 정도는 자동화로 뽑아낼 수도 있기 때문에 (혹은 자동으로 빌드를 하면 HTML/CSS 코드 정도는 자동으로 생성되는 툴 등) 보통 저희는 이 과정을 매우 효과적이고 빠르게 처리하려고 노력합니다. 때문에 해당 과정에서는 딱히 PM이 지시하고 커뮤니케이션 하고 산출물을 뽑아내는 일은 별로 없습니다.

4. 개발

각 회사마다 다를 수 있지만, 저희 같은 경우 DevOps(데브옵스), 프론트앤드 개발, 백앤드 개발로 크게 나눠 진행을 합니다.

데브옵스 같은 경우 처음 구성할때 많이 중요한 역할이고 이후는 프론트앤드와 백앤드 작업이 주가 됩니다.

서버 네트워크 환경, 개발 환경 등 구성을 하고, 이후 기획 산출물을 바탕으로 개발을 진행합니다.

저희 개발 부분은 리드 개발자가 총 리드로 진행하고 PM과 커뮤니케이션 하기 때문에 자세하게는 적지는 않겠습니다.

산출물

시스템 구성도 (하드웨어 구성도, 소프트웨어 구성도)

system architecture

5. 테스트 & 오픈

이후 테스트(QA)를 진행하는데, 다양한 케이스, 시나리오, 기능에 따른 테스트 할 요소를 엑셀에 정리해서 테스터가 모든 경우의 수를 테스트 해 볼 수 있게 해야합니다. 테스트 과정을 소홀히하면 오픈 후에 에러가 이것저것 튀어나올 수 있기 때문에 반드시 모든 프로세스의 경우의 수를 파악하여 작성합니다.

산출물
기능별/시나리오별 테스트 요청서