지금까지, 내가 안드로메다로 보내버린 소프트웨어 프로젝트는 많았다. 학부생의 입장에서, 체계화된 개발 프로세스 관리를 직접 경험하지 못했기 때문이라 생각하는데, 비슷한 문제를 겪는 다른 학생들도 많으리라 생각된다. 그래서, 내가 말아먹은것에 결정적인 공헌을 했던 요소들을 정리하고자 한다. 어려움을 겪는 다른 사람들에게도 도움이 된다면 좋겠고, 결정적으로는, 앞으로 내 자신의 프로젝트 성공률이 성장한다면 정말 좋겠다.

프로젝트를 안드로메다로 보내는 방법, 그 첫번째.
프로젝트 리더가 모든 일을 하려고 하면, 프로젝트가 망한다.

이 항목은 특히, 학생들에게서 흔히 볼 수 있는 모습이다. 그 이유는 3가지가 있는데, 첫째, 학교에서 내주는 프로젝트 과제는 무보수이기 때문이다. 그 동기가 (억지로라도 하게 되는) 월급이 아니다. 해당 프로젝트를 열심히 하지 않는다고 학교에서 짤리진 않을 뿐더러, 점수는 같은 팀에겐 같은 점수가 주어진다. 둘째, 그나마 코딩 좀 하는 사람이 팀장을 맡기 때문이다. 코딩과 개발 프로세스 관리는 당연히 다른 부분이지만, 학생들의 경험은 대체적으로 비슷하기 때문에, 해당 분야에 대한 경험이 좀 더 많은 사람이 팀장을 맡는다. 그 기준은 코딩 경험이 되기 마련이다. 셋째로, 최악의 경우인데, 가위바위보로 팀원이 정해졌을 경우. 게다가 처음보는 사람이 팀원일 경우이다. 누가 얼마만큼의 능력이 있는지도 모르고, 어느 분야가 그 사람의 도메인인지도 모른다. 거기에, 묻어가야겠다는 사람들이 섞여있으면 첩첩산중. 이런 경우들이면, 다음과 같은 일이 일어난다.

1. 팀장이 팀원A에게 작업을 할당한다.
2. 팀원A가 작업을 하다가, 코딩을 쪼끔 더 잘 하는 팀장에게 물어본다.
3. 팀장이 팀원A의 코드를 보면서 수정할 부분을 알려주다가,
4. 정신을 차려보니, 팀장이 직접 코드를 짜고 있다!!
5. 1번부터 4번까지 반복.

이런 프로젝트는 십중팔구 안드로메다로 간다. 특히, 이런 부분이 많을수록 망한다. “팀장이 팀원에게 작업을 할당한다”라는 과정에는, “팀장이 팀원에게 책임과 권한을 위임한다”는 내용이 포함되어 있다. 좋은 리더의 역할은, 방법을 알려주는 것이 아니다. 팀원의 역량을 파악하고, 그 팀원을 믿으며, 팀원이 해낼 수 있는 분량의 책임과 권한을 위임하는 것이다. 그렇지 않고, 위와 같은 일이 발생하게 되면, 해당 팀원은 프로젝트 진행시에 “기여했다”는 느낌을 얻지 못하게 된다. 아무리 커다란 프로젝트의 아무리 작은 부분이라도, “훗~ 이 부분은 내가 했지!!”란 황홀한 기분을 느낄 수 있는 기회를 제공해줘야 한다. 그렇지 않으면, 이 프로젝트에서 자신이 짐만 되는 것 같다고 생각하게 되고, 점점 소극적이 되며, 자신감이 없어지고, 더욱 실적이 떨어지는 악영향의 무한루프가 시작된다. 프로젝트는 결국 안드로메다로 간다.

즉, 안드로메다로 보내지 않으려면, 팀원에게 책임과 권한을 위임해야 한다. 객체의 책임을 다른 객체에 위임하는 Strategy 패턴과도 같다. 아무리, 능력이 부족한 팀원이더라도, 그 사람이 해낼 수 있는 작업이 반드시 존재한다. 그 팀원에게 적합한 작업을 찾아서 연결하는 것은 팀장의 몫이다. 일종의 Load Balancing이라고도 할 수 있다. 그러면, 해당 팀원이 그 이슈를 해결하기 위한 충분한 지식을 갖추지 못했을 경우는 어찌해야 하는가? 그 이슈를 해결하기 위한 떡밥을 던져줘야 한다. 어찌 되었든간에, “내가 해결했어!”라는 만족감을 제공해줘야 한다. 그래야, 팀원들이 계속 노를 젓고, 배가 앞으로 나아간다.

이 항목은, 프로젝트의 마감이 다가올수록 점점 더 지키기 어려워지는 부분이다. (나처럼) 성격이 급한 사람이 팀장이 되어버리면, 더더욱 지키기 어려운 항목이다. 하지만, 안드로메다로 보내지 않으려면, 이 항목을 반드시 기억해야 한다. 팀장은, 팀원에게 책임과 권한을 위임해야 한다. 그 권한을 다시 뺐는 것은 도와주는 것이 아니다. 한두번은 도움이라 느낄지 모르지만, 그 행위가 계속되면 해당 팀원은 의욕을 잃는다.

-- 이상한 나라의 종텐.