[항해99] MIL D+92 (1주차)

뒤늦게 올리는 후기

실전 프로젝트 1주차(08/26 ~ 09/01)

협업 툴 정리

• 우선 협업을 위한 툴들의 기초를 만들었다.
• 우리 팀은 크게 두가지 였는데 노션과 Figma였다. (이거 두개다 내가 적극적으로 주장하고 기본 틀을 만들었다. 물론 그 이후에는 팀원들과 같이 더 잘 만들었지만..)
• 팀 노션의 구조는 크게 아래의 4가지였다.
  • 협업과 화목한 소통을 위해 육성으로가 아닌 문서로 자신이 다른 포지션에게 요구사항을 전달할 수 있는 공유 사항
  • 포지션별로 회의와 각종 자료들을 정리할 수 있는 포지션 별 하위 페이지
  • 프로젝트의 뼈대를 담당하는 문서를 정리하는 프로젝트 구성 페이지
  • 프로젝트의 룰을 정하고 피드백들을 정리하는 프로젝트 진행 페이지
• 이렇게 정리를 하고 나니 프로젝트가 좀 더 정형화되어 진행되는 느낌이었고 중구난방 마구잡이식이 아니어서 좋았다.

프로젝트 주제

• 우리 팀은 리더님의 지인이 기획자 지망이셔서 같이 하기로 되어 기획자님께서 미리 짜놓으신 패션 커뮤니티를 하기로 결정했다.
• 사실 다른 팀원들은 랜덤으로 정해진 팀에서 주제가 이미 정해져 있다는 부분에서 마찰이 있을 수 있었지만
• 기본적으로 팀원들이 성격이 매우 좋으신 분들이라는 점과
• 막무가내로 주제를 밀어붙이는 것이 아닌 다른 대안이 있는지 아니면 불만족스러운 점은 없는지 계속 여쭤보면서 최대한 존중에 가치를 두어 문제를 해결했다.

소통! 협업! 다시 소통!

• 첫주차는 정말 정말 팀원들끼리 할 말이 많았다.
• 우선 API를 짜는 것 부터 시작해서
• 디자이너분과의 소통, 기획자님과의 소통, 백엔드분들과의 소통
• 모든게 다 대화와 타협으로 진행되었다.
• 사실 이제와 하는 말이지만 이 구간이 꽤나 힘들었다.

API 짜기

• API는 사실 어느정도 백엔드가 주도적으로 짜는것이 맞다고 생각한다.
• 하지만 그럼에도 반드시 무조건 API짜는 자리에는 프론트가 같이 있어야 하는데
• API를 너무 침범해도 안되지만 방치하면 API가 완성되고 이게 뭐지?…하며 다시 백엔드를 찾아가야 하기 때문이다.
• 또한 API가 추가된다는 것은 프론트적으로 그 API로 무언가를 만들어야 한다는 것이기에 꼼꼼이 살피며 정해진 기간내에 할 수 없는 것은 쳐내야 하는 부분도 있었다.
• API를 짤때 힘들었던 점은 꼼꼼함과 체력이었다.
• 계속해서 수많은 대화를 하며 서로의 통신 약속을 짜는데 이게 지금 빈틈이 있으면 나중에 다시 돌아와서 다시 짜야한다는 것을 너무 잘 알기에 정말 꼼꼼하고자 심혈을 기울였고
• 우리는 다른 팀에 비해 약 2일 정도를 더 쓰며 API명세를 짲고 API의 볼륨도 다른 팀의 2~3배는 되었다.
• (그리고 그럼에도 나중에 다시 조금은 수정을 하고 추가를 했다..)

소통 방법

• 디자이너님과 기획자님과의 협업에서 처음에 힘든 것은 단연 소통방법의 어려움이었다.
• 처음 1일차에는 디자이너님이 안계셨고 우리팀은 figma라는 툴에 전혀 안익숙한 상태였었다.
• 그래서 내가 생각해낸 방법이 figma로의 단체 이주였다.
• 우선 우리는 이미 항해99를 해왔기에 서로 많이 친했었고 따라서 우리가 조금 더 디자이너님께 친숙한 툴의 방향으로 가는것이 좋았다.

• 우리가 figma에 익숙해지니 디자이너님과의 소통은 물론이고 개발자들끼리도 와이어프레임을 토대로 글자 공간의 제약없이 작성하니 소통이 훨씬 원활했다.
• 문제는 그 다음이었다..

안됩니다! 못합니다! 힘듭니다! 대신

• 모든 팀에 공통이었겠지만 디자이너와 프론트의 마찰은 공포영화에서 멍청한 커플이 죽는 것보다 더더욱 당연한 것이었다.
• 왜냐면 디자이너님께서는 자신의 프로젝트가 조금 더 완성도 있기를 바라고 다른 서비스에서는 당연하게 되는 기능이며 무엇이 쉽고 무엇이 시간이 많이 걸리는지를 잘 모르실 수 있기 때문이다.
• 개발자 입장에서는 물론 다 해드리고 싶고 시간만 있으면 구현 할 수 있지만 문제는 시간이 한정되어있다는 점이다.
• 이 문제를 해결하기 위해서
  • 목소리의 온도를 높여서 따뜻하게 말하고
  • 최대한의 긍정 이후 안되는 이유를 최대한 자세하게 말한 후
  • 반드시!!! 디자이너님의 요구사항을 figma에 addon으로 기록해두었다.
• 내 생각으로는 어떻게든 거절하면 무시하는 느낌이 아주 조금이라도 날 것 같았고 따라서 꼭 기록을 해두어야 시각적으로도 유의미하게 기록이 남아있고 실제로 그렇게 addon으로 남겨둔 기능들 중 구현한 기능도 꽤 많이 된다,

데이터 흐름도

• 실전프로젝트를 들어가기 전 항상 하고 싶은 것이 있었다.
• 바로 데이터 흐름도 인데 나는 무언가 프로세스가 진행될때 그 흐름을 눈으로 머리로 이해하는 것을 좋아한다.
• 그 흐름의 꽃을 나는 흐름도라 불렀다. (이건 그냥 마인드맵이다)
• 필요없을 수도 있는데 다행이도 팀원분도 매우매우 긍정해주셨고 덕분에 API를 바탕으로 우리는 추가적으로 흐름도를 만들었다.
• 사실 API이후 바로 만들었기에 겨우겨우 만들었지 사간 좀 지난다음 만들었다면 분명 만들지 못했을 것이다.
• 사실2 이것을 만들고 나는 생각보다 많이 활용하지는 못했는데 이걸 만들면서 이미 redux의 상태관리 흐름이 머리속에 잘 정리 되었기 때문이다.
• 따라서 만들면서의 효과가 엄청났고 이후에는 그저 저장소였지만 정말 만족했던 경험이었다.