[기획] 프로젝트 관리

우리가 반복하던 리스크들

• 낙관성 추정의 오류: "3일이면 되겠지" 했던 작업이 실제로는 일주일씩 걸린다.
• 정보 비대칭: 내 할 일만 잘하면 된다는 생각 때문에 누가 뭘 하고 있는지 아무도 모른다.
• 막판 통합: 기능부터 잔뜩 만들어놓고 빌드는 마감 직전에야 뽑는다. 그 순간 온갖 문제가 한꺼번에 터진다.

이 세 가지를 해결하기 위한 방법이 1주일 단위 스프린트, 칸반 보드, 그리고 명확하고 단순하지만 엄격한 팀 규칙이다.

애자일이란

애자일은 작고 반복적인 개발 주기를 통해 제품을 만들어가는 방법론이다. 목표나 요구사항, 개발 환경이 수시로 바뀌는 프로젝트에 특히 적합해서, 많은 게임 프로젝트에서 채택하고 있다.

기본 프로세스는 다음 순서로 진행된다.

업무 분해(WBS) → 규모 추정 → 우선순위 결정 → 일정 배치

1. 업무 분해 (WBS)

WBS(Work Breakdown Structure)는 프로젝트 전체를 작은 작업 단위로 쪼갠 작업 분해도다. 처음부터 시간 단위로 쪼개는 게 아니라, 먼저 전체 업무를 큰 기능 덩어리로 나누고 그 다음 각 기능을 다시 시간 단위 작업으로 세분화하는 순서로 진행한다.

이때 각 기능에는 다음 세 가지를 함께 정리해야 한다.

• 우선순위
• 추정 작업 시간
• 해당 기능이 제대로 구현되었는지 검증할 체크리스트

여기서 중요한 건 기획의 완성도다. 기획이 꼼꼼할수록 기능 정리도 정확해지고, 뒤에 나올 추정치와 검증 체크리스트의 품질도 같이 올라간다.

2. 우선순위 결정 (MoSCoW)

기능마다 아래 네 등급 중 하나를 매긴다.

3. 추정치 산정

각 기능을 구현하는 데 걸리는 시간을 산정하는 단계다. 정확하게 추정하려면 결국 그 기능을 다시 WBS로 한 번 더 쪼개봐야 한다.

여기서 실전 팁 하나: 업무 시간을 추정할 때는 반드시 버퍼를 넣어야 한다. 스스로 추정한 시간에 대략 1.5배를 곱해야 실제 소요 시간에 가까워진다. 앞서 말한 "낙관성 추정의 오류"를 시스템적으로 보정하는 장치인 셈이다.

4. 의존성 연결

의존성이란 작업 간의 영향 관계를 말한다. 예를 들어 기본적인 애니메이션 시스템이 먼저 구현돼야, 이동 속도에 따라 애니메이션 프레임을 제어하는 시스템도 만들 수 있다. 이 경우 프레임 제어 시스템은 애니메이션 시스템에 의존성이 있는 것이다.

쪼개놓은 작업들을 의존성 단위로 연결해야 업무 배분이 명확해지고, 팀원 간 비는 시간이나 병목이 생기지 않는다. 또한 이 과정에서 처음엔 두루뭉술했던 작업 단위가 더 명확하게 다듬어지는 효과도 있다.

5. 검증 체크리스트 (데모 방식)

해당 기능이 완벽하게 구현되었음을 증명할 수 있는 테스트 항목이다. 여기서 주의할 점은, 이게 단순히 기능 목록 나열이 아니라는 것이다. 최대한 유저 관점에서 체험할 수 있는 요소 위주로 정리해야 하고, 프로그래밍·기획·그래픽 작업을 모두 아우를 수 있도록 구성해야 한다.

6. 스프린트 운영

스프린트는 반복적인 개발 주기다. 여기서 핵심은 스프린트가 단순히 하나의 긴 작업을 기간으로만 나눠놓은 게 아니라는 점이다. 각 스프린트는 그 자체로 완결된 형태의 결과물이 나와야 한다. 그래서 매 스프린트의 마무리는 항상 빌드로 끝맺는다.

운영 원칙은 이렇다.

• 일 단위 업무는 무조건 그날 끝내는 게 원칙
• 못 끝냈다면 야근을 하거나, 업무를 끝내지 못한 팀원을 서포트해서 일 단위 업무를 마무리
• 주말은 쉬고 회복하는 시간으로 남겨둔다

7. 그라운드 룰

팀의 기본적인 작업 규칙이다. 우리 팀은 이렇게 정했다.

• 지각/결석/조퇴 시 팀 소통 채널에 공유
• 밀린 업무는 해당 스프린트 내에 반드시 완료
• 자리 비움 이슈는 팀장에게 공유
• 모든 작업은 최대한 기록으로 남긴다
• 기획 내용이 바뀌면 반드시 기획서를 갱신한다

8. 커뮤니케이션 컨벤션

• 구두로 소통해서 바뀐 내용은 반드시 기획서에 갱신·기록한다
• 프로젝트 관련 논의는 항상 팀 디스코드에서 진행한다
• 공지나 작업 요청에는 반드시 이모티콘으로 읽음 체크를 하고 답변한다