최근 4개월 간의 긴 여정의 프로젝트를 마치며

정말 오랜만에 블로그 글을 쓰는 것 같다.

이렇게 블로그 공백을 가진 적이 없었는데, 그 사이에 블로그를 들여다 볼 마음 여건도 없었을 뿐더러, 지금까지 한 것중 가장 무거운 정도의 프로젝트를 미친듯이 해왔으니, 몸과 마음이 여유가 없어 기술 블로그를 쓰는 여건은 물론, 이런 회고 글도 쓰기 어려웠던 것 같다.

그럼에도 4개월이라는 콴다 Q&A라는 장기간 프로젝트를 마무리 단계에 들어서면서, 이런 경험을 그냥 흘러 내보내기는 아쉬워서 한번 회고를 써보려고 한다.

진행하면서 정말 아쉬웠던 것들이 참 많았으니, 앞으로 내가 어떻게 하면 더 잘할 수 있을지 여기에 정리해본다.

예측 했던 것 보다 매우 컸던 프로젝트 사이즈

제일 처음 시작하기 전에는 이 프로젝트를 사이드 프로젝트 형식으로 진행해보려고 했었다. 그만큼 겉으로 보기에는 정말 작아보이는 서비스였고 후딱 하고 끝내버리려고 했었다.
그래서 이런것을 한다는 것을 팀 리더분들과 얘기를 했을때, '왜 굳이 사이드 형태로 하려고 하냐. 그냥 업무 태스크로 올려서 제대로 업무 리소스 받아서 진행해라' 라고 해주셨던게, 그래도 이 프로젝트를 제대로 진행하며 잘 끝낼 수 있었던 첫 발판이 아니였나 싶다. 만약 우리가 정말 사이드로 이 프로젝트를 접했다면, 갈수록 만만치 않은 사이즈를 보게 되면서, "아, 이거는 생각보다 큰데, 그냥 하지 말까?" 하고 아무 변화 없이 끝났을 수도 있겠다 싶다.

그렇게 제대로 업무 리소스를 할당 받은 후, 4월 초반부터 시작을 진행했고, 업무 사이즈가 크지 않다고 판단하며 제대로 된 PM 리소스를 받지도 못했다.
이 프로젝트를 위해 참여한 멤버는 겨우

• 백엔드 개발자
• 프론트엔드 개발자
• DA
• 디자이너
  네 명이 끝이었다.
  어떻게 보면 정말 주요할 수 있는 PM 역할의 부재로 인해 이 프로젝트가 업무 난이도가 급격히 달라질 수 있다는 것을 몸소 깨달을 수 있었던 것 같다.

 

원활하지 않았던 프로젝트 진행

PM 역할이 없으니, 큰 단위의 해야할 업무들은 우리끼리도 잘 논의해서 진행할 수 있었지만, 작고 세밀한 그 많은 태스크들은 하나하나 모두 챙길 수 없었다. 그리고 그 작고 세밀한 부분으로 인해 기획 변경, 수정에 늪에 빠지고 말았고, 그 과정에서 프로젝트 진행 속도가 점차 늦춰지는 현상을 맞이하고 말았다.

생각했던 것보다 신경써야 할 많은 유저 케이스가 있다는 것을 캐치하지 못했다.
왜 우리는 이런 케이스들을 하나하나 신경쓰지 못했을까.

큰 단위의 작업들을 진행하는데 급급하다보니, 프로젝트의 디테일한 부분들을 신경쓸 겨를이 없는 것은 당연했다.
그래서 PM이란 역할이 괜히 있는 것이 아니란 것을 알 수 있었다.

그럼에도 앞으로 이러한 문제를 맞닥뜨렸을 때 잘 하기 위해선

• 큰 단위 업무 사이즈만 보지말고, 작은 단위의 케이스를 많이 생각해보도록 한다.
• 작은 사이즈여도 프로젝트를 진행할때는 PM 리소스를 할당 받도록 한다. 부득이하게 받지 못한다는 가정을 내세우지 말자. 무조건 받아야 한다. 이렇게 말하는 이유는 위에 썼듯이 각 포지션인 사람들은 자기들이 해야할 일에 집중을 해야하기 때문에 비즈니스적인 디테일한 부분은 물리적으로 모두 챙길 수 없기 때문이다.
  만약 그럼에도 PM의 리소스가 없으면, 리소스가 생길때까지 그 프로젝트 진행을 잠시 미루던가 한다. 애매모호하게 진행해버리면 업무 진행 퍼포먼스는 물론 프로젝트 실패 확률이 더 많이 올라가게 된다. 정확히 할 수 있는 상황일때 제대로 하자.

 

초반에 프로젝트 진행을 리드하지 못함

처음에는 끌려다니며 진행하는 느낌이었다. 내 쪽에서 작업하는 것이 중심이 아니고, 컨텍스트를 전달 받고 내가 진행을 해야하는 입장이었기 때문이었던 것 같다.

만약 프로젝트 초반처럼 내가 컨텍스트를 전달받는 느낌이 아니라, 컨텍스트를 파악하고 리드를 하도록 하기 위해선.

• 전체적인 프로젝트 컨텍스트를 파악하자.
• 진행되는 전체적인 과정을 계속 파악해야한다.
• 다른 사람들에게 질문을 두려워하지 않는다.

 

리드에 대한 아쉬움

• 네이티브와 웹뷰 작업부터는 내가 작업하는 부분이 중심이 되다보니, 자연스레 내가 네이티브 분들이 리드하게 되는 감이 있었다. 그런데 내가 리드하는 과정에서 잘 했던 점과 아쉬웠던 점이 몇가지 있었던 점을 정리해 보려고 한다.

초반에 아쉬웠던 점
내가 네이티브 단에서 작업할 수 있는 환경이 준비되지 못해 초반 몇몇 데일리 싱크를 제대로 진행하지 못했던 점.
초반에 실제 배포환경에 띄우고, 화면 위에 보여지는 기본적인 부분부터 했었어야 했는데, 그러한 작업을 하지 못했었다.

앞으로는 작은 단위에서 배포환경까지 먼저 확인을 한 뒤, 앞으로의 태스크에 찬찬히 진행할 수 있도록 한다.

미팅 중 논의한 내용은 제대로 파악한 뒤 정확한 로그를 남긴다.
해당 로그를 통해 다시 한번 논의되지 않고 히스토리를 확인할 수 있도록 한다.

기획 변경에 따른 개발 수정의 용이성의 아쉬움

- 비즈니스 로직과 컴포넌트 사이에서의 로직 분리.
- 재활용되는 컴포넌트가 아니면 Props로 받는 것을 하지 말기.
- 항상 변경사항에 대한 용이성을 생각해서 컴포넌트를 구현하자.

 

너무 실제 서버 API를 통한네트워크 의존성 개발을 진행

이번에 개인적으로 너무 아쉽게 느껴졌고, 내 스스로가 변화되었으면 하는 개발 방식이다.

개바을 진행하는데 있어, 실제 API 요청을 통한 페이로드 데이터를 가지고 개발을 하다보니 서버가 잠깐 죽거나 네트워크가 되지 않으면 내 개발 진행에 영향을 미치게 된다. 더불어, 네트워크가 잘 되도 neverland(사내 프록시 통신을 가능하게 해주는 녀석)가 고장나면 정말 골치였다.

MSW라는 정말 멋진 Mockup 처리를 해주는 기능을 놔두고, 너무 API 네트워크에 의존을 하면서 개발을 해서 전체적인 개발 진행 속도에 영향을 주고 있었다. 

초반에 시간이 꽤 걸리더라도 mock data 환경을 잘 구축해놓자.

 

 

그리고 무엇보다 쉬운 길을 선택하기보다, 내가 하고 있는 일에 Lesson Learn을 가져가도록 노력하자.