✅ 프로젝트 명
OffStory
✅ 팀원
🧑 조주영
👩 김지영
🧑 김영후
✅ 기술 스택
-. Vue
-. Figma
-. git, github
-. notion
✅ 기간
2021.10.15 ~ 2021.11.03
✅ 역할
(1) Header 개발
(2) 좋아요한 페이지 개발
(3) 개인 정보 수정 페이지 개발
✅ 끝맺음
팀원 모두 팀 프로젝트가 처음이고, 기간도 매우 짧아서, 프로젝트 진행 중 매 순간의 선택과 결정이 '프로젝트 완성 여부'에 크게 의존적이었음. 그렇기 때문에 문제 해결 과정의 경험보다는, 아쉽지만 과정에 대한 피드백만 많이 남겨 놓게 되었음.
✅ 반추
1____ 리더에 대한 아쉬움
어쩌면 제대로된 팀 프로젝트의 시작은 '리더'와 '팀원'을 명백하게 구분하는 것에서부터 시작되지 않나 싶다.
(팀장이 아닌 리더라는 단어를 쓴 이유는, 리더라는 단어가 더 무게감이 있다고 생각했다. 팀장이라는 단어는 '팀'이라는 단어와 함께 '구성원'의 '장'이라는 의미가 짙어서, '리더'에 비해 상대적으로 온화한 점이 있긴 하지만, 대학교를 졸업한 많은 사람들이 팀장 자리를 귀찮고, 안좋은 자리로만 인식한다는 점을 생각해 본다면, '의무'와 '책임'이 명확하게 주어지는 '회사'에 들어가기 전까지는, 팀장이라는 단어보다는 리더라는 단어를 쓰는게 낫지 않나 싶다)
이번에 팀 프로젝트를 하면서, 팀장을 뽑지 않았다. 로테이션으로 하자고 합의하였지만, 사실상 없는 수준이었다.
이런 상황에서, 프로젝트에서 내가 적지 않게 시간을 투자한 부분은, 프로젝트 진행 방향 설정이었다. 프로젝트 모임이 있는 날이면, 모였을 때 '우리 뭐해야 하죠?'라는 말이 듣기 싫어서, 항상 '개인적인 의견'으로 포장해 프로젝트 방향을 제시하곤 했다. 그리고 팀원들은 별말 없이 따라주었다.
이 과정에서 아쉬웠던 점은, 노선을 벗어나는 행위 혹은 코딩 스타일에 대해서까지 나서서 말을 꺼내고, 리딩을 해주고 싶었는데, '리더'라는 명확한 책임과 포지션이 없어서, 결정 사항이 발생했을 때 '그럼 어떻게 할까요?' 라는 질문과 함께, 누구의 결정에 힘이 실리기보단 서로 양보하는 듯한 스탠스로, 굉장히 불명확한 타협점을 정했다는 점이다. 그리고 이러한 결정들은 쌓이고 쌓여서, 프로젝트가 전체적으로 일관되지 못해 보이게 만들었던 것 같다.
유튜버 포프TV가 해준 말이 공감이 되어 가져와 봤다.
프로젝트 관리를 어떻게 잘 하느냐에 대한 답을 사람들이 엉뚱한 곳에서 찾으려고 한다. 이러이러한 방법을 도입하자, 이러이러하게 프로젝트를 진행하자 등...
결국 프로젝트 관리를 잘하는 방법은 딱 두가지다.
첫 번째는 리드가 좋아야 한다.
프로젝트는 누군가가 끌고가고, 관리하고, 통일성있게 방향을 잡아주어야 한다. 그리고 팀원이 질문했을 때 가는 방향을 햇갈리지 않게, 일관적으로 말해주어야 한다.
그리고 리더는 업무를 봤을때 소요되는 시간과, 누구에게 맡겨야할지, 뭐가 더 중요하고 덜 중요한지 등의 우선순위, 그리고 각 팀원의 장단점 등 모든것을 수치화하는 능력이 필요하다.
2____ 잘하는 사람 VS 열심히 하는 사람
프로젝트를 시작하기 훨씬 이전부터 팀원에 대한 고민이 조금 있었다. 당시에는 못하는 팀원보다는 잘하는 팀원이 있으면 든든하겠다 라는 생각이 있었지만, 지금은 바뀌었다. 잘하는 사람이든, 못하는 사람이든 별로 중요하지 않다. 중요한건 열심히 하는 사람인가?다. (열심히 하는데 방향이 맞냐도 중요하지만...)
예전에 아는 형님에서 박진영이 김영철을 본인 소속사에 영입하고 싶다고 했었는데, 그 이유가 다음과 같았다.
"나는 김영철을 영입하겠다. 영철이 자체가 수익을 낸다기 보다 회사 문화가 연예인들이 공부하는 문화다"
기사 내용이 조금 이상하게 적혀져 있는데, 기억나는대로 포장을 하면,
"연예인들도 공부를 해야한다. 그런 점에서 지금까지도 꾸준히 공부하는 영철이의 모습은 회사에 공부에 대한 분위기를 형성하는데 일조할 수 있으리라 생각된다"
비슷한 맥락이라고 생각한다.
프로젝트를 하면서, 나의 수준과는 별개로, 나의 부족함과 뛰어남에 대한 이야이와는 별개로, 팀원분들이 정말 잘한다는 느낌은 못 받았지만, 노력을 한다는 느낌을 많이 받았고, 그렇기 때문에 다들 으쌰으쌰 하는 분위기 속에서 프로젝트를 끝낼 수 있었던 것 같다.
3____ 기획과 관련하여,
위에서 말한 것 처럼 프로젝트 진행 방향에 있어서 본인의 의견이 많이 반영되었다. 그리고 본 목차에 적힌 내용들은 기획과 관련한 아쉬운 점들을 나열했다. 대부분 본인이 설정한 방향들이었는데, (리더는 아니지만) 조금 더 나은 방향을 설정하지 못했다는 점에서 팀원들에게 미안하다.
(1) SRS 문서를 어떻게 하면 효율적으로 작성할 수 있을까?
PPT는 페이지별 기능이 한 눈에 안들어와서 좋지 못했다.
(2) 와이어 프레임 제작 접근에 대한 아쉬움
와이어 프레임 작성에 대한 접근 방법이 조금 아쉬웠음. 개개인이 피그마에 대한 사용법을 배움과 동시에 디자인에 대한 고민을 할 수 있으므로, 각자가 맡은 페이지에 대해 각자만의 스타일로 작성해 오자. 라는 접근 방법이, 나뿐만 아니라, 다른 사람이 봤을 때 페이지의 전체적인 통일성이 떨어진다고 느껴졌음. 피그마 진입 장벽이 그렇게 높지도 않았던 점을 생각한다면, 다 같이 모여서 그렸어도 좋지 않았을까? 라는 아쉬움이 듬.
(3) usecase와 페이지별 이름 정의의 중요성
초반에 usecase에 대해 논의하지 않고, 페이지별 이름을 정의하지 않아서, 소통할 당시에는 서로가 모두 동일한 생각을 하는 듯 했으나, 실제로는 개개인이 생각하는 페이지와 기능적인 흐름이 전부 달랐다. 그 결과 했던 말을 반복하거나, 오해를 바로잡는 비효율적인 리소스가 많이 소비되게 되었다.
(1)과 (3)에 조금이나마 답이 될 수 있는 방법을 '달리는 모각코'팀 프로젝트에서 찾을 수 있었다. 아래와 같이 테이블을 만든다면 좀 더 가독성 있게 페이지를 구성할 수 있을 것 같다.
(4) API 명세서 검토
API 명세에 대한 검토를 빈약하게 했던 탓에, 프로젝트를 시작하고나서 SRS를 뒤집어야하는 상황이 발생했었다. 지금이야 강사님께 요청드리면 수정해주시지만, 정말 중요한 부분을 놓치지 않았나 싶다.
(5) 페이지 개발의 우선순위
어떤 페이지를, 어떠한 우선순위에 의해서 개발할 것이냐에 대한 논의가 있었다. 초기에 본인은, 유저가 많이 사용하는, 유저에게 많이 보여지는 페이지인 1.메인페이지, 2.글 상세 페이지, 3.개인 활동 페이지를 먼저 개발하자고 제안했다.
하지만 이는 잘못된 판단이었다. 위에서 말한 페이지들은 데이터를 불러와서 렌더링해주는 페이지에 불과하고, 그 전에 데이터를 서버에 저장하는 과정을 먼저 구현했어야 했다. 그러므로 1.헤더, 2.사이드바, 3.회원가입, 4.글쓰기 페이지, 5.개인정보 수정 페이지 순으로 구현했어야 했다.
