대서특필의 시작

shinychan95·2020년 1월 15일
0
post-thumbnail

총 8주간의 대서사시의 막은 이미 열렸다고 생각했다.

시작과 동시에 치열한 일주일을 마치고, 이번 주는 힘이 조금은 빠진 상태였다. 총 4시간이라는 통근과 하루 종일 맴도는 긴장감은 발휘된 열정 이상의 체력을 앗아갔다. 하지만 오늘 PMP 문서에 대한 이사님과의 회의는 다시금 시작하도록 우리 팀을 만들었다. 그리고 이제서야 서버개발캠프동안 회사에 약속했던 대서특필 을 할 수 있을 것 같다.

이사님은 프로젝트에 대한 인생 경험같은 혜안을 주셨다.

잘 짜여진 계획은 작은 것에서 무너진다.

PMP

대명사인지는 모르겠지만 저번 주부터 두달 간 진행할 프로젝트 PMP(Project Management Plan)을 작성해야 했다. 주제에 대한 구체화도, 프로젝트 및 개인의 목표도, 기능 및 아키텍처도 여럿 준비할 것들이 산더미였다. 어쩌면 첫 구성과 다르게 쪼개진 두 팀이 만나 효율적으로 정한 빅데이터 처리 기반 실시간 서비스 개발이라는 주제는 우리에게 낯설었고, 그만큼 자료 조사와 깊은 이해 및 설계를 하도록 만들었다.

거대하고 멋져보이는 주제에 우리는 이끌려 다녔다.

결국, 우리의 PMP에는 Management에 대한 제대로 된 견해도 없었으며, 개인적 욕심도 묻어나오지 않았으며 그저 빛 좋은 개살구 느낌이었다. 빛이라도 좋으면 다행이지, 인간미도 없고 사실상 완성도도 없었기에 참 지루한 PMP라는 지적을 받기 딱이었다.

프로젝트 그 자체

프로젝트를 할 때마다 보통 팀장을 맡아왔었다. 그만큼 내가 하면 원활하다고, 열정적으로 팀을 잘 이끌어갈 수 있다고 생각했다. 하지만, 이번엔 아니 지금까지 그래온 것이 아니란 생각이 들게 되었다.

내가 이끌어 왔던 팀은 결국 빛 좋은 개살구를 만들었다. 더욱이 창피한 것은 PMP를 만들고 나서 어느 정도는 만족했다는 사실이다. 디자인 때문인지, 내용이 깔끔했던 것인지, 자료 조사를 통해 나름 주제에 대해 이해를 해서 인지는 몰라도, 스스로 이정도면 되겠지 이제 개인 프로젝트를 해야지라고 생각을 했었다. 정말 충격적이다.

지난 시간동안 우리는 열심히 준비했다. 준비하는 과정에서 대화도 자료 조사도 합의도 다양하게 이루어졌다. 하지만 중요한 것은 우리는 그저 합의한 것이지 정말로 필요한 충돌도 욕심도 없었다. 결국 각자의 이야기를 담을 수가 없었던 것이다. 물론 필요하지 않은 일들을 해온 것은 아니다.

조금 방향과 시작을 잘못 잡아왔던 것 같다. 어쩌면 지난 프로젝트 진행의 관습이 방해가 되었던 것이다.

서버개발캠프는 회사에서 진행되는 프로젝트지만, 누구의 명령도 어떤 이익도 따라가지 않는 프로젝트이다. 그렇기에 개인이 모인 팀을 빌딩하는 과정에서 무엇보다도 우리는 개인의 욕심을 반영해야 했다. 개인이 진정으로 하고 싶고 이 기회를 통해 얻고 싶은 것을 주장하며 우리는 충돌해야 했다. 하지만 우리는 마치 누군가의 밑에서 일하는 사람처럼, 누가 주제를 준 것처럼 생각보다 간단하게 주제를 정해버렸다.

결국 우리 중 누군가는 자신의 의견을 스스로 묵살했을 것이며, 설상가상으로 의견을 내지 못하는 분위기로서 프로젝트가 진행되고 있던 것이다.

어쩌면 두 가지 방향의 프로젝트의 시작이 있다는 것을 깨달았다. 첫째는 주어진 목표 및 목적에 따라서 방향을 잃지 않고 프로젝트를 행하는 것이고, 둘째는 팀을 구성하여 주제를 정하는 과정부터 개개인이 목표와 목적부터 의견을 내세우며 이를 논의하고 정리하는 것이다. 둘은 어쩌면 같은 개념일지도 모르겠지만, 후자를 몸소 느낄 수 있었던 것은 나에게 뜻깊은 경험으로 다가 왔다.

우리의 시작

기획안과 PMP는 조금 다르다. 아니 사실 완전히 다르다고 해도 무방하다.

우리는 기획안을 만들었던 것이다. 물론 기획적으로도 완벽하지 않았다. PMP는 말그대로 Management 측면에서 구체적으로 정의해야 하는 것이다. 일정 계획 및 마일 스톤은 기본적인 것이고, 중요한 것은 발생하는 리스크와 페인 포인트를 정의하고 이를 어떻게 관리할 것인지 명시해야 하는 것 이다.

리스크와 페인 포인트는 다양한 원인에 의해서 생성되는데, 이번 프로젝트는 첫 단계인 팀 빌딩, 즉 개개인의 개발적 욕심과 목표가 충돌하는 과정과 합의를 이루는 과정들에서부터 생성된다. 우리는 그에 대한 충돌이 하나도 없었다. 어쩌면 이미 다 합의된 것처럼 하나도 언급하지 않았지만, 우리는 주제라는 명령 아래에 개인을 숨기고 있었던 것이다. 접근을 할 때부터 조금 방향이 틀렸다는 생각을 했다.

하나의 프로젝트가 각자에게 하나의 프로젝트 같은 느낌을 준다는 것이 무슨 말인지 이해할 수 있었다.

구체적인 피드백

  • 프론트엔드 개발에 있어서 목표점이 없다. 그저 clone 개발은 단단히 잘못되었다. 사용자들에게 편리한 UI & UX에 대한 감각이 목적이라면 더욱이 clone은 위험하다.
  • 본인들의 진짜 이야기, 개개인의 욕심 및 목표가 담겨 있지 않다. 어떻게 합의된 줄은 모르겠지만, 합의된 주제에 관한 그저 단순히 잘 짜여진 기획안이다.
  • 관리 측면에서 다양한 것들이 관리가 되어야 하는데, 그 부분에 있어서 구체적으로 정의된 내용이 한 가지도 없다.
  • 결국 프로젝트라는 것이 팀 빌딩으로 시작되어서, 빌딩이 되어 합의된 주제에 대해서 아키텍처가 연결되야 하는 것인데 그렇지 않다.
  • 우리가 충돌을 통해 합의한 주제에 대해 가장 큰 리스크가 무엇인지 그것들을 어떻게 관리하고, 그 방법론으로 어떤 것을 사용해볼지에 대한 내용이 없다. 지식이 부족하여 충분한 공부가 필요한 것이 위험이라면 이를 관리하기위한 적절한 관리 방법이 필요할 것이다.
  • 마일 스톤을 정했으면, 마일 스톤을 방해하는 요소에 대한 관리가 어떻게 이루어질지 명시해야 한다.
  • 결국, 최하단인 본질 속에는 개개인의 욕심과 목표가 남아 있는 것이다. 프로젝트가 진행되면서 충족되어야 할 본질적인 것들이며, 이를 위해서 관리가 필요하다.
  • 주제에 대한 경험이 모두가 없다면 많은 자료 조사를 통해 발생할 수 있는 문제에 대한 시나리오를 수십가지 구성하여, 이를 해결하고 공유하는 방식도 좋을 것이다.
  • 팀 빌딩이란 개개인의 욕심과 목표가 충돌하여 합의를 이루는 과정이라고 말할 수도 있지만, 어쩌면 결론적으로는 어떤 상황에서도 기여할 수 있는 한명 분의 commitment가 정의되는 과정이다.
  • 즉, 팀 빌딩이 제대로 이루어지면 몰입을 할 수가 있다.
  • 물론 PMP에는 모든 합의가 이루어진 최종 결과물 만이 보여지는 것이다.
profile
개발자로 일하는 김찬영입니다.

0개의 댓글