처음처럼
우리는 처음 스낵게임을 기획할 때, 간단한 서비스 플로우를 그렸었다.
덕분에 지금까지 자연스레 서비스와 도메인에 대한 지식을 공유하고, 발전시키며 개발을 진행할 수 있었다.
인지하지 못했지만, 굉장히 기특한 친구였다.
우리 아이가 달라졌어요
프로덕트가 발전하면서 구성원들의 관심사는 계속 변하고, 스스로 결정하게 되는 부분도 있을 것이다.
이런 결정들은 자동으로 공유되지 않는다.
우리도 어느 순간 서비스에 대한 지식에 서로 다른 부분이 존재한다는 것을 인지하게 되었다.
서로 용어가 통일되지 않은 경우, 서비스 플로우를 서로 다르게 알고 있는 경우 등…
그 때마다 ‘앞으로 이렇게 부르기로 하자’, ‘이렇게 이렇게 동작해’라고 하지만, 금새 잊혀지기 마련이다.
처음과 지금, 우리 아이에게는 달라지고 새로 생긴 부분들이 있다. 그래서 새로운 지도가 필요하다.
의사소통 효율성
스낵게임 팀은 질문에 열려있다. 모르면 물어보면 된다.
하지만 아는 것이 아무것도 없다면, 상대는 하나부터 열까지 설명해야 한다.
한두번은 괜찮지만, 새로운 구성원이라도 생기는 날에는 이것을 반복해야 한다.
구성원들간에 최소한의 맥락을 공유할 수 있는 수단이 있다면 어떨까?
우리가 서비스의 어떤 부분을 이야기하는지, 자신이 무엇을 모르는지 어렵지 않게 짚어낼 수 있을 것이다.
여태 그래왔던 것처럼 효율적으로 의사소통하고, 구성원의 의견을 더 잘 이해할 수 있을 것이다.
발전 아이디어를 내기도 수월할 것이다.
목표
- 전체적인 서비스(비즈니스) 플로우를 함께 정의하고, 쉽게 파악할 수 있게 한다.
- 서로의 도메인 지식을 공유한다.
- 처음 보는 사람이 서비스를 빠르게 파악하기 좋게 한다.
이벤트 스토밍
스낵게임만의 기준으로!
실제로 이벤트 스토밍을 하려니, 조금은 막막했다.
처음이다보니 아는 바가 없었고, 인터넷엔 정보도 거의 없었다.
그래서 우리는 어떤 틀에 맞추기보다, 우리만의 기준으로 만들어보기로 했다.
‘구성원이 공감하는 서비스 플로우를 만든다’는 목적이 가장 중요하다고 생각했기 때문이다.
우리는 스낵게임만의 몇가지 기준을 세웠다.
- Command, Event, Policy
- 이벤트 → 발생하는 사건들. ‘~~ 되었다’의 형식으로 표현하자. UI는 ‘나타났다’로!
- 커맨드 → 이벤트들의 시작 지점, 사건의 발단!
- 정책 → 이벤트들의 분기 지점!
- 이벤트들의 배치는 수평으로? 수직으로?
- 시간 흐름은 수평으로, 동시에 발생하는 일은 수직으로!
- Policy 이후의 이벤트는 어떻게 배치해야할까?
- 딱 붙여서 한 덩어리임을 표현하자.
정책의 영향이 어디까지인지를 나타낼 수 있다.
실행
다이소에서 3색 포스트잇과 도화지를 사왔다.
그리고 갑자기 만나서 이벤트 스토밍을 진행했다.
그 과정은 다음과 같았다.
과정
- 각자 이벤트들을 도출한다.
- 중복되는 이벤트를 제거한다.
- 커맨드, 정책 같은 요소를 활용해 이벤트들을 기준에 따라 나열한다.
결과물은 위와 같다.
이제 누구든 우리 팀에 데려와 서비스를 설명할 수 있을 것 같다.
실제로 서비스를 한눈에 파악하기 좋다는 피드백도 받았다.
잘했거나, 못했거나보다는 목적을 만족하는데 한발짝 다가섰다는 것이 기뻤다.
References
방법론에 대한 정리 - 블랙캣 (개인 자료, 업로드 하지 않음)
MSA 구성 요소, 배치 등 참고
성하~ 블로그
![[기획 & 설계] 이벤트 스토밍(Event Storming) 도입기](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Ft1.daumcdn.net%2Ftistory_admin%2Fstatic%2Fimages%2FopenGraph%2Fopengraph.png)
회고
땡칠이벤트 스토밍. 말은 거창하지만, 우리가 이미 해봤던 것과 유사해서 놀랐다.
사실 우리는 이미 잘 하고 있었던 것이 아닐까? 하는 생각이 들었다.
이벤트 스토밍을 실제로 해보니 '이걸 기반으로 패키지 구조를 구축해야지~’, ‘코드도 이렇게 작성해야지~' 하는 생각보다는,
‘우리 서비스를 더 잘 알게되어 좋다’, '팀원들끼리 서비스에 대한 지식, 도메인 지식을 공유할 수 있어서 좋다', '너랑 나랑 같은 생각하는거 맞지?' 와 같이 협업 측면의 장점이 엄청 와닿았다.
신기했던건 나보다 희수가 훨씬 더 잘 아는 면도 있었고, 이미 서로가 충분히 잘 알고있는 면도 있었다.
또, 분야를 막론하고 전체적인 흐름이 정리되어 한 눈에 파악하기 좋았다.
팀에 새로운 인원이 합류할 때, 도메인을 확장시킬 때 활용하고 싶다.
희수사공이 많을 때 배가 산으로 가는건 같은 그림을 바라보지 못해서 그렇다고 생각한다.
우리는 충분히 많은 의사소통이 있었지만 다른그림을 바라보고 있는 부분이 있지 않을까 생각도 했다.
실제로 이벤트 스토밍을 진행하니 우리는 같은 그림을 잘 바라보고 있었고 이해가 쉽고 한 눈에 볼 수 있는
만족스러운 결과물이 나온 것 같다.
이벤트 스토밍 과정 중 애매한 부분을 함께 재정의 하고 내 머리속의 도메인 지식들이 정리가 되는 부분도 있었다.
마찬가지로 새로운 인원이 들어온다면 팔로업(Follow-up)기간을 충분히 줄일 수 있을것 같았다.
개발적인 측면에서도 확장 되는 부분을 쉽게 확인할 수 있고 이벤트가 순차적으로 나누어져 있어 확장과 변경에 유연한 설계를 만들 때 도움이 될 것 이라고 생각한다.
