Naweke - 1차 프로젝트 전체 회고 - 1. 기획

첫 팀 프로젝트에 들뜨고 설레서 프로젝트 시작 전날 밤 잠을 이루지 못했었는데(그 때.. 많이, 푹 자뒀어야 했는데...)

금새 2주가 지나고 벌써 1차 프로젝트가 끝났다.

 

1차 프로젝트는 nike 웹사이트를 모티브로 프로젝트를 진행하게 되었고

4명의 프론트앤드, 나를 포함한 3명의 백앤드 팀원과 팀이 되었다.

그리고 어느덧 2주가 지나고 최종 배포를 마치고 나니, 타이슨이 남긴 명언 한 마디가 떠올랐다..

"Everyone has a plan 'till they get punched in the mouth."
"누구나 그럴싸한 계획을 가지고 있다. 처맞기 전까지는."
 - Michael Gerard Tyson

2주간의 짧은 프로젝트 동안의 나의 경험과 그 의미들을 내가 맡았던 역할을 중심으로 기록해보고자 한다.

 

1. 프로젝트 기획

"팀의 방향성을 다함께 정하고 정해진 방향대로 나아갈 수 있도록"

이번 프로젝트의 목표는 나이키 웹사이트를 모티브로 우리 팀만의 서비스를 만드는 것이었다.

'나이키 웹사이트를 있는 그대로 클론해보자', '나이키 쇼핑몰을 만드는데 상품 카테고리가 많으니 상품을 줄이자' 등등 많은 의견이 나왔지만 논의 내용이 수렴되지 않고 발산되는 느낌이 들었다. 곰곰히 생각해보니 "나이키 웹사이트"에 대해 팀원들 각자가 정의한 바가 모두 달라보였다. 그래서 팀원들에게 물었다.

"여러분에게 나이키 웹사이트는 한 마디로 정의하면 무엇인가요?"

"나이키 웹사이트가 존재하는 목적은 무엇일까요?"

두 가지 질문이 회의의 방향성을 잡아주기 시작했고 그 때 팀 프로젝트에서 나의 첫 번째 역할을 찾았다.

 

"팀의 방향성을 잡는데 중요한 질문을 내가 던지고, 논의된 내용을 한 방향으로 이끌어가는 역할을 내가 해보자"

이렇게 정리해보니 나이키 웹사이트는 크게 두 가지("나이키 브랜드의 브랜딩을 위한 웹사이트", "나이키 브랜드가 갖고 있는 상품 판매를 위한 웹사이트")로 정의되었다. 브랜딩과 판매라는 목적은 모호했고, 우리는 보다 명확하고 구체적인 방향으로 기획을 다르게 잡아보기로 했다.

약 2시간의 컨셉 회의동안 '요즘 중고거래가 유행이니까 나이키 상품 리셀 서비스를 해보자', '우리 모두 나이키 신발 하나씩은 갖고 있으니까 나이키 상품군들 중에서 신발만을 다뤄보자', '나이키 룩북을 만들어 제안하자' 등등 다양한 의견이 나왔지만

"운동을 좋아하는 MZ 세대 고객의 라이프 스타일에 맞는 편집숍" 이라는 컨셉에, 상품 카테고리는 최근 붐이 일고 있는 러닝과 축구 그리고 농구를 좋아하는 사람들을 위한 상품을 제안하기로 결정했다.

 

프로덕트 기획 회의를 마치고 주위를 둘러보니 다른 팀들은 프로덕트 제작에 착수하고 있었다.

팀내 분위기가 술렁였다.

'우리는 이제서야 겨우 프로덕트 컨셉 기획을 끝냈는데 다른 팀은 벌써 제작을 시작했다고?'

 

하지만 우리에겐 아직 프로덕트 기능 기획이 남아있었다.

짧은 프로젝트 기간이었기 때문에 늦게 시작한다는 것에 마음이 조급해졌지만

팀원 모두가 우리가 제작할 프로덕트의 내용을 사전에 최대한 구체적으로 협의하고 정해야

추후 작업 진행 중에 작업 내용을 재확인하는 등의 불필요한 소통과 작업 로스를 줄일 수 있다고 생각했다.

그래서 웹사이트 내의 카테고리와 옵션, 구현할 기능들을 사전에 최대한 구체적으로 빠르게 정했다.

 

또한 우리가 그동안 학습한 내용을 충분히 서비스에 녹여내는 경험을 하는 것도 이번 프로젝트의 주요 목적이었기 때문에

프로덕트의 존재 목적에 맞는 기능들을 나열하고 필수 기능과 추가 구현 기능으로 구분하여 공유했다.

 

0123

정말 허접한 화면설계서였지만... 이 간단한 파워포인트가 팀 프로젝트 생산성에 지대한 영향을 미쳤다고 생각한다.

 

그렇게 첫 기획에서 고생한 덕분이었을까. 그 이후로는 작업 속도에 탄력이 붙기 시작했다.

프론트는 레이아웃 기획과 기능 구현까지 물흐르듯 흘러갔고,

백앤드는 데이터 모델링에 많은 시간이 소요되었지만 이후 API를 구현하는 것도 빠른 속도로 진행되었다.

서로간의 합의가 이루어지지 않아서 불필요한 소통 때문에 작업 속도가 나지 않고,

팀원 간 서로 다른 이야기를 해서 힘들어하는 다른 팀들을 보면서

우리팀의 방식이 시작은 느릴 수 있지만 효율적이라는 것을 깨달았다.

(물론 서두에서 말했듯, 우리 팀의 계획은 당시에는 그럴싸했지만 예상 밖의 상황들이나 잘못된 기획도 있어 완전하지는 않았다.)

 

모두가 한 곳을 바라보고, 각자가 자신이 해야 할 역할을 명확히!

요약하자면,

나를 포함한 팀원 모두는 개발 프로젝트가 처음이었기 때문에,

프로덕트를 만들기 위해서 첫 회의때 어떤 이야기를 해야하고 무엇을 정해야 하는지에 대해 잘 알지 못했다.

이럴때 일수록 프로젝트의 목적을 명확히하고 그 목적 달성을 위해 수행해야하는 작업 내용을 구체적으로 정하는 것이

프로젝트 전반적으로 생산성을 높이는데 도움이 된다는 것을 알게 되었다.

 

추후에 알게된 내용이지만, 보통 웹 개발 프로젝트를 착수할 때 아래와 같이 팀에게 공유되는 여러 문서를 작성한다고 한다.

(참고 : 프로젝트에 참여할 때 알아야 할 것들)

1. 화면설계서 : 화면의 배치와 디자인이 담겨있는 문서

2. 요구사항 정의서 : 서비스 개발에 필요한 기능들을 정리한 문서

3. WBS(업무 분류 체계), UML 등등

 

저런 문서들처럼 상세하게 작성하지는 않았지만 간단하게나마 문서를 작성하여 팀 프로젝트에 활용했다는 것은 우리 팀이 잘한 것 같다.

다음 2차 프로젝트 때에는 보다 상세하게 화면설계서와 요구사항 정의서를 작성해서 작업을 진행하면 생산성을 보다 높여 프로젝트를 진행할 수 있겠다는 생각이 들었다.

 

...

글이 길어 몇 개의 글로 분할합니다.

...

 

[다음 글]

2. Naweke - 1차 프로젝트 전체 회고 - 2. DB Modeling

3. Naweke - 1차 프로젝트 전체 회고 - 3. API 제작 및 배포

4. Naweke - 1차 프로젝트 전체 회고 - 4. 회고