42서울 오픈스튜디오 프로젝트 개발기 - 4

42서울에서 진행하는 42 서울을 위한 프로젝트 개발기

네 번째 이야기

📅 (2021 / 03 / 22 ~ 2021 / 03 / 29)

팀원 중에 블랙홀 기간(42서울 생존 기간)이 얼마 남지않은 사람이 있어서 한 주의 블랙홀 탈출 시간을 갖고 3월 22일부터 프로젝트를 정상적으로 진행을 시작했다.

📑 명확하고 무결성이 깨져있지 않은 문서

지난 우리 팀의 보고서 피드백의 내용은 명확하지 않으며 무결성이 깨져있다는 내용이었다. 멘토님 피드백 중에서 가장 와닿은 것은 팀 매칭이라는 것이 어떻게 이루어지는 지에 대한 것이었다. 말이나 글로는 단지 팀 매칭이라고 정의를 할 수 있지만 현재의 팀원들이 아닌 다른 팀원들이 우리 팀에 들어와서 팀 매칭이라는 얘기를 들었을 때 팀과 팀이 매칭이 되는 것인지, 개인과 팀이 매칭이 되는 것인지 누군가가 의도적으로 팀을 선택해서 매칭을 하는 것인지 알 수가 없었다. 그래서 우리팀 이러한 점부터 하나씩 바로 잡기위해서 유저 스토리 레벨로 내려가 다시 재점검을 하는 것부터 시작했다.

확실히 위에 관점으로 유저스토리를 보았을 때 충분히 명확하지 않고 헷갈릴 수 있는 내용으로 적어놓은 것들이 보였고 이것들을 하나씩 바꿔나가기 시작했다. 우선 다양한 표현들을 명확한 표현으로 정리했다. 예를 들어 어느 부분에서는 팀 매칭 신청이고 다른 부분에서는 같은 내용이지만 다른 이름으로 표현하고있는 부분을 하나의 “랜덤 팀 매칭” 이라는 단어로 통일하여 표현했다. 그 다음으로 “랜덤 팀 매칭” 이라는 표현을 명확하게 정의를 했다. 팀원이 아닌 제 3자가 왔을 때 명확하게 이해할 수 없는 단어이면 안되기 때문에 명확하게 설명이 적힌 딕셔너리를 만들어서 모호한 부분을 제거했다.

명확해진 유저스토리

유저스토리를 작성하고 난 후 *“무결성” 이라는 키워드에 집중하면서 다음 문서 작성을 시작하기로 했다. 우리 팀이 생각한 다음 문서는 유즈케이스 다이어그램이었다. 이전에 작성한 유즈케이스 다이어그램을 보니 기능이라고 생각되는 것이 아닌 내용이 관계를 이루고 있는 부분이 있었고 누락된 기능들도 있었다. 명확하게 기능을 정의를 하고 유즈케이스 다이어그램으로 기능을 옮긴 것이 아니라 유저스토리를 보면서 기능을 뽑아서 진행을 했기 때문에 보이는 대로 기능을 적었었고 이것이 기능 누락과 이상한 내용이 들어가도록 만든 것으로 생각이 들었다. 그래서 우리 팀은 기능을 명확하게 뽑기 위한 유저 시나리오 문서를 먼저 작성을 진행했다.

유저 시나리오

유저가 어떤 기능을 이용할 수 있는 지에 대한 내용은 이전에 이미 많은 회의를 거쳐 명확했다. 또한 유저스토리를 명확하게 작성되어있어서 유저 시나리오에서 헷갈리거나 모호한 부분이 없었다. 그래서 무결성이 깨지지 않도록 하면서 유저 시나리오는 빠르게 작성할 수 있었다. 이제서야 기능들이 명확히 문서로 정의가 되었다.

재작성한 유즈케이스 다이어그램

유저 시나리오에 명확히 적혀 있는 기능들을 어떤 관계를 이루는 지에 대해서만 표현하면 되었기 때문에 유저 스토리를 만들고 유저 시나리오를 만들 때처럼 유즈 케이스 다이어그램도 금방 작성이 되었다.

🔗 와이어 프레임이 하는 역할

다시 와이어 프레임 작성의 시간이 돌아왔다. 이전 멘토님의 우리 팀 와이어 프레임 문서에 대한 피드백은 와이어 프레임인데 이 페이지에서 저 페이지로 이동하는 것들이 안보인다는 것이었다. 사실 와이어 프레임이 흐름을 나타내는 것이라는 것은 인지를 하고 있었다. 하지만 흐름을 나타내는 것이 가장 중요한 부분이라는 것을 놓친 것이 큰 실수였다. 그때의 우리 팀은 어느 정도의 화면 모습이 나타나져야 된다고 생각했고 figma를 이용해서 작성을 했었고 생각보다 화면을 상세하게 표현을 했었다. 불필요하게 디자인을 하는 방향으로 생각했던 것이었다. 그리고 화살표를 이용해서 어떤 흐름으로 넘어가는 지를 표현을 했었는데 보고하는 시간에 연결하는 부분을 모두 제외하고 보고를 했었다.

과거에 했던 큰 실수를 반복하지 않는 것을 주의하면서 화면의 흐름을 나타내는 것을 중심적으로 와이어 프레임을 재작성을 했다.

재작성한 와이어 프레임

다시 돌아온 보고의 시간 🙋‍♂️

우리 팀은 와이어 프레임까지 작성을 완료하고 시퀀스 다이어그램을 그리기 시작했다. 시퀀스가 조금 작성되었을 때쯤 월요일이 되어 멘토님에게 현재 진행상황을 보고하는 시간이 되었다.

주간 보고서

전체적으로 무결성을 맞추어 작성한 서류에 대한 피드백 보다는 다음으로 생각하고 진행해야할 것들에 대한 내용을 말씀해주셨다. (그렇다고 서류를 잘한 것은 아니라고 하셨다,,)

우선은 기획, 설계 기간이 길어지기 때문에 먼저 프로토타입을 개발하라고 하셨는데 우리 프로젝트의 목표에 대해서도 물어보셨다.어느 정도의 유저가 사용하는 것 혹은 어떤 것이 되어야 프로젝트의 성공인지 이런 것들을 얘기하시면서 이 내용이 개발 단계에서 정의되어 있어야 된다고 하셨다. 이 부분에 대해서 우리 팀은 아무 생각이 없었는데, 사실 프로젝트가 실제 사업이라고 생각을 했을 때 굉장히 중요한 점이었다.

우리 팀 프로젝트의 성공 목표와 지표에 대해서 생각을 해보고 프로토타입을 만들어보고 지표를 이용해서 우리 팀이 생각한 서비스가 정말로 사람들(42 카뎃)이 이용하고 필요로 하는 것인지 아니면 우리 팀의 단순한 생각이였는 지 증명을 해보라는 내용을 얘기해주셨다.

그리하여 우리 팀은 이제 프로젝트 성공 목표와 지표를 정하고 프로토 타입 개발을 시작하게 되었다.

🚦 한 주의 내용 짧은 평가

평가 점수 🟢

한 주의 블랙홀을 기간을 갖게되어서 프로젝트 일정이 조금 느려졌지만 이번주는 내용이 착실히 잘 된것으로 생각이 든다. 왜 유저스토리와 시나리오, 유즈케이스 다이어그램이 필요한 지와 이것으로 와이어 프레임을 어떻게 만들어야 하는 지를 명확히 깨달을 수 있는 한 주였던 것 같다.

앞으로 프로토타입 개발을 해야하는데, 시퀀스 다이어그램이 없이 어떻게 개발해야 될 지 걱정이 되는데 일단은 부딪혀보라는 것이 멘토님의 생각처럼 일단 부딪혀 볼 예정이다.