프로젝트 이해하기 2: 프로젝트의 프로세스와 산출물 알아보기

들어가며

지난 시간에 기획자의 업무 단위는 프로젝트를 알아보았다. 이번에는 비교적 규모가 큰 프로젝트에서 많이 사용하는 폭포수 모델을 알아봄으로써 전통적인 프로세스 방식에 대해 알아보고자 한다.

 

1. 프로젝트 Process

워터풀 방식의 특징

 

1. 앞 단계가 완료되지 않으면 다음 단계 진행이 불가능하다.
2. 단계별로 정해진 산출물이 정해져 있으며, 산출물이 모두 도출되어야 한다.
3. 규모가 큰 프로젝트의 경우 프로젝트 검수 및 종료 단계에서 다시 한번 산출물에 대한 최종 검수 및 현행화 작업을 거친다.

 

 

0. 계획

프로젝트 계획 단계

• 프로젝트의 비즈니스 모델, 비용, 목적을 산정한다.
• 프로젝트 제안서를 작성하고 업체를 수주하는 일련의 과정이 프로젝트의 계획 단계에 속한다.

1. 분석

프로젝트 분석 단계

기획자의 업무: 환경 분석, 요건 분석, 콘텐츠 분석, 정책 정의, 가이드 정의

• 분석: 환경, 요건, 콘텐츠 분석 등을 통해서 정책을 정의한다.
• 정책에 따른 문서 가이드 또는 작업 가이드를 작성한다.

 

2. 설계

프로젝트 설계 단계

기획자의 업무: IA(Information Architecture), 기능 정의, 서비스 프로세스, 와이어 프레임, 스토리보드 완성

• 정의: 앞서 분석한 산출물을 바탕으로 정보 구조 및 기능, 서비스 프로세스를 정의한다.
• 와이어프레임: 와이어프레임을 통해 스토리 보드를 완성한다. 

3. 구현

프로젝트 구현 단계

기획자의 업무: 스토리보드 리뷰, 스토리보드 현행화, 단위 테스트

• 스토리보드 리뷰: 설계한 스토리보드가 잘 구현되었는지 리뷰를 통해 확인한다.
• 스토리보드 현행화: 설계한 방향대로 구현되고 있는지 지속적으로 업데이트 및 현행화를 진행한다.
• 단위 테스트: 디자인 퍼블리싱에 대한 각각의 단위 테스트를 진행한다. 설계 방향과 맞는 디자인이 나왔는지, 맞는 인터렉션 또는 구동 방식으로 개발되었는지 단위별로 테스트한다. 

4. 검수

프로젝트 검수 단계

기획자의 업무: 검수 및 스토리보드 고도화, 단위 테스트, 통합 테스트

• 스토리보드 고도화: 구현 단계의 단위 테스트에서 좀 더 딥하게 테스트하고 검수하며 스토리보드를 고도화한다.
• 단위 테스트 및 통합 테스트: QA, QC 같은 전문 테스터들이 단위 테스트와 통합 테스트를 진행한다.   

5. 종료

프로젝트 종료 단계

기획자의 업무: 문서 최신화, 운영 매뉴얼, 인수인계 준비

• 문서 최신화: 최종 산출물에 대한 싱크가 맞도록 모든 파트에서 문서를 최신화한다.
• 운영 매뉴얼: 이 서비스를 맡아서 운영하는 운영자들에게 전달할 매뉴얼을 작성한다.
• 인수인계 준비: 안정화 단계 준비를 한다.

 

참고용 자료

현직 PM의 관리 폴더

 

 

2. 프로젝트 계획 이해하기

 

 

 

 

• 업무 분석: 업무를 분석해서 해당 업무에 필요한 인력은 몇 명인지, 인력 및 환경 세팅은 어떻게 할 것인지 계획한다.
• 인력 구성: 인력이 어떤 시점에 어떻게 투입되면 가장 적절한지 구성한다.
• 환경 셋팅: 프로젝트 전반의 환경(QA 환경, 프로젝트 룸 등)을 세팅한다(+ 개발 세팅 포함).
• 프로세스 정의: 모든 프로세스를 계획 단계에서 정의한다.
• 산출물 정의: 공식 산출물과 비공식 산출물(회의록), 근거 자료 등 프로젝트 진행 시 산출되는 작업물들을 꼼꼼히 관리한다.
• 일정 산정: 전체 일정 안에서 세부 일정을 산정한다.

 

계획 단계에서의 산출물

• 실 투입 인력 계획: 투입 인력 계획서에 작성한 내용을 기반으로 리더를 제외한 다른 구성원들은 변경될 수 있다. 실제 투입 인력에 대한 계획을 세운다.
• 상세 WBS: 상세 일정표
• 메인 시안용 기획: 설계 단계로 넘어가기 전에 메인 시안용 기획을 통해 기초 디자인 시안을 잡는다. 
• 제안 범위 재협의: 제안서의 범위를 다시 한번 재 협의하여 범위를 확정 짓는다.
• IA 초안 작업: 아키텍처 초안을 작업한다.

 

산출물 리뷰

1. 실투입 인력 계획서

앱 개발 인력 견적서 예시 (출처: 이랜서)

• 맨 먼스: m/m 한 달에 1명이면 1 맨먼스, 한 달에 2명이면 2 맨먼스

 

2. 산출물 정의

• 기본적으로 모든 프로젝트 진행에는 산출물이 나온다.
• 산출물 업데이트 및 현행화를 꼭 실행하도록 한다.
• 최신 버전과 문서의 싱크가 맞지 않는 문제가 일어나지 않도록 주의한다.
• 산출물에 대한 규칙(프로젝트 넘버링) 정의가 매우 중요하다.     **정리정돈 필수!

 

3. 상세 WBS

• 프로젝트 진행에는 일정이 가장 중요하다. 
• 일정에 맞춰 작업을 마무리할 수 있도록 상세하게 WBS를 정리하는 것이 중요하다.

 

3. 프로젝트 분석 이해하기

 

분석 단계에서의 산출물

• 환경 분석: 시장의 환경 분석, 업무적인 환경 분석
• 밴치마킹: 경쟁사 또는 트렌디한 서비스 또는 타사의 업무 환경 등을 어떤 규칙에 의해 개선하고자 하는 바를 벤치마킹함.
• ASIS: 현재 요건에 대해서 분석하고 요구사항을 정의(요구사항 정의서)한다.
• 개발 가능 범위 확인: 정의된 요구사항을 기반으로 개발 가능한 범위를 확인한다.
• 콘텐츠 분석: IA의 구조를 분석하며 현재의 문제점을 발견하고 개선 방향 선정 후 개선안을 도출한다.
• 정책 정의: 정책이 바뀔 경우 전략이 바뀔 수도 있다. 서비스별 정책을 확인하고 TOBE에 맞게 변경한다. 
  • (ASIS) 현재 회원가입에 본인 인증이 없었음 (TOBE): 회원가입 시 본인 인증을 거침
  • 정채적으로 회원가입 시 모든 사용자들이 본인인증을 거칠 수 있도록 외부 API를 해 본인 인증을 거칠 수 있도록 정책을 변경

 

분석 산출물 리뷰

MALL 벤치마킹 Summary 예시

1. 사이트별 MALL 구성표

• 구분에 대한 벤치마킹을 진행 후 반드시 다음과 같은 Summary를 반드시 작성해야 한다.

 

 

 

 

 

GNB의 변형 구조 - 사용자 스크롤 시 GNB 변형

• 1 LEVEL: APP 다운로드
• 2 LEVEL: 주요 제품 카테고리(햄버거 아이콘), LOGO, 장바구니(아이콘), 로그인/주문확인/도움말(아이콘)
• 3 LEVEL: 검색 창
• 4 LEVEL: (아이콘) 필터, (아이콘) 위/아래 정렬, (아이콘) 리스트

GNB의 간소화 시: 필터, 위/아래 정렬, 리스트/바둑판 정렬

 

 

 

GNB의 변형 구조 - 없음(사용자 스크롤 시 GNB 간소화 없음)

• 1 LEVEL: APP 다운로드
• 2 LEVEL: 주요 제품 카테고리(햄버거 아이콘), LOGO, 검색(아이콘), 장바구니(아이콘)

GNB의 변형 구조 - 사용자 스크롤 시 GNB 변형

• 1 LEVEL: 주요 카테고리 메뉴(햄버거 아이콘), LOGO, 장바구니(아이콘)
• 2 LEVEL: 검색 창

GNB 간소화 시 - 주요 카테고리 메뉴(햄버거 아이콘, LOGO, 장바구니(아이콘)

 

 

4. 프로젝트 설계 이해하기

 

 

 

 

 

 

• 분석 단계에서 충분히 고민했던 것들에 대한 인사이트를 바탕으로 프로젝트 설계를 한다.
• 그 과정에서 정책, 콘셉트 등이 조금씩 변경될 수 있다(인사이트를 기반으로 설계하되 100% 반영되지는 않는다.)
• 설계 앞 단에 분석하는 기간과 정책 정의를 하는 분석 기간이 반드시 필요하다.
• 또한 IA, 서비스 프로세스 등이 먼저 정의된 이후에 와이어프레임과 스토리보드를 작성할 수 있다.

 

 

프로젝트 설계 단계의 산출물

• IA: 개발 쪽과 리뷰를 하면서 완성하는 정보 구조 즉, 기능을 정의하는 문서다. IA를 통해 구현 전에 우리가 요청했던 요구사항은 무엇이고, 요구사항대로 실제 기능이 구현이 되었는지를 확인하는 지표로써 사용될 수 있다.
•  서비스 프로세스: 어떤 서비스의 프로세스를 의미한다. 
  • ex) 1:1 문의에 대한 서비스 프로세스를 정의해 달라고 요청했다면, 1:1 문의의 시작과 끝에 대한 프로세스를 작성해 달라는 것이다.
• 어떠한 프로세스를 거쳐서 이 서비스가 완성이 되는지를 정의한다. 
• 정책 확정: 프로세스를 정의할 때 회사에서 정의하는 정책을 정의해야 한다.
  • ex) 정책적으로 회원 가입 시 본인 인증이 필수다.
  • ex) 14세 이상만 가입이 가능하다.
• 디스크립션: 개발에 대한 규칙, 정책을 정의하는 것이다.
• 개발 리뷰: UI에 대해서, 여러 가지 정책적인 부분들에 대해서 개발자들과 디자이너들과 리뷰를 통해 상의하고 확정해 간다.
• 스토리보드 완성: 설계 단계에서 최종적인 산출물은 스토리보드이다. 
• 커뮤니케이션 문서: 구현하면서 완성되는 스토리보드에 대한 고도화 작업을 한다.

 

 

설계 산출물 리뷰

IA 문서 예시

 

4. 프로젝트 구현 이해하기

 

 

• 스토리보드 리뷰: 개발 과정에서 변경되는 사항들을 스토리보드 리뷰를 통해 확인한다.
• 스토리보드 현행화: 설계 당시 요청했던 정의서 대로 디자인, 인터랙션, 시스템 등이 나왔는지 리뷰를 확인하고 지속적으로 소통하면서 스토리보드를 현행화한다.
•  단위 테스트: 단위별로 테스트를 거치며 업데이트한다.

 

 

 

 

 

 

 

 

프로젝트구현 단계의 산출물

 

 

구현 산출물 리뷰

통합테스트 케이스 시나리오 예시

• 통합 테스트: 설계 단계에서 작성한 내용에 따라 테스트 시나리오가 끊임없이 영향을 받는 구조이다.
• 예상 결과와 체크 포인트들을 모두 확인할 수 있는 문서이다.

 

5. 프로젝트 검수하기

 

• 단위 테스트: 전체 플로우로 넘어갈 때 이슈가 없는지 확인하는 단계를 거친다. 단위 테스트는 크게 2가지로 나뉜다.
     첫째:  개발자단위 단위에 대한 테스트를 개발자 스스로가 진행한다.
     둘째: 공식적 단위테스트:  기획자가 검수 단계에서 실시간으로 단위 테스트를 진행한다.
• 검수 단계에서의 단위 테스트는 공식적으로 관련자들이 단위 테스트를 모두 진행한다(개발이 모두 완료되었다는 가정 하에 진행한다).
• 통합 테스트: 플로우를 전체적으로 다 돌려보는 것이다.
• 검수 단계에서의 테스트는 최소 한 달 정도 잡는다. 오픈할 수 있는지의 여부를 검수 단계에서 확인한다.

 

프로젝트 검수 단계의 산출물

 

최종적으로 처음에 원했던 프로젝트의 퀄리티가 나왔는지 검수를 통해 확인한다.

사용자에게 전달되기 전 오픈 준비를 한다.

 

 

6. 프로젝트 종료하기

대 고객에게 오픈하기 때문에 오픈 초기에 안정화 단계가 필요하다. 프로젝트 종료 단계에서 프로젝트 안정화를 시키고 운영 매뉴얼 및 인수인계를 준비한다. 오픈 초기에는 오류가 빈번히 발생하고 미처 확인하지 못한 이슈가 생길 수 있으니 프로젝트에 관여한 대부분의 인력이 남아서 안정화 단계를 거친다. 주로 기획 쪽에서는 ML, PO와 같은 리더 급이 남으며 개발자와 디자이너, 퍼블리셔는 무조건 남아서 대응한다.

 

 

• 문서 최신화: 문서에 대한 최신화를 진행한다. 프로젝트 오픈한 시점에 맞춰진 문서인지가 매우 중요하다.
• IA: 엑셀로 만들어진 문서를 스토리보드 앞쪽에 넣어준다. 약속된 산출물에 대한 핏을 공유한다.
• 운영 매뉴얼:
  • 서비스를 기획한 서비스 기획자가 작성한다. 
  • 실제 프로젝트를 오픈해서 사용자가 보고 있는 화면 캡처를 뜨고(사용자 화면, 관리자 화면) 모든 메뉴에 대한 매뉴얼을 작성한다.
  • 스토리보드도 있지만, 실제 화면을 떠서 넣어주는 것이 중요하다.
• 운영 가이드: 운영 매뉴얼로 대체되는 경우도 있지만 운영 가이드를 따로 작성하기도 한다.
• 유지보수에 대응하기 위한 인수인계를 준비한다. 

 

7. 프로젝트 안정화하기

안정화 단계에서는 프로젝트에 참여한 대부분의 인력이 철수한 후 최소한의 인력이 남아서 안정화를 진행한다. 

이때 기획자는 문서를 보거나 운영 매뉴얼 설명, CS 대응 등의 비교적 조용한 안정화 단계를 거친다.  

일정 기간 동안의 안정화 단계를 거치면 검수 확인서를 제출하고 잔류 인원도 정리한다.

 

 

8. 프로젝트 산출물 

문서를 어떻게 어떤 내용으로 관리하는 것이 매우 중요하다. 프로세스의 정책과 프로세스와 기능이 어떻게 정리되어 있는지, 이게 모두 녹아져 있는 와이어프레임이 포함되어야 유의미한 산출물이라고 할 수 있다.

 

프로젝트 산출물

산출물의 종류나 양은 프로젝트의 크기에 따라 달라질 수 있다. 오늘 작성한 내용들은 삼성이 삼성 SDS에게 발주 요청하는 수준의 규모가 있는 프로젝트를 진행할 경우 필요한 문서들이다. 

현직 PM의 산출물 목록

 

 

느낀 점

프로젝트 이해하기 1, 2편을 통해 서비스가 만들어지는 과정을 전반적으로 살펴볼 수 있었고, 특히 대형 프로젝트의 프로세스 방법을 알아보면서 그 사이에서 기획자가 해야 하는 업무들에 대해 알아볼 수 있었다. 솔직히 큰 프로젝트 진행 방식으로 알아봐서 그런지 과정 하나하나가 엄청 무거운 느낌이 들었다. 그래도 누가 처음부터 저렇게 큰 프로젝트를 신입한테 맡기겠는가. 이번 시간을 통해 전반적으로 프로세스가 흘러가는 방식은 이렇고, 이때에 이런 산출물들이 필요하니 미리 알아두고 미리 천천히 준비해 봐라, 시야를 키워라 정도로 담아가려고 한다. 강의를 들으며 현직자의 문서 관리 팁이라던지, 각 단계에서의 기획자의 역할이라던지 세세하게 배울 수 있어서 앞으로 어떤 부분을 더 갖춰가야겠다는 것들을 얻어갈 수 있었다.  

기획자는 서비스 론칭에 필요한 여러가지 산출물들을 전반적으로 관리해야 한다. 특히 현행화 작업이 정말 정말 중요하다. 이런 작업들을 헷갈리지 않고 관리하려면 파일명, 버전, 폴더 트리 관리가 정말 중요하다. 이런 부분들을 잘 챙기자!