[은고] 게임 프로그래밍

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. 가장 큰 이유는 팀원들 스스로에게 책임감을 부여하기 위함 입니다.

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

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

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

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

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

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

한줄 요약

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

3. ㅁㅁ을 자주 가져라.

팀 프로젝트를 어떻게 진행해야하는가? 하는 문제를

'보상', '참여 유도' 를 통해 이전 글에서 이야기 했었는데요.

세 번째로 언급할 사항은 "만남을 제때 가져라" 입니다.

응?? 왜 결론을 먼저 바로 얘기해주냐구요?

(숨겨봤자...뻔히 보이기 때문에...)

이미 첫번째 글에서 언급 된 

'3. 정기적인 회의 여부' 라는 항목에서 추론할 수 있기 때문에 결론을 바로 언급했습니다.

이 사항은 온라인/오프라인 작업에서도 똑같이 중요한 대목입니다.

정기 회의가 있는 회사라면 기본적인 내용이라 별로 유심히 보시지 않을 수도 있는데요.

혹, 대학 생활을 하시고 계시거나 별도의 온라인 활동을 통한 팀 프로젝트를 진행하고 계신 분들이 있으시다면 도움이 되실 수 있을까 해서 설명해보도록 하겠습니다.

앞서, 팀 프로젝트가 파토가 나는 경우의 절반은 팀원 참여의 부재로 인해 발생하는 예가 많다고 얘기한 적이 있습니다.

왜 그럴까요? 그냥 팀원 한명 자체가 삐꾸- 라서?

뭐...그렇다면 애시당초 사람 문제니 여기서 다룰 내용은 아닙니다.

그러나..참여를 하다가 중간에 파토가 나는 경우라면?

여러 요인이 있을 수 있으나, 여기서 다루고자 하는 것은 "팀 프로젝트가 잘 되다 파토가 나는가?" 라는 문제를 수면위로 끌어올리고자 합니다.

우리나라 IT기업들을 보면 흔히 회의를 엄청나게 많이하는 것을 볼 수 있습니다.

(아주 사람 귀찮게 하네 라고 느껴질 정도?)

또는 엄청 적게 하는 경우도 있지요.

(이건 뭐 하자는 건지 말자는건지...?)

잠시 '회의' 라는 말의 사전적 의미를 적어보겠습니다.

뭔가 '회의' 라는 단어 자체에도 많은 뜻이 내포되어 있군요.

여기서 다루고자 하는 회의는 가장 첫번째 회의(回議) 와 가장 마지막 회의(會議) 입니다.

왜 제가 "만남을 제때 가져라" 라고 했을까요?

먼저 제가 여기서 언급하는 회의가 필요한 이유는 3가지로 정리 됩니다.

(일반적인 회의의 이유에 대해서는 언급하지 않겠습니다. 당연히 필요하니까 회의하잖아= _=)

1. 팀 프로젝트의 진행(Progress)를 확인하기 위해

2. 팀원들의 책임감을 고양시키기 위해

3. 팀 프로젝트의 개발 효율성을 증대시키기 위해

이렇게 3가지 이유 입니다.

왜 이렇게 나왔는지 각 이유를 따라 적어보도록 하겠습니다.

1. 팀 프로젝트의 진행(Progress)를 확인하기 위해

왜 팀 프로젝트의 진행도를 확인해야 할까요? 

음...그냥 관리차원에서? 서로 맡은 파트가 얼마나 진행 됐는지 감독하려고?

윗 사람이 아랫사람을 관리하는 것이라면 그럴지도 모르겠네요.

하지만 동일 선상의 관계를 가진 팀원들이라면 누가 누구를 관리/감독 할 일이 있을까요.

ㅁㅁ

제 대답은...

진행도를 확인하는 것은 모두가 다같이 책임져야하고 알아야하는 내용이기 때문이라는 것.

입니다.

(아마 2. 팀원들의 책임감을 고양시키기 위해. 라는 말이랑 겹쳐 보일 수도 있겠네요.

하지만 2번에서 언급할 근거는 다른 내용이니 걱정안하셔도 됩니다)

본론으로 들어가도록 하조~

흔히 IT기업에서 프로젝트 매니저 라고 하는 직군을 볼 수 있었을 겁니다.

이 사람들 대체 왜 있을까요? 저도 모르겠어요...

근데 뭔가 하는거 같긴해요..

위 말은 농담으로 적은 내용입니다만, 뭔가 필요하고 하는 일이 있으니까 있는 직군입니다.

(그 분들이 몸 담고 있는 직군의 정체성을 부인하고 싶은건 아니에..!)

(공격 하...지말..주..주세요..으어..)

그런데 소규모 팀 프로젝트 단위에서 프로젝트 매니저가 있을까요? 없겠지요~

하물며 회사도 아닌, 초급자/인디/동아리 등등...

이런곳에서 진행하는 팀 프로젝트라면? 더더욱 없습니다.

그래서 우리가 진행하는 팀 프로젝트가 어느 정도 진행되고 있고, 어디까지 왔는지를 서로서로가 확인할 필요가 있습니다.

그럼, 이렇게 해서 얻는 이점이 뭘까요?

바로 프로젝트 개발 계획의 조정이 가능하다는 점!

(개발 속도를 올린다 / 어떤 기능에 좀 더 주안을 두자. 등등)

더욱이 권위있는 리더가 이런 것들을 관리해주는 것이 아닌 팀 프로젝트라면 회의에서 즉석으로 얘기가 가능하기 때문에 회의의 필요성을 자주 느껴지실 겁니다.

물론 몇몇 분들은 회의 시간 자체도 아까워...라고 생각하실 수도 있으실텐데요.

다른 파트의 사람들과의 시간이나 협업 관계를 맺다보면 아마 저절로 필요성을 느끼실 수 있으

리라 생각듭니다.

그렇다고 너무 귀찮을 정도로 많은 회의는 가끔 짜증나긴하지요..

2. 팀원들의 책임감을 고양시키기 위해

회의를 한다는 것이 어째서 팀원들의 책임감을 고양시키는 게 될까요?

사실...책임감을 고양시킨다기 보다는 현실적으로 얘기하자면

회의에 참여해서 보여주기 위해 팀 프로젝트에서 맡은 부분을 반 강제적으로라도 참여하게 된다는 것 때문에 그렇습니다.

저는 자주 팀 프로젝트를 진행하는 사람들이 어떻게 진행해야할지 모르겠어...

라고 이야기하면 딱 한마디만 합니다.

"맨날 모여서 회의해 = _=)..그럼 뭔가 될꺼야"

(속으로)그리고 도주하는 너의 팀원을 보겠지...

회의라는 것은 어찌보면 사람을 귀찮게 하지만, 돌려 말하면 귀찮아지게 한다는 것은 뭔가 준비를 하게 만들기 때문에 귀찮게 한다는 것 입니다.

만약 회의가 귀찮지 않다면, 그건 회의를 좀 덜해보신듯...?은 아니고

이미 "즐기는 자"의 반열에 들어가신 것 일수도 있겠군요.

아무튼. 회의를 정기적/지속적으로 하면 각 팀원들의 참여를 유도할 수 있고, 회의에서 할 내용을 준비하게 만듬으로 팀 프로젝트를 지속 유지/개발 할 수 있습니다.

그래서 두 번째 이유를 팀원들의 책임감을 고양시키기 위해 라고 언급을 하였습니다.

3. 팀 프로젝트의 개발 효율성을 증대시키기 위해

음..회의 라는 건 사실 양날의 검 입니다.

작업할 시간에 영향을 끼칠 정도로 너무 많으면 오히려 방해 요소이고, 스트레스만 줄 수 있습니다.

그렇다고 너무 회의를 줄이게 되면, 현자 모드가 와버리는 경우가 있지요.

그래서 적당한 타이밍과 적당한 회의 시간이 중요합니다.

만약 같은 파트의 사람들끼리 모여있는 거라면 시간 제한 또는 스케줄을 만드는것이 좋습니다.

타임리미트 또는 due date(마감일)를 잡는다는 것은 현업에서도 흔히 발생하는 사건이며

일반적으로 그렇게 흘러갑니다.

개개인의 역량 및 스킬을 쌓기 위해 어떤 제한된 환경으로 국한 시키고 작업하는 습관은 나쁘지 않다 생각합니다.

(제 생각에는 개인 프로젝트에서도 적용시켜서 훈련할 필요가 있다 봅니다)

물론 상업적으로 진행하는 금전적인 목적의 팀 프로젝트라면 위 내용을 꼭 지킬 필요는 없습니다. (실력 쌓는것 보다도 일단은 돈버는게 중요하니까...만약 회사라면 이야기가 조금 다릅니당!!)

그리고 팀 프로젝트를 진행하는데 있어서 스케줄은 각 팀원들의 반 강제적 참여를 유도하게 됩니다. 만약 타임리미트가 없는 일이 주어졌다면, 그게 언제 끝날지 알 수가 없기 때문에 마냥 그 팀원이 해결해주기만을 기다리고 있어야하지요. 

(이런 점은 제가 뭐 따로 언급하지 않아도 다들 몸소 느껴보셨거나 느껴보실거라 생각듭니다)

따라서, 이런 스케줄이나 타임리미트들은 회의에서 정해지고 회의에서 결과가 다뤄지기 때문에 세 번째 이유로 언급하였습니다.

그럼 마지막으로.

대체 언제? 어떻게? 얼마나 길게? 자주? 회의를 해야할까요?

이 문제는 어떤 스타일이냐에 따라 개개인마다 그리고 팀마다 다르겠지만.

개인적으로는 주 1회 (2시간 동안)이 마지노선이라 생각합니다.

만약 일주일 동안 진척된 내용이 많지 않아서 회의할 내용이 마땅히 없더라도

위 이유중 1, 2번의 이유에 근거하여 회의를 진행할 필요가 있다고 보고 있습니다.

한줄 요약.

 - 정기적으로 회의를 진행해서 서로 무언가를 하고있고 진척되고 있어! 라는 걸 확인합시다.

2. ㅁㅁ를 유도하라.

일반적으로 팀 프로젝트는 서로 얼굴을 알고 있는 사람들끼리 진행 되는 경우.

오프라인으로 프로젝트가 진행되어, 서로 가까운 자리에서 진행되는 작업이

매우 능률이 좋고 작업 속도가 온라인에 비해 잘나오는게 사실입니다.

그런데...위와 같은 경우는 회사를 제외하고선 한 자리에 모여서 진행하기 어렵다는게 안타까운 현실입니다.

마땅한 사무실이나 작업실이 있지 않는 한, 공동 작업을 펼치기 어렵기 때문이조.

해서 결과적으로 "조별과제" 라고 하는 패러디 같은 것이 우르르 나오고

한 명이 개고생을 한다? 라는 상황들이 자주 연출되거나 팀 프로젝트가 파토나는 경우가 허다합니다.

그럼 팀 프로젝트는 무조건 오프라인으로 진행해야 되는가?

만약 그럴 수 있다면 정말 좋지만!! 현실이 그렇게 허락하지 않으니 문제입니다.

그리고 한 자리에서 같이 작업하는 것을 기피하는 사람들도 있을 수 있습니다.

(저 또한, 개인적으로 혼자 작업하는 것을 좋아하는 스타일)

이런 작업 스타일은 서로 존중해줘야 하며 그렇지 않는다면 

팀 프로젝트에 참여하고자 하는 동기가 깨질 수 있습니다.

만약 여러분이 

"온라인/오프라인 진행이 그럼 무슨 상관이냐. 그냥 팀 프로젝트 잘 진행하기만 하면 되지."

라고 결과만을 쫓아간다면, 

팀 프로젝트가 파토나거나 자신이 버스기사로 운전을 하고 있는 경험을 하게 될 것 입니다.

사실 위 생각대로 온라인/오프라인 진행은 중요하지 않습니다. 네. 그럼 왜 적었는가?

온라인/오프라인 작업이란 것은 이 글을 보시는 분들께 키워드를 던지기 위함입니다.

여기서 중요한 점은 온라인으로 작업을 같이하건, 오프라인으로 같이 작업을 하건.

중간 단계의 결과물을 도출하고 참여를 유도하라. 입니다.

사실 팀 프로젝트가 파토가 나는 경우의 절반은 팀원의 참여 부재로 인해 발생하는 사례가 많습니다. 글쓴이 본인도 많이 겪었고 글쓴이 본인도 그렇게 행동했던 적이 있어서 많이 반성하고 있습니다.

그럼..어떻게 참여를 유도할까요?

중요한 점은 내가 팀 프로젝트에 기여하고 있다 -> 참여에 따른 뿌듯함을 느낀다.

라는 것을 만들어야 합니다.

예를 들어서, 개발자들끼리 팀 프로젝트를 진행 할 때.

나의 코드가 다른 사람에게 어떤 기능을 제공해주거나 다른 사람이 내 코드를 통해 어떤 편리함을 제공 받았다면, 내 작업물이 도움이 되는지 피드백을 받는 것도 좋은 방법 입니다.

그러나 꼭 같은 분야의 사람끼리 팀 프로젝트를 진행하란 법은 없지요.

그럼 다른 파트의 사람들끼리 있을 땐 어떻게 해야 하는가?

가장 좋은 방법은 내가 당신을 통해 일하고 있어요~ 라는 점을 보여지게 하면 됩니다.

가령, 프로그래머 ↔ 디자이너 관계에서

디자이너가 캐릭터를 그리면 그것을 움직이게 만들어 주는 것이 개발자의 몫 입니다.

캐릭터가 만약 움직이게 된다면 디자이너는 자신이 그린 캐릭터가 움직이는 데에서 뿌듯함을 느낄 것이고, 프로그래머 또한 거기서 뿌듯함을 느끼겠지요.

이처럼 팀 프로젝트의 중간 개발단계의 결과물들을 통한 기여에 따른 결과에 대한 성취감을 얻는 것이 중요합니다.

그러나...말처럼 이런 경우가 쉽게 나오지 않는 예도 있습니다.

글쓴이 본인이 겪었던 한 예를 들어보겠습니다.

두 프로그래머 친구가 같이 팀 프로젝트로 게임을 하나 개발하기로 했습니다.

여러가지 내용을 개발하던 중..

A 친구가 플레이어를 만들고 싶다고 했습니다.

그러나 B 친구도 플레이어를 만들고 싶었습니다.

그래서 두 친구는 서로 플레이어의 개발 내용을 서로 나누기로 결정합니다.

A친구가 플레이어의 스테이트를 만들기로 하고

B친구가 플레이어의 액션과 인벤토리를 만들기로 결정했습니다.

A, B 두 친구가 만든 플레이어는 어떻게 됐을까요?

개판입니다. 

말 그대로 개판이에요. 난리가 아닙니다. 

플레이어 캐릭터에서 어떤 버그가 발생해서 B친구에게 고쳐달라고 했더니 이건 A 친구가 만든 거라 내가 못건들어. 라고합니다.

.....(뭐 어쩌라고...)

솔직히 어떤 거대한 프로젝트라면 큰 틀에서 내용을 나눠 역할에 따라 분담하는 것이 맞지만 너무 디테일하게 들어가서 어떤 역할과 의미를 가진 객체를 쪼개버리면 추후에 위와 같은 문제가 발생 하는 경우가 있습니다.

이런 경우 팀 프로젝트의 진행 자체에 자원적으로 많은 영향을 끼치게 됩니다.

(시간, 돈, 기분, 관계 등등...)

위 내용에 대해서는 추후 기회가 된다면 다시 언급하도록 하고...

다시 본론으로 돌아오겠습니다.

제가 위 사례에서 말하고 싶은 것은. 성취감을 얻을 수 있는 항목을 너무 분할하지 말아 달라는 뜻 입니다.

팀 프로젝트의 참여를 유도하기 위해 서로의 피드백이나 결과를 통해 기여에 따른 성취도를 얻는 것은 중요하다 말했습니다. 그러나 위 사례처럼 그 성취감을 얻을 수 있는 내용을 다른 사람과 나눠 버리게 되면 그 만큼 참여를 유도할 수 있는 능률 자체도 나뉘게 된다는 뜻 입니다.

그렇다고해서 나누지 말라는 뜻은 아닙니다.

어떤 거대한 프로젝트나 많은 기능을 가진 객체를 분담하여 개발하는 것은 좋은 방법이조.

다만, 프로젝트 스케일이 어떤가에 따라서 팀 프로젝트 참여를 유도함에 악영향을 끼칠 수 있다는 뜻 입니다.

마지막으로 정리하자면,

팀 프로젝트를 진행 할 때는 자신이 어떤 것을 맡고 있고,

맡은 분야에서 성취감을 얻을 수 있는지를 확인하시는 게 중요합니다.

(성취감을 얻을 수 있다? 라는 걸 매번 미리 알 순 없겠지만, 그것을 얻을 수 있을거야~ 라는 기대를 갖는 것 만으로도 충분합니다)

한줄 요약.

 - 팀 프로젝트에 자신이 기여하고 있고 성취감을 얻기 위해 지속적으로 참여하도록 유도하라.

많은 분들이 팀 프로젝트를 진행하다가 좌절하거나 파토나는 경험을 많이 하실텐데요.

글쓴이 본인도 수 많은 팀 프로젝트 경험을 쌓은 것은 아니지만

여러 프로젝트를 진행하며 겪었던 경험을 바탕으로

이런 관점으로 팀 프로젝트를 진행하는 것은 어떤가? 라는 제시를 하고자 적어보게 되었습니다.

먼저 어떻게 팀 프로젝트를 진행해야 하는가 고민하기 전에!

자신의 팀 프로젝트가 어떤 속성을 갖고 있는지 먼저 파악해야합니다.

프로젝트의 목적 및 동기와 의도에 따라 팀 프로젝트를 진행하는 방향과 방식이 매우 달라집니다.

위의 3가지(목적/동기/의도) 항목에 따라 팀 프로젝트의 성향을 분류해보면 다음과 같은 요소들이 팀 프로젝트의 성향 및 방향을 결정하게 됩니다.

1. 상업적 / 비상업적

2. 온라인 작업 / 오프라인 작업

3. 정기적인 회의 여부

4. 개발 기간의 제한

5. 리더의 존재 여부

위 5가지 내용이 팀 프로젝트의 성향과 방향을 구분 짓는 주 요인입니다.

그 외 다양한 요인으로 인해 팀 프로젝트의 성향에 영향을 끼칠 수 있으나, 개인적으로 위 내용이 지대한 영향을 끼치는 항목들이라 생각하고, 아마 다들 같은 생각을 하시리라 믿습니다.

그럼 팀 프로젝트를 어떻게 진행해야하는가? 를 살펴보겠습니다.

1. ㅁㅁ을 확인하자.

팀 프로젝트를 진행함에 있어서 상업적인가 비상업적인가 하는 목적이 팀 프로젝트에서 가장 우선시 되는 중요한 요인입니다.

딱히 위 말의 의도가 비상업적인 것은 뭐가 다르나? 라는 뜻은 절대 아닙니다.

그저, 상업적인 목적의 프로젝트는 팀 프로젝트 참여도에 많은 영향을 끼치기 때문에 이 글에서 우선순위가 높게 잡혀있습니다.

이미 여러분은 일상에서 "조별과제" 라는 키워드의 패러디가 많이 나와있던 것을 많이 보셨을텐데요. 이 문제는 직·간접적으로 금전적인 것에 문제와 연관됩니다.

만약 어떤 금전적인 이익이 있거나 금전적인 것을 목표로 한다면

참여도와 개개인의 책임감이 높은것이 사실이고, 반대의 경우 참여도와 책임감을 고양시키기 어려운 게 현실입니다.

상업적인 프로젝트는 금전을 통해 프로젝트를 활발히 참여 시킬 수 있지만

비상업적인 프로젝트는 대체 어떻게 해야할까요?

원초적으로 상업적이고 금전적인 목표가 아니기 때문에 해결할 방안이 없을까요?

이 질문에 대한 답을 먼저 해드리자면

해결 방안이 없는 것은 아닙니다.

그럼 어떻게??

한번 사고를 전환해서 생각해보겠습니다.

비상업적인 팀 프로젝트의 경우. 그 목적이 상업화가 아닌 다른데에 있다는 것을 주안점으로 둬야합니다.

예를 들면, 난 이 프로젝트를 포트폴리오로 쓰겠어! 라든가.

난 이 프로젝트를 진행하면서 여러 사람들과 사귀고 싶어! 라든지..

금전적인 것이 아니더라도 다른 목표는 많이 나올 수 있습니다.

그리고 이 목표는 개개인마다 다를 수 있지요.

결과적으로 이 말에 대한 의미를 풀어보면 

1. 상업적 / 비상업적 -> 내가 얻을 수 있는 보상은 무엇인가?

라는 문제로 직결됩니다.

이 보상이라는 부분이 나의 목표와 부합하고 만족스러운 결과를 낼 수 있다면

참여도와 책임감을 올릴 수 있고, 그렇지 않다면 좋은 결과를 내기 어렵습니다.

따라서, 먼저 팀 프로젝트를 진행하기전에 

개개인이 원하는 보상을 팀 프로젝트를 통해 얻을 수 있는지를 먼저 확실히 확인해야 합니다.

반대로 팀 프로젝트의 관리자 또는 리더의 입장이라면 팀원들에게 위 보상을 적절히 챙겨줄 수 있는지를 꼭 확인해야 합니다.

결과로 따라올 보상이 팀 프로젝트를 진행함에 있어 모두에게 적절하다면

그 프로젝트는 어떤식으로든 모두 보상을 위해 참여하게 될 것 입니다.

한 줄 요약. 

 - 팀 프로젝트에서 얻을 수 있는 보상을 확인하자.