팀 프로젝트 어떻게 진행해야할까? [2편]ㅁㅁ를 유도하라

2. ㅁㅁ를 유도하라.

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

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

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

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

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

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

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

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

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

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

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

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

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

만약 여러분이 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

개판입니다. 

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

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

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

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

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

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

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

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

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

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

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

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

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

마지막으로 정리하자면,

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

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

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

한줄 요약.

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