[UE/Project] 기능 명세서 작성

1. 진행 일자

25.02.17 월요일

• 1차 - 12:15 ~ 13:15
• 2차 - 14:10 ~ 16:55
• 3차 - 17:00 ~ 18:00
• 4차 - 19:00 ~ 19:15

 

2. 명세서 작성 목적

1. 구현 방향 결정

• 동일한 기능일 지라도 각 자 생각하는 바가 다를 수 있다.
• 소통을 통해 생각을 통일하고 팀이 생각한 방향을 결론지을 수 있다.

2. 구현 담당 결정

• 방향이 정해졌다면 누가 그 길을 갈지 결정할 수 있게 된다.
• 그 구현의 결과는 팀이 생각했던 것과 동일하게 나올 것을 예측할 수 있다.

 

3. 진행 절차

3.1 기능 명세 작업

1. 필수 기능들을 모두 나열한다.
2. 각 기능별 구체화한다.
3. 팀원 의견 제시
   1. 자유롭게
4. 팀원 의견 수용
   1. 게임 컨셉과 어울리는가?
   2. 구현이 가능한가?
   3. 시간이 충분한가?
   4. 다양한 기능이 있다면 어떤 것이 더 효율적인가?
5. 팀원 의견 결정
   1. 과반수가 해당 기능 구현에 동의하였는가?

 

3.2 최종 검토

1. 전체 다시 요약 (다듬기)
2. 궁금했던 부분들을 다시 구체화
3. 놓쳤던 기능들을 추가
4. 구현 기능 확정

 

4. 기능 명세 보류

1. 부족한 아이디어

• AI 기능 구현에 대한 학습이 아직 부족하여 아이디어를 원활하게 제시하기 어렵다 판단하였다.
• 이에 따라 팀원들이 AI 기능을 충분히 학습한 후, 기능 구현을 진행하기로 합의하였다.

2. 구현되지 않은 기능의 불확실

• 게임 규칙은 큰 틀만 정하였다.
• 구현이 되지 않은 상태에서 게임 규칙을 세부적으로 정하기가 어렵다고 판단하였다.
• 따라서 일부 기능을 먼저 구현한 후, 직접 플레이를 통해 피드백을 수집하고, 이를 기반으로 게임 규칙을 정립해 나가기로 결정하였다.

 

5. 회의 자세

1. 의견 제시는 언제나 팀을 위한 것

• 서로가 아이디어를 제시하는 상황이기에 의견 충돌이 발생한다.
• 자신의 의견이 다른 사람 의견에 의해 받아들여지지 않을 경우 감정적으로 매몰될 수 있다.
• 그럴 경우 다른 사람 의견 또한 나와 동일하게 팀을 위한 의견임을 인지하고 감정에서 벗어나 다음 구현에 대해 생각하는 자세가 필요하다.

2. 지금이 아이디어를 제시할 수 있는 유일한 찬스

• 프로젝트는 시간과의 싸움이다.
• 프로젝트를 진행하다 갑자기 드리프트하여 방향을 꺾는 것은 많은 비용을 발생시고 팀원들의 사기 또한 저하 될 수 있다.
• 회의 진행 전, 최종 결정된 기능들이 곧 우리가 구현할 것임을 공지하고 향후 추가 의견 제시가 있을 때 변경이 어렵다는 것을 얘기할 필요가 있다.