팀 프로젝트 어떻게 진행해야할까? [4편]ㅁㅁ을 하자

4. ㅁㅁ을 하자.

시작부터 강렬한 짤방을 올려보았습니다.

다소 여성분들에겐 푸핰! 하고 난 여기서 빠져나가겠어!!!!!!

하실 수도 있겠지만...

(뒤 늦게나마 = _=죄송합니다...)

아무튼..

네 번째로 언급할 내용은 

4. 설계를 하자. 

입니다.

만약 이 글을 보시는 분이 프로그래머 분이라면, 혹 프로젝트를 진행하기 앞서

어떤 클래스가 어떤 메소드(함수)들을 내포하고 수행할 것인지

설계 해보신 적이 있으실 겁니다.

팀 프로젝트를 진행하는데 있어서도 위와 같은 생각을 하는 것은 똑같다고 생각합니다.

제가 "설계를 하자" 라고 언급하였는데, 왜 그랬을까요~?

이유는 팀 프로젝트에서 각 팀원들이 맡은 역할을 잘 분배하고 잘 수행하기 위해서 입니다.

제가 몸담고 있는 '게임' 이라고 하는 분야를 포커스로 이야기를 진행하도록 하겠습니다.

'게임' 이라고 하는 분야는 옛날엔 오락이었을 뿐이었지만,

현재는 '예술' 이라고도 칭하는 경지에 이르렀습니다.

디자인/개발/음악/기획/시나리오 등 많은 분야의 사람들이 모여서 같이 어떤 창작 활동을 하기 때문에 저는 예술 그 이상의 분야라 생각합니다.

그런데, 왜 팀 프로젝트에서 설계를 할까요?

간단한 상황을 들어보도록 하겠습니다.

어떤 미소녀 캐릭터가 있고 사운드 효과들이 포함되어 있으며 스토리가 포함된 액션 게임을 만든다고 칩시다.

시나리오 작가 : 열심히 미소녀 캐릭 액션 게임 스토리를 상상했습니다.

디자이너A : 주인공을 만들기 위해 피카츄를 그렸습니다.

디자이너B : 배경을 그렸습니다.

음원 제작가 : BGM과 이펙트 소리들을 만들었습니다.

프로그래머A : 대선 준비를 했습니다.

프로그래머B : 치킨만 먹었습니다.

자...우리는 여기서 무엇을 알수있는가? 하면.

네 안됩니다!!

안되요!! 뭘 해달라는거야!!

어떤 미소녀 캐릭터가 있는건 알겠는데, 스토리는 작가가 알아서 한다치고

디자이너와 프로그래머 및 음원 제작가는 대체 무엇을 만들었을까요...

알 수가 없습니다.

그냥 프로그래머 B가 치킨먹을때 같이 먹었을거 같아요.

여러분. 팀 프로젝트를 할 때는 항상 기본적인 육하 원칙을 지켜서 진행해야합니다.

1. 언제

2. 어디서

3. 어떻게

4. 무엇을

5. 누가

6. 왜

기본적으로 위 사항을 딱 한번만이라도 생각해본다면 여러분은 팀프로젝트를 진행할 수 있습니다.

일일이 모든 사항을 언급해서 적진 않겠습니다만, 간단히 요약해서 정리하자면

팀 프로젝트를 진행 하실 땐, 항상 누가 무엇을 한다. 라는 것을 지적해서 정해야 합니다.

따라서, 팀 프로젝트를 진행할 땐 항상 설계를 해야하는데,

어떤 설계를 해야하는가? 에 대해서 설명하겠습니다.

1. 일주일 간 진행할 목표를 정하자.

2. 다다음 회의 내용을 생각하자.  (다음이 아닙니다! 다다음 이에요!)

3. 스케줄을 만들자.

입니다.

첫 번째 항목부터 보도록 할까요.

1. 일주일 간 진행할 목표를 정하자.

프로젝트를 진행할 때 최종 목표는 이미 무엇을 만들자! 라는 식으로 정해져 있습니다.

그러면 마지막 최종 목표에 도달하기 위해 무엇들이 필요한지를 살펴봐야합니다.

제가 겪었던 한 예를 들어서 설명하겠습니다.

어떤 프레임워크를 만들기 위해 여러가지 어떤 내용들이 있는지 기능 별로 나눠서 포스트잇으로 적어보던 중 생각보다 많은 내용들이 등장한다는 것을 알게 되었던 적이 있습니다.

이 기능들이 모여서 결과적으론 최종 목표에 도달한다는 것도 다시 한번 눈으로 확인할 수도 있었지요.

그리고 이렇게 나눠놓은 리스트중에서 우선순위를 잡습니다.

우선순위 별로 포스트잇을 정렬시켜보니 위 그림처럼 나왔었습니다.

우선순위의 가중치는 여러 요인이 될 수 있습니다.

내가 지금 할 수 있는 것? 지금 당장해야 하는 것?

A 기능을 만들기 위해 B와 C가 미리 구현이 되어야한다는 점? 등등..

어쨋든 중요한 점은 이렇게 나눠본 프로젝트의 내부 항목들 중에서

이번 주에는 1~2번 기능을 구현하자. 라고 정하고 한 주 동안 개발을 시작하는 것 입니다.

만약 다음주까지 이 기능을 구현하지 못했다면 이 기능을 만드는데는 

"시간이 좀 더 필요하다" 라는 점을 경험할 수 있게 됩니다.

그리고 다음에 또 이와 같이 비슷한 기능을 만들 때 어느정도의 시간이 필요하겠구나

라는 것을 가늠할 수 있게 될 수 있습니다.

이런식으로 1~2 주 정도 진행하다보면 프로젝트를 진행하는데 감이 많이 잡히게 됩니다.

팀 프로젝트 단위에서도 마찬가지로 각자 맡은 개발분야에서 이런식으로 약속한 기간에 맞춰 회의 할 때마다 중간 점검을 하는식으로 진행을 하는 것이 좋습니다.

2. 다다음 회의 내용을 생각하자

왜 다음 회의 내용이 아닌 다다음 회의 내용을 생각하자 라고 했을까요.

사실 다음 회의 내용은 이번 주에 자신이 맡은 개발 파트가 어떻게 진행되냐에 따라

다음 개발 계획으로 진행이 될 것인지 말 것인지 의논하게 됩니다.

그래서 다다음 회의 내용을 생각하자 라고 한 것 입니다.

그러면 어짜피 다음 회의 내용을 생각한거랑 같은거 아닌가?

라고 생각이 드실텐데, 또 그것은 아닙니다.

그럼 대체 뭘 생각하란거야? 라고 느끼실텐데요.

한가지 상황을 통해 예를 들어보겠습니다.

1 주(진행중) - 어떻게 될지 모른다...다 만들수 있을지 없을지...(A 기능을 구현 중)

2 주 - B 기능에 대해서 생각해봐야한다.

그럼. 3 주 - ?????

무엇을 준비해야할까?

바로. 피드백 입니다.

다다음 회의 내용을 위해 생각할 것은 프로젝트에 대한 개발 내용보다는 

(1)이전에 했던 작업물에 대한 다른사람들을 위한 피드백 또는

(2)내가 하고있는 작업물에 대한 내용 정리입니다.

왜 이것을 해야할까요?

팀 프로젝트의 목적 상. 본래 어떤 목표를 위해 개발을 하는 것이지만.

결과만 바라보고 개발 과정을 정리하지 않으면

뒤에는 큰 후회만 남습니다.

왜 냐구요?

그 프로젝트가 끝까지 완수 될지 안될지 누가알아요!!!

만약 프로젝트가 중간에 파토가 나버리면 쏟아 부었던 노력에 대한 보상은 누가해주나요!?

아무도 안해줍니다. 없어요. 누가 해줄까요. 사장님? 팀장님?

물론 회사 라면 월급받고 일할테니 나의 경력과 돈이 생기겠지요.

하지만, 상업적이거나 회사에서 일하는 팀 프로젝트가 아니라면, 그 누구도 프로젝트가 파토났을 때 보상을 해줄 사람이 없습니다.

따라서, 다다음 회의 내용을 위해 피드백을 준비하라 라고 한 이유는

 (1) 팀 프로젝트가 계속 활발히 개발되어지고 있으며, 우리는 할 수 있을 거야 라는 확인하는 점

 (2) 중간 중간 내용을 정리하고 점검하며 내 실력을 쌓고 

 (3) 다른 사람이 만들었던 내용을 저장해야한다는 점

때문 입니다.

이런 내용들은 추후에 여러분에게 어떠한 것으로든 지적 재산이 될 수 있습니다.

3. 스케줄을 만들자

마지막으로 강조할 내용은 스케줄입니다.

Q. 왜 스케줄을 만들어야할까요?

A. 가장 큰 이유는 팀원들 스스로에게 책임감을 부여하기 위함 입니다.

시간 제한이 있다는 점은 항상 맡은 이에게 언제까지 끝내야 한다라는 책임을 느끼게합니다.

그리고 압박감을 느끼게 되지요. 물론 시간적으로 여유가 있다면 압박감은 덜하겠지만

언제까지 만들어야 한다는 점은 바뀌지 않습니다.

때문에, 팀 프로젝트를 진행 할 때는 꼭 스케줄을 만들어서 언제까지 무엇을 만들겠다 라는 규칙을 정해서 진행해야합니다.

적다보니 주관적인 내용들이 들어가면서 조금 글이 길어진 것 같습니다.

그래도 여기까지 읽어주셨다면 정말 감사드리고, 한줄 요약으로 마치겠습니다.

한줄 요약

 - 주 단위로, 작은 목표를 정해서 진행하고, 스케줄을 잘 관리하자!