wegra군이 남겨준 답글입니다.

—————————————————————

아마도 의사 소통과 정보 전달에는 별다른 문제는 없었을거야. 것보다는 다른 문제들이 있지 않을까..

적어도 내 경험상으론.. 학교 프로젝트에 열의를 가지고 달려드는 사람들은 거의 없었어. 그냥 어렵지 않게 대강 해서 내고 학점만 잘 받으면 되는 거지. 비전 제시에는 별다른 문제가 없었을거야. 다만 사람들이 그걸 이해만 할 뿐 공유하지는 않았을 뿐이지.

6명이나 되는 팀원 구성이라. 교수님께서 현실 파악을 못하고 있는 걸로 생각되는군. 모두다 기반 지식이 충분한 사람들도 아니고, 이제 막 배워가며 실습해보는 오합지졸(? – SE가 1~2년 공부한다고 익혀지는 것도 아니니..) 학부생 여섯 명 씩이나 모아놓고 몇 달 만에 프로젝트를 끝내라니.. 실현 불가능한 목표지. 매일 얼굴 맞대고 일하는 회사 팀들도 새로운 방법론 적용하는 걸 상당한 모험으로 꺼리는데 말야.

그리고 개발자 성향 분석 통계를 보면, 개발자들은 어떠한 일에 책임을 지는 것을 꺼려해. 그냥 자신이 맡은 일 간섭받지 않고 묵묵히 끝내길 좋아하지. 일이 정말 재밌고 의욕이 있다면 다들 알아서 뭉치겠지만, 어쩔 수 없이 해야하는 하나의 부담으로만 느끼는 상황이라면, 어떠한 문제가 발생했을 때 그에 대한 책임으로부터 회피하길 원하지. 지금은 민구가 책임자이므로 책임을 떠넘기기 최적의 처지에 놓인거지. ㅡㅡ;

그만큼 PL의 위치가 무거운거야. 비록 프로젝트가 제대로 흘러가지 않는다 해도 PL이 나약해지는 모습을 보이면 절대 안되. 우리가 같이 했던 프로젝트가 실패한 결정적 요인은 바로 PL이었던 내가 무너졌기 때문이었지. 민구 너는 어떠한 상황에서도 다른 팀원들 앞에선 푸념 섞인 말들과 짜증나고 자신 없는 표정을 지으면 안되. 전체적인 사기를 떨어뜨려 상황을 더욱 악화시킬 뿐이지.

나의 경우 지금 하는 프로젝트 중 하나는.. 초기에 프로젝트가 완전 무산될 위태로운 상황까지 몰고가면서까지 PL을 다른 친구에게 떠넘겼어. 내가 기획했고 내가 없이는 진행되기 힘들 프로젝트임에는 분명했지만 이런저런 이유(특히 시간적인)로 내가 중심을 잡아줄 수 없는 상황이었지. PL을 떠넘기는(?) 상황에서 가장 중요한 것은 그런 구성이 프로젝트 성공을 위한 더 낳은 방안이라는 것을 깨닫게 하는 것이었지. 내가 일을 진행하는 중간에 가끔 흔들리는 경향이 있기 때문에 안그래도 쉽지 않아 보이는 프로젝트에 커다란 걸림돌이 될 것이 눈에 보였었거든..

그리고 그 처방은 확실한 효과를 보고 있어. 비록 많은 시행착오를 거쳤고 일정도 제법 지연됐지만, 점차 제 방향을 잡아가고 있고, 무엇보다 프로젝트가 끊김 없이 앞으로 나아가고 있음이 보이거든..

너의 경우 일단 PL이란 짐을 짊어졌기 때문에 나처럼 할 수는 없는 상황인데. 그래도 지금 내 머리 속에 떠오르는 최고의 조언은 다른 사람을 찾으라는 거야.

책임을 떠넘길 사람이 아닌 함께 짊어질 동료를 찾아봐. 한 명만이라도 좋아. 아니, 한 명이 가장 좋아. 이것도 심라학적 근거가 있어. 명확히 자신이라 인식하지 않으면 회피하려는 경향이 아주 강하거든. 하지만 그 사람에게 공식적인 역할을 부여할 필요는 없어. 능동적인 사람을 한 명만 더 키워내면 상당한 변화가 있을거야. 너의 부담도 줄어들어 너 스스로도 더 재미있게 진행할 수도 있을거고.

적합한 사람이 있다해도, 무턱대고 “자네가 이런 역할 좀 해줘” 하며 짐을 전가하려는 인상을 주면 좀 곤란할 거 같고. 프로젝트에 대해 집중적으로 함께 고민해보면 어떨까 싶네. 팀을 이끌어 가는게 의욕만으론 안되거든. 프로젝트 진행 방향에 대해 너에 버금가는 비전을 공유해야 하지. 내가 나가고자 하는 방향과 PL인 자네가 나가고자 하는 방향이 같다는 걸 스스로 자신할 수 있어야해. 너의 프로젝트가 아닌 나의 프로젝트라 인식해야 한다는 거지. 모든 정책과 모든 지식이 PL로부터 나와주길 기대하게 해서는 안되. 많은 대화가 필요할거야. 같이 고민하고 많이 알게 될 수록 자연히 프로젝트에 대한 관심이 많아지고 관심이 많아지면 애착이 생길 수 있지.

여기서 하나 중요한 것은 프로젝트 목적이 단순히 A+만이어선 안될 거야. 그보다 훨씬 가치 있는 무언가를 얻어갈 수 있어야 하겠지. 이게 또 쉽지 않겠구나. 아쉽게도 어떤 것을 얻어갈 수 있을 지는 내가 알 수가 없네. SE 자체가 가져다주는 잇점이라던가 전망, 회사에 나가 또는 개인적인 성장에 어떠한 도움을 줄 지.. 나의 경우 그나마 평소 관심이 많았고 몸소 이것저것 해보며 자료도 축적하고 해서 이런 얘기 정도는 해줄 수 있는데.. 아니면 프로젝트에 적용하려는 기술적 특성, 그것을 익힘으로써 자신의 가치가 얼마나 올라갈 수 있는지 하는 얘기들도 할 수 있겠지.

만약 너가 생각해도 별 다른 매리트가 없는 프로젝트라면 다른 사람들에게 적극성을 유도하기란 꾀 힘든 일이 될거야. 다른 사람들이 공감할 수 있는 가치를 찾아봐. 터무니 없는 거라 생각되면 역효과가 나니깐 무리하지 말고.

객체지향 설계는 참 쉽지.. 각각의 모듈들에 역할을 할당한다. 그럼 알아서 그 역할을 수행하지. 그런데 역할지향 팀 구성은?? 음.. 재미난 주제거리가 될 거 같군… ^^

아참! 지금은 좀 늦었겠지만, 이런 것도 도움이 될 거야.. 프로젝트 시작 전에 각각의 팀원들이 프로젝트를 통해 무엇을 얻고자 하는지 스스로 생각해서 나눠보는 거지. 물론 진심된 목적을 적어야겠지. 모두가 공유할 수 있는 프로젝트 비전을 마련하기 위한 수단이기도 한데… 이렇게 해서, 그냥 무턱대고 시작하는 것보다 팀원들 각자가 프로젝트에 대해 한 번 쯤 더 생각해볼 기회가 생기고, 전체의 생각을 공유하면서 내가 생각지 못했던 다른 매력을 찾을 수도 있고, 내가 프로젝트를 망치므로써 다른 이들에게 어떤 상처를 주게 될 지도 간접적으로 느끼게 될 거야. 자연스런 책임감과 동기 유발책이지. ^^