개발관련 - 팀프로젝트 / 졸업 팀과제 조언

개발자 방에서 대학 팀 졸업과제 / 팀프로젝트 때문에 고통받고 있으신 분들을 위해 조언을 좀 해드릴까 합니다.

​

참고로 저도 졸업과제로 팀 프로젝트를 했었고 팀장을 맡았으며 조원과도 갈등이 있었으며 몇번이고 프로젝트가 터질뻔한 위험이 있었습니다. 하지만 이것들을 어떻게 해결했는 직접 경험하고 결국 최종적으로는 프로젝트를 완성해서 배포까지 완료 시켰었습니다.

​

첫주차가 핵심이다

 

대학생 분들이나 팀프로젝트를 처음 접하시는 분들이 많이 하시는 착각이 회의는 짧게하고 그냥 바로 구현부로 넘어가서 빠르게 개발하는게 좋다 라고 생각하신다는 겁니다.

​

하지만 이렇게 막무가내로 개발을 진행하면... 프로젝트가 너무나도 쉽게 터져버립니다.

​

팀프로젝트는 개인이 아닌 팀단위로 움직이는 프로젝트입니다. 또한 그 기간은 적게는 3개월 이내 혹은 그 이상이 될수 있죠.

​

하나의 프로젝트를 이렇게 길게 개발해보는 경험은 대부분 처음 겪는 상황이라는 겁니다.

때문에 처음에는 다들 열심히 해보자 으쌰으쌰 거려도 몇주만 지나면 그게 다식는 다는겁니다.. 그것 때문에 서로 감정상하고 일정 못맞춰서 프로젝트가 터지고 하는거죠..

​

이런 문제를 사전에 방지하기 위해서 첫주간 털어내기 작업을 미리 하는겁니다.

​

다음은 첫주차때 해야하는 목록입니다.

 

팀장을 정해라

 

가장 먼저 해야할건 당연히 팀장을 정하는겁니다.

팀장을 누가 맡느냐에 따라 그 프로젝트의 방향성이 결정됩니다.

역량이 좋은 사람이 팀장을 맡는다면 그 프로젝트가 터지지 않고 성공할 확률은 더더욱 높아지죠

​

그럼 누가 팀장을 맡느냐?

​

먼저 알아두셔야 할게 나는 외향형이니 내가 팀장을 맡을게!! 내가 팀원들과 잘 지낼수 있어 내가 주도할게! 이런 시기는 지나갔다는걸 아셔야합니다.

팀프로젝트는 모험을 떠나는것과 같습니다. 능력이 없고 의욕만 앞서는 사람이 리더를 맡아버리면.. 그 모험을 같이 떠난 팀원들은 개고생을 하겠죠?

때문에 팀장이 되기위해선 다음과 같은 조건을 갖추어야 한다고 생각합니다.

​

팀장이 되기 위한 조건

​

1. 그 분야에 대해 가장 잘 알고있는 사람이 팀장이 되어야 한다.

• 정말 기초중에 기초입니다. 팀장을 선출할때는 해당 분야에 대해 가장 지식이 깊은사람을 뽑으셔야 합니다.

이유는 팀장은 팀 프로젝트의 전체적인 구조를 다 이해를 하고 있어야 하기 때문이죠.

설계, 일분배, 일정조율 등의 작업은 모두 팀장이 한다고 보시면 됩니다. 따라서 해당 지식이 가장 깊은 사람이 반드시 팀장이 되어야 합니다.

​

2. 냉정하고 과감한 사람이 팀장이 되어야한다.

• 많이들 공감하실겁니다. 진짜 팀프로젝트 터지거나 혼자 속앓이를 하시는 분 대부분이 냉정하지 못해서 인거 같아요.

팀프로젝트를 하다 팀이 너무 지나치게 비협조적이거나 자신을 따르지 않는다면 과감하게 배제해 버리십시요.

졸업과제라서 너무하다 뭐라고 말하면 어떻게 합니까? 라고 걱정하시는 분들이 계실건데. 아니요 절대 아니니까 걱정하지 마세요.

그 누구도 뭐라고 하지않습니다. 원래 목마른자가 우물을 파는거예요 졸업을 하고싶으면 팀에 기여를 해야죠 기여도 하지않고 개발을 하지않았는데 졸업과제 했다고 졸업을 시킨다는게 말이 안되는겁니다.

팀을 잘 이끌어 나가는게 팀장이 해야할 일이다 라고 뭐라고 하거나 감점 받으면 어떻게 합니까? 라고 하시는 분들도 있으시겠죠.

하지만 아닙니다 걱정하지마세요 과감하게 팀원을 내치는것도 팀장이 해야할 일입니다.

교수님이 뭐라고 말하시면 팀을내친 타당한 이유와 근거를 제시하면 넘어가십니다.

​

실제로 프로젝트 비용산정 기법이라는게 있습니다.

프로젝트 인원수, 소스라인수, 개발기간, 비용, 노력, 생산성 등을 이용해서 해당 프로젝트의 비용을 산출해 내는 방법이죠.

이를 토대로 근거를 제시하면 충분한 사유가 되십니다.

​

3. 팀원을 잘 케어해주는 사람이 팀장이 되어야한다.

• 두번째 경우는 정말 최악의 상황을 마주했을때 필요한 능력이라면 이것은 평소에 팀장이 가져야할 태도입니다.

항상 팀원 진척상황을 확인하면서 팀원이 어느 문제에 봉착했다면 같이 문제를 고민해주고 자료를 찾아서 전달해 줘야합니다.

이를 해주지 않는다면 팀원은 혼자서 문제를 끙끙거리다 의욕을 잃어버리게 될것이고 결국 생산성이 떨어지게 될것입니다.

모든걸 다해주라는것이 아닙니다 당연히 막힌부분은 팀원이 알아서 공부를 해서 풀어야할 과제고... 그저 어느정도 참고할 자료만 같이 찾아주는 정도만 해주시면 됩니다.

​

팀장한테 많은 권력을 쥐어줘라

 

첫주에 확실하게 팀장에게 권력을 쥐어주십시요

팀장한테 권력을 쥐어줘야지 과감하게 판단을 내릴수 있습니다.

팀장에게 쥐어주는 권력으로써는

​

1. 프로젝트 Git 마스터 권한을 팀장에게 주기

• 팀원들은 팀장의 초대로만 해당 프로젝트에 접근할수 있게 해주시면 됩니다

불협조적인 팀원은 계속 경고를 주다가 정 안되면 프로젝트 접근권한을 뺏어버려서 퇴출시켜버리면 되니까요

​

2. 결정권한 팀장에게 주기

• 당연한 것이기도 한데 이 결정권한을 제대로 안지키는 분들이 많으시는것 같습니다.

팀장이 ~일 ~몇시에 회의를 하겠다 하면 그날 회의를 하세요. 물론 꼭 대면으로 하라는게 아닙니다 카톡으로 할수도있고 여러 비대면 수단을 사용해서 회의를 진행하라는 거예요. 캠 안켜도 됩니다. 그저 회의에 참석을 하라는 소리죠.

정말 피치못할 사정으로 그날 전체 시간이 안된다 하면 팀원에게 대안책을 물어보고 일정 조율이 절대 안된다하면 그사람과는 따로 회의를 거치도록 하십시요.

물론 그마저도 안한다면 경고 누적후 퇴출을 시키시면 됩니다.

​

브레인 스토밍을 많이해라

 

팀원마다 만들어 보고 싶은 기능이 반드시 있을것입니다.

원하지도 않는 기능을 만들라고 하면 의욕이 사라지죠

우선 구현 가능한가의 여부를 떠나서 여러 아이디어를 수집하세요. 적어도 팀원당 5개이상의 기능을 받아내셔야 합니다.

아이디어를 다 수집하고 나시면 그때부터 이제 해당 아이디어를 토대로 주제를 정하고 구현 가능 여부를 결정하시면 됩니다.

​

그리고 역할 분배할때 그 의견을 낸 팀원한테 해당 기능 구현을 맡기시면 됩니다.

본인이 직접 낸 의견이니 당연히 더 열심히 하겠죠?

​

​

회의는 매주 해라

 

이렇게 첫주차가 끝났습니다.

역할분배도 어느정도 마무리가 되었고요. 그렇다면 팀장이 다음에 해야할 일은 뭘까요?

당연히 일정 관리겠죠?

회사에서 왜 주간회의를 할까요? 할짓이 없어서..?

전혀 아닙니다. 다 이유가 있어요 매주 진척도를 확인하고 해당 프로젝트가 일정내에 끝날수 있는지 계속 계산을 하는겁니다.

진척도가 느린 팀원은 따로 불러내서 무슨 문제가 있는지 알아보고 같이 문제를 해결해 나가는것이죠.

대면으로 하든 비대면으로 하든 상관없습니다. 그저 매주 진척상황과 남은 기능만 보고받고 관리하시면 됩니다.

​

​

일정에 못맞출거 같으면 우선순위 기능부터 완료해라

 

프로젝트를 하다보면 반드시 시간이 모자라 100% 완벽한 앱을 못만드는 경우가 많습니다.

현업에서도 이런 경우가 정말 자주 나옵니다.

그럼 어떻게 처리를 하냐?

우선순위 기능을 정하십시요.

일단 핵심 기능부터 일정내에 다 만드는 겁니다. 그외 자잘한 기능은 모두 다 빼버리십시요.

핵심 기능이 다 만들어 지고 추후에 시간이 남거나 하면 이제 별도로 작업을 진행하고...

그조차 안된다면 일단 배포를 하십시요.

배포 하고 끝이아닙니다. 저희에게는 "업데이트" 라는 수단이 남아있죠.

미완성된 기능은 추후 업데이트를 통해 지원하면 그만입니다.

​

테스트 기간은 길게 잡아라

 

초보 개발자들은 자기들이 만든 환경에서 일단 돌아가면 아! 되는구나 라고 하는 착각을 가지는 경우가 많습니다.

하지만 현실은 그렇지 않아요.

모든 사람들이 동일한 환경에서 해당 프로그램이 돌아가라는 법은 없습니다.

특히 모바일 관련 프로젝트라면 그 정도가 더 심합니다.

사람들마다 가지고 있는 핸드폰의 해상도, 기능이 다 차이가 있고. 누구 핸드폰 해상도에서는 동작을 안할수 있습니다.

때문에 테스트 기간은 최소 일주일은 잡아주시고 그 일주일 내내 테스트를 진행하시고 버그를 잡으셔야 합니다.

​

마무리

 

포스팅이 좀 많이 길어졌네요.

결론을 말씀드리면 이겁니다.

리더가 팀원을 잘 이끌어야 하고 과감하게 판단을 내려야 프로젝트가 성공확률이 올라간다는 겁니다.

또한 자신과 팀원의 역량을 잘 파악하세요...

정말 공부해서 구현이 가능할 내용인지... 아니면 터무니 없는 내용인지..

솔직하게 말해서 첫 프로젝트 잡는 사람들이 모여봤자 나오는 결과물은 허접한 결과물입니다. 절대 완벽한 프로젝트 결과물이 나올수가 없어요...

그렇기 때문에 프로젝트 결과물 보다 그 과정을 더 중요시 해야 한다는 겁니다.