프로젝트 관리 및 팀워크 소개

프로젝트 관리와 팀워크는 디자인 및 개발 직무에 필요한 소프트 스킬이라고도 합니다. 프로젝트 관리에는 기술적인 부문이 존재하고 여러 다양한 프로젝트 관리 방법론이 있지만, 뛰어난 프로젝트 관리자가 되기 위해서는 커뮤니케이션 및 조직 기술을 포함한 팀워크가 필요합니다.

효과적인 프로젝트 관리와 팀워크를 실현하기 위해 필요한 내용은 다음과 같습니다.

• 팀원, 고객, 기타 관계자와의 명확한 커뮤니케이션
• 기한에 맞춰 최종 제품 전달
• 프로젝트에 대해 정립된 요구 사항을 만족하고 정의된 목표를 충족하는 최종 제품 또는 결과물

이 튜토리얼에서는 프로젝트 관리 및 팀 단위 작업에 대한 베스트 프랙티스를 소개합니다.

개인, 팀, 회사 및 조직은 각각 고유의 프로젝트 관리 방법을 사용하지만, 일반적으로 대부분의 프로젝트는 여러 단계로 구성됩니다.

실시간 제작 사이클에 대해 학습할 때 살펴보았듯이 일반적인 제작 단계는 다음과 같습니다.

1. 사전 제작: 계획, 프로토타이핑, 파이프라인 설정, 초기 디자인 등 정식 제작을 시작하기 전에 이루어지는 작업입니다.
   
2. 정식 제작: 최종 2D 이미지 및 3D 모델, 오디오, 조명, 사용자 경험 구현을 비롯하여, 제품과 그 안에 포함되는 에셋을 제작합니다.
   
3. 사후 제작: QA(품질 검증), 편집, 테스트, 버그 수정, 최종 마무리 등 최종 제품을 완성한 후 이루어지는 작업입니다.
   
4. 운영: 판매, 수익화, 업데이트, 지속적인 유지 관리 등 제품 출시 후 지속적으로 진행하는 작업입니다.

적절한 시점에 순조롭게 결과물이 산출되도록 프로젝트를 수행하려면 제작 사이클의 각 단계를 적절히 계획하는 것이 중요합니다.

프로젝트를 수행할 때에는 적절한 일정을 계획하고, 시간을 관리하고, 커뮤니케이션하고, 협업해야 합니다. 독립적으로 프로젝트를 수행하더라도 제작 프로세스의 특정 시점, 특히 사용자 테스트를 진행할 때 타인과 커뮤니케이션하는 경우가 많습니다.

개인 또는 큰 팀의 구성원으로서 프로젝트를 성공적으로 완수하기 위한 지침을 살펴보겠습니다.

문서화 및 추적

프로젝트 관리에서는 문서화가 중요합니다. 설계 문서는 구현하려는 경험에 대한 특정 요구 사항을 기록할 수 있는 SSOT(Single Source of Truth) 역할을 합니다. 설계 문서는 프로듀서와 프로젝트 관리자가 디자인 및 개발 프로세스를 추적할 수 있도록 지원합니다.

프로젝트를 관리할 때에는 디자인 및 개발 프로세스를 안내하기 위해 다음과 같은 방법으로 설계 문서를 일관되게 사용합니다.

• 목적, 대상, 프로젝트 목표를 파악합니다.
• 프로젝트 계획서를 작성하여 필요한 프로젝트 단계를 파악합니다.
• 프로젝트 계획서 안에 구체적인 결과물과 기한이 포함된 타임라인을 만듭니다.
• 결과물을 생성하고 기한을 지키기 위해 지속적으로 마일스톤을 추적합니다.
• 팀 단위로 작업하는 경우 역할을 할당하고, 자신과 모든 팀원의 작업을 정의하고 그 우선순위를 정합니다.
• 자신과 모든 팀원이 역할과 책임을 숙지하고 지키도록 합니다.

시간 관리

효과적인 시간 관리는 적시에 프로젝트를 완수하는 데 중요합니다. 프로젝트를 관리할 때 필요한 일들은 다음과 같습니다.

• 디자인 및 개발 프로세스의 각 단계에 필요한 시간을 정합니다.
• 매일 프로젝트 계획서를 검토하고 일일 현황 요약 보고서를 프로젝트 관리자 또는 프로듀서에게 제공합니다(일일 업데이트는 '스탠드 업'이라고도 불림).
• 예상치 못한 지연이 있을 때에는 긴급 대책을 통해 필요한 경우 프로젝트 계획상의 작업과 결과물을 업데이트하고 그 우선순위를 다시 정합니다.
• 자신과 팀에 적합한 프로젝트 계획 및 관리 툴을 파악하고, 선택한 툴을 일관되게 사용합니다.

커뮤니케이션

명확한 커뮤니케이션이 없으면 협업이 어렵거나 불가능할 수 있습니다. 커뮤니케이션은 다른 사람들과 협업할 때 매우 중요한 기술이며, 효과적인 프로젝트 관리를 위해 필수적입니다.

프로젝트와 관련해 사람들과 커뮤니케이션할 때 필요한 일들은 다음과 같습니다.

• 타인이 팀원이든 외부 협업자를 지원하든 관계없이, 타인의 작업에 영향을 미치는 진행 상황과 문제를 명확히 파악합니다.
• 타인과 자신의 시간을 존중합니다.
• 업무에 대해 비평을 해야 하는 경우 건설적인 태도를 갖추고 타인의 기분을 고려합니다. 유용하며, 구체적이고, 존중받을 수 있는 피드백을 제공하는 데 중점을 둡니다.
• 피드백을 제공하는 사람의 말을 경청하고 소통하며 피드백에 대해 열린 태도를 취합니다. 피드백에 어떻게 대응할 것인지 솔직한 자세로 이야기합니다.

존중 및 프로 정신

개인의 발전이나 즐거움을 위해 프로젝트를 수행하더라도 타인과 함께 일할 때에는 타인을 존중하고 일에 전문가다운 태도를 취하는 것이 중요합니다.

타인과 함께 프로젝트 협업을 진행할 때 필요한 일들은 다음과 같습니다.

• 시간을 엄수합니다.
• 협업자, 동료, 고객에게 즉시 응답합니다.
• 타인의 의견과 기여를 인정합니다.
• 협업에 적극적으로 참여합니다.

프로젝트 시작 시 사전 제작 단계에서 구현할 사항과 그 범위를 정하기 위해 설계 문서를 작성합니다. 이러한 문서에 포함되는 것들은 다음과 같습니다.

• GDD(게임(또는 경험) 설계 문서)
• 타겟 사용자 페르소나
• 프로젝트 헌장
• 기술 사양

설계 문서

설계 문서에는 프로젝트에 대한 청사진이 담기며, 포함되는 내용은 다음과 같습니다.

• 대략적인 개요(예: 게임(또는 경험) 설계 문서에 담긴 전반적인 프로젝트 비전)
• 프로젝트에서 특정 파이프라인의 요구 사항 및 기준
• 특정 기능의 자세한 설계 사양

개략적인 설계 문서에 포함되는 내용은 다음과 같습니다.

• 프로젝트의 목표 및 목적
• 대상 사용자 및 고객
• 프로젝트의 주요 특징
• 결과물의 최종 형식

설계 문서에는 다이어그램, 플로 차트, 스케치, 영감을 얻기 위한 유사 제품 이미지, 제품의 의도된 디자인(look and feel)을 파악하기 위한 참조 이미지가 포함될 수 있습니다.

설계 문서가 아직 없는 경우 자료 섹션에서 설계 문서 템플릿의 PDF 버전을 다운로드하거나, Google 문서 사본을 만들 수 있습니다.

프로젝트 헌장

설계 문서가 승인되어 프로젝트를 진행할 수 있는 경우, 특히 팀 단위로 작업할 때 프로젝트 헌장이 유용합니다. 이 문서는 프로젝트의 목표, 프로젝트 수행 방법, 관계자를 비롯하여 전체 프로젝트를 설명하는 공식 문서입니다. 프로젝트 헌장은 사전 제작 단계와 정식 제작 단계에서 모두 사용됩니다.

자료 섹션에서 예시 프로젝트 헌장의 PDF 버전을 다운로드하거나, Google 문서 사본을 만들 수 있습니다.

프로젝트 헌장에 일반적으로 포함되는 내용은 다음과 같습니다.

• 프로젝트의 당위성
• 프로젝트의 목표 및 제약
• 주요 관계자
• 확인된 위험
• 프로젝트의 이점
• 예산에 대한 일반 개요

추가 문서

프로젝트에 따라 제작 범위와 계획을 정하기 위해 사전 제작 단계에서 추가 보조 문서를 작성해야 할 수 있습니다. 필요한 경우 사전 제작 및 정식 제작 단계에서 이러한 문서를 반복 작성할 수 있습니다.

다음의 문서를 예로 들 수 있습니다.

• 기술 문서: 여기에는 프로젝트에서 기술적인 부분에 해당하는 아키텍처 및 기능이 기술된 문서가 포함됩니다.
• 회의록: 팀 단위로 작업하는 경우, 전체 팀에서 작업 중인 사항, 종속성, 진행 상황, 방해 요소를 기록하기 위한 회의록을 활용하는 것이 좋습니다.
• 제안서 또는 요청서: 회사의 승인을 받아야 하거나 투자자에게 프로젝트 자금 제공을 요청하는 경우, 정식 제안서 또는 요청서를 사용하는 것이 좋습니다.

프로젝트의 범위를 명확히 정했으면, 이제 적절한 일정을 잡고 프로젝트 계획서를 관리하여 프로젝트 관리 방식을 계획할 차례입니다. 프로젝트 계획서는 대개 사전 제작 단계에서 작성되지만, 프로젝트의 진행 상황을 추적하기 위해 정식 제작 단계에서 사용되고 반복 작성되기도 합니다.

프로젝트 계획서에서는 설계 문서와 프로젝트 헌장에 명시된 요소를 사용하여 구체적인 작업과 제공 날짜를 정합니다. 프로듀서 또는 프로젝트 관리자는 이러한 계획서를 작성한 후 변경 사항이 발생하면 그에 따라 계획서를 업데이트합니다. 또한 이들은 정해진 작업과 필요한 결과물 대비 진행 상황을 추적하기 위해 계획 자체에 포함되거나 별도로 구현될 수 있는 프로젝트 트래커를 제작합니다.

프로젝트 계획서를 작성하지 않고 준수하지 않으면 스코프 크리프(계획서에 새로운 아이디어와 기능을 지속적으로 추가하는 것)가 발생하며 프로젝트의 실패, 지연, 예산 초과 등으로 이어질 수 있습니다.

개인과 팀 모두가 프로젝트를 성공적으로 추적하기 위한 가이드라인은 다음과 같습니다.

• 필요한 프로젝트 단계를 파악합니다.
• 팀 단위로 작업하는 경우 구체적인 프로젝트 역할과 책임을 파악하고 할당합니다.
• 구체적인 결과물과 기한이 포함된 타임라인을 만듭니다.
• 스코프 크리프나 과도하게 의욕적인 설계 계획서, 촉박한 시간 제약 등을 비롯한 프로젝트 관리 문제를 파악합니다.
• 프로젝트 완료 기한을 결정합니다.
• 전체 프로젝트를 구성하는 프로젝트의 하위 요소별로 기한을 정합니다.
• 프로젝트 단계별로 합당한 기간을 둡니다.
• 팀 단위로 작업하는 경우 목록에 있는 작업별로 작업 담당자를 지정합니다.

고객을 위한 프로젝트 제작

고객을 위한 프로젝트를 제작하는 경우, 다음과 같은 내용을 추가로 고려하면 효과적인 프로젝트 관리에 도움이 될 수 있습니다.

• 명확한 프로젝트 역할 파악 - 고객과 그룹 간의 연락 담당자, 프로젝트의 여러 요소와 관련된 주요 관계자를 파악하는 작업이 포함됩니다.
• 고객의 기대를 명확히 이해
• 고객과의 명확한 커뮤니케이션을 지원하기 위한 계획 수립 - 고객과의 커뮤니케이션 방법과 고객과 프로젝트를 검토하는 데 필요한 온라인 협업 툴을 파악합니다.

프로젝트의 모든 단계를 파악하고 계획할 수 있는 다양한 프로젝트 관리 툴이 있습니다. Trello, Favro, Airtable, Monday.com, Google Apps, Jira, GitHub와 같은 제품은 개인과 팀이 작업 흐름을 계획하고 추적하여 제시간에 실행하고 제공할 수 있도록 지원하는 다양한 기능을 제공합니다. 이러한 프로젝트 관리 툴 대부분에는 특정 프로젝트 요구 사항에 맞게 재사용할 수 있는 템플릿이 있습니다.

이러한 툴을 아직 사용하지 않는 경우, 어떤 툴이 활용할 만한지 시간을 내어 살펴보고 다음 프로젝트에 사용해 볼 툴을 확인하세요.

이러한 툴을 이미 사용 중이지만 만족스럽지 않다면, 보다 효율적인 지원이 제공되는 새로운 옵션이나 기능이 있는지 조사해 볼 좋은 기회입니다.

경험 공유

특정 툴을 효과적으로 사용해 보았거나 조사를 통해 정말 유용한 툴을 발견한 적이 있다면, 다른 학습자에게 도움이 되도록 댓글로 정보를 공유해 주세요.

사후 제작 단계에서는 프로젝트 퍼블리시를 준비합니다. 프로젝트 계획서에는 결과물에 대한 QA(품질 검증) 테스트, 콘텐츠 편집 및 수정, 버그 수정, 최종 마무리 등에 대한 설명이 있어야 합니다.

QA 테스트에 대해 좀 더 자세히 살펴보겠습니다.

QA 테스트

QA 테스트 프로세스에서는 프로젝트 관리 차원에서 QA 테스트 스크립트와 버그 리포트 프로세스라는 두 가지 중요한 사항을 고려해야 합니다.

테스트 스크립트
QA 테스트 스크립트는 일련의 단계로 이루어지며, 테스터는 이를 따르고 그 결과를 기록해야 합니다. 이러한 스크립트는 일반적으로 정식 테스트가 시작되기 전에 작성되며, 특정 프로젝트 요구 사항 및 사용 사례에 대해 제품을 평가하는 데 사용됩니다. 제품의 사용자 경험에 대한 팀의 가정을 검증하는 데에도 사용될 수 있습니다.

버그 리포트 추적
버그 추적 및 해결은 제품 제공을 위한 마무리 작업에서 필수적인 부분입니다. 버그 리포트 추적에 사용되는 툴은 다양합니다. Jira 및 Github를 많이 이용하지만, 많은 개인 작업자와 팀이 스프레드시트를 사용하기도 합니다.

일반적인 버그 리포트에 포함되는 내용은 다음과 같습니다.

• 제목/간단한 요약: 버그에 대한 설명이 포함된 제목입니다.
• 확인된 빈도: 해당 버그가 발생하는 빈도(항상, 거의 항상, 무작위, 가끔)입니다.
• 재현 단계: 버그를 재현하는 방법에 대한 상세한 단계입니다. 개발자가 추가 정보 없이 버그를 직접 재현할 수 있을 만큼 내용이 상세해야 합니다.
• 상세 설명: 버그에 대한 정보와 버그가 사용자 경험에 미치는 영향을 좀더 자세히 설명하는 요약 내용입니다.
• 기타 관찰 사항: 여기에는 버그의 원인 및 기타 관련 세부 정보(예: '오류가 일관되지는 않지만 낮보다 밤에 더 자주 발생함')가 포함될 수 있습니다.

버그 리포트에 대해 자세히 알아보려면 Ministry of Testing에서 제공하는 버그 리포트의 기술(영문)을 살펴보세요.

프로젝트 테스트, 수정, 검증이 완료되면 퍼블리시할 준비가 된 것입니다. 프로젝트 계획서에는 제품을 퍼블리시할 시기와 위치에 대한 설명이 있어야 하며, 제공 기한을 준수하고 원래 정한 날짜에 프로젝트를 퍼블리시하는 것이 좋습니다.

사전 제작에서 정한 기한을 정확히 지키지는 않더라도, 명확한 프로젝트 계획을 따르고 도중에 조정함으로써 원래 출시 날짜의 합당한 범위 내에서 기한을 준수해야 합니다.

운영 활동

제작 사이클의 마지막 단계인 운영에는 제품 출시 후 지속적으로 이루어지는 작업이 포함됩니다. 일반적으로 운영 활동은 출시 전에 시작되지 않지만 사전 제작 단계에서 파악하고 계획해야 합니다. 이러한 활동에는 지속적인 판매, 수익화, 업데이트, 연속적인 유지 관리 등이 포함됩니다.

프로젝트 사후 평가

마지막으로, 프로젝트가 출시되면 자신과 팀(존재하는 경우)이 설계 및 개발 프로세스를 되돌아볼 수 있도록 사후 평가 계획을 세워야 합니다. 사후 평가를 통해 잘 된 영역과 그렇지 못한 영역, 향후 프로젝트에서 개선할 방법을 파악할 수 있습니다.

사후 평가를 수행하는 간단한 방법 중 하나는 세 개의 열이 있는 차트를 만들고 다음과 같은 항목을 파악하는 것입니다.

• 시작할 일
• 중단할 일
• 계속할 일

특정 프로젝트에 적합하거나 차별화된 솔루션을 찾는다면, 사후 평가를 구성하고 지원하는 데 사용 가능한 많은 툴과 프레임워크가 있습니다.

이 튜토리얼에서 프로젝트 관리의 기초를 살펴보았습니다. 이 튜토리얼의 내용은 크고 작은 실시간 경험 구현 또는 기타 모든 종류의 프로젝트에 적용됩니다.

다음 프로젝트를 시작할 때 이러한 권장 사항을 사용하여 진행 상황을 파악하고 제시간에 결과물을 제공할 수 있습니다. 다음 포트폴리오 프로젝트를 위해 문서와 간단한 프로젝트 계획서 또는 트래커를 준비해 보면 어떨까요?